混乱する代理問題

混乱した代理問題は、アクションを実行するためのアクセス許可を持たないエンティティが、より特権のあるエンティティにアクションの実行を強制できてしまう場合に生じる、セキュリティ上の問題です。これを防ぐために、サードパーティー (クロスアカウント) や 他の AWS サービス (クロスサービス)に対して、お客様のアカウント内のリソースへのアクセス権を提供してしまった場合に、お客様のアカウントの保護に役立つツールを AWS が提供します。

お客様の AWS リソースへのアクセス権をサードパーティーに付与 (委任) することが必要になる場合があります。例えば、Example Corp という第三者企業を雇って、コストを最適化するためにお客様の AWS アカウント をモニタリングする業務を依頼するとします。Example Corp がお客様の毎日の支出を追跡するには、お客様の AWS リソースにアクセスする必要があります。また、Example Corp は他の顧客について他の多くの AWS アカウント をモニタリングしています。IAM ロールを使用して AWS アカウント と Example Corp アカウントと間の信頼関係を確立できます。このシナリオで重要なのは、オプションの情報としての外部 ID です。この ID を IAM ロールの信頼ポリシーで使用することで、ロールを引き受けることができるユーザーを指定できます。外部 ID の最も重要な機能は、混乱した代理問題の防止と対処です。

AWS では、サービス間でのなりすましが、混乱した代理問題を生じさせる可能性があります。サービス間でのなりすましは、1 つのサービス (呼び出し元サービス) が、別のサービス (呼び出し対象サービス) を呼び出すときに発生する可能性があります。呼び出し元サービスは、本来ならアクセスすることが許可されるべきではない方法でその許可を使用して、別のお客様のリソースに対する処理を実行するように操作される場合があります。

クロスアカウントでの混乱した代理

次の図は、クロスアカウントでの「混乱した代理」問題を示しています。

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

次の状況が発生します。

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

Example Corp は、ロールの信頼ポリシーに ExternalId の条件の確認を含めることを必須とすることで、「混乱した代理」問題に対応できます。Example Corp は、顧客ごとに一意の ExternalId 値を生成して、ロールを引き受けるリクエストでその値を使用します。ExternalId 値は、Example Corp の顧客の間で一意でなければならず、Example Corp の顧客ではなく、Example Corp によって管理されます。そのため、外部 ID は Example Corp から取得するものであり、自分では用意できません。これにより、Example Corp が混乱した代理人になることを防ぎ、別のアカウントの AWS リソースへのアクセスを許可してしまうことを防ぎます。

このシナリオでは、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",
    "Principal": {
      "AWS": "Example Corp's AWS Account ID"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "12345"
      }
    }
  }
}

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

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

外部 ID により、Example Corp が他の顧客によって操られ、無意識にお客様のリソースにアクセスすることを防止します。

サービス間の混乱した代理の防止

リソースベースのポリシー内では aws:SourceArn、aws:SourceAccount、aws:SourceOrgID、または aws:SourceOrgPaths のグローバル条件コンテキストキーを使用して、サービスが持つ特定のリソースへのアクセス許可を制限することをお勧めします。1 つのリソースだけをクロスサービスのアクセスに関連付ける場合は、aws:SourceArn を使用します。アカウント内の任意のリソースをクロスサービスの使用に関連付ける場合は、aws:SourceAccount を使用します。組織内の任意のアカウントの任意のリソースをクロスサービスの使用に関連付ける場合は、aws:SourceOrgID を使用します。AWS Organizations パス内の任意のアカウントのリソースをクロスサービスの使用に関連付ける場合は、aws:SourceOrgPaths を使用します。パスの使用と理解の詳細については、「AWS Organizations エンティティパスを理解する」を参照してください。

