クラウド（AWS、Azure、GCP）メタデータがHTTPS経由で提供されないのはなぜですか？

Question

サーバー上のアプリケーションやユーザーが、このような安全でないURLを入力して、そのインスタンスに関するサーバー情報を取得できるのはなぜですか？

途中の攻撃者が、潜在的に重要で価値の高いデータを傍受できるようにしないのですか？

LTPCGO · Accepted Answer

注意すべき最初の点は、上記のアドレスのいずれかをクリックすると、それを開くことができないはずです。それらはすべて（Azureの場合は明らかに）リンクローカルIPアドレスを指します。これらは、スペース内の予約済みアドレス169.254.0.0/16ルーターによって転送されず、決定的に特定のインスタンスからのみアクセス可能です。

注意すべき2番目のポイントは、URLに含まれるデータです。ユーザーデータはこれらのAPIを介して保存できますただし、暗号化メソッドによって保護されていないため、保存しないでください。 Identity and Access Management（IAM）データも保存でき、これはその強みの1つです。ちょっと待って！これは、アクセス権を持つユーザーが、本来はすべきでないことを実行できるようにするデータを見ることができるという意味ではありませんか？はい、そうです。ただし、そのデータは比較的短い時間フレーム（デフォルトでは約1時間）でローテーションされるため、公開は制限され、データはオンデマンドでローテーションできます。

なぜURLが暗号化されていないのかという質問については？はい、ローカルネットワークインターフェイスでホストされている場合でも、ネットワーク通信は行われています。ただし、インスタンスからのみアクセス可能であり、ネットワークパケットを盗聴しようとする攻撃者はルートアクセスを必要とするため（少なくとも通常のシナリオでは）、ルート以外のユーザーによって傍受されることはありません。あなたのマシンでは、資格情報にどのようなデータが保存されているかは問題ではありません！メタデータサーバーがどのように呼び出されるかを正確に判断するのは難しいですが、データは仮想マシンの物理ホストによって単に格納され、認証は物理ホストによって行われ、要求した仮想マシンに対応する情報を返すだけです。から来た。その意味で、リクエストはインスタンスを離れますが、物理ホストが危険にさらされない限り、ネットワークを経由して傍受されることはありません。この時点でも、システムは危険にさらされています。 AWSやAzureには具体的な詳細はないようですが、 Googleはこの論理的な前提をバックアップしているようです：

メタデータサーバーから情報を取得するリクエストを行うと、リクエストとそれに続くメタデータレスポンスが、仮想マシンインスタンスを実行している物理ホストを離れることはありません。

ただし、それだけでは十分に説明できません。実際の答えはspeedです。追加のハンドシェイクには時間がかかりますが、データを暗号化する必要がない場合は、なぜそれを行うのですか？ここでそれを保護することは、追加の保護を提供せず、APIへの多くのリクエストを遅らせるのに役立ちます。

では、安全でないモデルでこれらのURLを介してIAM認証情報が取得されることはそれほど心配しないのはなぜですか。答えは、最小特権と徹底的な防御という2つの原則にあります。まず、割り当てられたインスタンスに割り当てられたIAMロールは、非常に限られた機能を提供する必要があります。理想的には、新しいデータやインターフェースを作成または作成する機能はありません。次に、アプリケーションを構築してメタデータへのリクエストを防ぐことができます。何らかの方法で攻撃者がメタデータを管理した場合、localhost以外のサーバーからのリクエストを許可しない、特定の外部の資格情報でリクエストが行われたときにアラームを設定するなど、他の防御メカニズムを使用できます。期間。

メタデータサーバーを利用する理由として有用なケースとして：データベースの読み取りまたは書き込みを行うには、通常、資格情報をサーバー上のどこかに保存する必要があります。通常、固定ファイルまたはパブリックビューのメモリに保存されます。ただし、IAMロールをインスタンスに割り当てて、アプリケーションがこれらの資格情報を保存せずに「オンザフライ」でフェッチできるようにすることができます。また、資格情報が頻繁にローテーションされた後にそれらを読み取ることができるため、そうでない場合は自動化できます非常に退屈な管理作業になります。