Zero Trust Architecture คืออะไร: จากปัญหาจริงสู่ทางเลือกที่ทำได้ในทางปฏิบัติ

เวลาพูดถึง Zero Trust Architecture หลายคนจะนึกถึงประโยคสั้น ๆ ว่า “Never trust, always verify” ซึ่งช่วยให้จำง่าย แต่ถ้าเอาไปใช้จริง ประโยคนี้ยังไม่พอ เพราะคำถามที่ยากกว่าคือเราควร verify อะไร, verify เมื่อไร, ใช้ข้อมูลอะไรตัดสินใจ, และต้องทำแค่ไหนถึงจะคุ้มกับภาระดูแลระบบ

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

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

ปัญหาคืออะไร

ปัญหาหลักที่ Zero Trust พยายามแก้คือ security model แบบเดิมที่เชื่อว่า “ข้างในปลอดภัย ข้างนอกอันตราย” หรือที่มักเรียกว่า perimeter-based security

ในอดีตแนวคิดนี้พอเข้าใจได้ เพราะระบบส่วนใหญ่อยู่ใน office, data centre หรือ network ภายในองค์กร ผู้ใช้เชื่อมต่อจากเครื่องที่องค์กรดูแล และการเข้าจากภายนอกมักผ่าน VPN หรือ firewall เป็นหลัก แต่โลกปัจจุบันเปลี่ยนไปมาก ผู้ใช้ทำงานจากบ้าน ใช้ SaaS ใช้ cloud มี contractor เข้ามาช่วยงาน มี API เชื่อมระบบภายนอก และบางองค์กรยังมี BYOD หรืออุปกรณ์ที่ควบคุมได้ไม่เต็มที่

พอเส้นแบ่งระหว่าง “ข้างใน” กับ “ข้างนอก” เริ่มเบลอ การเชื่อว่าใครก็ตามที่เข้ามาใน network ได้แล้วควรเข้าถึงระบบอื่นได้กว้าง ๆ จึงกลายเป็นความเสี่ยงทันที

ตัวอย่างที่เห็นได้บ่อยคือ

1. ผู้ใช้ login VPN ได้แล้วมองเห็นระบบภายในหลายส่วนเกินความจำเป็น
2. service account มีสิทธิ์กว้างมาก เพราะตอนติดตั้งระบบต้องการให้ใช้งานได้เร็ว
3. เครื่องพนักงานติด malware แล้ว attacker ใช้เครื่องนั้นเป็นจุดเริ่มต้นไปยังระบบอื่น
4. ระบบภายในบางตัวไม่มี MFA เพราะคิดว่าอยู่หลัง firewall แล้วปลอดภัยพอ
5. log และ monitoring ไม่พอ ทำให้ไม่รู้ว่า credential ที่หลุดถูกใช้เข้าถึงอะไรบ้าง

พูดแบบตรงไปตรงมา ปัญหาไม่ใช่ว่า firewall หรือ VPN ไม่มีประโยชน์ แต่ปัญหาคือเราเอา network location มาเป็นเหตุผลหลักในการเชื่อใจมากเกินไป

Zero Trust Architecture คืออะไร

NIST SP 800-207 อธิบาย Zero Trust Architecture ว่าเป็นแนวทางออกแบบความปลอดภัยที่ย้ายจุดสนใจจากการป้องกัน perimeter เพียงอย่างเดียว ไปสู่การปกป้อง resource แต่ละตัว โดยตัดสินใจให้สิทธิ์เข้าถึงจากข้อมูลหลายด้าน เช่น identity, device, workload, data, application, policy และพฤติกรรมที่สังเกตได้

ถ้าพูดให้เข้าใจง่ายขึ้น Zero Trust Architecture คือการออกแบบระบบโดยตั้งต้นว่า “การอยู่ใน network เดียวกันไม่ได้แปลว่าเชื่อใจได้” ทุก request ควรถูกประเมินตามบริบทก่อนเข้าถึง resource ที่ต้องการ

