セキュリティの観点からAWS IMDSv1とIMDSv2を理解する

AWS EC2を運用していると、IMDSv1、IMDSv2という表現をよく目にします。

ここでIMDSはInstance Metadata Serviceの略で、EC2インスタンス内部から自身のメタデータを照会できるサービスです。

例えば、EC2内部では以下のような情報を照会できます。

インスタンスID
AMI ID
リージョン
アベイラビリティゾーン
ネットワーク情報
IAMロール名
IAMロールの一時的な認証情報

この中でセキュリティの観点から最も重要なのは、IAMロールの一時的な認証情報です。

EC2にIAMロールがアタッチされている場合、アプリケーションはアクセスキーをコードや環境変数に直接保存する必要がありません。

代わりにIMDSを通じて一時的な認証情報を取得し、AWS APIを呼び出すことができます。

この構造自体は非常に優れたセキュリティ設計です。

しかし、アプリケーションにSSRFのような脆弱性がある場合、話は変わってきます。

1. IMDSはどこにあるのか？

EC2インスタンス内部からは、以下のリンクローカルアドレスでIMDSにアクセスできます。

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

例えば、インスタンスIDを照会するには、次のように実行します。

curl http://169.254.169.254/latest/meta-data/instance-id

IAMロールがアタッチされているインスタンスであれば、以下のパスでロール名を確認できます。

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

ロール名が分かれば、そのロールの一時的な認証情報も照会できます。

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME

ここで返される情報には、以下の値が含まれます。

AccessKeyId
SecretAccessKey
Token
Expiration

つまり、EC2内部で動作するアプリケーションは、IMDSを通じてAWS API呼び出しに必要な一時的な認証情報を取得できます。

2. IMDSv1の動作方式

IMDSv1は構造が非常に単純です。

別途トークンなしで、HTTP GETリクエストだけでメタデータを照会できます。

例は以下の通りです。

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

IAMロールの一時的な認証情報も次のように照会できます。

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

IMDSv1の利点は、単純さと互換性です。

古いAWS SDK、古いエージェント、古いスクリプトでも簡単に動作します。

しかし、セキュリティの観点からは、この単純さが問題となる可能性があります。

3. IMDSv1のセキュリティ問題

IMDSv1の最大の問題は、リクエストに別途トークンが不要である点です。

IMDSは本来、EC2内部からのみアクセス可能なサービスです。

したがって、外部ユーザーがインターネットから直接169.254.169.254にアクセスできるわけではありません。

しかし、ウェブアプリケーションにSSRF脆弱性がある場合、攻撃者はアプリケーションサーバーにIMDSへのアクセスを代行させることができます。

例えば、あるウェブサービスにURLを入力すると、サーバーがそのURLを代わりに取得する機能があると仮定してみましょう。

https://example.com/fetch?url=http://example.org/image.png

この機能がURL検証なしで動作する場合、攻撃者は次のようにリクエストできます。

https://example.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

この場合、外部攻撃者が直接IMDSにアクセスするわけではありませんが、EC2内部のウェブアプリケーションが代わりにIMDSにアクセスすることになります。

これがSSRFとIMDSv1が結合したときに危険になる典型的なシナリオです。

4. SSRFとIMDSv1が結合すると、なぜ危険なのか？

SSRFを通じて攻撃者がIMDSにアクセスできる場合、以下の情報が漏洩する可能性があります。

EC2にアタッチされたIAMロール名
一時的なアクセスキー
一時的なシークレットキー
セッショントークン
認証情報の有効期限

このとき、EC2ロールに過度な権限が付与されている場合、被害範囲は拡大します。

例えば、以下のような権限がロールに含まれている場合、非常に危険です。

S3へのフルアクセス
Secrets Managerの全参照
DynamoDBへのフルアクセス
EC2の作成/削除権限
IAM PassRole
管理者権限

結局、問題は単に「IMDSv1を使用したか」だけではありません。

実際のセキュリティ事故の観点からは、以下の要素が複合的に作用します。

