自然言語を活用したマイクロセグメンテーションポリシーの定義と簡略化

データセンターやクラウドの3つの基本リソース（コンピューティング、ストレージ、ネットワーク）のうち、リソースの仮想化と抽象化が進む現代の世界への進化が最も遅いのはネットワークです。これは主に設計によるものです。どのデータセンターやクラウドアーキテクチャにおいても、ネットワークファブリックは最も重要なリソースであると言えるでしょう。ネットワークがなければ、コンピューティングとストレージは手の届かない孤立した島です。ネットワークは、すべてのコンピューティングリソースとストレージリソース間、およびそれらのリソースのエンドユーザー間のアクセスと通信を可能にします。アーキテクチャの基盤となるネットワークがなければ、クラウドに関するすべての会話は無意味です。ベアメタルからサーバーレスまで、コンピューティングリソースに関するクラウドの会話をどの程度抽象化しても、全体像のどこかに IP パケットがあるとしたら、ネットワークは重要です。

ネットワークセキュリティは、ネットワーク言語ではなく自然言語を使用して定義されるようになりました。

これは常識であり、ネットワークには、特定のネットワーク問題を解決するための独自の形式のリソース仮想化があります。とはいえ、ここで言及しているのは、データセンターやクラウド環境のセキュリティは伝統的にネットワークに実装されてきたという単純な事実からです。クラウド・リソース間で転送されるネットワーク・トラフィックをブロックまたは有効にするために、ネットワーク・ファブリックのどこかにファイアウォールが導入されています。エンドポイントソフトウェアはコンピュートリソース上にデプロイされることがあります。コンピュートリソースは通常、既知のマルウェアや不正行為を探すシグネチャベースのツールですが、これらは一般にトラフィックを検査するもので、ブロックや許可はしていません。ほとんどのワークロードには Linux の iptables など、何らかのファイアウォール機能が組み込まれていますが、これらのツールを大規模にオーケストレーションするのは管理が難しい場合が多く、したがって使用されません。そこで、 ネットワークセキュリティ トラフィックの取締りは、伝統的にネットワークファイアウォールで行われていました。

セキュリティは多くの場合、別の言語で定義されています

ファイアウォールは通常、ネットワークチームによって管理されるため、セキュリティポリシーは、ほとんどの場合、ネットワークチームにとって馴染みのある用語を使用して定義されます。ファイアウォールは何十年も前から存在しており、その構成方法はここ数年でほとんど変化していません。ポリシールールは従来、IP アドレス、TCP/UDP ポート、VLAN、およびゾーンを使用して記述されていました。ファイアウォールは、ネットワークトラフィックのボトルネックにならないようにするため、通常、パケットのデータペイロードを詳しく調べてどのようなコンテンツやアプリが含まれているかを調べるようには設計されていません。

いわゆる 次世代ファイアウォール (NGFW) これらには、パケットをワイヤスピードでより詳細に検査する機能があり、ネットワークヘッダーだけでなく、パケットのデータペイロードに実際に含まれているものに対してポリシーを定義できます。しかし、古い習慣はなかなか消え去ってしまうため、これらのファイアウォールは多くの場合、次世代のオプションが使用されないまま古い方法で構成されています。その結果、ネットワーク用語を使用して定義を行うデバイスが生まれました。 ネットワークセキュリティこれは、データセンターやクラウドでホストされているリソースのユーザーがそれらのリソースをどのように認識するかではありません。ユーザーは多くの場合、リソースがどのネットワークセグメントでホストされているかを知らなかったり、気にしたりしません。彼らはリソースそのものに関心があります。

ネットワークポリシーには、保護対象のリソースに対するユーザーの認識を反映させる必要があります

ユーザーまたは開発者が、データセンターまたはクラウドでホストされているリソースにアクセスできないなどの問題を報告した場合、通常はアクセスできない特定のワークロードまたはアプリケーションについて問い合わせます。通常、特定のポートでは特定の IP アドレスにアクセスできないという報告はしません。ただし、ネットワークや セキュリティオペレーション チームはこの情報を要求します。そして、ここで問題が発生します。 報告されている問題は、ネットワークポリシーを適用しているデバイスとは異なる言語で表示されています。通常、アプリケーションのスピーキングとネットワークのスピーキングは同じではありません。

