แนวปฏิบัติ Zero Trust ของ สกมช.
สรุปแนวปฏิบัติ Zero Trust (Zero Trust Guidelines) ฉบับเผยแพร่ v1.0 ของ สกมช. สำหรับผู้บริหาร ผู้กำหนดนโยบาย ทีมเทคนิค ผู้ดูแลระบบ และวิศวกรความมั่นคงปลอดภัย เพื่อวางแผนเปลี่ยนผ่านจากการป้องกันแบบอาศัยขอบเขตเครือข่ายสู่การตรวจสอบอย่างต่อเนื่องตามความเสี่ยง
- กลุ่มเป้าหมายที่บังคับใช้
- ผู้บริหาร ผู้กำหนดนโยบาย ทีมเทคนิค และวิศวกรความมั่นคงปลอดภัยที่วางแผนเปลี่ยนผ่านจาก Perimeter-based Security
- ความถี่ในการทดสอบ
- ทบทวน Protect Surface นโยบาย และ maturity ตามแนวปฏิบัติ ไม่ใช่ข้อบังคับ pentest รายปี
- ขอบเขตการทดสอบ
- ตัวตน อุปกรณ์ เครือข่าย แอปพลิเคชันและเวิร์กโหลด และข้อมูล ตาม Zero Trust Maturity Model
- ความเสี่ยงหากไม่ปฏิบัติตาม
- การถูกโจมตีแบบ Lateral Movement เมื่อยังเชื่อถือเครือข่ายภายในโดยปริยาย
หลักคิด Zero Trust และขอบเขตการนำไปใช้
แนวปฏิบัติอธิบายการเปลี่ยนสมมติฐานจากการเชื่อถือเครือข่ายภายใน ไปสู่การตรวจสอบทุกคำขอเข้าถึงตามตัวตน สถานะอุปกรณ์ และบริบทของเซสชัน
ทุกคำขอต้องผ่านการตัดสินใจตามบริบทและบังคับใช้สิทธิเท่าที่จำเป็น
- ทรัพยากรเป็นบริการ — ปกป้องข้อมูล แอป สินทรัพย์ และบริการ
- อนุญาตเป็นรายเซสชัน — ให้สิทธิเท่าที่จำเป็นต่อคำขอ
- ใช้นโยบายตามบริบท — ประเมินตัวตน อุปกรณ์ ตำแหน่ง และพฤติกรรม
- ไม่เชื่อถือจากตำแหน่ง — เครือข่ายภายในไม่ทำให้คำขอน่าเชื่อถือเอง
- ตรวจสถานะสินทรัพย์ — ประเมินอุปกรณ์และระบบอย่างต่อเนื่อง
- ปกป้องการสื่อสาร — ยืนยันและเข้ารหัสทุกเส้นทาง
- ใช้ Telemetry ปรับนโยบาย — นำข้อมูลเหตุการณ์กลับไปปรับการตัดสินใจ
- ทรัพยากรทั้งหมด เช่น ข้อมูล แอปพลิเคชัน บริการ และอุปกรณ์ ควรถูกมองว่าเป็นสิ่งที่ต้องปกป้อง ไม่ว่าตั้งอยู่ที่ใด
- การเข้าถึงต้องกำหนดเป็นรายเซสชันและปรับตามความเสี่ยง โดยใช้ข้อมูลประกอบ เช่น ตัวตน สถานะอุปกรณ์ ตำแหน่ง และพฤติกรรมที่เกี่ยวข้อง
- หลักการ 7 ประการของ Zero Trust เน้นการยืนยันตัวตนและการอนุญาตที่เข้มงวด การตรวจสอบความมั่นคงปลอดภัยของสินทรัพย์อย่างต่อเนื่อง และการใช้ข้อมูลที่เก็บได้เพื่อปรับปรุงมาตรการ
สถาปัตยกรรมและจุดตัดสินใจเชิงนโยบาย
เอกสารอธิบายว่า requester และอุปกรณ์ต้องผ่านจุดตัดสินใจตามนโยบายก่อนเข้าถึงทรัพยากร โดยแยกหน้าที่ตัดสินใจ จัดการเซสชัน และบังคับใช้นโยบาย
PE ประเมินคำขอ ส่วน PA สั่งสร้างหรือยุติเซสชัน การเข้าถึงทรัพยากรจริงผ่าน PEP จึงต้องทดสอบทั้งการตัดสินใจและการบังคับใช้
- ผู้ร้องขอและอุปกรณ์ — ส่งคำขอพร้อมบริบท
- Policy Engine (PE) — ประเมินนโยบายและความน่าเชื่อถือ
- Policy Administrator (PA) — สร้างหรือยุติเซสชัน
- จุดบังคับใช้ (PEP) — เปิด ตรวจสอบ หรือยุติการเชื่อมต่อ
- ทรัพยากร — เข้าถึงเท่าที่ได้รับอนุญาต
- Policy Engine ประเมินนโยบายและข้อมูลประกอบเพื่อวินิจฉัยว่าอนุญาตการเข้าถึงได้หรือไม่
- Policy Administrator จัดตั้งหรือยุติเส้นทางการสื่อสาร รวมถึงจัดการ Session Token และ Credential ตามผลการตัดสินใจ
- Policy Enforcement Point เป็นจุดที่เปิด ตรวจสอบ หรือยุติการเชื่อมต่อ และควรรับข้อมูลจาก identity, device, security telemetry และแหล่งข้อมูลที่เกี่ยวข้อง
การเปลี่ยนผ่าน 5 ขั้นตอนตามความเสี่ยง
แนวปฏิบัติให้เริ่มจากพื้นที่ป้องกันที่ชัดเจนและขยายผลเป็นลำดับ แทนการปรับเปลี่ยนทุกระบบพร้อมกัน
เริ่มจากพื้นที่ที่ต้องปกป้องและ Flow จริง ก่อนเลือกเทคโนโลยี
- กำหนด Protect Surface — ระบุ Data, Applications, Assets และ Services
- ทำแผนผัง Transaction Flow — เข้าใจการสื่อสารและการพึ่งพา
- ออกแบบสถาปัตยกรรม — เลือกแนวทางให้ตรงบริบทและความเสี่ยง
- กำหนดนโยบาย 5W1H — ระบุ Who, What, When, Where, Why และ How
- เฝ้าระวังและบำรุงรักษา — ใช้ Log, Alert และ Feedback ปรับนโยบาย
- กำหนด Protect Surface และกลยุทธ์ที่อิงตามความเสี่ยง จากนั้นจัดทำ Transaction Flows เพื่อเข้าใจการเชื่อมโยงของข้อมูล แอปพลิเคชัน สินทรัพย์ และบริการ
- ออกแบบสถาปัตยกรรม Zero Trust สำหรับพื้นที่นั้น โดยพิจารณา identity, segmentation, microsegmentation, cloud หรือ hybrid ตามบริบทและระดับความเสี่ยง
- กำหนดนโยบายด้วยกรอบ 5W1H คือ Who, What, When, Where, Why และ How แล้วเฝ้าระวัง บันทึกเหตุการณ์ แจ้งเตือน และทบทวนพื้นที่ป้องกันกับนโยบายอย่างต่อเนื่อง
Gap analysis, maturity และการดำเนินงานต่อเนื่อง
การประเมินช่องว่างต้องครอบคลุมกลยุทธ์ การกำกับดูแล ข้อมูล สินทรัพย์ การดำเนินงาน และประสิทธิผลของการควบคุม ไม่ใช่เปรียบเทียบรายการเครื่องมืออย่างเดียว
ประเมินแต่ละเสาหลักแยกกัน ตามระดับ Traditional, Initial, Advanced และ Optimal แล้วกำหนดเป้าหมายและแผนปรับปรุง
- ตัวตน — ประเมินการยืนยันตัวตน สิทธิ และความเสี่ยง
- อุปกรณ์ — ประเมินสถานะและความน่าเชื่อถือของอุปกรณ์
- เครือข่าย — ประเมินการแบ่งส่วน การเชื่อมต่อ และ Telemetry
- แอปพลิเคชันและเวิร์กโหลด — ประเมินสิทธิและการปกป้อง Workload
- ข้อมูล — ประเมินการจัดชั้น การเข้าถึง และการป้องกัน
- ใช้ Risk Management Framework เป็นโครงสำหรับวิเคราะห์ช่องว่าง ตั้งแต่การเตรียมตัว จัดหมวดหมู่ เลือกมาตรการ ประเมิน อนุญาต และเฝ้าระวัง
- ใช้ Zero Trust Maturity Model เพื่อประเมินความพร้อมใน 5 เสาหลัก ได้แก่ identity, devices, networks, applications and workloads และ data พร้อมตัวชี้วัดความเสี่ยง
- จัดทำบทบาทและความรับผิดชอบ การสื่อสาร การฝึกอบรม และวงจรป้อนกลับ เพื่อให้ policy ปรับตามเหตุการณ์และสภาพแวดล้อมที่เปลี่ยนไป
ตารางเปรียบเทียบข้อกำหนดและการทดสอบความปลอดภัย
สรุปรายละเอียดประกาศ บทบัญญัติ และขอบเขตการทดสอบความปลอดภัยที่จำเป็น
| ประกาศ และข้อกำหนด | สาระสำคัญ | ขอบเขตการทดสอบ | รอบเวลาทดสอบ |
|---|---|---|---|
| หลักการ 7 ประการ (NIST SP 800-207 ตามแนวปฏิบัติ สกมช.) | ตรวจสอบทุกคำขอเข้าถึงตามตัวตน สถานะอุปกรณ์ และบริบทของเซสชัน | Policy Engine, Policy Administrator และ Policy Enforcement Point | ตรวจสอบแบบรายเซสชันตามแนวปฏิบัติ ไม่ใช่รอบ pentest รายปี |
| เสาหลัก 5 ด้าน (CISA ZTMM ตามแนวปฏิบัติ สกมช.) | ประเมิน maturity ของตัวตน อุปกรณ์ เครือข่าย แอปพลิเคชันและเวิร์กโหลด และข้อมูล | Protect Surface, Transaction Flow และนโยบาย 5W1H | ประเมินตามบริบทและขยายพื้นที่ป้องกันเป็นลำดับ |
เครื่องมือประเมินความพร้อม
คลิกเลือกรายการที่องค์กรของท่านได้ดำเนินการแล้ว เพื่อคำนวณระดับความพร้อมเบื้องต้น
คำถามที่พบบ่อย (FAQ)
คำถามและข้อสงสัยสำคัญเกี่ยวกับข้อกำหนดและการตรวจประเมินตามมาตรฐาน
หลักการ Zero Trust Architecture (ZTA) แตกต่างจากแนวทางรักษาความปลอดภัยแบบเดิมอย่างไร?
แนวทางเดิมเน้นการป้องกันขอบเขตเครือข่ายภายนอก (Perimeter Security) แต่ Zero Trust ใช้หลักการ ไม่ไว้วางใจใครและต้องตรวจสอบสิทธิ์เสมอ แม้การเชื่อมต่อจะมาจากภายในเครือข่ายองค์กรก็ตาม
การย้ายระบบไปสู่ Zero Trust ต้องเริ่มต้นจากส่วนใดก่อน?
แนวปฏิบัติให้เริ่มจาก Protect Surface และกลยุทธ์ตามความเสี่ยง จากนั้นจัดทำ Transaction Flow ออกแบบสถาปัตยกรรม และกำหนดนโยบายด้วยกรอบ 5W1H แล้วขยายพื้นที่ป้องกันเป็นลำดับ แทนการปรับทุกระบบพร้อมกัน
