ワークロードのセグメンテーションのベストプラクティス:無駄のない合理化、それとも重くて複雑なか?

「サイバーセキュリティ」は幅広いトピックをカバーしており、その中にはネットワークの優先順位、ホストの優先順位、認証、ID、自動化、コンプライアンスなどが含まれます。マイクロセグメンテーションは 、このより広範な原則の一部ですが、多くの人は依然として、大規模に実装するのは難しいと考えています。

最新のワークロードには、Linux の iptables など、統合されたファイアウォールとポート フィルターが含まれています。個々のワークロードでこれを構成するのは比較的簡単ですが、大規模に行うのは多くの場合困難です。そして、モノリシックワークロードからマイクロサービスへの移行が進む中で、その課題の運用化はさらに困難になります。その結果、アーキテクチャのワークロード層でのセグメンテーションは行われず、代わりに、このタスクを基盤となるネットワークファブリックに任せて実装することが多くなります。このアプローチでは、ネットワークセグメンテーションがワークロードセグメンテーションに必要な理由とは異なる理由で実装されることが多いため、優先順位の競合が生じます。

ハイブリッドクラウドとマイクロサービスアーキテクチャの両方でワークロードレイヤーでセグメンテーションするための2つの重要な要件は、自動化と大規模アーキテクチャのサポートです。自動化とは、運用プロセスに人間が関与すればするほど、設定ミスやエラーが発生する可能性が高くなるため、人的要素を可能な限り排除することを意味します。また、大規模なアーキテクチャをサポートするということは、一定の規模に達した後、アーキテクチャ全体の障害を防ぐような方法でセグメンテーションの自動化を可能にすることを意味します。

これらの要件は、「重い」アプローチまたは「軽量」アプローチの 2 つの方法のいずれかで実装できます。これら 2 つのアプローチを比較して、どちらがあなたとあなたの組織にとって最も理にかなっているかを見てみましょう。

マイクロセグメンテーションへの2つのアプローチの物語

まず、私たちが「重い」アプローチと考えるものについて説明しましょう。たとえば、Cisco Tetration などのより重いアプローチは、すべてのワークロードからすべてのパケットをキャプチャし、ネットワーク ファブリック全体でネットワーク分析を実行し、セグメンテーション ポリシーを大規模に実装するために大量の人間の介入を必要とすることに重点を置いています。このようなツールの運用は非常に複雑であるため、マイクロセグメンテーションを実装するための「重い」アプローチと言えます。

対照的に、イルミオのような「軽量」アプローチは、 マイクロセグメンテーション専用に構築されていました。それらは1つの製品として生まれ、後に別の製品に改造されたわけではありません。これらはワークロード層でのセグメンテーションのみに焦点を当てており、基盤となるネットワークがどのように実装されているかに意図的にとらわれず、ネットワーク分析のタスクをネットワークツールに任せています。このアプローチにより、セグメンテーションポリシーの実装は自動化に重点を置き、人間の介入はほとんど必要とされず、

セグメンテーションがアーキテクチャを壊すのはいつですか?

これは自明の理ですが、繰り返します:解決策が複雑であればあるほど、運用上の上限に達するのは早いということです。ある時点で、複雑なソリューションは、ワークロードセグメンテーションアーキテクチャ全体をどこまで拡張できるかに最終的に障害が生じます。

マイクロセグメンテーションのためのより重くて複雑なソリューションは、小規模なユースケースでは機能しますが、それらのユースケースが拡大するにつれて、最終的には運用上のオーバーヘッドが重くなってしまい、ハードリミットに達します。その時点で、追加のワークロードが保護されないままになることが多く、自動化が崩壊し始めます。ソリューションが実行するタスクが増えると、複雑さは最終的に運用上の負担になります。

マイクロセグメンテーションベンダーは、マネージドワークロードの上限を反映した数値を頻繁に公開しており、これらの数値は予想される成長に対応するのに十分な大きさであるようです。しかし、ハイブリッドクラウドアーキテクチャを採用する組織が増えるにつれ、仮想化は従来のベアメタルホストの場合よりもはるかに多くのワークロードを生み出します。また、マイクロサービスアーキテクチャでは、ホスト内にIPアドレス指定可能なエンティティが大幅に追加され、ワークロードの総数が急速に増加します。管理対象ワークロードの数は、セグメンテーションの運用に使用されるツールによって決定されるべきではありません。ワークロードの成長サイクルが中断されないようにするには、数が少ないだけで十分だとは決して考えないでください。

進化するハイブリッドクラウドアーキテクチャでマイクロセグメンテーションを自動化するには、上限に達した後にソリューションが故障しないようにする必要があります。

