เปลี่ยนผ่านสู่ยุค Zero Trust: แนวคิดพื้นฐานที่ควรเข้าใจ และตัวอย่างการใช้ในชีวิตจริง
Zero Trust ไม่ใช่สินค้า แต่เป็นแนวคิดการออกแบบความปลอดภัยที่ลดการเชื่อใจโดยปริยาย บทความนี้อธิบายแก่นของ Zero Trust ให้ตรงขึ้น แยกกรอบคิดของ Microsoft ออกจาก NIST และยกตัวอย่างการประยุกต์ใช้ในชีวิตจริงแบบ practical
เวลาพูดถึง Zero Trust หลายคนจะนึกถึงคำสั้น ๆ ว่า “Never Trust, Always Verify” ซึ่งก็ถือว่าเป็นแก่นที่ช่วยให้เข้าใจเร็ว แต่พอจะเอาไปใช้งานจริง เรื่องมักเริ่มซับซ้อนขึ้นทันที เพราะคำว่า Zero Trust ถูกใช้ทั้งในฐานะ philosophy, security strategy, architecture และบางครั้งก็ถูก vendor เอาไปทำให้เหมือนเป็นชื่อสินค้ากลุ่มหนึ่ง
ผมเลยอยากเขียนบทความนี้ใหม่ให้ตรงขึ้นและ practical มากขึ้น โดยเฉพาะในจุดที่มักสับสนกันบ่อย คือการเอากรอบของ Microsoft กับ NIST มาปนกันเหมือนเป็นชุดหลักการเดียวกัน ทั้งที่จริงแล้วสองฝั่งนี้พูดเรื่องเดียวกันในภาพใหญ่ แต่ใช้ภาษากับโครงอธิบายคนละแบบ
Zero Trust คืออะไร และทำไมมันถึงสำคัญ
ถ้าพูดแบบตรงไปตรงมา Zero Trust คือแนวคิดที่ตั้งต้นจากการไม่เชื่อว่าอะไรควร “ได้รับความไว้วางใจโดยอัตโนมัติ” เพียงเพราะอยู่ในเครือข่ายภายใน อยู่หลัง VPN หรือเป็นอุปกรณ์ขององค์กร
NIST SP 800-207 อธิบาย Zero Trust Architecture ว่าเป็นการย้ายจุดสนใจจากการป้องกัน perimeter แบบเดิม ไปสู่การปกป้องผู้ใช้ อุปกรณ์ ทรัพยากร และ resource แต่ละตัวให้มากขึ้น แนวคิดนี้เกิดขึ้นเพราะโลกปัจจุบันไม่ได้มีเส้นแบ่งชัดแบบเมื่อก่อนอีกแล้ว คนทำงานจากที่บ้าน ใช้ cloud ใช้ BYOD และเชื่อมต่อระบบภายนอกตลอดเวลา ถ้ายังคิดว่า “ข้างในปลอดภัย ข้างนอกไม่ปลอดภัย” อย่างเดียว มันเริ่มใช้ไม่ได้จริง
ถ้ามองในเชิงประวัติศาสตร์ แนวคิด Zero Trust ในโลก security สมัยใหม่มักถูกโยงกลับไปที่ John Kindervag จาก Forrester ราวปี 2010 ก่อนที่ต่อมาหลายองค์กรและสถาบันจะนำไปพัฒนาเป็น framework หรือ architecture guidance ของตัวเอง
จุดที่ต้องแยกให้ออก: Microsoft กับ NIST ไม่ได้ใช้กรอบเดียวกัน
เวลาคนเรียน Zero Trust ใหม่ ๆ มักเจอ 3 คำที่จำง่ายมากคือ
- Verify explicitly
- Use least privilege access
- Assume breach
สามข้อนี้เป็นกรอบที่ Microsoft ใช้อธิบาย Zero Trust ได้ดีและใช้งานง่ายมาก โดยเฉพาะสำหรับคนที่อยากเห็นภาพเร็วว่าแนวคิดนี้ควรเปลี่ยนวิธีตัดสินใจด้าน security อย่างไร
แต่สิ่งที่ต้องระวังคือ อย่าเผลอพูดว่า NIST ก็ “กำหนดสามหลักการนี้เหมือนกัน” เพราะไม่ตรงนัก NIST SP 800-207 ใช้โครงอธิบายที่กว้างกว่าและเป็นเชิง architecture มากกว่า เช่น การไม่ให้ network location เป็นตัวกำหนด trust, การทำ authentication และ authorisation ก่อนเข้าถึง resource, การบังคับใช้นโยบายแบบ dynamic และการเฝ้าติดตามอย่างต่อเนื่อง
พูดให้สั้นที่สุดคือ
- ถ้าจะอธิบายแบบจำง่ายและใช้งานในเชิง mindset กรอบของ Microsoft มีประโยชน์มาก
- ถ้าจะอธิบายเชิง architecture และหลักการออกแบบระบบ NIST SP 800-207 คือ reference สำคัญ
สองอย่างนี้เสริมกันได้ แต่ไม่ควรอ้างว่าเป็นชุดหลักการเดียวกันแบบตรงตัว
แล้วในชีวิตจริง Zero Trust หน้าตาเป็นอย่างไร
ปัญหาของ Zero Trust คือถ้าอธิบายแต่ทฤษฎี คนจะรู้สึกว่ามันลอยมาก ผมเลยคิดว่าควรมองผ่านตัวอย่างที่จับต้องได้
1. ปิดความเคยชินแบบ “เปิดพอร์ตทิ้งไว้ก่อน”
ในหลายบ้าน หลาย homelab หรือแม้แต่ในองค์กรขนาดเล็ก เรามักเห็นพฤติกรรมเปิดพอร์ตอย่าง 3389 สำหรับ RDP หรือ 22 สำหรับ SSH ออกอินเทอร์เน็ตตรง ๆ เพราะอยาก remote เข้าเครื่องให้สะดวก แนวคิดแบบ Zero Trust จะชวนให้ถามกลับทันทีว่า “จำเป็นไหมที่ service นี้ควรถูกเข้าถึงจากใครก็ได้บนอินเทอร์เน็ต”
ทางเลือกที่ปลอดภัยกว่ามักเป็นการใช้ ZTNA หรือ tunnel-based access เช่น Cloudflare Tunnel, Tailscale หรือ Twingate แทนการเปิด inbound port ตรง ๆ เพราะเราบังคับให้การเข้าถึงผูกกับ identity, policy และ context มากขึ้น
2. อย่าเชื่อว่า login ผ่านแล้วคือจบ
MFA เป็นตัวอย่างง่ายที่สุดของ Zero Trust mindset ถ้ายังใช้ SMS OTP อย่างเดียวก็ยังดีกว่าไม่มีอะไรเลย แต่โดยทั่วไป authenticator app หรือ hardware key เช่น YubiKey จะปลอดภัยกว่า เพราะลดความเสี่ยงจาก SIM swapping และการดักรับข้อความ
3. จำกัดสิทธิ์ให้แคบที่สุดเท่าที่จำเป็น
Least privilege ไม่ใช่แค่แนวคิดสวย ๆ แต่มันคือการลด blast radius เวลาอะไรผิดพลาด เช่น ถ้าบัญชีหนึ่งหลุด จะให้ attacker ไปได้ไกลแค่ไหน Microsoft เองก็อธิบายส่วนนี้ผ่านแนวทางอย่าง JIT และ JEA ซึ่งช่วยให้สิทธิ์ไม่ได้ถูกให้ค้างไว้ตลอดเวลาโดยไม่จำเป็น
4. มองที่ resource protection ไม่ใช่ network perimeter อย่างเดียว
Disk encryption เช่น BitLocker บน Windows หรือ FileVault บน macOS เป็นตัวอย่างที่ดีมาก เพราะมันสะท้อนแนวคิดว่าข้อมูลควรถูกปกป้องแม้อุปกรณ์จะไม่ได้อยู่ใน “เครือข่ายที่ไว้ใจได้” สมมติ laptop หาย สิ่งที่สำคัญไม่ใช่แค่ว่าเครื่องนั้นเคยอยู่หลัง firewall หรือไม่ แต่คือข้อมูลยังถูกป้องกันอยู่หรือเปล่า
สิ่งที่ Zero Trust ไม่ใช่
จุดนี้สำคัญพอ ๆ กับสิ่งที่มันเป็น
Zero Trust ไม่ใช่ผลิตภัณฑ์ชิ้นเดียวที่ซื้อแล้วจบ และไม่ใช่โครงการที่ต้องรื้อทุกอย่างภายในรอบเดียว NIST เองก็เขียนไว้ชัดว่า ZTA เป็นแนวทางเชิงสถาปัตยกรรมที่องค์กรสามารถนำไปปรับใช้ได้หลายแบบตามบริบท
ดังนั้นเวลา vendor บอกว่าซื้อเครื่องมือชิ้นนี้แล้ว “ได้ Zero Trust” สิ่งที่ควรถามต่อคือ ได้แค่ component หนึ่งของ Zero Trust หรือได้ policy, identity, monitoring, segmentation และ operational discipline ครบจริงหรือไม่
ถ้าจะเริ่มแบบ practical ควรเริ่มตรงไหน
สำหรับคนทั่วไป ทีมเล็ก หรือ homelab ผมคิดว่าเริ่มจาก 4 เรื่องนี้คุ้มที่สุด
- ปิดพอร์ตที่ไม่จำเป็นและลดการเปิด service ตรงสู่อินเทอร์เน็ต
- เปิด MFA ให้กับบัญชีสำคัญทั้งหมด โดยเลี่ยงการพึ่ง SMS เป็นตัวเลือกหลักถ้าทำได้
- ทบทวนสิทธิ์ของผู้ใช้และ service account ว่าให้เกินความจำเป็นหรือไม่
- เข้ารหัสดิสก์และข้อมูลสำคัญบนอุปกรณ์ปลายทาง
สี่อย่างนี้ยังไม่ใช่ Zero Trust ที่สมบูรณ์ แต่เป็นจุดเริ่มต้นที่ตอบโจทย์ชีวิตจริงมากกว่าการพูดเรื่อง architecture แบบกว้าง ๆ โดยยังไม่แตะ hygiene ขั้นพื้นฐาน
สรุปแบบตรงไปตรงมา
Zero Trust เป็นแนวคิดที่มีประโยชน์มาก แต่จะมีประโยชน์ก็ต่อเมื่อเราใช้มันอย่างแม่น ไม่ใช่ใช้เป็นคำเท่ ๆ ที่รวมทุกอย่างเข้าด้วยกันจนความหมายเบลอ
ถ้าจะสรุปให้ชัดที่สุด ผมคิดว่าเราควรจำไว้สามเรื่อง
- Zero Trust คือแนวคิดและ architecture ไม่ใช่สินค้า
- กรอบ 3 ข้อ Verify explicitly, Use least privilege access และ Assume breach เป็น framing ของ Microsoft
- NIST SP 800-207 เป็น guidance เชิง architecture ที่กว้างกว่าและไม่ควรถูกย่อเหลือแค่สามคำนี้
พอแยกตรงนี้ได้ เวลาคุยเรื่อง Zero Trust เราจะไม่สับสนระหว่าง mindset, vendor framing และมาตรฐานอ้างอิง และจะเริ่มนำไปใช้ในชีวิตจริงได้ตรงโจทย์กว่ามาก