Segmentation และ Micro-segmentation: เริ่มโดยไม่ทำระบบล่ม

Network segmentation (การแบ่งส่วนเครือข่าย) คือการแบ่งเครือข่ายออกเป็นโซนแยกกัน แล้วควบคุมว่าข้อมูลอะไรผ่านระหว่างโซนได้บ้าง เมื่อจุดใดจุดหนึ่งถูกบุกรุก การโจมตีจะได้ไม่ลามไปทั่วเครือข่าย Micro-segmentation (การแบ่งส่วนระดับย่อย) ใช้แนวคิดเดียวกัน แต่แบ่งละเอียดลงไปถึงระดับ workload (ระบบหรือโปรแกรมแต่ละตัวที่รันอยู่) หรือแอปพลิเคชันแต่ละตัว ส่วนที่ยากมักไม่ใช่เทคโนโลยี แต่เป็นการจำกัดทราฟฟิกโดยไม่ตัดขาดระบบที่มีคนใช้งานอยู่ บทความนี้อธิบายวิธีเริ่มแบ่งส่วนเครือข่ายทีละขั้น โดยระวังความเสี่ยงข้อนี้ อ้างอิงแนวทางของ CISA และ NIST

การแบ่งส่วนเครือข่ายช่วยอะไร

CISA อธิบายว่า segmentation คือแนวทางด้านสถาปัตยกรรมที่แบ่งเครือข่ายเป็นหลาย segment ด้วยวิธีทางกายภาพหรือแบบเสมือน (virtual) แต่ละ segment ทำหน้าที่เป็นเครือข่ายย่อยของตัวเอง และมีมาตรการความปลอดภัยและการควบคุมเพิ่มเข้าไป วิธีนี้จำกัดการเข้าถึงอุปกรณ์ ข้อมูล และแอปพลิเคชัน รวมถึงจำกัดการสื่อสารระหว่างเครือข่าย อินโฟกราฟิก Layering Network Security Through Segmentation ของ CISA (มกราคม 2022) ระบุผลเมื่อเครือข่าย IT และ OT (ระบบควบคุมเครื่องจักรหรืออุปกรณ์ในโรงงาน) ไม่ได้แบ่งส่วนไว้ดังนี้ OT จะได้รับผลจากช่องโหว่ของเครือข่าย IT ที่เชื่อมอยู่ ผู้โจมตีเคลื่อนที่ต่อภายในเครือข่าย (lateral movement) ได้ง่ายขึ้น และตรวจจับได้ยากขึ้นเพราะมีทราฟฟิกปริมาณมาก

Macro-segmentation กับ micro-segmentation

• Macro-segmentation: แนวทางดั้งเดิมที่แบ่งเป็นโซนใหญ่ไม่กี่โซน เช่น ผู้ใช้ เซิร์ฟเวอร์ DMZ (โซนกลางที่คั่นระหว่างอินเทอร์เน็ตกับเครือข่ายภายใน) พัฒนา และ production CISA ระบุว่าวิธีนี้คุมทราฟฟิกระหว่างส่วนต่าง ๆ ของเครือข่ายได้ในระดับภาพรวม และจัดการง่ายกว่า
• Micro-segmentation: แบ่งขอบเขตเหล่านั้นให้เล็กลงอีก เช่น ให้เซิร์ฟเวอร์สื่อสารเฉพาะกับเซิร์ฟเวอร์ที่งานของตนต้องใช้ CISA ระบุว่า microsegment กำหนดได้ทั้งแบบไดนามิก (ปรับตามสถานการณ์) และแบบคงที่ อาจแบ่งย่อยโซนความน่าเชื่อถือเดิม หรือคร่อมหลายโซนก็ได้
• แบบอิงตัวตนหรือ workload: NIST SP 800-215 อธิบายนโยบายที่อิงตัวตนของบริการหรือแอปพลิเคชัน แทนการอิงที่อยู่ IP ทำให้นโยบายไม่ขึ้นกับว่า workload รันอยู่ที่ใด วิธีนี้ต้องให้ทุกแอปหรือบริการมีตัวตนเฉพาะของตัวเองที่ตรวจสอบได้

