マイクロセグメンテーション環境におけるNGFW機能の使用の探求

ほぼ20年間、 次世代ファイアウォール(NGFW) は不可欠なセキュリティツールでした。しかし、今日のネットワークがますます複雑になるにつれて、NGFWによって提供される境界保護は、ますます関連性が低くなっている問題を解決します。

イルミオは、 マイクロセグメンテーション 環境にNGFW機能を実装する可能性を研究しており、2つのテクノロジーを組み合わせて複雑なネットワークに必要な種類のセキュリティを提供します。

パート 1 では、次世代ファイアウォール (NGFW) の歴史、価値、課題について概説しました。

この 2 番目の記事では、NGFW 機能のサブセットをマイクロセグメンテーション ソリューションに埋め込むという「もしも」のシナリオについて説明します。さまざまなユースケースと、それぞれに適したNGFW機能について説明します。

NGFW は南北の交通で機能しますが、東西の交通では苦戦します

NGFWは、ネットワークの境界を保護するという考えを中心に設計され、主に着信トラフィックの脅威から保護することを中心に設計されました。ネットワークの世界では、このタイプのトラフィックは「ノースサウス」と呼ばれることがよくあります。この用語は、インターネットの「バブル」を上部に置き、データセンターに流入するトラフィックが上から下へ、または北から南に移動するネットワークを描画するという広範な慣行に由来しています。データセンター内のトラフィックは通常、左から右、または右から左に横方向に移動するように描画されるため、「東西」と呼ばれることがよくあります。

この用語を使用すると、パート 1 で説明したように、南北の役割で使用される NGFW には強力なユースケースがあると言えます。しかし、East-Westのユースケースは少し確実ではありません。この 2 番目の発言はおそらく首の後ろに毛が生えたので、その発言についてもう少し具体的に説明しましょう。

ファイアウォールには、ハードウェア、メンテナンス/サポート、構成/監視の 3 種類の費用がかかります。3つのカテゴリーすべてでコストが高いにもかかわらず、NGFWのROIは南北のユースケースでかなり明確です。東西に関しては、完全な NGFW 機能のサブセットのみが関連していることがわかりますが、ベンダーは完全な機能セットを使用しないことに対して割引を提供しません。NGFWアプライアンスを完全に購入し、機能の半分しか使用しないことを正当化することはしばしば困難であり、NGFW機能セットが法律や規制で義務付けられていない場合はなおさらです。

南北交通用のNGFW

これはNGFWの優れたユースケースの2つですが、実際には、通りすがりを除いて、人々がめったに考慮しない3番目のユースケースがあります:南-北のユースケース、または英語で言えば、ネットワーク内からのアウトバウンドトラフィックを制御します。NGFWのベンダーはそれについて話しますが、ほんの少しだけです。そして、ほとんどの組織は、無制限のアウトバウンド接続の脅威を認識していますが、実際にそれに対処するためにほとんど行動していません。長年にわたって多くのお客様と仕事をしてきた中で、ほとんどの組織には、社内のアプリケーション所有者がネットワーク境界で送信制御を要求するためのプロセスさえ整備されていないことがわかりました。

私の仕事は基本的に研究開発で、「R」の部分に重点を置いています。その流れで、思考実験をしてみましょう。少しの間、南北の問題が解決されたことを考えてみましょう。100%完璧なソリューションがないという意味では解決されていませんが、ほとんどの組織がその経路をネットワークへの攻撃の主な手段とは考えなくなったという意味で解決されています。代わりに、選択したNGFW機能をマイクロセグメンテーションソリューションに実装し、機器を追加購入したり、アウトバウンドNGFW機能を利用できない独自の内部組織プロセスと戦ったりすることなく、東西と南北の両方のNGFW制御を改善できれば、ネットワークの安全性をどのように高めることができるかを考えてみましょう。

南北と東西のユースケースは異なりますが、かなりの重複があります。さらに、多くの南北地物は、これらのどちらにも関連しません。まず、東西のユースケースから始めましょう。

