วิธีตรวจสอบความถูกต้องของนโยบาย microsegmentation ก่อนบังคับใช้

Microsegmentation นิยามได้ง่าย แต่ลงมือทำจริงยาก บนกระดาษ เป้าหมายดูตรงไปตรงมา:

• จำกัดการเข้าถึงไว้เฉพาะเท่าที่จำเป็น
• ตัดการเคลื่อนไหวในแนวระนาบที่ไม่จำเป็นออก
• บังคับใช้หลัก least privilege กับทุก workload

แต่เมื่อขาด policy hygiene กฎที่มีอยู่จึงอาจไม่สะท้อนสภาพจริง ในทางปฏิบัติ สภาพแวดล้อมส่วนใหญ่มีลักษณะดังนี้:

• ก่อตัวขึ้นจากการเปลี่ยนแปลงทีละเล็กละน้อยตลอดหลายปี
• เต็มไปด้วย dependency ที่ไม่มีการบันทึกไว้
• เป็นโครงข่ายที่เชื่อมโยงกันอย่างเปราะบาง การเปลี่ยนแปลงเพียงจุดเดียวอาจกระทบธุรกิจทั้งองค์กร

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

ปัญหาหลัก: บังคับใช้โดยไม่ตรวจสอบความถูกต้อง

ความพยายามทำ segmentation ส่วนใหญ่ดำเนินตามรูปแบบนี้: 1. กำหนดเจตนาของการทำ segmentation 2. แปลงเจตนาให้เป็นกฎ 3. นำไปบังคับใช้ 4. แก้ปัญหาที่เกิดขึ้นตามมา ปัญหาอยู่ที่ขั้นตอนที่ 4 เมื่อบังคับใช้ segmentation โดยไม่ตรวจสอบความถูกต้องก่อน:

• ทราฟฟิกที่ถูกต้องตามกฎถูกบล็อก
• dependency ที่ซ่อนอยู่ปรากฏขึ้น
• ทีมงานต้องย้อนการเปลี่ยนแปลงกลับภายใต้แรงกดดัน

ผลลัพธ์คาดเดาได้ นั่นคือ segmentation กลายเป็นเพียงทฤษฎี ไม่ใช่สิ่งที่ใช้งานได้จริง

“การตรวจสอบความถูกต้อง” หมายถึงอะไรกันแน่

การตรวจสอบความถูกต้องไม่ใช่การทบทวนกฎ แต่คือการตอบคำถามนี้: หากบังคับใช้นโยบาย segmentation นี้ ทราฟฟิกใดจะยังทำงานได้ และทราฟฟิกใดจะหยุดทำงาน การจะตอบคำถามนี้ได้ ท่านต้องจำลองสิ่งต่อไปนี้:

• เส้นทางการเข้าถึงจริง
• ปฏิสัมพันธ์ของกฎข้ามอุปกรณ์ต่าง ๆ
• dependency ระหว่างระบบ

ขั้นตอนที่ 1: สร้างโมเดลของการเข้าถึงในปัจจุบัน

ก่อนกำหนด segmentation ท่านต้องเข้าใจว่าปัจจุบันระบบอนุญาตอะไรไว้บ้างจริง ๆ ซึ่งต้องทำมากกว่าการทบทวนคอนฟิก ท่านต้องมีโมเดลที่สร้างขึ้นจาก:

• กฎ firewall จากทุกผู้ผลิต
• โทโพโลยีเครือข่ายและเส้นทางการ routing
• object group และการแมป address
• พฤติกรรมทราฟฟิกเท่าที่มีข้อมูล

ผลลัพธ์

ชุดของเส้นทางการเข้าถึงที่มีผลจริง: App_Server → DB_Server (1433) App_Server → Logging_Service (514) App_Server → Backup_System (445) สิ่งนี้คือ baseline ของท่าน

ขั้นตอนที่ 2: ระบุการเข้าถึงที่เปิดกว้างเกินจำเป็น

สภาพแวดล้อมแบบ brownfield ส่วนใหญ่มักมี:

• กฎ “allow any” ที่เปิดกว้าง
• ข้อยกเว้นชั่วคราวที่กลายเป็นถาวร
• object group ที่ซ้อนทับกัน
• เส้นทางการเข้าถึงที่ซ้ำซ้อน

การทำ segmentation เริ่มต้นด้วยการระบุว่า: มีการเข้าถึงใดบ้างที่ไม่ควรมีอยู่

ตัวอย่าง

App_Server → DB_Server (1433) ← จำเป็น App_Server → Backup_System (445) ← ไม่จำเป็น App_Server → Reporting_DB (1433) ← ไม่ได้ตั้งใจเปิดไว้ สิ่งนี้คือเป้าหมายในการลดการเข้าถึงของท่าน

ขั้นตอนที่ 3: กำหนดเจตนาของการทำ segmentation

นโยบาย segmentation ควรกำหนดในรูปแบบของ:

• flow ที่อนุญาตอย่างชัดแจ้ง
• แนวทาง deny-by-default
• ข้อจำกัดเฉพาะของแต่ละสภาพแวดล้อม

ตัวอย่างเจตนา

อนุญาต: App_Server → DB_Server (1433) ปฏิเสธ: App_Server → ระบบภายในอื่น ๆ ทั้งหมด นี่คือสถานะที่ท่านต้องการ

ขั้นตอนที่ 4: แปลงเจตนาเป็นการเปลี่ยนแปลงนโยบาย

เจตนาต้องถูกแปลงเป็น:

• กฎ firewall
• การอัปเดต security group
• นโยบายของแพลตฟอร์ม microsegmentation

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

ขั้นที่ 5: จำลองนโยบาย segmentation