ทั้งสองแบบไม่ได้ใช้แทนกัน CISA ระบุว่า microsegmentation ไม่ได้มาแทน defense-in-depth (การป้องกันหลายชั้น) และไม่ได้มาแทนการจัดการข้อมูล สินทรัพย์ การตั้งค่า และช่องโหว่ แต่เป็นส่วนเสริมของสิ่งเหล่านั้น เส้นทางที่พบบ่อยคือทำ macro-segmentation ให้เรียบร้อยก่อน แล้วค่อยเพิ่ม microsegment รอบระบบที่มีมูลค่าสูง ซึ่งเป็นเส้นทางเดียวกับสถานการณ์ตัวอย่างแรกของ CISA NIST SP 800-215 ชี้ว่าแนวทางดั้งเดิมมีความยากสองข้อ ข้อแรกคือการจับคู่ความต้องการด้านความปลอดภัยของแอปเข้ากับ segment ของเครือข่าย ข้อที่สองคือการรักษาการจับคู่นั้นให้ตรงกันเมื่อ workload ย้ายที่

ทำไมการแบ่งส่วนเครือข่ายจึงทำให้ระบบล่ม

โครงการแบ่งส่วนเครือข่ายมักทำให้ระบบหยุดทำงานด้วยสาเหตุที่คาดเดาได้ NIST SP 800-207 ระบุว่าชุดนโยบายขององค์กรแทบไม่เคยครบถ้วนตั้งแต่รอบแรก บัญชีสำคัญ เช่นบัญชีผู้ดูแลระบบ จึงอาจถูกปฏิเสธการเข้าถึงทรัพยากรที่ต้องใช้ CISA แนะนำให้เตรียมช่องทางย้อนนโยบายที่เพิ่งอัปเดตกลับได้ สาเหตุที่พบบ่อยมีดังนี้

• การพึ่งพาที่ซ่อนอยู่: ระบบอาจต้องพึ่งงานที่ไม่มีใครนึกถึง เช่น งานสำรองข้อมูล probe (ตัวตรวจสอบ) ของระบบเฝ้าระวัง การค้นหา DNS หรือ NTP (บริการแปลงชื่อและบริการตั้งเวลา) หรืองาน batch (งานประมวลผลตามรอบเวลา) ที่ไม่มีใครจำได้
• บังคับใช้เร็วเกินไป: เขียนกฎจากแผนผังเครือข่าย แทนที่จะเขียนจากทราฟฟิกที่สังเกตได้จริง
• ไม่สื่อสารกับผู้เกี่ยวข้อง: เจ้าของระบบและผู้ใช้มารู้เรื่องนี้ตอนที่ระบบมีปัญหาไปแล้ว
• ไม่มีทางย้อนกลับ: ไม่มีแผน rollback (การย้อนกฎกลับ) ที่ทดสอบแล้ว หรือไม่มีช่องทางอนุมัติข้อยกเว้นฉุกเฉิน

แนวทางแบบเป็นระยะที่ช่วยไม่ให้ระบบล่ม

เอกสาร Microsegmentation in Zero Trust Part One ของ CISA (กรกฎาคม 2025) แนะนำให้ทำเป็นระยะ ทีละแอปพลิเคชัน ทีละกระบวนการทำงาน (workflow) ทีละสินทรัพย์ หรือทีละสภาพแวดล้อม โดยแบ่งเป็น 4 เฟส ซึ่งต้องทำซ้ำเป็นรอบ ไม่ใช่ทำครั้งเดียวแล้วจบ

