Zero Trust ไม่ใช่ของที่ซื้อได้: ผู้บริหารควรลงทุนตามลำดับไหน และรายงานบอร์ดอย่างไร

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

คำตอบของคำถามนี้กำหนดลำดับการลงทุนทั้งหมด

บทความนี้เขียนให้ CTO, CIO และ CISO ที่ต้องอนุมัติงบและรายงานความคืบหน้าต่อบอร์ด เราจะเล่าว่าทำไมโมเดลความปลอดภัยแบบเดิมถึงรับความเสี่ยงระดับองค์กรไม่ได้แล้ว ควรลงทุนตามลำดับไหน และวัดผลอย่างไรให้บอร์ดเห็นว่าความเสี่ยงลดลงจริง

โมเดลเดิมไว้ใจตำแหน่งบนเครือข่าย ไม่ได้ตรวจตัวตน

ระบบความปลอดภัยที่หลายองค์กรใช้อยู่ถูกออกแบบรอบเส้นแบ่งเดียว คือข้างในกับข้างนอกเครือข่าย ใครผ่าน firewall หรือต่อ VPN เข้ามาได้ จะถูกมองว่าเป็นคนใน และมักเข้าถึงระบบภายในได้กว้างกว่าที่งานของเขาต้องใช้

สมมติฐานนี้เคยพอใช้ได้ ตอนที่พนักงานนั่งในสำนักงาน และระบบทั้งหมดอยู่ในห้องเซิร์ฟเวอร์ของตัวเอง วันนี้ระบบหลักกระจายอยู่บนคลาวด์หลายเจ้า พนักงานทำงานจากนอกสำนักงาน และผู้รับจ้างหลายรายถือบัญชีเข้าระบบขององค์กร เส้นแบ่งที่ใช้ตัดสินว่าใครน่าไว้ใจจึงไม่ตรงกับความจริงอีกต่อไป

รายงานสาธารณะชี้ไปทางเดียวกัน Data Breach Investigations Report (DBIR) 2026 ของ Verizon ที่เผยแพร่เมื่อ 19 พฤษภาคม 2569 พบว่า breach ที่มีบุคคลที่สามเกี่ยวข้องคิดเป็น 48% ของทั้งหมด เพิ่มขึ้น 60% จากรายงานปีก่อน ตัวเลขนี้เป็นข้อมูลระดับโลก ไม่ได้แยกประเทศไทย

ด้านค่าเสียหาย รายงาน Cost of a Data Breach 2026 ของ IBM และ Ponemon Institute พบว่าค่าเสียหายเฉลี่ยต่อ breach ในกลุ่มอาเซียนอยู่ที่ 4.12 ล้านดอลลาร์สหรัฐ เพิ่มจาก 3.67 ล้านในรายงานปีก่อน กลุ่มนี้รวมไทยกับสิงคโปร์ อินโดนีเซีย ฟิลิปปินส์ มาเลเซีย และเวียดนามไว้ด้วยกัน เก็บข้อมูลช่วงมีนาคม 2568 ถึงกุมภาพันธ์ 2569 และรายงานไม่ได้แยกตัวเลขของไทยออกมา

ในภาพรวมทั่วโลก รายงานเดียวกันพบว่า breach ที่เริ่มจากการใช้บัญชีที่ถูกต้องในทางมิชอบ มีค่าเสียหายเฉลี่ย 5.07 ล้านดอลลาร์สหรัฐ ผู้โจมตีกลุ่มนี้ไม่ได้พังประตูเข้ามา เขาใช้กุญแจที่องค์กรออกให้เอง ทั้งบัญชีพนักงาน บัญชีบริการ และบัญชีของผู้รับจ้าง

เมื่อเข้ามาได้แล้ว โมเดลเดิมปล่อยให้เดินต่อได้ไกล

Zero Trust เปลี่ยนคำถาม จาก "อยู่ข้างในไหม" เป็น "คำขอนี้ควรผ่านไหม"

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

