developersIO
IAM Identity Center の委任管理者に触らせたくないアカウントを SCP で守ってみた

IAM Identity Center の委任管理者に触らせたくないアカウントを SCP で守ってみた

IAM Identity Center の委任管理者機能を使う際に、保護したいアカウントへのアクセスを SCP で制限してみました。
Service Control PolicyAWS OrganizationsセキュリティAWS
2026.09.28

はじめに

みなさん IAM Identity Center の委任管理者を使われているでしょうか。
マネジメントアカウントへのアクセスを絞るために、Identity Center の管理だけを別のメンバーアカウントに任せられる機能です。

Identity Center の運用を委任管理者に任せる構成を組んでいたのですが、一部のアカウントだけは Identity Center からのアクセスを拒否したいケースがありました。
委任管理者は基本的に、マネジメントアカウント以外のすべてのアカウントに Permission Set を割り当てられます。

そこで、委任先には触らせたくないアカウントへのアクセス権を、委任管理者が作れないよう SCP で制限してみました。

前提とする構成

登場するアカウントを先に整理します。

呼称 役割
管理アカウント AWS Organizations のマネジメントアカウント。Identity Center のインスタンスもここにある。以降は管理アカウントと表記する
委任アカウント Identity Center の委任管理者として登録するアカウント。専用の OU に隔離する
保護対象アカウント 委任先には触らせたくないアカウント
メンバーアカウント 委任先が自由に Permission Set を割り当ててよい通常のアカウント

保護対象アカウントは Identity Center で管理しないアカウントとして定義します。（Permission Set の割り当てを作成させない）

そのほかの前提です。

  • Identity Center は組織インスタンスを使う
  • 委任アカウントを専用の OU（ここでは IdcOU と呼びます）に隔離し、OU に対して SCP をアタッチする
  • Identity Center の identity source は Identity Center ディレクトリ。ユーザーとグループを Identity Center 内で直接管理する

図にするとこうなります。

idc-delegated-admin-scp-org-structure.drawio.png

利用者のプリンシパル ARN は方式によって形が変わります。SCP の除外条件は、この形を意識して書きます。

方式 プリンシパル ARN
IAM ユーザー + スイッチロール arn:aws:iam::<account>:role/<管理用ロール名>
Identity Center ユーザー arn:aws:iam::<account>:role/aws-reserved/sso.amazonaws.com/<region>/AWSReservedSSO_<PS名>_<hash>

AWSReservedSSO_ のロール ARN は identity source のリージョンによってリージョン部の有無が変わります。
このあたりはすでに詳しい記事があるので、そちらを参照してください。

https://dev.classmethod.jp/articles/iam-identity-center-scp-awsreservedsso-role-arn/

委任アカウントを Identity Center 専用にする SCP

まず、委任アカウントが Identity Center の管理以外の用途に使われないよう縛ります。
Deny と NotAction を組み合わせた allowlist 型の SCP です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllOutsideIdentityCenter",
      "Effect": "Deny",
      "NotAction": [
        "sso:*",
        "sso-directory:*",
        "identitystore:*",
        "identitystore-auth:*",
        "identity-sync:*",
        "sso-oauth:*",
        "organizations:Describe*",
        "organizations:List*",
        "iam:Get*",
        "iam:List*",
        "sts:GetCallerIdentity",
        "access-analyzer:ValidatePolicy",
        "signin:CreateTrustedIdentityPropagationApplicationForConsole",
        "signin:ListTrustedIdentityPropagationApplicationsForConsole",
        "ds:Describe*"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/ops-*"
          ]
        }
      }
    }
  ]
}

NotAction に書いたアクション以外を拒否しつつ、Condition で運用側のロールを除外しています。
この 2 つは AND で評価されるので、「除外条件に一致しないプリンシパルが、allowlist にないアクションを叩いたら拒否」という動きになります。

Identity Center コンソールの全画面を網羅的に叩いたわけではないので、使う機能によっては足りないアクションが出る可能性もあります。

保護対象アカウントへの割り当てを拒否する SCP

次が本題です。委任先には Identity Center の管理を任せますが、保護対象アカウントへの割り当てだけは作らせません。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAssignmentToProtectedAccounts",
      "Effect": "Deny",
      "Action": [
        "sso:CreateAccountAssignment",
        "sso:DeleteAccountAssignment",
        "sso:ProvisionPermissionSet"
      ],
      "Resource": [
        "arn:aws:sso:::account/111122223333",
        "arn:aws:sso:::account/444455556666"
      ],
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/ops-*"
          ]
        }
      }
    }
  ]
}

Resource には arn:aws:sso:::account/<account-id> 形式で保護対象アカウントを指定します。
管理アカウントには委任管理者からもともと割り当てできないため、ここで指定しなくても拒否されます。

保護対象アカウントには割り当てがない状態を想定しています。
それでも、割り当てが残っていた場合に Permission Set の編集から再プロビジョニングされないよう、sso:ProvisionPermissionSet も拒否しています。

Permission Set のポリシー側で制限するのでは足りない

同じことを Permission Set のインラインポリシーで実現する方法も考えられます。
委任管理者に渡す Permission Set の中に「このアカウントには割り当てるな」と書く形です。

