Published: October 29, 2026

Policy Workbench 101: ใช้เมื่อใดและใช้อย่างไร

FireMon Policy Workbench ช่วยให้วิศวกรออกแบบแผนการเปลี่ยนแปลง firewall ได้ แต่การบันทึกไม่ได้หมายถึงการ deploy เพราะการเปลี่ยนแปลงต้องผ่าน workflow ของ Policy Planner ก่อน

by FireMon

มี firewall change request เข้ามาเพื่อขอเปิดการเข้าถึงระหว่างสองระบบ FireMon Rule Recommendation ระบุ firewall ที่เกี่ยวข้อง และเสนอให้เพิ่ม rule ใหม่เหนือ rule ที่มีอยู่ เนื่องจาก rule เดิมมีขอบเขตกว้างเกินไป

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

จุดนี้เองที่ FireMon Policy Workbench เข้ามามีบทบาท

Policy Workbench ผสานคำแนะนำ rule แบบอัตโนมัติเข้ากับพื้นที่ทำงานสำหรับตรวจสอบ policy ที่มีอยู่และออกแบบการเปลี่ยนแปลง วิศวกรสามารถตรวจทานคำแนะนำ ตรวจสอบ rules และ objects รวมถึงทำการเปลี่ยนแปลงด้วยตนเองตามที่ระบบรองรับเมื่อจำเป็น

ต่อไปนี้คือกรณีที่ควรใช้ Workbench และวิธีดำเนินการจากคำแนะนำไปสู่ change plan

ตำแหน่งของ Policy Workbench ใน firewall change management

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

FireMon รองรับงานเหล่านี้ผ่านความสามารถสามส่วนที่เชื่อมโยงกัน

Security Manager ให้บริบทด้าน policy โดยช่วยให้วิศวกรมองเห็น firewall rules, objects และ configurations บนอุปกรณ์ที่รองรับ

Policy Planner บริหารจัดการกระบวนการเปลี่ยนแปลง โดยมี workflows ที่มีโครงสร้างสำหรับการสร้าง วิเคราะห์ อนุมัติ นำไปใช้ และตรวจสอบยืนยันการเปลี่ยนแปลง firewall policy

Policy Workbench ให้พื้นที่ทำงานสำหรับการออกแบบ ในฐานะส่วนหนึ่งของ Policy Planner นั้น Workbench ช่วยให้วิศวกรตรวจทานคำแนะนำ rule ตรวจสอบ policy ที่มีอยู่ และเตรียมการเปลี่ยนแปลงก่อนส่งต่อไปยัง workflow ส่วนที่เหลือ

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

Workbench ช่วยให้วิศวกรประเมินคำแนะนำเหล่านั้น แทนที่จะยอมรับโดยไม่ผ่านการตรวจทาน

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

ข้อแตกต่างนี้สำคัญ: การบันทึก change plan ที่เสนอไว้ใน Workbench ไม่ได้เป็นการ deploy การเปลี่ยนแปลงลงบน firewall แผนดังกล่าวจะดำเนินต่อผ่าน workflow ของ Policy Planner ที่เกี่ยวข้องก่อนการนำไปใช้จริง

ควรใช้ Policy Workbench เมื่อใด

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

Workbench รองรับสามสถานการณ์ที่พบได้บ่อย

เมื่อ Rule Recommendations ตอบโจทย์คำขอได้

สมมติว่า Rule Recommendation ระบุ firewall ที่เกี่ยวข้องและเสนอให้เพิ่ม rule ที่ตอบสนองการเข้าถึงที่ร้องขอ

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

เป้าหมายไม่ใช่การทำซ้ำกระบวนการให้คำแนะนำด้วยตนเอง แต่คือการยืนยันว่าการเปลี่ยนแปลงที่เสนอตรงตามความต้องการและสอดคล้องกับมาตรฐาน policy ขององค์กรคุณ

เมื่อคำแนะนำต้องการการตรวจสอบอย่างละเอียด

ลองย้อนกลับไปที่ตัวอย่างในตอนต้น

Rule Recommendation เสนอให้สร้าง rule ใหม่เหนือ rule ที่มีอยู่ เนื่องจาก rule เดิมมีขอบเขตกว้างเกินไป

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

Firewall rules ถูกประมวลผลตามพฤติกรรมของ policy บนอุปกรณ์และลำดับของ rule ดังนั้นตำแหน่งของ rule ที่เสนอจึงส่งผลต่อวิธีจัดการ traffic ได้

ก่อนยอมรับคำแนะนำ คุณต้องตรวจสอบ rule ที่มีอยู่ และทำความเข้าใจว่าการเปลี่ยนแปลงที่เสนอเข้ากับ policy อย่างไร

