configuring-microsegmentation-for-zero-trust

ゼロトラスト向けマイクロセグメンテーションの設定

前提条件

• ゼロトラストの原則（NIST SP 800-207）を理解していること
• ネットワークセグメンテーションの概念に関する知識
• ファイアウォールと SDN 技術に精通していること
• VMware NSX、Illumio、Guardicore、または Cisco ACI の使用経験

概要

マイクロセグメンテーションでは、ネットワークをきめ細かなセキュリティゾーンに分割し、従来の VLAN ベースのセグメンテーションに頼るのではなく、アプリケーションレイヤーでワークロード間の最小権限アクセスを適用します。ゼロトラストアーキテクチャでは、マイクロセグメンテーションによって同じネットワークセグメント内のワークロード間にある暗黙の信頼が排除され、攻撃者が最初のアクセスを獲得した後のラテラルムーブメントも防止されます。

このスキルでは、ワークロードのアイデンティティを使用したマイクロセグメンテーションポリシーの設計、ホストベースおよびネットワークベースの適用の実装、Illumio Core や VMware NSX などのツールを使用したセグメンテーションの有効性の検証を扱います。

使用する場面

• 環境でゼロトラスト機能を実現するために、マイクロセグメンテーションを導入または設定する場合
• コンプライアンス要件に沿ったセキュリティコントロールを確立する場合
• この分野のセキュリティアーキテクチャを構築または改善する場合
• この実装を必要とするセキュリティ評価を実施する場合

前提条件

• ゼロトラストアーキテクチャの概念とツールに精通していること
• 安全に実行できるテスト環境またはラボ環境へのアクセス
• 必要な依存関係をインストールした Python 3.8 以降
• テスト活動に必要な適切な認可

アーキテクチャ

マイクロセグメンテーションモデル

1. ネットワークベース（VMware NSX、Cisco ACI）：ハイパーバイザーまたはネットワークファブリックレベルで適用される分散ファイアウォールルール
2. ホストベース（Illumio、Guardicore）：iptables/WFP ルールを使用して OS レベルで適用するエージェントベースの方式
3. コンテナベース（Calico、Cilium）：Kubernetes のポッド／コンテナレベルで適用するネットワークポリシー
4. アプリケーションベース（Zscaler Workload Segmentation）：IP アドレスではなくソフトウェアのアイデンティティに基づくアイデンティティベースのセグメンテーション

適用ポイント

Traditional Segmentation        Microsegmentation
┌─────────────────┐            ┌──────────────────────┐
│  VLAN 10        │            │  Workload A ←policy→ │
│  ┌───┐ ┌───┐   │            │  Workload B ←policy→ │
│  │ A │ │ B │   │            │  Workload C ←policy→ │
│  └───┘ └───┘   │            │  Workload D ←policy→ │
│  (trust each    │            │  (zero trust between  │
│   other)        │            │   every pair)         │
└─────────────────┘            └──────────────────────┘

主要な概念

アプリケーション依存関係マッピング

セグメンテーションポリシーを作成する前に、トラフィックテレメトリを使用してワークロード間の実際の通信フローを検出します。Illumio、Guardicore、AppDynamics などのツールは、どのワークロードがどのポートで、どのくらいの頻度で通信しているかを示すアプリケーション依存関係マップを提供します。

ポリシーのモデリング

適用する前に、ポリシーを監視／可視化モードで作成します。これにより、提案したルールが正当なトラフィックを妨げないことを検証しながら、不要またはリスクのある通信経路を特定できます。

ラベルベースのポリシー

最新のマイクロセグメンテーションでは、IP ベースのルールではなく、ラベル（役割、アプリケーション、環境、場所）を使用します。ラベルベースのポリシーは環境間で移植可能であり、移行時に IP アドレスが変更されても維持されます。

リングフェンシング

重要なアプリケーション（PCI カード会員データ環境、SWIFT 金融システム、医療分野の PHI）を、明示的に許可されていないすべてのトラフィックを拒否する厳格な許可リストポリシーで隔離します。

ワークフロー

フェーズ 1：検出とマッピング

