Zero Trust ไม่ใช่การรื้อระบบใหม่ทั้งหมด: แนวทางปฏิบัติจริงสำหรับทีมไอทีในการวางโรดแมป

เกริ่นนำ

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

รายงานจาก Forrester Research ที่เผยแพร่ผ่าน AWS Marketplace ชี้ให้เห็นมุมมองที่ต่างออกไป: องค์กรสามารถทำ Zero Trust แบบเป็นเฟส (phased approach) โดยต่อยอดจากการลงทุนด้านความปลอดภัยที่มีอยู่เดิม ไม่จำเป็นต้องเปลี่ยนทุกอย่างพร้อมกัน สิ่งสำคัญคือการมี "โรดแมป" ที่ชัดเจน ซึ่งอิงจากการประเมินความพร้อม (maturity assessment) ขององค์กรเอง แล้วค่อย ๆ ขยับไปทีละโดเมนตามลำดับความสำคัญ

บทความนี้สรุปแนวคิดหลักและขั้นตอนเชิงเทคนิคจากรายงานดังกล่าว โดยเน้นสิ่งที่ทีมไอทีและวิศวกรความปลอดภัยสามารถนำไปปรับใช้ได้จริง ครอบคลุมตั้งแต่การวางกรอบกลยุทธ์ ไปจนถึงรายละเอียดทางเทคนิคในแต่ละโดเมนของ Zero Trust ทั้ง 5 ด้าน คือ People (ผู้ใช้งาน), Workloads (เวิร์กโหลด), Devices (อุปกรณ์), Networks (เครือข่าย) และ Data (ข้อมูล)

กรอบแนวคิด Zero Trust ของ Forrester

Forrester นิยาม Zero Trust ว่าเป็นการเปลี่ยนจากโมเดลความปลอดภัยแบบยึดขอบเขตเครือข่าย (perimeter-based) ไปสู่โมเดลที่ลดความเชื่อถือโดยปริยาย (implicit trust) ให้เหลือน้อยที่สุด โดยอาศัยหลักการยืนยันตัวตนที่เข้มแข็ง (strong authentication) สิทธิ์การเข้าถึงขั้นต่ำสุด (least privilege) การอนุญาตสิทธิ์แบบต่อเนื่อง (continuous authorization) และการเข้ารหัสข้อมูล กรอบนี้แบ่งออกเป็น 7 องค์ประกอบหลัก (core domains) แต่ในรายงานนี้เน้นอธิบายรายละเอียดใน 5 ด้านหลักที่มักเป็นจุดเริ่มต้นของการวางโรดแมป

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

ขั้นตอนก่อนเริ่มวางโรดแมป

ก่อนลงมือสร้างโรดแมป รายงานแนะนำให้ทำ 3 สิ่งควบคู่กัน:

1. ดึงผู้มีส่วนได้ส่วนเสียเข้ามาร่วมออกแบบ ตั้งแต่ระดับบอร์ดบริหารซึ่งมักเป็นผู้อนุมัติงบประมาณและตัดสินใจสูงสุด ไปจนถึงสถาปนิกระบบองค์กร (enterprise architects) เจ้าของแอปพลิเคชัน และทีม IT operations ที่ต้องดูแลโครงสร้างพื้นฐานหลังการติดตั้งจริง
2. หาจุดเชื่อมโยงกับโปรเจกต์ที่มีอยู่แล้ว เช่น การย้ายระบบขึ้นคลาวด์ หรือโปรเจกต์ธุรกิจอื่น ๆ ที่สามารถใช้เป็นตัวเร่งการทำ Zero Trust ได้ แต่ต้องระวังการ implement ที่รุนแรงเกินไป เช่น การทำ microsegmentation แบบเร่งรัดอาจไปรบกวนการทำงานของระบบเครือข่ายที่มีอยู่และกระทบตารางเวลาของโปรเจกต์ IT operations อื่น
3. ประเมิน maturity ปัจจุบันก่อนเริ่ม โดยใช้เกณฑ์ประเมินแบบ 0-5 ระดับ ครอบคลุมทั้ง 5 โดเมน เพื่อหาจุดเริ่มต้นที่เหมาะสม เช่น หากองค์กรมี IAM capability ที่แข็งแกร่งอยู่แล้ว (มี MFA และ privileged identity management ใช้งานจริง) ก็อาจข้ามไปเริ่มที่โดเมนที่ยังอ่อนกว่า เช่น cloud workload security แทน

Forrester แนะนำกรอบเวลา 2-3 ปีสำหรับการวางแผนโรดแมปแบบละเอียด เพื่อให้ maturity ขยับขึ้นอย่างมีนัยสำคัญโดยไม่คาดหวังความสมบูรณ์แบบในทันที

Zero Trust สำหรับผู้ใช้งาน (People / IAM)

โดเมนนี้มักเป็นจุดเริ่มต้นที่เห็นผลเร็วที่สุด เพราะเทคโนโลยี IAM ค่อนข้างเป็นมาตรฐานและวัดผลได้ชัดเจน ประเด็นทางเทคนิคสำคัญที่ทีมไอทีควรให้น้ำหนัก:

