【実務・中級編】クラウド環境におけるメタデータサービス (IMDSv2) の強制 – アプリケーションセキュリティ & 安全な開発防御ガイド

2026.07.25

攻撃者の盲点をつぶせ！クラウド環境の最終防衛線、IMDSv2強制によるSSRF完全防御戦略

やあ、みんな。セキュリティバイブルを手に、日夜システムの堅牢化に励んでいるエンジニア諸君。私は長年、最前線でサイバー攻撃と対峙し、数々のインシデントを未然に防いできたセキュリティチーフだ。今日は、君たちが普段意識しにくい、しかし一度狙われたら取り返しのつかないダメージをもたらす可能性のある盲点、クラウド環境のメタデータサービスについて、その奥深さと具体的な防御策を徹底的に解説していこう。

教科書的なガイドラインや一般的な勧告だけでは、実際の攻撃者の巧妙な手口には到底太刀打ちできない。現場での泥臭いインシデントハンドリングと、攻撃者がどこを狙うかという深い洞察があって初めて、本当のセキュリティが実現する。今日はその知見を惜しみなく共有するぞ。

「またか…」SSRF攻撃、その深淵とIMDSv1の脆弱性

君たちは「SSRF (Server-Side Request Forgery)」という言葉を耳にしたことがあるだろう。Webアプリケーションが提供する機能を使って、攻撃者が意図しない内部ネットワーク上のリソースや外部サービスにリクエストを送信させる攻撃だ。

「うちのシステムはWAFで内部IPへのアクセスはブロックしてるから大丈夫！」なんて油断している後輩がいたら、私はまず「本当にそうか？」と問い詰めるだろう。なぜなら、SSRF攻撃の本質は、サーバー自身にリクエストを生成させることにあるからだ。WAFは外部からのリクエストをフィルタリングするが、サーバー自身が生成するリクエストは、その防御網をすり抜けてしまう可能性がある。

クラウド環境、特にAWSにおいては、EC2インスタンスのメタデータサービス (IMDS: Instance Metadata Service) がこのSSRF攻撃の格好の標的となる。

IMDSv1の危険な仕組み

IMDSv1は、EC2インスタンスが自身の情報（インスタンスID、リージョン、IAMロールの一時認証情報など）を取得するためのシンプルなHTTPエンドポイントだ。

http://169.254.169.254/latest/meta-data/

このローカルIPアドレス (169.254.169.254) は、EC2インスタンス内からのみアクセス可能であり、外部からは到達できない。しかし、SSRFの脆弱性を持つWebアプリケーションがあると、攻撃者は以下のようなステップで機密情報を窃取することが可能になる。

1. 脆弱なアプリケーションの発見:
例えば、http://example.com/proxy?url= のように、URLをパラメータとして受け取り、そのURLの内容を取得して表示するような機能を持つWebアプリケーション。

2. SSRF攻撃の実行 (PoC):
攻撃者は、http://example.com/proxy?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/my-iam-role のようなリクエストを送信する。

もしIMDSv1が有効な場合、Webアプリケーションは内部で http://169.254.169.254/latest/meta-data/iam/security-credentials/my-iam-role にリクエストを送り、その結果（IAMロールの一時認証情報、つまりAWSのアクセスキー、シークレットキー、セッショントークン！）を攻撃者に返してしまうのだ。

この一時認証情報を手に入れれば、攻撃者はそのIAMロールが持つ権限で、S3バケットへのアクセス、EC2インスタンスの起動、RDSへの接続など、あらゆる操作が可能になってしまう。これはまさに、クラウド環境のマスターキーを奪われるに等しい事態だ。

3. さらに悪質なケース: User Dataの漏洩
インスタンスの起動時に渡されるUser Dataには、データベースの接続情報やAPIキーなど、さらに機密性の高い情報が含まれていることがある。これもIMDSv1経由で取得されてしまう可能性がある。

http://169.254.169.254/latest/user-data

君たちのシステムがどんなに強固なWAFやネットワークACLで守られていても、アプリケーション内部にSSRFの脆弱性が一つでもあれば、この地獄の扉は開いてしまう。この現実を直視し、対策を講じなければならない。

IMDSv2の救世主としての登場：セッションベースの認証で壁を築く

AWSは、このIMDSv1の脆弱性に対処するため、よりセキュアなIMDSv2 (Instance Metadata Service Version 2) を導入した。IMDSv2は、SSRF攻撃を非常に困難にする「セッションベースの認証」という強力な防御メカニズムを持っている。

IMDSv2の仕組み：この一手間がシステムを守る

