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

やあ、みんな。セキュリティチーフのSだ。今日は、みんなが日々開発しているWebアプリケーションのセキュリティについて、ちょっと骨太な話をしておこうと思う。特に、Kubernetes環境でアプリを動かしているなら、絶対に耳を傾けてほしい。

Webアプリケーションの脆弱性の中でも、古くて新しい脅威、それが「クロスサイトスクリプティング（XSS）」だ。そして、万が一XSSを許してしまった時、その被害を最小限に抑えるための最後の砦となるのが、Kubernetesの「NetworkPolicy」によるマイクロセグメンテーションだ。

「え、XSSとNetworkPolicyって直接関係あるの？」と思った人もいるかもしれない。実はこれが、インシデント対応の現場で痛い目を見てきた俺だからこそ言える、非常に重要な組み合わせなんだ。今日はその辺を、具体的な攻撃シナリオと防御策、そしてコピペで使える設定例を交えながら、徹底的に解説していく。

—

脆弱性の王様、クロスサイトスクリプティング（XSS）の真の恐ろしさ

まずは基本に立ち返ろう。XSSは、ウェブサイトに悪意のあるスクリプトを注入し、それをユーザーのブラウザ上で実行させる攻撃だ。みんなも「」なんてペイロードは見たことがあるだろう。でも、アラートが表示されるだけなら可愛いものだ。XSSが本当に怖いのは、ユーザーのセッションクッキーを盗んでセッションハイジャックを起こしたり、ユーザーになりすまして機密情報を窃取したり、さらにはユーザーのブラウザを踏み台にして内部ネットワークへの攻撃を仕掛けたりする点にある。

XSSには大きく分けて以下の3種類がある。

1. 反射型XSS (Reflected XSS)

ユーザーから送信された悪意のあるデータが、サーバー側で適切にサニタイズされずにHTMLレスポンスにそのまま「反射」されてしまうタイプだ。
例えば、検索機能で入力された文字列が、結果ページにそのまま表示されるようなケースで発生しやすい。攻撃者は悪意のあるリンクをユーザーにクリックさせることで攻撃を成立させる。

2. 格納型XSS (Stored XSS)

攻撃者が注入した悪意のあるスクリプトが、ウェブサイトのデータベースなどに「格納」され、その後、そのデータが読み込まれるたびに、閲覧した不特定多数のユーザーのブラウザで実行されてしまう最も危険なタイプだ。
掲示板の投稿、ブログのコメント、プロフィール欄など、ユーザーがデータを入力して永続化されるあらゆる場所が攻撃対象になりうる。

3. DOM型XSS (DOM-based XSS)

サーバーを経由せず、クライアントサイドのJavaScriptが、ユーザーから受け取った（またはURLから取得した）データを不適切に処理することで発生するタイプだ。
例えば、URLのハッシュ部分をJavaScriptで直接読み込み、innerHTMLなどを使ってDOMに書き込むような処理で発生しやすい。これはサーバー側のログには残りにくく、検知が難しい場合もある。

—

なぜXSSとNetworkPolicyがタッグを組むのか？

さて、ここからが本題だ。XSSそのものの防御策は、入力値の厳格なサニタイズ、出力時のエスケープ、CSP（Content Security Policy）の導入などが基本中の基本だ。これは絶対に怠ってはいけない。

だが、どんなに注意しても、人間が書くコードにバグはつきものだ。もし、万が一XSSの脆弱性が存在し、攻撃が成功してしまったらどうなるか？

攻撃者は、ユーザーのブラウザ上でJavaScriptを実行できる。この時、攻撃スクリプトはそのブラウザがアクセスできるあらゆるリソースに対してリクエストを送ることができる。具体的には、

  • 同じオリジン（document.domain）内のAPIエンドポイント
  • 外部の攻撃者サーバー
  • そして、もしブラウザから直接アクセス可能な範囲にあるなら、内部の管理ツールやAPI

そう、ここが危険なポイントだ。例えば、攻撃者がXSSを成功させ、ユーザーのブラウザ上で以下のようなJavaScriptを実行したとする。

// PoC: XSSから内部APIへのアクセスを試みる
fetch(‘/api/v1/internal/admin-panel/users’, {
method: ‘GET’,
headers: {
‘X-Requested-With’: ‘XMLHttpRequest’,
‘Authorization’: ‘Bearer ‘ + localStorage.getItem(‘jwt_token’) // もしトークンが漏れていれば
}
})
.then(response => response.json())
.then(data => console.log(‘内部APIから取得した機密情報:’, data))
.catch(error => console.error(‘内部APIへのアクセスエラー:’, error));