• Least privilege เป็นหัวใจหลัก ต้องมีกระบวนการ attestation ที่รีวิวสิทธิ์การเข้าถึงของผู้ใช้อย่างสม่ำเสมอ ทั้งแบบ manual และ automated ผ่านแพลตฟอร์ม identity governance โดยเฉพาะกลุ่ม privileged users ที่ต้องไม่มีสิทธิ์ admin เกินความจำเป็นของงาน และต้องมีกระบวนการ deprovision สิทธิ์เมื่อผู้ใช้เปลี่ยนบทบาทหรือโปรเจกต์
• ยกเลิกการพึ่งพารหัสผ่าน (password) เนื่องจากรหัสผ่านเป็นช่องโหว่สำคัญที่ถูกขโมย ดักฟัง หรือถูก brute force ได้ง่าย ทีมไอทีควรผลักดัน phishing-resistant MFA เป็นขั้นต่ำสำหรับแอปและข้อมูลสำคัญ และพิจารณาใช้ passwordless authentication เช่น biometrics, security keys, หรือ OAuth-based solutions ซึ่งช่วยลดพื้นผิวการโจมตีแบบ man-in-the-middle ได้อย่างมีนัยสำคัญ
• การผลักดันโปรเจกต์ IAM ให้สำเร็จ มักต้องผูกกับปัญหาทางธุรกิจหรือ audit ที่จับต้องได้ เพื่อให้ได้รับงบประมาณและแรงสนับสนุนจากผู้บริหาร

Zero Trust สำหรับเวิร์กโหลด (Workloads)

เมื่อ IAM เริ่มเข้าที่ โดเมนถัดไปที่หลายองค์กรมักเลือกคือ workload หรือ device security โดยเฉพาะในบริบทของการย้ายระบบขึ้นคลาวด์ที่ทำให้ workload ขยายตัวเร็วมาก ประเด็นเทคนิคที่ต้องวางระบบ:

• Cloud governance ที่เป็นกระบวนการต่อเนื่อง ไม่ใช่การตรวจสอบแบบ checkbox ครั้งเดียว ต้องครอบคลุมทั้ง on-premises, private cloud, และ public cloud รวมถึงการบริหารต้นทุน (cost optimization) และการปฏิบัติตามข้อกำหนด (regulatory compliance)
• Inventory และ monitor การตั้งค่า workload อย่างต่อเนื่อง เพราะ cloud workload สร้างขึ้นได้ง่ายและรวดเร็ว มักขาดการกำกับดูแล เช่น การตั้งค่า S3 bucket แบบ world-writable โดยไม่ตั้งใจ กระบวนการ manual หรือเครื่องมือ infrastructure-as-a-service เพียงอย่างเดียวไม่เพียงพอ จำเป็นต้องมีโซลูชัน cross-cloud workload security โดยเฉพาะ (ตัวอย่างเวนเดอร์ในตลาดที่รายงานกล่าวถึง ได้แก่ Aqua Security, Orca Security, Qualys, Sysdig, Trend Micro และ Wiz)
• การย้ายระบบขึ้นคลาวด์ควรใช้เป็นโอกาสในการ replatform หรือ refactor แอปพลิเคชันให้ใช้บริการ cloud-native อย่าง containerization, cloud-native storage และ logging แทนการ lift-and-shift แบบตรงตัว ซึ่งมักนำไปสู่ data sprawl และการป้องกันข้อมูลที่ไม่เหมาะสม

Zero Trust สำหรับอุปกรณ์ (Devices)

ความท้าทายของโดเมนนี้คือขอบเขตอุปกรณ์ที่กว้างมาก ตั้งแต่ laptop, mobile device ไปจนถึง IoT/OT ซึ่งมักมีช่องโหว่จากโปรโตคอลสื่อสารที่ไม่ปลอดภัย การเข้ารหัสที่อ่อนแอ หรือรหัสผ่าน default ที่ไม่เคยเปลี่ยน แนวทางเชิงเทคนิคที่แนะนำ:

• Network segmentation สำหรับ IoT/OT เพื่อสร้าง zone หรือ microperimeter แยกอุปกรณ์เหล่านี้ออกจากเครือข่าย IT ทั่วไป พร้อมความสามารถในการกักกัน (quarantine) อุปกรณ์ที่สงสัยว่าติดมัลแวร์ ไม่ให้แพร่กระจายต่อ
• การจัดการความเสี่ยงจาก BYOD ด้วยการทำ posture check ก่อนอนุญาตให้อุปกรณ์เชื่อมต่อทรัพยากรองค์กร ผู้ให้บริการ identity อย่าง Microsoft และ Okta หรือแพลตฟอร์ม Zero Trust อย่าง Check Point, Palo Alto Networks และ Zscaler มีความสามารถด้าน posture checking ให้ใช้งาน รวมถึงการใช้ application allow/deny list ผ่าน unified endpoint management เพื่อควบคุมแอปที่รันบนอุปกรณ์ส่วนตัวของพนักงาน