Workbench ช่วยให้คุณตรวจสอบ security rules, network objects และ service objects ที่เกี่ยวข้อง คุณสามารถตรวจทานตำแหน่งที่เสนอและตัดสินใจว่าการออกแบบที่แนะนำนั้นเหมาะสมหรือไม่

เมื่อคำแนะนำไม่สมบูรณ์หรือไม่มีคำแนะนำ

บางครั้ง Rule Recommendation ไม่สามารถให้ผลลัพธ์ที่สมบูรณ์ได้

สาเหตุอาจมาจากข้อมูลที่ขาดหายไป การเลือกอุปกรณ์ configuration ที่ไม่รองรับ หรือเงื่อนไขอื่นที่ส่งผลต่อการวิเคราะห์

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

หากยังไม่มีคำแนะนำ Workbench ยังรองรับการออกแบบการเปลี่ยนแปลงด้วยตนเอง ภายในขอบเขตความสามารถและสิทธิ์ของสภาพแวดล้อมนั้น

การเปลี่ยนแปลงที่มาจากคำแนะนำและที่ทำด้วยตนเองสามารถรวมอยู่ใน change plan เดียวกันได้ ทำให้วิศวกรทำงานต่อได้โดยไม่ต้องพึ่งพาระบบอัตโนมัติทั้งหมด

วิธีใช้ Policy Workbench: จากคำแนะนำสู่ change plan

ลองกลับไปที่สถานการณ์ตั้งต้นอีกครั้ง

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

ต่อไปนี้คือวิธีที่วิศวกรสามารถประเมินคำแนะนำและเตรียม change plan ใน Workbench

ขั้นตอนที่ 1: กำหนดความต้องการด้านการเข้าถึง

เริ่มจากคำขอเข้าถึง ไม่ใช่จาก firewall rule ที่ถูกเสนอ

ยืนยัน source, destination, services ที่จำเป็น และวัตถุประสงค์ทางธุรกิจ รายละเอียดเหล่านี้กำหนดว่าการเปลี่ยนแปลงต้องบรรลุสิ่งใด

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

อย่าสันนิษฐานว่าสิทธิ์ที่กว้างกว่าของ rule ที่มีอยู่ควรถูกนำมาใช้กับการเข้าถึงใหม่

เป้าหมายคือการตอบสนองคำขอด้วยการเข้าถึงที่มีขอบเขตเหมาะสม

ขั้นตอนที่ 2: เปิด change plan ใน Workbench

ใน Policy Planner ให้ค้นหา ticket และ requirement ที่ต้องการ change plan

ขยาย requirement แล้วเลือก เพิ่ม Change Plan ระบบจะเปิด Change Plan Editor ขึ้นในแท็บเบราว์เซอร์ใหม่

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

ก่อนขอคำแนะนำ ให้ยืนยันว่า requirement อธิบายการเข้าถึงที่ต้องการได้อย่างถูกต้อง

ขั้นตอนที่ 3: ตรวจทาน Rule Recommendation

เลือก ขอคำแนะนำ เพื่อเริ่มกระบวนการสร้างคำแนะนำ เมื่อผลลัพธ์พร้อมใช้งาน ให้เลือก ดูคำแนะนำ.

Rule Recommendation จะระบุอุปกรณ์ที่เกี่ยวข้องและเสนอการเปลี่ยนแปลงโดยอ้างอิงจากข้อมูล policy ที่มีอยู่ การตั้งค่า workflow และสิทธิ์ของผู้ใช้

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

ก่อนเลือกใช้ ให้ตรวจสอบอุปกรณ์ rule และตำแหน่งการวางที่ระบบเสนอ

ในเวอร์ชันที่รองรับ เกี่ยวกับคำแนะนำนี้ จะให้บริบทเพิ่มเติมที่อธิบายว่าเหตุใดจึงเสนอการดำเนินการนั้น

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

ขั้นตอนที่ 4: ตรวจสอบ policy ที่มีอยู่และปรับแต่งการออกแบบ

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

ใช้ Workbench ตรวจสอบ security rule ที่มีอยู่ พร้อมทั้ง network object และ service object ที่เกี่ยวข้อง

พิจารณาว่า rule ปัจจุบันอนุญาตสิ่งใด และขอบเขตของ rule นั้นเทียบกับการเข้าถึงที่ร้องขออย่างไร

ในตัวอย่างนี้ คำถามสำคัญคือการเพิ่ม rule ที่เฉพาะเจาะจงมากขึ้นไว้เหนือ rule เดิมจะตอบโจทย์คำขอได้อย่างถูกต้องหรือไม่