ในทางปฏิบัติ ทุกคำขอเข้าถึงระบบต้องผ่านจุดตัดสินใจที่ถามว่า ใครเป็นคนขอ อุปกรณ์ที่ใช้อยู่ในสภาพที่ยอมรับได้หรือไม่ และสิทธิ์ที่ขอเกินกว่างานนั้นต้องใช้หรือไม่ NIST เรียกส่วนที่ตัดสินว่า policy decision point และส่วนที่บังคับใช้ผลว่า policy enforcement point สิทธิ์ที่ได้ใช้ได้เป็นราย session และการผ่านการตรวจของระบบหนึ่ง ไม่ได้ทำให้เข้าระบบอื่นได้โดยอัตโนมัติ

สิ่งที่ผู้บริหารควรเห็นคือ Zero Trust ไม่ได้มีหน้าที่ทำให้บัญชีถูกขโมยยากขึ้นอย่างเดียว มันจำกัดว่าบัญชีที่ถูกขโมยไปแล้วจะทำความเสียหายได้แค่ไหน เราเคยเขียนถึงหลักเดียวกันนี้ในกรณีที่แคบกว่า คือการเตรียมระบบก่อนให้ AI Agent เข้าถึงระบบจริง บทความนี้ขยายหลักเดียวกันไปทั้งองค์กร

ข้อสำคัญสำหรับการตั้งงบคือ Zero Trust เป็นวิธีออกแบบ ไม่ใช่ผลิตภัณฑ์ ไม่มีสินค้าตัวไหนที่ซื้อแล้วองค์กรกลายเป็น Zero Trust ทันที เครื่องมือที่ vendor เสนอช่วยได้ในบางส่วน แต่ลำดับการลงทุนต้องมาจากแผนที่ความเสี่ยงขององค์กรเอง

ใช้ 5 pillar ของ CISA เป็นภาษากลางในการวางแผน

กรอบที่เราใช้วางแผนคือ Zero Trust Maturity Model เวอร์ชัน 2.0 ของ CISA หน่วยงานความมั่นคงไซเบอร์ของสหรัฐฯ เผยแพร่เมื่อเมษายน 2566 โมเดลนี้แบ่งงานเป็น 5 pillar คือ Identity, Devices, Networks, Applications and Workloads และ Data และมีความสามารถที่ต้องทำข้ามทุก pillar อีก 3 เรื่อง คือ Visibility and Analytics, Automation and Orchestration และ Governance

แต่ละ pillar มีระดับความพร้อม 4 ขั้น คือ Traditional, Initial, Advanced และ Optimal โครงสร้างนี้เปลี่ยนคำถามว่า "เราทำ Zero Trust แล้วหรือยัง" ซึ่งไม่มีใครตอบได้ ให้เป็นคำถามว่า "แต่ละ pillar อยู่ขั้นไหน และปีนี้จะขยับไปขั้นไหน" ซึ่งตอบได้และตรวจได้

โมเดลนี้เขียนขึ้นสำหรับหน่วยงานรัฐบาลกลางสหรัฐฯ ที่ต้องทำตามเป้าหมายของคำสั่ง OMB M-22-09 ภายในสิ้นปีงบประมาณ 2024 ของสหรัฐฯ ซึ่งผ่านไปแล้ว องค์กรไทยไม่ได้อยู่ใต้คำสั่งนั้น แต่โครงสร้าง pillar และขั้นความพร้อมใช้เป็นภาษากลางระหว่างทีมเทคนิคกับบอร์ดได้ดี

ลำดับการลงทุนที่เราแนะนำ

CISA ไม่ได้กำหนดว่าต้องเริ่มจาก pillar ไหน ลำดับด้านล่างเป็นความเห็นของเรา โดยใช้เกณฑ์เดียว คือเริ่มจากจุดที่บัญชีที่ถูกขโมยจะทำความเสียหายได้มากที่สุด

ขั้นแรก Identity ทำให้บัญชีทุกประเภทมีเจ้าของที่ระบุตำแหน่งได้ ทั้งบัญชีพนักงาน บัญชีผู้ดูแลระบบ บัญชีบริการ และบัญชีของผู้รับจ้าง บัญชีที่มีสิทธิ์สูงต้องใช้ MFA แบบที่ทนต่อ phishing และบัญชีของคนนอกต้องมีวันหมดอายุตามสัญญา ขั้นนี้มักใช้งบเครื่องมือน้อย แต่ใช้เวลาของคนมาก เพราะต้องไล่หาเจ้าของบัญชีที่ไม่มีใครจำได้ว่าเปิดไว้ทำไม

