【入門編】クラウドメタデータサービス(IMDSv2)の強制とSSRF対策 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

こんにちは！クラウドインフラの構築やWebアプリの開発に毎日奮闘されている皆さん、お疲れ様です。

新しいシステムを作ったり、AWSなどのクラウド環境にサーバーを引っ越したりする時、「セキュリティ対策」ってなんだか難しく聞こえますよね。「専門用語が多くてよくわからない…」「とりあえず動くから大丈夫かな？」なんて後回しにしてしまうこと、ありませんか？

今回は、クラウド環境でよく使われる「メタデータサービス（IMDS）」と、そこを狙うサイバー攻撃、そしてその対策である「IMDSv2」について、身近な防犯に例えながら一緒に優しく紐解いていきたいと思います。

専門知識がゼロの新人さんでも大丈夫です！一歩ずつ、安心して学んでいきましょうね。

—

1. クラウドの「メタデータ」ってなに？（例え話で理解しよう）

まずは、クラウドの世界にある「メタデータサービス」がどんなものかイメージしてみましょう。

皆さんが暮らす「家（＝クラウド上の仮想サーバー）」を想像してください。その家の中には、郵便受けがあったり、ガスのメーターがあったり、家電の取扱説明書が置いてある引き出しがあったりしますよね。
この「家に関する情報や、住んでいる人の設定情報」が詰まった引き出しのような場所が、クラウドの世界における「メタデータサービス」です。

AWS（Amazon Web Services）などのクラウドでは、サーバー自身が「今、自分にはどんなIPアドレスが割り当てられているっけ？」「自分の名前（インスタンスID）は何だっけ？」と確認するために、このメタデータサービス（専用の住所：169.254.169.254）へアクセスする仕組みになっています。

サーバー自身が自分を知るためにはすごく便利なのですが…ここに「泥棒が入ってきた時のリスク」が潜んでいるんです。

—

2. 昔の仕様（IMDSv1）に潜んでいた危険な落とし穴

昔から使われてきた古い仕組み（これをIMDSv1と呼びます）には、ちょっと心配な特徴がありました。

先ほどの「家」の例えで言うと、「家の窓（Webアプリケーションの脆弱性）から侵入した泥棒が、リビングのテーブルにある『合鍵の入った引き出し』を、ノックもせず、身分証も見せずにパッと開けられてしまう状態」だったのです。

Webアプリケーションに、ユーザーからの入力をそのまま処理してしまうような「SSRF（サーバーサイド・リクエスト・フォージェリ）」と呼ばれる脆弱性があると、攻撃者はこんな悪事ができてしまいます。

1. 攻撃者は、脆弱性のあるWebアプリを悪用して、サーバー自身に「メタデータサービス（169.254.169.254）のページを見てきて！」とこっそり命令します。
2. 古い仕組み（IMDSv1）では、「お、サーバーからの依頼だな！はいどうぞ！」と、中身のデータをノーチェックでそのまま返してしまいます。
3. その中には、なんと「このサーバーを管理するための強力な権限（一時的な管理者キー）」が含まれていることが多いのです！

結果として、泥棒はクラウド全体のマスターキーを手に入れてしまい、家じゅうの財宝をごっそり盗み出されてしまう…という大惨事につながります。これが、IMDSv1を悪用した攻撃の恐ろしいメカニズムです。

—

3. 防犯をガッチリ固める！新時代の「IMDSv2」とは？

「じゃあ、そんな危ないなら古い仕組みはやめよう！」ということで登場したのが、セキュアな新バージョンである「IMDSv2」です。

IMDSv2がやってくれたことは、防犯で言うと「二重ロックと、合言葉（トークン）の導入」です。

IMDSv2では、メタデータを取りに行くときに、以下のような厳しいルールが課されます。

1. セッションの開始（合言葉の発行）を要求する
まず最初に「今からメタデータを見たいので、専用の使い捨ての合言葉（トークン）をください」と、特別なリクエスト（PUTリクエスト）を送る必要があります。
2. 合言葉を持っていないとデータは渡さない
メタデータ本体を取りに行くときは、さきほど手に入れた「合言葉」をヘッダーに添えて提示しなければいけません。

