ポリシーリスクを可視化。自然な言葉でポリシーに関する疑問を解決します。 デモを申し込む →
Published:
一時的なアクセスを恒久的なファイアウォールポリシーにしてはならない
一時的なファイアウォールアクセスが本来の目的を終えた後も残り続ける理由と、オーナー、申請理由、有効期限、レビューによって期限付きルールを統制する方法を解説します。
by FireMon
一時的なアクセスは、いつの間にか恒久的なものになりがちです。
プロジェクト、ベンダー対応、移行、緊急の要求のためにルールが作成されます。作成時点では、なぜそのルールが存在するのかを誰もが把握しています。しかし数か月後には、その背景情報を見つけ出すことは難しくなります。
誰が申請したのか。誰が承認したのか。どのようなビジネス上の必要性に基づくものか。そのアクセスは今も必要なのか。
こうした情報がなければ、技術的には妥当なファイアウォールルールであっても、評価は困難になります。
だからこそ、実効性のあるポリシー管理では、ルールが何を許可しているかを把握するだけでは不十分です。チームはさらに、 そのルールがなぜ存在し、誰が責任を負っているのかを把握する必要があります。
判断が新しいうちにコンテキストを記録する
上記の動画では、FireMonでグローバルフィールドエンジニアリングを統括するシニアディレクター、Rob Rodriguezが、ファイアウォールルールの背景にあるビジネスコンテキストをSecurity Manager上で直接文書化する方法を紹介しています。
このコンテキストには、たとえば次のような情報を含められます。
- ビジネス上の正当性
- 事業部門
- ルールのオーナー
- 申請者と承認者
- 変更管理情報
- 次回レビュー日
- 有効期限
Robが示す例には「Temp Access」というラベルが付いており、ポリシー管理によくある問題を浮き彫りにしています。
一時的なアクセスが必要になることはあります。リスクが生じるのは、そのアクセスをいつ終了すべきかを判断する明確な仕組みがない場合です。
有効期限やレビュー予定日を設定すれば、チェックポイントが生まれます。数か月後に当初の申請内容を誰かが覚えていることに頼るのではなく、判断を見直すために必要な情報をポリシー自体が保持することになります。
ルールを後から評価しやすくする
技術的な設定が示すのは、そのファイアウォールルールが何をするのかです。
ドキュメントが示すのは、そのルールがなぜ存在するのかです。
この違いは、環境が拡大し、チームの顔ぶれが変わるほど重要になります。
作成から6か月後にそのルールをレビューするエンジニアは、当初の申請に関与していないかもしれません。アプリケーションのオーナーは異動しているかもしれません。プロジェクトはすでに終了しているかもしれません。ベンダーとの取引も続いていないかもしれません。
オーナーとビジネス上の正当性が分からなければ、チームはそのアクセスが今も妥当かどうかを判断する前に、ルールの経緯を一から洗い出さざるを得ません。
こうした情報を最初に記録しておけば、将来のレビューははるかに容易になります。
「このルールが何のためのものか分かる人はいますか」と尋ねるのではなく、実務担当者は文書化された目的、オーナー、レビュー時期を出発点にできます。
一時的なアクセスには終了日を設定する
一時的なルールには特に注意が必要です。本来の目的が、特定の事象や期間に結び付いていることが多いためです。
メンテナンスウィンドウ、移行、テスト期間、サードパーティとの契約、短期的な業務要件などが該当します。
有効期限やレビュープロセスを設けずにルールを作成すると、当初の必要性がなくなった後も長期にわたってアクセスが残り続ける可能性があります。
望ましいプロセスは、技術的なルールをビジネス上のライフサイクルと結び付けます。
アクセスにオーナー、正当性、レビュー日が設定されていれば、そのアクセスを維持すべきかどうかを問う明確な根拠が得られます。
これは、期日が来たすべての一時的なルールを自動的に削除するという意味ではありません。既定のままアクセスが無期限に継続することを避け、意図的なレビューの機会を設けるということです。
ファイアウォールルールをガバナンスされた意思決定へ
ルールを単なる設定オブジェクトではなくビジネス上の意思決定として扱えば、ファイアウォールポリシーの管理は容易になります。
FireMonは、技術的なポリシーと、そのアクセスを継続的に管理するために必要なオーナー、正当性、レビュー情報とを結び付けることを支援します。
その結果、アクセスが存在する理由がより明確に記録され、それが今も必要かどうかを判断する現実的な手段が得られます。
問われているのは、そのルールが今日機能するかどうかだけではありません。明日もなお、組織がそのアクセスを理解し、責任を持ち、必要としているかどうかです。
ファイアウォールポリシー管理にビジネスコンテキストを取り入れましょう。 FireMon Security Manager が、複雑な環境全体でセキュリティポリシーの把握、文書化、ガバナンスをどのように支援するのかをご覧ください。
よくあるご質問
オーナー、ビジネス上の正当性、有効期限、レビュー日を定めずにルールを作成すると、一時的なファイアウォールアクセスは恒久的なものになります。作成時点では、なぜそのルールが存在するのかを誰もが把握しています。しかし数か月後には、申請者は異動し、プロジェクトも終了しているかもしれません。そのアクセスが今も必要かどうかを誰も答えられなければ、ルールは既定のまま残り続けます。
一時的なアクセスが残り続けると、技術的には妥当なファイアウォールルールであっても評価が難しくなります。何を許可しているかは分かっても、なぜ存在するのか、誰が責任を負っているのかが分からないため、当初の必要性がなくなった後も長くアクセスが残る可能性があります。レビュー担当者は、そのアクセスが今も妥当かどうかを判断する前に、ルールの経緯を一から洗い出さなければなりません。
一時的なファイアウォールアクセスは通常、特定の事象や期間のために設定されます。よくある例としては、プロジェクト、メンテナンスウィンドウ、移行、テスト期間、サードパーティやベンダーとの契約、緊急の要求、短期的な業務要件などが挙げられます。必要性がその事象に結び付いている以上、ルールのライフサイクルもレビュー日や終了日によって同様に結び付けるべきです。
ビジネス上の正当性、事業部門、ルールのオーナー、申請者と承認者、変更管理情報、次回レビュー日、有効期限を記録してください。判断が新しいうちに記録しておけば、将来のレビュー担当者は経緯を一から洗い出すのではなく、文書化された目的とオーナーを出発点にできます。FireMon Security Managerでは、こうしたビジネスコンテキストをファイアウォールルール上に直接記録できます。
有効期限やレビュー予定日は、当初の申請を誰かが覚えていることに依存しないチェックポイントとなります。期日が来たとき、ルールのオーナーと正当性が、そのアクセスを維持するのか、変更するのか、削除するのかを判断する明確な根拠になります。このチェックポイントがなければ、一時的なアクセスは既定のまま無期限に継続しがちです。
必ずしもそうではありません。FireMonが推奨するのは、有効期限を自動削除のトリガーではなく、意図的なレビューの機会として扱うことです。正当に必要とされているアクセスもあり、確認せずに削除すれば業務に支障が出る恐れがあります。目的は、誰も確認しないまま継続させるのではなく、すべての一時的なルールについて明示的な判断を下すことです。
まず次の4点を確認してください。このルールは誰が申請したのか。誰が承認したのか。どのようなビジネス上の必要性に基づくものか。その必要性は今も存在するのか。次に、オーナー、アプリケーション、プロジェクト、ベンダーとの関係に変化がないかを確認します。ルールに正当性、オーナー、レビュー日が記録されていれば、「このルールが何のためのものか分かる人はいますか」と尋ねることなく、迅速に答えを出せます。
正当性、事業部門、オーナー、申請者と承認者、変更管理情報、レビュー日、有効期限といったビジネスコンテキストを各ルールに紐付けられるソリューションを選んでください。ルールを単なる設定オブジェクトではなく、ライフサイクルを持つガバナンス対象のビジネス上の意思決定として扱えることが重要です。FireMon Security Managerは、こうしたコンテキストをファイアウォールルール上に記録できるため、明確な記録に基づいて一時的なアクセスを見直せます。