セルフマネージド型のアクセス許可を付与する - AWS CloudFormation

セルフマネージド型のアクセス許可を付与する

セルフマネージド型アクセス許可を使用する場合、アカウントと 間でデプロイするために StackSets で必要な AWS リージョン (IAM) ロールを作成します。これらのロールは、スタックセットを管理するアカウントとスタックインスタンスをデプロイするアカウントとの間に信頼できる関係を確立するために必要です。このアクセス許可モデルを使用すると、StackSets は、 IAM ロールを作成するアクセス許可を持つ任意の AWS アカウント にデプロイできます。

サービス管理アクセス許可を使用するには、AWS Organizations の信頼されたアクセスをアクティブ化する代わりに「」を参照してください。

セルフマネージド型のアクセス許可

セルフマネージド型のアクセス許可を持つスタックセットを作成する前に、各アカウントに IAM サービスロールを作成しておく必要があります。

基本的なステップは次のとおりです。

  1. どの AWS アカウントが管理者アカウントであるかを判断します。

    スタックセットはこの管理者アカウントで作成されます。ターゲットアカウントは、スタックセットに属する個別のスタックを作成するアカウントです。

  2. スタックセットのアクセス許可を構成する方法を決定します。

    最も単純な (そして最も許容性の高い) アクセス許可構成は、管理者アカウントのすべてのユーザーとグループに、そのアカウントで管理されているすべてのスタックセットを作成および更新するアクセス権限を付与することです。きめ細かな制御が必要な場合は、以下を指定するアクセス許可を設定できます。

    • ターゲットアカウントを持つスタックセットオペレーションを実行できるユーザーとグループ。

    • ユーザーとグループがスタックセットに含めることができるリソース。

    • 特定のユーザーおよびグループが実行できるスタックセットオペレーション。

  3. 管理者とターゲットアカウントに必要な IAM サービスロールを作成して、必要なアクセス許可を定義します。

    具体的には、次の 2 つの必須ロールがあります。

    • AWSCloudFormationStackSetAdministrationRole – このロールは管理者アカウントにデプロイされます。

    • AWSCloudFormationStackSetExecutionRole – このロールは、スタックインスタンスを作成するすべてのアカウントにデプロイされます。

すべてのターゲットアカウントでスタックセットオペレーションを実行するために、管理者アカウントのすべてのユーザーのアクセス許可を設定する

すべてのターゲットアカウントでスタックセットオペレーションを実行するために、管理者アカウントのすべてのユーザーのアクセス許可を設定する 管理者アカウントとターゲットアカウントで必要な IAM サービスロールを作成する手順を説明します。管理者アカウントへのアクセス許可を持つユーザーは、ターゲットアカウントの任意のスタックセットを作成、更新、または削除するアクセス許可を持ちます。

このようにアクセス許可を作成すると、スタックセットを作成または更新してもユーザーが管理者ロールを渡すことはありません。

管理者アカウントとターゲットアカウントの間に信頼関係を設定します。管理者アカウントのユーザーは誰でもスタックセットを作成できます。
Administrator account

管理者アカウントで、AWSCloudFormationStackSetAdministrationRole という名前の IAM ロールを作成します。

そのためには、以下の AWS CloudFormation テンプレートからスタックを作成します。このテンプレートは https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetAdministrationRole.yml でオンラインで入手できます。

例 アクセス許可ポリシーの例。

前述のテンプレートによって作成された管理ロールには、次のアクセス許可ポリシーが含まれています。

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::*:role/AWSCloudFormationStackSetExecutionRole" ], "Effect": "Allow" } ] }
例 信頼ポリシーの例

前述のテンプレートには、管理ロールを使用するアクセス許可とロールにアタッチされたアクセス許可をサービスに付与する次の信頼ポリシーも含まれています。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudformation.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
例 信頼ポリシーの例

デフォルトで無効になっているリージョンにあるターゲットアカウントにスタックインスタンスをデプロイするには、そのリージョンのリージョンサービスプリンシパルも含める必要があることに注意してください。デフォルトで無効になっているリージョンごとに、独自のリージョンサービスプリンシパルがあります。