IMDSv2では、メタデータにアクセスするために、まずセッショントークンを取得する必要がある。このトークンは一定時間（最大6時間）有効で、メタデータへのリクエストには必ずこのトークンをHTTPヘッダーに含めなければならない。

具体的なフローはこうだ。

1. トークンの取得:
EC2インスタンス内から、PUTリクエストを使ってIMDSv2エンドポイントにトークンを要求する。
このPUTリクエストは、X-aws-ec2-metadata-token-ttl-seconds ヘッダーでトークンの有効期限を指定する。

PUT http://169.254.169.254/latest/api/token
X-aws-ec2-metadata-token-ttl-seconds: 21600 (例: 6時間)

このPUTリクエストは、HTTPホップリミットが1に設定されている必要がある。つまり、同一のEC2インスタンスから直接送信されたリクエスト以外は受け付けない。これにより、リバースプロキシやSSRFを介したリクエストではトークン取得が極めて困難になる。

2. メタデータの取得:
取得したトークンを X-aws-ec2-metadata-token ヘッダーに含め、GETリクエストでメタデータエンドポイントにアクセスする。

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/my-iam-role
X-aws-ec2-metadata-token: [ここに取得したトークン]

この「PUTリクエストでトークン取得」→「GETリクエストでトークンをヘッダーに含めてメタデータ取得」という二段階認証が、SSRF攻撃の強力な防御となる。一般的なSSRF攻撃はGETリクエストしか発行できないか、PUTリクエストをサポートしていてもホップリミットの制約を回避できないため、IMDSv2のトークンを取得することが非常に難しいのだ。

実践！IMDSv2強制設定とセキュアなアプリケーション実装

さて、IMDSv2の重要性は理解できたな。ここからは、君たちのシステムをSSRFから完全に守るための具体的な設定手順と実装例を、コピペで動く形で提供しよう。

1. EC2インスタンスでのIMDSv2強制設定

まずは、EC2インスタンス自体でIMDSv2を強制し、IMDSv1を無効化する設定だ。既存のインスタンスにも、新規に起動するインスタンスにも適用できる。

1-1. AWS CLIでの設定

既存のEC2インスタンスに適用する場合

すでに稼働中のインスタンスに対してIMDSv2を強制する。

IMDSv2を強制 (HttpTokens=required) し、
ホップリミットを1 (HttpPutResponseHopLimit=1) に設定する。
これにより、IMDSv2トークン取得がインスタンス内部からの直接リクエストに限定される。
HttpEndpoint=enabled はIMDSエンドポイント自体を有効にする設定。
aws ec2 modify-instance-metadata-options \
–instance-id i-0abcdef1234567890 \
–http-tokens required \
–http-endpoint enabled \
–http-put-response-hop-limit 1 \
–region ap-northeast-1 # 環境に合わせてリージョンを指定

新規EC2インスタンス起動時に適用する場合

新しいインスタンスを起動する際に、最初からIMDSv2を強制する設定を含める。

aws ec2 run-instances \
–image-id ami-0abcdef1234567890 \
–instance-type t3.micro \
–count 1 \
–tag-specifications ‘ResourceType=instance,Tags=[{Key=Name,Value=MyIMDSv2ForcedInstance}]’ \
–metadata-options ‘HttpTokens=required,HttpPutResponseHopLimit=1,HttpEndpoint=enabled’ \
–region ap-northeast-1 # 環境に合わせてリージョンを指定

1-2. Infrastructure as Code (IaC) での設定 (Terraformの例)

Terraformを使っているなら、コードでIMDSv2の強制設定を管理することが推奨される。

resource “aws_instance” “web_server” {
ami = “ami-0abcdef1234567890” # 適切なAMI IDに置き換える
instance_type = “t3.micro”
key_name = “my-key-pair” # 適切なキーペア名に置き換える
vpc_security_group_ids = [“sg-0123456789abcdef0”] # 適切なセキュリティグループIDに置き換える

# ★★★ ここが重要！IMDSv2を強制するための設定 ★★★
metadata_options {
http_endpoint = “enabled” # メタデータサービスエンドポイントを有効化
http_tokens = “required” # IMDSv2トークンを必須とする (IMDSv1を無効化)
http_put_response_hop_limit = 1 # トークン要求時のホップリミットを1に設定 (SSRF防御)
}

tags = {
Name = “Web-Server-IMDSv2-Forced”
}
}

CloudFormationでも同様の設定が可能だ。MetadataOptions プロパティを利用する。

2. アプリケーションコードでのIMDSv2対応

