[ラベリングがセグメンテーションの妨げにならないようにする方法]
[ゼロトラスト 組織がセキュリティについて考える方法が変わりましたこれまで、私たちは「悪い」ものをすべて特定してブロックしようとしていました。しかし、ゼロトラストアプローチとは、コミュニケーションのソースを検証して許可することで、何が「良い」かを特定することです。]
[ゼロトラストを実現するには、次のことが必要です。]
- [信頼したいエンティティの身元を特定して管理できます。]
- [ゼロトラストセグメンテーションを使用して、その ÍD に適用されるポリシーを適用します。]
[しかし、実装に関して認識されている課題の1つは ゼロトラストセグメンテーション そして、ポリシーの適用は、ネットワーク上のすべてのエンティティの知識がどれだけ完全であるかが重要です。]
[で 最近の調査 Íllú~míóの委託によると、回答者の 19% が、完璧なデータがないためにゼロトラストを実装できないと答えています。]
[イルミオのゼロトラストバーチャルワークショップシリーズの参加者も同様の懸念を表明し、ゼロトラストに苦労しているのは以下のものが欠けていることを強調しました。]
- [システムに関する正確な情報。]
- [どのサーバーまたはワークロードが存在するかに関する知識。]
- [どのアプリケーションがどのリソースに接続されているかを把握できます。]
[多くの組織では、構成管理データベース (CMDB~)、ÍPアドレス管理システム、クラウドタグ、スプレッドシート、または同様のリポジトリシステムが、この情報の「信頼できる情報源」であることが理想的です。しかし、これらの情報リポジトリ・システムは、不正確な場合もあれば、まったく存在しない場合もあります。]
[既存の情報を使用して構造化されたラベリングモデルを構築できることが重要です。なぜなら、情報がないと、環境はこのようになるからです。]
![[áppl~ícát~íóñ d~épéñ~déñc~ý máp~ úñst~rúct~úréd~]](https://cdn.prod.website-files.com/63e25fb5e66132e6387676dc/654d5358816172eb9b1764b6_application-dependency-map-unstructured.png)
[CMDB~はラベル作成のすべてではない]
[組織が直面する主な問題の1つは、命名衛生です。システムが進化し、人員が変わるにつれて、命名規則も変化します。]
[たとえば、「プロダクション」として始まったものが「プロダクション」になり、次に「プロダクション」になります。つまり、ゼロトラストポリシーを適用するルールは、最初に書き込まれたときと名前が変わると時代遅れになってしまう可能性があるということです。]
[また、フリーテキスト形式のラベル付けでは、ルール作成に多くの矛盾が生じる可能性があります。リソースのラベル付けが不正確だったり、限定的だったりすると、環境を理解するのが難しくなることは間違いありません。]
[ポリシーの適用は、CMDB~またはその他の情報リポジトリの正確性または完全性によって制限されるべきではありません。命名に一貫性がない場合は、これを回避する方法があるはずです。]
[CMDB~を持っていない人にとっては、もっとシンプルなものを使用しても問題はありません。たとえば、ほとんどのシステムでは.CSV 形式でデータをインポートおよびエクスポートできるため、データを管理するための非常にポータブルな方法となっています。]
[Íllú~míóがワークロードのラベル付けを簡素化および自動化する方法]
[イルミオは、ゼロトラストセグメンテーションポリシーの命名と適用プロセスを大幅に簡素化するシンプルなツールセットを開発しました。ツールを持つことはソリューションの一部であると言わざるを得ません。ツールを正しく適用することが違いを生むのです。]
[ゼロトラストを実装する鍵は一貫性です。構造化された命名規則により、セキュリティポリシーをさまざまな環境 (さまざまな環境など) 間で移植できます。 ハイパーバイザー とクラウド)。]
[たとえば、ÍP アドレスモデルは常に同じなので機能します。ネットワークに接続されているすべてのデバイスは ÁÁ~Á.BBB~.CCC.D~DD/XX~ という形式を想定しています。これがなければ、どのような形の通信も成り立ちません。ワークロードのラベル付けについても同じことが言えます。一貫したモデルがないと、組織のセキュリティが危険にさらされる可能性があります。]
[Íllú~míóは、いくつかの簡単なステップでネーミングプロセスを合理化します。]
- [ステップ 1: CMDB~、スプレッドシート、タグのリスト (またはこれらすべての組み合わせ) のいずれであっても、どの組織にも「信頼できる情報源」があります。完全に正確ではないと思っても、Íllú~míó は各ワークロードからメタデータを収集し、ネットワークとワークロードからデータを自動的に更新できます。]
- [ステップ 2: ネットワークからの情報を使用してください。たとえば、本番サーバーは開発サーバーとは異なるサブネットに存在する可能性があります。ÍP アドレスを使用してルールを作成し始めるのは現実的ではありませんが、ネットワーク情報は名前を生成するための良い出発点となります。]
- [ステップ 3: ホスト名を使用してください。時間が経つにつれて不整合が蓄積されてきたとしても、文字列の一貫した部分を特定し、それをできるだけ多くのワークロードで解析することで、ギャップを埋めることができます。この情報は、ほぼすべてのソースから取得できます。]
[ここまでで、既存の信頼できる情報源から潜在的な環境を発見し、Wéb や D~átáb~ásé などのサーバの役割を強調できるホスト名情報を特定しました。]
[これらの手順を完了すると、トラフィックフロー情報を使用して、他の手順では見られなかった可能性のあるコアサービスやその他の機能について学習し、特定できます。これは、未知ではあるが重要なサーバーを特定するのに役立ちます。]
[これらすべての知識があれば、各ワークロードにラベルを簡単に適用でき、それを使用してワークロード間の通信を視覚化し、ゼロトラストセグメンテーションポリシーを適用できます。]
[構造化されたラベリングにより、環境のマップはこのようになりました。]
![[áppl~ícát~íóñ d~épéñ~déñc~ý máp~ lábé~ls]](https://cdn.prod.website-files.com/63e25fb5e66132e6387676dc/654d5358816172eb9b176488_app-dependency-map-labels.png)
[ワークロードにラベルを付けるプロセスが簡単になればなるほど、マップもシンプルになり、セグメンテーションから真の価値をすばやく得ることができます。]
[もちろん、これらのステップはどのような順序で実行してもかまいません。一部のベンダーは、トラフィック学習を第一歩と位置付けています。ここで問題となるのは、認識されたポートで大量のフローが生成されているという理由だけで、通信が正当に見える可能性があるということです。そうなると、結果の潜在的な不正確さが元に戻されるまでには長い時間がかかることがあります。これにより、マップのクリーンアップに時間がかかるため、値に達するまでのプロセスが遅くなります。最初に固定情報を使用する方がはるかに簡単で安全です。]
[のシンプルなツールを使用する イルミオコア、必要なデータを簡単に収集し、ラベル付けのプロセスを自動化できます。このアプローチにより、セキュリティポリシーの特定と展開におけるデータ不足や潜在的な複雑さに関する懸念がなくなります。]
[さらに詳しく知るには:]
- [読む マイクロセグメンテーションのラベリングを簡素化するための5つのヒント。]
- [をダウンロード イルミオコアの概要 ゼロトラストセグメンテーションに対するイルミオのアプローチの詳細については、こちらをご覧ください。]