• 1. ระบุทรัพยากรที่จะทำก่อน: ทำรายการแอปพลิเคชัน workflow ข้อมูล และสภาพแวดล้อม แล้วจัดลำดับตามความสำคัญและความง่ายในการทำ CISA เสนอว่ารอบแรกอาจเลือกสิ่งที่เปลี่ยนผ่านง่าย ส่วนรอบหลังจึงเลือกสินทรัพย์มูลค่าสูง
• 2. ระบุ dependency (สิ่งที่ต้องพึ่งพากัน): สำหรับแต่ละตัวเลือก ให้หาทุกอย่างที่ตัวเลือกนั้นต้องใช้ และทุกอย่างที่ต้องใช้ตัวเลือกนั้น เริ่มจากการสื่อสารที่สังเกตได้จริง แล้วให้ผู้เกี่ยวข้องช่วยตรวจว่ารายการครบ
• 3. กำหนดนโยบาย: เลือกวิธีแบ่งส่วนและกฎที่ทำให้ธุรกิจยังทำงานได้ โดยให้ผู้ใช้มีส่วนร่วม
• 4. ทดสอบและนำไปใช้: รันนโยบายใน permissive mode (โหมดที่แจ้งเตือนเมื่อมีการฝ่าฝืนกฎ แต่ยังไม่บล็อก) เพื่อให้เห็น dependency ที่ตกหล่น จากนั้นจึงบังคับใช้จริง โดยมีการเฝ้าระวัง บันทึกการเปลี่ยนแปลงเป็นเอกสาร และมีช่องทางรับ feedback

NIST SP 800-207 ให้คำแนะนำเดียวกันสำหรับ zero trust (แนวคิดที่ไม่เชื่อใจใครโดยอัตโนมัติ ต้องตรวจสอบทุกครั้ง) คือให้เริ่มด้วยโหมดสังเกตและเฝ้าดู เพราะชุดนโยบายแทบไม่เคยครบตั้งแต่ต้น โหมดรายงานอย่างเดียว (reporting-only) ช่วยให้เทียบ log การเชื่อมต่อจริงกับนโยบายที่ร่างไว้ได้ และช่วยให้เรียนรู้รูปแบบการสื่อสารปกติ สถานการณ์ตัวอย่างแรกของ CISA ทำแบบนี้ คือรันนโยบายใหม่ใน permissive mode ที่แจ้งเตือนเมื่อมีการฝ่าฝืน ปรับแต่งไปเรื่อย ๆ แล้วจึงย้ายสู่ production โดยมีกลุ่มผู้ใช้นำร่องทดสอบทรัพยากรแต่ละตัว

เลือกจุดที่จะบังคับใช้นโยบาย

ตารางประเภทการแบ่งส่วนของ CISA จัดวิธีบังคับใช้นโยบายเป็นกลุ่มต่าง ๆ ดังนี้ แต่ละกลุ่มมีข้อดีข้อเสียต่างกัน

• แบบเครือข่าย (ไฟร์วอลล์ เราเตอร์ สวิตช์): ใช้โครงสร้างพื้นฐานเดิมได้ และใช้ได้ในที่ที่ติดตั้ง agent (ซอฟต์แวร์ที่ลงบนเครื่อง) ไม่ได้ แต่มองเห็น endpoint (เครื่องของผู้ใช้) ตัวตนผู้ใช้ และแอปพลิเคชันได้จำกัดกว่า และการเปลี่ยนผ่านทั้งระบบอาจดูแลรักษายาก
• แบบ endpoint หรือ host-based (agent บนเครื่อง และไฟร์วอลล์ในตัวเครื่อง): เชื่อมกับตัวตนและแอปพลิเคชันได้ดีกว่า และตามอุปกรณ์ที่เคลื่อนย้ายไปด้วยได้ แต่ต้องติดตั้ง agent บนทุกเครื่อง และอาจใช้กับ OT, IoT หรืออุปกรณ์รุ่นเก่าไม่ได้
• แบบ hypervisor, container และ cloud-native: เหมาะกับสภาพแวดล้อมที่ใช้ hypervisor (ซอฟต์แวร์ที่รันเครื่องเสมือน) container (แพ็กเกจแอปแบบเบา) และคลาวด์ แต่มักใช้ได้เฉพาะแพลตฟอร์มนั้น จึงย้ายข้ามแพลตฟอร์มได้จำกัด

