ネットワークで語る怖い話

ハロウィンを間近に控え、実際にあったファイアウォールポリシーの恐怖談をご紹介します。（雰囲気を出すために、不気味なしゃがれ声で語られる戒めの物語として、あるいはお好みでMorgan Freemanの声で想像していただいてもかまいません。）

セールスエンジニアとして、私は日々、当社製品のデモを行い、セキュリティエンジニア、コンプライアンス担当者、DevOpsマネージャー、CISOの方々とファイアウォールやネットワークセキュリティについて話をしています。現場の最前線にいる方々の話は、信じがたいものもあれば、まさに恐ろしいものもあります。ここでは、あらゆるファイアウォールエンジニアを夜も眠れなくさせる、あるお客様の最近の話をご紹介します。

シナリオ:
その企業は最近「ゼロトラスト」の考え方を採用し、その目標に近づくために多大な時間を投じてきました。この1年間、彼らが注力してきたのは、ファイアウォールポリシーの整理であり、ビジネス上の必要性に即したルール、つまりアクセスを必要とする特定のIPとネットワークだけを記述し、それ以上は一切許可しないという方針でした。作業は順調に進んでいましたが、あるエンジニアが恐ろしい発見をします。ポリシーの中ほどに埋もれていた、忌まわしい「Any - Any - Any - Accept」ルールです。

チームはこのルールが存在する理由を突き止めようと奔走しました。最終的に判明したのは、若手のネットワークエンジニアが、とにかく動かそうとしてこのルールを作成していたということでした。このたった1つのルールが、ゼロトラストの目標に向けて積み上げてきた成果をすべて無効にし、ネットワークを甚大なリスクにさらしていたのです。

当然、このルールは削除しなければなりません。しかし、このルールは少なくとも6か月間、検知されないままポリシーに存在し、確実にビジネスクリティカルなトラフィックを許可していました。実際、ログのトラフィックからは、このルールが極めて頻繁に使用されていることが示されていました。もちろん、ビジネスクリティカルなトラフィック以外も許可していた可能性が高く、悪意のあるトラフィックも通していたと考えられます。彼らはこの問題を迅速に是正する必要がありました。

まず、ネットワーク担当者との会議を開き、どのようなトラフィックが該当し得るかを推測し、ネットワークに詳しい人々がこのルールを使用している可能性があると考える重要なアプリケーションやトラフィックを洗い出しました。しかし最終的には、意を決してルールを削除し、誰が悲鳴を上げるかを見るしかないという結論に至りました。

そこで彼らは、この誤りについて全事業部門のマネージャーに通知しました。きまりの悪い思いをしながら、オペレーターが待機する「ホットライン」を設置すると伝え、最終的には、製品、アプリケーション、業務遂行に必要なもの、顧客・パートナー・ベンダーとの取引に必要なものが、体制を整えるまでの間だけ停止するにとどまるよう、担当者にビジネスクリティカルな機能をすべてテストさせることになりました。実際に停止は発生しましたし、問題を是正する新しいルールを作成できる体制も整えていましたが、それにしても悪夢のような事態でした。

—

上記のような悪夢のような状況には陥っていないとしても、FireMonはファイアウォールポリシーの整理を支援することで、皆様の業務をより容易にできます。ここでは、FireMonが上記のシナリオを防ぎ得た方法をいくつかご紹介します。また、ポリシー内に過度に緩いルールを発見された場合は、下記6番の、痛みを伴わない解決策をぜひご確認ください。

1) コンプライアンスのアラートとレポート:
このような過度に緩いルールが有効になった場合、当社は直ちにチームに通知します。ルールの許容範囲は、「60,000を超える宛先へのアクセスを許可するルール」や「/16より大きいネットワークを送信元とするルール」といった形で、基本的に「ダイヤルを設定する」ように調整できます。

2) 変更アラート:
このルールは、ファイアウォールベンダーを問わず、当社の正規化されたビューに表示され、追加されたことが一目でわかります。したがって「こっそり紛れ込ませる」ことはできません。エンジニアやマネージャーの中には、変更が行われるたびに自動でポリシー変更レポートをメールで受け取る方や、変更内容の30日間のスナップショットだけを受け取る方もいます。

3) 当社の自動化ツールであるFireMon Policy Plannerを導入していれば、このリスクの高いルールは、プッシュされる前にその場で阻止されていたはずです。当社の「変更前分析」により、本番環境にプッシュされ、1パケットでも通過させる前に、このルールは特定され、フラグが立てられていたでしょう。だからこそコンプライアンス担当者は、当社が必要性に基づいてルールの作成を推奨するだけでなく、サンドボックス環境のように、ルールを自動的にプッシュする前にコンプライアンスアルゴリズムを実行する点を高く評価しています。この機能だけを目的にPolicy Plannerを導入し、当社のAPIを介して利用しているお客様もいます。

4) 同じく変更アラートにより、チームは誰がいつどの変更を行ったかを確実に把握できます。したがってこのケースでは、若手エンジニアによる変更であったため、マネージャーやリーダーは、そのユーザーが過去1週間、少なくとも1か月間に行った変更を素早くフィルタリング/ソートし、どのような種類の変更を行っていたかを確認できたはずです。これはコンプライアンスチーム、さらにはユーザー本人でも確認できる内容です。

5) ドキュメンテーションの観点では、FireMonは「誰が申請したのか、アプリケーションのオーナーは誰か、このルールが最後にレビューされたのはいつか」といった情報の単一の信頼できる情報源となり得ます。したがって、ルールのドキュメントを用いてルールをフィルタリング・ソートすることで、この問題ももっと早く特定できたはずです。

6) 最良のものを最後に取っておきました。過度に緩いルールが存在する場合、たとえば前任者が現在とは異なる、より「オープンで柔軟なルール作成スタイル」の方針を取っていた場合でも、当社にはこうしたルールを簡単に整理する方法があります。トラフィックフロー分析を使用すると、当社のツールがルールを通過するすべてのIPアドレスを確認し、any/any/anyを個々のフローに分解します。これらのフローをエクスポートし、それに基づいて具体的なルールを作成できます。