Policy Workbench 入门：何时使用、如何使用

一项防火墙变更请求要求放通两个系统之间的访问。FireMon Rule Recommendation 识别出相关防火墙，并建议在一条现有规则上方新增一条规则，因为该现有规则的范围过于宽泛。

该建议为您提供了起点。但在推进之前，您需要了解现有规则、评估建议的放置位置，并确认该变更在满足请求的同时不会引入不必要的访问权限。

这正是 FireMon Policy Workbench 的用武之地。

Policy Workbench 将自动化规则建议与用于检查现有策略、设计变更的工作区结合在一起。工程师可以审查建议、调查规则与对象，并在需要时进行受支持的手动变更。

以下介绍何时使用 Workbench，以及如何从一条建议推进到变更计划。

Policy Workbench 在防火墙变更管理中的定位

防火墙变更不仅仅是决定添加哪条规则。工程师需要对现有环境的可见性、设计变更的方法，以及审查和实施变更的流程。

FireMon 通过三项相互关联的能力支持这些工作。

Security Manager 提供策略上下文。 它让工程师能够查看所支持设备上的防火墙规则、对象和配置。

Policy Planner 管理变更流程。 它为防火墙策略变更的创建、分析、审批、实施和验证提供结构化的工作流。

Policy Workbench 提供设计工作区。 作为 Policy Planner 的组成部分，Workbench 让工程师在变更进入后续工作流之前，审查规则建议、检查现有策略并准备变更。

Rule Recommendation 会分析所请求的访问，识别相关设备并建议适当的策略变更。视环境而定，它可能建议新增规则、修改现有规则，或在访问已经存在时无需任何操作。

Workbench 帮助工程师评估这些建议，而不是不加审查地直接采纳。

当自动化建议不完整或需要进一步细化时，它还提供了手动设计变更的结构化方式。

这一区别很重要：在 Workbench 中保存建议的变更计划，并不会将变更部署到防火墙上。 该计划在实施前仍会继续经过适用的 Policy Planner 工作流。

何时应使用 Policy Workbench

并非每项防火墙变更都需要同等程度的调查。有些建议十分直接，另一些则会引出关于现有规则、策略放置位置或信息缺失的疑问。

Workbench 支持三种常见情形。

当规则建议已满足请求时

假设 Rule Recommendation 识别出了相关防火墙，并提出新增一条规则以满足所请求的访问。

您可以检查建议的变更、审查受影响的策略，并在合适的情况下选择采纳该建议。

目的并不是手动重复一遍建议过程，而是确认建议的变更满足需求，并符合贵组织的策略标准。

当建议需要进一步检查时

回到开头的示例。

Rule Recommendation 建议在一条现有规则上方创建新规则，因为该现有规则的范围过于宽泛。

这为什么重要？

防火墙规则是按照设备的策略行为和规则顺序进行匹配的。建议规则所处的位置会影响流量的处理方式。

在采纳该建议之前，您需要检查现有规则，并了解建议的变更如何融入整体策略。

Workbench 让您可以查看相关的安全规则、网络对象和服务对象。您可以审查建议的放置位置，并判断推荐的设计是否合适。

当建议不完整或无法生成时

有时，Rule Recommendation 无法给出完整的结果。

原因可能是信息缺失、设备选择、不受支持的配置，或其他影响分析的情况。

Workbench 提供有助于排查此类问题的信息。您可以在条件允许时纠正问题，并重新请求建议。

如果仍然无法获得建议，Workbench 也支持在环境的能力与权限范围内手动设计变更。

推荐的变更与手动变更可以纳入同一个变更计划，使工程师无需完全依赖自动化即可继续推进工作。

如何使用 Policy Workbench：从建议到变更计划

让我们回到最初的场景。

一项访问请求需要变更防火墙策略。Rule Recommendation 建议在一条现有规则上方新增一条规则，因为该规则的范围过于宽泛。

以下说明工程师如何在 Workbench 中评估该建议并准备变更计划。

第 1 步：明确访问需求

从访问请求入手，而不是从建议的防火墙规则入手。

确认源、目的、所需服务和业务用途。这些细节确定了该变更需要达成的目标。

例如，一项允许两个系统之间通信的请求，应明确指出究竟哪些系统需要访问权限，以及它们需要哪些服务。

不要想当然地认为现有规则更宽泛的权限应当延续到新的访问上。

目标是以范围适当的访问权限满足该请求。

第 2 步：在 Workbench 中打开变更计划

在 Policy Planner 中，找到对应的工单以及需要变更计划的需求项。

展开该需求项并选择 添加变更计划。变更计划编辑器将在新的浏览器标签页中打开。