// あるいは、特定の内部管理コンソールのURLにリダイレクトさせる
// location.href = ‘http://internal-admin.mycompany.local/dashboard’;

もし、この/api/v1/internal/admin-panel/usersのような内部APIが、WebフロントエンドのPodとは別のPodで動いており、ネットワークレベルでのアクセス制限が全くされていないとしたらどうだろう？攻撃は成功し、内部情報が漏洩したり、不正な操作が行われたりする可能性がある。

まさにこの「万が一」の事態に備え、被害の拡大を防ぐのが、KubernetesのNetworkPolicyによる「マイクロセグメンテーション」の役割だ。

—

最小権限の原則：Kubernetes NetworkPolicyによるマイクロセグメンテーション

従来のネットワークセキュリティは、データセンターの境界にファイアウォールを置いて、外部からの侵入を防ぐ「境界防御」が主流だった。しかし、一度境界を突破されてしまえば、内部ネットワークは「フリーパス」状態となり、横展開されてしまうリスクがあった。

マイクロセグメンテーションは、この考え方を変える。ネットワークを極めて小さな単位（この場合、Pod）で区切り、「デフォルトで全ての通信を拒否する」 というゼロトラストの思想に基づいて、「必要な通信だけを明示的に許可する」 方式だ。これにより、たとえ一つのPodが侵害されても、他のPodへの影響を最小限に抑えることができる。

KubernetesのNetworkPolicyは、このマイクロセグメンテーションを実現するための強力なツールだ。Podに付与された「ラベル」を使って、どのPodがどのPodと通信できるかを細かく制御できる。

NetworkPolicyを導入する前の注意点

NetworkPolicyを機能させるためには、KubernetesクラスターにNetworkPolicyをサポートするCNI（Container Network Interface）プラグインが導入されている必要がある。代表的なものには、Calico、Cilium、Weave Net などがある。お使いのクラスターでどのCNIが使われているか、事前に確認しておこう。

実装ステップ1: デフォルトで全ての通信を拒否する

まず、最も重要な一歩は、該当するNamespace内で全てのPod間の通信をデフォルトで拒否するポリシーを設定することだ。これにより、明示的に許可されていない通信は全てブロックされるようになる。

例えば、web-app-prodというNamespaceにこのポリシーを適用する場合。

default-deny-all.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: web-app-prod # 対象のNamespaceを指定
spec:
podSelector: {} # このNamespace内の全てのPodを対象とする
policyTypes:

  • Ingress # Ingress (受信) 通信を制御
  • Egress # Egress (送信) 通信を制御

# いずれのルールも定義しないことで、デフォルトで全ての通信を拒否する

このYAMLを適用すると、web-app-prod Namespace内のPodは、お互いに、また外部とも一切通信できなくなる。かなりインパクトが大きいので、本番環境に適用する前に十分なテストが必要だ。

kubectl apply -f default-deny-all.yaml

実装ステップ2: 必要な通信を明示的に許可する

デフォルトで全てを拒否したら、次にアプリケーションが動作するために必要な通信だけを許可していく。ここでは典型的なWebアプリケーションの構成を例に見ていこう。

ケーススタディ1: WebフロントエンドからAPIバックエンドへの通信許可

Webフロントエンド（Nginx/Apache + PHP-FPM, Node.jsなど）が、APIバックエンドサービスにリクエストを送る必要がある。

  • Webフロントエンド Podのラベル: app: frontend
  • APIバックエンド Podのラベル: app: backend

allow-frontend-to-backend.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-backend
namespace: web-app-prod
spec:
podSelector:
matchLabels:
app: backend # 許可したい通信の「受信側」Podを指定（APIバックエンド）
policyTypes:

  • Ingress # 受信ルールを定義

ingress:

  • from:
  • podSelector:

matchLabels:
app: frontend # 「送信側」Podを指定（Webフロントエンド）
ports:

  • protocol: TCP

port: 8080 # APIバックエンドがリッスンしているポート

このポリシーは、「app: backendラベルを持つPod（APIバックエンド）は、app: frontendラベルを持つPod（Webフロントエンド）からのTCP 8080ポートへのIngress通信を許可する」という意味になる。

ケーススタディ2: APIバックエンドからデータベースへの通信許可

APIバックエンドがデータベースPod（PostgreSQL, MySQLなど）にアクセスする必要がある。

  • APIバックエンド Podのラベル: app: backend
  • データベース Podのラベル: app: database

allow-backend-to-database.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-backend-to-database
namespace: web-app-prod
spec:
podSelector:
matchLabels:
app: database # 許可したい通信の「受信側」Podを指定（データベース）
policyTypes:

  • Ingress

