この記事は、シスコ セキュリティ ビジネス グループのプリンシパル エンジニアある Andrew Ossipov によるブログ「Security Multi-Tenancy Part 1: Defining the Problem」
（2018/7/17）の抄訳です。
事実上の仮想ファイアウォール
現在、誰もがネットワーク機能の仮想化について語る機会が増えています。ほとんどのセキュリティベンダーは、いくつかの一般的なハイパーバイザ上で稼働するファイアウォール製品を構築しています。ただし、「仮想ファイアウォール」という用語は、仮想化が今のように流行する前からあるものです。多くのファイアウォール管理者は、単一の物理セキュリティアプライアンス内に複数の仮想パーティションまたはコンテキストを作成する機能の説明としてこの用語を使用しています。これらの仮想ファイアウォールは、それぞれ独自の設定、ステートフルコネクションテーブル、管理機能を備えています。ただしそれらは、皆さんが考えているほど、独立/分離したものではありません。これについては、後で詳しく説明します。Cisco 適応型セキュリティアプライアンス（ASA）ソフトウェアが、以前からマルチコンテキストモードによる仮想ファイアウォールをサポートしていたにもかかわらず、シスコは、仮想ファイアウォールを正しく理解するために、脅威防御を中心とした Firepower Threat Defense（FTD）製品に同様の機能を導入するのを、あえて遅らせました。優れたエンジニアが言うように、適切なソリューションは、問題を完全に理解するところから始まります。つまり、シスコのセキュリティ製品のお客様がなんのために仮想ファイアウォールを導入するのかを理解する必要があります。
使用例を理解する
すべてのお客様が、複数のセキュリティ コンテキストをマルチテナントに導入しているわけではありません。あるお客様は、ルーティングテーブルを分離しようとしています。その場合、仮想ファイアウォールに求められるのは、Virtual Routing and Forwarding（VRF）ドメインを分離することです。この機能は、IP 空間が重複している複数の内部組織を保護しようとする場合に特に便利です。その他のファイアウォール管理者は、マルチコンテキストモードを活用して、異なるドメイン間でポリシー管理を分離してシンプルにしようとしています。単一のフラットなポリシーにするのではなく、各ネットワークセグメントに応じて小さな塊に分割します。この場合、管理を分離することも含まれ、各セキュリティコンテキストの管理は、各組織に委ねられます。一般的な例としては、大規模な大学が挙げられます。そこでは、複数の部門がエクストラネットのエッジで 1つの物理アプライアンスを共有しながらそれぞれのネットワークを管理して、個別の仮想ファイアウォールを設定しています。また別のお客様では、さらに踏み込んで、異なるテナント間、またはネットワークセグメント間で、トラフィックの処理を完全に分離することを求めています。たとえば、1つの典型的な例として、実稼働環境のアプリケーションが、ラボ環境のトラフィックの影響を受けないようにしたい場合があります。これらの要件を理解できれば、ほとんどの既存ファイアウォール マルチテナントソリューションの課題が明確になります。
実現性の確認
仮想ファイアウォールを導入する際に検討する必要がある、運用上の考慮事項がいくつかあります。単一アプライアンス上のすべてのセキュリティコンテキストは、同じソフトウェアイメージを実行するため、テナントを限定してアップグレードのテストをすることはできません。同様に、稼働も停止も同時で、1つのテナントだけ再起動することはできません。機能に関しては、仮想ファイアウォールモードでサポートされていないものを把握しておく必要があります。ほとんどの場合、これまでにすでに導入を進めた際に、これらの難しい問題に気づくことになります。でも、ちょっと待ってください。まだ続きがあります。
確かに仮想ファイアウォールを使用して、ルーティングまたはポリシードメインを分離することはできますが、必要以上に複雑になります。ファイアウォールコンテキストを作成し、各種のインターフェイスを割り当てて、それらをすべて別々に設定する必要があります。さらに、ポリシーや他の関連の設定を管理するためには、ドメインを交互に切り替えられるようにする必要もあります。すべてのコンテキストで単一のアクセス ポリシーが必要な場合は、各仮想ファイアウォールで別々にプログラミングしなければなりません。幸いにも、VRFなどの機能によって、ルーティングドメインだけを分離することで、マルチコンテキストモードを回避することができます。ポリシーのシンプル化に関しては、複数の仮想ファイアウォールを管理するのは非常に煩雑なため、1 つのセキュリティ コンテキストに再度統合し、セキュリティ グループ タグ（SGT）を利用した方が、ルールセットを大幅に削減できることに気づいているお客様もいます。テナントを完全に分離することが本当に必要な場合以外は、仮想ファイアウォールを導入することは、ほとんど意味がありません。
管理の分離に関しては、マルチコンテキスト モードは最適なソリューションのように思われます。結局、各テナントが独自のファイアウォールを備えることで、すべてのテナントが他のテナントに影響を与えることなく運用されるからです。しかし、本当にそうでしょうか。各仮想ファイアウォールがそれぞれ独立した設定になっていたとしても、すべて、共有物理デバイス上の単一のセキュリティ アプリケーション内で動作することになります。それはつまり、ほとんどの導入において、管理プレーンがすべての仮想コンテキストで共有されることを意味します。1 つのテナントがポリシーを大きく変えたり、常に接続情報をポーリングしたりしていれば、同じデバイス上で稼働している他のすべての仮想ファイアウォールに必然的に影響を与えることになります。ただし、本当の問題は、共有データ プレーンにあります。
分離されていると認識されていても、結局すべての仮想ファイアウォールは、CPU、メモリ、内部のバックプレーン リソースを共有しています。各セキュリティ コンテキストに別々の物理インターフェイスを割り当てた場合でも、通常すべてのトラフィックは、CPU の入力分類機能で統合されます。コンテキストごとにルーティング テーブルやコネクション テーブルの最大サイズを設定できたとしても、ネットワーク トラフィックの量や、特定のテナントが利用する CPU リソースを制限できるわけではありません。パケットを特定の仮想ファイアウォールに分類するためには、システムは、最初に分類処理を実施するために CPU サイクルを使用する必要があります。特定のテナントがネットワークから大量のトラフィックを受信した場合、後でレート リミッタによってドロップされるとしても、そのトラフィックによってシステムの CPU リソースが過度に消費される可能性があります。そのため、1 つ仮想ファイアウォールが多くのリソースを使用して、同じシステム上の他のセキュリティ コンテキストに影響を与えることがないとは言い切れません。私は、ファイアウォールの管理者が、このようなシンプルな警告をまったく認識していなかったケースを数多く見てきました。これは特定のベンダーに関する問題ではなく、現在どれほど多くの仮想ファイアウォールが導入されているか、という問題なのです。
コンテキストを離れて考える
使用例を見て、既存の仮想ファイアウォールの導入に関する課題を分析したところで、FTD にマルチテナントを導入するアプローチを根本的に変える必要があることを認識しました。理想的なソリューションは、管理とトラフィックの処理をすべてのテナントで完全に分離し、1 つの仮想ファイアウォールが同じシステム上の他のテナントにまったく影響を与えないようにすることです。この場合、ソフトウェアのアップグレードやリロードも分離する必要があります。また、仮想ファイアウォールが導入された時点で、利用できるすべての FTD 機能は、常にサポートされる必要があります。それによって、エンドユーザ エクスペリエンスがシンプルになるだけでなく、開発とテストに要する期間が大幅に短縮されます。
これらの要件は実現不可能なように思われたかもしれませんが、私には、お客様のためにそれらの要件を実現する、本当にすばらしいアイデアがありました。この新しいアプローチは、シスコの Firepower プラットフォームのマルチサービス機能をベースに、アプリケーション コンテナ化の開発トレンドを利用して構築されています。このソリューションは、あと数ヵ月で完成する予定ですので、今後の私のブログで最新情報をチェックしてください。
Authors