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

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

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

重要

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

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

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

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

例えば、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 オペレーションの詳細については、「一時的なセキュリティ認証情報のリクエスト」を参照してください。

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

  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 を使用する理由

抽象的には、外部 ID により、ロールを引き受けるユーザーは、業務を遂行する環境へのアクセスを要求できます。また、アカウント所有者が、特定の環境においてのみロールを引き受けることができるようにする方法の 1 つでもあります。外部 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 を要求するまで待ちます。こうすることにより、顧客による不正を防止し、"混乱した代理" 問題からお客様と顧客の両方を守ることができます。