IAM ロールマネージャーを Organizations の SCP で拒否してみた
はじめに
2026年8月12日、IAM ロールマネージャーの一般提供が始まりました。対応サービスのコンソールから、そのサービスが必要とするロールをテンプレートに沿って作成できる機能です。
機能の全体像や対応サービス、有効化の手順は、以下の既報記事で紹介しています。
統制を考えるうえで押さえておきたいのは、生成されるロールに AWS 管理ポリシー PowerUserAccess がアタッチされる場合があることです。このポリシーの主要なステートメントは、アクションを列挙していません。iam:*、organizations:*、account:* の3つを NotAction で除外し、Resource は * です。つまりこの3つ以外のすべての API を全リソースに許可し、新しい AWS サービスが追加されると自動的に許可対象へ入ります。ほかに iam:CreateServiceLinkedRole や organizations:DescribeOrganization など一部のアクションを明示的に許可するステートメントがあります。
公式ドキュメントの Manage access to role manager は、SCP で統制する例として3つを示しています。有効化を禁止するもの、Null 条件でロールテンプレート由来のロール作成を一括で拒否するもの、ロールマネージャー以外の経路でのロール作成を拒否するものです。
本記事では、有効化そのものを禁止する SCP と、権限の広い PowerUserRoleTemplate 由来のロール作成だけを拒否する SCP を、管理アカウントで作成し、OU にアタッチしました。メンバーアカウントで拒否が成立するかを確かめています。AWS Lambda 関数の作成時にロールマネージャーがどのように動作するかは、IAMの新機能「ロールマネージャ」で Lambda の実行ロール設定を省略してみたで扱っています。
検証内容
管理アカウントで作成した SCP を検証用の OU にアタッチし、配下のメンバーアカウントから AWS CLI で操作しました。
有効化そのものを禁止する
ロールマネージャーの有効化は iam:PutAccountProperties で行い、RoleManager ネームスペースを対象に指定します。公式ドキュメントのサンプル SCP をそのまま使いました。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyRoleManagerEnablement",
"Effect": "Deny",
"Action": "iam:PutAccountProperties",
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"iam:AccountPropertyNamespaces": "RoleManager"
}
}
}
]
}
この状態でメンバーアカウントから有効化を試みると、拒否されました。
$ aws iam put-account-properties --properties RoleManager/Enabled=true
An error occurred (AccessDenied) when calling the PutAccountProperties operation:
User: arn:aws:sts::444455556666:assumed-role/OrganizationAccountAccessRole/role-manager-scp-verify
is not authorized to perform: iam:PutAccountProperties on resource: *
with an explicit deny in a service control policy:
arn:aws:organizations::111122223333:policy/o-exampleorgid/service_control_policy/p-example11111
メッセージには with an explicit deny in a service control policy と拒否元のポリシー ARN が含まれています。そのため、メンバーアカウント側でもどのポリシーで止まったのかを判別できます。
テンプレート単位で拒否する
有効化を許可したまま、作成できるロールをテンプレート単位で制限する SCP の記述方法もあります。条件キー iam:RoleTemplateARN は、先に挙げた Manage access to role manager の SCP 例でも使われています。ただし、3つの例のうち、テンプレートを指定して制限するものはありません。ここでは、StringLike 条件で PowerUserRoleTemplate にだけ一致するよう指定しました。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyPowerUserRoleTemplate",
"Effect": "Deny",
"Action": "iam:*",
"Resource": "*",
"Condition": {
"StringLike": {
"iam:RoleTemplateARN": "arn:aws:iam::aws:role-template/iam.amazonaws.com/PowerUserRoleTemplate*"
}
}
}
]
}
この SCP を適用した状態で、aws iam acquire-role --template-arn <テンプレートの ARN> を3パターン実行しました。
| 呼び出したテンプレート | 結果 |
|---|---|
PowerUserRoleTemplate:1 |
AccessDenied |
PowerUserRoleTemplate-v1 |
AccessDenied |
AWSSecretsManagerRotationRoleTemplate:1 |
成功（ロール作成） |
上2行は同じテンプレートを別の表記で指定したものです。エラーメッセージには、AcquireRole ではなく、内部で実行される iam:CreateRole が拒否されたことが示されます。次は PowerUserRoleTemplate:1 を指定したときのメッセージです。
An error occurred (AccessDenied) when calling the AcquireRole operation:
User: arn:aws:sts::444455556666:assumed-role/OrganizationAccountAccessRole/rm-template-scp-verify
is not authorized to perform: iam:CreateRole on resource: role/PowerUserRole
with an explicit deny in a service control policy:
arn:aws:organizations::111122223333:policy/o-exampleorgid/service_control_policy/p-example22222
この SCP は PowerUserRoleTemplate を指定した呼び出しを拒否します。このテンプレートは Elastic Beanstalk、EventBridge、Lambda、Step Functions で共有されているため、iam:RoleTemplateARN だけではサービス単位の切り分けはできません。対応関係は IAM ユーザーガイドのロールテンプレート一覧に記載されています。
SCP の末尾のワイルドカードは、CloudTrail に記録される PowerUserRoleTemplate-v1 と、生成されたロールの SourceRoleTemplate やドキュメントに示される PowerUserRoleTemplate:1 の両方に一致します。両者は同じ TemplateVersionId を返す、同一のテンプレートバージョンです（関連記事での実測）。
バージョンは2026年8月時点のものです。PowerUserRoleTemplate と AWSSecretsManagerRotationRoleTemplate はいずれも :1、PowerUserAccess は v12 です。
AWSSecretsManagerRotationRoleTemplate 由来のロールには、管理ポリシーではなく SecretRotationPermissionPolicy が付与されていました。このロールでは、シークレットの対象、種類、呼び出し元アカウントを条件で絞っています。一方、PowerUserRoleTemplate で付与される PowerUserAccess の主な許可には、対象リソースや用途を絞る条件がありません。テンプレートごとに権限設計が異なるため、内容を確認して制御対象を決める必要があります。
許可された Secrets Manager 向けロールのポリシー
テンプレートは信頼ポリシーに aws:SourceAccount 条件を設定していました。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SecretsManagerPrincipalAccess",
"Effect": "Allow",
"Principal": {
"Service": "secretsmanager.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "444455556666"
}
}
}
]
}
インラインポリシーでは、シークレット操作の対象をアカウント内のシークレット ARN に絞っています。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowRotationAccessGeneric",
"Effect": "Allow",
"Action": [
"secretsmanager:DescribeSecret",
"secretsmanager:GetSecretValue",
"secretsmanager:PutSecretValue",
"secretsmanager:UpdateSecretVersionStage"
],
"Resource": "arn:aws:secretsmanager:us-east-1:444455556666:secret:*",
"Condition": {
"StringEquals": {
"secretsmanager:resource/Type": "AWS::RDS::DBInstance"
}
}
},
{
"Sid": "AllowPasswordGenerationAccessAdmin",
"Effect": "Allow",
"Action": [
"secretsmanager:GetRandomPassword"
],
"Resource": "*"
}
]
}
まとめ
IAM ロールマネージャーは、有効化そのものを止めるか、テンプレート単位で作成できるロールを選ぶかの2段で統制できます。
ロールマネージャーにより、必要なロールの設定を省略できる開発用アカウントがない場合は、有効化そのものを SCP で禁止する方法がシンプルです。
組織でロールマネージャーの利用を認める場合は、利用を認めるアカウントを専用の例外 OU に配置します。それ以外の OU では、SCP によりロールマネージャーの有効化を原則として禁止します。例外 OU でも、意図せず強い権限を持つロールが利用されることを避けるため、テンプレート単位の制御を検討することをおすすめします。