1. 可視化エージェントを導入する

   • すべてのワークロード（サーバー、VM、コンテナ）に軽量エージェントをインストールする
   • エージェントがリアルタイムのトラフィックテレメトリを管理コンソールに報告するよう設定する
   • 包括的なフローマップを構築するため、2～4 週間トラフィックを収集する

2. アプリケーション依存関係マップを構築する

   • 管理コンソールで自動検出された通信フローを確認する
   • アプリケーション層を特定する：Web サーバー、アプリケーションサーバー、データベース、ミドルウェア
   • 正当な通信経路をマッピングし、予期しない接続にフラグを立てる
   • コンプライアンス範囲（PCI、HIPAA）に関するデータフローを文書化する

3. ラベルを割り当てる

   • ラベル分類体系を作成する：役割（web、app、db）、アプリケーション（ERP、CRM）、環境（prod、dev、staging）、場所（dc1、aws-east）
   • 管理コンソールまたは API を通じて、すべてのワークロードにラベルを適用する
   • CMDB とアプリケーション所有者からの情報に照らして、ラベルが正確であることを検証する

フェーズ 2：ポリシー設計

4. セグメンテーションゾーンを定義する

   • 環境の分離：本番環境から開発環境への通信を禁止します
   • 階層の分離：データベース階層では、アプリケーション階層からの接続のみを許可します
   • アプリケーションの隔離：PCI 対応アプリケーションを、非 PCI ワークロードから隔離します
   • 管理アクセス：管理経路を踏み台サーバーのみに限定します

5. 許可リストポリシーを作成する

   • 各アプリケーションについて、必要な通信を明示的に許可するルールを定義します
   • 可能な場合は、IP ベースではなくラベルベースのルールを使用します
   • 対応している場合は、プロセスレベルの制限も設定します（例：ポート 443 では httpd のみ許可）
   • リストにないすべての通信をデフォルトで拒否するよう設定します

6. テストモードでポリシーをモデル化する

   • ポリシーを可視化／テストモードで有効にします（強制適用はしません）
   • 正当な通信がブロックされる可能性のあるケースを監視します
   • 1～2 週間のテスト結果に基づいてポリシーを調整します
   • 強制適用の前に、アプリケーション所有者の承認を得ます

フェーズ 3：強制適用

7. 段階的に強制適用する

   • 最も分離され、リスクが最も低いアプリケーションから開始します
   • ポリシーをテストモードから強制モードに切り替えます
   • 最初の 24～48 時間は、アプリケーションに問題がないか監視します
   • 検証後、次のアプリケーションに進みます

8. セグメンテーションを検証する

   • セグメント間のラテラルムーブメントを試みる侵入テストを実施します
   • ブロックされた通信によって管理コンソールにアラートが生成されることを確認します
   • 緊急時のオーバーライド手順（ブレークグラス）をテストします
   • 各アプリケーションゾーンの強制適用状況を記録します

フェーズ 4：運用保守

9. 継続的なポリシー管理
   • CI/CD と統合し、デプロイパイプラインから新しいワークロードに自動でラベルを付与します
   • 毎週ポリシー違反を確認し、異常を調査します
   • アプリケーションの変更時や新しいサービスのデプロイ時にポリシーを更新します
   • 四半期ごとにセグメンテーションの有効性を確認します

検証チェックリスト

• 対象範囲内のすべてのワークロードにエージェントがデプロイされている
• アプリケーションの依存関係マップが確認され、アプリケーション所有者の承認を得ている
• CMDB と照合してラベルが割り当てられ、検証されている
• 誤検知がないことを確認しながら、2 週間以上テストモードでポリシーがモデル化されている
• 監視を行いながら、ポリシーが段階的に強制適用されている
• セグメント化されたすべてのゾーンでデフォルト拒否が有効になっている
• ラテラルムーブメントテストにより、許可されていない通信がブロックされることを確認している
• ポリシー違反に対するアラートが設定されている
• ブレークグラス手順が文書化され、テストされている
• 規制対象環境で、コンプライアンス監査担当者の承認を得ている

参考資料

• NIST SP 800-207：ゼロトラストアーキテクチャ
• CISA Zero Trust Maturity Model v2.0 - ネットワークの柱
• Illumio Core Administration Guide
• VMware NSX Distributed Firewall Configuration Guide
• Forrester Zero Trust eXtended（ZTX）Framework