Policy Workbench 入門：使うべきタイミングと使い方

2 つのシステム間のアクセスを許可するため、ファイアウォールの変更申請が提出されました。FireMon の Rule Recommendation は該当するファイアウォールを特定し、既存ルールの範囲が広すぎるため、その上位に新しいルールを追加することを提案します。

この推奨は出発点にすぎません。先に進む前に、既存ルールを理解し、提案された配置を評価したうえで、不要なアクセスを生じさせることなく申請内容を満たせるかを確認する必要があります。

ここで役立つのが FireMon Policy Workbench です。

Policy Workbench は、自動化されたルール推奨と、既存ポリシーを精査して変更を設計するためのワークスペースを組み合わせています。エンジニアは推奨内容をレビューし、ルールやオブジェクトを調査し、必要に応じてサポートされている範囲で手動の変更を加えられます。

ここでは、Workbench を使うべき場面と、推奨内容から変更計画へと進める手順を解説します。

ファイアウォール変更管理における Policy Workbench の位置づけ

ファイアウォールの変更は、どのルールを追加するかを決めるだけでは終わりません。エンジニアには、既存環境の可視性、変更を設計する手段、そしてレビューと実装のプロセスが必要です。

FireMon は、連携する 3 つの機能でこれらの作業を支援します。

Security Manager はポリシーのコンテキストを提供します。 サポート対象デバイス全体のファイアウォールルール、オブジェクト、構成をエンジニアが可視化できるようにします。

Policy Planner は変更プロセスを管理します。 ファイアウォールポリシー変更の作成、分析、承認、実装、検証を体系化したワークフローを提供します。

Policy Workbench は設計用のワークスペースを提供します。 Policy Planner の一部として、Workbench ではエンジニアがルール推奨をレビューし、既存ポリシーを精査し、以降のワークフローに進める前に変更を準備できます。

Rule Recommendation は申請されたアクセスを分析してデバイスを特定し、適切なポリシー変更を提案します。環境によっては、ルールの追加、既存ルールの変更、あるいはすでにアクセスが存在する場合には対応不要との推奨が示されることもあります。

Workbench は、こうした推奨を無条件に受け入れるのではなく、エンジニアが評価できるよう支援します。

また、自動の推奨が不完全な場合や調整が必要な場合に、手動で変更を設計するための体系的な手段も提供します。

この違いは重要です。 Workbench で変更計画案を保存しても、その変更がファイアウォールに展開されるわけではありません。 計画は実装前に、該当する Policy Planner のワークフローを経由します。

Policy Workbench を使うべきタイミング

すべてのファイアウォール変更に同じだけの調査が必要なわけではありません。推奨がそのまま適用できる場合もあれば、既存ルールやポリシー上の配置、情報の不足について確認が必要になる場合もあります。

Workbench は、代表的な 3 つの場面に対応します。

ルール推奨が申請内容を満たしている場合

Rule Recommendation が該当するファイアウォールを特定し、申請されたアクセスを満たすルールの追加を提案したとします。

提案された変更を精査し、影響を受けるポリシーを確認したうえで、適切であればその推奨を選択できます。

目的は、推奨のプロセスを手作業でやり直すことではありません。提案された変更が要件を満たし、自社のポリシー基準に沿っているかを確認することです。

推奨の詳細な確認が必要な場合

冒頭の例を考えてみましょう。

Rule Recommendation は、既存ルールの範囲が広すぎるため、その上位に新しいルールを作成することを提案します。

なぜこれが問題になるのでしょうか。

ファイアウォールルールは、デバイスのポリシー動作とルールの順序に従って評価されます。提案されたルールの位置によって、トラフィックの扱われ方が変わる可能性があります。

推奨を受け入れる前に、既存ルールを精査し、提案された変更がポリシー全体のなかでどのように機能するかを理解する必要があります。

Workbench では、関連するセキュリティルール、ネットワークオブジェクト、サービスオブジェクトを確認できます。提案された配置をレビューし、推奨された設計が適切かどうかを判断できます。

