セキュリティ

EC2 のメタデータ 169.254.169.254 の正体 - リンクローカルアドレスと IMDSv2 の設計

EC2 インスタンスメタデータサービスのエンドポイント 169.254.169.254 がリンクローカルアドレスである理由、SSRF 攻撃で悪用された歴史、IMDSv2 のトークンベース認証が生まれた経緯を解説します。

約 3 分で読めます

169.254.169.254 はどこにあるのか

EC2 インスタンスの内部から http://169.254.169.254/latest/meta-data/ にアクセスすると、インスタンス ID、AMI ID、IAM ロールの一時認証情報、ネットワーク設定など、インスタンスに関するメタデータが返されます。この 169.254.169.254 というアドレスは、インターネット上のサーバーではなく、Nitro System のハイパーバイザーが提供するローカルサービスです。169.254.0.0/16 は RFC 3927 で定義されたリンクローカルアドレスで、ルーターを越えて転送されない特殊なアドレス範囲です。つまり、このアドレスへのリクエストはインスタンスの外に出ることなく、ハイパーバイザーが直接応答します。この設計により、メタデータサービスはネットワーク障害の影響を受けず、VPC のルーティング設定にも依存しません。インスタンスが起動した瞬間から、ネットワーク設定が完了する前でも、メタデータサービスにアクセスできます。cloud-init がインスタンスの初期設定を行う際に、最初にメタデータサービスからユーザーデータやネットワーク設定を取得するのは、この信頼性の高さがあるからです。

Capital One 事件 - SSRF でメタデータが漏洩した日

2019 年 7 月、Capital One (米国の大手銀行) で約 1 億人の個人情報が漏洩する事件が発生しました。攻撃者は、Capital One の Web アプリケーションに存在した SSRF (Server-Side Request Forgery) 脆弱性を悪用し、EC2 インスタンスのメタデータサービスから IAM ロールの一時認証情報を取得しました。SSRF は、サーバーサイドのアプリケーションに任意の URL へのリクエストを実行させる攻撃です。攻撃者は Web アプリケーションに http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name というリクエストを送信させ、IAM ロールのアクセスキー、シークレットキー、セッショントークンを取得しました。この認証情報を使って S3 バケットにアクセスし、大量の個人情報をダウンロードしました。この事件は、IMDSv1 (Instance Metadata Service Version 1) の設計上の弱点を浮き彫りにしました。IMDSv1 は単純な HTTP GET リクエストでメタデータを返すため、SSRF 攻撃で容易にアクセスできてしまいます。

IMDSv2 - トークンベース認証による防御

Capital One 事件を受けて、AWS は 2019 年 11 月に IMDSv2 (Instance Metadata Service Version 2) をリリースしました。IMDSv2 は、メタデータへのアクセスにセッショントークンを要求するトークンベースの認証方式です。IMDSv2 でメタデータを取得するには、まず PUT リクエストでセッショントークンを取得し、そのトークンを HTTP ヘッダーに含めて GET リクエストを送信する必要があります。この 2 ステップの認証が SSRF 攻撃を防ぐ理由は、ほとんどの SSRF 脆弱性が GET リクエストしか実行できないためです。PUT リクエストを実行できる SSRF 脆弱性は稀であり、さらにレスポンスヘッダーからトークンを抽出して次のリクエストに含めるという複雑な操作が必要です。加えて、IMDSv2 のトークン取得リクエストには X-aws-ec2-metadata-token-ttl-seconds ヘッダーが必須で、IP フォワーディングされたリクエスト (TTL が 1 に設定されるため、ネットワークホップを越えられない) もブロックされます。2024 年以降、AWS は新規インスタンスのデフォルトを IMDSv2 のみに変更しており、IMDSv1 を無効化することを強く推奨しています。

メタデータで取得できる情報の全体像

メタデータサービスから取得できる情報は多岐にわたります。インスタンスの基本情報 (instance-id、instance-type、ami-id、hostname)、ネットワーク情報 (local-ipv4、public-ipv4、mac、network/interfaces)、IAM ロールの一時認証情報 (iam/security-credentials/role-name)、ユーザーデータ (user-data)、ブロックデバイスマッピング (block-device-mapping) などです。特に重要なのは IAM ロールの一時認証情報です。EC2 インスタンスに IAM ロールをアタッチすると、メタデータサービスから一時的なアクセスキー、シークレットキー、セッショントークンが取得できます。AWS SDK はこの仕組みを内部で自動的に使用しており、開発者がアクセスキーをコードにハードコードする必要がありません。一時認証情報は自動的にローテーションされ、有効期限は通常 6 時間です。メタデータサービスにはインスタンスのユーザーデータも含まれます。ユーザーデータはインスタンス起動時に指定するスクリプトやデータで、cloud-init が初期設定に使用します。ユーザーデータにパスワードやシークレットを含めるのは危険です。メタデータサービス経由で誰でも読み取れるためです。

メタデータサービスのセキュリティ強化策