CISA คาดว่าองค์กรส่วนใหญ่ต้องผสมหลายแบบเข้าด้วยกัน ไม่ใช่ใช้แบบเดียวทั้งองค์กร NIST SP 800-207 ระบุเพิ่มว่าไฟร์วอลล์แบบ stateless (ตรวจแพ็กเก็ตทีละตัว ไม่จำสถานะการเชื่อมต่อ) ทำ micro-segmentation ได้บางส่วน แต่ต้นทุนการดูแลสูงและปรับตามการเปลี่ยนแปลงได้ยาก จึงเป็นทางเลือกที่แย่มาก

กรณีพิเศษ: OT ระบบเก่า และอุปกรณ์ผู้ใช้

• OT, IoT และระบบรุ่นเก่า: CISA ระบุว่าเครื่องมือแบบ agent อาจใช้ไม่ได้ จึงต้องใช้การแบ่งส่วนแบบเครือข่าย ระบบเหล่านี้มักมีการป้องกันในตัวจำกัด จึงยิ่งต้องแบ่งส่วน (IoT คืออุปกรณ์ที่เชื่อมต่อเครือข่าย เช่น กล้องและเซนเซอร์) ขั้นแรกที่พบบ่อยคือแยก OT ออกจาก IT และอนุญาตเฉพาะทราฟฟิกที่งานธุรกิจต้องใช้ ดู Zero Trust สำหรับ OT: ปรับใช้โดยไม่รบกวนโรงงาน
• อุปกรณ์ผู้ใช้ที่เคลื่อนย้ายได้: การแบ่งส่วนแบบเครือข่ายใช้ได้เมื่ออุปกรณ์อยู่ในองค์กร แต่อุปกรณ์ที่อยู่ภายนอกอาจต้องใช้วิธีแบบ agent หรือแบบอิงแอปพลิเคชัน
• การเข้าถึงระยะไกล: อินโฟกราฟิกของ CISA แนะนำให้อนุญาตเฉพาะผู้ใช้และอุปกรณ์ที่กำหนดไว้ ให้เชื่อมต่อจากระยะไกลเข้ามาที่ DMZ เพื่อเข้าถึงเซิร์ฟเวอร์ที่มีมูลค่าสูง
• การย้ายขึ้นคลาวด์: CISA แนะนำให้ใช้โอกาสนี้ฝังการแบ่งส่วนไว้ตั้งแต่ต้นด้วยแนวทาง cloud-native แทนการ lift and shift (ย้ายระบบเดิมขึ้นคลาวด์โดยไม่ออกแบบใหม่)

ข้อผิดพลาดที่พบบ่อย

• บังคับใช้ก่อนสังเกต: เขียนกฎจากทราฟฟิกที่เห็นจริง และรันใน permissive mode ก่อน
• เริ่มทั้งเครือข่ายพร้อมกัน: ควรทำทีละแอปพลิเคชันหรือทีละสภาพแวดล้อม CISA ระบุว่าเฟสต่าง ๆ ต้องทำซ้ำเป็นรอบ
• ข้ามไปทำ micro-segment ทันที: ควรกำหนดโซนหลักก่อน เช่น ผู้ใช้ เซิร์ฟเวอร์ DMZ เครือข่ายจัดการ และ OT
• segment ที่ไม่มีการเฝ้าระวัง: CISA แนะนำให้ทำความเข้าใจว่าผู้โจมตีอาจข้ามการแบ่งส่วนได้อย่างไร เพื่อให้เฝ้าระวังหรือบล็อกเส้นทางนั้นได้
• ลืมเครือข่ายจัดการและเส้นทางของผู้ดูแลระบบ: CISA ระบุว่าเครือข่ายจัดการ (management network) มักอยู่ในตำแหน่งที่ได้รับความไว้วางใจสูงเป็นพิเศษ จึงควรมีมาตรการควบคุมและการเฝ้าระวังที่เข้มงวด
• มองเป็นโครงการที่จบในครั้งเดียว: CISA ระบุว่าการเปลี่ยนผ่านไม่ได้ทำครั้งเดียวแล้วจบ ต้องตรวจสอบซ้ำเมื่อแอปพลิเคชัน สภาพแวดล้อม หรือภัยคุกคามเปลี่ยนไป
• ไม่มีแผนย้อนกลับ: ก่อนเริ่มบังคับใช้ ต้องรู้ว่าใครย้อนกฎได้ ใช้เวลานานเท่าไร และทำอย่างไร

