Zero Trust ตามมาตรฐาน NIST SP 800-207: เลิกเชื่อเครือข่ายภายใน

ยุคที่พนักงานทำงานจากทุกที่และระบบกระจายอยู่หลายคลาวด์ กำแพงเครือข่ายแบบเดิมไม่พออีกต่อไป บทความนี้อธิบายสถาปัตยกรรม Zero Trust ตามเอกสาร NIST SP 800-207 หลักการ Never Trust, Always Verify องค์ประกอบหลัก และแผนการเปลี่ยนผ่านที่องค์กรไทยเริ่มได้เป็นขั้นตอน

ทำไมโมเดลปราสาทกับคูเมืองถึงล้มเหลว

สถาปัตยกรรมความปลอดภัยแบบดั้งเดิมเปรียบเหมือนปราสาทกับคูเมือง (Castle-and-Moat) คือเข้มงวดที่ขอบเครือข่าย แต่เมื่อผ่านเข้ามาแล้วก็เชื่อใจแทบทุกอย่างภายใน ปัญหาคือเมื่อผู้โจมตีเจาะผ่านจุดเดียวได้ เช่น ผ่านอีเมล Phishing ของพนักงานหนึ่งคน ก็สามารถเคลื่อนที่ตามแนวราบ (Lateral Movement) ไปยังระบบสำคัญได้ทั่วองค์กร

โลกการทำงานปัจจุบันยิ่งทำให้เส้นขอบเครือข่ายเลือนหาย พนักงานทำงานจากบ้านและร้านกาแฟ ระบบกระจายอยู่บนหลายคลาวด์ และมี SaaS ภายนอกเต็มไปหมด NIST จึงจัดทำ Special Publication 800-207 เป็นเอกสารอ้างอิงกลางของสถาปัตยกรรม Zero Trust ที่หน่วยงานรัฐและเอกชนทั่วโลกใช้เป็นมาตรฐานตั้งต้น

หลักการแกนกลาง: Never Trust, Always Verify

Zero Trust ตามนิยามของ NIST ไม่ใช่ผลิตภัณฑ์ที่ซื้อมาติดตั้งได้ แต่คือชุดหลักการออกแบบ สาระสำคัญคือ ไม่มีการเชื่อถือโดยปริยายจากตำแหน่งบนเครือข่าย ทุกคำขอเข้าถึงทรัพยากรต้องถูกยืนยันตัวตน ตรวจสิทธิ์ และประเมินความเสี่ยง ต่อคำขอ (Per-Request) ไม่ใช่ตรวจครั้งเดียวตอนล็อกอินแล้วปล่อยยาว

หลักการสำคัญที่ NIST ระบุ ได้แก่ มองทุกแหล่งข้อมูลและบริการเป็นทรัพยากรที่ต้องคุ้มครอง, รักษาความปลอดภัยการสื่อสารเสมอไม่ว่าจะอยู่เครือข่ายใด, ให้สิทธิ์แบบ Least Privilege ต่อเซสชัน, ตัดสินใจจากหลายสัญญาณประกอบกัน (ตัวตน สุขภาพอุปกรณ์ พฤติกรรม) และเฝ้าติดตามวัดผลความปลอดภัยของทรัพย์สินทั้งหมดต่อเนื่อง

องค์ประกอบเชิงสถาปัตยกรรม: PDP และ PEP

หัวใจเชิงตรรกะของ NIST SP 800-207 คือการแยกจุดตัดสินใจออกจากจุดบังคับใช้ Policy Decision Point (PDP) ประกอบด้วย Policy Engine ที่ประเมินทุกคำขอจากนโยบายและสัญญาณความเสี่ยง ส่วน Policy Enforcement Point (PEP) คือด่านที่ยืนขวางระหว่างผู้ใช้กับทรัพยากร คอยเปิดหรือตัดการเชื่อมต่อตามคำตัดสินของ PDP

Policy Engine ที่ดีใช้ข้อมูลประกอบหลายแหล่ง เช่น ระบบ Identity (ตำแหน่งงาน สถานะพนักงาน), สุขภาพอุปกรณ์ (แพตช์ครบไหม มี EDR ไหม), ตำแหน่งและเวลาเข้าถึง และ Threat Intelligence การตัดสินใจจึงเป็นแบบไดนามิก เช่น พนักงานคนเดิมเข้าระบบเดิมจากอุปกรณ์ที่ไม่ผ่านเกณฑ์ อาจถูกลดสิทธิ์ให้อ่านได้อย่างเดียวหรือถูกบังคับยืนยันตัวตนเพิ่ม

