ネットワークをワークロードのセグメンテーションの障害にしないでください

セキュリティとネットワーキングは、長い間、優先順位が相反する原因となってきました。従来のデータセンターまたはハイブリッドクラウドファブリックを設計する場合、ネットワークアーキテクチャの優先事項は、信頼性と回復力のあるトラフィック配信です。ネットワークは、おそらく、データセンターやクラウドアーキテクチャにおいて最も重要なリソースです。結局のところ、ワークロード、クライアント、およびデータベースは、それらの間にネットワークがない限り、相互に通信することはできません。また、すべてのネットワークは、パケットのヘッダーやその他のさまざまなメトリックの分析に基づいて転送の決定を行うことによって動作します。さらに、ルーターとスイッチはレイヤー 2 とレイヤー 3 の概念に関する情報を交換しますが、どちらもパケットのデータ ペイロードの奥深くに含まれるアプリケーション固有の詳細にほとんど依存しません。ネットワークは、トラフィックに含まれるアプリケーションデータではなく、トラフィックを確実かつ迅速に移動することに重点を置いています。

では、これらのアプリケーションとそのワークロードを保護する場合、なぜネットワークに結び付けられたアプローチを依然として検討するのでしょうか?ネットワークがアジャイルなワークロードの配信、自動化、セキュリティの障害にならないように、アプローチを進化させる方法を見てみましょう。

最新のワークロードの内部動作

あらゆるネットワークを介して通信するワークロードは、アプリケーション固有の優先順位に基づいて通信するように設計されています。ワークロードが何をしているかは、基盤となるネットワーク ファブリックがどのように見えるかよりも重要です。クライアントはワークロードと通信し、ワークロードは、通常、ネットワークパケットヘッダーに含まれる詳細に依存しない概念に基づいてデータベースと通信します。

従来のベアメタルワークロードとは異なり、最新のワークロードは、基盤となるネットワークまたはサーバーリソースの上に大部分が抽象化されています。基盤となるリソース上のワークロードの存在は一時的なものであり、ホスト間、データ センター間、クラウド間で動的にライブ マイグレーションできると想定されます。これらの移行は通常、人間の手動指示なしに動的に行われます。基になるリソースの上にワークロードが抽象化されているため、ワークロードの IP アドレスをそのワークロードの存続期間中の有用な ID 形式と見なすことはもはや現実的ではありません。ワークロードは、そのライフサイクル全体にわたって多くの異なる IP アドレスを持つ可能性があり、これは最新のネットワーク全体でセキュリティ境界がどのように定義されるかに直接影響します。

従来のネットワークセグメンテーションとファイアウォール

ネットワークへの変更は、ネットワークファブリックの重要な性質により、設計上、従来は遅いものでした。多くのデータセンターネットワークはほぼフラットであり、多くのパブリッククラウドネットワークファブリックには大まかなレベルのセグメンテーションしか含まれていません。ネットワークが任意の環境でセグメント化される場合、通常、DMZ、WAN セグメント、キャンパス セグメント、従来の Web/App/Dev セグメントなど、幅広いカテゴリのリソース間で分離を作成するなど、ネットワーク固有の優先順位のために行われます。ネットワークをセグメント化するその他の理由としては、ネットワーク パフォーマンスの最適化、スループットの向上、パスの冗長性の実装、ルートの要約、スパニング ツリー、ECMP などのタスクの効率化などがあります。

ネットワークセグメントは従来、従来の「アンダーレイ」ネットワークまたは「オーバーレイ」ネットワーク全体で VLAN とサブネットを作成することによって実装され、SDN コントローラーと VXLAN などのトンネリングを使用して実装されていました。トポロジがアンダーレイかオーバーレイかに関係なく、これらのネットワークセグメントはすべて、ハードウェアまたは仮想のルーターまたはスイッチで終端します。また、これらのセグメント全体にセキュリティを実装するには、通常、ネットワークファイアウォールを使用して行われます。

