自然言語を活用してマイクロセグメンテーションポリシーを定義および簡素化する

データセンターやクラウドの3つの基本リソース(コンピューティング、ストレージ、ネットワーク)のうち、ネットワークは、リソースの仮想化と抽象化の現代の世界への進化が最も遅いです。これは主に設計によるものです。ネットワークファブリックは、あらゆるデータセンターやクラウドアーキテクチャにおいて最も重要なリソースであると言えます。ネットワークがなければ、コンピューティングとストレージは到達できない島になります。ネットワークはアクセスを可能にし、すべてのコンピューティング リソースとストレージ リソース間の通信を可能にし、それらのリソースのエンド ユーザー間で通信できるようにします。アーキテクチャの基盤となるネットワークがなければ、すべてのクラウド会話は意味がありません。ベアメタルからサーバーレスまで、コンピューティングリソースに関するクラウドの会話をどれだけ抽象化しても、画像のどこかにIPパケットがある場合、ネットワークは重要です。

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

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

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

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

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

ネットワーク ポリシーは、保護されているリソースをユーザーがどのように認識しているかを反映する必要があります

ユーザーまたは開発者が、データセンターまたはクラウドでホストされているリソースにアクセスできないなどの問題を報告すると、通常、到達できない特定のワークロードまたはアプリケーションを参照します。通常、特定の IP アドレスが特定のポート経由で到達できないことを報告することはありません。ただし、ネットワークまたは セキュリティ運用 チームは、この情報を要求します。ここで問題が発生します 。報告されている問題は、ネットワークポリシーを適用しているデバイスとは異なる言語で書かれています。通常、アプリケーションのスピークは、ネットワークのスピークと同等ではありません。

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

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

その結果、ファイアウォールは最新のクラウドアーキテクチャに導入されないことがよくあります。代わりに、クラウド ファブリックの境界に座り、North-South トラフィックのみを強制し、East-West トラフィックの大部分を無視します。

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

最新のSDNコントローラのほとんどは、各ワークロードに適用されるワークロードIPとメタデータのローカルデータベースに相当するものを作成できます。たとえば、5 つの運用ワークロードが SQL Server で、他の 5 つのワークロードが開発用 SQL Server の場合、コントローラは、最初の 5 つのワークロード IP が "SQL-Prod" のメタデータ タグに割り当てられ、2 番目の 5 つのワークロード IP が "SQL-Dev" のメタデータ タグに割り当てられる 2 つのカテゴリに一覧表示されるローカル レコードを作成します。コントローラーはこれらのワークロードを監視し、何らかの理由でワークロードが IP を変更した場合、またはスピンダウンされた場合、コントローラーはメタデータから IP へのマッピングのローカル レコードを更新します。

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

メタデータを使用してワークロードを識別することで、そのワークロードの ID をネットワークの詳細から完全に抽象化できます。「開発中の SQL サーバーは本番環境の SQL サーバーとの接続を開始できません」のようなポリシーを定義することは、「192.168.10.0/24TCP 1024-2000 10.10.0.0/16 許可。メタデータ用語は、ネットワーク用語よりもはるかに人間が読みやすいです。

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

イルミオラベルの価値

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

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

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

それで、私はラベルを使用しています: さて、どうしますか?

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

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

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

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

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

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

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