IMDSv2 の有効化に加えて、メタデータサービスのセキュリティを強化する方法がいくつかあります。第 1 に、HttpPutResponseHopLimit を 1 に設定することです。これにより、コンテナ内からのメタデータアクセスがブロックされます。ECS や Docker コンテナ内のアプリケーションがメタデータサービスにアクセスする必要がない場合、ホップ制限を 1 にすることで、コンテナからの SSRF 攻撃を防げます。第 2 に、メタデータサービス自体を無効化することです。HttpEndpoint を disabled に設定すれば、メタデータサービスへのアクセスが完全にブロックされます。IAM ロールの認証情報が不要なインスタンス (固定の認証情報を使用する場合) では、メタデータサービスを無効化するのが最も安全です。第 3 に、IAM ロールの権限を最小限にすることです。メタデータサービスから認証情報が漏洩しても、そのロールの権限が最小限であれば被害を限定できます。Capital One 事件では、漏洩したロールが S3 バケットへの広範なアクセス権限を持っていたことが被害を拡大させました。EC2 のセキュリティ設計を体系的に学ぶには、専門書籍 (Amazon)が参考になります。

関連するサービス

Amazon EC2クラウド上で仮想サーバーを提供するコンピュートサービスAWS IAMAWS リソースへのアクセスを安全に管理するための認証・認可サービス

関連する記事

AWS アカウント ID の 12 桁に隠された構造 - なぜ 12 桁なのか、何が読み取れるのかAWS アカウント ID が 12 桁の数字である理由、ARN の構造に埋め込まれた設計意図、アカウント ID から推測できる情報とセキュリティ上の注意点を雑学的に解説します。IAM ポリシーの評価ロジック完全解説 - 暗黙の Deny が明示的な Allow に勝つ仕組みIAM がリクエストを許可・拒否する際の評価フローを、暗黙の Deny、明示的な Allow、明示的な Deny の優先順位、SCP・パーミッションバウンダリー・セッションポリシーの交差判定まで段階的に解説します。Amazon EC2 インスタンスの選び方 - インスタンスファミリーと購入オプションの最適化インスタンスファミリーの特徴と Graviton プロセッサの性能優位性を整理し、オンデマンド・リザーブド・スポットの購入オプションを使い分ける指針を紹介します。

同じテーマの記事

IAM Access Analyzer で検出する過剰なアクセス権限 - 外部アクセスと未使用権限の分析IAM ロールの未使用権限を CloudTrail ベースで検出し、最小権限ポリシーを自動生成する。外部アクセスの検出と CI/CD へのカスタムポリシーチェック組み込みまでを解説します。AWS Certificate Manager で自動化する SSL/TLS 証明書管理 - 発行からローテーションまでACM によるパブリック証明書の無料発行、DNS 検証、自動更新、ALB ・ CloudFront へのデプロイを解説します。AWS Artifact でコンプライアンスレポートを取得 - 監査対応と契約管理SOC・PCI DSS・ISO の監査レポートをオンデマンドで取得し、BAA や GDPR DPA を Organizations 全体に一括適用する手順を紹介します。監査の自動化 - AWS Audit Manager でコンプライアンス証跡を継続的に収集するAWS Audit Manager を使った監査証跡の自動収集を解説。フレームワーク (SOC 2、PCI DSS、GDPR 等) に基づく自動評価、エビデンスの一元管理、監査レポートの生成を紹介します。AWS アカウント ID の 12 桁に隠された構造 - なぜ 12 桁なのか、何が読み取れるのかAWS アカウント ID が 12 桁の数字である理由、ARN の構造に埋め込まれた設計意図、アカウント ID から推測できる情報とセキュリティ上の注意点を雑学的に解説します。AWS アカウントのルートユーザーはなぜ危険なのか - 権限分離の設計思想と封印の実践AWS ルートユーザーが IAM では制限できない特権を持つ理由、ルートユーザーでしかできない操作の一覧、MFA の設定方法、Organizations のルートアクセス管理による封印戦略を解説します。証明書管理と HTTPS 化 - AWS Certificate Manager による TLS 証明書の自動運用AWS Certificate Manager (ACM) を使った TLS/SSL 証明書の発行・自動更新・デプロイを解説。CloudFront ・ ALB ・ API Gateway との統合、DNS 検証、プライベート CA の活用まで紹介します。AWS CloudHSM で実現する専用鍵管理 - FIPS 140-2 Level 3 準拠の暗号化専有の HSM インスタンスで FIPS 140-2 Level 3 準拠の鍵管理を実現する。KMS との使い分けと、KMS カスタムキーストアによる両者の統合を紹介します。

内容が近い記事・サービス

AWS アカウント ID の 12 桁に隠された構造 - なぜ 12 桁なのか、何が読み取れるのかAWS アカウント ID が 12 桁の数字である理由、ARN の構造に埋め込まれた設計意図、アカウント ID から推測できる情報とセキュリティ上の注意点を雑学的に解説します。AWS IAMAWS リソースへのアクセスを安全に制御するための認証・認可サービスで、ユーザー、グループ、ロール、ポリシーによるきめ細かなアクセス管理を提供するS3 のリクエスト課金はなぜ GET と PUT で料金が違うのか - ストレージ I/O の経済学S3 の GET リクエストが PUT の 10 分の 1 の料金である理由を、書き込みの内部コスト、イレイジャーコーディング、整合性保証の仕組みから解説し、リクエスト料金を最適化する実践的なテクニックを紹介します。ユーザー認証の実装 - Cognito によるセキュアな認証基盤の構築Amazon Cognito を活用したユーザー認証基盤の設計と実装を解説し、ユーザープール、ID プール、外部 ID プロバイダー連携による認証フローの構築方法を紹介します。Amazon Cognito で実装するユーザー認証 - User Pool と Identity Pool の設計Cognito User Pool によるユーザー認証、Identity Pool による AWS リソースアクセス、ソーシャルログインの統合を解説します。