【テクニカル・上級編】Kubernetes NetworkPolicyによるマイクロセグメンテーションの実装 – アプリケーションセキュリティ & 安全な開発防御ガイド

Kubernetes NetworkPolicyによるマイクロセグメンテーション：見えない壁でアプリケーションを守る深淵

サイバー攻撃の最前線は、もはや境界防御だけでは語れない。特にクラウドネイティブ環境、中でもKubernetesはその柔軟性とスケーラビリティの裏側で、攻撃者にとって魅力的な攻撃対象領域（Attack Surface）を広げている。我々が日々直面するXSS（クロスサイトスクリプティング）のようなアプリケーションレイヤーの脆弱性も、その根源には低レイヤのメモリ挙動やプロトコル仕様の欠陥が潜んでいる場合がある。しかし、本稿では、さらにその下、ネットワークレイヤーにおける堅牢な防御戦略、すなわち「Kubernetes NetworkPolicyによるマイクロセグメンテーション」に焦点を当てる。

攻撃者が狙う「平坦なネットワーク」という名の脆弱性

従来のオンプレミス環境では、ファイアウォールやVLANによってネットワークが論理的に分割され、ある程度の「壁」が存在していた。しかし、コンテナ化されたマイクロサービスアーキテクチャが主流となったKubernetes環境では、Pod間の通信がデフォルトで「平坦」になりがちだ。つまり、一度ネットワーク境界を突破されると、攻撃者はクラスタ内の他のPodに比較的容易にアクセスできてしまう。これが、攻撃者にとって最も美味しい「ラテラルムーブメント（横展開）」を可能にする温床となる。

例えば、あるWebアプリケーションのPodにXSS脆弱性が見つかったとしよう。もしネットワークポリシーが適切に設定されていなければ、その脆弱性を突かれた攻撃者は、同じクラスタ内のデータベースPodや、機密情報を扱う別のマイクロサービスPodに容易に侵入できてしまう。これは、まるで堅牢な城壁に穴が開いたら、城内のあらゆる部屋に侵入されるようなものだ。

マイクロセグメンテーションの本質：最小権限のネットワーク原則

ここで登場するのが、Kubernetes NetworkPolicyによるマイクロセグメンテーションだ。これは、「デフォルト拒否」の原則に基づき、Pod間の通信を厳密に制御する仕組みである。具体的には、各Podにネットワークポリシーを適用し、「誰が」「誰と」「どのようなポートで」通信できるのかを明示的に定義する。これにより、必要最小限の通信のみを許可し、それ以外の通信はすべてブロックする。

このアプローチは、攻撃者によるラテラルムーブメントを根本的に困難にする。たとえ一つのPodが侵害されたとしても、その影響範囲はネットワークポリシーによって限定され、他のPodへの感染拡大を防ぐことができる。これは、現代のサイバーセキュリティにおける「ゼロトラスト」の考え方と非常に親和性が高い。

Kubernetes NetworkPolicyの仕組み：ラベルとセレクターの魔法

NetworkPolicyは、KubernetesのAPIオブジェクトとして定義され、YAMLファイルで記述される。その核心となるのは、ラベル（Label）とセレクター（Selector）の概念だ。

• ラベル: PodやNamespaceなどのKubernetesリソースに付与されるキー・バリューペアのメタデータ。例えば、app: frontendやtier: backendといった具合だ。
• セレクター: NetworkPolicyが、どのPodに適用されるか、そしてそのPodが「誰と」通信できるかを定義するために使用するラベルの条件。

1. Pod Selector：ポリシーが適用されるPodを指定する

まず、podSelectorを用いて、そのNetworkPolicyがどのPodに適用されるかを指定する。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: default
spec:
podSelector:
matchLabels:
app: my-app # このラベルを持つPodにポリシーが適用される

この例では、app: my-appというラベルを持つPodに、deny-allというNetworkPolicyが適用される。

2. Policy Types：インバウンド/アウトバウンド通信の制御

policyTypesフィールドで、このポリシーがインバウンド（Ingress）通信に適用されるのか、アウトバウンド（Egress）通信に適用されるのか、あるいは両方に適用されるのかを指定する。

policyTypes:

• Ingress
• Egress

3. Ingress（インバウンド）ポリシー：外部からのアクセスを制御する

ingressセクションで、指定されたPodが「どのPodから」「どのポートで」通信を受け入れられるかを定義する。

• from: 通信元を指定する。podSelectorやnamespaceSelector、あるいはipBlock（CIDR形式）を使用できる。
• ports: 許可するプロトコルとポート番号を指定する。

例：frontend Podは、同じNamespace内のbackend Podからのみ、TCPポート8080で通信を受け入れる

ingress:

• from:
• podSelector:

matchLabels:
tier: backend # 通信元Podのラベルを指定
ports:

• protocol: TCP

port: 8080 # 許可するポート番号

例：frontend Podは、同じNamespace内の別のfrontend Pod（例：APIゲートウェイ）から、TCPポート80で通信を受け入れる

ingress:

• from:
• podSelector:

matchLabels:
app: frontend
role: api-gateway # より詳細なセレクター
ports:

• protocol: TCP

port: 80

例：frontend Podは、特定のIPレンジ（例：社内ネットワーク）からのみ、TCPポート443で通信を受け入れる

ingress:

• ipBlock:

cidr: 192.168.1.0/24 # 許可するIPレンジ
ports:

• protocol: TCP

port: 443

例：全ての通信を拒否する（デフォルト拒否の基盤）

ingressセクションを空にすると、そのPodへの全てのインバウンド通信が拒否される。

ingress: [] # 全てのインバウンド通信を拒否

4. Egress（アウトバウンド）ポリシー：外部への通信を制御する

egressセクションで、指定されたPodが「どのPodへ」「どのポートで」通信を発信できるかを定義する。ingressと同様に、to（通信先）とportsを指定する。

例：backend Podは、同じNamespace内のdatabase Podへ、TCPポート5432（PostgreSQL）で通信のみを発信できる

egress:

• to:
• podSelector:

matchLabels:
app: database
ports:

• protocol: TCP

port: 5432

例：frontend Podは、外部のDNSサーバー（IPアドレス 8.8.8.8）へ、UDPポート53で名前解決のために通信を発信できる

egress:

• to:
• ipBlock:

cidr: 8.8.8.8/32 # 特定のIPアドレス
ports:

• protocol: UDP

port: 53

例：全ての通信を拒否する

egressセクションを空にすると、そのPodからの全ての（明示的に許可されていない）アウトバウンド通信が拒否される。

egress: [] # 全ての（明示的に許可されていない）アウトバウンド通信を拒否

実践：マイクロセグメンテーション導入のステップと考慮事項

1. 現状把握と通信要件の定義: まず、各マイクロサービスが互いにどのような通信を行っているのか、その依存関係を正確に把握する。これは、ログ分析やネットワーク監視ツールを用いて行う。XSS脆弱性を持つアプリケーションであっても、それを修正するまでの間、あるいは修正後も、ネットワークレベルでの防御は不可欠だ。
2. ラベル戦略の策定: PodやNamespaceに一貫性のあるラベルを付与することが、NetworkPolicyの管理を容易にする鍵となる。app, tier, release, environmentなどのラベルを適切に設計する。
3. 「デフォルト拒否」ポリシーの適用: まず、全てのPodに対して、インバウンド・アウトバウンド通信をデフォルトで拒否するポリシーを適用する。これにより、意図しない通信経路をすべて遮断できる。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: <対象のNamespace>
spec:
podSelector: {} # 全てのPodに適用
policyTypes:

• Ingress
• Egress

ingress: [] # 全てのインバウンドを拒否
egress: [] # 全てのアウトバウンドを拒否

注意: このポリシーを適用すると、Kubernetes APIサーバーへの通信などもブロックされる可能性があるため、CNIプラグイン（Calico, Ciliumなど）によっては、特別な考慮が必要な場合がある。また、kube-system Namespaceなどのシステムリソースへの通信は、別途許可する必要がある。
4. 必要最小限の通信許可ポリシーの作成: 次に、各アプリケーションの要件に基づき、必要な通信のみを許可するポリシーを順次作成していく。通信元、通信先、プロトコル、ポートを具体的に指定する。
5. 段階的な導入とテスト: 最初は開発環境やステージング環境でテストを行い、徐々に本番環境へ適用していく。ポリシーの変更は、アプリケーションの動作に影響を与える可能性があるため、慎重なテストが不可欠だ。