混乱した代理問題から保護するための最もきめ細かな方法は、リソースベースポリシー内のリソースの完全な ARN を指定しながら、グローバル条件コンテキストキー aws:SourceArn を使用することです。リソースの完全な ARN が不明な場合や、複数のリソースを指定する場合には、グローバル条件コンテキストキー aws:SourceArn で、ARN の未知部分を示すためにワイルドカード (*) を使用します。例えば、arn:aws:servicename:*:123456789012:* と指定します。

aws:SourceArn の値に Amazon S3 バケット ARN などのアカウント ID が含まれていない場合は、両方の aws:SourceAccount と aws:SourceArn を使用して、アクセス許可を制限する必要があります。

混乱した代理問題から保護するために、リソースベースポリシー内のリソースの組織 ID または組織パスを指定しながら、aws:SourceOrgID または aws:SourceOrgPaths のグローバル条件コンテキストキーを使用してください。aws:SourceOrgID または aws:SourceOrgPaths キーを含むポリシーには正しいアカウントが自動的に組み込まれるため、組織のアカウントを追加、削除、移動する際には手動で更新する必要はありません。

サービスにリンクされていないロールの信頼ポリシーの場合、信頼ポリシー内のすべてのサービスで iam:PassRole アクションを実行して、ロールが読み出し元サービスと同じアカウントにあることが検証されています。その結果、これらの信頼ポリシーと aws:SourceAccount、aws:SourceOrgID、または aws:SourceOrgPaths を併用する必要はありません。信頼ポリシーで aws:SourceArn を使用すると、Lambda 関数 ARN など、代理としてロールが引き受けることのできるリソースを指定できます。一部の AWS のサービス では、新しく作成されたロールに対して信頼ポリシーで aws:SourceAccount と aws:SourceArn を使用しますが、アカウント内の既存のロールにキーを使用する必要はありません。

AWS Security Token Service のクロスサービスでの混乱した代理の防止

AWS の多くのサービスでは、ロールを使用して、ユーザーに代わって該当サービスが他のサービスのリソースにアクセスすることを許可する必要があります。サービスがお客様に代わってアクションを実行するために引き受けるロールは、サービスロールと呼ばれます。ロールには 2 つのポリシーが必要です。ロールを引き受けることができるプリンシパルを指定する、ロールの信頼ポリシーと、ロールで実行できる操作を指定する、アクセス許可ポリシーです。IAM においては、ロールの信頼ポリシーがリソースベースのポリシーの唯一のタイプです。その他の AWS のサービス には、Amazon S3 バケットポリシーなどのリソースベースのポリシーがあります。

サービスがユーザーに代わってロールを引き受ける場合、サービスプリンシパルが sts:AssumeRole アクションを実行できるように、ロールの信頼ポリシーで許可されている必要があります。サービスが sts:AssumeRole を呼び出すとき、ロールのアクセス許可ポリシーで許可されているリソースに、サービスプリンシパルがアクセスするために使用する、一時的なセキュリティー認証情報のセットを、AWS STS が返します。アカウント内でサービスがロールを引き受ける場合は、ロール信頼ポリシーに aws:SourceArn、aws:SourceAccount、aws:SourceOrgID または aws:SourceOrgPaths のグローバル条件コンテキストキーを含めることで、期待するリソースによって生成されたリクエストのみに、ロールのアクセスを制限できます。

例えば、AWS Systems Manager Incident Manager では、お客様の代わりに Incident Manager が Systems Manager Automation ドキュメント を実行できるように、ロールを選択する必要があります。オートメーションドキュメントには、CloudWatch アラームまたは EventBridge イベントによって開始される、インシデントの自動化された応答プランを含めることができます。次のロール信頼ポリシーの例では、aws:SourceArn 条件キーを使用して、インシデントレコードの ARN をもとに、サービスロールへのアクセスを制限できます。応答プランリソース myresponseplan から作成されたインシデントレコードのみが、このロールを使用できます。

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "Service": "ssm-incidents.amazonaws.com"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "ArnLike": {
        "aws:SourceArn": "arn:aws:ssm-incidents:*:111122223333:incident-record/myresponseplan/*"
      }
    }
  }
}