สิทธิ์เข้าถึงชั่วคราวไม่ควรกลายเป็น Firewall Policy ถาวร

การเข้าถึงแบบชั่วคราวมักลงเอยด้วยการกลายเป็นการเข้าถึงถาวร

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

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

หากขาดข้อมูลเหล่านี้ แม้แต่ firewall rule ที่ถูกต้องในเชิงเทคนิคก็ยังประเมินได้ยาก

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

บันทึกบริบทไว้ตั้งแต่ตอนที่ยังจำการตัดสินใจได้ชัดเจน

ในวิดีโอด้านบน Rob Rodriguez, Senior Director ฝ่าย Global Field Engineering ของ FireMon สาธิตวิธีที่ทีมงานบันทึกบริบททางธุรกิจเบื้องหลัง firewall rule ได้โดยตรงใน Security Manager

บริบทดังกล่าวอาจประกอบด้วยข้อมูล เช่น

• เหตุผลความจำเป็นทางธุรกิจ
• หน่วยธุรกิจ
• เจ้าของ rule
• ผู้ร้องขอและผู้อนุมัติ
• ข้อมูล change control
• วันที่ทบทวนครั้งถัดไป
• วันหมดอายุ

ตัวอย่างที่ Rob แสดงมีป้ายกำกับว่า “Temp Access” ซึ่งสะท้อนปัญหาที่พบบ่อยในการบริหารจัดการ policy

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

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

ทำให้ rule ประเมินได้ง่ายขึ้นในอนาคต

การตั้งค่าทางเทคนิคบอกว่า firewall rule ทำอะไร

เอกสารประกอบบอกว่าเหตุใดจึงต้องมี rule นั้น

ความแตกต่างนี้ยิ่งสำคัญมากขึ้นเมื่อสภาพแวดล้อมขยายตัวและทีมงานเปลี่ยนแปลง

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

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

การบันทึกข้อมูลเหล่านี้ตั้งแต่ต้นทำให้การทบทวนในอนาคตง่ายขึ้นมาก

แทนที่จะต้องถามว่า “มีใครรู้บ้างว่า rule นี้มีไว้ทำอะไร” ผู้ปฏิบัติงานสามารถเริ่มต้นจากวัตถุประสงค์ เจ้าของ และกำหนดการทบทวนที่บันทึกไว้แล้ว

กำหนดวันสิ้นสุดให้กับการเข้าถึงชั่วคราว

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

ไม่ว่าจะเป็นช่วง maintenance window การย้ายระบบ ช่วงทดสอบ การทำงานร่วมกับบุคคลที่สาม หรือความต้องการทางธุรกิจระยะสั้น

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

กระบวนการที่ดีกว่าคือการเชื่อม rule ทางเทคนิคเข้ากับวงจรชีวิตทางธุรกิจของ rule นั้น

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

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

เปลี่ยน firewall rule ให้เป็นการตัดสินใจที่มีการกำกับดูแล

การบริหารจัดการ firewall policy จะง่ายขึ้นเมื่อมอง rule เป็นการตัดสินใจทางธุรกิจ ไม่ใช่เพียง configuration object

FireMon ช่วยให้ทีมงานเชื่อมโยง policy ทางเทคนิคเข้ากับข้อมูลเจ้าของ เหตุผลความจำเป็น และการทบทวน ซึ่งจำเป็นต่อการบริหารจัดการการเข้าถึงนั้นในระยะยาว

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

เพราะคำถามไม่ได้มีเพียงว่า rule ใช้งานได้ในวันนี้หรือไม่ แต่คือองค์กรจะยังเข้าใจ เป็นเจ้าของ และจำเป็นต้องใช้การเข้าถึงนั้นในวันข้างหน้าหรือไม่

นำบริบททางธุรกิจเข้าสู่การบริหารจัดการ firewall policy ดูว่า FireMon Security Manager ช่วยให้ทีมงานเข้าใจ บันทึก และกำกับดูแล security policy ในสภาพแวดล้อมที่ซับซ้อนได้อย่างไร