脆弱性（CVE）の根本原因との関連性

XSSのようなアプリケーションレイヤーの脆弱性も、その影響範囲をNetworkPolicyで限定できる。例えば、XSS攻撃によってセッションハイジャックが発生したとしても、もしそのセッション情報が外部の認証サーバーや別のAPIにアクセスする必要がある場合、NetworkPolicyでその通信経路がブロックされていれば、攻撃者はさらに攻撃を継続することが難しくなる。

また、低レイヤのメモリ挙動や通信プロトコル仕様の欠陥に起因する脆弱性（例：HTTP/2のハッキング、TLSの脆弱性など）も、NetworkPolicyによって、たとえ脆弱なPodが特定されたとしても、そのPodが他の不正なPodと通信できないようにすることで、被害の拡大を防ぐことができる。

耐量子暗号への移行と生成AIプロンプトインジェクションへの防御

現代のセキュリティアーキテクトは、さらに未来を見据えた設計が求められる。

• 耐量子暗号への移行: 将来的に量子コンピュータが実用化された場合、現在の公開鍵暗号は破られる危険性がある。Kubernetesクラスタ内での暗号化通信（mTLSなど）においても、耐量子暗号アルゴリズムへの移行を視野に入れた設計が必要となる。NetworkPolicy自体は直接的な暗号化には関与しないが、通信経路の制御という観点から、暗号化された通信を許可する際にも、将来的なアルゴリズム変更に対応できる柔軟性を持たせるべきだ。
• 生成AIプロンプトインジェクションへの防御: 生成AIサービスをKubernetes上で提供・利用する場合、プロンプトインジェクションという新たな脅威に直面する。例えば、ユーザーからの入力を受け付けて、それをAIモデルへのプロンプトとして利用するような場合、悪意のあるユーザーが不正なプロンプトを注入し、AIモデルを誤動作させたり、機密情報を漏洩させたりする可能性がある。

NetworkPolicyは、このようなケースで直接的なプロンプトインジェクションを防ぐことはできないが、AIモデルがアクセスできるリソースを限定することで、間接的な防御層を構築できる。

例：AIモデルPodは、外部のインターネットへのEgress通信を一切許可せず、必要な学習データやAPIへのアクセスのみを明示的に許可する。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: ai-model-egress-guardrail
namespace: ai-apps
spec:
podSelector:
matchLabels:
app: ai-model
policyTypes:

• Egress

egress:

• to:
• ipBlock:

cidr: <学習データサーバーのIP>/32
ports:

• protocol: TCP

port: 443 # HTTPS

• to:
• ipBlock:

cidr: <外部APIサーバーのIP>/32
ports:

• protocol: TCP

port: 443
# このポリシーにより、明示的に許可されていないIPアドレスやポートへのEgress通信は全てブロックされる。
# これにより、プロンプトインジェクションによってAIモデルが不正な外部サービスと通信するのを防ぐ。

これは、AIモデルが「壁に囲まれた安全な庭」の中でのみ動作するように制御するイメージだ。

まとめ：見えない壁が、見えない脅威から守る

Kubernetes NetworkPolicyによるマイクロセグメンテーションは、単なるネットワーク設定ではなく、アプリケーションのセキュリティを根本から強化するための戦略的なアプローチだ。攻撃者が最も嫌う「ラテラルムーブメント」を効果的に阻害し、たとえ一部のコンポーネントが侵害されたとしても、その影響範囲を最小限に抑える。

我々セキュリティアーキテクトやチーフホワイトハッカー、テックリードは、常に攻撃者の視点に立ち、システム全体の脆弱性を俯瞰しなければならない。NetworkPolicyは、そのために不可欠な「見えない壁」であり、我々のアプリケーションを、日々巧妙化するサイバー攻撃の脅威から守るための、最も強力な武器の一つと言えるだろう。この技術を深く理解し、適切に実装することで、より安全でレジリエントなシステムを構築することが可能になる。