บัญชีที่มักหลุดจากแผนคือบัญชีที่ไม่ใช่คน เช่น บัญชีบริการที่ระบบใช้เรียกกันเอง API key ที่ฝังอยู่ในสคริปต์ และบัญชีของเครื่องมืออัตโนมัติ บัญชีกลุ่มนี้ไม่เคยลาออก จึงไม่เคยถูกปิดตามรอบของฝ่ายบุคคล ถ้าองค์กรเริ่มใช้ AI Agent จำนวนบัญชีกลุ่มนี้จะโตเร็วขึ้นอีก ทุกบัญชีต้องมีเจ้าของที่เป็นคน และมีรอบทบทวนเหมือนบัญชีพนักงาน

ขั้นที่สอง Applications and Workloads และ Data ที่สำคัญที่สุด เลือกระบบจำนวนไม่มากที่ถ้าข้อมูลรั่วหรือถูกแก้ องค์กรจะเสียหายหนักที่สุด แล้วให้การเข้าถึงระบบเหล่านี้ผ่านจุดตรวจสิทธิ์ต่อคำขอก่อนระบบอื่น การเลือกให้แคบทำให้เห็นผลได้ภายในปีงบประมาณแรก

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

ขั้นที่สี่ Networks แบ่ง segment เพื่อให้ระบบที่ถูกเจาะไม่พาไปถึงระบบอื่นได้ง่าย หลายองค์กรอยากเริ่มจากขั้นนี้เพราะทีมคุ้นกับงาน network แต่ถ้า identity ยังไม่เรียบร้อย segment ที่แบ่งไว้ก็ถูกข้ามได้ด้วยบัญชีที่มีสิทธิ์กว้าง

ส่วน Visibility and Analytics ต้องเริ่มตั้งแต่ขั้นแรก ไม่ใช่รอทำตอนท้าย log การเข้าถึงคือหลักฐานที่บอกได้ว่าการควบคุมแต่ละขั้นทำงานจริง

ระบบเก่าที่รองรับ SSO หรือ MFA ไม่ได้ มักติดอยู่ที่ขั้นที่สอง ถ้าองค์กรกำลังชั่งว่าจะปรับหรือเปลี่ยนระบบเหล่านั้น ควรนับข้อจำกัดนี้เข้าไปในการตัดสินใจระหว่าง rewrite กับ refactorด้วย

รายงานบอร์ดด้วยขั้นความพร้อม ไม่ใช่รายการเครื่องมือ

รายงานความคืบหน้าที่พบบ่อยคือรายการเครื่องมือที่ซื้อแล้วและสัดส่วนการติดตั้ง รายงานแบบนี้บอกว่าใช้งบไปเท่าไร แต่ไม่บอกว่าความเสี่ยงลดลงหรือยัง

รูปแบบที่เราแนะนำคือตารางหนึ่งหน้า แถวละหนึ่ง pillar มีสี่คอลัมน์ คือขั้นปัจจุบันตามนิยามของ CISA ขั้นเป้าหมายของปีนี้ ตัวชี้วัดที่พิสูจน์ว่าขยับขั้นแล้ว และตำแหน่งที่เป็นเจ้าของ pillar นั้น

ตัวชี้วัดควรนับได้จากระบบจริง เช่น สัดส่วนบัญชีสิทธิ์สูงที่ใช้ MFA แบบทนต่อ phishing จำนวนบัญชีบริการที่ไม่มีเจ้าของ บัญชีผู้รับจ้างที่ยังเปิดอยู่หลังสัญญาจบ และเวลาที่ใช้ถอนสิทธิ์ของพนักงานที่ลาออก

ตัวชี้วัดชุดนี้มีข้อดีอีกข้อ คือตัวเลขรอบแรกมักไม่สวย บอร์ดที่เห็นว่ายังมีบัญชีผู้รับจ้างเปิดค้างหลังสัญญาจบ จะเข้าใจเหตุผลของงบได้เร็วกว่าการอ่านคำอธิบายเรื่องสถาปัตยกรรม

สิ่งที่ Zero Trust ไม่ได้แก้

