マイクロセグメンテーション入門 - ネットワークの細分化による防御強化

従来のネットワークセキュリティは、境界防御（北南トラフィック）に重点を置いてきました。しかし、一度境界を突破されると、内部ネットワーク（東西トラフィック）での攻撃者の横移動（ラテラルムーブメント）を防ぐことが困難でした。この課題を解決するのがマイクロセグメンテーションです。

本記事では、マイクロセグメンテーションについて以下の内容を解説します。

• マイクロセグメンテーションの概念と従来のネットワークセグメンテーションとの違い
• フラットネットワークが抱えるセキュリティリスク
• セグメント設計の基本的な考え方とベストプラクティス
• SDN（ソフトウェア定義ネットワーク）との関係性
• ホストベースとネットワークベースの実装アプローチ

この記事を読むことで、マイクロセグメンテーションの必要性を理解し、ゼロトラスト時代に適したネットワーク分割の設計指針を策定できるようになります。

前提知識

本記事を理解するために、以下の知識があることを前提としています。

• ネットワークの基本概念（VLAN、サブネット、ファイアウォール）を理解している
• ゼロトラストの基本原則を把握している
• TCP/IPの基礎知識がある

ゼロトラストの基本原則については、ゼロトラストセキュリティ入門 - 基本原則と7つの柱を理解するを先に読むことをお勧めします。

期待される学習成果

本記事を読み終えると、以下のことができるようになります。

1. マイクロセグメンテーションの定義と目的を説明できる
2. フラットネットワークのリスクを具体的に説明できる
3. 北南トラフィックと東西トラフィックの違いを理解できる
4. セグメント設計の基本方針を策定できる
5. 実装アプローチを比較し、適切な選択ができる

マイクロセグメンテーションとは何か

マイクロセグメンテーションは、ネットワークを細かいセグメント（区画）に分割し、各セグメントに対して個別のセキュリティポリシーを適用するネットワークセキュリティ手法です。ゼロトラストセキュリティの重要な構成要素であり、「最小権限の原則」をネットワークレベルで実現します。

従来のネットワークセグメンテーションとの違い

従来のネットワークセグメンテーションとマイクロセグメンテーションには、明確な違いがあります。

flowchart TB
    subgraph traditional["従来のネットワークセグメンテーション"]
        direction TB
        fw1["ファイアウォール"]
        
        subgraph vlan1["VLAN 10: Webサーバー"]
            web1["Web1"]
            web2["Web2"]
        end
        
        subgraph vlan2["VLAN 20: APサーバー"]
            ap1["AP1"]
            ap2["AP2"]
        end
        
        fw1 --> vlan1
        fw1 --> vlan2
        web1 <-.->|"制御なし"| web2
        ap1 <-.->|"制御なし"| ap2
    end
    
    subgraph micro["マイクロセグメンテーション"]
        direction TB
        
        subgraph seg1["セグメント1"]
            mweb1["Web1"]
        end
        
        subgraph seg2["セグメント2"]
            mweb2["Web2"]
        end
        
        subgraph seg3["セグメント3"]
            map1["AP1"]
        end
        
        subgraph seg4["セグメント4"]
            map2["AP2"]
        end
        
        mweb1 -->|"許可されたトラフィックのみ"| map1
        mweb2 -->|"許可されたトラフィックのみ"| map2
    end

北南トラフィックと東西トラフィック

ネットワークトラフィックは、その方向性によって2種類に分類されます。

北南トラフィック（North-South Traffic）

クライアントとサーバー間、つまり外部ネットワークと内部ネットワーク間を流れるトラフィックです。従来のファイアウォールは、この北南トラフィックの制御に特化していました。

東西トラフィック（East-West Traffic）

データセンターやクラウド環境内部で、ワークロード間を流れるトラフィックです。現代のデータセンターでは、東西トラフィックが全体の80%以上を占めるといわれています。

