LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

AWS IMDSv2とは、EC2メタデータをトークン必須にするセッション方式

AWS IMDSv2とは、EC2インスタンスメタデータサービス(IMDS。起動情報やIAMロールの認証情報をインスタンス内部から取得する仕組み)を、セッション型のトークン必須方式に切り替える設定を指します^*1。AWSは2024年3月25日、新規起動インスタンスをアカウント単位でIMDSv2専用にできる機能を発表しました^*3。

IMDSv2はまずPUTリクエストでセッショントークンを取得します。トークンの有効期間は1秒〜21600秒(6時間)の範囲で指定でき、期間内は同じトークンを使い回せます^*1。以降のGETリクエストには、このトークンをX-aws-ec2-metadata-tokenヘッダーに含める必要があります^*1。

一方のIMDSv1は、トークンなしのGETリクエストだけでメタデータを取得できる方式です^*1。両者の仕組みの違いは、リスクの受け止め方にも直結します。詳しい比較は次章以降で整理します。

2024年3月、AWSがIMDSv2のアカウント既定化機能を発表

IMDSv2が生まれた背景には、SSRF(サーバーサイドリクエストフォージェリ。アプリケーションの脆弱性を突いて、攻撃者が意図しない宛先へリクエストを送らせる手法)への対策があります。AWSのセキュリティチームは2019年11月19日公開のブログで、SSRFの多くは攻撃者が任意のヘッダーを付与できる点が課題だと説明しました^*4。

トークンをPUTで取得し、GETに含める2段階の仕組みについて、AWSは単一の静的ヘッダー要件よりも常に厳密に効果的だと述べています^*4。攻撃者が単純にヘッダーを転送するだけでは、事前に発行されたトークンまでは持ち出せないためです^*4。

その後AWSは、既定値そのものをIMDSv2寄りに変える取り組みを段階的に進めました。2023年11月6日のAWS公式ブログでは、2024年半ばを目安に新しく提供するEC2インスタンスタイプをIMDSv2専用にする方針が示されています^*2。そして2024年3月25日、アカウント単位で新規起動インスタンスの既定値をIMDSv2専用に設定できる機能が公開されました^*3。この機能は全リージョンとAWS GovCloud(US)で利用できます^*3。

この機能と合わせて、IMDSv1呼び出しが拒否された回数を示すCloudWatchメトリクスMetadataNoTokenRejectedも用意されています^*3*6。既存インスタンスの設定は自動では変わらないため、対応が必要かどうかは自社の起動設定を確認しないと判断できません^*5。

IMDSv1とIMDSv2の仕組みの違い——SSRFへの耐性を左右するトークン

IMDSv1——ヘッダーなしのGETでメタデータを取得できる方式

IMDSv1は、インスタンス内部からのGETリクエストだけでメタデータを返す方式です^*1。リクエストに特別なヘッダーは不要で、実装は手軽です。ただしこの手軽さは、外部からリクエストを発生させられる脆弱性があると、意図せずメタデータへ到達される経路にもなり得ます^*4。

IMDSv2——PUTでトークンを取得し以降のGETに必須とする方式

IMDSv2はまずPUTでトークンを要求し、そのトークンをヘッダーに載せたGETでメタデータを取得します^*1。トークンは発行元のインスタンスに固有で、ほかのインスタンスからは利用できません^*1。HttpTokensをrequiredに設定すると、トークンのない、あるいは期限切れのリクエストは401エラーになります^*1。

PUTリクエストの応答には、既定でホップ制限(IPプロトコル層でのTTL)が1に設定されています^*1。ホップ制限は1〜64の範囲で調整でき、コンテナ環境など複数ホップを経由する構成では、この値を引き上げないと取得に失敗する場合があります^*1。

両者の違いを整理すると次の通りです。

監査から強制化まで——IMDSv2移行の5ステップ

AWSは既存環境でIMDSv2を必須化する際の手順を、5段階の推奨パスとして公開しています^*6。段階を飛ばして一気にrequiredへ切り替えると、IMDSv1に依存したソフトウェアが動かなくなるおそれがあるため、順を追った移行が推奨されています^*6。

ステップ1は、IMDSv2がoptionalのままのインスタンスの洗い出しと、IMDSv1呼び出しの監査です^*6。AWS CLIのdescribe-instancesでmetadata-options.http-tokensがoptionalの一覧を取得できます^*6。あわせてCloudWatchのMetadataNoTokenメトリクスを見れば、IMDSv1呼び出しの有無を確認できます^*6。

ステップ2は、IMDSv2に対応したSDK・CLIへのソフトウェア更新です^*6。IAMロールの認証情報取得にIMDSv1しか使えない古いライブラリが残っていると、必須化した瞬間に処理が失敗します^*1*6。事前の洗い出しと更新が欠かせません。

