ポリシーリスクを可視化。自然な言葉でポリシーに関する疑問を解決します。 デモを申し込む →
Published:
ファイアウォールルールの再認証：アクセスレビューを反復可能なプロセスにする
チームをまたいでファイアウォールのアクセスレビューを反復可能にしましょう。FireMon Policy Optimizer がルールのコンテキストを集約し、再認証の判断を記録する仕組みをご覧ください。
by FireMon
未使用のルールや疑わしいファイアウォールルールを発見することは、始まりにすぎません。
より難しいのは、そのルールをどう扱うかを判断することです。
そのアクセスには、今も正当なビジネス上の目的があるでしょうか。ルールは削除できるでしょうか。まず誰かがレビューする必要があるでしょうか。そして、同じ問いに後から再び答えずに済むよう、その判断をどのように記録するでしょうか。
ここで重要になるのが、ルールの再認証です。
反復可能な再認証プロセスがあれば、不要と思われるアクセスを特定するだけで終わらず、そのアクセスを維持すべきかどうかを体系的に判断できるようになります。
検出結果を判断につなげる
上の動画では、FireMon の Global Field Engineering シニアディレクターである Rob Rodriguez が、Policy Optimizer によってファイアウォールルールのレビューと再認証をどのように支援できるかを紹介しています。
この例では、Rob は未使用と判定されたルールを取り上げ、レビューを裏付ける情報を一つずつ確認していきます。
対象となるのは、ルールそのもの、裏付けとなる分析結果、コメント、添付ファイル、タスク履歴、レビュー履歴、そしてルールの使用状況情報です。
これらの情報が揃うことで、レビュー担当者は判断を下す前により多くのコンテキストを得られます。
未使用のルールは有用なシグナルですが、それが即座に削除すべきルールであるとは限りません。最近使用されていないことに正当な理由がある場合もあります。
再認証は、単一の指標だけで対応するのではなく、こうした根拠を精査するためのプロセスを生み出します。
アクセスレビューに一貫性を持たせる
プロセスが定義されていないと、ファイアウォールルールのレビューは一貫性を欠きがちです。
あるチームは四半期ごとに未使用ルールをレビューし、別のチームは監査のときにしか確認しません。さらに別の担当者は、スプレッドシートやチケット履歴、あるいはルールを作成したエンジニアの記憶に頼っているかもしれません。
これでは、信頼できるポリシーガバナンスの体制を確立することは困難です。
体系化された再認証ワークフローがあれば、チームは同じ基本的な問いを一貫して立てられます。
- このアクセスは現在も必要ですか
- 当初のビジネス上の必要性は現在も有効ですか
- 誰がその判断を承認すべきですか
- ルールの維持または削除を裏付ける根拠は何ですか
- このルールは最後にいつレビューされましたか
目的は、レビュー作業をもう一つ増やすことではありません。放置すれば無期限に残り続けかねないアクセスについて、判断が記録として残るプロセスを構築することです。
ルールの使用状況を出発点にする
ルールの使用状況データは、どこから着手すべきかを見極める助けになります。
長期間使用されていないルールは、アプリケーションの変更、プロジェクトの終了、トラフィックの移行、あるいはアクセスがすでに不要になっていることを示している可能性があります。
しかし、使用状況だけでは答えのすべてを得ることはできません。
使用状況の情報に、ルールの詳細、所有者、過去のレビュー、裏付けとなるドキュメントを組み合わせることで、担当者はそのルールを維持すべきかどうかをより的確に判断できます。
すべてのルールを手作業で調査することが現実的でない大規模環境では、この点が特に重要になります。
役目を終えたアクセスを残さない
ファイアウォール環境は絶えず変化します。アプリケーションは廃止され、ユーザーの役割は変わり、インフラは移行し、取引関係も終了します。
アクセスもそれに合わせて変わるべきです。
FireMon Policy Optimizer は、レビューすべきルールの特定と、ポリシー管理プロセスへの再認証の組み込みを支援します。これにより、不要と思われるアクセスの発見から、次に取るべき対応の記録までを、より明確な道筋でたどれます。
その結果、誰も見直さなかったという理由だけで過去のアクセスが残り続ける状態を避け、ファイアウォールポリシーを現在のビジネスニーズに一貫して整合させられます。
ファイアウォールルールのクリーンアップと再認証を、反復可能なプロセスにしましょう。 詳しくは FireMon Policy Optimizer が不要なルールの特定、アクセスのレビュー、ポリシーの継続的な最適化をどのように支援するかをご覧ください。
本シリーズの他の記事もあわせてご覧ください：
よくあるご質問
体系化された再認証ワークフローを一つに統一し、どのチームも同じ問いを立て、同じ方法で判断を記録できるようにします。これがないと、あるチームは四半期ごとにレビューし、別のチームは監査を待ち、さらに別のチームはスプレッドシートや記憶に頼ることになります。FireMon Policy Optimizer は再認証をポリシー管理に組み込む取り組みを支援し、レビューのコンテキストと判断をツール間に散在させることなく一元的に管理できます。
一貫したレビューでは、すべてのルールについて5つの問いを立てます。このアクセスは現在も必要か。当初のビジネス上の必要性は現在も有効か。誰がその判断を承認すべきか。ルールの維持または削除を裏付ける根拠は何か。このルールは最後にいつレビューされたか。毎回同じ問いを立てることで、ルールのレビューは単発のクリーンアップ作業ではなく、記録に残るガバナンスの実践になります。
まずルールの使用状況から着手すべき箇所を把握し、次にルールの詳細、所有者、過去のレビュー、裏付けとなるドキュメントを加えます。使用状況は有力な候補を示し、その他のデータはそのアクセスが存在する理由を説明します。FireMon Policy Optimizer では、レビュー担当者はルール、裏付けとなる分析結果、コメント、添付ファイル、タスク履歴、レビュー履歴、使用状況情報をまとめて確認できます。
未使用のルールは有用なシグナルですが、そのアクセスが不要であることの証拠にはなりません。最近トラフィックが流れていないことに正当な理由がある場合もあります。使用頻度の低さは、アプリケーションの変更、プロジェクトの終了、トラフィックの移行を意味することもあります。再認証により、レビュー担当者は単一の指標で対応するのではなく、根拠全体を踏まえて判断できます。
レビュー担当者は、ルールそのもの、裏付けとなる分析結果、コメント、添付ファイル、タスク履歴、過去のレビュー履歴、ルールの使用状況を確認すべきです。これらを合わせて見ることで、誰が、なぜそのアクセスを申請したのか、そしてビジネス上の必要性が今も有効かどうかが分かります。FireMon Policy Optimizer はレビュー対象の各ルールについてこうしたコンテキストを集約するため、エンジニアの記憶ではなく記録された根拠に基づいて判断できます。
一時的なアクセスが恒久化するのは、たいてい誰も見直さないからです。アプリケーションが廃止され、ユーザーの役割が変わり、インフラが移行し、取引関係が終了しても、ルールはそのまま残ります。定期的な再認証は、維持か削除かの判断を記録として残すことを必須にすることでこの問題を解消します。誰も問い直さなかったという理由で役目を終えたアクセスが残ることなく、アクセスはビジネスの変化に合わせて変わります。
FireMon Policy Optimizer は、ファイアウォールルールのレビューを簡素化するために設計されています。セキュリティチームはレビューすべきルールを特定し、各ルールの背景にあるコンテキストを確認し、再認証の判断を記録できます。FireMon はマルチベンダー環境全体のポリシーガバナンス層として機能し、ファイアウォールや Panorama、FortiManager といった各ベンダーのコンソールは、引き続き自社プラットフォームの管理と適用を担います。