Zero Trust ไม่ได้ปิดทุกช่อง DBIR 2026 ฉบับเดียวกันพบว่า การเจาะช่องโหว่ของซอฟต์แวร์กลายเป็นช่องทางเข้าอันดับหนึ่ง คิดเป็น 31% ของ breach ที่ระบุช่องทางเข้าได้ ส่วนการใช้ credential ที่ขโมยมา ซึ่งเคยอยู่อันดับหนึ่ง ลดลงเหลือ 13% Verizon ระบุว่าเป็นครั้งแรกในรอบ 19 ปีของรายงานที่ลำดับนี้สลับกัน ถ้าระบบที่เปิดสู่อินเทอร์เน็ตมีช่องโหว่ที่ยังไม่ได้ patch การตรวจตัวตนที่ดีแค่ไหนก็ไม่ได้ปิดจุดนั้น

Zero Trust ช่วยในขั้นถัดไป คือจำกัดว่าเมื่อระบบหนึ่งถูกเจาะแล้ว ผู้โจมตีจะเดินต่อไปถึงระบบอื่นได้แค่ไหน งบ Zero Trust จึงไม่ควรไปแย่งงบของงาน patch และการจัดการช่องโหว่ สองงานนี้ต้องเดินคู่กัน

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

ข้อโต้แย้งที่ได้ยินบ่อย: เรามี firewall และ VPN อยู่แล้ว

ข้อโต้แย้งนี้มีส่วนถูก firewall และ VPN ยังมีหน้าที่ และองค์กรไม่ควรถอดออกเพียงเพราะเริ่มโครงการ Zero Trust ทีมที่ดูแล network ทุกวันรู้ดีที่สุดว่าอุปกรณ์เหล่านี้กันอะไรได้จริง

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

เขียนเงื่อนไขลง TOR ตั้งแต่ระบบใหม่ตัวแรก

ระบบที่จัดหาในปีนี้จะอยู่กับองค์กรอีกหลายปี ถ้าไม่ระบุเงื่อนไขด้าน identity ตั้งแต่ TOR ระบบนั้นจะกลายเป็นงานแก้ในแผน Zero Trust ปีถัดไป

อย่างน้อยควรระบุว่าระบบต้องรองรับ SSO และ MFA ขององค์กร ต้องส่ง log การเข้าถึงออกมาให้องค์กรเก็บเองได้ และบัญชีของผู้พัฒนาต้องเป็นบัญชีที่องค์กรเพิ่มให้และถอนได้เอง หลักเรื่องบัญชีคลาวด์ที่ต้องอยู่ในมือองค์กร เราเขียนไว้แล้วในเงื่อนไข TOR ที่ทำให้ระบบดูแลต่อได้

ขอบเขตของบทความนี้

บทความนี้พูดถึงการวางแผนและสถาปัตยกรรม ไม่ได้ให้คำแนะนำทางกฎหมาย ถ้าองค์กรของคุณเป็นหน่วยงานโครงสร้างพื้นฐานสำคัญทางสารสนเทศ หรืออยู่ใต้หน่วยงานกำกับดูแลเฉพาะอุตสาหกรรม คำถามว่ามีข้อผูกพันด้าน Zero Trust หรือไม่ ควรสอบถาม สกมช. หรือหน่วยงานกำกับดูแลของคุณโดยตรง สกมช. เผยแพร่แนวปฏิบัติการใช้ซีโร่ทรัสต์ (Zero Trust Guidelines) เมื่อต้นเดือนกุมภาพันธ์ 2569 ควรอ่านฉบับจริงประกอบการวางแผน

สรุป

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

หากองค์กรของคุณกำลังวางแผนงานด้านความปลอดภัยของปีหน้า และอยากให้มีคนช่วยไล่ทั้ง 5 pillar กับระบบจริงขององค์กร ดูแนวทางที่เราทำงานกับองค์กรได้ที่หน้า บริการของเราสำหรับองค์กร เรายินดีคุยด้วย ไม่มีกำหนดเวลาบังคับ และไม่ต้องรีบตัดสินใจ

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างร่างขอบเขตงาน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรง ๆ เพราะการเริ่มโครงการผิดจังหวะ มีต้นทุนสูงกว่าการรออีกหนึ่งไตรมาส