ゼロトラストの運用化 – ステップ 5: ポリシーを設計する

このブログシリーズは、3月の投稿「ゼロトラストは難しくありません...現実的であれば。」

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

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

ステップ 5: ポリシーを設計する

このシリーズの 前回の投稿 では、「必要なデータを処方する」について見てきました。この記事では、次の点を指摘しました。

「ゼロトラストの最も重要な側面の1つは、ゼロトラストを効果的に実装するには、ポリシーの策定を支援するコンテキスト情報(メタデータ)へのアクセスに依存していることです。したがって、ワークロードを保護するという文脈でマイクロセグメンテーションについて話す場合、必要な標準トラフィックレポート以外の最小限のメタデータは、データセンターのアプリケーションと環境のコンテキストでのワークロードを記述します。」

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

1. 保護するワークロードのリアルタイムトラフィックイベント。
2. 各ワークロードと接続のコンテキスト データ – これには、CMDB などのレコード システムから取得されるワークロードに関連付けられたメタデータと、ワークロードから直接取得される通信プロセスの詳細などの情報が含まれます。'
3. An アプリケーション依存関係マップ (項目1と2から派生)により、アプリケーション所有者またはセグメンテーション担当者は、特定のアプリケーションの上流および下流の依存関係をすばやく視覚化できます。

すべてをまとめる

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

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

私が「必要」と言ったデータに続いて、ポリシーの作成に使用できるいくつかのトラフィックログエントリの例を以下に示します。

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

• ソース: 10.0.0.1, 10.0.0.2
• ソースコンテキスト: Web サーバー、支払アプリケーション、本番環境、英国
• 宛先: 192.168.0.1
• 宛先: コンテキスト: DNS レスポンダー、DNS インフラストラクチャ、本番環境、英国 o 宛先プロセス: 名前付き
• ポート: 53
• プロトコル: UDP
• アクション: 許可

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

• ソース: 10.0.0.1,10.0.0.2
• ソースコンテキスト: Web サーバー、支払アプリケーション、本番環境、英国
• 宛先:10.0.1.5、10.0.1.6、10.0.1.7
• 宛先コンテキスト: アプリケーションサーバー、支払アプリケーション、本番環境、英国
• 宛先プロセス: tomcat
• ポート: 8080
• Protocol: 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
• Protocol: TCP
• アクション: 許可

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

• ソース:10.1.2.1,10.1.2.2
• ソースコンテキスト: データベースサーバー、支払アプリケーション、本番、ドイツ
• 宛先:10.0.1.5、10.0.1.6、10.0.1.7
• 宛先コンテキスト: アプリケーションサーバー、支払アプリケーション、本番環境、英国
• 宛先プロセス: httpd
• ポート: 80
• Protocol: TCP
• アクション: 許可

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

今のところ大丈夫です。

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

1. Web サーバー、支払い、本番環境、英国 - > DNS レスポンダー、DNS インフラストラクチャ、本番環境、英国 53/udp
2. アプリサーバー、支払い、本番環境、英国 - > DNS レスポンダー、DNS インフラストラクチャ、本番環境、英国 53/udp
3. Web サーバー、支払い、本番環境、英国 -> アプリサーバー、支払い、本番、英国 8080/tcp

また、次の 2 つのフローは正しく表示されないため、最初のルールに含めるべきではないこともわかっています。

1. Web サーバー、支払い、生産、ドイツ -> アプリサーバー、支払い、生産、英国 80/tcp
2. DBサーバー、支払い、本番、ドイツ->アプリサーバー、支払い、本番、英国80 / tcp

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

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

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

これを念頭に置いて、ゼロトラストポリシーは、次のルールに要約されます。

ルール1:

• 出典: Web サーバー、支払い、生産、英国
• 宛先: DNS レスポンダー、DNS インフラストラクチャ、本番環境、英国
• 宛先サービス:53/udp
• 宛先プロセス: 名前付き

ルール2:

• 出典: App Server, Payments, Production, UK
• 宛先: DNS レスポンダー、DNS インフラストラクチャ、本番環境、英国
• 宛先サービス:53/udp
• 宛先プロセス: 名前付き

ルール3:

• 出典: Web サーバー、支払い、生産、英国
• 宛先: アプリサーバー、支払い、本番、英国
• 宛先サービス:8080/tcp
• 宛先プロセス: tomcat

以上です。

ゼロトラストへの取り組みの次のステップに進む準備はできていますか?マイクロセグメンテーションを使用してゼロトラスト戦略を運用し、内部スクープを入手する方法については、 当社のページ をご覧ください。