ตรวจทาน source, destination, services และตำแหน่งการวางของ rule ที่เสนอ พิจารณาว่าสอดคล้องกับ naming convention ที่กำหนดไว้และข้อกำหนดของ policy ภายในองค์กรหรือไม่

หากคำแนะนำเหมาะสม ให้เลือกคำแนะนำนั้นเข้าสู่แผนการเปลี่ยนแปลง

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

การดำเนินการแก้ไขที่ใช้ได้ขึ้นอยู่กับอุปกรณ์ การกำหนดค่า policy สิทธิ์การใช้งาน และ workflow ที่รองรับ

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

เป้าหมายคือการออกแบบที่ครบถ้วนและสอดคล้องกัน ซึ่งตอบโจทย์ความต้องการด้านการเข้าถึง

ขั้นตอนที่ 5: บันทึกแผนการเปลี่ยนแปลงและตรวจสอบความเสี่ยงก่อนนำไปใช้งานจริง

ก่อนบันทึก ให้ตรวจทานแผนการเปลี่ยนแปลงที่ประกอบขึ้นมา

ยืนยันว่าอุปกรณ์และ policy ที่เกี่ยวข้องถูกรวมไว้ครบถ้วน ตรวจสอบนิยามของ rule, object และตำแหน่งการวางที่เสนอ และตรวจสอบให้แน่ใจว่าการแก้ไขด้วยตนเองทั้งหมดสอดรับกับคำแนะนำที่เลือกไว้

เมื่อแผนพร้อมแล้ว ให้เลือก บันทึก.

การบันทึกเป็นเพียงการเก็บการเปลี่ยนแปลงที่เสนอไว้ ไม่ใช่การนำไปใช้งานบน firewall

จุดนี้เองที่การวิเคราะห์ความเสี่ยงและ compliance ก่อนการเปลี่ยนแปลงของ FireMon มีความสำคัญอย่างยิ่ง

เมื่อ ticket เคลื่อนผ่าน workflow ของ Policy Planner FireMon สามารถจำลองการเปลี่ยนแปลงที่เสนอ และประเมินเทียบกับ control ด้านความปลอดภัยและ compliance ที่เกี่ยวข้องก่อนนำไปใช้งานจริง

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

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

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

ด้วยการผสานความสามารถในการออกแบบการเปลี่ยนแปลงของ Workbench เข้ากับการประเมินก่อนการเปลี่ยนแปลงของ Policy Planner วิศวกรจะเดินหน้าต่อได้โดยเข้าใจชัดเจนว่าการเปลี่ยนแปลงนั้นจะส่งผลอย่างไร และเป็นไปตามข้อกำหนดด้านความปลอดภัยขององค์กรหรือไม่

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

สิ่งที่ต้องตรวจสอบก่อนดำเนินการต่อ

แผนการเปลี่ยนแปลงที่สมบูรณ์ควรระบุได้อย่างชัดเจนว่าต้องเปลี่ยนอะไรและเพราะเหตุใด

ก่อนผลัก ticket ไปยังขั้นถัดไป ให้ตรวจทานคำถามห้าข้อต่อไปนี้

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

อุปกรณ์ object และตำแหน่งการวาง rule เหมาะสมหรือไม่? พิจารณาว่าการเปลี่ยนแปลงที่เสนอจะส่งผลต่อ policy ที่มีอยู่อย่างไร สำหรับตัวอย่างนี้ ให้ยืนยันว่าการแทรก rule ไว้เหนือ rule ที่มีขอบเขตกว้างกว่าให้ผลลัพธ์ตามที่ต้องการ

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

ยังเหลือการวิเคราะห์และการอนุมัติใดบ้าง? ระบุการประเมินความเสี่ยง การตรวจสอบ compliance และการอนุมัติใน workflow ที่ต้องดำเนินการก่อนนำไปใช้งานจริง

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

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

ใช้ Rule Recommendations ร่วมกับวิจารณญาณของผู้ปฏิบัติงาน

Rule Recommendation ช่วยให้วิศวกรระบุได้ว่าจุดใดอาจต้องเปลี่ยนแปลง และการดำเนินการใดจะตอบโจทย์คำขอเข้าถึง

Policy Workbench มอบบริบทและความยืดหยุ่นในการตัดสินใจว่าจะดำเนินการต่ออย่างไร

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

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

สำรวจ Policy Workbench เพื่อดูว่า FireMon ผสานคำแนะนำ rule แบบอัตโนมัติเข้ากับการออกแบบการเปลี่ยนแปลง policy ด้วยตนเองได้อย่างไร

คำถามที่พบบ่อย