flowchart TB
    subgraph external["外部ネットワーク"]
        client["クライアント"]
    end
    
    subgraph perimeter["境界防御"]
        fw["ファイアウォール"]
    end
    
    subgraph internal["内部ネットワーク"]
        direction LR
        web["Webサーバー"]
        app["APサーバー"]
        db["DBサーバー"]
        
        web <-->|"東西トラフィック"| app
        app <-->|"東西トラフィック"| db
    end
    
    client -->|"北南トラフィック"| fw
    fw -->|"北南トラフィック"| web

マイクロセグメンテーションは、この東西トラフィックを可視化し、制御することで、内部ネットワークにおけるセキュリティを大幅に強化します。

フラットネットワークのリスク

多くの組織では、内部ネットワークがフラット（平坦）な構成になっています。フラットネットワークでは、一度内部に侵入した攻撃者が自由に移動できるため、重大なセキュリティリスクを抱えています。

フラットネットワークとは

フラットネットワークとは、内部のすべてのシステムが同一のネットワークセグメントに配置され、相互に自由に通信できる状態を指します。管理が容易で通信の遅延が少ないというメリットがありますが、セキュリティ上は大きな脆弱性となります。

flowchart TB
    subgraph flat["フラットネットワーク（同一セグメント）"]
        direction TB
        
        attacker["侵入した攻撃者"]
        
        subgraph targets["すべてのシステムにアクセス可能"]
            web["Webサーバー"]
            app["APサーバー"]
            db["DBサーバー"]
            file["ファイルサーバー"]
            ad["Active Directory"]
        end
        
        attacker -->|"自由に移動可能"| web
        attacker -->|"自由に移動可能"| app
        attacker -->|"自由に移動可能"| db
        attacker -->|"自由に移動可能"| file
        attacker -->|"自由に移動可能"| ad
    end

ラテラルムーブメント（横移動）の脅威

ラテラルムーブメント（Lateral Movement）とは、攻撃者が最初に侵害したシステムを足がかりに、ネットワーク内を横方向に移動し、より価値の高いターゲットに到達する攻撃手法です。

フラットネットワークでは、以下の理由からラテラルムーブメントが容易になります。

1. 無制限の内部通信: すべてのシステムが相互に通信可能
2. 可視性の欠如: 東西トラフィックの監視が困難
3. 検知の遅延: 正当な通信と攻撃の区別が困難
4. 被害の拡大: 一度侵入されると全システムが危険にさらされる

実際のインシデント事例から学ぶ

多くの重大なセキュリティインシデントでは、ラテラルムーブメントが攻撃の成功に大きく寄与しています。

典型的な攻撃シナリオ

flowchart LR
    subgraph phase1["フェーズ1: 初期侵入"]
        phish["フィッシングメール"]
        endpoint["従業員端末を侵害"]
    end
    
    subgraph phase2["フェーズ2: 横移動"]
        recon["内部偵察"]
        cred["認証情報の窃取"]
        spread["他システムへ侵入"]
    end
    
    subgraph phase3["フェーズ3: 目標達成"]
        target["重要データに到達"]
        exfil["データ窃取/暗号化"]
    end
    
    phish --> endpoint
    endpoint --> recon
    recon --> cred
    cred --> spread
    spread --> target
    target --> exfil

このような攻撃に対して、マイクロセグメンテーションは以下の効果を発揮します。

• 移動範囲の制限: 各セグメント間の通信を厳密に制御
• 異常検知の向上: 許可されていない通信を即座に検知
• 被害の局所化: 侵害されても影響範囲を最小限に抑制
• フォレンジックの支援: 通信ログによる追跡が容易

セグメント設計の考え方

効果的なマイクロセグメンテーションを実現するには、適切なセグメント設計が不可欠です。ここでは、設計の基本原則と具体的なアプローチを解説します。

セグメント設計の基本原則

マイクロセグメンテーションの設計では、以下の原則に従います。

原則1: デフォルト拒否（Deny by Default）

