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

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

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

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

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

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

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

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

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

ファイアウォールは、通常、セグメントを、関連する TCP/UDP ポートを伴う IP 範囲のグループとして、または、関連する IP 範囲間でブロックまたは許可するポートを伴うセグメントのコレクションであるゾーンとして認識します。ネットワーク ファイアウォールは、パケットのデータ ペイロードのアプリケーション固有のコンテンツに基づいてセキュリティを実装しません。ファイアウォールは、パケットの宛先または送信元の IP アドレスとポートをワークロードの ID と見なします。パケットの奥深くに含まれるアプリケーションデータに基づいて判断を下せる最新の 「次世代」ファイアウォール でさえ 、ファイアウォールルールの大部分は依然として従来のIPアドレスとポート範囲に基づいて設定されています。古い習慣はなかなか抜けません。

伝統を打ち破る

DevOps の哲学では、展開のスピードと自動化を重視します。また、前述のように、ネットワーク セグメントやファイアウォールの変更は、通常は時間がかかり、手動で行う必要があります。ネットワークやセキュリティの変更を自動化すると、運用上の障壁にぶつかることが多く、変更が困難になることがあります。その結果、セキュリティはプロセスを遅くするだけなので、後回しにされることが多くなります。通常、ワークロードは迅速かつ機敏に展開され、侵害が発生して企業が訴訟に直面した後にのみ、セキュリティが優先事項として復活します。セキュリティがなぜ優先されなかったのか、そしてなぜ自社が訴訟を起こされているのかを CEO に説明したいと思う人は誰もいません。

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

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

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

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

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

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

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

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

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

ファイアウォールは、これまでと同様にファブリック全体に広範なセグメントを作成するために使用されますが、アプリケーションのセグメント化要件に対応するために扱いにくい数の VLAN またはサブネットを作成する必要はなくなりました。ネットワーク設計者は、 ネットワーク セグメンテーションを設計する際に、スループット、冗長性、ルート集約、スパニング ツリー、ECMP などのネットワークの優先順位に重点を置くことができます。アプリケーションのセグメンテーションによってネットワーク設計に頭を悩ませる必要はなくなりました。ワークロードによってセグメンテーション境界が作成され、強制されると、セキュリティ問題のトラブルシューティング時に原因を探すときに、ネットワークが最初に調査される必要がなくなります。

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

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

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

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

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

まとめると

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

最新のクラウド ファブリックでは、はるかにスケーラブルなアプローチとして、ワークロードに進んでマイクロセグメントを作成し、ワークロードに関連するポリシーを適用することで、ネットワーク設計に関連する優先順位に沿ってネットワーク セグメンテーションを自由に定義できるようになります。ネットワークはもはや、 アプリケーション ワークロードの俊敏性とセキュリティに対する障害ではなくなりました。また、 アプリケーション セキュリティのトラブルシューティングが発生したときにネットワークが最優先されることはなくなり、インシデント対応時に責任のなすり合いが減ります。

セグメンテーションの進化を詳しく説明したこのビデオをご覧ください。また、 こちらで当社のソリューションの詳細をご覧ください。