メニュー
AWS Identity and Access Management
ユーザーガイド

AWS リソースへのアクセス権を第三者に付与するときに外部 ID を使用する方法

お客様の AWS リソースへのアクセス権を第三者に付与(委任)することが必要になる場合があります。このシナリオで重要になるのが外部 ID です。この ID は、IAM ロールの信頼ポリシーでロールを引き受けることができるユーザーの指定に使用できるオプションの情報です。

たとえば、Example Corp という第三者企業を雇って、コストを最適化するためにお客様の AWS アカウントをモニタリングする業務を依頼するとします。Example Corp がお客様の毎日の支出を追跡するには、お客様の AWS リソースにアクセスする必要があります。また、Example Corp は他の顧客について他の多くの AWS アカウントを監視しています。

Example Corp にお客様の AWS アカウントの IAM ユーザーへのアクセス権とその長期的な認証情報を提供することは可能ですが、代わりに、強く推奨されるベストプラクティスとして、IAM ロールを使用することにします。IAM ロールは、第三者が長期的な認証情報(IAM ユーザーのアクセスキーなど)を共有することなくお客様の AWS リソースにアクセスできるようにするメカニズムです。

IAM ロールを使用して、お客様の AWS アカウントと Example Corp に属するアカウントとの間の信頼関係を確立できます。この関係が確立された後、信頼される AWS アカウントの Example Corp のいずれかの IAM ユーザーまたはアプリケーションは、AWS STS の AssumeRole API を呼び出して、一時的なセキュリティ証明書を取得して、後でお客様のアカウントの AWS リソースへのアクセスに使用できます。

注記

一時的なセキュリティ認証情報を取得するために呼び出すことのできる AssumeRole とその他の AWS API の詳細については、「一時的なセキュリティ認証情報のリクエスト」を参照してください。

このシナリオの詳細は以下のとおりです。

  1. お客様は Example Corp を雇うとします。Example Corp はお客様の一意の顧客 ID を作成します。Example Corp はその一意の顧客 ID と Example Corp の AWS アカウント番号をお客様に提供します。この情報は次の手順でお客様が IAM ロールを作成するために必要になります。

    注記

    Example Corp は、顧客ごとに一意である限り、任意の文字列値を ExternalId に使用できます。顧客のアカウント番号を使用することもできますし、ランダムな文字列でもかまいません。ただし、2 つの顧客に同じ値を使用することはできません。「シークレット」することを意図したものではありません。Example Corp は、顧客ごとに ExternalId 値を指定する必要があります。キーは、顧客ではなく、Example Corp が生成したものでなければなりません。

  2. お客様は AWS にサインインし、お客様のリソースへのアクセス権を Example Corp に付与する IAM ロールを作成します。他の IAM ロールと同様に、このロールにも 2 つのポリシー(アクセスポリシーと信頼ポリシー)があります。ロールの信頼ポリシーでは、だれがこのロールを引き受けることができるかを指定します。このサンプルシナリオでは、ポリシーで Principal として Example Corp の AWS アカウント番号を指定します。これにより、そのアカウントの ID はロールを引き受けることができるようになります。さらに、信頼ポリシーに Condition 要素を追加し、Example Corp を雇ったときにお客様に割り当てられた一意の顧客 ID と ExternalID コンテキストキーが一致することをこの要素でテストして確認します。以下に例を示します。

    Copy
    "Principal": {"AWS": "Example Corp's AWS Account ID"}, "Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
  3. ロールのアクセスポリシーでは、ロールがだれに何を許可するかを指定します。たとえば、お客様の Amazon EC2 と Amazon RDS のリソースのみを管理でき、お客様の IAM ユーザーまたはグループは管理できないようにロールを指定できます。サンプルシナリオでは、アクセスポリシーを使用して、お客様のアカウントのすべてのリソースに対する読み取り専用アクセス権を Example Corp に付与します。

  4. ロールの作成が完了したら、そのロールの Amazon リソースネーム(ARN)を Example Corp に提供します。

  5. Example Corp がお客様の AWS リソースへのアクセス権を必要とするとき、Example Corp の担当者が AWS の sts:AssumeRole API を呼び出します。この呼び出しには、引き受けるロールの ARN とお客様の顧客 ID に対応する ExternalID パラメータが含まれています。

これらすべてによって、リクエストはロールの ARN と外部 ID が正しく、Example Corp の AWS アカウントを使用している担当者がリクエスト元である場合にのみ承認されます。リクエストが承認されると、一時的なセキュリティ認証情報が提供されます。Example Corp はその情報を使用して、お客様のロールが許可している AWS リソースにアクセスできます。

つまり、ロールのポリシーに外部 ID が含まれている場合、そのロールを引き受けるユーザーは、ロールでプリンシパルとして指定されているだけではなく、正しい外部 ID を指定する必要があります。

外部 ID の使用が必要な理由

抽象的には、外部 ID により、ロールを引き受けるユーザーは、業務を遂行する環境へのアクセスを要求できます。また、アカウント所有者が、特定の環境においてのみロールを引き受けることができるようにする方法の 1 つでもあります。外部 ID の最も重要な機能は、"混乱した代理" 問題の防止と対処です。

"混乱した代理" 問題

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

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

 "混乱した代理" 問題の説明。

この図は、以下を前提としています。

  • AWS1 は、お客様の AWS アカウントである。

  • 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 値を提供したとします。お客様は、sts:ExternalID 値が 12345 であることを必須とする以下のような Condition 要素をロールの信頼ポリシーに追加する必要があります。

Copy
{ "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 が別の顧客によって操られ、無意識にお客様のリソースにアクセスすることを防止でき、"混乱した代理" 問題が解消されます。

外部 ID を使用する必要性

外部 ID は以下の状況で使用します。

  • お客様が AWS アカウントを所有しており、それ以外の AWS アカウントにアクセスするロールを第三者のために設定した場合、第三者がお客様のロールを引き受けるときに含める外部 ID を第三者にリクエストする必要があります。その後、ロールの信頼ポリシーでその外部 ID の可否を調べて、外部の第三者がお客様に代わって操作を行う場合にのみ、お客様のロールを引き受けることができるようにします。

  • 前のシナリオの Example Corp のように、さまざまな顧客に代わってロールを引き受ける立場にある場合は、お客様が一意の外部 ID をそれぞれの顧客に割り当て、顧客のロールの信頼ポリシーに外部 ID を追加するように依頼する必要があります。ロールを引き受けるには、リクエストに正しい外部 ID が常に含まれていることを確認する必要があります。

    既にそれぞれの顧客に一意の ID を割り当てている場合は、この一意の ID を外部 ID として使用できます。外部 ID は、この目的のためだけに明示的に作成したり個別に追跡したりする必要のある特別な値ではありません。

    外部 ID は常に AssumeRole API 呼び出しで指定する必要があります。さらに、顧客からロールの ARN を受け取ったら、正しい外部 ID と正しくない外部 ID の両方を使用して、そのロールを引き受けることができるかどうかをテストします。正しくない外部 ID でロールを引き受けることができた場合は、顧客が正しい外部 ID を要求するようにロールの信頼ポリシーを更新するまで、顧客のロールの ARN をお客様のシステムに格納しないでください。こうすることにより、顧客による不正を防止し、"混乱した代理" 問題からお客様と顧客の両方を守ることができます。