すべての通信をデフォルトで拒否し、明示的に許可されたトラフィックのみを通過させます。これにより、不要な通信経路を排除できます。

原則2: 最小権限アクセス（Least Privilege）

各ワークロードには、業務に必要な最小限の通信のみを許可します。

原則3: アプリケーション中心の設計

IPアドレスやポートではなく、アプリケーションの要件に基づいてポリシーを設計します。

セグメント分割の粒度

セグメントの分割粒度は、セキュリティ要件と運用負荷のバランスを考慮して決定します。

flowchart TB
    subgraph env["環境別セグメンテーション"]
        direction LR
        prod["本番環境"]
        dev["開発環境"]
        test["テスト環境"]
    end
    
    subgraph tier["層別セグメンテーション（本番環境内）"]
        direction TB
        webtier["Webティア"]
        apptier["APティア"]
        dbtier["DBティア"]
        
        webtier -->|"HTTP/HTTPS"| apptier
        apptier -->|"TCP/3306"| dbtier
    end
    
    subgraph app["アプリケーション別セグメンテーション"]
        direction LR
        crm["CRMアプリ"]
        erp["ERPアプリ"]
        hr["HRアプリ"]
    end

ポリシー設計のベストプラクティス

効果的なセグメンテーションポリシーを設計するためのベストプラクティスを紹介します。

1. 通信フローの可視化から始める

現状のトラフィックを把握せずにポリシーを設計すると、必要な通信を遮断してしまう可能性があります。まず、アプリケーション間の通信フローを可視化します。

2. ラベルベースのポリシーを採用する

IPアドレスベースのポリシーは、動的な環境では管理が困難です。環境（env=prod）、アプリケーション（app=crm）、役割（role=web）などのラベルを使用します。

3. 段階的に適用する

いきなり厳格なポリシーを適用するのではなく、以下の段階で進めます。

flowchart LR
    subgraph stages["段階的導入アプローチ"]
        s1["フェーズ1<br/>監視モード"]
        s2["フェーズ2<br/>アラートモード"]
        s3["フェーズ3<br/>一部適用"]
        s4["フェーズ4<br/>完全適用"]
    end
    
    s1 -->|"通信パターン学習"| s2
    s2 -->|"ポリシー調整"| s3
    s3 -->|"段階的拡大"| s4

4. 例外管理プロセスを確立する

業務要件により一時的にポリシーを緩和する必要がある場合の承認プロセスを定義します。

SDN（ソフトウェア定義ネットワーク）との関係

マイクロセグメンテーションの実現には、SDN（Software-Defined Networking）技術が重要な役割を果たします。

SDNの基本概念

SDNは、ネットワークの制御プレーン（Control Plane）とデータプレーン（Data Plane）を分離し、ソフトウェアでネットワークを集中管理する技術です。

flowchart TB
    subgraph control["制御プレーン"]
        controller["SDNコントローラー"]
        policy["ポリシーエンジン"]
        
        controller <--> policy
    end
    
    subgraph data["データプレーン"]
        direction LR
        sw1["仮想スイッチ1"]
        sw2["仮想スイッチ2"]
        sw3["仮想スイッチ3"]
    end
    
    controller -->|"ポリシー配布"| sw1
    controller -->|"ポリシー配布"| sw2
    controller -->|"ポリシー配布"| sw3
    
    sw1 <-->|"トラフィック"| sw2
    sw2 <-->|"トラフィック"| sw3

SDNがマイクロセグメンテーションを可能にする理由

従来の物理ネットワークでは、セグメント変更のたびにハードウェア設定の変更が必要でした。SDNにより、以下のことが可能になります。

1. 動的なポリシー適用

ワークロードの作成・変更・削除に応じて、リアルタイムでセキュリティポリシーを適用できます。

2. 論理的なセグメント作成

物理的なネットワーク構成に依存せず、論理的にセグメントを作成できます。

3. 一元管理

複数のデータセンターやクラウド環境にまたがるポリシーを一元的に管理できます。