ingress:

  • from:
  • podSelector:

matchLabels:
app: backend # 「送信側」Podを指定（APIバックエンド）
ports:

  • protocol: TCP

port: 5432 # PostgreSQLのデフォルトポート
# – port: 3306 # MySQLのデフォルトポート

ケーススタディ3: 監視ツール（Prometheusなど）からのメトリクス収集許可

Prometheusのような監視ツールが、各アプリケーションPodのメトリクスエンドポイント（例: /metrics）にアクセスする必要がある。

  • 監視ツール Podのラベル: app: monitoring
  • アプリケーション Podのラベル: app: frontend または app: backend

allow-monitoring-to-apps.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-monitoring-to-apps
namespace: web-app-prod
spec:
podSelector:
matchLabels:
# 監視対象となる全てのアプリケーションPodを対象とする
# 例としてfrontendとbackendの両方にアクセス許可
app: frontend # もしくは app: backend など、監視対象のPodラベル
policyTypes:

  • Ingress

ingress:

  • from:
  • podSelector:

matchLabels:
app: monitoring # 「送信側」Podを指定（監視ツール）
ports:

  • protocol: TCP

port: 9100 # よくあるメトリクスポート（例: Node Exporter）
# もしアプリケーションが直接メトリクスを公開しているならそのポート

これらのポリシーを適用することで、web-app-prod Namespace内のPodは、必要な通信だけが許可され、それ以外の全ての通信はブロックされる状態になる。

—

XSSの二次被害をNetworkPolicyで阻止するシナリオ

これで、XSSとNetworkPolicyがどう繋がるか、より明確になるはずだ。

もし、WebフロントエンドのPodがXSSの脆弱性を抱えていて、攻撃者が悪意のあるスクリプトを注入したとする。そのスクリプトが、ユーザーのブラウザ上で実行され、例えば以下のような内部APIエンドポイントへのリクエストを試みた場合を考えてみよう。

// XSSペイロードが実行されたとする
// このスクリプトは、ブラウザから見える範囲の内部APIを叩こうとする
fetch(‘http://backend-service.web-app-prod.svc.cluster.local:8080/internal-admin/config’, {
method: ‘GET’,
headers: {
‘X-Requested-With’: ‘XMLHttpRequest’
}
})
.then(response => {
if (response.ok) {
return response.json();
}
throw new Error(‘Network response was not ok.’);
})
.then(data => console.log(‘内部設定:’, data))
.catch(error => console.error(‘内部APIへのアクセス失敗:’, error));

このリクエストは、ユーザーのブラウザから直接バックエンドサービスを呼び出すものだ。しかし、もしバックエンドサービスが公開されているServiceのClusterIP経由であっても、NetworkPolicyはPod間通信を制御するため、このリクエストがバックエンドPodに到達する前にブロックされる。

具体的には、allow-frontend-to-backend.yamlで許可されているのは、app: frontendラベルを持つPodからの通信だ。XSSスクリプトはユーザーのブラウザで実行されるため、そのリクエスト元はWebフロントエンドのPodではない。結果として、この不正なリクエストはNetworkPolicyによってブロックされ、内部APIへのアクセスは失敗に終わる。

これは、XSSによる情報漏洩や不正操作の範囲を、ブラウザの範囲内に限定し、バックエンドの機密情報や他のマイクロサービスへの横展開を阻止するという点で、極めて重要な防御層となる。

—

XSSそのものを完全に防御するための追加策（再確認）

NetworkPolicyは「被害拡大阻止」の強力なツールだが、XSSの発生自体を防ぐものではない。だからこそ、以下の防御策は引き続き、そしてより厳格に実装する必要がある。

1. 入力値の厳格な検証と出力時のエスケープ

あらゆるユーザー入力は信頼せず、サーバーサイドで厳格に検証し、出力時には必ずコンテキストに応じたエスケープ処理を行う。

PHPの例 (HTMLコンテキスト)

Python (Flask/Jinja2) の例

app.py (Flask)
from flask import Flask, render_template, request

app = Flask(__name__)

@app.route(‘/search’)
def search():
query = request.args.get(‘q’, ”)
# Jinja2テンプレートエンジンはデフォルトでHTMLエスケープを行うため、
# {{ variable }} の形式で出力すれば自動的にエスケープされる
return render_template(‘search_results.html’, query=query)

if __name__ == ‘__main__’:
app.run(debug=True)





検索結果

検索結果: {{ query }}

検索ワード: {{ query }}


JavaScript (DOM操作) の例

