ネットワークがワークロードセグメンテーションの障害にならないようにしましょう

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

では、これらのアプリケーションとそのワークロードを保護するうえで、なぜ私たちはいまだにネットワークに関連するアプローチを検討しているのでしょうか？ネットワークがアジャイルなワークロード配信、自動化、セキュリティの障害にならないように、アプローチをどのように進化させるかを探っていきましょう。

現代のワークロードの内部の仕組み

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

従来のベアメタルワークロードとは異なり、最新のワークロードは主に基盤となるネットワークまたはサーバーリソースよりも抽象化されています。基盤となるリソース上のワークロードは一時的なものであり、ホスト間、データセンター間、クラウド間で動的にライブマイグレーションできると想定されています。このような移行は通常、手動による指示なしに動的に行われます。このように、基盤となるリソースよりもワークロードが抽象化されているため、ワークロードの IP アドレスをそのワークロードの存続期間にわたって有用な ID 形式と見なすことはもはや現実的ではありません。ワークロードにはライフサイクルを通じてさまざまな IP アドレスが割り当てられている場合があり、これは現代のネットワークにおけるセキュリティ境界の定義方法に直接影響します。

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

従来、ネットワーク・ファブリックの重要性により、設計上、ネットワークへの変更には時間がかかっていました。 多くのデータセンターネットワークはほぼフラットであり、多くのパブリッククラウドネットワークファブリックには大まかなレベルのセグメンテーションしか含まれていません。 どのような環境でもネットワークをセグメント化する場合、DMZ、WANセグメント、キャンパスセグメント、従来のWeb/アプリ/開発セグメントなど、幅広いカテゴリのリソースを分離するなど、ネットワーク固有の優先事項に基づいてセグメント化するのが一般的です。ネットワークをセグメント化するその他の理由としては、ネットワークパフォーマンスの最適化、スループットの向上、パスの冗長性の実装、ルート集約、スパニングツリー、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 など。アプリケーションをセグメンテーションしても、ネットワーク設計を悩ませる必要はもうありません。また、ワークロードにセグメンテーション境界を設定して適用することで、セキュリティ問題のトラブルシューティング時に原因を突き止めるときにネットワークが最初に列に並ぶ必要がなくなります。

最新のワークロード向けの最新のセグメンテーション

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

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

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

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

まとめると

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

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

これをチェックしてください ビデオ セグメンテーションの進化を解き明かし、当社のソリューションについてさらに学ぶためのクイックジャーニー ここに。