เริ่มได้วันนี้

• วาดแผนที่ตามความเป็นจริง: ระบุห้าระบบที่ถ้าถูกบุกรุกแล้วจะเสียหายมากที่สุด และดูว่าใครบ้างสื่อสารกับระบบเหล่านั้น
• เปิด flow logging (การบันทึกว่าใครเชื่อมต่อกับใคร) ที่ไฟร์วอลล์หรือเซิร์ฟเวอร์สำคัญ เพื่อดูว่าใครสื่อสารกับใครจริง ๆ ก่อนจะเขียนกฎ deny (กฎบล็อก) แม้แต่ข้อเดียว
• ตรวจโซนที่ควรแยกจากกัน: ได้แก่เครือข่ายผู้เยี่ยมชมหรือ IoT เครือข่ายจัดการ ระบบสำรองข้อมูล เซิร์ฟเวอร์ ผู้ใช้ และ OT ว่าแยกจากกันจริง และมีกฎควบคุมทราฟฟิกระหว่างโซนหรือไม่
• เลือกหนึ่งแอปพลิเคชัน แล้วทำครบสี่เฟสกับแอปนั้น ใน permissive mode โดยมีกลุ่มผู้ใช้นำร่องช่วยทดสอบ
• เขียนแผนย้อนกลับ: ระบุว่าใครย้อนกฎได้ ทำได้เร็วแค่ไหน และทำอย่างไร
• ซ้อมในห้องทดลองก่อน ดู Network & Cyber Security Simulator: ประเภทและการใช้งาน

หากต้องการดูว่าการแบ่งส่วนเครือข่ายอยู่ตรงไหนในแผน zero trust ให้อ่าน Zero Trust Architecture: องค์ประกอบและแผนเริ่มต้น และลองใช้ แบบประเมินตนเอง ส่วนบทบาทของไฟร์วอลล์ในฐานะจุดบังคับใช้นโยบาย ดูได้ที่ NGFW, UTM และ WAF ต่างกันอย่างไร และเลือกอย่างไร

สำหรับระบบ OT การแบ่งโซนและช่องทางสื่อสารมีกรอบอ้างอิงเป็นมาตรฐาน ดู IEC 62443 สำหรับมือใหม่: ความปลอดภัยระบบควบคุมอุตสาหกรรม

ใน Kubernetes การแบ่งส่วนเครือข่ายระดับ Pod ทำด้วย NetworkPolicy ดูขั้นตอนในบทความความปลอดภัยของ container และ Kubernetes

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• CISA: Layering Network Security Through Segmentation: อินโฟกราฟิก มกราคม 2022 เรื่อง IT/OT, DMZ และการจำกัดการเคลื่อนที่ต่อภายในเครือข่าย
• CISA: Microsegmentation in Zero Trust Part One: หน้าเอกสาร กรกฎาคม 2025 อธิบายแนวทาง 4 เฟสและข้อควรพิจารณาในการวางแผน
• CISA: Microsegmentation in Zero Trust Part One (PDF): ตัวเอกสารฉบับเต็ม เวอร์ชัน 1.0
• NIST SP 800-207: Zero Trust Architecture: หัวข้อ 3.1.2 (micro-segmentation) และ 7.3.6 (การติดตั้งเริ่มต้นแบบสังเกตการณ์)
• NIST SP 800-215: Guide to a Secure Enterprise Network Landscape: หัวข้อ 5.1 เรื่อง microsegmentation และแนวทางการติดตั้ง
• CISA Zero Trust Maturity Model: microsegmentation อยู่ในเสาหลักด้านเครือข่าย (network pillar)
• NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy: ประเภทของไฟร์วอลล์และพื้นฐานการเขียนนโยบาย