境界線の消失：IMDSv1の悪夢と、IMDSv2が強いる「セッション」という防壁
クラウドネイティブな環境において、インスタンスメタデータサービス（IMDS）は、いわば「クラウドの心臓部」に直結する神経系だ。しかし、過去数年間にわたる大規模なクラウド侵害の多くを遡れば、必ずと言っていいほどIMDSv1の脆弱性、すなわちSSRF（Server-Side Request Forgery）による認証情報の窃取という「初歩的だが致命的なミス」に行き着く。
IMDSv1は、単なるHTTPリクエストを送るだけでメタデータ（IAMロールのクレデンシャルを含む）を返却する。これは攻撃者にとって「認証なしのパスポート発行所」に等しい。なぜこれが放置されてきたのか？ それは、クラウドインフラの黎明期において「ローカルネットワーク内であれば信頼できる」という、今となっては時代遅れの楽観主義が設計思想の根底にあったからに他ならない。
なぜIMDSv2はSSRFを無効化できるのか
IMDSv2の核心は「セッション指向」への移行にある。単にリクエストを投げるのではなく、最初に PUT リクエストでセッショントークンを取得し、そのトークンを X-aws-ec2-metadata-token ヘッダーに付与しなければデータにアクセスできない。
なぜこれが防衛になるのか。攻撃者がアプリケーションの脆弱性（例：file_get_contents のような関数に渡すURLを制御できるSSRF）を突こうとした際、GET リクエストしか送れない状況であれば、まずトークンを取得するための PUT リクエストを発行することが不可能になるからだ。
さらに、X-Forwarded-For ヘッダーによる偽装を無効化するため、ホップ制限（HttpPutResponseHopLimit）を 1 に設定することで、プロキシ経由の攻撃を物理層（IPヘッダーのTTL）レベルで遮断する。これは単なるソフトウェアの設定ではなく、ネットワークプロトコルの挙動を利用した極めて硬質な防御層である。
実践：Terraformによる強制化と防御層の構築
インフラをコードで管理する（IaC）時代において、IMDSv1の排除はポリシーとして強制すべきだ。以下は、AWS環境においてIMDSv2を必須化し、ホップ制限を最小にするためのTerraform設定例である。
# AWS EC2インスタンス設定におけるメタデータオプションの強化
resource "aws_instance" "hardened_instance" {
ami = "ami-xxxxxxxxxxxxxxxxx"
instance_type = "t3.micro"
metadata_options {
# IMDSv2の強制。これを 'optional' にするとv1が生存し続けるため、必ず 'required' にする
http_tokens = "required"
# プロキシ経由のSSRFを防ぐためのホップ制限。
# 1に設定することで、インスタンスから直接の通信以外を拒否する
http_put_response_hop_limit = 1
# 物理的なパケットレベルでの防御を有効化
http_endpoint = "enabled"
}
}攻撃者から見た「突破不能な壁」
私がレッドチームとして侵入を試みる際、IMDSv2が有効化されている環境は、文字通り「壁」として立ちはだかる。もしアプリケーションが cURL や requests を介して外部リクエストを許可していたとしても、その関数が PUT メソッドをサポートし、かつ取得したトークンを後続の GET リクエストのヘッダーに注入する構造になっていない限り、メタデータには到達できない。
近年の生成AIを用いた自動攻撃ツールであっても、この「セッション管理」というステートフルな制約を突破するには、アプリケーションコード自体に高度なリクエスト構築能力（あるいはリモートコード実行によるメモリ空間の操作）が必要となり、攻撃コストは劇的に跳ね上がる。
セキュリティアーキテクトへの提言：将来の脅威を見据えて
IMDSv2への移行は、現代のクラウドセキュリティにおける「最低ライン」だ。しかし、我々が次に備えるべきは、メタデータサービスそのものの暗号化や、耐量子暗号（PQC）の導入、そしてAIが生成した複雑なプロンプトインジェクションに対するガードレイルの構築である。
特に、LLMをバックエンドに持つアプリケーションがIMDSにアクセスするケースでは、prompt injection によって意図せずメタデータエンドポイントへのリクエストが構築されるリスクがある。防御側は以下の観点を監査基準に追加すべきだ。
1. ネットワーク分離: IMDSへのアクセスを特定のプロセスやユーザーのみに制限する（iptables や ebpf を用いたきめ細かな制御）。
2. モニタリングの深化: メタデータへのアクセスログ（特に失敗したトークンリクエスト）をリアルタイムで監視し、異常なアクセスパターンを即座に切断する自動応答システムを構築すること。
3. ガードレイルの配置: アプリケーションレイヤーの入力バリデーションだけでなく、ネットワークエッジで X-aws-ec2-metadata-token ヘッダーを意図的に削除または書き換えるミドルウェアの導入。
セキュリティとは、終わりのないパッチワークではない。プロトコルの仕様を深く理解し、攻撃者が「最もコストがかかるルート」を選択せざるを得ないような、理詰めのアーキテクチャを設計することこそが、我々エンジニアの真価である。IMDSv1を無効化し、堅牢な防御層を構築することは、その最初にして最も重要な一歩だ。
コメント