ここでSSRF（不正なリクエストを強制する攻撃）の視点に戻ってみましょう。
多くの単純なSSRF脆弱性では、攻撃者は「データの取得（GETリクエスト）」は仕掛けられても、「合言葉を先にもらう（PUTリクエスト）」という複雑な手順を同時に実行させることが非常に難しいのです。

つまり、泥棒は「合言葉」を手に入れられないため、たとえ窓から侵入してきても、肝心の引き出しを開けることができなくなります。これが、IMDSv2がSSRFに対して圧倒的に強い理由です！

—

4. 実務で設定しよう！IMDSv2の強制とコード例

「なるほど、じゃあうちのクラウドでもIMDSv2を義務化（強制）したいな」と思ったそこのあなた。実務での設定方法と、開発時のコードの書き方を一緒に見ていきましょう。

① インフラ側の設定（AWS CLIの例）

AWSで新しくサーバーを作る時、あるいは既存のサーバーをアップデートする時は、IMDSv1を禁止して「v2を必須（強制）」にする設定を行います。

# AWS CLIを使って、インスタンスのメタデータサービスをIMDSv2必須に設定する例
aws ec2 modify-instance-metadata-options \
    --instance-id i-0123456789abcdef0 \
    --http-tokens required \
    --http-endpoint enabled

*(※日本語コメント：--http-tokens required と指定することで、古いIMDSv1へのアクセスを遮断し、IMDSv2のトークン利用を強制しています)*

② アプリケーション側（PHP）でのIMDSv2の取得コード例

もし皆さんが、サーバー上で動くアプリケーションからメタデータを取得するプログラムを書く場合、IMDSv2では次のような手順（2ステップ）を踏むことになります。

<?php
// ステップ1: IMDSv2のセッショントークンを取得する (PUTリクエスト)
$ch = curl_init('http://169.254.169.254/latest/api/token');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'PUT');
// トークンの有効期限（秒）をヘッダーで指定します
curl_setopt($ch, CURLOPT_HTTPHEADER, [
    'X-aws-ec2-metadata-token-ttl-seconds: 21600'
]);
$token = curl_exec($ch);
curl_close($ch);

if ($token) {
    // ステップ2: 取得したトークンをヘッダーに添えて、メタデータを取りに行く (GETリクエスト)
    $ch2 = curl_init('http://169.254.169.254/latest/meta-data/instance-id');
    curl_setopt($ch2, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch2, CURLOPT_HTTPHEADER, [
        'X-aws-ec2-metadata-token: ' . $token
    ]);
    $instanceId = curl_exec($ch2);
    curl_close($ch2);

    echo "インスタンスID: " . htmlspecialchars($instanceId, ENT_QUOTES, 'UTF-8');
} else {
    echo "トークンの取得に失敗しました。";
}
?>

*(※日本語コメント：プログラムから安全にメタデータを取得するため、最初に PUT でトークンを取得し、次の GET リクエストのカスタムヘッダーにそれを載せているのがポイントです)*

—

5. まとめ：安全なクラウドライフに向けて

今回は、クラウドメタデータサービス（IMDSv1とIMDSv2）の仕組みから、SSRF攻撃への対策までを分かりやすく解説しました。

IMDSv1は、鍵の掛かっていない引き出しのようなもので、SSRF経由で重要情報が盗まれるリスクがあった。
IMDSv2は、使い捨ての「合言葉（トークン）」を要求する仕組みにより、SSRF耐性が飛躍的に向上している。
クラウドインフラを構築する際は、必ず http-tokens を required にして、古い仕組みをシャットアウトしよう！

セキュリティの対策と聞くと身構えてしまいますが、一つひとつの仕組みは「家やオフィスの防犯」と同じように、とてもシンプルで理にかなったものです。

今日学んだ知識を活かして、ぜひ皆さんのプロジェクトやインフラ環境でもIMDSv2が正しく設定されているか確認してみてくださいね。「一歩ずつ、安全で強いシステムを作っていきましょう！」

それでは、また次回のセキュリティ解説でお会いしましょう！