# セルフマネージド型のアクセス許可を付与する
このトピックでは、*セルフマネージド*許可を使用して、複数のアカウントおよび AWS リージョン にデプロイするために、StackSets によって必要とされる IAM サービスロールを作成する方法について説明します。これらのロールは、StackSet を管理するアカウントとスタックインスタンスをデプロイするアカウントとの間に信頼できる関係を確立するために必要です。このアクセス許可モデルを使用すると、StackSets は、 IAM ロールを作成するアクセス許可を持つ任意の AWS アカウント にデプロイできます。
*サービス管理アクセス*許可を使用するには、[信頼されたアクセスをアクティブ化する](stacksets-orgs-activate-trusted-access.md)代わりに「」を参照してください。
**Topics**
+ [セルフマネージド許可の概要](#prereqs-self-managed-permissions)
+ [管理者アカウントのすべてのユーザーに、すべてのターゲットアカウントのスタックを管理するための許可を付与します。](#stacksets-prereqs-accountsetup)
+ [StackSet オペレーションのアドバンストアクセス許可オプションの設定](#stacksets-prereqs-advanced-perms)
+ [混乱した代理問題を軽減するためにグローバルキーを設定する](#confused-deputy-mitigation)
## セルフマネージド許可の概要
セルフマネージド型のアクセス許可を持つ StackSet を作成する前に、各アカウントで IAM サービスロールを作成しておく必要があります。
基本的なステップは次のとおりです。
1. どの AWS アカウント が*管理者アカウント*であるかを判断します。
StackSets はこの管理者アカウントで作成されます。*ターゲットアカウント*は、StackSet に属する個別のスタックを作成するアカウントです。
1. StackSet のアクセス許可を構成する方法を決定します。
最も単純な (そして最も許容性の高い) アクセス許可設定は、管理者アカウントの*すべて*のユーザーとグループに、そのアカウントで管理されている*すべて*の StackSet を作成および更新する権限を付与することです。きめ細かな制御が必要な場合は、以下を指定するアクセス許可を設定できます。
+ どのユーザーとグループがどのターゲットアカウントで StackSet オペレーションを実行できるか。
+ ユーザーとグループが StackSets に含めることができるリソース。
+ 特定のユーザーおよびグループが実行できる StackSet オペレーション。
1. 管理者とターゲットアカウントに必要な IAM サービスロールを作成して、必要なアクセス許可を定義します。
具体的には、必要な 2 つのロールは次のとおりです:
+ **AWSCloudFormationStackSetAdministrationRole** – このロールは管理者アカウントにデプロイされます。
+ **AWSCloudFormationStackSetExecutionRole** – このロールは、スタックインスタンスを作成するすべてのアカウントにデプロイされます。
## 管理者アカウントのすべてのユーザーに、すべてのターゲットアカウントのスタックを管理するための許可を付与します。
このセクションでは、管理者アカウントのすべてのユーザーとグループが、すべてのターゲットアカウントで StackSet オペレーションを実行することを許可するためのアクセス許可を設定する方法を説明します。管理者アカウントとターゲットアカウントで必要な IAM サービスロールを作成する手順を説明します。管理者アカウントのユーザーは誰でも、任意のターゲットアカウント全体でスタックを作成、更新、または削除できるようになります。
このようにアクセス許可を構成することで、ユーザーは StackSet を作成または更新するときに管理ロールを渡す必要がなくなります。
![\[このため、信頼関係を設定した後は、管理者アカウント内のユーザーなら誰でもターゲットアカウントに StackSet を作成できるようになります。\]](http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/images/stacksets_perms_master_target.png)
------
#### [ Administrator account ]
管理者アカウントで、**AWSCloudFormationStackSetAdministrationRole** という名前の IAM ロールを作成します。
そのためには、CloudFormation テンプレートからスタックを作成します。このテンプレートは [https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetAdministrationRole.yml](https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetAdministrationRole.yml) で入手できます。
**Example アクセス許可ポリシーの例。**
前述のテンプレートによって作成された管理ロールには、次の許可ポリシーが含まれています。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::*:role/AWSCloudFormationStackSetExecutionRole"
],
"Effect": "Allow"
}
]
}
```
**Example 信頼ポリシーの例 1**
また、前述のテンプレートには、管理ロールと、ロールにアタッチされた許可を使用するためのサービス許可を付与する次の信頼ポリシーも含まれています。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
**Example 信頼ポリシーの例 2**
デフォルトで無効になっているリージョンにあるターゲットアカウントにスタックインスタンスをデプロイするには、そのリージョンのリージョンサービスプリンシパルを含める必要もあります。デフォルトで無効になっているリージョンごとに、独自のリージョンサービスプリンシパルがあります。
次の信頼ポリシーのサンプルは、デフォルトでは無効になっているアジアパシフィック (香港) リージョン (`ap-east-1`) で管理ロールを使用するための許可をサービスに付与します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"cloudformation.amazonaws.com",
"cloudformation.ap-east-1.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
詳細については、「[デフォルトでは無効になっている AWS リージョン で StackSet オペレーションを実行する準備をする](stacksets-opt-in-regions.md)」を参照してください。リージョンコードの一覧については、「*AWS 全般のリファレンス ガイド*」の「[Regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints)」を参照してください。
------
#### [ Target accounts ]
各ターゲットアカウントで、管理者アカウントを信頼する **AWSCloudFormationStackSetExecutionRole** という名前のサービスロールを作成します。ロールにはこの正確な名前が必要です。そのためには、以下の CloudFormation テンプレートからスタックを作成します。このテンプレートは [https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetExecutionRole.yml](https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetExecutionRole.yml) でオンラインで入手できます。このテンプレートを使用すると、ターゲットアカウントと信頼関係を持っている必要がある管理者アカウントのアカウント ID を指定するよう求められます。
**重要**
このテンプレートは管理者アクセス権を付与することに注意してください。テンプレートを使用してターゲットアカウント実行ロールを作成した後、ポリシーステートメントのアクセス許可を、StackSets を使用して作成するリソースの種類にスコープする必要があります。
ターゲットアカウントサービスロールは、CloudFormation テンプレートで指定されたすべてのオペレーションを実行する許可を必要とします。たとえば、テンプレートが S3 バケットを作成している場合、S3 の新しいオブジェクトを作成するためのアクセス許可が必要です。ターゲットアカウントは常に完全な CloudFormation 許可を必要とします。これには、スタックを作成、更新、削除、および記述するための許可が含まれます。
**Example アクセス許可ポリシー 1 の例。**
このテンプレートで作成されたロールは、ターゲットアカウントで次のポリシーを有効にします。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
```
**Example アクセス許可ポリシー 2 の例。**
以下の例は、StackSets が機能するための*最低限*のアクセス許可を持つポリシーステートメントを示します。CloudFormation 以外のサービスのリソースを使用するターゲットアカウントでスタックを作成するには、それらのサービスアクションおよびリソースを、各ターゲットアカウントの **AWSCloudFormationStackSetExecutionRole** ポリシーステートメントに追加する必要があります。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:*"
],
"Resource": "*"
}
]
}
```
**Example 信頼ポリシーの例**
次の信頼関係は、テンプレートによって作成されています。管理者アカウントの ID は、*admin\$1account\$1id* として表示されます。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole"
}
]
}
```
既存のターゲットアカウントの実行ロールの信頼関係を設定して、管理者アカウントで特定のロールを信頼できます。管理者アカウントでロールを削除し、代わりとなる新しいロールを作成する場合、新しい管理者アカウントロールでターゲットアカウントの信頼関係を設定する必要があります。これは、前の例の *admin\$1account\$1id* によって表されます。
------
## StackSet オペレーションのアドバンストアクセス許可オプションの設定
ユーザーとグループが 1 つの管理者アカウントを使用して作成している StackSets に対してきめ細かな制御が必要な場合は、IAM ロールを使用して次の項目を指定できます。
+ どのユーザーとグループがどのターゲットアカウントで StackSet オペレーションを実行できるか。
+ ユーザーとグループが StackSets に含めることができるリソース。
+ 特定のユーザーおよびグループが実行できる StackSet オペレーション。
### 特定のターゲットアカウントで StackSet オペレーションを実行できるユーザーを制御する
カスタマイズされた管理ロールを使用して、どのユーザーおよびグループがどのターゲットアカウントで StackSet オペレーションを実行できるかを制御します。StackSet オペレーションを実行する管理者アカウントのユーザーとターゲットアカウントを制御します。これを行うには、管理者アカウント自体に **AWSCloudFormationStackSetAdministrationRole** サービスロールを作成するのではなく、各ターゲットアカウントと特定のカスタマイズされた管理ロールの間に信頼関係を作成します。これで、特定のターゲットアカウントで StackSet オペレーションを実行する際、特定のユーザーとグループをアクティブ化して、カスタマイズされた管理ロールを使用します。
たとえば、ロール A とロール B を管理者アカウント内に作成できます。ターゲットアカウント 1 ～ 8 にアクセスする許可を ロール A に付与することができます。ターゲットアカウント 9 ～ 16 にアクセスする許可を ロール B に付与することができます。
![\[ユーザーによる StackSet の作成を許可する、カスタマイズされた管理ロールとターゲットアカウント間における信頼関係。\]](http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/images/stacksets_perms_admin_target.png)
必要な許可を設定するには、カスタマイズされた管理ロールの定義、ターゲットアカウントのサービスロールの作成、ユーザーへの許可の付与を行い、StackSet オペレーションを実行するときに、カスタマイズされた管理ロールを渡す必要があります。
必要な許可を設定したときの一般的な動作は次のとおりです。StackSet を作成する際、ユーザーは、カスタマイズされた管理ロールを指定する必要があります。ユーザーには、CloudFormation にロールを渡すための許可が必要です。さらに、カスタマイズされた管理ロールには、StackSet に指定されたターゲットアカウントとの信頼関係が必要です。CloudFormation では StackSet を作成し、カスタマイズされた管理ロールをこの StackSet に関連付けます。StackSet を更新する場合、ユーザーはカスタマイズされた管理ロールを明示的に指定する必要があります (この StackSet で以前に使用したのと同じカスタマイズされた管理ロールである場合でも必要です)。CloudFormation は、上記の要件に従い、このロールを使用してスタックを更新します。
------
#### [ Administrator account ]
**Example アクセス許可ポリシーの例。**
StackSet ごとに、ターゲットアカウント実行ロールを引き受けるためのアクセス許可を持つカスタマイズされた管理ロールを作成します。
ターゲットアカウント実行ロール名は、すべてのターゲットアカウントで同じである必要があります。ロール名が **AWSCloudFormationStackSetExecutionRole** である場合、StackSets は StackSet を作成する際にその名前を自動的に使用します。カスタムロール名を指定する場合、ユーザーは StackSet を作成する際に実行ロール名を指定する必要があります。
カスタム名と次の許可ポリシーを使用して [IAM サービスロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)を作成します。以下の例では、*custom\$1execution\$1role* はターゲットアカウントの実行ロールを指します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::111122223333:role/custom_execution_role"
],
"Effect": "Allow"
}
]
}
```
単一のステートメントで複数のアカウントを指定するには、アカウントをカンマで区切ります。
```
"Resource": [
"arn:aws:iam::target_account_id_1:role/custom_execution_role",
"arn:aws:iam::target_account_id_2:role/custom_execution_role"
]
```
アカウント ID の代わりにワイルドカード (\$1) を使用して、すべてのターゲットアカウントを指定できます。
```
"Resource": [
"arn:aws:iam::*:role/custom_execution_role"
]
```
**Example 信頼ポリシーの例 1**
どの IAM プリンシパルがロールを引き受けることができるかを定義するには、サービスロールの信頼ポリシーを指定する必要があります。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
**Example 信頼ポリシーの例 2**
デフォルトで無効になっているリージョンにあるターゲットアカウントにスタックインスタンスをデプロイするには、そのリージョンのリージョンサービスプリンシパルを含める必要もあります。デフォルトで無効になっているリージョンごとに、独自のリージョンサービスプリンシパルがあります。
次の信頼ポリシーのサンプルは、デフォルトでは無効になっているアジアパシフィック (香港) リージョン (`ap-east-1`) で管理ロールを使用するための許可をサービスに付与します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"cloudformation.amazonaws.com",
"cloudformation.ap-east-1.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
詳細については、「[デフォルトでは無効になっている AWS リージョン で StackSet オペレーションを実行する準備をする](stacksets-opt-in-regions.md)」を参照してください。リージョンコードのリストについては、「*AWS 全般のリファレンスガイド*」の「[Regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints)」を参照してください。
**Example パスロールポリシーの例**
また、StackSet オペレーションを実行する際にユーザーがカスタマイズされた管理ロールを渡すことを許可する IAM ユーザーの IAM 許可ポリシーも必要です。詳細については、[Granting a user permissions to pass a role to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) を参照してください。
以下の例では、*customized\$1admin\$1role* は、ユーザーが渡す必要のある管理ロールを意味します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:PassRole"
],
"Resource": "arn:aws:iam::*:role/customized_admin_role"
}
]
}
```
------
#### [ Target accounts ]
ターゲットアカウントごとに、このアカウントで使用するカスタマイズされた管理者ロールを信頼するサービスロールを作成します。
ターゲットアカウントロールは、CloudFormation テンプレートで指定されたすべてのオペレーションを実行する許可を必要とします。たとえば、テンプレートが S3 バケットを作成している場合、S3 の新しいオブジェクトを作成するためのアクセス許可が必要です。ターゲットアカウントは常に完全な CloudFormation 許可を必要とします。これには、スタックを作成、更新、削除、および記述するための許可が含まれます。
ターゲットアカウントのロール名は、すべてのターゲットアカウントで同じである必要があります。ロール名が **AWSCloudFormationStackSetExecutionRole** である場合、StackSets は StackSet を作成する際にその名前を自動的に使用します。カスタムロール名を指定する場合、ユーザーは StackSet を作成する際に実行ロール名を指定する必要があります。
**Example アクセス許可ポリシーの例。**
以下の例は、StackSets が機能するための*最低限*のアクセス許可を持つポリシーステートメントを示します。CloudFormation 以外のサービスのリソースを使用するターゲットアカウントでスタックを作成するには、それらのサービスアクションおよびリソースを、許可ポリシーに追加する必要があります。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:*"
],
"Resource": "*"
}
]
}
```
**Example 信頼ポリシーの例**
信頼関係を定義するロールを作成する際、次の信頼ポリシーを指定する必要があります。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/customized_admin_role"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
### ユーザーが特定の StackSets に含めることができるリソースを制御する
カスタマイズされた実行ロールを使用して、ユーザーおよびグループが StackSets に含めることができるスタックリソースを制御します。例えば、作成した StackSets に Amazon S3 関連のリソースのみを含めることができるグループを設定し、別のチームには DynamoDB リソースのみを含めることができます。これを行うには、各グループのカスタマイズされた管理ロールと各リソースセットのカスタマイズされた実行ロールとの間に信頼関係を作成します。カスタマイズされた実行ロールは、どのスタックリソースを StackSets に含めることができるかを定義します。カスタマイズされた管理ロールは管理者アカウントにあり、カスタマイズされた実行ロールは定義されたリソースを使用して StackSets を作成する各ターゲットアカウントにあります。次に、StackSets オペレーションを実行するときにカスタマイズされた管理ロールを使用するように特定のユーザーとグループをアクティブ化します。
例えば、管理アカウントでカスタマイズされた管理者ロール A、B、C を作成できます。ロール A を使用するアクセス許可を持つユーザーおよびグループは、カスタマイズされた実行ロール X に明確にリストされているスタックリソースを含む StackSets を作成できますが、ロール Y または Z のリソースや実行ロールに含まれていないリソースは含まれません。
![\[ユーザーによる StackSet の作成を許可する、カスタム管理者ロールとターゲットアカウント内のカスタム実行ロール間における信頼関係。\]](http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/images/stacksets_perms_admin_execution.png)
StackSet を更新する場合、ユーザーはカスタマイズされた管理ロールを明示的に指定する必要があります (この StackSet で以前に使用したのと同じカスタマイズされた管理ロールである場合でも必要です)。ユーザーが StackSet に対してオペレーションを実行するアクセス許可を持っている場合、CloudFormation は指定のカスタマイズされた管理ロールを使用して更新を実行します。
同様に、ユーザーはカスタマイズされた実行ロールを指定することもできます。カスタマイズされた実行ロールを指定した場合、CloudFormation は、上記の要件に従って、スタックを更新するロールを使用します。ユーザーがカスタマイズされた実行ロールを指定しない場合、CloudFormation は、StackSet でオペレーションを実行するアクセス許可がユーザーに付与されている限り、StackSet に以前関連付けられていた、カスタマイズされた実行ロールを使用して更新を行います。
------
#### [ Administrator account ]
「[特定のターゲットアカウントで StackSet オペレーションを実行できるユーザーを制御する](#stacksets-prereqs-multiadmin)」で説明されているように、カスタマイズされた管理ロールを管理者アカウントで作成します。カスタマイズされた管理ロールと、使用するカスタマイズされた実行ロールとの間に信頼関係を含めます。
**Example アクセス許可ポリシーの例。**
次の例は、ターゲットアカウントのために定義された **AWSCloudFormationStackSetExecutionRole** とカスタマイズされた実行ロールの両方のための許可ポリシーです。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Stmt1487980684000",
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::*:role/AWSCloudFormationStackSetExecutionRole",
"arn:aws:iam::*:role/custom_execution_role"
]
}
]
}
```
------
#### [ Target accounts ]
StackSets を作成するターゲットアカウントで、ユーザーとグループが StackSets に含めることができるようにするサービスとリソースにアクセス許可を付与するカスタマイズされた実行ロールを作成します。
**Example アクセス許可ポリシーの例。**
次の例では、StackSets の最小限のアクセス許可に加えて、Amazon DynamoDB テーブルを作成するアクセス許可を付与しています。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"dynamoDb:createTable"
],
"Resource": "*"
}
]
}
```
**Example 信頼ポリシーの例**
信頼関係を定義するロールを作成する際、次の信頼ポリシーを指定する必要があります。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/customized_admin_role"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
### 特定の StackSet オペレーションのアクセス許可を設定する
さらに、StackSets またはスタックインスタンスの作成、更新、削除など、特定の StackSet オペレーションを実行できるユーザーとグループのアクセス許可を設定できます。詳細については、「*サービス認可リファレンス*」の「[CloudFormation のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html)」を参照してください。
## 混乱した代理問題を軽減するためにグローバルキーを設定する
混乱した代理問題は、アクションを実行する許可を持たないエンティティが、より特権のあるエンティティにアクションを実行するように強制できるセキュリティの問題です。AWS では、サービス間でのなりすましによって、混乱した代理問題が発生する場合があります。サービス間でのなりすましは、あるサービス (*呼び出し元サービス*) が、別のサービス (*呼び出し対象サービス*) を呼び出すときに発生する可能性があります。呼び出し元サービスが操作され、それ自身のアクセス許可を使用して、本来アクセス許可が付与されるべきではない方法で別の顧客のリソースに対して働きかけることがあります。これを防ぐため、AWS では、アカウント内のリソースへのアクセス許可が付与されたサービスプリンシパルですべてのサービスのデータを保護するために役立つツールを提供しています。
リソースポリシーで [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) および [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) のグローバル条件コンテキストキーを使用して、CloudFormation StackSets が別のサービスに付与するアクセス許可をそのリソースに制限することをお勧めします。両方のグローバル条件コンテキストキーを同じポリシーステートメントで使用する場合は、`aws:SourceAccount` 値と、`aws:SourceArn` 値に含まれるアカウントが、同じアカウント ID を示している必要があります。
混乱した代理問題から保護するための最も効果的な方法は、リソースの完全な ARN を指定して `aws:SourceArn` グローバル条件コンテキストキーを使用することです。リソースの完全な ARN が不明な場合や、複数のリソースを指定する場合は、`aws:SourceArn` グローバルコンテキスト条件キーを使用して、ARN の未知部分をワイルドカード (`*`) で表します。例えば、`arn:aws:cloudformation::123456789012:*` です。より具体的であるため、可能な限り `aws:SourceArn` を使用してください。`aws:SourceAccount` は、正しい ARN または ARN パターンを判別できない場合にのみ使用してください。
StackSets が **[administrator]** (管理者) アカウントで **[Administration]** (管理者) ロールを引き受けるとき、StackSets は **[administrator]** (管理者) アカウント ID と StackSets Amazon リソースネーム (ARN) を入力します。したがって、信頼関係で[グローバルキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) `aws:SourceAccount` および `aws:SourceArn` の条件を定義して、[混乱した代理問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)を防ぐことができます。次の例では、StackSets で `aws:SourceArn` および `aws:SourceAccount` グローバル条件コンテキストキーを使用して、混乱した代理問題を回避する方法を示します。
------
#### [ Administrator account ]
**Example `aws:SourceAccount` および `aws:SourceArn` のグローバルキー**
StackSets を使用する場合は、混乱した代理の問題を防ぐために、**AWSCloudFormationStackSetAdministrationRole** 信頼ポリシーでグローバルキー `aws:SourceAccount` および `aws:SourceArn` を定義します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:cloudformation:*:111122223333:stackset/*"
}
}
}
]
}
```
**Example StackSets ARN**
より細かく制御するために、関連する StackSets ARN を指定します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": [
"arn:aws:cloudformation:STACKSETS-REGION:111122223333:stackset/STACK-SET-ID-1",
"arn:aws:cloudformation:STACKSETS-REGION:111122223333:stackset/STACK-SET-ID-2"
]
}
}
}
]
}
```
------