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

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

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

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

2回目の記事では、「もしも？」についてお話します。NGFW 機能のサブセットをマイクロセグメンテーションソリューションに組み込むシナリオ。さまざまなユースケースと、どの NGFW 機能がそれぞれに適しているのかを説明します。

NGFWは南北の交通には役立ちますが、東西の交通には苦労しています

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

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

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

南北交通用NGFW

これは NGFW の良いユースケースの 2 つですが、実際には 3 つ目の 1 つは、あくまで例外を除いて、ほとんど考慮されないユースケースです。南北のユースケース、つまり英語では、ネットワーク内からのアウトバウンドトラフィックを制御するユースケースです。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アプライアンスはほぼスーパーコンピュータークラスのシステムであり、かなりのパフォーマンスを実現するための専用ハードウェアが多数備わっていることを思い出してください。つまり、同じ機能を実装すると、個々のサーバーにかなりのパフォーマンス上のペナルティが課せられることになります。幸いなことに、このような状況は、直感が通用しない場合の一つかもしれません。その理由について話しましょう。

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

要するに、これらの1000台のマシンの脆弱性シグネチャが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つは解決可能な問題です。

どうやって?なぜなら、すべてのサーバにエージェントがあるおかげで、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（暗号化されたトラフィック）に移行するトラフィックが増えていきました。現在、すべてのウェブトラフィックのほぼ 100% が暗号化されているため、マルウェア、ウイルス、データ漏えい、その他の NGFW サーバーについて分析することはできません。このために開発されたソリューションは TLS MitM (中間者攻撃) と呼ばれています。

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

ユーザー（またはサーバーまたはその他のデバイス）が外部のWebサイト（この例ではgmail.com）にアウトバウンド接続する場合、Google TLS証明書を使用する代わりに、組織の内部証明書でトラフィックを暗号化します。境界の 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 は、ブラウザと Web サーバー間でデータをやり取りするための JavaScript アプリケーションの優れたソリューションとなるため、Web アプリケーションでは WebSocket がますます一般的になっています。WebSocket 接続では文字通り何でも移動でき、NGFW からは完全に見えなくなります。

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

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