境界防御の終焉と「IDこそがネットワーク」である現実
かつて我々は、境界ファイアウォールという名の「城壁」の中にいれば安泰だという幻想を抱いていた。しかし、クラウドネイティブの時代において、その城壁は塵と化した。Cloud Runという抽象化されたコンピューティング環境において、サービス間の通信をどのように制御するか。結論から言えば、それは「誰が（Who）」を証明するIDトークンの検証と、「何を（What）」まで許すかのIAM設定の極小化に集約される。
多くのエンジニアは、IAMロールを `roles/run.invoker` に設定して満足する。だが、セキュリティアーキテクトの視点からは、それは「鍵をかけた門の前に、誰でも入れる鍵穴を放置している」のと同じだ。
1. サービス間認証の深淵：OIDCトークンのライフサイクル
Cloud Runのサービス間通信において、最も重要なのは「署名付きJWT（JSON Web Token）」の検証だ。Googleが発行するIDトークンは、特定の聴衆（Audience）に対して発行される。
ここで攻撃者が狙うのは、「Replay Attack（リプレイ攻撃）」や「Audienceの誤設定」だ。開発者はしばしば、汎用的なサービスアカウントを作成し、複数のサービスで使い回す。もし一つのサービスがSSRF（Server-Side Request Forgery）の脆弱性により侵害された場合、そのサービスアカウントに付与された権限は横展開（Lateral Movement）の踏み台となる。
実装の勘所：Audienceの厳格な検証
コード内でトークンを検証する際、単に署名を検証するだけでは不十分だ。`aud` クレームが、現在実行中のサービス自身のURLと完全に一致しているかを検証せよ。
Google Authライブラリを使用したIDトークン検証の核心部
from google.oauth2 import id_token
from google.auth.transport import requests
def verify_cloud_run_request(id_token_str, expected_audience):
“””
攻撃者はトークンの差し替えを試みる。
expected_audienceには、自身のCloud RunサービスのURLを指定すること。
“””
request = requests.Request()
try:
# 署名の検証と、発行者(iss)の検証を同時に行う
claims = id_token.verify_oauth2_token(
id_token_str, request, expected_audience)
return claims
except ValueError as e:
# ここで握りつぶさず、セキュリティ監査ログにスタックトレースを残せ
log_security_event(“INVALID_TOKEN_ATTEMPT”, e)
raise
2. IAMの最小権限設定：静的なロールから条件付きアクセスへ
「最小権限」とは、単に権限を削ることではない。コンテキスト（文脈）に応じた動的な制御だ。Cloud Runでは、IAM条件（IAM Conditions）を活用することで、特定の時間帯や特定のネットワークIPレンジ、あるいは特定のタグが付与されたリソースのみにアクセスを限定できる。
特に、最近の攻撃トレンドは「サービスアカウントの乗っ取り」だ。これを防ぐには、Workload Identityの活用が不可欠となる。
- Workload Identityの鉄則:
- サービスアカウントに `roles/run.invoker` を付与する際は、必ず `resource.name` で特定のサービス名に限定せよ。
- プロダクション環境では、デフォルトのCompute Engineサービスアカウントの使用を禁止せよ。これは「特権の肥大化」の入り口である。
3. 生成AI時代の新たな脅威：プロンプトインジェクションとガードレイル
昨今のアーキテクチャでは、Cloud Runの背後にLLM（大規模言語モデル）を配置することが増えた。ここで盲点となるのが、「プロンプトインジェクションによるIAM権限の悪用」だ。
もしLLMがCloud Runを経由してGoogle Cloud APIを叩く設計であれば、LLMへの入力がそのままIAM操作のコマンドになる可能性がある。これを防ぐには、アプリケーション層での「ガードレイル」が必須だ。
- 入力のサニタイズ: ユーザーの入力値を直接SQLやAPIクエリに渡さない。
- 権限分離: LLMを実行するサービスアカウントには、推論に必要な最低限の読み取り権限のみを与え、書き込み権限（Create/Update/Delete）は物理的に遮断した別サービスに委譲する。
4. まとめ：監査可能なアーキテクチャの構築
セキュリティとは「状態」ではなく「プロセス」だ。最後に、現場のテックリードへ伝えたい。
1. 監査ログの全量保持: Cloud Audit LogsをBigQueryにエクスポートし、異常なサービス間通信のパターン（例えば、深夜帯の大量のIDトークン要求）を検知できる体制を整えよ。
2. 防御的プログラミング: パケット構造やプロトコル仕様の欠陥を突く攻撃は、最終的にアプリケーションの境界で止めるしかない。入力値検証（Validation）は、セキュリティの最後の防波堤だ。
耐量子暗号（PQC）への移行が議論される中、我々が今なすべきは、ID基盤を強固にすることである。暗号技術が進化しても、IAMの設計思想が脆弱であれば、攻撃者は正面玄関から堂々と入り込む。
「最小権限」をコードに落とし込み、全ての通信にIDの裏付けを持たせること。それが、今のクラウドインフラを守る唯一の正攻法だ。
コメント