境界防御の幻想を捨てろ：ゼロトラスト時代に「認証だけ」で安心するな
多くのエンジニアが「VPNがあるから社内ネットワークは安全だ」あるいは「認証を通したから、このAPIは安全だ」という幻想を抱いている。しかし、現場でインシデント対応をしていると痛感するのは、「一度侵入されたら、境界の内側は無防備なスルメのように柔らかい」という現実だ。
NIST SP 800-207が提唱するゼロトラストアーキテクチャ（ZTA）の本質は、「信頼しないこと」ではない。「全てのアクセスを都度、文脈を持って検証し続けること」だ。今日は、概念論ではなく、実務で明日から取り入れるべきPDP（ポリシー決定ポイント）とPEP（ポリシー実行ポイント）の実装について深く掘り下げる。
—
1. 攻撃者が狙う「認可の盲点」
攻撃者は、ID/パスワードの漏洩（クレデンシャルスタッフィング）だけでなく、「一度認証されたセッションの不正利用」を狙う。
例えば、ユーザーAが認証を突破した後、APIサーバーに対して「本来権限のないリソースID」をパラメータとして投げる攻撃がある。これを防ぐには、各APIエンドポイントで「誰が（Identity）」だけでなく、「何を（Permission）」かつ「どのコンテキスト（Context: IP、デバイス状態、時間）」で操作しようとしているかを判断するPDPが不可欠だ。
—
2. 実装の要：PDP/PEPの分離設計
理想的なZTAでは、アプリケーションコードの中に認可ロジックをベタ書きしてはならない。ビジネスロジックと認可ルールを分離し、認可判断（PDP）を中央集権的に管理する。
Python (FastAPI) によるPEPの実装例
以下の例では、リクエストの属性（ユーザーのロールとリソースID）を外部のPDP（ここでは簡易的な判定関数）に委譲する実装を示している。
from fastapi import FastAPI, Depends, HTTPException, Request
app = FastAPI()
# 【重要】PDP: ポリシー決定ポイント
# 本来はOIDCのクレームやOPA(Open Policy Agent)などを参照して判定を行う
def check_policy(user_id: str, resource_id: str, action: str):
# ここに複雑なアクセス制御ロジックを配置（DB照会や属性ベース制御）
# 例：特定のユーザーが所有するリソースか確認
allowed_resources = {"user_123": ["res_a", "res_b"]}
if resource_id in allowed_resources.get(user_id, []):
return True
return False
# 【重要】PEP: ポリシー実行ポイント
# エンドポイントのガードとして機能させる
async def authorize_request(request: Request):
user_id = request.headers.get("X-User-ID") # 認証済みトークンから取得を想定
resource_id = request.path_params.get("resource_id")
if not check_policy(user_id, resource_id, "READ"):
raise HTTPException(status_code=403, detail="アクセス権限がありません")
@app.get("/data/{resource_id}")
async def get_data(resource_id: str, _ = Depends(authorize_request)):
return {"data": f"極秘情報: {resource_id}"}—
3. インフラ層でのPEP：Nginx + Luaでの防御
アプリケーション層に到達する前に、リクエストを強制的に検証する。Nginxの auth_request モジュールは、ZTAにおけるPEPとして極めて優秀だ。
# Nginx設定ファイル
location /api/ {
# サブクエリとして認可サーバー(PDP)を叩く
auth_request /auth_check;
# 許可された場合のみバックエンドへ
proxy_pass http://backend_app;
}
location = /auth_check {
internal;
proxy_pass http://auth_service/verify;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}—
4. エンジニアが守るべき「3つの鉄則」
現場でインシデントを未然に防ぐために、以下のルールを設計指針（アーキテクチャ標準）としてチームに浸透させてほしい。
1. Identityを「認証」から「属性（Claims）」へ:
JWTなどのトークンには、IDだけでなく「ロール」「所属グループ」「リスクスコア」などのコンテキストを含めろ。これを元にPDPで動的な判断を行う。
2. 防御の多層化（Defense in Depth）:
WAFによるシグネチャベースの防御（SQLiやXSS対策）は、いわば「玄関の鍵」だ。PEPは「金庫の鍵」である。どちらか一方が突破されてもシステム全体が崩壊しない設計を維持せよ。
3. ログを「証跡」ではなく「分析対象」にせよ:
PDPが拒否したリクエスト（403エラー）は、攻撃の予兆そのものだ。これをCloudWatchやSIEMでリアルタイム監視し、異常なアクセスパターンを検知したら自動的にIPをブロックするフローを構築せよ。
最後に：完璧なセキュリティなど存在しない
ゼロトラストは製品ではなく「考え方」だ。どんなに優れたコードを書こうとも、設定ミスや運用上の脆弱性は必ず生まれる。だからこそ、「常に侵害されている」という前提で、最小権限の原則（Least Privilege）を徹底し、異常を即座に検知できる泥臭い運用体制を築いてほしい。
コードのコピペは技術の習得には役立つが、セキュリティの「設計思想」までコピペしてはならない。自分のシステムのどこが弱点になり得るか、今日から一歩立ち止まって考えてみてくれ。君たちのコードが、最強の防壁になることを期待している。
コメント