Firewall Change Management: กระบวนการ 7 ขั้นตอนสำหรับองค์กรขนาดใหญ่

Firewall change management คือกระบวนการร้องขอ ประเมิน อนุมัติ นำไปใช้งาน ตรวจสอบยืนยัน และจัดทำเอกสารสำหรับทุกการเปลี่ยนแปลงของ firewall rule และนโยบายความปลอดภัย หากดำเนินการได้ดี ทีมงานของท่านจะทำงานได้เร็วขึ้นโดยไม่เปิดช่องความเสี่ยงใหม่ และยังได้หลักฐานที่ผู้ตรวจสอบต้องการ

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

ประเด็นสำคัญ

• คืออะไร: กระบวนการ 7 ขั้นตอน (ร้องขอ ตรวจสอบความถูกต้อง ประเมินความเสี่ยง อนุมัติ นำไปใช้งาน ตรวจสอบยืนยัน และจัดทำเอกสาร) ที่ใช้กับทุกการเปลี่ยนแปลง firewall rule
• เหตุใดจึงสำคัญ: การเปลี่ยนแปลงที่ไม่ผ่านการตรวจทานทำให้เกิดสิทธิ์การเข้าถึงที่เปิดกว้างเกินจำเป็น ระบบหยุดทำงาน และข้อค้นพบจากการตรวจสอบ
• ขยายผลอย่างไร: ให้คะแนนความเสี่ยงของแต่ละการเปลี่ยนแปลง เพื่อให้คำขอความเสี่ยงต่ำผ่านได้รวดเร็ว ส่วนคำขอความเสี่ยงสูงได้รับการตรวจทานมากขึ้น
• ผู้ตรวจสอบต้องการอะไร: ผู้ร้องขอ เหตุผลทางธุรกิจ ผู้อนุมัติที่ไม่ใช่ผู้ดำเนินการ แผน rollback และหลักฐานว่าการเปลี่ยนแปลงได้รับการตรวจสอบยืนยันแล้ว

Firewall change management คืออะไร

Firewall change management คือกระบวนการกำกับดูแลที่ควบคุมวิธีการเพิ่ม แก้ไข และลบ firewall rule หากต้องการคำนิยามแบบสั้น โปรดดูคำอธิบายใน glossary เรื่อง firewall change management ส่วนที่เหลือของคู่มือนี้อธิบายวิธีดำเนินกระบวนการ

เหตุใด firewall change management จึงสำคัญ

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

จุดที่ล้มเหลวบ่อยที่สุด:

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

เมื่อมีการเปลี่ยนแปลงเกิดขึ้นในสภาพแวดล้อมของท่าน ทีมงานควรตอบคำถามสามข้อนี้ได้:

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

หากคำตอบตามความเป็นจริงของข้อใดข้อหนึ่งคือ "ไม่แน่ใจ" กระบวนการของท่านยังต้องปรับปรุง

กระบวนการ firewall change management 7 ขั้นตอนมีอะไรบ้าง

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

1. ส่งคำขอเปลี่ยนแปลง

ทุกการเปลี่ยนแปลงเริ่มต้นด้วยคำขออย่างเป็นทางการที่ระบุ:

• ต้นทาง ปลายทาง service และ action
• เหตุผลความจำเป็นทางธุรกิจ
• เจ้าของ rule
• วันหมดอายุสำหรับสิทธิ์การเข้าถึงชั่วคราว

เชื่อมโยงทุกคำขอเข้ากับ ticket ในระบบ IT service management (ITSM) ของท่าน เพื่อให้ทุก rule ย้อนกลับไปถึงเหตุผลที่มีอยู่ได้ และใช้ role-based access control (RBAC) เพื่อให้เฉพาะผู้ได้รับสิทธิ์เท่านั้นที่ส่งคำขอ อนุมัติ หรือดำเนินการเปลี่ยนแปลงได้

หลักฐานที่ต้องจัดเก็บ: ticket ID ผู้ร้องขอ และเหตุผลทางธุรกิจ

2. ตรวจสอบคำขอเทียบกับนโยบายที่มีอยู่

ก่อนที่ใครจะอนุมัติการเปลี่ยนแปลง ให้ตรวจสอบคำขอเทียบกับ rule base ปัจจุบัน:

• ขัดแย้งกับ rule ที่มีอยู่หรือไม่
• ซ้ำซ้อนหรือไม่ หรือจะถูก rule ที่กว้างกว่าซึ่งอยู่เหนือกว่าบดบังไว้
• ละเมิดข้อกำหนดด้าน compliance หรือไม่

การตรวจสอบความถูกต้องแบบอัตโนมัติตอบคำถามเหล่านี้ได้อย่างรวดเร็ว และสกัดการตั้งค่า firewall ที่ผิดพลาดซึ่งพบบ่อย ก่อนที่จะไปถึง production