ファイアウォールは従来、セグメントを IP 範囲のグループと関連する TCP/UDP ポート、またはセグメントの集合であるゾーンと、関連する IP 範囲間でブロックまたは許可するポートとして見なします。ネットワークファイアウォールは、パケットのデータペイロードのアプリケーション固有のコンテンツに基づいてセキュリティを実装しません。ファイアウォールは、パケットの宛先または送信元 IP アドレスとポートをワークロードの ID と見なします。パケットの奥深くに含まれるアプリケーションデータに基づいて意思決定を行うことができる最新の「次世代」ファイアウォールを使用しても、ファイアウォールルールの大部分は依然として従来のIPおよびポート範囲に沿って構成されています。古い習慣はなかなか消えません。

伝統を打ち破る

DevOps の哲学は、デプロイの速度と自動化に重点を置いています。また、前述のように、ネットワークセグメントと ファイアウォールの変更は通常、遅く、手動で行われます。ネットワークとセキュリティの変更を自動化すると、運用上の障壁に遭遇することが多く、変更が困難な場合があります。その結果、セキュリティは単にプロセスを遅くするだけなので、後回しにされることがよくあります。通常、ワークロードは迅速かつ機敏に展開され、セキュリティは侵害が発生し、ビジネスが訴訟に直面した後にのみ優先事項として戻ってきます。なぜセキュリティが最優先事項でなかったのか、なぜ自分のビジネスが今訴えられているのかをCEOに説明する人になりたい人は誰もいません。

Amazon は 2012 年に、ワークロードの俊敏性とネットワークの変更の間の優先順位の対立を「ネットワークが私の邪魔をしている」と表現したことで有名です。ネットワークとネットワークセグメントの変化は、アジャイルなワークロード展開の障害となっています。そのため、 ネットワークセグメンテーション は行われないか、ネットワークチームによって非常に粗雑な方法で行われることがよくあります。

しかし、ネットワークのセグメンテーションとセキュリティをワークロード内から直接実装できるとしたらどうなるでしょうか?基盤となるネットワークファブリックにセグメンテーションを実装するためにネットワーク運用を待つ必要はもうありません。

代わりに、DevOps プロセスを介してワークロードをデプロイするのと同じアジャイル プロセス内から、必要なセグメントを直接実装できるとしたらどうでしょうか?

そして、さらに重要なことは、 これらのセグメント間のセキュリティを、古いIP/ポートファイアウォールルールに依存するのではなく、自然言語ポリシーを使用して定義できるとしたらどうなるでしょうか?送信元 IP と、宛先 IP とポートを指すポートは、ライフサイクル全体を通じてワークロードに関連付けられなくなるため、ポリシーを定義する必要はなくなりました。

