おい、最近のクラウドインフラの設計を見ていて肝を冷やすことが増えた。
「うちのアプリケーションはAWS上で動いているから大丈夫です。WAFも入っているし、IAM権限も最小限にしています」――そう胸を張るジュニアエンジニアのコードをレビューしてみると、平然とSSRF（サーバー側リクエスト偽造）の穴が放置されている。そして、その背後には大抵、無防備な旧世代のクラウドメタデータサービスが口を開けて待っているんだ。
セキュリティの世界では、暗号理論の数学的な美しさ（AESやRSA、ECCなど）に目を奪われがちだが、実際のインシデントの現場でシステムを致命傷に追い込むのは、往々にしてこうした「認証の前提が崩れた接続インターフェース」のミスだ。
今回は、クラウドセキュリティの急所であるIMDSv2（Instance Metadata Service Version 2）の強制化と、セッション指向の認証フローの原理について、攻撃者の視点を交えながら徹底的に解説しよう。明日からお前のチームで即座に使える具体的なコードと設定も用意した。最後までしっかりついてこい。
—
1. なぜIMDSv1は「秒」で抜かれるのか？（攻撃者の視点）
クラウドインスタンス（特にAWSのEC2など）の内部から、自身のメタデータ（インスタンスID、セキュリティグループ、さらにはアタッチされたIAMロールの一時クレデンシャル）を取得するための仕組みがメタデータサービスだ。IPアドレスでいうと 169.254.169.254 という、いわゆるリンクローカルアドレスがそれに該当する。
IMDSv1の致命的な構造欠陥
従来の IMDSv1 は、単なる「HTTPのGETリクエストを送るだけ」で機密情報が返ってくる仕様だった。これが何を意味するか？
もしお前のWebアプリケーションに、ユーザーが入力したURLに対してサーバー側でリクエストを飛ばすような機能（例えば、OGP画像の自動取得、URLプレビュー、外部API連携など）があり、そこにSSRFの脆弱性が存在していた場合、攻撃者は次のようなリクエストを仕込んでくる。
GET /latest/meta-data/iam/security-credentials/MyWebRole HTTP/1.1
Host: 169.254.169.254WebアプリがこのURLをそのまま内部でフェッチしてしまったらどうなるか？ サーバーは攻撃者に代わってメタデータサービスにアクセスし、IAMの一時クレデンシャル（AccessKeyId, SecretAccessKey, Token）をごっそり引き抜いてレスポンスに含めてしまう。
攻撃者はその盗んだクレデンシャルを使い、お前のAWS環境へ「正規の管理者」として堂々と侵入するわけだ。WAFでSQLインジェクションやクロスサイトスクリプティングを防いできた努力が、たった1行のSSRFで水の泡になる瞬間だな。
—
2. IMDSv2の原理：なぜセッション指向なのか
この泥臭い悪夢を根絶するためにAWSが導入したのが IMDSv2 だ。
IMDSv2の核心は、単なるHTTPリクエストの排除ではなく、「セッション指向のトークンベース認証（Session-Oriented Authorization）」の導入にある。ここには暗号技術そのものではないが、ステートフルな信頼関係を確立するための堅牢なプロトコル設計思想がある。
IMDSv2の通信フロー
IMDSv2では、メタデータにアクセスする前に必ず以下の「一手間」が強制される。
1. トークンの取得（PUTリクエスト）
クライアント（アプリケーション）は、PUT メソッドを使ってメタデータサービスに対し、セッションの開始を要求する。この際、カスタムヘッダー（X-aws-ec2-metadata-token-ttl-seconds）を付与することが義務付けられる。
2. 秘密トークンの発行
サービス側は、有効期限付きのセッション・トークンを発行して返す。
3. メタデータの取得（GETリクエスト）
実際の機密データを取りに行く際、先ほど取得したトークンをHTTPヘッダー（X-aws-ec2-metadata-token）に含めて GET リクエストを送る。トークンがないリクエストは容赦なく弾かれる。
なぜこれがSSRFを防ぐのか？
一般的なSSRFの脆弱性は、攻撃者がアプリケーションに対して「任意の GET リクエストを強制させる」ことはできても、「事前に PUT リクエストを投げてセッション・トークンを取得し、それを次の GET のカスタムヘッダーに付与する」という一連の複雑なステートフルな処理を代理実行させるのは極めて困難だからだ。
HTMLの <img> タグや <iframe> タグ、あるいは単純なブラウザからのリクエスト（これらはデフォルトで GET しか発行できない）を使った古典的なSSRFでは、IMDSv2の壁を突破することは不可能に近い。
—
3. 実務で即座に実行すべき対策と設定
口で言うだけなら誰でもできる。ここからは、インフラ側での強制化と、アプリケーション側でのセキュアな実装の双方から、完全に防御を固める手順を解説する。
A. インフラ層：IMDSv1の無効化とIMDSv2の強制（AWS CLI）
まずはクラウド基盤の土台を固める。既存のインスタンスも含めて、IMDSv1を完全に禁止し、IMDSv2を必須（Required）に設定しよう。
以下のAWS CLIコマンドを実行し、インフラ全体で古いプロトコルを締め出す。
# 特定のEC2インスタンスに対してIMDSv2を強制し、v1を無効化する設定
aws ec2 modify-instance-metadata-options \
--instance-id i-0123456789abcdef0 \
--http-tokens required \
--http-endpoint enabledさらに、新規作成されるインスタンス全てでこれをデフォルト強制したい場合は、AWS OrganizationsのSCP（サービスコントロールポリシー）や、TerraformなどのIaCツール側で http_tokens = "required" をマストのバリデーションとして組み込んでおくこと。これを破るデプロイはコードレビューの段階で容赦なく落とせ。
—
B. アプリケーション層：セキュアなHTTPクライアントの実装例
アプリケーション側で外部URLへのリクエストを処理する場合、SSRFそのものを防ぐためのバリデーション（プライベートIPやローカルループバックへのアクセス拒否）に加え、万が一SSRFの穴があった場合でも被害を最小限にする設計が必要だ。
ここでは、実務でよく使われる Python (requests) と PHP (cURL) を用いて、URLの厳格なバリデーションを行うセキュアなサンプルコードを示す。
Python (requests) によるセキュアなURLフェッチの例
import ipaddress
import socket
from urllib.parse import urlparse
import requests
def secure_fetch(target_url: str) -> str:
"""
SSRFを防止するためにURLのホスト名を検証し、
プライベートIPやAWSメタデータIPへの不正なアクセスを遮断するセキュアな関数
"""
parsed_url = urlparse(target_url)
# 許可するスキームは http と https のみ
if parsed_url.scheme not in ('http', 'https'):
raise ValueError("無効なURLスキームです。")
hostname = parsed_url.hostname
if not hostname:
raise ValueError("ホスト名が特定できません。")
try:
# ホスト名をIPアドレスに解決
ip_addr_str = socket.gethostbyname(hostname)
ip_addr = ipaddress.ip_address(ip_addr_str)
except socket.gaierror:
raise ValueError("ホスト名の解決に失敗しました。")
# 【最重要】プライベートIP、ループバック、およびAWSメタデータアドレスへのアクセスをブロック
if (ip_addr.is_private or
ip_addr.is_loopback or
ip_addr.is_link_local or
ip_str_equals(ip_addr_str, "169.254.169.254")):
raise SecurityError("内部ネットワークやメタデータサービスへのアクセスは禁止されています。")
# 安全が確認された場合のみリクエストを実行
response = requests.get(target_url, timeout=5)
response.raise_for_status()
return response.text
def ip_str_equals(ip: str, target: str) -> bool:
return ip == targetPHP (cURL) による実装例
PHPで外部URLを叩く場合も同様だ。curl_setopt の設定に気を配る必要がある。特に CURLOPT_FOLLOWLOCATION（リダイレクトの追跡）を有効にしている場合、攻撃者が外部の悪意あるサーバーを経由して http://169.254.169.254/ にリダイレクトさせる「オープンリダイレクトを絡めたSSRF」に要注意だ。
<?php
/**
* SSRF対策を施したセキュアな外部URL取得関数
*/
function secure_url_get(string $url): string {
$parsed = parse_url($url);
if (!isset($parsed['scheme']) || !in_array($parsed['scheme'], ['http', 'https'], true)) {
throw new InvalidArgumentException("無効なURLスキームです。");
}
$host = $parsed['host'] ?? '';
$ip = gethostbyname($host);
// IPアドレスがプライベートレンジやリンクローカル（メタデータ含む）に該当するかチェック
if (
filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE) === false ||
$ip === '169.254.169.254'
) {
throw new RuntimeException("不正な宛先IPアドレスへのリクエストが検出されました。");
}
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
// 【重要】リダイレクト先でのSSRF（Open Redirect経由のメタデータアクセス）を防ぐため、
// 原則としてリダイレクトの自動追跡はオフにするか、追跡先のIPも厳格にバリデーションする
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false);
$response = curl_exec($ch);
if (curl_errno($ch)) {
$error = curl_error($ch);
curl_close($ch);
throw new RuntimeException("cURLエラー: " . $error);
}
curl_close($ch);
return $response;
}—
4. チーフエンジニアからの実務アドバイス
セキュリティ対策というのは、「これをやっておけば100%安全」という銀の弾丸はない。だが、幾重にも防御壁を張り巡らせる「多層防御（Defense in Depth）」を構築することで、攻撃者のコストを跳ね上げ、標的から外させることは十分に可能だ。
今回のテーマであるIMDSv2とSSRF対策において、現場のエンジニアが心得るべきポイントを最後にまとめておく。
1. 「デフォルトだから安全」という幻想を捨てる
クラウドのデフォルト設定が常にセキュアとは限らない。古い世代との互換性のために、あえて危険なオプションが残されているケースは多々ある。インフラの構築時には必ず「セキュアなベースライン設定」をコード（TerraformやCloudFormation）で強制し、後から手動で緩められない仕組みを作れ。
2. SSRFの芽をアプリ層で摘む
アプリケーションが外部のURLを受け付けてリクエストを投げる設計自体が、本質的にハイリスクだ。可能であれば、URLを直接受け取るのではなく、許可されたドメインのリスト（ホワイトリスト）やIDベースの参照方式に設計をリファクタリングすることを強く勧める。
3. IAMの権限は最小限に（Least Privilege）
万が一、SSRFを突破され、IMDSv2の壁も何らかのゼロディや設定ミスで破られた最悪のシナリオを想像しろ。その時、そのEC2インスタンスに付与されているIAMロールが AdministratorAccess だったらどうなる？ 全リソースが瞬時に奪われる。アプリが必要とする最小限の権限（例えば特定のS3バケットの読み取りだけ等）に絞ることで、被害を極小化できる。
セキュリティは日々の泥臭い積み重ねだ。自分のコードやインフラに「隙」がないか、今日の退勤前に必ずもう一度見直してくれ。頼んだぞ。
コメント