君たちのアプリケーションが直接IMDSを利用することは少ないかもしれない。ほとんどの場合、AWS SDK（Boto3 for Python, AWS SDK for PHPなど）が内部でIMDSv2を自動的に利用してくれるからだ。しかし、その仕組みを理解しておくことは、デバッグやトラブルシューティング、そしてより深いセキュリティ理解に繋がる。

以下は、AWS SDKを使わずにIMDSv2の挙動を再現する例だ。

2-1. PythonでのIMDSv2対応 (requestsライブラリ使用)

import requests
import json
import os

IMDSv2のトークンを取得する関数
def get_imds_v2_token():
try:
# PUTリクエストでトークンを取得。ホップリミットは1に設定されているため、
# アプリケーションが直接発行しないと成功しない。
response = requests.put(
“http://169.254.169.254/latest/api/token”,
headers={“X-aws-ec2-metadata-token-ttl-seconds”: “21600”}, # トークン有効期間 (秒)
timeout=1 # タイムアウト設定は重要
)
response.raise_for_status() # HTTPエラーが発生した場合に例外を発生させる
return response.text
except requests.exceptions.RequestException as e:
print(f”IMDSv2トークン取得失敗: {e}”)
return None

IAMロール名と一時認証情報を取得する関数 (IMDSv2対応)
def get_iam_credentials_imds_v2():
token = get_imds_v2_token()
if not token:
return {“error”: “IMDSv2トークン取得失敗”}

try:
# まず、利用可能なIAMロール名を取得する
# IMDSv2ではトークンをヘッダーに含める必要がある
role_name_response = requests.get(
“http://169.254.169.254/latest/meta-data/iam/security-credentials/”,
headers={“X-aws-ec2-metadata-token”: token},
timeout=1
)
role_name_response.raise_for_status()
role_name = role_name_response.text.strip()

if not role_name:
return {“error”: “IAMロール名が見つかりません”}

# 次に、そのIAMロールの一時認証情報を取得する
credentials_response = requests.get(
f”http://169.254.169.254/latest/meta-data/iam/security-credentials/{role_name}”,
headers={“X-aws-ec2-metadata-token”: token},
timeout=1
)
credentials_response.raise_for_status()
return json.loads(credentials_response.text)

except requests.exceptions.RequestException as e:
print(f”IAM認証情報取得失敗: {e}”)
return {“error”: f”IAM認証情報取得失敗: {e}”}
except json.JSONDecodeError as e:
print(f”JSONパースエラー: {e}”)
return {“error”: f”JSONパースエラー: {e}”}

実行例
if __name__ == “__main__”:
print(“IMDSv2経由でIAM認証情報を取得中…”)
credentials = get_iam_credentials_imds_v2()

if “error” not in credentials:
print(“IAM認証情報 (一部):”)
print(f” AccessKeyId: {credentials.get(‘AccessKeyId’, ‘N/A’)}”)
print(f” SecretAccessKey: {” len(credentials.get(‘SecretAccessKey’, ”))}”) # セキュリティのため非表示
print(f” Token: {” len(credentials.get(‘Token’, ”))}”) # セキュリティのため非表示
print(f” Expiration: {credentials.get(‘Expiration’, ‘N/A’)}”)
else:
print(credentials[“error”])

AWS SDK (boto3) はIMDSv2を自動的に利用しようとします。
以下のコードはIMDSv2の仕組みを理解するためのものであり、
通常はboto3のクライアント/リソースを直接使用します。
例:
import boto3
s3_client = boto3.client(‘s3′, region_name=’ap-northeast-1’)
print(s3_client.list_buckets()) # これだけで内部的にIMDSv2が使われる