人間の自動化≠

自動化には、無駄のない合理化されたアーキテクチャが必要です。クラウド環境におけるセキュリティ侵害の大部分は、管理者による正直なミスによるものです。ワークロードのライフサイクルがより動的になり、ネットワークセグメント上のワークロードが存在する場所がますます一時的になるにつれて、セキュリティプロセスを自動化し、運用プロセスへの人間の介入によってもたらされる重大なリスクを取り除くことがより重要になっています。

イルミオは、軽量アプローチの一例として、 4次元ラベル とアプリケーションリングフェンシングの概念を使用して、ワークロードの開始時にセグメンテーションを適用するプロセスを簡素化および自動化します。これにより、セグメンテーションの境界を自動的に提案したり、管理者がこれらの境界を定義したりできます。これにより、人間の介入によって誤ってエラーが発生するリスクが大幅に軽減されます。

Tetration などのほとんどの重いソリューションには、IP アドレス指定とは無関係にワークロードを追跡するためにワークロードにタグを適用するオプションが含まれています。とはいえ、このプロセスは「重く」複雑であり、運用するにはかなりの量の初期人間との相互作用と専門知識が必要です。また、ご想像のとおり、プロセスに人間の介入と専門知識が必要であればあるほど、意図しないエラーのリスクが高くなります。

ワークロードのセグメント化の自動化を計画するときは、プロセスが複雑になるほどリスクが高くなるというルールに留意してください。

マイクロサービスを導入し、より多くのワークロードを期待する

モノリシックワークロードからマイクロサービスへのアプリケーション開発の移行により、管理する必要があるワークロードの数が大幅に増加する効果が生じます。仮想化の出現により、1 つのベアメタル ホストで、それぞれが独自の IP アドレスを持つ多数の VM を管理できるようになりました。そして現在、マイクロサービスの出現により、これらの各 VM は多くのコンテナ化された構造をホストできるようになり、その結果、さらに多くの IP アドレスが生まれます。

IP アドレスを持つネットワーク上のすべてのエンティティがワークロードとして定義されている場合、マイクロサービス環境ではワークロードの数が爆発的に増加する可能性があります。監視する必要があるワークロードの数が非常に多いため、非常に多くの数に拡張できるソリューションが必要です。

視覚化が最も重要です

ワークロードの監視は、ポリシーの適用と視覚化という 2 つの基本的なことを意味します。しかし、多数のワークロードにわたってアプリケーションが相互に何をしているかをどのように視覚化すればよいでしょうか?ワークロード通信の視覚化は、 ネットワークセグメンテーションに依存することはできません。マイクロサービスの場合、視覚化の必要性は VM 間のトラフィックを超えて広がり、Kubernetes または OpenShift を使用してコンテナのライフサイクルを調整する場合は、ポッド、ノード、およびサービス間の通信を含める必要があります。

Tetrationのような重いソリューションは、コンテナ化された環境内でポリシーを適用できますが、これらの構造内でのアプリケーショントラフィックの視覚化は制限されています。これらのソリューションでは、多くの場合、ホスト間のトラフィックの視覚的なマップを作成できますが、ビューはそこで停止し、ホスト内のコンテナ化された構成間のトラフィックが欠落します。一方、軽量ソリューションは、ベアメタル ホストから VM および任意のホスト内のすべてのコンテナ化された構造に可視性を拡張します。モノリシックであろうとコンテナ化であろうと、すべてのワークロードは、たとえばIllumioがアプリケーションの依存関係マップを構築するときに完全に表示されます。

ホスト方法に関係なく、すべてのアプリケーショントラフィックと動作を視覚化することは、オンプレミスのデータセンターとパブリッククラウドファブリックの両方で、ハイブリッドクラウドとさまざまなコンピューティングリソースにわたってワークロードが進化するにつれて不可欠です。人間 が読める宣言型ポリシーを作成して適用するために、これらの詳細がより複雑かつ動的になるにつれて、視覚化の重要性が高まります。

要するに

ワークロードのセグメンテーションを大規模かつ自動化された方法で実装する方法を決定する場合、無駄のない合理化されたアプローチが唯一の実行可能なオプションです。水上でのスピードと俊敏性が目標の場合、戦艦を配備するよりもスピードボートを配備する方が良い選択である場合があるのと同様に、最新のハイブリッドクラウドとコンピューティングファブリック全体にマイクロセグメンテーションを展開する方法にも同じことが当てはまります。複雑さを軽減し、ソリューションを「重い」のではなく「軽量」に保ちます。