Microsoft นิยมสรุป Zero Trust เป็น 3 หลักคิดที่จำง่าย คือ verify explicitly, use least privilege access และ assume breach กรอบนี้มีประโยชน์มากในเชิง mindset แต่ถ้าจะออกแบบ architecture จริง ควรอ่านร่วมกับ NIST และ maturity model ของ CISA เพราะจะเห็นมิติที่กว้างกว่า เช่น identity, devices, networks, applications and workloads, data และ visibility/analytics

สิ่งสำคัญคือ Zero Trust ไม่ใช่สินค้าเดียว ไม่ใช่ toggle ที่เปิดแล้วองค์กรกลายเป็น Zero Trust ทันที และไม่ใช่การเลิกใช้ firewall, VPN หรือ network security ทั้งหมด แต่เป็นการเปลี่ยนวิธีคิดว่า trust ต้องถูกพิสูจน์และจำกัดตามความจำเป็น ไม่ใช่ให้กว้างไว้ก่อนเพราะอยู่ในฝั่งที่เราคุ้นเคย

ทำไมเรื่องนี้ถึงสำคัญ

เรื่องนี้สำคัญเพราะความเสียหายจาก incident ในโลกจริงมักไม่ได้เกิดจากช่องโหว่เดียวแล้วจบ แต่มักเกิดจากการเคลื่อนที่ต่อภายในระบบ หรือ lateral movement หลังจาก attacker ได้ foothold จุดแรกแล้ว

ถ้าบัญชีผู้ใช้หนึ่งหลุด แต่สิทธิ์ของบัญชีนั้นแคบ มี MFA มี device check มี access policy และระบบสำคัญแยกสิทธิ์ไว้ดี ความเสียหายอาจถูกจำกัดอยู่ในวงเล็กกว่าเดิมมาก แต่ถ้าบัญชีเดียวเข้าถึง file share, admin panel, database, dashboard, cloud console หรือระบบภายในอื่นได้กว้าง ความเสียหายจะลามเร็ว

อีกเหตุผลที่สำคัญคือรูปแบบการทำงานสมัยใหม่ไม่ได้อยู่ในอาคารเดียวอีกต่อไป ต่อให้เราลงทุนป้องกัน network ภายในดีมาก แต่ข้อมูลอาจอยู่ใน SaaS, cloud storage, endpoint, mobile device หรือระบบของ partner ดังนั้น security architecture ที่ผูกกับ network ภายในอย่างเดียวจึงไม่พอ

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

ถ้าไม่ทำอะไรจะเกิดผลอย่างไร

ถ้าองค์กรยังใช้ implicit trust แบบเดิมมากเกินไป ผลที่มักเกิดขึ้นไม่ใช่ระบบล่มทันที แต่เป็นการสะสมความเสี่ยงแบบเงียบ ๆ

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

ผลที่สองคือ incident investigation ยากขึ้น เพราะถ้าไม่มีการแยก policy, ไม่มี log ที่ดี และไม่มีการบังคับสิทธิ์แบบละเอียด ทีมจะตอบคำถามพื้นฐานได้ช้า เช่น attacker เข้าจากไหน, ใช้บัญชีอะไร, แตะระบบใดบ้าง, และยังมี access token หรือ session ไหนค้างอยู่หรือไม่

ผลที่สามคือการเติบโตขององค์กรจะทำให้ความเสี่ยงขยายตาม เมื่อเพิ่ม SaaS, cloud, API, contractor หรือ remote work เข้าไปเรื่อย ๆ ถ้าไม่มีแนวคิดเรื่อง identity, least privilege และ monitoring ตั้งแต่ต้น ระบบจะซับซ้อนขึ้นโดยไม่มี control ที่ชัด

ผลสุดท้ายคือทีม security และ IT อาจติดอยู่กับการแก้เฉพาะหน้า เช่น ปิดบัญชีหลังเกิดเหตุ รีเซ็ตรหัสผ่านเป็นรอบ ๆ หรือไล่ตาม firewall rule ที่ไม่มีใครกล้าลบ เพราะไม่รู้ว่าจะกระทบระบบใดบ้าง

มีทางเลือกอะไรบ้าง

Zero Trust Architecture ไม่ได้มีทางเดียว และไม่ควรเริ่มจากการซื้อ platform ใหญ่เสมอไป ทางเลือกที่ practical มักขึ้นกับขนาดองค์กร ระบบเดิม งบประมาณ และทีมที่ต้องดูแล

