第三者が所有する AWS アカウント へのアクセス - AWS Identity and Access Management

第三者が所有する AWS アカウント へのアクセス

組織内の AWS リソースへ組織外の第三者がアクセスする必要がある場合には、ロールを使用することでアクセス許可を委任することができます。たとえば、組織内の AWS リソースの管理を第三者へ委託しているような場合が相当します。IAM ロールを使用することで、AWS セキュリティ認証情報を共有することなく第三者に AWS リソースへのアクセスを許可することができます。第三者は代わりに、AWS アカウント に作成したロールを引き受けることで、AWS リソースにアクセスできます。信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「IAM Access Analyzer とは」を参照してください。

第三者は、以下の情報を提供する必要があります。これらの情報は、第三者が引き受けることのできるロールの作成に必要です。

  • 第三者の AWS アカウント ID。ロールの信頼ポリシーを定義するときは、その AWS アカウント ID をプリンシパルとして指定します。

  • ロールを一意に関連付けるための外部 ID。外部 ID は、ユーザーと第三者によってのみ識別される識別子です。たとえば、ユーザーとサードパーティーの間の請求書 ID は使用できますが、サードパーティーの名前や電話番号などの推測できるものは使用しないでください。ロールの信頼ポリシーを定義するときは、この ID を指定する必要があります。サードパーティーは、ロールを引き受けるときに、この ID を指定する必要があります。

  • 第三者が AWS リソースでの作業を行うのに必要なアクセス許可。ロールのアクセス許可ポリシーを定義する際に、権限を指定する必要があります。このポリシーには、第三者はどのアクションができるのか、およびどのリソースにアクセスできるのかが定義されています。

ロールの作成が完了したら、そのロールの Amazon リソースネーム(ARN)を対象の第三者に提供します。第三者がロールを担当するにあたり、このロールの ARN を必要とします。

重要

お客様の AWS リソースへのアクセスを第三者に許可すると、第三者はポリシーで指定したすべてのリソースにアクセスできます。サードパーティーによるリソースの使用は、ユーザーに請求されます。したがって、第三者によるリソースの使用については適切な制限を設けるようにしてください。

第三者によるアクセスのための外部 ID

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

重要

AWS は、外部 ID を機密情報として扱いません。アクセスキーペアやパスワードなどの機密情報を AWS で作成した場合、それらを再び表示することはできません。ロールの外部 ID は、ロールを表示する権限を持つすべてのユーザーが表示できます。

外部 ID が適している状況

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

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

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

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

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

外部 ID を使用したシナリオの例

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

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

IAM ロールを使用して AWS アカウント と Example Corp アカウントと間の信頼関係を確立できます。この関係が確立されると、Example Corp アカウントのメンバーは、AWS Security Token Service AssumeRole API を呼び出して、一時的セキュリティ認証情報を取得できます。次に、Example Corp のメンバーは、この認証情報を使用してアカウントの AWS リソースにアクセスできます。

注記

一時的セキュリティ認証情報を取得するために呼び出すことのできる AssumeRole とその他の AWS API オペレーションの詳細については、「AWS STS 認証情報を比較する」を参照してください。

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

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

    注記

    Example Corp は、顧客ごとに一意である限り、任意の文字列値を ExternalId に使用できます。顧客のアカウント番号を使用することもできますし、ランダムな文字列でもかまいません。ただし、2 つの顧客に同じ値を使用することはできません。「シークレット」することを意図したものではありません。Example Corp は、顧客ごとに ExternalId 値を指定する必要があります。重要なのは、各外部IDがユニークであることを確認するために、お客様によってではなく、Example Corp によって生成される必要があるということです。

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

    "Principal": {"AWS": "Example Corp's AWS アカウント 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 パラメータが含まれています。

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

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

外部 ID の重要なポイント

  • 異なる AWS で複数の顧客をサポートするマルチテナント環境では、AWS アカウント アカウントごとに 1 つの外部 ID を使用することをお勧めします。この ID は、サードパーティーによって生成されたランダムな文字列である必要があります。

  • ロールを引き受けるときにサードパーティーが外部 ID を提供することを要求するには、ロールの信頼ポリシーを選択した外部 ID で更新します。

  • ロールを引き受けるときに外部 ID を提供するには、AWS CLI または AWS API を使用してそのロールを引き受けます。詳細については、「STS AssumeRole API オペレーション」または「STS assume-role CLI オペレーション」を参照してください。

追加リソース

第三者が所有する AWS アカウントへのアクセスを提供する方法について詳しく知りたい場合は、以下のリソースを参考にすると便利です。