先に述べたように、東西のNGFWコントロールの限られたサブセットのユースケースは確かにあります。本格的なアプライアンス (または仮想アプライアンス) の ROI は、コストを考えると疑わしいかもしれませんが、それでもその必要性は現実的です。ネットワークに PII、HIPPA、または PCI データが含まれている場合、そのデータの保護に関する法律や規制の対象となることはほぼ確実です。多くの場合、これには、DLP(データ損失防止)やIDS/IPS(侵入検知/防止サービス)などの従来のNGFWサービスを実装するための明示的な要件が含まれます。義務がなくても、ベストプラクティスであることに変わりはありません。アプリケーションID、つまり、ポートやプロトコルではなく、実際のトラフィックの種類に基づいてトラフィックをブロックまたは許可する機能も、攻撃やデータ流出を防ぐための強力で望ましいツールです。

南と北のユースケースでは、いくつかの追加機能が役立つ場合があります。DLPはおそらくまだ必要であり、アプリケーションIDはこのユースケースにも同様に役立ちますが、それに加えて、URLフィルタリングと、宛先IPレピュテーションと地理に基づいてトラフィックを制御する機能を追加します。確かに、ボーダー NGFW はすでにこれを行うことができますが、前に指摘したように、ボーダー デバイスが制御下にない場合、アプリケーション所有者がこれらの機能を利用できないことがよくあります。また、大規模なデータセンター環境にあることはめったにありません。

他のNGFWサービスのほとんどは、東西または南北の価値が限られています。DDoS と QoS は、ネットワーク内ではほとんど意味がありません。同様に、OS 内で実行される最新の AV ソフトウェアは、おそらくネットワークベースのソリューションよりも効率的であるため、ネットワークベースのアンチウイルスはおそらく議題にありません。

エンドポイントデバイスでのNGFW機能のパフォーマンス

エンドポイントで実行されるNGFW機能のパフォーマンスへの影響について話します。覚えている方もいらっしゃると思いますが、パート 1 では、NGFW アプライアンスは、立派なパフォーマンスを得るために多くの特殊なハードウェアを備えた、ほぼスーパーコンピューター クラスのシステムであると述べました。明らかに、同じ機能を実装すると、個々のサーバーに大幅なパフォーマンス低下が課せられます。幸いなことに、これは直感が窓の外に出る時期の1つかもしれないようです。その理由について話しましょう。

