ファイアウォールの実践的な歴史 – 第2回：管理の価値

Jody Brazil FireMon CEO Check Point とステートフルインスペクション型ファイアウォールは、プロキシ型ファイアウォールとの初期の戦いに勝利しました（第1回：黎明期）。それはすべてインスペクション技術によるものだと考えるのは容易ですが、それでは Check Point のソリューションにおける重要な革新、すなわちポリシー管理を見落とすことになります。90年代半ばにステートフルインスペクション型ファイアウォールがプロキシ型の競合に勝った要因の大部分は、管理のしやすさにありました。本記事の多くは Check Point に焦点を当てています。これは主に、90年代後半から2000年代初頭のファイアウォール市場において Check Point が支配的な役割を果たしていたためです。ただし、当時私が Check Point に多く触れていたことも理由でしょう。皆様のご見解を歓迎し、コメントをお待ちしております。90年代半ばは、ネットワークが急速に進化していた時代でした。たとえば、イーサネットは選択肢の一つではあったものの、常にローカルネットワークプロトコルとして使われていたわけではありません（トークンリングを覚えていますか）。インターネットへの接続は前提ではなく、検討事項でした。ダイヤルアップはまだ一般的で、AOL が支配的な存在でした。ファイアウォールが主流技術だったと言うのは、インターネットが主流だったという誤解に基づくものです。この急速に変化するネットワークがもたらした影響の一つが、知識と経験の著しい不足でした。この文脈において、ファイアウォールの管理性は、この市場で最終的に勝者となる要因を左右する重要な市場推進力として見過ごすべきではありません。今日のソフトウェア開発では、ユーザーエクスペリエンスやユーザビリティが話題になります。当時それらは流行語ではありませんでしたが、今日それらが語られる理由は、当時も同じくらい重要でした。顧客はその製品を「気に入って」いたのです。したがって、セキュリティと性能が重要であった一方で、Check Point のファイアウォール GUI の使いやすさも軽視すべきではありません。当時の Gauntlet の営業担当者の言葉を借りれば、「見込み客が誰であろうと関係なかった。どの案件に入っても Check Point の GUI と戦わねばならず、たいてい負けた」のです。Check Point は、中央管理と非常に革新的なユーザーインターフェイスを備えたファイアウォールを世に出しました。主な機能には次のようなものがありました。

• グラフィカルなルールエディタ
• ファイアウォールポリシー間で共有される中央オブジェクトリポジトリ
• 中央ログ管理
• マルチドメイン管理と OPSEC

Check Point のポリシーエディタ

ファイアウォールのルールが、送信元、宛先、プロトコル、ポート（プロトコルとポートはサービスと呼ばれる単一のオブジェクトにまとめられていました）、アクションの5要素で構成されるという概念は、Check Point のポリシーエディタよりはるか以前から存在していました。80年代の初期のアクセスコントロールリストもこの概念に対応していました。しかし Check Point は、グラフィカルなルールエディタによってパラダイムを変えました。ルールを作成するために CLI の構文を知る必要はもはやなくなりました。マウスと数回のクリックだけで済んだのです。さらにルール編集には、コピー＆ペースト、ユーザー定義のコメント、1列あたり複数オブジェクトといった便利な機能が加わりました。この1列あたり複数オブジェクトという点は画期的でした。それまでのアクセスコントロールリストは、各列に単一の送信元、単一の宛先、単一のサービスしか指定できませんでした。複数オブジェクトへの対応により各ルールはより強力になり、ポリシー編集は新しいルールを作成するのではなく既存のルールを修正する作業になることが多くなりました。このポリシーエディタの多くは、もう一つの進歩である中央オブジェクトリポジトリを前提としていました。

Check Point の中央オブジェクトリポジトリ

従来、アクセスコントロールリストは送信元や宛先として特定の IP アドレスを参照して作成されていました。これは機能はしましたが、システムの IP が変わると、すべてのルールを更新する必要がありました。再利用可能なソースコードと同様に、Check Point は中央オブジェクトリポジトリを作成し、そのオブジェクトをルールで使用する方がよい戦略だと気づきました。これにより、ホストの IP が変更されても更新が必要なのはオブジェクトだけとなり、ポリシーは保存されたオブジェクトへの参照を使用しているため、その更新が自動的に正しく反映されるようになりました。さらに、これらのオブジェクトのグループ（およびグループのグループ）を作成し、共通のオブジェクトグループをポリシー全体で再利用することも可能になりました。これらは、より効果的なポリシー管理に向けた大きな進歩でした。

