境界線の消失と「IDの奪取」：IMDSv2強制化が突きつけるアーキテクチャの真実
セキュリティの現場で長年戦っていると、多くのエンジニアが「クラウドは安全な箱庭」だという幻想を抱いていることに気づく。だが、現実はどうか。APIを叩けば物理ハードウェアのリソースが振ってくるクラウド環境において、「メタデータサービス（IMDS）」こそが、攻撃者にとっての聖杯（Holy Grail）であることに異論はないはずだ。
SSRF（Server-Side Request Forgery）の脆弱性を見つけた攻撃者は、まず何をするか？ 決まって `169.254.169.254` を叩く。ここでIMDSv1が有効なまま放置されていれば、IAMロールの認証情報が平文で手に入る。これは、攻撃者が「アプリケーションの脆弱性」という小さな穴から、「クラウドインフラの管理者権限」という広大な権限へエスカレーションするための、最も安易で確実なショートカットだ。
IMDSv1の構造的欠陥：なぜ「リクエスト一つ」で落ちるのか
IMDSv1は、HTTPリクエストを送るだけでメタデータが返る。この設計は、IPルーティングの脆弱性に依存している。SSRFのペイロードを仕込むだけで、攻撃者はセッション確立のプロセスをスキップし、静的な認証情報を盗み取れる。
対して、IMDSv2は「セッション指向」だ。PUTリクエストでセッショントークンを取得し、そのトークンをヘッダーに乗せてGETリクエストを行う。この一手間が、従来の単純なSSRFを無効化する。
なぜなら、攻撃者が仕掛ける多くのSSRFは、GETリクエストによる「一方的な情報の引き出し」に依存しているからだ。PUTによるハンドシェイクを強制することで、悪意あるリクエストの送信経路に「認証の壁」を一段設けることができる。
アーキテクトとして実装すべき防御レイヤー
単に「IMDSv2を有効にする」だけでは片手落ちだ。真のセキュリティアーキテクトであれば、以下の3階層で防御を固める必要がある。
1. トークンのTTL（有効期限）の最適化
デフォルトのTTLは60秒だが、攻撃者がセッションを維持しようとする時間を極限まで削るべきだ。
AWS CLIによるインスタンスメタデータ設定の強制
hop-limit 1 は、プロキシサーバーを経由したSSRFを防ぐための重要なパラメータ
aws ec2 modify-instance-metadata-options \
–instance-id i-xxxxxxxxxxxxxxxxx \
–http-tokens required \
–http-put-response-hop-limit 1 \
–http-endpoint enabled
ここで注目すべきは `–http-put-response-hop-limit 1` だ。この設定により、メタデータへのリクエストはインスタンス内から直接発せられたもの（ホップ数1）以外は拒否される。もしアプリケーションがプロキシやコンテナのサイドカーを経由してメタデータにアクセスする設計であれば、この値を調整する必要があるが、セキュリティの観点では「1」が最強の防壁となる。
2. 生成AIガードレイルとの統合
最近の脆弱性トレンドとして、LLM（大規模言語モデル）を介したRCE（リモートコード実行）からIMDSを突く攻撃が増えている。プロンプトインジェクションによりLLMが「メタデータを取得して要約せよ」というコードを生成した場合、IMDSv2が有効でも、アプリケーション自体がメタデータを読み取る権限を持っていると被害が拡大する。
ここで重要なのは、IAMロールの最小権限原則（Least Privilege）だ。「アプリケーションが必要とするアクション以外は全て拒否する」というSCP（Service Control Policy）を適用していないなら、IMDSv2はあくまで時間稼ぎに過ぎない。
コードで担保する「セッションの安全性」
開発者がインフラの制約を意識しなくても済むよう、SDKレベルでのラッパーを推奨する。以下は、IMDSv2のセッションを確実に維持するためのPythonのラッパー実装例だ。
import requests
def get_metadata(path):
# 1. セッショントークンの取得（PUTリクエスト）
token_url = “http://169.254.169.254/latest/api/token”
headers = {“X-aws-ec2-metadata-token-ttl-seconds”: “60”}
try:
# トークンを取得
token = requests.put(token_url, headers=headers, timeout=1).text
# 2. トークンをヘッダーに含めてデータ取得
metadata_url = f”http://169.254.169.254/latest/{path}”
response = requests.get(metadata_url, headers={“X-aws-ec2-metadata-token”: token}, timeout=1)
return response.text
except requests.exceptions.RequestException as e:
# ログには詳細を吐き出し、ユーザーには伏せるのが鉄則
print(f”Metadata access failed: {e}”)
return None
監査の観点：設定の「ドリフト」を許すな
セキュリティバイブルの主筆として最後に強調したいのは、「設定は一度適用して終わりではない」という点だ。CI/CDパイプラインにおいて、TerraformやCloudFormationでIMDSv2を強制しても、後から手動で設定変更されては意味がない。
- Config Rules（AWS Config）による継続的モニタリング:
`ec2-instance-metadata-service-check` ルールを有効にし、v1が有効なインスタンスが検知された瞬間に自動停止、あるいはSlackへ即時アラートが飛ぶ仕組みを構築せよ。
- クエリの可視化:
VPCフローログを活用し、`169.254.169.254` へのアクセスパターンを監視する。特定のコンテナから急激なPUTリクエストが発生している場合、それは「探索」の兆候だ。
メタデータサービスを巡る戦いは、攻撃者が「アプリケーション」を侵食し、「インフラ」を支配しようとする試みそのものだ。IMDSv2への強制移行は、その支配への道を塞ぐための最低限の礼儀だと思え。これすら怠るテックリードに、クラウドの設計を語る資格はない。
脆弱性は常に、我々が「まさかここを突くわけがない」と高を括った場所から顔を出す。IMDSv2の強制は、その慢心を断ち切るための最初のステップに過ぎない。次は、君のアプリケーションのコードレベルでのSSRF耐性を問い直す番だ。
コメント