主要なSDNソリューション

マイクロセグメンテーションを実現する主要なSDNソリューションには、以下があります。

実装アプローチの比較

マイクロセグメンテーションの実装には、大きく分けて3つのアプローチがあります。それぞれの特徴と適用場面を理解することで、適切な選択が可能になります。

ホストベースアプローチ

ホストベースアプローチは、各ワークロード（VM、コンテナ、物理サーバー）にエージェントをインストールし、ホスト上のファイアウォール（iptables、Windows Firewall など）を制御する方式です。

メリット

• ワークロード単位の細かな制御が可能
• ネットワーク構成に依存しない
• ワークロードの移動に追従できる

デメリット

• エージェントのインストール・管理が必要
• レガシーシステムへの適用が困難な場合がある
• エージェント自体が攻撃対象になる可能性

主要な製品: Illumio、Guardicore（Akamai）、Carbon Black

ネットワークベースアプローチ

ネットワークベースアプローチは、仮想スイッチやSDNコントローラーでトラフィックを制御する方式です。

メリット

• エージェント不要でワークロードへの影響が少ない
• ネットワーク機器の機能を活用できる
• 高いパフォーマンス

デメリット

• 特定のハイパーバイザーやネットワーク機器に依存
• 暗号化されたトラフィックの検査が困難
• 物理サーバーへの適用が制限される場合がある

主要な製品: VMware NSX、Cisco ACI、Juniper Contrail

クラウドネイティブアプローチ

クラウドネイティブアプローチは、クラウドプロバイダーが提供するセキュリティ機能を活用する方式です。

メリット

• クラウド環境との高い親和性
• 追加コストが抑えられる
• クラウドプロバイダーによる運用・保守

デメリット

• クラウドプロバイダーごとに異なる実装
• オンプレミスとの統合が困難
• 機能の制約がある

主要な機能: AWS Security Groups、Azure NSG/ASG、GCP Firewall Rules

実装アプローチの選定基準

環境や要件に応じて、適切なアプローチを選定します。

flowchart TB
    start["実装アプローチの選定"]
    
    q1{"環境は?"}
    q2{"エージェント<br/>導入可能?"}
    q3{"SDN基盤<br/>あり?"}
    
    host["ホストベース"]
    network["ネットワークベース"]
    cloud["クラウドネイティブ"]
    hybrid["ハイブリッド"]
    
    start --> q1
    q1 -->|"クラウドのみ"| cloud
    q1 -->|"オンプレミス/ハイブリッド"| q2
    
    q2 -->|"可能"| host
    q2 -->|"困難"| q3
    
    q3 -->|"あり"| network
    q3 -->|"なし"| hybrid

多くの組織では、単一のアプローチではなく、複数のアプローチを組み合わせたハイブリッド実装が現実的な選択肢となります。

マイクロセグメンテーションの導入ステップ

マイクロセグメンテーションを組織に導入する際の実践的なステップを解説します。

ステップ1: 現状把握と可視化

まず、現在のネットワーク構成とトラフィックパターンを把握します。

flowchart LR
    subgraph discovery["ディスカバリーフェーズ"]
        asset["資産の洗い出し"]
        flow["通信フロー分析"]
        dep["依存関係マッピング"]
    end
    
    asset --> flow --> dep

実施すべき作業は以下のとおりです。

• ネットワーク上のすべての資産（サーバー、アプリケーション）を特定
• アプリケーション間の通信フローを可視化
• 業務に必要な通信と不要な通信を識別
• 重要資産とその保護優先度を決定

ステップ2: セグメント設計

可視化した情報をもとに、セグメント設計を行います。

考慮すべき要素は以下のとおりです。

• 機密性: データの機密度に応じたセグメント分離
• 規制要件: PCI DSS、HIPAAなどの規制対象システムの分離
• 業務要件: 業務プロセスに必要な通信の確保
• 運用性: 管理可能な粒度の設定

