ポリシーリスクを可視化。自然な言葉でポリシーに関する疑問を解決します。 デモを申し込む →
Published:
攻撃者にアクセスを許してしまう、よくあるファイアウォールの設定ミス4種
by FireMon
Jody Brazil が FireMon を立ち上げたのは、意図しないアクセスを防ぐためにファイアウォールポリシーの変更を記録する必要に迫られたからでした。それから20年以上が経過した現在も、ポリシーに起因する同種のファイアウォールの設定ミスは依然として広く見られます。とりわけ、複雑さを増し、時には不十分でもある今日のサイバーセキュリティ体制においては顕著です。
「問題の原因であるかどうかにかかわらず、障害が発生するとファイアウォールが疑われることがよくあります」と、FireMon の Technology Alliances 担当バイスプレジデントである Tim Woods は述べています。実際にファイアウォールに原因がある場合、その多くは攻撃者に意図しないアクセスを与えてしまう設定ミスです。
「攻撃者は自動化を用いてインターネットをスキャンし、設定ミスを継続的に探索しています」と Woods は述べています。「攻撃者は、容易な侵入経路となる過度に許可的なルールを狙っているのです」
従業員への新しいアプリケーションの展開など、業務上妥当な目的でアクセスを許可するために、ルールが一時的に制限なしの状態、いわば「開放」された状態になることは少なくありません。管理者は、そのアプリケーションに権限を与えるためにファイアウォールの制限を緩めることがあります。
「後で戻ってそのルールを厳格化するつもりではいます」と Woods は述べています。「問題は、他に15件もの優先事項が発生し、そのルールの修正に戻らないことです」
一見すべてが正常に機能しているように見えますが、管理者は攻撃者に悪用される余地を残してしまっているのです。
よくあるファイアウォールの設定ミス4種
Woods は、過度に許可的な環境を招きかねない4種類のファイアウォール設定ミスについて詳しく説明してくれました。
1. ハードウェアの廃止
たとえば、管理者が特定のマーケティング用サーバー向けにファイアウォールのアクセスルールを作成し、その後そのサーバーが廃止されたとします。しかし、不要になった関連のアクセスルールを削除し忘れてしまいました。その結果、ルールは放置されたまま残ります。1か月後、同僚がその旧サーバーの IP を再利用して新しいデバイスを立ち上げると、放置されていたルールが「復活」し、最終的に意図しないリソースへの不用意なネットワークアクセスを許してしまいます。
2. 重複ルール
重複ルールとは、その名の通り、既存の論理的なアクセス経路と重複するルールです。ただちに深刻な問題を引き起こすわけではありませんが、時間の経過とともに重複ルールが蓄積すると、セキュリティ実施ポリシーに不要な複雑さをもたらします。
3. シャドウ化されたファイアウォールルール
シャドウルールは重複ルールに似ていますが、逆の動作を定義する点が異なります。つまり、アクセスを許可するルールと拒否するルールが併存している状態です。セキュリティポリシーを手作業で確認するファイアウォール管理者は、ポリシーの実際の挙動を誤って解釈する可能性があります。拒否ルールは目に入っても、その上位にある許可ルールを見落としてしまうのです。結果として、「シャドウ化された」ルールは認識されないままとなります。
「これは技術的な誤りです」と Woods は述べています。「ルールが重なり合うこともあれば、ルールが最下部に埋もれたままになることもあります」管理者はポリシー内のどこにルールを配置すべきか分からず、上位で類似または矛盾するルールが使われていることに気づかないまま、とりあえず最下部に置いてしまうことがある、と Woods は説明します。その結果、ポリシールールの挙動は誤解されやすくなります。
4. ポリシーの肥大化
「大企業では、ファイアウォールポリシーの30-40%が使われていないという状況は珍しくありません」と Woods は述べています。
20年前には200-300行だったルールが、今日のポリシーでは10,000行から100,000行に達することもあります。これにファイアウォールの総数を掛け合わせると、ルールの総量は手に負えないものになります。ポリシーの肥大化の多くは、未使用ルール、重複ルール、シャドウルール、過度に許可的なルールの積み重ねによるものです。この肥大化は、セキュリティ実施ポリシー全体の健全性を損ないます。
セキュリティチームのサイロ化が設定ミスを招く
上記の理由に加えて、近年はセキュリティ責任の分散化が進み、組織がセキュリティの focus を一元的に維持できなくなっていることも背景にあります。
かつてはすべての制御を管理する中央のセキュリティチームが存在しましたが、現在ではアプリケーション、ワークロード、リソースの立ち上げに際して、事業部門の責任者、ステークホルダー、devops、セキュリティクラウドチーム、IT セキュリティがそれぞれセキュリティ制御の導入を担っています。今日の大規模な「ハイブリッドエンタープライズ」環境では、セキュリティ責任の所在がグレーゾーンになりがちだと Woods は述べています。
「もはや全員が同じ楽譜を見て演奏している状態ではありません」と Woods は述べています。「そして、こうしたサイロ化、すなわち生じてしまった分断がセキュリティギャップを生み出すのです」
時間の経過とともに、複雑性のギャップは拡大していきます。ルールの量が増えるにつれ、未使用ルール、冗長なルール、過度に許可的なルールも増加します。
そのギャップが広がるほど、人的ミスが入り込む確率は高まり、設定ミスが発生してシステムに影響を及ぼす確率も高まると Woods は述べています。
自動化されたセキュリティポリシー管理による設定ミスの解決
設定ミスの問題を未然に防ぐために、Woods はすべてのファイアウォールポリシー変更を特定してラベル付けするネットワークセキュリティポリシー管理ソリューションの活用を推奨しています。
「変更が発生するたびに、答えを出さなければならない問いが一つあります」と Woods は述べています。「その問いとは、『自社のネットワークでたった今起きた変更は、害をもたらすのか。イエスかノーか』というものです」
言い換えれば、そのポリシー変更は組織のセキュリティ体制に悪影響を与えたのか、ということです。複雑さにラベルを付けることが、最終的にはその低減につながると Woods は述べています。変更が発生した時点でそれを分析できれば、可視性が得られます。しかし、膨大な量のアラートに人間の管理者が追いつくことはできません。そこで目的特化型の自動化プラットフォームが役立ちます。変更が発生するたびに、アプリケーションが旧ルールと比較し、変更の記録を作成し、ポリシー全体の文脈の中でそのルールを評価します。
まとめ
ファイアウォールの設定ミスは、さまざまな理由で発生します。FireMon の Tim Woods は、設定ミスのよくある4つの原因を挙げ、さらにこうした設定上の誤りを招きかねないセキュリティ人員体制の複雑さについても背景を説明しました。最後に、ファイアウォールポリシーの設定ミスを解決する手段として、Woods はすべてのファイアウォールポリシー変更の可視化と分析を自動化できる、目的特化型のネットワークセキュリティポリシー管理プラットフォームを推奨しました。こうしたよくある落とし穴を避けるためのファイアウォールの適切な導入方法については、ファイアウォール導入:ステップバイステップガイドをご覧ください。