IDS/IPSは、始めるのに最適な場所です。すべてのNGFWサービスの中で、IDS/IPSは「最も重い」サービスの1つと考えられており、不釣り合いな数のリソースを消費し、NGFWアプライアンスに大量のカスタムシリコンが存在する理由の1つです。IDS/IPS ソリューションで 1,000 のワークロードからなる中規模のデータセンターを保護する場合、おそらく少なくとも 12 の異なるオペレーティング システム (Windows 2008、2012、2016、2019、CentOS、RedHat、Ubuntu の少なくとも半ダースのバリエーションとバージョン (医療や銀行に携わっている場合は Solaris や AIX も含まれる) で IDS/IPS シグネチャをサポートする必要があります。これらの 1,000 台のサーバーはそれぞれ、私が監視したい少なくとも 1 つのサービスを実行しており、おそらくそれぞれに 3 つまたは 4 つの異なるサービスがあり、そのすべてに潜在的な脆弱性があります。また、12 のオペレーティング システムでは、これら 3 つまたは 4 つのサービスごとに 12 の異なるバージョンを実行している可能性があり、それぞれに異なる脆弱性があります。

要するに、私はこれらの10,000台のマシンについて、10,000から100,000の脆弱性シグネチャを監視しています。そして、NGFWネットワークデバイスを流れるすべてのパケット、つまり動作している可能性のあるすべてのポートで、それらの兆候を探しています。これは明らかに、データセンター内のすべてのサーバーに課す負荷ではありません。

実際には、その必要はありません。Linux ホストで Windows の脆弱性を探す理由はありません。NGINX を実行しているマシンで apache2 の脆弱性を探す必要はありません。アプリケーション X バージョン 2.2 を実行しているシステムで、アプリケーション X バージョン 1.0、1.1、1.2、1.3、2.0、2.1 の脆弱性を探す必要はありません。

すべてのパケットで10,000〜100,000の脆弱性を探すのではなく、おそらく4つを探します。4,000人ではありません。4。そして、4つは解決可能な問題です。

どう。すべてのサーバーにエージェントがあるため、OS、適用されたパッチと適用されていないパッチ、インストールされているソフトウェア(およびそのソフトウェアのバージョン)、特に通信するポートを理解するためのフルアクセス権があるからです。検出されたOSやソフトウェアのバージョン、特に関連プロセスがバインドされているポートに固有の脆弱性を探します。検索空間を約4桁減らします。そして、コンピュータサイエンスでは4桁という数字は驚くほど大きい数です。難しいことと簡単なことの違いです。

同様の戦略を DLP や URL フィルタリングなどのサービスにも適用できます。制限された DLP コンテンツについて、すべてのサーバー上のすべてのパケットをフィルタリングしたり、すべてのサーバー上のパブリック アドレスの URL や IP 情報の大規模なデータベースを保持したりする必要はありません。DLP の場合、セグメンテーション ポリシーが適用されるのと同じ方法で、ワークロード ラベルに基づいて、非常に特定のサーバー セット上の特定のコンテンツのみを検索します。URL フィルタリングの場合、IP 特性の大規模なデータベースを中央ポリシー管理システムに保持し、必要に応じて低遅延の LAN 接続を介してフェッチし、後続のルックアップのためにローカルにキャッシュできます。ほとんどのサーバーは、同じ比較的小さなサーバーセットと何度も通信します。

マイクロセグメンテーションソリューションのためのNGFW機能

マイクロセグメンテーションソリューションにNGFW機能を追加する場合、最も得られる利点の1つは、ファイアウォールポリシーと同様に、NGFW機能がグループとしてVLAN全体またはサブネットにではなく、必要な場所に正確に外科的に適用されることです。ラベルベースのポリシーにより、アプリケーション所有者は、データセンターを大まかなブラシで描くのではなく、必要な場所に正確に、非常に特殊なサービスを外科的に適用できます。特定のNGFW機能は、必要なサーバーに対してのみオンにでき、必要な検査を正確に実行します。これにより、オーバーヘッドは特定のセキュリティニーズを満たすために必要な最小限に抑えられ、セキュリティ、パフォーマンス、コストのバランスを取ることができます。

ここでの目的は、ボーダー NGFW デバイスを交換することではないことに注意してください。むしろ、既存のNGFWソリューションがアーキテクチャ上または財務的に意味をなさないギャップを、サーバー自体で実行されるNGFW機能の強力なサブセットで選択的に埋めることです。このアプローチにより、アプリケーション所有者は、他の方法では不可能なアウトバウンドセキュリティを「所有」できるだけでなく、従来のソリューションでは法外なコストがかかる状況でもこれらの機能を提供できます。

今後の展望

これを結びつけるために、さらに未来を見据えましょう。

TLS 1.3 は 2018 年に批准され、暗号化された Web やその他のサービスの次の標準になりつつあります。これに対するあなたの最初の反応は、「私の問題ではない」または「だから何?」かもしれません。私は、それが実際には非常に関連性があると主張します。NGFW は、ディープ パケット インスペクション(DPI)なしでは、利用可能なほとんどのサービスを提供できません。また、DPI が何らかの形で意味を持つためには、データが暗号化されていないクリアテキストである必要があります。

NGFWが最初に市場に出回ったとき、暗号化されたWebトラフィックはごく一部でした。時間が経つにつれて、ますます多くのトラフィックが HTTPS または暗号化されたトラフィックに移行しました。現在、すべてのWebトラフィックのほぼ100%が暗号化されているため、マルウェア、ウイルス、データ流出、またはその他のNGFWサーバーを分析することはできません。このために開発されたソリューションは、TLS MiTM (中間者) と呼ばれます。

TLS MiTM のセットアップは、概念的には簡単ですが、少し面倒です。ソリューションには多くの可動部分があります。まず、組織は内部 TLS 証明書を作成します。公開鍵は組織内のすべてのシステム (ラップトップ、デスクトップ、サーバーなど) にプッシュされ、各オペレーティング システムは、その証明書を信頼し、宛先に関係なくすべての送信通信を暗号化するために使用するように構成されます。その後、秘密鍵は、透過的な Web プロキシとして構成された境界 NGFW デバイスに配布されます。  

ユーザー(またはサーバーまたはその他のデバイス)が外部 Web サイトへの送信接続を行うと、この例では Google TLS 証明書を使用する代わりに、組織の内部証明書を使用してトラフィックが暗号化されると gmail.com します。境界NGFWは、その送信トラフィックを検出すると、秘密鍵のコピーを持っているため、それを復号化し、トラフィックの内容を完全に分析できます。NGFW は内部接続を終了し、Google 証明書を使用して gmail.com への新しい TLS 接続を開始し、2 つの接続の内容(組織内からの内部接続から Gmail への外部接続)をプロキシするため、暗号化されていてもすべてのトラフィックを表示および分析できます。

この方法は面倒でCPUを集中的に消費しますが、SSLを使用した約10年間、TLS 1.0、1.1、および1.2を使用して、ほとんどのサービスでかなりうまく機能してきました。

今のところ大丈夫です。しかし、TLS 1.3 はゲームを変えます。まず、TLS 1.3 では、接続ごとの DH キー交換という形で、完全順方向の機密性が義務付けられています。このため、パッシブデバイスは、使用中の秘密鍵にアクセスしたとしても、ペイロードを復号化する方法がありません。TLS 1.3 では、ストリームにデバイスを挿入し、トラフィックをプロキシすることが必須です。次に、TLS 1.3 ではセキュリティの低い暗号が非推奨になり、プロキシ デバイスがプロキシ接続を TLS 1.2 に降格する機能が削除されますが、これは NGFW のコンピューティング リソースを節約するためによく採用される一般的な戦略です (通常、セキュリティの低い暗号は計算量が少なくて済むため)。

暗号化の歴史が私たちに何かを教えてくれたとすれば、古くて信頼できる標準は、ほぼ 100% の確実性で時間の経過とともに脆弱であることが判明する傾向があるということです。TLS 1.3 を TLS 1.2 に降格して、受動的な復号化や降格を可能にしてリソースを節約する現在の慣行は、タイマー上にあり、TLS 1.2 が非推奨になるのを待っています。その日が来ると、非常に多くの受動検査装置が高価な文鎮になり、多くのインラインソリューションは、より計算コストの高い暗号化の使用を余儀なくされるため、すぐに圧倒されます。

NGFW の世界の汚い小さな秘密は、少なくともこの記事の執筆時点では、WebSocket トラフィックがいかなる種類の脅威についても検査されていない可能性があるということです。なぜでしょうか。一般的なNGFWはトラフィックをリアルタイムで復号化できないためです。ペイロードを検査するには、WebSocketトラフィックをブラウザ内で表示するか(開発者ツールを使用して)、Wiresharkなどを使用して(秘密鍵を持っていると仮定して)事後にキャプチャして復号化する必要があります。WebSocket は、JavaScript アプリケーションがブラウザと Web サーバー間でデータを行き来するための優れたソリューションを提供するため、Web アプリケーションでますます一般的になってきています。文字通り、WebSocket接続を介して何でも移動でき、NGFWには完全に不透明です。

最後に、Web トラフィックに QUIC を使用するなど、他の広範な新しいテクノロジーも忘れてはなりません。QUIC は、ブラウザーへのトラフィックをより迅速かつ効率的に取得するための強力な新しいツールですが、標準の TLS 暗号化は使用しません。つまり、インライン NGFW は、すべての QUIC トラフィックをブロックするか (TLS へのダウングレードを強制)、トラフィックが検査されずに通過できるようにする必要があります。最初のソリューションはユーザーエクスペリエンスの品質を低下させ、2番目のソリューションは組織をリスクにさらします。どちらも理想的ではありません。

ワークロードレベルで一部のNGFWタスクを処理すると、既存のNGFWアプライアンスへの投資の寿命を延ばすことができます。これにより、ワークロードごとに処理することで、計算コストの高いプロセスをある程度オフロードできます。これにより、お客様は検査ペイロードの一部をネットワークデバイスからオフロードできるため、必要なファイアウォールのアップグレードを遅らせると同時に、技術的または財務的に意味のないネットワークの一部にゼロトラストの利点をもたらすことができます。