次の信頼ポリシーの例では、デフォルトで無効になっているリージョンであるアジアパシフィック (香港) リージョン (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 全般のリファレンスの「リージョンとエンドポイント」を参照してください。

Target accounts

各ターゲットアカウントで、管理者アカウントを信頼する AWSCloudFormationStackSetExecutionRole という名前のサービスロールを作成します。ロールにはこの正確な名前が必要です。そのためには、以下の AWS CloudFormation テンプレートからスタックを作成します。このテンプレートは https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetExecutionRole.yml でオンラインで入手できます。このテンプレートを使用すると、ターゲットアカウントと信頼関係を持っている必要がある管理者アカウントの名前を指定するよう求められます。

重要

このテンプレートは管理者アクセス権を付与することに注意してください。テンプレートを使用してターゲットアカウント実行ロールを作成した後、ポリシーステートメントのアクセス許可を、StackSets を使用して作成するリソースの種類にスコープする必要があります。

ターゲットアカウントサービスロールは、AWS CloudFormation テンプレートで指定されたすべてのオペレーションを実行するアクセス許可を必要とします。たとえば、テンプレートが S3 バケットを作成している場合、S3 の新しいオブジェクトを作成するためのアクセス許可が必要です。ターゲットアカウントは常に完全な AWS CloudFormation アクセス許可を必要とします。これには、スタックを作成、更新、削除、および記述するためのアクセス許可が含まれます。

例 アクセス許可ポリシー 1 の例。

このテンプレートで作成されたロールは、ターゲットアカウントで次のポリシーを有効にします。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ] }
例 アクセス許可ポリシー 2 の例。

以下の例は、StackSets が機能するための最低限のアクセス許可を持つポリシーステートメントを示します。 以外のサービスのリソースを使用するターゲットアカウントでスタックを作成するには、それらのサービスアクションおよびリソースを、各ターゲットアカウントの [AWSCloudFormationStackSetExecutionRole] ポリシーステートメントに追加する必要があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*" ], "Resource": "*" } ] }
例 信頼ポリシーの例

次の信頼関係は、テンプレートによって作成されています。管理者アカウントの ID は、admin_account_id として表示されます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::admin_account_id:root" }, "Action": "sts:AssumeRole" } ] }

既存のターゲットアカウントの実行ロールの信頼関係を設定して、管理者アカウントで特定のロールを信頼できます。管理者アカウントでロールを削除し、代わりとなる新しいロールを作成する場合、新しい管理者アカウントロールでターゲットアカウントの信頼関係を設定する必要があります。これは、前の例の admin_account_id によって表されます。

スタックセットオペレーションのアドバンストアクセス許可オプションの設定

ユーザーとグループが 1 つの管理者アカウントを使用して作成しているスタックセットに対してきめ細かな制御が必要な場合は、IAM ロールを使用して次の項目を指定できます。

  • ターゲットアカウントを持つスタックセットオペレーションを実行できるユーザーとグループ。

  • ユーザーとグループがスタックセットに含めることができるリソース。

  • 特定のユーザーおよびグループが実行できるスタックセットオペレーション。

特定のターゲットアカウントでスタックセットオペレーションを実行できるユーザーを制御する

カスタマイズされた管理者ロールを使用して、どのユーザーおよびグループがどのターゲットアカウントでスタックセットオペレーションを実行できるかを制御します。スタックセットオペレーションを実行する管理者アカウントのユーザーとターゲットアカウントを制御します。これを行うには、管理者アカウント自体に AWSCloudFormationStackSetAdministrationRole サービスロールを作成するのではなく、各ターゲットアカウントと特定のカスタマイズされた管理ロールの間に信頼関係を作成します。これで、特定のターゲットアカウントでスタックセットオペレーションを実行する際、特定のユーザーとグループをアクティブ化して、カスタマイズされた管理者ロールを使用します。

たとえば、ロール A とロール B を管理者アカウント内に作成できます。ターゲットアカウント 1 ~ 8 にアクセスする許可を ロール A に付与することができます。ターゲットアカウント 9 ~ 16 にアクセスする許可を ロール B に付与することができます。

カスタマイズされた管理者ロールとターゲットアカウントの間に信頼関係を設定します。スタックセットを作成する際、ユーザーはそのロールを渡します。

必要なアクセス許可を設定するには、カスタマイズされた管理者ロールの定義、ターゲットアカウントのサービスロールの作成、ユーザーへのアクセス許可の付与を行い、スタックセットオペレーションを実行するときに、カスタマイズされた管理者ロールを渡す必要があります。

必要な許可を設定したときの一般的な動作は次のとおりです。スタックセットを作成する際、ユーザーは、カスタマイズされた管理者を指定する必要があります。ユーザーには、AWS CloudFormation にロールを渡すためのアクセス権限が必要です。さらに、カスタマイズされた管理者ロールには、スタックセットに指定されたターゲットアカウントとの信頼関係が必要です。AWS CloudFormation ではスタックセットを作成し、カスタマイズされた管理者ロールをこのスタックセットに関連付けます。スタックセットを更新する場合、ユーザーはカスタマイズされた管理者ロールを明示的に指定する必要があります (このスタックセットで以前に使用したのと同じカスタマイズされた管理者ロールである場合でも)。AWS CloudFormation は、上記の要件に従い、このロールを使用してスタックを更新します。