クラウドアーキテクチャでできるだけ多くのリソースを自動化するための重要な点の 1 つは、保護対象のリソースをユーザーが認識しているのと同じ用語を使用してネットワークポリシーを定義できることです。ファイアウォールがアプリケーションX、Y、Z間でポリシーを適用している場合、ホストされているネットワークリソースに固有のポリシーではなく、それらのアプリケーション固有のポリシーを定義できるはずです。

これは特に、IP アドレスが一時的なものであるマイクロサービスなどの最新のパブリッククラウドホストインフラストラクチャに当てはまります。多くの場合、ワークロードとアプリケーションは異なるネットワークセグメント間で動的に移行されるため、IP アドレスは、リソースのライフサイクル全体にわたって特定のワークロードを識別するための信頼できる方法ではなくなりました。IP アドレスが変更されるたびにファイアウォールを変更しなければならない場合、これはスケーラブルではありません。

その結果、ファイアウォールは現代のクラウドアーキテクチャに導入されていないことがほとんどです。その代わり、ファイアウォールはクラウドファブリックの境界に配置され、南北トラフィックのみに適用され、東西トラフィックの大部分には見えなくなります。

IP ではなくメタデータを使用してセキュリティを定義

最新のSDNコントローラーのほとんどは、各ワークロードに適用されるワークロードIPとメタデータのローカルデータベースに相当するものを作成できます。たとえば、5つの本番ワークロードがSQL Serverで、別の5つのワークロードが開発用SQLサーバーである場合、コントローラーはそれらのサーバーを2つのカテゴリに分類するローカルレコードを作成します。最初の5つのワークロードIPは「SQL-prod」のメタデータタグに割り当てられ、次の5つのワークロードIPは「SQL-dev」のメタデータタグに割り当てられます。コントローラーはこれらのワークロードを監視し、何らかの理由でワークロードのIPが変更されたり、スピンダウンしたりすると、メタデータからIPへのマッピングのローカルレコードを更新します。

これにより、コントローラーは、割り当てられた IP アドレスに関係なく、割り当てられたメタデータに基づいてワークロードのライフサイクル全体を追跡できます。ワークロードへのパケット転送とワークロードからのパケット転送は、現在割り当てられている IP アドレスを使用して IP ルックアップを使用して引き続き実行されます。ただし、そのワークロードの ID は、割り当てられているネットワークセグメントに関係なく、割り当てられたメタデータによって維持されます。

メタデータを使用してワークロードを識別することで、そのワークロードのアイデンティティをネットワークの詳細から完全に抽象化できます。これが、最新のセキュリティを定義する方法です。「開発中のどのSQLサーバーも製品内のSQLサーバーとの通信を開始できない」のようなポリシーを定義することは、「192.168.10.0/24 TCP 1024-2000 10.10.0.0/16 permit」と読むようにポリシーを定義するようなものよりも、ユーザーがこれらのリソースをどのように認識するかに非常に近いものです。メタデータ用語は、ネットワーク用語よりもずっと人間が読みやすい用語です。

メタデータを使用してリソースを識別することは、通常「タグ」または「ラベル」と呼ばれます。また、この概念は SDN 以外のコントローラーでも使用されています。と イルミオ ASP、各ワークロードにラベルを割り当てることができます。各ラベルには、役割、アプリケーション、環境、および場所という4つの「次元」があります。各ワークロードには、これらのディメンションの 1 つまたはすべてと照合するラベルを割り当てることができ、そのラベルを使用してポリシーを定義できます。そのため、Illumio のルールセットはポートや IP ではなく、ラベルを指します。

イルミオラベルの価値

ラベルの概念は些細なことのように思えるかもしれませんが、強調する価値があります。ラベルを使用すると、保護されているリソースをユーザーがどのように認識するかと同じ用語を使用してポリシーを定義できます。これは、従来のネットワークセキュリティの定義とは大きく異なります。何十年もの間、ネットワークセキュリティは IP、VLAN、ポートなどのネットワーク構成要素を中心に定義されてきました。ファイアウォールは、これらのネットワーク構造のレンズを通してセキュリティを捉えているため、これらの構成のいずれかが変更された場合は、ファイアウォールの構成を変更する必要があります。