推奨が不完全、または取得できない場合

Rule Recommendation が完全な結果を出力できないこともあります。

原因としては、情報の不足、デバイスの選択、サポート対象外の構成、あるいは分析に影響するその他の条件が考えられます。

Workbench は、問題を調査するための情報を提供します。可能な範囲で問題を修正し、推奨を再度取得できます。

それでも推奨が得られない場合でも、Workbench は環境の機能と権限の範囲内で手動による変更設計をサポートします。

推奨による変更と手動による変更は同一の変更計画にまとめられるため、エンジニアは自動化だけに依存することなく作業を進められます。

Policy Workbench の使い方: 推奨から変更計画まで

冒頭のシナリオに戻りましょう。

アクセス申請によりファイアウォールポリシーの変更が必要になりました。Rule Recommendation は、既存ルールの範囲が広すぎるため、その上位に新しいルールを追加することを提案します。

ここからは、エンジニアが Workbench でこの推奨を評価し、変更計画を準備する手順を見ていきます。

ステップ 1: アクセス要件を定義する

提案されたファイアウォールルールではなく、アクセス申請そのものから着手します。

送信元、宛先、必要なサービス、業務上の目的を確認します。これらの情報により、この変更で達成すべき内容が明確になります。

たとえば、2 つのシステム間の通信を許可する申請であれば、どのシステムにアクセスが必要で、どのサービスが求められるのかを正確に特定する必要があります。

既存ルールの広い許可範囲をそのまま新しいアクセスに引き継いでよい、と考えるのは避けてください。

目的は、適切に範囲を絞ったアクセスで申請を満たすことです。

ステップ 2: Workbench で変更計画を開く

Policy Planner で、変更計画が必要なチケットと要件を特定します。

要件を展開し、Add Change Planを選択します。Change Plan Editor が新しいブラウザータブで開きます。

このエディターでは、ルール推奨、サポートされている手動変更、変更の設計に必要なポリシー情報を利用できます。

推奨を取得する前に、要件が意図するアクセスを正確に記述しているかを確認してください。

ステップ 3: ルール推奨をレビューする

Request Recommendations を選択して、推奨プロセスを実行します。結果が表示されたら、View Recommendations を選択します。

Rule Recommendation は、参照可能なポリシー情報、ワークフローの設定、ユーザー権限に基づいて対象となり得るデバイスを特定し、変更内容を提案します。

今回のシナリオでは、既存ルールの範囲が広すぎるため、そのルールの上に新しいルールを作成することが推奨されています。

選択する前に、提案されたデバイス、ルール、配置位置を確認してください。

対応リリースでは、About This Recommendation に、特定のアクションが推奨された理由を説明する追加のコンテキストが表示されます。

その情報をもとに推奨内容を理解したうえで、変更プランに含めるかどうかを判断してください。

ステップ 4: 既存ポリシーを確認し、設計を精緻化する

推奨は変更の候補を示すものです。次に、その変更が妥当かどうかを判断する必要があります。

Workbench で、既存のセキュリティルールと、それに関連するネットワークオブジェクトおよびサービスオブジェクトを確認します。

現在のルールが何を許可しているか、またその範囲が要求されたアクセスとどう異なるかを確認します。

今回の例では、既存ルールの上により限定的なルールを追加することで要求に適切に対応できるかどうかが、重要な論点となります。

提案されたルールの送信元、宛先、サービス、配置位置を確認します。既存の命名規則や社内のポリシー要件に適合しているかどうかも検討してください。

推奨内容が適切であれば、変更プランに追加するものとして選択します。

調整が必要な場合、Workbench では対応デバイス上でルールとオブジェクトを手動で変更できます。別の変更を用意することも、必要に応じて選択した推奨内容を補完することも可能です。

実行できる編集操作は、デバイス、ポリシー構成、権限、対応するワークフローによって異なります。