代わりに、ユーザーがリソースをどのように認識するかを反映するポリシーを記述できるとしたらどうでしょうか ("ニューヨークに展開された Web サーバーのみがロンドンのデータベース サーバーと通信できますか?"

そして、これをきめ細かなアプローチで定義し、「Webserver-1 のみが同じ場所内の Webserver-2 と通信できる」などの真の「マイクロセグメント化された」ゼロトラストアプローチを実現できたらどうでしょうか?

次の図に示すように、ネットワークアーキテクチャにはポリシーを適用できる4つの広範なレイヤーがあります。

層を上に上げると、政策は下位層にとらわれず、より自然な言語で表現されます。ワークロードにワークロードポリシーを直接適用すると、下位レイヤーが解放され、ネットワークの優先順位に集中できます。

ワークロード層ツールが、基盤となるネットワークファブリックの上に抽象化された方法でワークロード間のセグメンテーションと適用を定義できるようにすることで、ネットワーク運用チームは、アプリケーション要件がネットワーク設計に影響を与える必要がなくなります。アプリケーションのセグメンテーションと適用をワークロード層に「上」にプッシュすることで、ネットワーク運用チームはネットワークの優先順位に沿ってネットワークファブリックを設計できます。

これまでと同様に、ファイアウォールはファブリック全体に広範なセグメントを作成するために使用され続けますが、アプリケーションのセグメンテーション要件に対応するために、扱いにくい数の VLAN やサブネットを作成する必要はなくなりました。代わりに、ネットワークアーキテクトは、スループット、冗長性、ルート要約、スパニングツリー、ECMPなどの ネットワークセグメンテーションを設計する際に、ネットワークの優先順位に焦点を当てることができます。アプリケーションのセグメンテーションは、ネットワーク設計に頭痛の種を加える必要はもうありません。また、ワークロードにセグメンテーション境界を作成して適用させることで、セキュリティ問題のトラブルシューティング時に原因を探すときにネットワークが最初に並ぶ必要がなくなります。

最新のワークロードのための最新のセグメンテーション

イルミオの アダプティブ・セキュリティ・プラットフォーム (ASP)は、真の ゼロトラスト・アーキテクチャを構築するために不可欠なワークロード間のマイクロセグメンテーションを可能にし、自然言語式を使用してそれらのワークロード間のポリシーを定義します。これにより、ハイブリッドクラウドファブリック全体にわたって、どのワークロードが相互に通信しているのか、誰が誰との接続を開始しているのかを正確に把握できる アプリケーション依存関係マップ が提供されます。また、ワークロードで使用されるIPアドレス指定を完全に可視化できますが、ネットワークアドレス指定とアプリケーション間の関連付けは一時的なものであるため、IPアドレス指定に対してポリシーを定義することはできませんし、定義すべきではありません。

Illumioは、ラベルを使用して、ワークロードがホストされている基盤となるハイブリッドクラウドネットワークセグメントのどのセグメントの上でも抽象化された基準に照らしてワークロードを識別します。

• これらのラベルには、現在の IP アドレスに関係なく、ワークロードに関連付けられたメタデータが含まれます。
• ラベルは、ロール、アプリケーション、環境、およびロケーション ("RAEL") です。
• これらはワークロード間のセグメントを定義するために使用され、これらのラベル付きワークロード間の適用は、Web ワークロードはアプリ ワークロードと通信できますが、アプリ ワークロードのみがデータベース ワークロードと通信できるなど、自然言語式を使用して定義されます。ポリシーは IP アドレス指定に固有ではありません。
• 次に、イルミオは、これらのラベルベースのポリシールールを、現在それらのワークロードを実行しているOSのネットワークフィルタリング機能に固有の構成(Linux iptablesとipsets、Windows Filtering Platform(WFP)、またはSolarisおよびAIXワークロードのIPFilter状態テーブルのいずれかに変換します。

Illumioでは、ワークロードがホストされる方法と場所よりも完全に抽象化された方法でポリシーを定義できるため、ネットワークの優先順位とアプリケーションの優先順位が競合しなくなります。

まとめると

最新のデータセンターおよびハイブリッドクラウドネットワークアーキテクチャでは、境界はワークロードが現在ホストされている場所として単純に定義され、そのワークロードはクラウドの任意のセグメント間で動的に移動できます。データセンターとインターネットの間にあるという境界の従来の定義はもはや意味がなく、アプリケーションの境界を越えたマイクロセグメンテーションを可能にするネットワークファブリックを設計しようとすることは、拡張が困難です。ハイパーバイザーで終端するコントローラーとオーバーレイネットワークを使用するSDNソリューションは、ネットワークとワークロードの間の境界をホストに効果的に移動しますが、ワークロードレイヤーの問題を解決するために、ネットワークレイヤーから「ボトムアップ」からセグメントを定義することに依存しています。

最新のクラウド ファブリックにおけるはるかにスケーラブルなアプローチは、ワークロードに移動してマイクロセグメントを作成し、ワークロードに関連するポリシーを適用することで、ネットワーク設計に関連する優先順位に沿ってネットワーク セグメンテーションを定義できるようにすることです。ネットワークは、もはや アプリケーションワークロード の俊敏性とセキュリティの障害ではありません。また、 アプリケーションセキュリティ のトラブルシューティングが行われるときにネットワークが最初に並ぶことはなくなり、インシデント対応中の非難を減らすことができます。

セグメンテーションの進化を分析する簡単なジャーニーについては、この ビデオ をチェックし、 ソリューションの詳細については、こちらをご覧ください。