ポリシーテンプレート
ポリシーテンプレートとは、顧客のアカウントでパートナーがリクエストする一時的なアクセス許可を定義するための、新しい IAM コンストラクトです。従来の IAM ポリシーと同様、Effect、Action、Resource、Condition の各要素を含むステートメントを使用してアクセス許可を定義します。従来のポリシーとの大きな違いは、ポリシーテンプレートに、委任リクエストを作成する際に実際の値に置き換えられるパラメータ (@{bucketName} など) が含まれている点です。
ポリシーテンプレートの仕組み
ユーザーは、オンボーディングプロセスの最中にポリシーテンプレートを AWS に登録します。AWS は、各テンプレートに、委任リクエストの作成時に参照する一意の ARN を割り当てます。
委任リクエストを作成するときは、以下を指定します。
ポリシーテンプレート ARN
テンプレートに代入するパラメータ値
AWS は、テンプレートをパラメータ値と組み合わせて、標準の IAM ポリシーを生成します。顧客は、委任リクエストを承認するときに生成されたこの最終版のポリシーを確認し、付与されるアクセス許可を完全な形で目にします。
注記
生成された最終版のポリシーの、文字数の上限は 2048 文字です。
テンプレートの置換の仕組みを、以下の簡単な例でご紹介します。
ポリシーテンプレート
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::@{bucketName}/*" } ] }
委任リクエストで指定されるパラメータ
{ "Name": "bucketName", "Values": ["customer-data-bucket"], "Type": "String" }
生成された最終版のポリシー (顧客が目にする内容)
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::customer-data-bucket/*" } ] }
テンプレートの構文
ポリシーテンプレートは、パラメータ置換と条件ステートメントという 2 つの主要な機能により柔軟性を高めています。パラメータ置換を使用すると、委任リクエストの作成時に実際の値に置き換えられるプレースホルダーをテンプレートで定義できます。条件ステートメントを使用すると、パラメータ値に基づいて、ポリシーステートメント全体を含めたり除外したりできます。
パラメータ置換とタイプ
@{parameterName} 構文は、ポリシーテンプレートでパラメータを定義するときに使用します。委任リクエストを作成するときは、各パラメータのタイプを指定します。
String
テンプレートに直接代入される 1 個の値です。
テンプレート:
"Resource": "arn:aws:s3:::@{bucketName}/*"
パラメータ :
{ "Name": "bucketName", "Values": ["my-bucket"], "Type": "String" }
生成された結果
"Resource": "arn:aws:s3:::my-bucket/*"
StringList
複数のリソースエントリを生成する複数の値です。StringList パラメータは、リソース ARN で使用すると、値ごとに個別のリソースエントリを作成するように拡張します。
テンプレート:
"Resource": "arn:aws:s3:::@{bucketNames}/*"
パラメータ :
{ "Name": "bucketNames", "Values": ["bucket-1", "bucket-2"], "Type": "StringList" }
生成された結果
"Resource": [ "arn:aws:s3:::bucket-1/*", "arn:aws:s3:::bucket-2/*" ]
クロス積の動作
複数のパラメータを同じリソース ARN で使用すると、StringList パラメータはすべての組み合わせのクロス積を作成します。
テンプレート:
"Resource": "arn:aws:s3:::@{bucketNames}/@{prefix}/*"
パラメータ :
[ { "Name": "bucketNames", "Values": ["bucket-1", "bucket-2"], "Type": "StringList" }, { "Name": "prefix", "Values": ["data"], "Type": "String" } ]
生成された結果
"Resource": [ "arn:aws:s3:::bucket-1/data/*", "arn:aws:s3:::bucket-2/data/*" ]
条件ステートメント
@Enabled ディレクティブは、パラメータ値に基づいてステートメント全体を条件付きで包含または除外するときに使用します。
構文:
@Enabled: "parameterName" – このステートメントは、パラメータ値が「True」のときに含めます
@Enabled: "!parameterName" – このステートメントは、パラメータ値が「True」ではない (否定) のときに含めます
テンプレート:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "*" }, { "@Enabled": "ENABLE_S3_WRITE", "Effect": "Allow", "Action": ["s3:PutObject"], "Resource": "arn:aws:s3:::@{bucketName}/*" } ] }
パラメータ (ENABLE_S3_WRITE が「True」のとき)
[ { "Name": "bucketName", "Values": ["my-bucket"], "Type": "String" }, { "Name": "ENABLE_S3_WRITE", "Values": ["True"], "Type": "String" } ]
生成された結果
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "*" }, { "Effect": "Allow", "Action": ["s3:PutObject"], "Resource": "arn:aws:s3:::my-bucket/*" } ] }
パラメータ (ENABLE_S3_WRITE が「False」のとき)
[ { "Name": "bucketName", "Values": ["my-bucket"], "Type": "String" }, { "Name": "ENABLE_S3_WRITE", "Values": ["False"], "Type": "String" } ]
生成された結果
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "*" } ] }
ENABLE_S3_WRITE を「True」に設定すると条件ステートメントが含まれます。「False」に設定すると、ステートメントは生成されたポリシーから除外されます。
その他の例
一時委任でポリシーテンプレートを使用する際の、共通するパターンの例を以下にご紹介します。長期間有効なアクセス許可を提供するために、アクセス許可の境界を持つ IAM ロールを作成することに焦点をあて、特定のリソースに的を絞ったアクセス許可を設定するためのさまざまな戦略をご紹介します。こちらの例では、ARN プレフィックス、リソースのタグ付け、アクセス許可の境界の更新といった方法を使用することで、柔軟性とセキュリティの間のバランスを取っています。
例 1: 特定のリソースへのアクセスを長期間許可する
次のアクセス許可の境界は、「partner.com」の「SQSAccessorBoundary」として送信されます。
{ "Effect": "Allow", "Action": [ "sqs:DeleteMessage", "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } }
注記
これには、オープンなリソースポリシーを持つ他のアカウントの、キューへのアクセスを許可しないための、同一アカウント条件が含まれます。この境界は全顧客間で共有されテンプレート化ができないため、顧客のアカウント ID への直接参照は、含めることができません。
こちらはこのポリシーの初版であるため、ARN は以下のようになります。arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15
一時的なアクセス許可については、次のポリシーテンプレートが送信されます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sqs:ListQueues" ], "Resource": "arn:aws:sqs:*:*:*" }, { "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy" ], "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15" } } } ] }
例 2: ARN プレフィックスを使用する
アクセス許可の境界を使用すると、リソース ARN プレフィックスを指定してアクセスを制限することができます。
"Resource": "arn:aws:sqs:*:@{AccountId}:PartnerPrefix*"
それにより、アクセスできるのはこのプレフィックスを持つリソースのみに限定され、アクセス可能なリソースの範囲が狭められます。
例 3: リソースアクセスコントロールにタグを使用する
一時委任によるアクセスの最中にリソースにタグを付け、それらのタグを使って長期間のアクセス制御が行えます。
タグ付けされたリソースへのアクセスを許可するアクセス許可の境界
{ "Effect": "Allow", "Action": [ "sqs:DeleteMessage", "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "Null": { "aws:ResourceTag/ManagedByPartnerDotCom": "false" }, "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } }
作成時に新しいキューにタグを付けるポリシーテンプレート
{ "Effect": "Allow", "Action": [ "sqs:CreateQueue", "sqs:TagQueue" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "Null": { "aws:RequestTag/ManagedByPartnerDotCom": "false" } } }
既存のキューにタグ付けしてロールを作成するポリシーテンプレート
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sqs:TagQueue" ], "Resource": "arn:aws:sqs:*:@{AccountId}:@{QueueName}", "Condition": { "ForAllValues:StringEquals": { "aws:TagKeys": "ManagedByPartnerDotCom" } } }, { "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy" ], "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15" } } } ] }
この方法を使えば、顧客は自分がどのリソースに長期間アクセスできるのかを明示的に確認できます。
例 4: アクセス許可の境界を更新する
アクセス許可の境界を更新するには、新しいバージョンを新しい日付サフィックスに登録し、それを置き換えるアクセス許可をリクエストします。
追加のアクセス許可を使ってアクセス許可の境界を更新する
{ "Effect": "Allow", "Action": [ "sqs:DeleteMessage", "sqs:PurgeQueue", "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } }
第 2 版として、このポリシーには次の ARN が含まれます。arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_20
既存のロールのアクセス許可の境界を更新するポリシーテンプレート
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:PutRolePermissionsBoundary" ], "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_20" } } } ] }
顧客は、既存のロールのアクセス許可の境界を更新するには、この委任リクエストを承認する必要があります。