นำกฎ segmentation ที่เสนอไว้ไปใช้กับโมเดลของสภาพแวดล้อมโดยยังไม่บังคับใช้จริง การจำลองนี้จะ:

• คำนวณเส้นทางการเข้าถึงทั้งหมดใหม่
• ใช้ลำดับและลำดับความสำคัญของกฎ
• ประเมินการทำงานร่วมกันระหว่างอุปกรณ์และเลเยอร์ต่าง ๆ

ระบบจะตอบคำถามว่า หากบังคับใช้ segmentation นี้ จะยังเหลือการเชื่อมต่อใดอยู่บ้าง

ขั้นที่ 6: ระบุจุดที่เสียหายและช่องว่าง

การตรวจสอบความถูกต้องจะเผยให้เห็นสองประเด็นสำคัญ:

1. ทราฟฟิกที่ถูกต้องแต่ถูกตัดขาด

คือการเชื่อมต่อที่จำเป็นแต่จะถูกบล็อก ตัวอย่าง App_Server → Logging_Service (514) ← จำเป็นแต่ไม่ได้รวมไว้ กรณีเหล่านี้สะท้อนถึง:

• การกำหนดนโยบายที่ขาดหายไป
• การพึ่งพาที่ซ่อนอยู่

2. การเข้าถึงที่ไม่ได้ตั้งใจซึ่งยังหลงเหลืออยู่

คือทราฟฟิกที่ยังเปิดอยู่แม้จะมีเจตนา segmentation แล้ว ตัวอย่าง App_Server → Backup_System (445) ← ยังอนุญาตอยู่ผ่านเส้นทางอื่น กรณีเหล่านี้สะท้อนถึง:

• การบังคับใช้ที่ไม่สมบูรณ์
• ความเสี่ยงจากเส้นทางหลายทางข้ามอุปกรณ์

ขั้นที่ 7: ปรับนโยบายก่อนบังคับใช้

จากผลการจำลอง:

• เพิ่มกฎอนุญาตที่จำเป็น
• ตัดเส้นทางการเข้าถึงที่ไม่ได้ตั้งใจออก
• ปรับขอบเขตและลำดับของกฎ

ทำซ้ำกระบวนการนี้จนกว่า การเข้าถึงจริงจะตรงกับการเข้าถึงที่ต้องการ

ขั้นที่ 8: ตรวจสอบความถูกต้องในทุกเลเยอร์ของการบังคับใช้

ในสภาพแวดล้อมแบบไฮบริด segmentation ครอบคลุม:

• Network firewall
• Cloud security group
• Microsegmentation ระดับโฮสต์

การตรวจสอบความถูกต้องต้องยืนยันว่า:

• นโยบายสอดคล้องกันในทุกเลเยอร์
• ไม่มีช่องว่างระหว่างจุดบังคับใช้
• ไม่มีกฎที่ขัดแย้งกันระหว่างระบบ

ขั้นที่ 9: บังคับใช้อย่างมั่นใจ

ควรบังคับใช้นโยบายหลังผ่านการตรวจสอบความถูกต้องแล้วเท่านั้น เมื่อถึงขั้นนี้:

• ทราบการเข้าถึงที่คาดหวังไว้แล้ว
• แก้ไขจุดที่จะเสียหายเรียบร้อยแล้ว
• ความเสี่ยงอยู่ในระดับต่ำที่สุด

การ deploy จึงเป็นการดำเนินการตามแผน ไม่ใช่การลองผิดลองถูก

ภาพในทางปฏิบัติเป็นอย่างไร

หากไม่มีการตรวจสอบความถูกต้อง:

• บังคับใช้ segmentation
• แอปพลิเคชันล่ม
• ทีมงานต้องเร่งหากฎที่ขาดหายไป

หากมีการตรวจสอบความถูกต้อง:

• จำลอง segmentation ไว้ล่วงหน้า
• พบช่องว่างตั้งแต่ต้น
• บังคับใช้ได้โดยไม่กระทบการให้บริการ

เหตุใดเรื่องนี้จึงสำคัญต่อ Zero Trust

Zero Trust ขึ้นอยู่กับ:

• Segmentation ที่แม่นยำ
• การบังคับใช้อย่างต่อเนื่อง
• การให้สิทธิ์เข้าถึงน้อยที่สุดตั้งแต่การออกแบบ

แต่ Zero Trust จะล้มเหลวเมื่อ:

• เจตนาของนโยบายไม่สอดคล้องกับการบังคับใช้จริง
• ไม่เข้าใจการพึ่งพาทั้งหมดอย่างครบถ้วน
• การเปลี่ยนแปลงเปิดช่องการเข้าถึงที่ไม่ได้ตั้งใจ

การตรวจสอบความถูกต้องทำให้มั่นใจได้ว่าสิ่งที่ท่านออกแบบไว้คือสิ่งที่ถูกบังคับใช้จริง

บทบาทของ FireMon

FireMon ช่วยให้การตรวจสอบความถูกต้องนี้เกิดขึ้นได้ด้วยการ:

• สร้างแบบจำลองนโยบายครอบคลุมทุก firewall และทุกสภาพแวดล้อม
• จำลองการเปลี่ยนแปลง segmentation ก่อนบังคับใช้จริง
• ระบุการเข้าถึงที่ไม่ได้ตั้งใจและ dependency ที่ขาดหายไป
• ตรวจสอบความสอดคล้องกันในทุกชั้นของการบังคับใช้นโยบาย

FireMon ทำหน้าที่เป็นชั้นการกำกับดูแลระหว่างเจตนาของ segmentation กับระบบที่บังคับใช้นโยบายจริง

บทสรุป

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