ステップ3: ポリシー定義

各セグメント間の通信ポリシーを定義します。

1
2
3
4
5
6
7
8
9

# ポリシー定義例（概念的な記述）
セグメント: Web層
許可する受信:
  - ソース: ロードバランサー, ポート: 443
  - ソース: 監視サーバー, ポート: 9100
許可する送信:
  - 宛先: AP層, ポート: 8080
  - 宛先: ログサーバー, ポート: 514
デフォルト: 拒否

ステップ4: 段階的な適用

定義したポリシーを段階的に適用します。

1. 監視モード: ポリシーを適用せず、違反トラフィックを記録
2. アラートモード: 違反時にアラートを発報（通信は許可）
3. 一部ブロック: 低リスクなセグメントから適用開始
4. 全面適用: 全セグメントにポリシーを適用

ステップ5: 継続的な運用と改善

マイクロセグメンテーションは導入して終わりではありません。継続的な運用と改善が必要です。

• 新規アプリケーション追加時のポリシー設定プロセス
• 定期的なポリシーレビューと不要ルールの削除
• セキュリティインシデント発生時のポリシー見直し
• クラウド移行などの環境変化への対応

Kubernetes環境でのマイクロセグメンテーション

コンテナとKubernetesの普及により、マイクロセグメンテーションの実装方法も進化しています。

Kubernetesにおける課題

Kubernetes環境では、以下の特性がマイクロセグメンテーションを複雑にします。

• 動的なIPアドレス: Podは短命でIPアドレスが頻繁に変わる
• 高速なスケーリング: 数秒でPodが起動・終了
• サービスメッシュ: サービス間通信の抽象化
• ネームスペース: 論理的な分離の概念

NetworkPolicyによる実装

Kubernetesは、NetworkPolicyリソースによるマイクロセグメンテーションをサポートしています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: web-tier-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      tier: web
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: ingress-nginx
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              tier: app
      ports:
        - protocol: TCP
          port: 8080
    - to:
        - namespaceSelector:
            matchLabels:
              name: monitoring
      ports:
        - protocol: TCP
          port: 9090

このNetworkPolicyは以下の制御を行います。

• tier: webラベルを持つPodに適用
• Ingressはingress-nginxネームスペースからの8080/TCPのみ許可
• Egressはtier: appのPodとmonitoringネームスペースのみ許可

CNI（Container Network Interface）プラグインの選択

NetworkPolicyを実際に適用するには、対応するCNIプラグインが必要です。

まとめ

マイクロセグメンテーションは、ゼロトラストセキュリティを実現するための重要な技術です。本記事で解説した内容を振り返ります。

マイクロセグメンテーションの本質

• ネットワークを細かいセグメントに分割し、東西トラフィックを制御する
• フラットネットワークのリスク（ラテラルムーブメント）を軽減する
• 「デフォルト拒否」と「最小権限」の原則に基づく

設計と実装のポイント

• 通信フローの可視化から始める
• ラベルベースのポリシー設計を採用する
• 段階的に導入し、継続的に改善する

実装アプローチの選択

• ホストベース: ワークロード単位の細かな制御
• ネットワークベース: SDN環境での効率的な実装
• クラウドネイティブ: クラウド環境との高い親和性
• 多くの場合、ハイブリッドアプローチが現実的

マイクロセグメンテーションの導入は、一朝一夕には完了しません。しかし、適切な計画と段階的な実装により、組織のセキュリティ態勢を大幅に強化できます。次のステップとして、VPNからZTNA（ゼロトラストネットワークアクセス）への移行ガイドで、ネットワークアクセスの近代化についても学んでいきましょう。

参考リンク

• NIST SP 800-207 Zero Trust Architecture
• Palo Alto Networks - What Is Microsegmentation?
• Cisco - What is Micro-segmentation?
• VMware - What is Micro-Segmentation?
• Kubernetes Network Policies
• Forrester - The Forrester Wave: Microsegmentation Solutions