innerHTMLにユーザーからの入力を直接代入するのは非常に危険。textContentやinnerTextを使うことで、HTMLとして解釈されずにテキストとして挿入される。

// 危険な例: XSSの温床
// document.getElementById(‘output’).innerHTML = userInput;

// 安全な例: textContentを使用
const userInput = ““;
document.getElementById(‘output’).textContent = userInput;
// 結果:

2. CSP (Content Security Policy) の導入

CSPは、ウェブページが読み込むことのできるリソース（スクリプト、スタイルシート、画像など）のロード元を制限することで、XSS攻撃の多くを無力化できる強力なセキュリティメカニズムだ。HTTPレスポンスヘッダーで設定する。

Nginxの設定例 (CSPヘッダーを追加)
server {
listen 80;
server_name example.com;

add_header Content-Security-Policy ”
default-src ‘self’; # デフォルトで同じオリジンからのみ許可
script-src ‘self’ https://trusted.cdn.com; # スクリプトは自己と信頼できるCDNからのみ許可
style-src ‘self’ ‘unsafe-inline’; # スタイルは自己とインラインスタイルを許可 (注意: ‘unsafe-inline’はなるべく避ける)
img-src ‘self’ data:; # 画像は自己とdata URIを許可
object-src ‘none’; # タグは許可しない
base-uri ‘self’; # タグのURLを制限
form-action ‘self’; # フォームの送信先を制限
frame-ancestors ‘self’; # iframeによる埋め込みを制限 (クリックジャッキング対策)
report-uri /csp-report-endpoint; # 違反レポートを送信するエンドポイント
“;

# … その他の設定 …
}

CSPは非常に強力だが、設定が複雑で、誤るとサイトの機能に影響が出る可能性がある。report-onlyモードで導入し、レポートを監視しながら徐々に厳しくしていくのが賢明だ。

3. HttpOnly Cookieの活用

セッション管理にクッキーを使用している場合、HttpOnly属性を付与することで、JavaScriptからのクッキーへのアクセスを制限できる。これにより、XSSによってセッションクッキーが盗まれるリスクを大幅に軽減できる。

3600,
‘path’ => ‘/’,
‘domain’ => ‘.example.com’,
‘secure’ => true, // HTTPS接続でのみ送信
‘httponly’ => true, // JavaScriptからのアクセスを禁止
‘samesite’ => ‘Lax’ // CSRF対策 (Lax, Strict, None)
]);
session_start();
?>

4. WAF (Web Application Firewall) の導入

クラウドベースのWAF（AWS WAF, Cloudflare WAF, Azure WAFなど）は、既知のXSSパターンを検知し、ブロックするルールセットを提供してくれる。これはアプリケーションレイヤーでの防御の「最後の砦」として非常に有効だ。アプリケーションコードの修正が難しいレガシーシステムにも導入しやすい。

—

まとめ：多層防御の重要性と継続的な改善

今日の話で、XSSの恐ろしさと、それを防御するための多層的なアプローチの重要性を理解してもらえただろうか。

NetworkPolicyによるマイクロセグメンテーションは、XSSそのものを防ぐものではない。だが、万が一XSSが成功してしまった際の「被害拡大を阻止する」、つまり「攻撃の横展開を防ぐ」 ための、Kubernetes環境における極めて重要なセキュリティレイヤーだ。まるで、一軒家をいくら頑丈にしても、個々の部屋のドアに鍵をかけ、不審な侵入者が他の部屋に行けないようにするようなものだ。

セキュリティは、一度やれば終わり、というものではない。常に新しい攻撃手法が登場し、システムの構成も変化していく。だからこそ、

  • 開発段階でのセキュアコーディングプラクティス
  • コードレビューや静的解析による脆弱性検出
  • Webアプリケーションファイアウォールによる外部からの攻撃防御
  • CSPによるクライアントサイドの挙動制限
  • そして、NetworkPolicyによる内部ネットワークの堅牢化

これら全てを組み合わせて、多層的な防御戦略を構築し、継続的に見直し、改善していくことが、我々エンジニアに課せられた使命だ。

チームの後輩たちよ、Webアプリ開発の楽しさや新しい技術の追求は素晴らしい。だが、その根底には常に「ユーザーのデータと信頼を守る」という重大な責任があることを忘れないでほしい。今日話した内容を参考に、君たちのプロダクトをより安全なものにしてくれることを期待している。

何か疑問があれば、いつでも俺に聞いてくれ。一緒に、より堅牢なシステムを創り上げていこうじゃないか。

スポンサーリンク

コメント

タイトルとURLをコピーしました