1. เริ่มจาก identity-first

แนวทางนี้เน้นบัญชีผู้ใช้ สิทธิ์ MFA, SSO, conditional access และ lifecycle ของ account เป็นหลัก เหมาะกับองค์กรที่ใช้ SaaS เยอะและมีปัญหาสิทธิ์กระจัดกระจาย

ข้อดีคือเห็นผลเร็ว ลดความเสี่ยงจาก credential compromise ได้ดี และมักต่อยอดกับระบบเดิมได้ไม่ยาก ข้อจำกัดคือถ้า network, endpoint และ data access ยังเปิดกว้างมาก ผลลัพธ์จะยังไม่ครบ

2. เริ่มจาก ZTNA หรือ access proxy

แนวทางนี้ใช้ Zero Trust Network Access, access proxy หรือ tunnel-based access แทนการเปิดระบบภายในให้เข้าผ่าน VPN แบบกว้าง ๆ เหมาะกับองค์กรที่มี remote access เยอะ หรือมี application ภายในที่ไม่ควรถูกเปิดให้ทุกคนใน VPN เห็น

ข้อดีคือช่วยลดการเปิดพอร์ต ลดการเห็น network กว้างเกินจำเป็น และกำหนด policy ต่อ application ได้ละเอียดขึ้น ข้อจำกัดคือการย้าย application เก่าเข้าระบบแบบนี้อาจต้องปรับ architecture และต้องทดสอบ user experience ให้ดี

3. เริ่มจาก segmentation และ least privilege

แนวทางนี้เน้นแบ่งระบบตามความเสี่ยง เช่น แยก user network, server network, admin network, production, development, IoT และ third-party access แล้วจำกัดเส้นทางการสื่อสารให้เท่าที่จำเป็น

ข้อดีคือช่วยลด lateral movement ได้มากในทางปฏิบัติ ข้อจำกัดคือถ้าทำโดยไม่มี inventory และ dependency map ที่ดี อาจทำให้ระบบใช้งานสะดุด และทีมอาจต้องใช้เวลาปรับ rule หลายรอบ

4. เริ่มจาก data protection และ monitoring

บางองค์กรอาจเริ่มจากข้อมูลสำคัญก่อน เช่น classification, encryption, DLP, access review, backup, log, SIEM หรือ alert ที่เกี่ยวกับการเข้าถึงข้อมูลผิดปกติ

ข้อดีคือผูก security เข้ากับสิ่งที่ธุรกิจแคร์จริง นั่นคือข้อมูลและ continuity ข้อจำกัดคือถ้า identity และ access control ยังหลวม monitoring จะกลายเป็นการเห็นปัญหามากขึ้น แต่ยังหยุดปัญหาได้ไม่ดีพอ

ข้อดีในทางปฏิบัติ

ข้อดีแรกของ Zero Trust คือช่วยลด blast radius ถ้ามี account, endpoint หรือ application ตัวใดตัวหนึ่งมีปัญหา ความเสียหายไม่ควรถูกปล่อยให้ลามไปทั้งระบบง่าย ๆ

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

ข้อดีที่สามคือช่วยให้ remote work และ cloud adoption ปลอดภัยขึ้น เพราะ access ไม่ได้ผูกกับการอยู่ใน office อย่างเดียว แต่ผูกกับ identity และ context ที่ตรวจสอบได้

ข้อดีที่สี่คือช่วยให้ incident response ดีขึ้น ถ้ามี log, policy และ segmentation ที่ชัด ทีมจะสืบสวนและตัดสิทธิ์เฉพาะส่วนได้เร็วกว่าเดิม

ข้อดีสุดท้ายคือช่วยให้ security conversation เป็นรูปธรรมขึ้น ผู้บริหารและทีมเทคนิคสามารถคุยกันจาก resource, risk และ business process แทนการคุยแบบกว้าง ๆ ว่า “ทำ security ให้แน่นขึ้น”

ข้อเสียและข้อควรระวัง

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