Administrator account
例 アクセス許可ポリシーの例。

スタックセットごとに、ターゲットアカウントの AWSCloudFormationStackSetExecutionRole サービスロールを引き受けるアクセス許可を持つカスタマイズされた管理者ロールを作成します。

ターゲットアカウントの実行ロール名は、すべてのターゲットアカウントで同じである必要があります。ロール名が AWSCloudFormationStackSetExecutionRoleの場合、StackSets はスタックセットの作成時にロール名を自動的に使用します。カスタムロール名を指定する場合、ユーザーはスタックセットを作成するときに実行ロール名を指定する必要があります。

次のアクセス許可ポリシーに従って、カスタム名を指定してIAM サービスロールを作成します。以下の例では、custom_execution_role はターゲットアカウントの実行ロールを参照します。

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::target_account_id: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 の代わりにワイルドカード (*) を使用して、すべてのターゲットアカウントを指定できます。

"Resource": [ "arn:aws:iam::*:role/custom_execution_role" ]
例 信頼ポリシーの例

ロールを引き受けることができる IAM プリンシパルを定義するには、サービスロールの信頼ポリシーを指定する必要があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudformation.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
例 信頼ポリシーの例

デフォルトで無効になっているリージョンにあるターゲットアカウントにスタックインスタンスをデプロイするには、そのリージョンのリージョンサービスプリンシパルも含める必要があることに注意してください。デフォルトで無効になっているリージョンごとに、独自のリージョンサービスプリンシパルがあります。

次の信頼ポリシーの例では、デフォルトで無効になっているリージョンであるアジアパシフィック (香港) リージョン (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 全般のリファレンスの「リージョンとエンドポイント」を参照してください。

例 パスロールポリシーの例

また、スタックセットオペレーションの実行時にカスタマイズされた管理ロールを渡すことをユーザーに許可する IAM ユーザーの IAM アクセス許可ポリシーも必要です。詳細については、Granting a user permissions to pass a role to an AWS service を参照してください。

以下の例では、customized_admin_role は、ユーザーが渡す必要のある管理者ロールを意味します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:GetRole", "iam:PassRole" ], "Resource": "arn:aws:iam::*:role/customized_admin_role" } ] }
Target accounts

ターゲットアカウントごとに、このアカウントで使用するカスタマイズされた管理者ロールを信頼する AWSCloudFormationStackSetExecutionRole という名前のサービスロールを作成します。

ターゲットアカウントサービスロールは、AWS CloudFormation テンプレートで指定されたすべてのオペレーションを実行するアクセス許可を必要とします。たとえば、テンプレートが S3 バケットを作成している場合、S3 の新しいオブジェクトを作成するためのアクセス許可が必要です。ターゲットアカウントは常に完全な AWS CloudFormation アクセス許可を必要とします。これには、スタックを作成、更新、削除、および記述するためのアクセス許可が含まれます。

ターゲットアカウントのロール名は、すべてのターゲットアカウントで同じである必要があります。ロール名が AWSCloudFormationStackSetExecutionRoleの場合、StackSets はスタックセットの作成時にロール名を自動的に使用します。カスタムロール名を指定する場合、ユーザーはスタックセットを作成するときに実行ロール名を指定する必要があります。

例 アクセス許可ポリシーの例。

以下の例は、StackSets が機能するための最低限のアクセス許可を持つポリシーステートメントを示します。CloudFormation 以外のサービスのリソースを使用するターゲットアカウントでスタックを作成するには、それらのサービスアクションおよびリソースを、各ターゲットアカウントの ポリシーステートメントに追加する必要があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*" ], "Resource": "*" } ] }
例 信頼ポリシーの例

信頼関係を定義するロールを作成する際、次の信頼ポリシーを指定する必要があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::admin_account_id:role/customized_admin_role" }, "Action": "sts:AssumeRole" } ] }

ユーザーが特定のスタックセットに含めることができるリソースを制御する

カスタマイズされた実行ロールを使用して、ユーザーおよびグループがスタックセットに含めることができるスタックリソースを制御します。たとえば、作成したスタックセットに Amazon S3 関連のリソースのみを含めることができるグループを設定し、別のチームには DynamoDB リソースのみを含めることができます。これを行うには、各グループのカスタマイズされた管理者ロールと各リソースセットのカスタマイズされた実行ロールとの間に信頼関係を作成します。カスタマイズされた実行ロールは、どのスタックリソースをスタックセットに含めることができるかを定義します。カスタマイズされた管理者ロールは管理者アカウントにあり、カスタマイズされた実行ロールは定義されたリソースを使用してスタックセットを作成する各ターゲットアカウントにあります。これで、スタックセットオペレーションを実行する際、特定のユーザーとグループが、カスタマイズされた管理者ロールを使用できるようにアクティブ化します。

たとえば、管理者アカウントでカスタマイズされた管理者ロール A、B、C を作成できます。ロール A を使用するアクセス許可を持つユーザーおよびグループは、カスタマイズされた実行ロール X に明確にリストされているスタックリソースを含むスタックセットを作成できますが、ロール Y または Z のリソースや実行ロールに含まれていないリソースは含まれません。

カスタマイズされた管理者ロールと、ターゲットアカウント内のカスタマイズされた実行ロールの間に信頼関係を設定します。スタックセットを作成する際、ユーザーはそれらのロールを渡します。

スタックセットを更新する場合、ユーザーはカスタマイズされた管理者ロールを明示的に指定する必要があります (このスタックセットで以前に使用したのと同じカスタマイズされた管理者ロールである場合でも)。ユーザーがスタックセットに対してオペレーションを実行するアクセス許可を持っている場合、AWS CloudFormation は指定のカスタマイズされた管理者ロールを使用して更新を実行します。

同様に、ユーザーはカスタマイズされた実行ロールを指定することもできます。カスタマイズされた実行ロールを指定した場合、AWS CloudFormation は、上記の要件に従って、スタックを更新するロールを使用します。ユーザーがカスタマイズされた実行ロールを指定しない場合、 は、スタックセットでオペレーションを実行する許可がユーザーに付与されている限り、スタックセットに以前関連付けられていた、カスタマイズされた実行ロールを使用して更新を行います。

Administrator account

特定のターゲットアカウントでスタックセットオペレーションを実行できるユーザーを制御する」で説明されているように、カスタマイズされた管理者ロールを管理者アカウントで作成します。カスタマイズされた管理者ロールと、使用するカスタマイズされた実行ロールとの間に信頼関係を含めます。

例 アクセス許可ポリシーの例。

次の例には、カスタマイズされた実行ロールに加えて、ターゲットアカウントに対して定義された 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

スタックセットを作成する対象のアカウントで、ユーザーとグループがスタックセットに含めることができるようにするサービスとリソースにアクセス許可を付与するカスタマイズされた実行ロールを作成します。

例 アクセス許可ポリシーの例。

次の例では、スタックセットの最小限のアクセス許可に加えて、Amazon DynamoDB テーブルを作成するアクセス許可を付与しています。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "dynamoDb:createTable" ], "Resource": "*" } ] }
例 信頼ポリシーの例