ただ、これは成立しません。
委任管理者は sso:* を持っているので、sso:PutInlinePolicyToPermissionSet で自分の Permission Set を編集して制限を外せてしまいます。

AWS Security Blog でも、すべての Permission Set を編集できる権限を渡すと自分の Permission Set も編集できてしまう点に触れられています。

https://aws.amazon.com/blogs/security/delegating-permission-set-management-and-account-assignment-in-aws-iam-identity-center/

SCP でリソース ARN を直接指定して拒否すれば、委任管理者は SCP そのものを変更できないので改ざんされません。

確かめてみる

ポリシーを書いたら実際に叩いて確認します。

まず管理アカウントで SCP を作成し、委任アカウントを隔離した OU にアタッチします。

aws organizations create-policy \
  --name DenyAssignmentToProtectedAccounts \
  --type SERVICE_CONTROL_POLICY \
  --content file://scp-protected-accounts.json \
  --profile management

aws organizations attach-policy \
  --policy-id p-xxxxxxxx \
  --target-id ou-xxxx-xxxxxxxx \
  --profile management

次に委任アカウントへ検証用の IAM ロールを作ります。
名前は除外条件に一致しないものを選びます。ここでは VerifyRole としました。

aws iam create-role \
  --role-name VerifyRole \
  --assume-role-policy-document file://trust-policy.json \
  --profile delegated-admin

aws iam attach-role-policy \
  --role-name VerifyRole \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess \
  --profile delegated-admin

AdministratorAccess を付けているのは意図的です。
IAM 側を全許可にしておくと、拒否されたときに SCP が原因だと切り分けられます。
SCP は AdministratorAccess でも上書きできないので、この作り方が成立します。

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

割り当てを試す前に、管理アカウントで Identity Center のインスタンス ARN を取得しておきます。
Identity Center を有効化しているリージョンを指定します。

> aws sso-admin list-instances --region ap-northeast-1 --profile management

{
    "Instances": [
        {
            "InstanceArn": "arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx",
            "IdentityStoreId": "d-xxxxxxxxxx",
            "OwnerAccountId": "999988887777",
            "Status": "ACTIVE"
        }
    ]
}

続いて、委任アカウントで作った VerifyRole に AssumeRole します。

aws sts assume-role \
  --role-arn arn:aws:iam::777788889999:role/VerifyRole \
  --role-session-name verify \
  --profile delegated-admin

返ってきた一時クレデンシャルを環境変数にエクスポートしてから、保護対象アカウントへの割り当てを叩きます。
--region は Identity Center を有効化しているリージョンに揃えます。

export AWS_ACCESS_KEY_ID=<AccessKeyId>
export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
export AWS_SESSION_TOKEN=<SessionToken>

> aws sso-admin create-account-assignment \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx \
  --target-id 444455556666 \
  --target-type AWS_ACCOUNT \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxxxxxxxxxx/ps-xxxxxxxxxxxxxxxx \
  --principal-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --principal-type USER \
  --region ap-northeast-1

An error occurred (AccessDeniedException) when calling the CreateAccountAssignment operation:
User: arn:aws:sts::777788889999:assumed-role/VerifyRole/verify is not authorized to perform:
sso:CreateAccountAssignment on resource: arn:aws:sso:::account/444455556666
with an explicit deny in a service control policy:
arn:aws:organizations::999988887777:policy/o-xxxxxxxxxx/service_control_policy/p-xxxxxxxx

狙いどおり拒否されました。

まとめ

委任アカウントを Identity Center 専用に縛る SCP と、保護対象アカウントへの割り当てを拒否する SCP の 2 段構成で、委任先のスコープを絞れました。
Permission Set のインラインポリシーではなく SCP に制限を置いたことで、委任管理者の側からは外せない形になっています。

ただし、この構成は「保護対象アカウントへの割り当てをゼロにしておく」という前提の上に成り立っています。
保護対象アカウントにグループへの割り当てが残っていると、委任管理者はそのグループにユーザーを追加するだけでアクセスできてしまいます。

グループへのメンバー追加を絞る方法は、次の記事が参考になります。

https://dev.classmethod.jp/articles/identity-center-restrict-group-addition/

Identity Center からのアクセス対象外にしたい AWS アカウントが出てきたときの参考にしてください。

以上、鈴木純がお送りしました。

参考

そのマルチアカウント運用、気合いで支えていませんか

Organizations や Control Tower で土台は作れても、アカウントもポリシーも増えるほど、運用は「詳しい一人」に寄りかかっていく。属人化が限界を迎える前に、組織として回す仕組み＝CCoEへ。5,600社の支援から得た立ち上げの型を、無料資料にまとめました。

CCoE総合支援

組織で回す仕組みの資料をもらう

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

IAM Identity Center の許可セットで禁止した操作、自作ロールなら回避できる？ SCP で権限昇格を防げるか検証してみた
板倉舞
2026.07.02
IAM Identity Center ユーザーのユーザー ID を使用して特定アクションを制限する SCP を作ってみた
板倉舞
2025.08.13
AWS IAM Identity Center の特定の許可セットに対応するロールだけを SCP の Deny 対象から除外するときの ARN 指定方法
平井裕二
2026.05.12
IAM ロールマネージャーを Organizations の SCP で拒否してみた
suzuki.ryo
2026.08.14