Amazon Web Services ブログ
EC2 インスタンスメタデータサービスの拡張により、オープンなファイアウォール、リバースプロキシ、SSRFの脆弱性に対する防御を強化しました
10 年以上前にリリースして以来、Amazon EC2 インスタンスメタデータサービス ( IMDS ) は、安全でスケーラブルなアプリケーションの構築を支援してきました。IMDS は、一時的な認証情報へのアクセスを提供することで、クラウドユーザーにとって大きなセキュリティ上の課題を解決し、手動またはプログラムによってインスタンスに機密認証情報をハードコードしたり、配布したりする必要をなくしました。EC2 インスタンスにアタッチされた IMDS は、特別な「リンクローカル」の IP アドレス 169.254.169.254 で接続され、インスタンスで実行中のソフトウェアだけがアクセスできます。アプリケーションは IMDS にアクセスして、インスタンス、ネットワーク、およびストレージに関するメタデータを利用できます。また、IMDS は、インスタンスにアタッチされている IAM ロール による AWS 認証情報を使用できるようにします。
クラウドでアプリケーションを実行する場合、アプリケーションのセキュリティはインスタンスのセキュリティと同様に重要です。インスタンスで実行されているアプリケーションに脆弱性や設定ミスがあると、重大な問題が生じる可能性があります。アプリケーションセキュリティは多層防御において重要な役割を果たしますが、AWS はインスタンス内であっても、このような状況による被害の可能性を最小限に抑えるために、防御レイヤーを追加する場所をいつも検討しています。
本日、EC2 インスタンスメタデータサービスの v2（ IMDSv2 ）が利用可能になりました。既存のインスタンスメタデータサービス（ IMDSv1 ）は完全にセキュアであり、こちらも引き続きサポートします。しかし、IMDSv2 は、IMDS へのアクセスを試みる可能性がある４種類の脆弱性に対して新しい保護を追加します。この新しい保護は、IAM ロールの制限や、ローカルファイアウォールのルールを使用した IMDS へのアクセス制御など、既存の緩和策とシームレスに連携しますが、これらの緩和策よりも効果的に機能します。また、IMDSv2 をサポートする新しいバージョンの AWS SDK および CLI も利用可能です。
IMDSv2 の新機能
IMDSv2 では、すべてのリクエストがセッション認証によって保護されるようになりました。このセッションは、EC2 インスタンスで実行中のソフトウェアがリクエストするもので、ローカルに保存されている EC2 インスタンスのメタデータと認証情報にアクセスするためのものです。ソフトウェアは、IMDSv2 への単純な HTTP PUT リクエストを使用してセッションを開始します。IMDSv2 は EC2 インスタンスで実行中のソフトウェアにシークレットトークンを返します。次に、シークレットトークンをパスワードとして使用し、IMDSv2 にメタデータと認証情報を要求します。従来のパスワードとは異なり、PUT リクエストでトークンを取得するため、ソフトウェアがトークンを取得することを心配する必要はありません。トークンは IMDSv2 によって格納されることはなく、後続の呼び出しで取得することもできません。そして、トークンを使用するプロセスが終了すると、セッションとそのトークンは破棄されます。１つのセッション内の要求数に制限はなく、IMDSv2 セッション数に制限はありません。セッションは最長 6時間保持することができます。セキュリティを強化するために、セッショントークンは、セッションが開始された EC2 インスタンスからのみ使用できます。
たとえば、次の curl の例は、6 時間（21600 秒）有効なセッショントークンを取得し、そのトークンを使用して EC2 インスタンスのプロファイルメタデータにアクセスします。
IMDSv2 に対して直接操作するコードを記述する必要がある場合は、EC2 ユーザガイド を確認ください。.
変更による影響と防御効果
この IMDSv2 の変更は使いやすく、新しいバージョンの AWS SDK および CLI を使用している場合は、自動的に使用が開始されます。この変更点は、誤って設定された Web アプリケーションファイアウォール( WAF )、リバースプロキシ、対策されていない SSRF 脆弱性、誤って構成されたレイヤ 3 ファイアウォールや NAT 機器を保護する緩和策よりも効果的に機能します。
誤って設定された Web アプリケーションファイアウォールからの保護
AWS WAF などの一部のウェブアプリケーションファイアウォール（ WAF ）サービスは、オープンな WAF として機能するように設定できません。しかし、一部のサードパーティ製 WAF は、攻撃者に EC2 IMDS を含む WAF の背後にあるネットワークへの不正アクセスを許してしまうように誤って設定される可能性があります。
多くの WAF は、アプリケーションを変更したり再設定したりすることなく、Web サイトやアプリケーションを保護できるように設計されています。透過的にするために、WAF は通常、リクエストに付属するすべてのヘッダーを渡し、他のプロキシが追加するような X-Forwarded-For ヘッダーなど、独自のヘッダーを追加しません。つまり、WAF の背後のアプリケーションは、要求者が送信したとおりにリクエストを受信します。
AWS のアプローチは、オープン WAF がほとんどサポートしない HTTP PUT リクエストを使用して、オープンな WAF をブロックすることです。
Amazon S3 などのウェブサービスはオブジェクトストレージに PUT リクエストを使用しますが、ウェブサイトやブラウザでは珍しいタイプのリクエストです。サードパーティの WAF 製品と、誤って設定されたオープンな WAF を調査したところ、大半は HTTP PUT リクエストを許可していないことがわかっています。この PUT リクエストを使用して、よりよい新しい防御層を提供します。セッションの開始時に PUT リクエストを要求するよう IMDSv2 サービスを設計することで、大多数のケースにおいて、オープンな WAF が悪用され IMDS にアクセスするのを防ぐことができます。
誤って設定されたリバースプロキシからの保護
オープンなリバースプロキシが PUT リクエストを許可することも非常にまれですが、IMDSv2 にはオープンなリバースプロキシに対する他の防御層もあります。Apache httpd や Squid などのリバースプロキシも、外部からのリクエストを内部リソースに到達できるよう誤って設定される可能性がありますが、これらのプロキシは通常、X-Forwarded-For HTTP ヘッダーを追加して送信します。このヘッダーは、元の発信者の IP アドレスを渡すために使用されます。IMDSv2 は、X-Forwarded-For ヘッダーを持つ呼び出しにセッショントークンを発行しません。これは、オープンなリバースプロキシのような設定ミスによる不正アクセスをブロックするのに効果的です。
SSRF 脆弱性からの保護
SSRF 脆弱性を悪用すると、攻撃者は Web アプリケーションから不正なリクエストを行うことが可能です。このリクエストはアプリケーション自体から行われるため、アプリケーションはアクセスできるが、外部からはアクセスできないように意図されている内部リソースにアクセスできます。SSRF 脆弱性の重大度は様々で、一部の緩和策では効果がないものもあります。例えば、静的ヘッダーの認証によってインスタンスメタデータへのSSRF をブロックする方法は、攻撃者が URL だけコントロールできる脆弱性の場合にのみ効果的です。しかし、AWS の分析では、攻撃者が任意のヘッダーを設定できる SSRF 脆弱性が多く発見されています。この種の脆弱性は、アプリケーション自身のヘッダー処理に影響を与えることができてしまいます。
IMDSv2 の PUT リクエストによるセッション開始と、別リクエストでシークレットセッショントークンを要求する組み合わせは、静的ヘッダーのみを必要とする緩和策よりも常に厳密で効果的です。AWS による実際の脆弱性の調査により、この組み合わせが大半の SSRF 脆弱性を保護することがわかっています。
誤って設定されたレイヤ３ファイアウォール、NAT 機器からの保護
最後に、IMDSv2 には、オープンなルーター、レイヤー３ファイアウォール、VPN、トンネル、NAT 機器として誤って設定された EC2 インスタンスを保護する最後の防御レイヤーがあります。IMDSv2 のデフォルト設定では、シークレットトークンを含む PUT レスポンスは、インスタンスの外部に移動できません。これは、シークレットトークンを含む IP パケットのデフォルトの Time To Live（ TTL ; 存続可能時間）が「1」に設定されており、一般的な「64」などの値よりもはるかに低くすることで実現されています。 EC2 インスタンスを含むパケットを処理するハードウェアおよびソフトウェアは、パケットが通過するたびに、パケットの TTL フィールドから 1 を引きていきます。TTL が 0 になると、パケットは破棄され、エラーメッセージが送信者に返されます。したがって、TTL が「64」のパケットは、ネットワーク内で 64 の「ホップ」を行うことができ、TTL が「1」のパケットは インスタンスの内部だけ存在することができます。この TTL の機能は、ネットワークにループがある場合に、パケットがループ内で無限に転送されるのを防止するために設計されています。
IMDSv2 では、TTL 値を「1」に設定すると、EC2 インスタンス自体からのリクエストは減算が発生しないので機能することになります。しかし、EC2 インスタンスがオープンなルーター、レイヤー３ファイアウォール、VPN、トンネル、NAT 機器として誤って設定されている場合、トークンを含むレスポンスの TTL はインスタンスを離れる前に０になり、パケットはインスタンスから出る前に破棄され、攻撃者へ転送されません。この情報は EC2 インスタンス自体よりもさらに進むことはありません。つまり、攻撃者が他の防御を乗り越えることに成功していても、トークンの応答を得ることができず、インスタンスメタデータにアクセスできないことを意味します。
移行計画の作成
IMDSv1 と IMDSv2 の両方が利用可能で、デフォルトでは両方が有効になっています。お客様はどちらを使用するかを選択できます。IMDS は v2 のみ有効にすることもでき、IMDS 自体（ v1 および v2 の両方）を完全に無効にすることもできます。AWS では、セキュリティを拡張するために v2 を採用し、v2 のみへのアクセスに制限することをお勧めします。IMDSv1 は、v1 を使用するツールとスクリプトをお持ちのお客様や、インスタンスの今のセキュリティに満足しているお客様のために引き続き利用可能です。
v2 への移行と v1 の無効化をシームレスに行うためのツールが数多く用意されています。本日より、インスタンスで行われている v1 呼び出しの数を可視化できる新しい CloudWatch メトリクス が利用可能になりました。お客様は、このメトリクスを使用して、Amazon マシンイメージ、AWS SDK、CLI、cloud-init、および IMDS にアクセスするその他のソフトウェアの更新、リリース、アップグレードなど、v1 のアクセス頻度をモニタリングできます。インスタンスの起動、アクティブ化、サービス利用で、メトリックスが０であることが確認できたら、IMDSv2 への安全な移行と、v1 の無効化ができます。IMDSv2 への移行の詳細についてはユーザガイドを参照してください。
この移行中は、さらにセキュリティを強化することもできます。IMDS によって提供される AWS 認証情報に ec2:RoleDelivery コンテキストキーが含まれるようになりました。IMDSv1 によって提供される認証情報は ec2:RoleDelivery の値が「1.0」で、新しいスキームを使用する認証情報は値が「2.0」になります。これらのコンテキストキーを IAM ポリシー、リソースポリシー、または AWS Organizations Service Control Policy ( SCP )の条件として使用することで、新しいスキームの使用を、サービス単位またはリソース単位で容易に適用できます。たとえば、S3 バケットにアクセスするすべてのソフトウェアが IMDSv2 を使用するようにアップグレードした場合、その S3 バケットは、コンテキストキーに「2.0」以上の値を持つロールアカウント認証情報のアクセスのみを許可するように安全に制限できます。これにより、IMDSv1 を使用して取得した認証情報はバケットにアクセスできなくなります。AWS CloudTrail も更新され、この新しい ec2:RoleDelivery パラメータが記録されるようになっています。
re:Invent での IMDSv2 関連のセッション
12月の AWS re: Invent で IMDSv2 と移行方法について、Mark Ryland が詳しく解説します。re: Invent カタログの SEC310 を参照してください。
AWS セキュリティのニュースは Twitter でもお届けしています。
原文のブログはこちらです。翻訳は SA 桐谷 が担当しました。