หลักฐานที่ต้องจัดเก็บ: ผลการตรวจสอบความถูกต้อง

3. ประเมินความเสี่ยงและผลกระทบ

ให้คะแนนการเปลี่ยนแปลงด้วยชุดปัจจัยที่ใช้มาตรฐานเดียวกัน (ดูตารางความเสี่ยงด้านล่าง) จากนั้นจำลองผลกระทบก่อนนำไปใช้งานจริงว่าจะเปิดเส้นทางการเข้าถึงใดบ้าง กระทบการตรวจสอบ compliance ข้อใด และเกี่ยวข้องกับอุปกรณ์ใด การวิเคราะห์แบบ what-if เปลี่ยนการใช้วิจารณญาณให้เป็นการตัดสินใจที่มีเอกสารรองรับ

หลักฐานที่ต้องจัดเก็บ: คะแนนความเสี่ยงและผลการวิเคราะห์ผลกระทบ

4. ส่งการเปลี่ยนแปลงเข้าสู่เส้นทางการอนุมัติ

ให้คะแนนความเสี่ยงเป็นตัวกำหนดเส้นทางการอนุมัติ การเปลี่ยนแปลงความเสี่ยงต่ำผ่านได้ด้วยการตรวจทานจากเพื่อนร่วมทีมเพียงคนเดียว ส่วนการเปลี่ยนแปลงความเสี่ยงสูงต้องเพิ่มผู้ตรวจทานด้านความปลอดภัย เจ้าของระบบงานทางธุรกิจ หรือ change advisory board (CAB) และมีกฎหนึ่งข้อที่ยืดหยุ่นไม่ได้: ผู้ที่อนุมัติการเปลี่ยนแปลงต้องไม่ใช่ผู้ที่ดำเนินการเปลี่ยนแปลงนั้น

หลักฐานที่ต้องจัดเก็บ: ชื่อผู้อนุมัติและ timestamp

5. นำไปใช้งานในช่วงเวลาที่ได้รับอนุมัติ

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

• สิ่งที่ต้องกู้คืน
• ผู้มีอำนาจตัดสินใจ
• เงื่อนไขที่ทำให้ต้อง rollback

หลักฐานที่ต้องจัดเก็บ: บันทึกการ deploy และ rollback plan

6. ตรวจสอบยืนยันการเปลี่ยนแปลง

ยืนยันว่า rule ทำงานตามวัตถุประสงค์ที่ตั้งไว้ และไม่เกินกว่านั้น:

• ทราฟฟิกไหลผ่านตามที่กำหนดไว้
• ไม่มีสิ่งอื่นใดได้รับผลกระทบ
• rule มีการ match กับทราฟฟิกจริง

การระบุเพียงคำว่า "done" ใน ticket ไม่ถือเป็นหลักฐาน

หลักฐานที่ต้องจัดเก็บ: การเปรียบเทียบ configuration ก่อนและหลัง พร้อม hit count หรือ log ที่ดึงออกมา

7. จัดทำเอกสารและทบทวน

บันทึกทุกการเปลี่ยนแปลงในระดับ rule รวมถึงนโยบายความปลอดภัยเครือข่ายที่ได้รับผลกระทบ จากนั้นรักษา rule base ให้อยู่ในสภาพดีอยู่เสมอ:

• ทบทวนและรับรอง rule ร่วมกับ business owner ตามรอบเวลาที่กำหนดอย่างสม่ำเสมอ
• ลบ rule ชั่วคราวเมื่อหมดอายุ

หลักฐานที่ต้องจัดเก็บ: ประวัติการเปลี่ยนแปลงและบันทึกการรับรอง rule ซ้ำ

ท่านจะตัดสินใจอย่างไรว่าการเปลี่ยนแปลงใดต้องผ่านการอนุมัติเพิ่มเติม

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

วิธีนำไปใช้อย่างง่าย:

• ปัจจัยส่วนใหญ่อยู่ในคอลัมน์ความเสี่ยงต่ำกว่า: โดยทั่วไปการอนุมัติจากเพื่อนร่วมทีมหนึ่งคนก็เพียงพอ
• มีปัจจัยใดก็ตามอยู่ในคอลัมน์ความเสี่ยงสูงกว่า: ให้เพิ่มผู้ตรวจสอบด้านความปลอดภัย
• มีหลายปัจจัยอยู่ในคอลัมน์ความเสี่ยงสูงกว่า: ต้องได้รับการอนุมัติจาก business owner พร้อม rollback plan ที่ผ่านการทดสอบแล้ว

