「混乱した代理」問題 - AWS Identity and Access Management

「混乱した代理」問題

前の例を続けるには、Example Corp はお客様の AWS アカウントの特定のリソースにアクセスする必要があります。しかし、Example Corp にはお客様以外にも顧客がいるため、それぞれの顧客の AWS リソースに別々にアクセスする方法が必要です。Example Corp は、共有されてはならない秘密である顧客の AWS アカウントのアクセスキーを顧客にリクエストする代わりに、それぞれの顧客にロールの ARN をリクエストします。しかし、Example Corp の別の顧客は、お客様のロールの ARN を推測または取得できる可能性があります。次に、この顧客はロールの ARN を使用し、Example Corp を介して AWS リソースにアクセスできます。このようなアクセス許可のエスカレーションは「混乱した代理」問題と呼ばれます。

次の図は、"混乱した代理" 問題を示しています。


            「混乱した代理」問題の説明

このシナリオでは、次のことを前提としています。

  • AWS1 はお客様の AWS アカウント ID です。

  • AWS1:ExampleRole は、お客様のアカウントのロールである。このロールの信頼ポリシーは、Example Corp の AWS アカウントを、ロールを引き受けることができるアカウントとして指定することによって、Example Corp を信頼しています。

次の状況が発生します。

  1. お客様は、Example Corp のサービスの使用を開始するとき、AWS1:ExampleRole の ARN を Example Corp に提供します。

  2. Example Corp はそのロールの ARN を使用して、お客様の AWS アカウントのリソースにアクセスするために必要な一時的なセキュリティ認証情報を入手します。この方法では、お客様に代わって操作を実行できる "代理" として Example Corp を信頼します。

  3. 別の AWS ユーザーも Example Corp のサービスを利用し始め、このユーザーも AWS1:ExampleRole の ARN を Example Corp が使用できるように提供するとします。この別のユーザーは、秘密ではない AWS1:ExampleRole を知った、または推測した可能性があります。

  4. その別のユーザーが Example Corp に自分のアカウントの AWS リソース (そう自称しているリソース) へのアクセスを依頼すると、Example Corp は AWS1:ExampleRole を使用してお客様のアカウントのリソースにアクセスします。

このようにして、その別のユーザーはお客様のリソースに不正にアクセスできます。Example Corp は、この別のユーザーによって操られ、無意識にお客様のリソースにアクセスしたため、"混乱した代理" になります。

外部 ID が「混乱した代理」問題を防止する方法

"混乱した代理" 問題には、ロールの信頼ポリシーに ExternalId の条件の確認を含めることで対応します。"代理" 会社が顧客ごとに固有の外部 ID 値を AWS 認証情報のリクエストに挿入します。外部 ID は、Example Corp の顧客の間で一意であることが必要な顧客 ID 値であり、Example Corp の顧客の管理対象外です。そのため、外部 ID は Example Corp から取得するものであり、自分では用意できません。これにより、ある顧客が別の顧客になりすますのを防止できます。Example Corp は常に、顧客に割り当てた外部 ID をリクエストに挿入するため、Example Corp からのリクエストにお客様のもの以外の外部 ID が含まれることはありません。

このシナリオでは、Example Corp がお客様に割り当てた一意の ID は "12345" であり、別の顧客の ID は "67890" とします。これらの ID は、このシナリオで使用することのみを目的としているため、簡略化されています。通常、これらの ID は GUID です。これらの ID が Example Corp の顧客の間で一意であることを考慮すると、これらの値を外部 ID として使用することは賢明です。

Example Corp はお客様に "12345" という外部 ID 値を提供したとします。お客様は、Condition 値が 12345 であることを必須とする以下のような sts:ExternalId 要素をロールの信頼ポリシーに追加する必要があります。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": {"AWS": "Example Corp's AWS Account ID"}, "Condition": {"StringEquals": {"sts:ExternalId": "12345"}} } }

このポリシーの Condition 要素に基づいて、AssumeRole API 呼び出しに "12345" という外部 ID 値が含まれている場合にのみ Example Corp はロールを引き受けることができます。Example Corp は、顧客に代わってロールを引き受けるたびに、その顧客の外部 ID 値を AssumeRole 呼び出しに含めます。別の顧客がお客様の ARN を Example Corp に提供した場合でも、Example Corp が AWS へのリクエストに含める外部 ID を顧客がコントロールすることはできません。これにより、権限のない顧客がお客様のリソースにアクセスすることを防止できます。

次の図は、このプロセスを示したものです。


                「混乱した代理」問題を解消する方法
  1. 前述と同様に、お客様は、Example Corp のサービスを利用し始めるとき、AWS1:ExampleRole の ARN を Example Corp に提供します。

  2. Example Corp がそのロールの ARN を使用して AWS1:ExampleRole ロールを引き受けるとき、Example Corp は AssumeRole API コールにお客様の外部 ID (「12345」) を含めます。この外部 ID はロールの信頼ポリシーと一致するため、AssumeRole API 呼び出しは正常に実行され、Example Corp はお客様の AWS アカウントのリソースにアクセスするための一時的なセキュリティ認証情報を取得します。

  3. 別の AWS ユーザーも Example Corp のサービスを利用し始め、先ほどと同様、このユーザーも AWS1:ExampleRole の ARN を Example Corp が使用できるように提供するとします。

  4. しかし、今回は、Example Corp が AWS1:ExampleRole ロールを引き受けるとき、別の顧客に関連付けられている外部 ID (「67890」) を提供します。その別の顧客がこの ID を変更することはできません。Example Corp がこれを行うのは、ロールを使用するリクエストが別の顧客から発生しており、"67890" は Example Corp が業務を遂行する環境を示すからです。お客様は自身の外部 ID (「12345」) を使用する条件を AWS1:ExampleRole の信頼ポリシーに追加したため、AssumeRole API コールは失敗します。別の顧客がお客様のアカウントのリソースに不正にアクセスすることが防止されます (図の赤色の「X」で示しています)。

外部 ID により、Example Corp が別の顧客によって操られ、無意識にお客様のリソースにアクセスすることを防止でき、"混乱した代理" 問題が解消されます。