2-2. PHPでのIMDSv2対応 (GuzzleHttpライブラリ使用)

  • IMDSv2トークンを取得する関数
  • @return string|null 成功すればトークン文字列、失敗すればnull

    • /
    function getImdsV2Token(): ?string
    {
    $client = new Client([
    ‘base_uri’ => ‘http://169.254.169.254/’,
    ‘timeout’ => 1, // タイムアウト設定は重要
    ]);

    try {
    // PUTリクエストでトークンを取得。ホップリミットは1に設定されているため、
    // アプリケーションが直接発行しないと成功しない。
    $response = $client->request(‘PUT’, ‘latest/api/token’, [
    ‘headers’ => [
    ‘X-aws-ec2-metadata-token-ttl-seconds’ => ‘21600’, // トークン有効期間 (秒)
    ],
    ]);
    return (string)$response->getBody();
    } catch (RequestException $e) {
    error_log(“IMDSv2トークン取得失敗: ” . $e->getMessage());
    return null;
    }
    }

    /

    • IAMロール名と一時認証情報を取得する関数 (IMDSv2対応)
    • @return array 成功すれば認証情報の配列、失敗すればエラー情報

    /
    function getIamCredentialsImdsV2(): array
    {
    $token = getImdsV2Token();
    if (is_null($token)) {
    return [“error” => “IMDSv2トークン取得失敗”];
    }

    $client = new Client([
    ‘base_uri’ => ‘http://169.254.169.254/’,
    ‘timeout’ => 1, // タイムアウト設定は重要
    ]);

    try {
    // まず、利用可能なIAMロール名を取得する
    // IMDSv2ではトークンをヘッダーに含める必要がある
    $roleNameResponse = $client->request(‘GET’, ‘latest/meta-data/iam/security-credentials/’, [
    ‘headers’ => [
    ‘X-aws-ec2-metadata-token’ => $token,
    ],
    ]);
    $roleName = trim((string)$roleNameResponse->getBody());

    if (empty($roleName)) {
    return [“error” => “IAMロール名が見つかりません”];
    }

    // 次に、そのIAMロールの一時認証情報を取得する
    $credentialsResponse = $client->request(‘GET’, “latest/meta-data/iam/security-credentials/{$roleName}”, [
    ‘headers’ => [
    ‘X-aws-ec2-metadata-token’ => $token,
    ],
    ]);
    return json_decode((string)$credentialsResponse->getBody(), true);

    } catch (RequestException $e) {
    error_log(“IAM認証情報取得失敗: ” . $e->getMessage());
    return [“error” => “IAM認証情報取得失敗: ” . $e->getMessage()];
    } catch (JsonException $e) {
    error_log(“JSONパースエラー: ” . $e->getMessage());
    return [“error” => “JSONパースエラー: ” . $e->getMessage()];
    }
    }

    // 実行例
    if (php_sapi_name() === ‘cli’) {
    echo “IMDSv2経由でIAM認証情報を取得中…\n”;
    $credentials = getIamCredentialsImdsV2();

    if (!isset($credentials[‘error’])) {
    echo “IAM認証情報 (一部):\n”;
    echo ” AccessKeyId: ” . ($credentials[‘AccessKeyId’] ?? ‘N/A’) . “\n”;
    echo ” SecretAccessKey: ” . str_repeat(”, strlen($credentials[‘SecretAccessKey’] ?? ”)) . “\n”; // セキュリティのため非表示
    echo ” Token: ” . str_repeat(”, strlen($credentials[‘Token’] ?? ”)) . “\n”; // セキュリティのため非表示
    echo ” Expiration: ” . ($credentials[‘Expiration’] ?? ‘N/A’) . “\n”;
    } else {
    echo $credentials[‘error’] . “\n”;
    }
    }

    // AWS SDK for PHP はIMDSv2を自動的に利用しようとします。
    // 以下のコードはIMDSv2の仕組みを理解するためのものであり、
    // 通常はSDKのクライアント/リソースを直接使用します。
    // 例:
    // use Aws\S3\S3Client;
    // $s3Client = new S3Client([
    // ‘region’ => ‘ap-northeast-1’,
    // ‘version’ => ‘latest’
    // ]);
    // print_r($s3Client->listBuckets()); // これだけで内部的にIMDSv2が使われる

    これらのコード例は、IMDSv2がどのように機能するかを理解するためのものだ。君たちのアプリケーションがAWS SDKを利用している場合、これらの低レベルな実装を直接書く必要はほとんどない。重要なのは、IMDSv2を強制設定し、SDKがその恩恵を自動的に受けられるようにすることだ。

    3. 多層防御の視点：WAFとNginxでの追加防御

    IMDSv2の強制は非常に強力な防御策だが、「万が一」に備えるのがセキュリティチーフの務めだ。アプリケーション層でのSSRF脆弱性を見逃してしまった場合や、IMDSv2が有効でない古いインスタンスが残ってしまった場合を想定し、ネットワーク層でも防御を固めよう。

    3-1. WAF (Web Application Firewall) での防御

    AWS WAFやModSecurityなどのWAFを使って、169.254.169.254 などのクラウドメタデータサービスのアドレスへのアクセスをブロックするルールを設定する。

    AWS WAFの例

    AWS WAFでは、String Match Rule や Regex Match Rule を使用して、リクエストのURLやボディに 169.254.169.254 や metadata.google.internal (GCPの場合) といった文字列が含まれていないかをチェックし、含まれていればブロックするルールを設定できる。

    • ルールタイプ: String match rule
    • Inspected part of web request: URI path, Query string, Request body など
    • Match type: Contains string
    • String to match: 169.254.169.254
    • Action: Block

    さらに、メタデータサービスへのパス（/latest/meta-data/など）をブロックするルールも追加するとより堅牢になる。

    ModSecurity (Nginxと連携) の例

    Nginxのリバースプロキシ環境でModSecurityを利用している場合、以下のようなルールを追加できる。

    ModSecurityの設定ファイル (例: modsecurity.conf または別のルールファイル) に記述

    クラウドメタデータサービスへの直接的なURIパスをブロック
    /latest/meta-data/ や /20XX-XX-XX/meta-data/ などのパターンを検出
    SecRule REQUEST_URI “@rx ^/(latest|20[0-9]{2}-[0-9]{2}-[0-9]{2})/meta-data/” \
    “id:1000001,\
    phase:2,\
    block,\
    msg:’Cloud Metadata Service URI access detected – BLOCKING’,\
    severity:’CRITICAL'”

    リクエストパラメータやボディにクラウドメタデータIPアドレスが含まれる場合をブロック
    169.254.169.254 (AWS), metadata.google.internal (GCP) など
    SecRule ARGS_GET|ARGS_POST|REQUEST_BODY “@rx (169\.254\.169\.254|metadata\.google\.internal)” \
    “id:1000002,\
    phase:2,\
    block,\
    msg:’Cloud Metadata IP address detected in request parameters/body – BLOCKING’,\
    severity:’CRITICAL'”

    注意: これらのルールは非常に強力なため、正当な処理がブロックされないか慎重にテストしてください。

    3-2. Nginx (リバースプロキシ) での防御

    Nginxをリバースプロキシとして利用している場合、内部IPアドレスへのリクエストをブロックする設定を追加することで、SSRF攻撃をさらに防ぐことができる。

    server {
    listen 80;
    server_name example.com;

    location / {
    # ★★★ ここが重要！内部IPアドレスへのリクエストをNginxレベルでブロック ★★★
    # 169.254.169.254 はEC2メタデータサービスのアドレス
    # 127.0.0.1 はローカルホスト
    # 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 はプライベートIPアドレス範囲
    # アプリケーションがこれらの内部IPにアクセスする必要がある場合は、
    # 許可する特定のパスやIPを別途設定するか、このルールを調整してください。
    # $host はリクエストヘッダーのHostフィールド、$uriはURIパス
    if ($host ~ “^(169\.254\.169\.254|127\.0\.0\.1|10\.|172\.16\.|192\.168\.)”) {
    return 403; # 禁止されたリクエスト (Forbidden)
    }
    # URIパスにメタデータサービスへの直接的なパスが含まれる場合もブロック
    if ($uri ~ “^(/latest/meta-data/|/aws/credentials)”) {
    return 403; # 禁止されたリクエスト
    }

    # バックエンドへのプロキシ設定
    proxy_pass http://backend_servers; # ここは君たちのバックエンドサーバーに合わせて変更
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    }

    # … その他の設定
    }

    このNginx設定は、アプリケーションがSSRF脆弱性を抱えていたとしても、外部からのリクエストが 169.254.169.254 やその他の内部IPアドレスにルーティングされるのを防ぐことができる。

    まとめ：セキュリティは一度設定したら終わりではない

    今日の話はどうだったかな？クラウド環境におけるSSRF攻撃とIMDSv1の危険性、そしてIMDSv2による強力な防御策、さらにWAFやNginxによる多層防御について、具体的な設定とコードを交えて解説した。

    セキュリティは、一度設定したら終わり、というものではない。攻撃手法は常に進化し、我々防御側もそれに合わせて進化し続けなければならない。特にクラウド環境では、その利便性の裏に潜むリスクを深く理解し、適切な対策を講じることが不可欠だ。

    今すぐ、君たちの管理するEC2インスタンスがIMDSv2を強制しているか確認しろ。 もしIMDSv1が有効なままのインスタンスがあれば、それは攻撃者にとって格好のターゲットとなりうる。そして、アプリケーション開発においても、外部からのURLを受け取る機能は特に慎重にレビューし、SSRF対策を徹底すること。

    君たちが守るシステムは、多くのユーザーの信頼の上に成り立っている。その信頼を裏切らないために、手を抜くな。最高のセキュリティは、常に最新の知識と、それを実践する君たちの意識から生まれるのだ。

    また次の機会に、最前線の知見を共有しよう。ご武運を。

    スポンサーリンク

    コメント

    タイトルとURLをコピーしました