アプリケーションにSSRF脆弱性があるか？
EC2でIMDSv1が許可されているか？
EC2ロールの権限が過度か？
ネットワークまたはアプリケーションレベルでメタデータアドレスへのアクセスを遮断していないか？

5. IMDSv2の動作方式

IMDSv2は、IMDSv1のセキュリティ上の弱点を軽減するために導入された方式です。

核となるのはトークンベースのセッションです。

IMDSv2では、直接メタデータを照会することはできません。

まず、PUTリクエストでトークンを発行する必要があります。

TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" 
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

次に、メタデータリクエストにトークンをヘッダーとして含める必要があります。

curl -H "X-aws-ec2-metadata-token: $TOKEN" 
  http://169.254.169.254/latest/meta-data/instance-id

IAMロールの認証情報照会も同様です。

ROLE_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" 
  http://169.254.169.254/latest/meta-data/iam/security-credentials/)

curl -H "X-aws-ec2-metadata-token: $TOKEN" 
  http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME

つまり、IMDSv2では以下の2つのステップが必要です。

PUTリクエストでトークンを発行
発行されたトークンをヘッダーに入れてメタデータを照会

6. IMDSv2がセキュリティを強化する方式

IMDSv2は以下の方式で攻撃の難易度を高めます。

1) 単純なGETリクエストの遮断

IMDSv1では、GETリクエストだけでメタデータを取得できました。

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

しかし、IMDSv2 Requiredの状態では、トークンなしのリクエストは失敗します。

つまり、単純にURLを操作できるSSRF脆弱性であれば、IMDSv2を迂回することは困難です。

2) PUTリクエストの必要性

IMDSv2トークンはPUTリクエストで発行されます。

多くのSSRF脆弱性は単純なGETリクエストのみを許可するか、HTTPメソッドの変更を許可しません。

この場合、攻撃者はトークンを発行することが困難になります。

3) カスタムヘッダーの必要性

IMDSv2では、メタデータ照会時に以下のヘッダーが必要です。

X-aws-ec2-metadata-token: <TOKEN>

URLのみを操作できるSSRF脆弱性では、このヘッダーを追加することは困難です。

4) ホップリミットの制御

IMDSv2にはHttpPutResponseHopLimit設定があります。

この値は、IMDSv2トークン応答が通過できるネットワークホップの数を制限します。

一般的なEC2単独環境では1を使用できます。

ただし、コンテナ環境ではネットワークパスがさらに1段階増える可能性があるため、2が必要になる場合があります。

7. IMDSv1とIMDSv2の比較

区分	IMDSv1	IMDSv2
メタデータ照会方式	GETリクエスト	PUTでトークン発行後GETリクエスト
トークン必要性	なし	必要
SSRF防御力	低い	相対的に高い
カスタムヘッダー必要性	なし	必要
HTTPメソッド	主にGET	PUT + GET
運用推奨	レガシー互換用	運用環境推奨
設定値	HttpTokens=optionalで利用可能	HttpTokens=requiredで強制可能
主な利点	単純さ、互換性	セキュリティ強化
主な欠点	SSRFに脆弱になる可能性あり	旧バージョンSDK/Agentの互換性確認が必要

—

8. EC2メタデータオプションの主要設定

設定	説明	推奨
HttpEndpoint	IMDSの使用有無	不要であればdisabled
HttpTokens	IMDSv2トークンの要求有無	requiredを推奨
HttpPutResponseHopLimit	IMDSv2トークン応答のホップリミット	一般的なEC2は1、コンテナは2を検討
InstanceMetadataTags	インスタンスタグをメタデータとして公開するかどうか	不要であればdisabled

運用環境では通常、以下の方向性を推奨します。

IMDSが不要なインスタンス: HttpEndpoint disabled
IMDSが必要なインスタンス: HttpTokens required
一般的なEC2: ホップリミット1を検討
ECS/EKS/コンテナ環境: ホップリミット2を検討
インスタンスタグの照会が不要であればInstanceMetadataTags disabled

9. 現在のEC2のIMDS設定確認

AWS CLIで現在のインスタンスのメタデータオプションを確認できます。