ステップ3では、既存インスタンスにmodify-instance-metadata-optionsコマンドで–http-tokens requiredを適用します^*6。この変更は稼働中のインスタンスに即時反映され、再起動は必要ありません^*6。新規インスタンスもrun-instances時にHttpTokensをrequiredで指定します^*6。切替後はMetadataNoTokenRejectedメトリクスで、影響を継続的に確認します^*6。

ステップ4は、アカウント単位の既定値をrequiredに変更する段階です^*6。modify-instance-metadata-defaultsコマンドで–http-tokens requiredを指定します^*3*6。–http-put-response-hop-limitもあわせて指定できます^*3*6。設定後は、そのリージョンで起動する新規インスタンスへ既定値として自動的に適用されます^*3*6。

ステップ5は、IMDSv1への依存がないと確認できた段階でのアカウントレベルの強制化です^*6。強制化を有効にすると、HttpTokensがrequiredでない起動はすべて失敗するようになります^*5*6。

ec2:MetadataHttpTokensなどのIAM条件キーを使う方法も選べます。IAMポリシーやSCP(Service Control Policy。AWS Organizationsで複数アカウントに一括適用する制御ポリシー)に組み込むことで、同様の強制化を実現できます^*6。

移行で見落としやすい落とし穴——ホップ制限・IAM・アプリ側の非互換

必須化の設定変更そのものはコマンド一つで完了します。ただし影響範囲の見極めが移行の負荷を左右します。IMDSv1に依存したまま必須化すると、認証情報の取得に失敗し、アプリケーションが起動できなくなるおそれがあります^*1*6。

コンテナ環境ではホップ制限が既定の1のままだと、コンテナ内のプロセスからメタデータへ到達できない場合があります^*1。Auto Scalingグループでは、既存インスタンスと新規起動インスタンスとで設定の反映経路が異なる点にも注意が必要です^*6。既存インスタンスの設定変更に加え、起動テンプレート側のMetadataOptionsもあわせて更新する必要があります^*6。更新を怠ると、スケールアウト時に古い設定のインスタンスが混在します。

この作業を内製で担うには、複数領域の知識が要ります。EC2のインスタンスメタデータ仕様、IAM(Identity and Access Management。AWSリソースへの権限を管理する仕組み)ロールの取得経路、Auto Scalingの起動テンプレート、CloudWatchメトリクスの読み方などです^*1*6。

IMDS Packet Analyzer(IMDSv1呼び出しを検出するAWS公式のオープンソースツール)のようなツールの使い方も押さえておく必要があります^*6。監査から強制化までを一貫して担当できる体制が前提になります。

内製と外注の分かれ目——EC2運用体制の工数で判断する

IMDSv2移行そのものはAWSが手順を公開しているため、対象が少数のインスタンスであれば自社で対応できる場合もあります^*6。判断が分かれるのは、対象インスタンスが多い環境や、Auto Scaling・コンテナ基盤が絡む構成での監査と検証です。

専門パートナーに委託する場合は、依頼範囲の広さが選定の分かれ目になります。IMDSv1呼び出しの洗い出しからアプリケーション側の改修要否の判定、段階的な必須化、アカウント既定化までを一括して依頼できるかどうかを確認します^*6。内製では既存の運用担当者が通常業務と並行して対応することになり、監査と検証に割ける時間が限られる場合があります。

。移行対象のインスタンス数やAuto Scaling構成の有無によって必要な工数は変わってきます。現状の構成を診断したうえで、内製・外注の切り分けを検討することが実務的です。

まとめ：AWS IMDSv2移行で押さえる3つの判断軸

本稿ではAWS IMDSv2移行の仕組みと手順を、AWS公式情報をもとに整理しました。要点は3つに集約できます。第一に、IMDSv2はPUTで取得したトークンをGETに必須とするセッション方式です^*1。AWSは2024年3月25日にアカウント単位の既定化機能を公開しています^*3。第二に、移行は監査・更新・必須化・既定化・強制化の5段階が公式に推奨されており、段階を飛ばすとアプリケーションの停止につながりかねません^*6。第三に、対象インスタンス数やAuto Scaling・コンテナ基盤の有無によって監査・検証の工数は変わり、内製と外注の判断材料になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：AWS「Use the Instance Metadata Service to access instance metadata」（AWS EC2 User Guide）（https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html）
2. *2　出典：AWS News Blog「Amazon EC2 Instance Metadata Service IMDSv2 by default」（2023年11月6日）（https://aws.amazon.com/blogs/aws/amazon-ec2-instance-metadata-service-imdsv2-by-default/）
3. *3　出典：AWS「Set IMDSv2 as default for all new instance launches in your account」（What’s New、2024年3月25日）（https://aws.amazon.com/about-aws/whats-new/2024/03/set-imdsv2-default-new-instance-launches/）
4. *4　出典：AWS Security Blog「Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service」（2019年11月19日）（https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/）
5. *5　出典：AWS「Configure the Instance Metadata Service options」（AWS EC2 User Guide）（https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html）
6. *6　出典：AWS「Transition to using Instance Metadata Service Version 2」（AWS EC2 User Guide）（https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html）

Tweet