ゼロトラストの運用 — ステップ 5: ポリシーの設計

このブログシリーズは、私が3月の投稿で紹介したアイデアを拡張したものです。」ゼロトラストは難しくありません... 現実的であれば。」

その記事では、ゼロトラストを実現するための6つのステップの概要を説明しました。ここでは、そのステップの1つ、つまりポリシーの設計について詳しく説明したいと思います。このステップが、組織の規模に関係なく、マイクロセグメンテーションの実践者なら誰でもプロジェクトをより成功させるために使用できる強固なフレームワークの実装をどのようにサポートできるかを説明します。

始める前に、次の 6 つのステップについて復習しておきます。

ステップ 5: ポリシーの設計

の中に 最終投稿 このシリーズから、「どのようなデータが必要かを規定すること」について見てきました。この記事の中で、私は以下の点を指摘しました。

「ゼロトラストの最も重要な側面の1つは、必要なほどカバーされていないものの、 ゼロトラストを効果的に実施するには、ポリシーの策定に役立つコンテキスト情報またはメタデータへのアクセスが必要です。 つまり、ワークロード保護の観点からマイクロセグメンテーションについて話す場合、データセンターのアプリケーションと環境のコンテキストにおけるワークロードの記述は、標準トラフィックレポート以外に必要な最低限のメタデータです。」

このステートメントに基づいて、必要なデータの 3 つのキービットは次のとおりです。

1. リアルタイムの交通イベント 保護したいワークロードのためです。
2. 各ワークロードと接続のコンテキストデータ — これには、CMDBなどの記録システムから取得されるワークロードに関連するメタデータや、ワークロードから直接供給される通信プロセスの詳細などの情報が含まれます。'
3. あの アプリケーション依存関係マップ （項目1と2から導き出された）これにより、アプリケーションの所有者またはセグメンテーション担当者は、特定のアプリケーションの上流と下流の依存関係をすばやく視覚化できます。

すべてをまとめる

これで、そのポリシーを構築する準備がほぼ整いました。ただし、目標を思い出させてください。

• ワークロードを保護するためのマイクロセグメンテーションポリシーを構築したい。
• このポリシーがゼロトラストの原則に従うことを望んでいます。
• したがって、作成するルールでは、ビジネス機能を実行するために必要なワークロードへのアクセスのみとワークロードからのアクセスを許可する必要があります。

先ほど「必要」と答えたデータに続いて、ポリシーの構築に使用できるトラフィックログエントリの例をいくつか示します。

トラフィックログ接続 1:

• ソース:10.0.0.1、10.0.0.2
• ソースコンテキスト:Web サーバー、支払いアプリケーション、プロダクション、英国
• 目的地:192.168.0.1
• 宛先:コンテキスト:DNS レスポンダー、DNS インフラストラクチャ、プロダクション、英国、または宛先プロセス:名前付き
• ポート:53
• プロトコル:UDP
• アクション:許可

トラフィックログ接続 2:

• ソース:10.0.0.1,10.0.0.2
• ソースコンテキスト:Web サーバー、支払いアプリケーション、プロダクション、英国
• 目的地:10.0.1.5,10.0.1.6,10.0.1.7
• 宛先コンテキスト:アプリケーションサーバー、支払いアプリケーション、プロダクション、英国
• デスティネーションプロセス:トムキャット
• ポート:8080
• プロトコル:TCP
• アクション:許可

トラフィックログ接続 3:

• ソース:10.0.1.5、10.0.1.6,10.0.1.7
• ソースコンテキスト:アプリケーションサーバー、支払いアプリケーション、プロダクション、英国
• 目的地:192.168.0.1
• 宛先:コンテキスト:DNS レスポンダー、DNS インフラストラクチャ、プロダクション、英国
• 宛先プロセス:名前付き
• ポート:53
• プロトコル:UDP
• アクション:許可

トラフィックログ接続 4:

• ソース:10.1.0.1,10.1.0.2
• ソースコンテキスト:Web サーバー、支払いアプリケーション、プロダクション、ドイツ
• 目的地:10.0.1.5,10.0.1.6,10.0.1.7
• 宛先コンテキスト:アプリケーションサーバー、支払いアプリケーション、プロダクション、英国
• デスティネーションプロセス:httpd
• ポート:80
• プロトコル:TCP
• アクション:許可

トラフィックログ接続 5:

• ソース:10.1.2.1,10.1.2.2
• ソースコンテキスト:データベースサーバー、支払いアプリケーション、プロダクション、ドイツ
• 目的地:10.0.1.5,10.0.1.6,10.0.1.7
• 宛先コンテキスト:アプリケーションサーバー、支払いアプリケーション、プロダクション、英国
• デスティネーションプロセス:httpd
• ポート:80
• プロトコル:TCP
• アクション:許可

これを使用すると、アプリケーションの依存関係マップをすばやく導き出すことができます。

これまでのところ、とても良いです。

これで、アプリケーションの依存関係マップを見て、実際に許可したいフローを決定できます。アプリケーションに関する知識に基づいて、たとえば次のフローが必須であることがわかります。

1. Webサーバー、支払い、プロダクション、UK-> DNSレスポンダー、DNSインフラストラクチャ、プロダクション、UK on 53/udp
2. アプリサーバー、支払い、プロダクション、UK-> DNSレスポンダー、DNSインフラストラクチャ、プロダクション、UK on 53/udp
3. Webサーバー、支払い、プロダクション、英国-> 8080/tcpでのアプリケーションサーバー、支払い、プロダクション、英国

また、次の 2 つのフローは適切ではないため、最初のルールに含めるべきではないこともご存知でしょう。

1. Webサーバー、支払い、生産、ドイツ->アプリサーバー、支払い、生産、英国（80/tcp）
2. DBサーバー、支払い、生産、ドイツ->アプリケーションサーバー、支払い、生産、英国（80/tcp）

ルールの作成に使用するアプリケーション依存関係マップは、最終的に次のようになります。

では、これらのルールを実際にどのように表現するのでしょうか？ 従来のファイアウォールでは、送信元と宛先のIPアドレスを使用してこれらを定義する必要がありました。しかし、この方法では、これらのフローを発見したときに得た豊富なコンテキスト情報がすべて完全に削除され、さらに悪いことに、ルールを見直したときにこのコンテキストを再挿入する必要があります。また、支払いアプリ用に DNS レスポンダーや新しいアプリサーバー、ウェブサーバーを追加するとどうなるでしょうか。

ゼロトラストの原則に従ったポリシー、つまり、常に最低限の権限しか与えられないようにするポリシーを構築しようとしているということを覚えておきましょう。適応型セキュリティエンジンがバックグラウンドで魔法のように機能するコンテキストベースのアプローチは、まさにこれを容易にします。つまり、既存のコンテキストを持つ新しいサーバーを組み込むようにポリシーを拡大するのと同じように、サーバーを廃止したときにもポリシーを縮小したいと思うでしょう。たとえば、DNS レスポンダーの 1 つを廃止する場合、それまでその DNS レスポンダーからの/へのアクセスを許可していたすべてのルールを更新して、このアクセスが不可能になるようにする必要があります。これはまさにイルミオのルールです。 ポリシーコンピュートエンジン (PCE) の目的は、メタデータを使用してマイクロセグメンテーションポリシーを定義し、PCEがその特定の時点でどのワークロードがメタデータと一致するかを判断して、ゼロトラストセキュリティ体制を維持するために各ワークロードに適用する必要がある実際のルールを計算することです。状況に変化があるたびに、PCE はポリシーを適応させ、ワークロードに更新を通知します。

これを念頭に置くと、ゼロトラストポリシーは次のルールにまとめられます。

ルール 1:

• 出典：ウェブサーバー、ペイメント、プロダクション、英国
• 送信先:DNS レスポンダー、DNS インフラストラクチャ、プロダクション、英国
• デスティネーションサービス:53/udp
• 宛先プロセス:名前付き

ルール 2:

• 出典：アプリサーバー、ペイメント、プロダクション、英国
• 送信先:DNS レスポンダー、DNS インフラストラクチャ、プロダクション、英国
• デスティネーションサービス:53/udp
• 宛先プロセス:名前付き

ルール 3:

• 出典：ウェブサーバー、ペイメント、プロダクション、英国
• 送信先:アプリサーバー、決済、プロダクション、英国
• デスティネーションサービス:8080/tcp
• デスティネーションプロセス:トムキャット

それでおしまいです。

ゼロトラストへの旅の次の一歩を踏み出す準備はできていますか？をご覧ください 私たちのページ ゼロトラスト戦略をマイクロセグメンテーションで運用化し、内部情報を把握する方法について説明します。