aws ec2 describe-instances 
  --query 'Reservations[].Instances[].{
    InstanceId:InstanceId,
    State:State.Name,
    HttpEndpoint:MetadataOptions.HttpEndpoint,
    HttpTokens:MetadataOptions.HttpTokens,
    HopLimit:MetadataOptions.HttpPutResponseHopLimit,
    MetadataTags:MetadataOptions.InstanceMetadataTags
  }' 
  --output table

結果のHttpTokens値を確認してください。

optional: IMDSv1とIMDSv2の両方を許可
required: IMDSv2のみを許可

つまり、HttpTokens=optionalであれば、セキュリティの観点から移行検討対象です。

10. 既存のEC2をIMDSv2 Requiredに変更

既存のEC2インスタンスをIMDSv2 Requiredに変更するには、以下のコマンドを使用できます。

aws ec2 modify-instance-metadata-options 
  --instance-id i-xxxxxxxxxxxxxxxxx 
  --http-tokens required 
  --http-endpoint enabled

変更後には、以下のコマンドで確認します。

aws ec2 describe-instances 
  --instance-ids i-xxxxxxxxxxxxxxxxx 
  --query 'Reservations[].Instances[].MetadataOptions' 
  --output json

コンテナ環境でホップリミットを2に設定する必要がある場合は、次のように適用できます。

aws ec2 modify-instance-metadata-options 
  --instance-id i-xxxxxxxxxxxxxxxxx 
  --http-tokens required 
  --http-put-response-hop-limit 2 
  --http-endpoint enabled

11. 新規EC2にIMDSv2をデフォルト適用する

運用環境では、インスタンスを作成した後に修正するよりも、最初からIMDSv2を要求するように設定するのが良いでしょう。

起動テンプレートで以下の設定を指定できます。

{
  "MetadataOptions": {
    "HttpTokens": "required",
    "HttpEndpoint": "enabled",
    "HttpPutResponseHopLimit": 2
  }
}

AWS CLIでアカウント/リージョン単位のデフォルト値を設定することもできます。

ただし、既存のアプリケーション、エージェント、SDKがIMDSv2をサポートしていない場合、障害が発生する可能性があります。

したがって、運用環境ではすぐに強制適用するのではなく、まずIMDSv1の使用状況を確認する必要があります。

12. IMDSv1の使用状況の確認

IMDSv2への移行前には、まだIMDSv1を使用しているプロセスがないか確認する必要があります。

代表的な確認方法は以下の通りです。

CloudWatch MetadataNoTokenメトリクスの確認

MetadataNoTokenメトリクスは、トークンなしでIMDSにアクセスしたリクエストを確認するために使用されます。

簡単に言えば、IMDSv1方式のリクエストが発生したかどうかを確認できるメトリクスです。

このメトリクスが継続的に増加している場合、まだIMDSv1を使用しているアプリケーションやエージェントがあることを意味します。

IMDS Packet Analyzerの使用

AWSが提供するIMDS Packet Analyzerを使用すると、インスタンス内部でどのプロセスがIMDSv1を呼び出しているかを確認できます。

移行前には、以下の項目を点検することをお勧めします。

古いAWS CLI
古いAWS SDK
旧バージョンのSSM Agent
旧バージョンのCloudWatch Agent
直接作成したcurlスクリプト
古いアプリケーションライブラリ

13. セキュリティ観点からの推奨移行手順

運用環境では、以下の順序で移行するのが安全です。

EC2全体リストからHttpTokens=optionalのインスタンスを特定
CloudWatch MetadataNoTokenメトリクスを確認
IMDS Packet AnalyzerでIMDSv1呼び出しプロセスを確認
AWS CLI、SDK、SSM Agent、CloudWatch Agentを更新
開発環境でIMDSv2 Requiredをテスト
ステージング環境に適用
運用インスタンスに順次適用
起動テンプレート、Auto Scalingグループ、AMIビルドパイプラインにIMDSv2 Requiredを反映
新規インスタンスのデフォルト値をIMDSv2 Requiredに設定
組織単位での強制が必要な場合は、SCPまたはアカウントのデフォルト値を検討

14. IMDSv2だけで十分か？