作業中は、「Change Plan」ドロワーに組み立て中の変更内容が表示されます。これにより、推奨による変更と手動による変更を別々の作業として扱うのではなく、まとめて確認できます。

目指すのは、アクセス要件を満たす、完全で一貫性のある設計です。

ステップ 5: 変更プランを保存し、実装前にリスクを検証する

保存する前に、組み立てた変更プランを確認します。

適切なデバイスとポリシーが含まれていることを確認します。提案されたルール定義、オブジェクト、配置位置を点検します。手動で加えた変更が、選択した推奨内容を適切に補完していることを確かめてください。

プランが完成したら、次を選択します: Save を選択します。

保存すると提案された変更内容は保持されますが、ファイアウォールに適用されるわけではありません。

ここで重要になるのが、FireMon による変更前のリスク分析とコンプライアンス分析です。

チケットが Policy Planner のワークフローを進む過程で、FireMon は提案された変更をシミュレーションし、実装前に該当するセキュリティおよびコンプライアンス統制に照らして評価できます。

これらの評価により、提案された変更がポリシー上のコンプライアンス違反を生じさせないか、リスクを高めないかを把握できます。アクセス要求を満たすかどうかだけで変更を承認するのではなく、エンジニアはセキュリティ面で生じ得る影響を評価できます。

評価で問題が検出された場合、チームはその結果を確認し、承認前に変更プランの修正が必要かどうかを判断できます。

これは重要な違いです。要求されたアクセスを満たす変更であっても、許容できないリスクをもたらす場合があります。

Workbench の変更設計機能と Policy Planner の変更前評価を組み合わせることで、エンジニアはその変更が何をもたらすのか、自社のセキュリティ要件を満たすのかをより明確に把握したうえで作業を進められます。

必要な評価と承認が完了すると、チケットは設定されたワークフローに従って実装と検証へ進みます。

次の段階に進む前に確認すべきこと

完成した変更プランには、何をなぜ変更する必要があるのかが明確に示されているはずです。

チケットを次の段階に進める前に、次の 5 つの点を確認してください。

提案されたアクセスは要件と一致していますか。 送信元、宛先、サービス、業務上の目的が当初の要求と整合していることを確認します。過度に広範な許可になっていないかにも注意してください。

デバイス、オブジェクト、ルールの配置位置は適切ですか。 提案された変更が既存ポリシーとどのように影響し合うかを確認します。今回の例では、より広範なルールの上にルールを挿入することで意図した動作が実現できるかを確かめます。

警告や不完全な推奨への対応は済んでいますか。 推奨のエラーや情報の欠落は必ず調査してください。結果が不完全だからといって、変更が不要であると判断してはいけません。

どの分析と承認が残っていますか。 実装前に必要なリスク評価、コンプライアンスチェック、ワークフロー上の承認を特定します。

意図したアクセスをどのように検証しますか。 展開後に、変更が想定どおりに機能し、意図しないアクセスを生じさせていないことをどう確認するかを決めておきます。

これらの確認により、提案された変更がプロセスの次の段階へ進められる状態にあることを担保できます。

ルール推奨と実務者の判断を活かす

Rule Recommendation は、どこに変更が必要となり得るのか、どのような対応でアクセス要求を満たせるのかを、エンジニアが特定する助けになります。

Policy Workbench は、どのように進めるかを判断するためのコンテキストと柔軟性を提供します。

推奨が明確であれば、エンジニアはその内容を確認して選択できます。提案された変更にさらなる調査が必要な場合は、既存のポリシーを精査できます。推奨が不完全な場合でも、対応環境での手動設計によってプランの構築を継続できます。

その結果、ファイアウォールの変更設計はより実践的なアプローチになります。下準備は自動化が担い、重要な判断はエンジニアが下します。

Policy Workbench をご覧いただき、 FireMon が自動のルール推奨と実践的なポリシー変更設計をどのように組み合わせているかをご確認ください。