ให้เฝ้าระวัง object ที่ใช้ร่วมกันอย่างใกล้ชิด การแก้ไข address group หรือ service group อาจขยายสิทธิ์การเข้าถึงในทุกจุดที่ group นั้นถูกเรียกใช้ แม้การเปลี่ยนแปลงจะดูเหมือนเป็นเพียงบรรทัดเดียวก็ตาม การวิเคราะห์ rule จึงต้องคลี่ค่า object ออกมาจริง ไม่ใช่เพียงอ่านข้อความของ rule ระบบอัตโนมัติระดับ object ของ FireMon จะเพิ่มเข้าไปใน rule ที่มีอยู่เดิมแทนการสร้าง rule ใหม่ ซึ่งช่วยไม่ให้ rule base บวมขึ้นทุกครั้งที่มีคำขอ

ท่านควรจัดการการเปลี่ยนแปลง firewall ในกรณีฉุกเฉินอย่างไร

เหตุฉุกเฉินเกิดขึ้นได้เสมอ กระบวนการของท่านจึงควรยืดหยุ่นได้โดยไม่เสียหลักการ:

• ระบุให้ชัดเจนว่าผู้ใดมีอำนาจอนุมัติการเปลี่ยนแปลงฉุกเฉิน รวมถึงการอนุมัติด้วยวาจา และบันทึกไว้เป็นหลักฐาน
• กำหนดให้ต้องมี rollback plan แม้จะเป็นฉบับย่อก็ตาม
• ดำเนินการทบทวนย้อนหลัง ภายในจำนวนวันทำการที่กำหนดไว้
• ติดตามสัดส่วนของการเปลี่ยนแปลงที่ใช้ช่องทางฉุกเฉิน หากสัดส่วนเพิ่มขึ้นต่อเนื่อง แสดงว่าทีมงานกำลังใช้ช่องทางนี้เพื่อข้ามกระบวนการปกติ

กรอบมาตรฐาน compliance ใดบ้างที่กำหนดให้ต้องมี firewall change management

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

สำหรับแนวทางเฉพาะของแต่ละกรอบมาตรฐาน โปรดดู คู่มือ PCI compliance รวมถึงบทความของเราเรื่อง compliance ด้านความปลอดภัยตาม HIPAA และ compliance ด้านความปลอดภัยตาม NIST.

ประโยชน์ของกระบวนการ firewall change management ที่มีประสิทธิภาพ

• ยกระดับ security posture: การตรวจสอบความถูกต้องของการเปลี่ยนแปลง rule ก่อน deploy ช่วยป้องกันความผิดพลาดของ configuration บังคับใช้สิทธิ์การเข้าถึงแบบ least privilege และควบคุม attack surface ให้เล็กที่สุดทั้งบน on-premises และ cloud
• ลด downtime: การจำลองการเปลี่ยนแปลงก่อน deploy ช่วยตรวจจับ misconfiguration ที่ทำให้ระบบล่ม แอปพลิเคชันสำคัญจึงทำงานได้ต่อเนื่อง
• ผ่าน audit ได้เร็วขึ้น: กระบวนการที่มีโครงสร้างจะบันทึกทุกการเปลี่ยนแปลง การอนุมัติ และการประเมินความเสี่ยง การจัดเตรียมหลักฐานจึงเป็นเพียงการค้นหา ไม่ใช่โครงการใหญ่
• ตอบสนองต่อ incident ได้เร็วขึ้น: ประวัติการเปลี่ยนแปลงระดับ rule แสดงให้เห็นชัดเจนว่ามีอะไรเปลี่ยนและเปลี่ยนเมื่อใด ทีมงานจึงหาสาเหตุของปัญหาได้เร็วขึ้น
• ดำเนินงานได้มีประสิทธิภาพมากขึ้น: การยื่นคำขอ การอนุมัติ และการ deploy แบบอัตโนมัติช่วยลดงาน manual ขณะที่การเชื่อมต่อกับระบบ ITSM และระบบ ticketing ลดความติดขัดระหว่างทีม security และทีม operations

ควรมองหาอะไรในเครื่องมือ firewall change management

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

การตรวจสอบการเปลี่ยนแปลงแบบ real-time

เครื่องมือของคุณควรตรวจจับการเปลี่ยนแปลง policy บนทุกอุปกรณ์ ทั้ง on-premises และบน cloud ได้ทันทีที่เกิดขึ้น เมื่อมี rule เปลี่ยนแปลงนอกกระบวนการ คุณควรได้รับแจ้งอย่างรวดเร็วผ่านช่องทางที่ทีมของคุณใช้งานอยู่แล้ว ศึกษาเพิ่มเติมว่า continuous monitoring ช่วยปกป้องสภาพแวดล้อมที่ซับซ้อนได้อย่างไร.

workflow การเปลี่ยนแปลงที่มีประสิทธิภาพ

คำขอ rule หนึ่งรายการไม่ควรต้องใช้เวลาหลายวันในการวิเคราะห์เส้นทางด้วยมือ มองหาเครื่องมือที่:

• ประเมินทุกคำขอเทียบกับสภาพแวดล้อมทั้งหมด
• ระบุ firewall และอุปกรณ์ทุกตัวในเส้นทางของ traffic
• แนะนำวิธีสร้าง rule และ object ที่ควรนำกลับมาใช้ซ้ำ

อ่านรายละเอียดเพิ่มเติมได้ที่ วิธีเลือกโซลูชัน change management.

การทำ automation ของการเปลี่ยนแปลง policy

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

ภาพรวมความสามารถด้าน firewall change management

คำถามที่ควรถามเวนเดอร์

1. ระบบสามารถ normalize กฎข้ามทุก firewall vendor และทุก cloud platform ที่คุณใช้งานอยู่ได้หรือไม่
2. ตรวจสอบการเปลี่ยนแปลงที่เสนอเพื่อหาความขัดแย้ง ความเสี่ยง และ compliance ก่อน deploy ได้หรือไม่
3. ทำงานร่วมกับระบบ ITSM ของคุณ เช่น ServiceNow หรือ Jira เพื่อให้กฎทุกข้อเชื่อมโยงกับ ticket ได้หรือไม่
4. จำลองผลกระทบของการเปลี่ยนแปลงต่อ access path ก่อนขึ้นใช้งานจริงได้หรือไม่
5. เก็บประวัติการเปลี่ยนแปลงในระดับกฎพร้อมมุมมองก่อนและหลังหรือไม่
6. ทำ deployment แบบอัตโนมัติในจุดที่คุณไว้วางใจ และให้คำแนะนำสำหรับขั้นตอนที่ต้องทำด้วยมือในจุดที่ยังไม่ไว้วางใจได้หรือไม่
7. กำหนดตารางการ recertification ของกฎร่วมกับเจ้าของระบบฝั่งธุรกิจได้หรือไม่
8. จัดทำหลักฐานสำหรับการตรวจสอบได้ทันทีเมื่อต้องการหรือไม่

FireMon ช่วยด้าน firewall change management ได้อย่างไร

ปัญหา: ข้อมูลการเปลี่ยนแปลงกระจายอยู่ตาม console ของแต่ละ vendor, ticket และสเปรดชีต และทุกขั้นตอนที่ทำด้วยมือคือโอกาสเกิดความผิดพลาด ไม่มีใครอยากตรวจสอบคำขอเปลี่ยนกฎกับ firewall สิบตัวด้วยมือ งานลักษณะนี้ควรใช้เวลาเพียงไม่กี่นาที ไม่ใช่หลายวัน

ผลลัพธ์: ทีมของคุณได้รับคำแนะนำการเปลี่ยนแปลงที่แม่นยำอย่างรวดเร็ว ตรวจสอบความเสี่ยงและ compliance ก่อน deploy และมี audit trail ระดับกฎครอบคลุมทุก vendor และทุก cloud

FireMon ช่วยอย่างไร: FireMon รวบรวมและ normalize policy จาก firewall และ cloud security group ของคุณให้อยู่ในโมเดลเดียว ทุกการเปลี่ยนแปลงจึงถูกประเมินเทียบกับทั้งสภาพแวดล้อม FireMon รองรับ workflow การเปลี่ยนแปลงแบบครบวงจร:

• การออกแบบ policy แบบ intent-based
• การจำลองความเสี่ยงก่อน deploy
• workflow การอนุมัติ
• การตรวจสอบความถูกต้องหลังการเปลี่ยนแปลง

การเปลี่ยนแปลง policy สามารถตรวจสอบความถูกต้องและ deploy ได้ภายในไม่กี่นาที พร้อมการเชื่อมต่อ workflow, การ rollback และการประเมินความเสี่ยงแบบเรียลไทม์ในตัว FireMon ตรวจจับการเปลี่ยนแปลงแบบเรียลไทม์ และบันทึกการแก้ไขแต่ละครั้งพร้อมเหตุผลประกอบเพื่อใช้เป็นหลักฐานในการตรวจสอบ workflow การ recertification ที่มีโครงสร้างชัดเจนช่วยกำหนดเจ้าของให้กับกฎทุกข้อ FireMon เชื่อมต่อกับเทคโนโลยีด้าน security, cloud, network, workflow, ITSM และ operations ที่รองรับมากกว่า 120 รายการ จึงทำงานร่วมกับเครื่องมือที่คุณใช้อยู่แล้วได้

ดูเพิ่มเติมเกี่ยวกับ ระบบอัตโนมัติสำหรับการเปลี่ยนแปลง firewall, การติดตามการเปลี่ยนแปลง และ Policy Planner.

การควบคุม network security policy สำหรับองค์กรยุคใหม่ จองการสาธิต เพื่อดูว่า FireMon จัดการ firewall change management ทั่วทั้งสภาพแวดล้อมของคุณได้อย่างไร