IMDSv2は非常に重要な防御装置です。

しかし、IMDSv2だけを適用したからといって、すべての危険がなくなるわけではありません。

セキュリティの観点からは、以下の対策を併せて適用する必要があります。

IAMロールの最小権限

IMDSを通じて奪取されうる最も重要な情報は、IAMロールの一時的な認証情報です。

したがって、EC2ロールには最小限の権限のみを付与する必要があります。

悪い例は以下の通りです。

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

良い例は、必要なサービスとリソースのみを制限する方式です。

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject"
  ],
  "Resource": [
    "arn:aws:s3:::example-bucket/app/*"
  ]
}

SSRF防御

ウェブアプリケーションで外部URLを受け取り、サーバーが直接リクエストする機能は注意が必要です。

以下のIPアドレスは基本的に遮断対象です。

169.254.169.254
fd00:ec2::254
127.0.0.1
localhost
RFC1918プライベートIP帯域
リンクローカルアドレス
内部DNS名
クラウドメタデータエンドポイント

また、リダイレクトが発生する場合、最終的な宛先も再度検証する必要があります。

DNSリバインディング攻撃も考慮する必要があります。

コンテナ環境の権限分離

ECSやEKS環境では、コンテナがEC2ノードのインスタンスプロファイル権限を使用できるか確認する必要があります。

可能であれば、以下の構造を使用することをお勧めします。

ECS: タスクロールを使用
EKS: IRSAまたはEKS Pod Identityを使用
ノードロールの権限を最小化
PodまたはコンテナからのIMDSアクセス必要性を検討

コンテナがノードのIMDSにアクセスでき、ノードロールの権限が過度である場合、コンテナが奪取された際にAWSアカウントの権限に拡大される可能性があります。

15. CISベンチマークの観点から見たIMDSv2

CIS AWS Foundations Benchmarkやクラウドセキュリティ点検基準では、EC2メタデータサービスの設定を重要なセキュリティ項目と見なしています。

特に、以下のような観点から点検できます。

IMDSv1が許可されているか？
IMDSv2 Requiredが適用されているか？
EC2ロールに過度な権限が付与されているか？
インスタンスメタデータタグの公開が必要か？
コンテナワークロードでノードロールの権限が公開される可能性はあるか？

自動診断スクリプトでは通常、describe-instances結果のMetadataOptions値を確認します。

例えば、以下の基準で診断できます。

HttpTokens == required 이면 양호
HttpTokens == optional 이면 취약 또는 개선 필요

ただし、運用環境では単にコマンドで変更するよりも、アプリケーションの互換性確認が優先されます。

16. 実務上の結論

IMDSv1は古い方式であり、単純なGETリクエストだけでメタデータを照会できます。

このため、SSRF脆弱性と結合されると、EC2 IAMロールの一時的な認証情報が漏洩する可能性があります。

IMDSv2はトークンベースのセッションを使用します。

まずPUTリクエストでトークンを発行し、その後のリクエストにはトークンヘッダーを含める必要があります。

この構造のおかげで、単純なSSRF攻撃でメタデータを奪取することが困難になります。

運用環境では、以下の基準を推奨します。

可能であればIMDSv2 Requiredを適用
IMDSが不要なインスタンスはIMDSを無効化
EC2 IAMロールは最小権限で設計
SSRF防御ロジックを適用
コンテナ環境ではタスクロール、IRSA、EKS Pod Identityを使用
移行前にMetadataNoTokenメトリクスとエージェントの互換性を確認

一言でまとめると以下の通りです。

IMDSv1は互換性重視のレガシー方式であり、

IMDSv2はSSRFとメタデータ奪取のリスクを軽減するためのセキュリティ強化方式です。

運用環境では、特別な理由がない限り、IMDSv2 Requiredをデフォルトとすることが安全です。

参考リンク

AWS EC2 User Guide – Instance Metadata Service

AWS EC2 User Guide – Configure instance metadata options

AWS Security Blog – Add defense in depth against SSRF vulnerabilities

AWS Security Blog – Get the full benefits of IMDSv2 and disable IMDSv1