ただし、ポリシーがラベルを使用して定義され、そのラベルによってワークロードの組み込みファイアウォール機能がバックグラウンドでこの定義を適用するように構成された場合、ポリシーがリソースの実際の使用方法と一致するようになります。現在、ネットワークセキュリティはネットワーク言語ではなく自然言語を使用して定義されています。そして、この自然言語ポリシーは 1 回定義すれば、ワークロードがネットワークファブリックをまたいで移行したり、スピンダウンまたはスピンアップしたり、大規模なデプロイメントにスケールアップされたりしても、何も表示されなくなります。

セキュリティは、ワークロードのスケーラビリティ要件を妨げるものであってはなりません。自然言語を使用してポリシーを定義する（ラベルを使用する）ことで、セキュリティによってDevOpsプロセスが遅くなることなく、ワークロードを進化させることができます。

だから私はラベルを使っています。さてどうする？

ネットワークチームが自然言語ラベルを使用してポリシーを定義することに慣れてきたとしても、人間が読みやすい言語を作成するために、ポリシー定義の背後にある考え方は依然としてネットワーク中心であることが多いです。ラベルはワークロードとアプリケーションを指しますが、ネットワーキングチームは依然として信頼境界をネットワークの境界と見なしています。しかし、採用する企業が増えるにつれ ゼロトラスト マインドセットは、組織が信頼の境界線をネットワークから切り離し、ラベルが参照しているリソースに直接到達させる必要があるという重要な特徴の1つです。SQL ワークロードが 5 つある場合、それぞれのワークロードが独自の信頼境界になります。信頼境界は、すべてのネットワークセグメントが共有しているような共通のネットワークセグメントではありません。

Illumioは、と呼ばれるエージェントをデプロイします オーブン監視対象のすべてのワークロードで、エージェントはラベルベースのポリシーを各ワークロードの組み込みファイアウォールのルールに変換します。つまり、パケットが生まれたときの最初のステップはポリシーです。ゼロトラストについての別の考え方は、「検査が終わるまで、パケットはネットワーク転送プレーンに届かない」ということです。イルミオでは、パケットがネットワーク転送プレーンに到達するまでに、すでにセキュリティが適用されています。

これは、次の問題に対処しようとするときに特に重要です。 横方向の動きこれにより、悪意のある攻撃者やマルウェアが検出されずにネットワークを通過できます。たとえば、リモートユーザーとセキュリティガイドラインについて話し合う場合、通常はセキュリティの必要性が認識されますが、よくある回答は「隠すものは何もない」というものです。これは、わざわざワークロードを保護しない理由として使用されます。そのユーザーには隠すものが何もないかもしれませんが、他のユーザーには隠す可能性があります。マルウェアは、そのワークロードから他のワークロードに移るという特定の目的で、そのワークロードを侵害することが多く、そのターゲットはより貴重なリソースとなります。これは水平移動であり、あるワークロードを別のワークロードの出発点として使用します。

信頼境界がネットワークセグメントであり、マルウェアがそのネットワークセグメント上の複数のワークロードのいずれかに侵入した場合、ネットワークファイアウォールが気付くことなく、マルウェアはセグメントを共有するワークロード間を横方向に移動できます。 ラテラルムーブメントは、ネットワークファブリック内ではなく、すべてのワークロードで防止する必要があります。

ラベルは、ポリシーを理解しやすくし、最終目標、つまりセキュリティソリューションを保護しようとしている対象に押し出すという最終目標に焦点を合わせておくのに役立ちます。クラウドアーキテクチャの 1 つのレイヤーに依存して別のレイヤーを保護しないでください。信頼の境界は、ワークロードがどこにあっても変わりません。ゼロトラストはすべてのワークロードがセグメントであることを意味し、すべてのワークロードを保護すれば、ラテラルムーブメントのリスクを大幅に軽減できます。

Illumio ASPの詳細とラベリングについての考え方については、以下をご覧ください。

• の新しいビデオ ラベルの力
• ザの イルミオ ASP デザインガイド