该编辑器可供您查看规则建议、受支持的手动变更，以及设计变更所需的策略信息。

在请求建议之前，请确认该需求项准确描述了预期的访问。

第 3 步：审查规则建议

选择 请求推荐 以运行推荐流程。结果生成后,选择 查看推荐。

规则推荐会识别相关设备,并根据现有策略信息、workflow 配置和用户权限提出变更建议。

在本示例场景中,由于某条现有规则过于宽泛,推荐结果建议在该规则上方新建一条规则。

在选用该建议之前,请先核查建议涉及的设备、规则及其放置位置。

在受支持的版本中,关于此推荐 会提供更多背景信息,说明系统为何给出该项操作建议。

请借助这些信息理解该建议,再决定是否将其纳入变更计划。

第 4 步:检查现有策略并优化设计

推荐结果指出了一项可行的变更。接下来,您需要判断该变更是否合理。

使用 Workbench 检查现有安全规则及其关联的网络对象和服务对象。

查看当前规则允许哪些访问,以及其范围与申请的访问需求相比有何差异。

在本示例中,关键问题在于:在现有规则上方添加一条更具体的规则,能否正确满足该访问申请。

请审查建议规则的源、目标、服务及放置位置,并考虑其是否符合既定命名规范和内部策略要求。

如果该建议合适,即可将其选入变更计划。

如果需要调整,Workbench 支持在受支持的设备上手动修改规则和对象。您可以另行准备一项变更,或在必要时对所选建议进行补充。

可用的编辑操作取决于设备、策略配置、权限以及受支持的 workflow。

在操作过程中,Change Plan 抽屉面板会显示正在编排的各项变更,使您能够统一审查推荐变更与手动变更,而不必将二者视为彼此独立的工作。

目标是形成一套完整、一致且满足访问需求的设计方案。

第 5 步:保存变更计划并在实施前验证风险

保存之前,请审查已编排完成的变更计划。

确认已包含相应的设备和策略;核对建议的规则定义、对象及放置位置;确保任何手动变更都能与所选建议相互配合。

计划就绪后,选择 保存。

保存只会保留拟议的变更内容,并不会将其实施到 firewall 上。

正因如此,FireMon 的变更前风险与合规分析才至关重要。

随着工单在 Policy Planner 的 workflow 中流转,FireMon 可对拟议变更进行模拟,并在实施前依据适用的安全与合规控制对其进行评估。

这些评估有助于判断拟议变更是否会造成策略不合规或加剧风险。工程师不必仅凭变更能否满足访问申请就予以批准,而是可以评估其潜在的安全影响。

如果评估发现问题,团队可审阅相关结论,并判断是否需要在批准前修订变更计划。

这一区别十分重要:一项变更可能满足了申请的访问需求,却仍会带来不可接受的风险。

将 Workbench 的变更设计能力与 Policy Planner 的变更前评估相结合,工程师便能更清楚地了解变更的实际效果,以及它是否符合组织的安全要求,从而放心推进。

所需的评估与审批完成后,工单即可按照既定 workflow 进入实施和验证环节。

推进之前应核查哪些内容

一份完成的变更计划应清晰说明需要变更什么以及为什么要变更。

在推进工单之前,请先回答五个问题。

拟议的访问权限是否与需求一致? 确认源、目标、服务和业务用途与最初的申请相符,并留意是否存在不必要的宽泛权限。

设备、对象和规则放置位置是否恰当? 检查拟议变更与现有策略之间的相互影响。在本示例中,请确认在较宽泛的规则上方插入一条规则能够实现预期行为。

警告信息或不完整的推荐结果是否已处理? 排查推荐过程中的错误或缺失信息。不要想当然地认为结果不完整就意味着无需变更。

还有哪些分析和审批尚未完成? 明确实施前所需的风险评估、合规检查和 workflow 审批。

将如何验证预期的访问权限? 确定在部署后如何确认变更按预期生效,且未引入意外的访问权限。

这些核查有助于确保拟议变更已具备进入下一阶段的条件。

让规则推荐与工程师判断力协同发挥作用

规则推荐可帮助工程师识别哪些地方可能需要变更,以及采取哪些操作能够满足访问申请。

Policy Workbench 则提供相应的上下文与灵活性,让他们自行决定如何推进。

当推荐结果明确时,工程师可直接审查并选用;当某项拟议变更需要进一步核实时,他们可以检查现有策略;而当推荐结果不完整时,受支持的手动设计方式可让他们继续完善计划。

由此形成一种更务实的 firewall 变更设计方式:由自动化完成基础工作,由工程师做出关键决策。

深入了解 Policy Workbench,看看 FireMon 如何将自动化规则推荐与亲手完成的策略变更设计结合起来。