Zero Trust สำหรับเครือข่าย (Networks)

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

• Microsegmentation ที่ยึดทรัพยากรเป็นศูนย์กลาง ไม่ใช่ยึดเครือข่ายแบบเดิม เช่น ในสถาปัตยกรรมแอปแบบ three-tier front-end ควรคุยกับ middleware ได้ แต่ต้องไม่สามารถเข้าถึง database ได้โดยตรง ส่วนแอปแบบ cloud-native ที่ใช้ microservices/containers การสื่อสารระหว่างกันต้องผ่านการอนุญาตแบบ least privilege อย่างชัดเจน แนะนำให้เริ่มด้วยการทำ flow discovery เพื่อสร้าง baseline นโยบาย แล้ว deploy ในโหมด monitor ก่อนค่อยเปลี่ยนเป็น full enforcement การบังคับใช้นโยบายสามารถทำได้ทั้งแบบ host-based agent (พบมากที่สุด) หรือแบบ agentless ผ่าน hypervisor, network hardware หรือ physical appliance
• Content filtering เพื่อป้องกัน north-south traffic ผ่าน cloud security gateway หรือ DNS-based filtering ซึ่งติดตั้งง่ายแม้จะให้การป้องกันแบบหยาบกว่า
• Next-generation firewall ยังมีบทบาทสำคัญ โดยเฉพาะในรูปแบบ virtualized firewall ที่วางไว้หลัง gateway load balancer ในระบบคลาวด์ เพื่อตรวจสอบ traffic ระดับแอปพลิเคชัน

Zero Trust สำหรับข้อมูล (Data)

โดเมนนี้มักซับซ้อนที่สุด เพราะต้องเข้าใจก่อนว่าข้อมูลใดสำคัญและมีค่าต่อองค์กร รายงานแนะนำแนวทาง 3 ขั้น:

1. Define — สร้างความสามารถด้าน data discovery และ classification เพื่อรู้ว่าข้อมูลอยู่ที่ไหนและข้อมูลใดเป็นข้อมูลอ่อนไหว ซึ่งมีทั้งฟีเจอร์ในตัวของแพลตฟอร์มอย่าง Microsoft Purview และโซลูชันเฉพาะทางอย่าง BigID หรือ Varonis
2. Dissect — เข้าใจ data flow, ผู้ใช้งาน, วัตถุประสงค์การเก็บ และผลกระทบหากข้อมูลถูกละเมิด โดยอาศัยข้อมูลจากเครื่องมือ DLP และ XDR ที่มีอยู่แล้ว
3. Defend — ป้องกันด้วย 4 มาตรการหลัก คือ access control, การตรวจสอบรูปแบบการใช้ข้อมูล, การทำลายข้อมูลอย่างปลอดภัย (defensible disposal) และการทำ obfuscation ครอบคลุมทั้งการเข้ารหัสข้อมูลใน 3 สถานะ (at rest, in transit, in use) รวมถึงเทคโนโลยีใหม่อย่าง homomorphic encryption และ quantum-safe encryption

การสื่อสารกับบอร์ดบริหาร

นอกเหนือจากมิติเทคนิค การให้ความสำคัญกับการสื่อสารกลยุทธ์ Zero Trust ให้บอร์ดเข้าใจ โดยเน้นว่าอย่าติดกับดักการถกเถียงเรื่องชื่อเรียก (บางองค์กรเลือกใช้ชื่ออื่นแทน "Zero Trust" เพื่อให้บอร์ดเข้าใจง่ายขึ้น) สิ่งสำคัญกว่าคือการสื่อสารผลกระทบทางธุรกิจ ไม่ใช้ fear-uncertainty-doubt เป็นตัวขับเคลื่อน แต่เน้น impact และ likelihood ของความเสี่ยง พร้อมทั้งแปลงความต้องการด้านเทคโนโลยีให้เป็นผลประโยชน์ทางธุรกิจที่จับต้องได้ เช่น การรองรับ digital transformation หรือ remote workforce

สรุป

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

• ประเมิน maturity ปัจจุบันในทั้ง 5 โดเมน (People, Workloads, Devices, Networks, Data) เพื่อหาจุดที่อ่อนแอที่สุดและมีความเสี่ยงสูงสุด
• เริ่มจากโดเมนที่ให้ผลตอบแทนเร็วและวัดผลได้ชัด เช่น IAM/MFA มักเป็นจุดเริ่มต้นที่คุ้มค่าที่สุด
• ใช้โปรเจกต์ที่มีอยู่แล้ว เช่น การย้ายขึ้นคลาวด์ เป็นตัวเร่งการ implement แทนที่จะแยกเป็นโปรเจกต์ใหม่ทั้งหมด
• วางแผนระยะยาว 2-3 ปี พร้อมทั้งสื่อสารความคืบหน้าและผลลัพธ์เชิงธุรกิจให้ผู้บริหารเห็นอย่างต่อเนื่อง เพื่อรักษาการสนับสนุนด้านงบประมาณและทรัพยากร

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