ข้อเสียที่สองคือภาระ operational ถ้าทีมไม่มีเวลาทำ inventory, review policy, ดู log และดูแล exception ให้ดี ระบบจะกลายเป็นกฎจำนวนมากที่ไม่มีใครมั่นใจว่าถูกต้องหรือไม่

ข้อเสียที่สามคือค่าใช้จ่าย เครื่องมือบางกลุ่มมีประโยชน์จริง แต่ถ้าซื้อก่อนเข้าใจ architecture อาจได้ platform ที่ดูครบในเอกสาร แต่ใช้งานจริงได้แค่บางส่วน

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

แนวทางเริ่มต้นที่ผมคิดว่าคุ้ม

ถ้าต้องเริ่มแบบ practical ผมจะไม่เริ่มจากคำว่า “เราจะทำ Zero Trust ทั้งองค์กร” เพราะประโยคนี้ใหญ่เกินไปและมักทำให้ scope บาน

ผมจะเริ่มจาก 6 คำถามนี้แทน

1. ข้อมูลหรือระบบใดสำคัญที่สุดถ้าถูกเข้าถึงผิดทาง
2. ใครควรเข้าถึงระบบนั้นได้ และควรเข้าถึงจากอุปกรณ์แบบไหน
3. ตอนนี้มีสิทธิ์ใดที่กว้างเกินจำเป็นหรือให้ค้างไว้นานเกินไป
4. ถ้า credential ของผู้ใช้คนหนึ่งหลุด attacker จะไปต่อได้ไกลแค่ไหน
5. เรามี log พอจะรู้หรือไม่ว่าเกิดอะไรขึ้น
6. control ที่เพิ่มเข้าไปจะทำให้ผู้ใช้ทำงานยากจนเลี่ยงระบบหรือไม่

จากนั้นค่อยเลือก pilot ที่ขนาดพอดี เช่น ระบบ HR, finance, source code, cloud admin, remote access หรือ data storage สำคัญ แล้วทำให้ครบวงจรเล็ก ๆ ก่อน ได้แก่ MFA, SSO หรือ identity policy, least privilege, access review, segmentation เท่าที่จำเป็น, logging และแผน revoke access เมื่อเกิดเหตุ

แนวทางนี้อาจไม่เท่เท่าการประกาศโครงการใหญ่ แต่ในทางปฏิบัติมักรอดกว่า เพราะทีมได้เรียนรู้จากระบบจริง เห็น friction จริง และปรับ policy ก่อนขยายไปส่วนอื่น

สรุป

Zero Trust Architecture มีประโยชน์มากถ้าใช้เป็นแนวทางออกแบบ ไม่ใช่คำโฆษณาหรือรายการซื้อเครื่องมือ

แก่นของมันคือการลด implicit trust และทำให้การเข้าถึง resource สำคัญต้องผ่านการประเมินตามบริบท ไม่ว่าจะเป็น identity, device, application, data, network, policy และพฤติกรรมที่สังเกตได้

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

ทางที่ดีคือเริ่มจากโจทย์จริง เลือก resource สำคัญ ทำ pilot ขนาดเล็ก และยอมรับว่า Zero Trust เป็นการเดินทางระยะยาวที่ต้องบาลานซ์ security, usability, cost และ operations ให้พอดี ไม่ใช่การเปิดสวิตช์ครั้งเดียวแล้วจบ

อ่านต่อที่เกี่ยวข้อง

• ถ้าอยากปูพื้นแนวคิดก่อน อ่าน เปลี่ยนผ่านสู่ยุค Zero Trust: แนวคิดพื้นฐานที่ควรเข้าใจ และตัวอย่างการใช้ในชีวิตจริง
• ถ้าใช้ในบ้านหรือ lab ส่วนตัว อ่าน Zero Trust สำหรับ Homelab: ต้องทำแค่ไหนถึงจะคุ้ม ไม่มากไปไม่น้อยไป
• ถ้ากำลังคิดเรื่อง remote access อ่าน รีวิว NetBird สำหรับสาย Self-Hosted และ Homelab

แหล่งอ้างอิง

• NIST SP 800-207: Zero Trust Architecture
• CISA Zero Trust Maturity Model
• Microsoft Learn: What is Zero Trust?
• NIST Zero Trust Networks programme page