中央ログ管理

ファイアウォールで極めてよくある問題は、誤ったトラフィックを遮断してしまうことです。特に、それまでセグメント化されていなかった2つのネットワークの間にファイアウォールを設置する場合であり、90年代後半にはほぼすべての新規ファイアウォール導入がこれに該当しました。すべてのファイアウォールログを中央に集約し、容易に検索できるようにしたことで、ポリシーの誤りの診断は非常に明快かつ比較的簡単になりました。ユーザーが問題を報告し、送信元 IP と宛先 IP の組み合わせを提示すれば、管理者はログビューアで「drop」のログと、その遮断を引き起こしたルールを見つけることができました（あるいは「accept」のログを見つけて、ユーザーの指摘が誤りであると伝えることもできました）。ファイアウォールポリシーの管理において誤りは当時も今もよく起こるため、トラブルシューティングの容易さはあらゆるファイアウォールプラットフォームにとって重要な付加価値でした。

マルチドメイン管理と OPSEC

2000年代初頭、Check Point は Provider-1 によるマルチドメイン管理と OPSEC による統合 API を導入し、管理の力にさらに大きく賭けました。いずれも、Check Point を他のファイアウォール競合と差別化する管理の力への大きな賭けであり、それは功を奏しました。Provider-1 はその名が示すとおり、プロバイダー業界、通信事業者、マネージドサービスプロバイダーを対象としていました。プロバイダーがこの技術の早期採用者であった一方で、企業もすぐにこの製品を利用する理由を見出しました。権限制御、大規模なポリシーとオブジェクトデータベースを分割することによる管理性と UI 性能の向上、グローバルに適用・強制できるグローバルルールといった主要機能は、いずれも大企業が求めていた重要な機能でした。これらの多くは、標準の管理プラットフォームにおける制約でもありました。Check Point は顧客に Provider-1 の高額な追加費用を求めるのではなく管理プラットフォーム自体を改善すべきだったという意見もあり得ますが、顧客はその利点を認め、こうした高度な管理機能に対価を払う用意がありました。OPSEC は、サードパーティ製品との統合を促進するために Check Point がリリースしたパートナープログラムと API 群です。初期の成功例としては、Log Export API（LEA）を利用したレポート製品、URL Filtering Protocol（UFP）を利用した URL フィルタリング製品、Check Point Management Interface（CPMI）を利用した FireMon などの管理製品が挙げられます。このプログラムと統合は大きな成功を収めました。今日では、100社をはるかに超える OPSEC パートナーが同プラットフォームとの何らかの統合機能を提供しています。このセキュリティ製品のエコシステムは、顧客に付加価値と投資への確信をもたらします。今日では API 統合は当たり前のものとなっていますが、OPSEC が発表された2001年当時、それは決して一般的ではありませんでした。

Cisco と CLI も有力な存在だった

市場が Check Point と GUI によって完全に支配されていたわけではありません。Check Point が強力で使いやすい GUI によってファイアウォール市場のリーダーとしての地位を確立する一方、Cisco は Pix においてコマンドラインインターフェイス（CLI）というその原点に忠実であり続けました。Pix はファイアウォール市場における初期の競合製品で、1994年に遡り、1995年に Cisco が買収しました。ネットワーク管理者にとって Cisco と CLI が馴染み深かったことから、ネットワークチームがセキュリティを担当している場合には Pix が好んで選ばれました。Check Point は、セキュリティ機能と GUI によってこの優位を切り崩していき、さらに企業の組織構造がゆるやかに変化してセキュリティがネットワークチームとは別のグループになっていったことがそれを後押ししました。この変化が進むにつれ、Cisco がネットワークチームとの間に築いていた既存の関係は、ファイアウォールベンダー選定において果たす役割を小さくしていきました。強化された管理機能は、Check Point の市場での地位確立に寄与し、セキュリティ製品における管理の価値を裏付けました。しかし、90年代に性能が Check Point のプロキシに対する勝利を助けたのと同じように、その後の年月において性能は再び重要な選定基準となり、今度は Check Point が脅かされることになります。第3回：性能が主役になる