เสาหลักที่ต้องสร้าง: Identity, Device และ Micro-Segmentation

รากฐานข้อแรกคือระบบ Identity ที่เข้มแข็ง ใช้ Single Sign-On รวมศูนย์ บังคับ MFA ทุกบัญชี โดยเฉพาะแบบทนต่อ Phishing เช่น FIDO2/Passkey สำหรับบัญชีสิทธิ์สูง และมีกระบวนการเพิกถอนสิทธิ์ทันทีเมื่อพนักงานพ้นสภาพ ข้อมูลจากรายงานอุตสาหกรรมชี้ตรงกันว่าบัญชีที่ถูกขโมยคือช่องทางโจมตีอันดับต้น ๆ และ MFA ตัดการโจมตีอัตโนมัติได้เกือบทั้งหมด

ถัดมาคือทะเบียนและสุขภาพอุปกรณ์ (Device Inventory/Posture) และการแบ่งเครือข่ายเป็นส่วนย่อย (Micro-Segmentation) เพื่อจำกัดรัศมีความเสียหาย เช่น เซิร์ฟเวอร์ฐานข้อมูลรับการเชื่อมต่อจากแอปที่กำหนดเท่านั้น ไม่ใช่จากทั้ง VLAN สำหรับการเข้าถึงระยะไกล แนวทาง ZTNA (Zero Trust Network Access) ให้เข้าถึงเป็นรายแอปตามสิทธิ์ แทน VPN แบบเดิมที่เปิดประตูสู่ทั้งเครือข่าย

แผนเปลี่ยนผ่านสำหรับองค์กรจริง

NIST ย้ำว่าการย้ายสู่ Zero Trust เป็นการเดินทางแบบค่อยเป็นค่อยไป ไม่ใช่โครงการรื้อระบบครั้งเดียว ขั้นแรกให้จัดทำทะเบียนทรัพย์สิน ผู้ใช้ และกระแสข้อมูล (ใครคุยกับระบบไหน ด้วยสิทธิ์อะไร) เพราะเราคุ้มครองสิ่งที่มองไม่เห็นไม่ได้ จากนั้นเลือกเส้นทางธุรกิจที่มีความเสี่ยงสูงหรือระบบใหม่หนึ่งระบบเป็นโครงการนำร่อง

ลำดับที่ใช้ได้จริงสำหรับองค์กรขนาดกลาง: (1) บังคับ MFA และรวมศูนย์ Identity (2) ทำทะเบียนอุปกรณ์และเกณฑ์สุขภาพขั้นต่ำ (3) แทนที่ VPN ด้วย ZTNA สำหรับแอปภายใน (4) แบ่ง Segment ระบบสำคัญ (5) รวม Log เข้าศูนย์กลางและตั้งการตรวจจับพฤติกรรมผิดปกติ แต่ละขั้นให้คุณค่าด้วยตัวเองแม้ยังไปไม่ครบทั้งเส้นทาง

ข้อควรระวังและความเข้าใจผิดที่พบบ่อย

ระวังการตลาดที่ขาย "กล่อง Zero Trust" สำเร็จรูป NIST ระบุชัดว่านี่คือสถาปัตยกรรมและกระบวนการ ไม่มีผลิตภัณฑ์เดียวที่ทำให้เป็น Zero Trust ได้ทันที อีกความเข้าใจผิดคือคิดว่า Zero Trust แปลว่าเลิกใช้การป้องกันขอบเครือข่ายทั้งหมด ความจริงคือ Firewall และการป้องกันเดิมยังมีประโยชน์ เพียงแต่ไม่ใช่แนวป้องกันเดียวอีกต่อไป

สุดท้าย อย่าลืมสมดุลด้านประสบการณ์ผู้ใช้ นโยบายที่เข้มจนพนักงานต้องยืนยันตัวตนซ้ำทุกสิบนาทีจะผลักคนไปหาทางลัดที่อันตรายกว่า เป้าหมายที่ถูกคือความปลอดภัยที่แนบเนียน เข้มงวดขึ้นเฉพาะเมื่อความเสี่ยงสูงขึ้น สำหรับองค์กรไทย แนวทางนี้ยังช่วยตอบข้อกำหนดมาตรการความมั่นคงปลอดภัยตาม PDPA และกฎเกณฑ์ของหน่วยงานกำกับในภาคการเงินได้โดยตรง