クラウドの境界を溶かす：IMDSv1の黄昏とIMDSv2が強制する「信頼」の再定義
クラウドインフラのセキュリティを語る際、我々攻撃者が最も「好物」とするのは、設定不備によって露出したメタデータサービス（IMDS）だ。かつてAWSのEC2を攻略する際、169.254.169.254という魔法のIPアドレスに対し、単純なGETリクエストを投げるだけでIAMロールの権限を強奪できた時代があった。
今日は、なぜIMDSv1が「設計上の必然」として破綻し、IMDSv2がどのようなプロトコルレベルの制約を課すことで、SSRF（Server-Side Request Forgery）の脅威を無効化しようとしているのか、その深層を解き明かす。
IMDSv1の罪：プロトコルに潜む「無防備な信頼」
IMDSv1の根本的な欠陥は、HTTPの「リクエスト・レスポンス」という通信モデルの単純さに甘えたことにある。メタデータサービスは、特定のインスタンスからのパケットであることを「IPアドレス」のみで識別していた。
しかし、現代のクラウド環境では、SSRFという脆弱性がこれを無力化する。攻撃者がWebアプリケーションの入力値を操作し、サーバー自身にhttp://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>をリクエストさせれば、それは「インスタンス自身からの正当な要求」として処理されてしまう。
防御側は「WAFで防げばいい」と言い張るかもしれないが、それは表層的な対処に過ぎない。本質的な問題は、「認証が存在しないプロトコル設計」そのものにある。
IMDSv2による「セッション指向」への転換
IMDSv2は、この「認証なし」という悪夢を解決するために、セッションベースの認証を導入した。攻撃を成立させるには、単にURLを叩くだけでは不十分となり、以下の二段構えのプロセスが必要になった。
1. PUTリクエストによるセッションの確立: 特定のカスタムヘッダー（X-aws-ec2-metadata-token-ttl-seconds）を付与したPUTリクエストを送り、有効期限付きのセッショントークンを取得する。
2. トークンの添付: 取得したトークンを、以降の全てのGETリクエストのヘッダー（X-aws-ec2-metadata-token）に含める。
この設計が強力なのは、「多くのSSRF攻撃ツールが、PUTリクエストを送信できない（GETのみを想定している）」という制約を突いている点だ。
アーキテクトのための防衛実装：IMDSv2の強制
AWS環境において、IMDSv2を強制するには、単にコードを書くのではなく、インスタンスのメタデータオプションで「厳格な制御」を行う必要がある。Terraformでの設定例を以下に示す。
# EC2インスタンスのメタデータオプション設定
resource "aws_instance" "secure_instance" {
ami = "ami-xxxxxxxx"
instance_type = "t3.micro"
metadata_options {
# IMDSv2を必須に設定（v1を無効化）
http_tokens = "required"
# Hop制限を1に設定することで、SSRFによる踏み台転送を物理的に困難にする
http_put_response_hop_limit = 1
# メタデータサービスの有効化
http_endpoint = "enabled"
}
}ここで重要なのが http_put_response_hop_limit = 1 だ。この設定により、パケットのTTL（Time To Live）が制限され、万が一Webアプリケーションがプロキシとして機能していても、メタデータへのアクセスはインスタンス内から直接発信されたもの以外、弾かれることになる。
次の戦場：ガードレイルと量子耐性を見据えて
我々が現在注視しているのは、SSRFの先にある「プロンプトインジェクション」と「クラウドメタデータ」の交差点だ。LLMを搭載したアプリケーションが、LLM自身にクラウドのメタデータを取得させるような設計ミスを犯せば、IMDSv2の壁すらLLMのプロンプトによってバイパスされるリスクがある。
これに対する防御のアーキテクチャは、もはやネットワークレベルの制限だけでは足りない。
- アイデンティティの分離: インスタンス自体に権限を持たせず、IAM Roles for Service Accounts (IRSA) を使い、コンテナレベルで最小権限を適用する。
- ガードレイルの設置: LLMの出力に対する検証層（ガードレイル）を設け、
169.254.169.254のようなIPアドレスやメタデータに関連するキーワードが抽出されないよう、リアルタイムでフィルタリングをかける。
結びに：ペネトレーションテスターからの助言
脆弱性診断の現場で、未だに「IMDSv1が有効なまま」の環境を見つけることは珍しくない。管理者は「内部ネットワークだから安全だ」と誤認しているが、内部ネットワークとは、攻撃者が一度侵入すれば、すべての歯止めが外れる「信頼の密室」に過ぎない。
IMDSv2への移行は単なる設定変更ではない。「通信プロトコルに認証を組み込む」という、セキュリティの基本原則への回帰だ。今すぐあなたのクラウドアセットを確認してほしい。 http_tokens は required になっているか？ その1ビットの設定が、データ漏洩とシステム保全の分水嶺になる。
プロトコルの低レイヤを理解し、パケットがどう運ばれるかを想像できるエンジニアだけが、この終わりのない「猫とネズミの追いかけっこ」において、最後の一手を打つことができる。
コメント