ไม่ การบันทึกแผนการเปลี่ยนแปลงใน FireMon Policy Workbench ไม่ได้ส่งการเปลี่ยนแปลงไปยัง firewall แต่เป็นเพียงการเก็บการแก้ไข rule และ object ที่เสนอไว้ภายใน Policy Planner เท่านั้น แผนดังกล่าวยังต้องผ่าน workflow ที่กำหนดไว้ของ Policy Planner ซึ่งรวมถึงการประเมินความเสี่ยงและ compliance ตลอดจนการอนุมัติอย่างเป็นทางการ ก่อนที่จะมีการนำไปใช้งานบนอุปกรณ์

หลังจากบันทึกแผนแล้ว FireMon Policy Planner จะนำแผนดังกล่าวเข้าสู่ขั้นตอนที่เหลือของ workflow ซึ่งขึ้นอยู่กับการตั้งค่า อาจรวมถึงการจำลองการเปลี่ยนแปลงที่เสนอเทียบกับ control ด้านความปลอดภัยและ compliance การส่งต่อเพื่อขออนุมัติ และเมื่อผ่านขั้นตอนเหล่านี้แล้วจึงดำเนินการและตรวจสอบยืนยันบน firewall การบันทึกจึงเป็นขั้นตอนการออกแบบ ไม่ใช่ขั้นตอนการนำไปใช้งานจริง

FireMon Policy Workbench อยู่ภายใน Policy Planner ในฐานะพื้นที่ทำงานสำหรับการออกแบบ ซึ่งคั่นอยู่ระหว่างคำขอเปลี่ยนแปลงกับการนำไปใช้งานจริง โดย FireMon Security Manager ให้การมองเห็นในระดับ rule และ object ที่เป็นพื้นฐาน Rule Recommendation เสนอแนะการเปลี่ยนแปลงที่เป็นไปได้ ส่วน Workbench คือจุดที่วิศวกรตรวจสอบข้อเสนอแนะเหล่านั้น ปรับแก้ หรือสร้างการเปลี่ยนแปลงด้วยตนเอง ก่อนที่แผนจะเดินหน้าเข้าสู่การอนุมัติและการ deploy

FireMon ประเมินแผนการเปลี่ยนแปลงที่บันทึกไว้เทียบกับ control ด้านความปลอดภัยและ compliance ที่เกี่ยวข้อง ซึ่งเป็นส่วนหนึ่งของ workflow ใน Policy Planner โดยจำลองการเปลี่ยนแปลง rule และ object ที่เสนอก่อนที่จะมีผู้นำไปใช้งานจริง วิธีนี้ทำให้วิศวกรและผู้อนุมัติเห็นว่าการเปลี่ยนแปลงที่ตอบโจทย์คำขอ access นั้นจะทำให้เกิดการไม่สอดคล้องกับนโยบายหรือเพิ่มความเสี่ยงด้วยหรือไม่ แทนที่จะอนุมัติโดยพิจารณาเพียงเรื่อง access อย่างเดียว

ได้ FireMon Rule Recommendation จะวิเคราะห์ access ที่ร้องขอเทียบกับ policy ของ firewall ที่มีอยู่ และสามารถระบุได้ว่ามี rule เดิมที่อนุญาต access ดังกล่าวอยู่แล้ว ซึ่งในกรณีนี้จะไม่มีการแนะนำ rule ใหม่ อย่างไรก็ตาม วิศวกรยังคงใช้ Policy Workbench เพื่อยืนยันผลการวิเคราะห์ดังกล่าวกับ rule ที่เกี่ยวข้อง ก่อนปิดคำขอโดยไม่ต้องเปลี่ยนแปลงใด ๆ

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

ก่อนออกแบบการเปลี่ยนแปลง access บน firewall วิศวกรควรยืนยัน source, destination, services ที่จำเป็น และวัตถุประสงค์ทางธุรกิจจากคำขอต้นทาง แทนที่จะสันนิษฐานว่าสิทธิ์ที่กว้างกว่าของ rule เดิมควรถูกนำมาใช้ต่อ จากนั้น FireMon Policy Workbench จะช่วยให้ตรวจสอบข้อมูลดังกล่าวเทียบกับ policy ที่มีอยู่ ก่อนยอมรับหรือสร้างการเปลี่ยนแปลง

ก่อนส่งต่อ ticket วิศวกรควรยืนยันว่า access ที่เสนอตรงกับคำขอ ว่า device, object และตำแหน่งการวาง rule เหมาะสม และคำเตือนจากคำแนะนำหรือผลลัพธ์ที่ไม่สมบูรณ์ได้รับการจัดการแล้ว นอกจากนี้ควรระบุด้วยว่ายังเหลือการประเมินความเสี่ยงและ compliance หรือการอนุมัติใดบ้าง และจะตรวจสอบยืนยัน access ที่ได้หลังการ deploy อย่างไร