信頼関係を定義するロールを作成する際、次の信頼ポリシーを指定する必要があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::admin_account_id:role/customized_admin_role" }, "Action": "sts:AssumeRole" } ] }

特定のスタックセットオペレーションのアクセス許可を設定する

さらに、スタックセットの作成、更新、削除、インスタンスのスタックなど、特定のスタックセットオペレーションを実行できるユーザーとグループのアクセス許可を設定できます。詳細については、IAM ユーザーガイド にある Actions, resources, and condition keys for AWS CloudFormation を参照してください。

混乱した代理問題を軽減するためにグローバルキーを設定する

混乱した代理問題は、アクションを実行する許可を持たないエンティティが、より権限のあるエンティティにアクションの実行を強制できるセキュリティ上の問題です。AWS では、サービス間でのなりすましによって、混乱した代理問題が発生する場合があります。サービス間でのなりすましは、あるサービス (呼び出し元サービス) が、別のサービス (呼び出し対象サービス) を呼び出すときに発生する可能性があります。呼び出し元サービスが操作され、それ自身のアクセス許可を使用して、本来アクセス許可が付与されるべきではない方法で別の顧客のリソースに対して働きかけることがあります。これを防ぐため、AWS では、アカウント内のリソースへのアクセス許可が付与されたサービスプリンシパルですべてのサービスのデータを保護するために役立つツールを提供しています。

リソースポリシーで aws:SourceArn および aws:SourceAccount のグローバル条件コンテキストキーを使用して、AWS 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) を入力します。したがって、信頼関係でグローバルキー aws:SourceAccount および aws:SourceArn の条件を定義して、混乱した代理問題を防ぐことができます。次の例では、StackSets で aws:SourceArn および aws:SourceAccount グローバル条件コンテキストキーを使用して、混乱した代理問題を回避する方法を示します。

Administrator account
aws:SourceAccount および aws:SourceArn のグローバルキー

StackSets を使用する場合は、 信頼ポリシーでグローバルキー aws:SourceAccountaws:SourceArn を定義して、混乱した代理の問題を防ぎます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudformation.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" }, "StringLike": { "aws:SourceArn": "arn:aws:cloudformation:*:111122223333:stackset/*" } } } ] }
例 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", ] } } } ] }