こんにちはますのです。
AWSを活用する開発現場において、インフラ管理者と開発チームの間で以下のようなバトルが起きていることと思います。

最小権限で運用したい vs 開発効率を重視したい

ｵﾔｵﾔ、IAMのベストプラクティスも知らぬ間に変わっていますね。

IAMユーザ：非推奨
IAM Identity Center：推奨

直近のベストプラクティスに沿った場合、どういった設計にすると皆が幸せになれるのか？を考えました。
この記事で少しでもハッピーな組織が増えるとｲｲﾅｧ。と思いつつ参りましょう。

本記事は「Security-JAWS【第39回】_IAMスペシャル」で登壇した際の資料をベースに作成しています。
https://www.docswell.com/s/masno_soy/KYVJ89-2025-11-08-050406

概要

IAM Identity CenterのABAC（属性ベースアクセス制御）を使っていく
タグによって触れるリソースを制限していく
開発チームにIAM管理毎委譲してしまう

利用するAWSサービスと概要図

セキュアな権限委譲アーキテクチャを実現するため、以下の機能を組み合わせます。

IAM Identity Center（内蔵 IdP）：ユーザー管理とタグ付けの起点
ABAC（属性ベースアクセス制御）：aws:PrincipalTag を用いた動的な認可
Permissions Boundary（アクセス許可の境界）：委譲した権限が悪用されないための「絶対的な壁」

セキュアな IAM 権限委譲アーキテクチャの設計

今回の設計では、開発チーム内の役割を「DevAdmin（管理者）」と「Member（一般メンバー）」の2つに分割し、タグの動的比較制御を用いたガードレールを実装します。

1. IAM Identity Center と ABAC によるリソース分離

IAM Identity Center のユーザー属性（タグ）を活用し、ABAC（Attribute-Based Access Control）を実装します。
これにより、「プロジェクトAのタグを持つユーザーは、プロジェクトAのタグが付いたリソースしか操作できない」といった動的なアクセス制御が可能になります。開発チームが他のプロジェクトのリソースを誤って操作・削除してしまうリスクを根本から防ぎます。

ABACに利用可能なIdPの属性は以下を参考にしました。

https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/attributemappingsconcept.html#supportedidpattributes

2. Permissions Boundary によるガードレール

開発チームの管理者（DevAdmin）に対して IAM ロールの作成権限を委譲します。しかし、自由にロールを作れる状態では、DevAdmin が自分自身に AdministratorAccess を付与したロールを作成し、権限昇格してしまう危険性があります。

そこで、ロールを作成する際の条件として 「特定の Permissions Boundary（アクセス許可の境界）をアタッチしなければ作成できない」 という制限をかけます。これにより、開発者が自由に IAM ロールを作成・編集しても、インフラ管理者が Permissions Boundary で定めた「境界」を超える権限は決して発揮できなくなります。

役割に応じた 5つのカスタムポリシー

ポリシー名	役割	付与対象
① DevRole Protection Policy	IAM作成・管理時にPermissions Boundary（許可の境界）の設定を強制し、境界用ポリシーの変更・削除を保護する。	DevAdmin
② IAM ABAC Policy	自身のチームタグと一致するチーム専用IAMロール・ポリシーのみ作成・変更管理を許可する。	DevAdmin
③ Resource ABAC Policy	IAM以外のAWSリソースについて、自身のチームタグと一致するリソースのみ作成・管理を許可する。	DevAdmin / Member
④ DevTeam Boundary Policy	開発者ユーザー自身に対するガードレール。セキュリティ関連や管理系操作を明示的に拒否し、それ以外の開発操作を許可する。	DevAdmin / Member
⑤ DevRole Boundary Policy	開発管理者が作成する「チーム専用IAMロール」が持てる最大権限（上限値）を定義するガードレール（Permissions Boundaryとして使用）。	開発者が作る全ロール

各ポリシーの詳細は以下を参考にご覧ください。
https://github.com/masno-soy/secjaws39-iam-for-devteams-json-list

実装のポイント（ポリシーの記述例）

実装のポイント：ABAC判定を実現するタグの動的比較

ABACを実現するためのコアとなるのが、Condition 句を用いたタグの動的比較です。
IAM作成時やリソース変更時に、以下のタグ値を比較することで、「自分のチームのリソースしか触れない」という制御を実現しています。

aws:RequestTag：これから作成・付与しようとしているタグの値
aws:PrincipalTag：操作をしているユーザ（IAM Identity Center）の属性タグの値
aws:ResourceTag：既存リソースに設定されているタグの値

IAM ABAC Policyの実装例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateRole",
                "iam:PutRolePolicy"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/Team": "${aws:PrincipalTag/Team}"
                },
                "StringLike": {
                    "iam:PermissionsBoundary": "arn:aws:iam::*:policy/dev-team-boundary-policy"
                }
            }
        }
    ]
}

このように ${aws:PrincipalTag/Team} という変数を使うことで、TeamAのユーザはTeamAのタグがついたリソースのみ、TeamBのユーザはTeamBのタグがついたリソースのみを操作できるようになり、チーム数が増えてもポリシーを1つに集約することが可能です。

記述の解説

${aws:PrincipalTag/Team}: 操作しているユーザー（Principal）に付与されている Team タグの値を動的に参照します。
iam:PermissionsBoundary: この条件を入れることで、ロール作成時に dev-team-boundary-policy を指定しない限り、APIリクエストが拒否されます。

まとめ

IAM Identity Center の ABAC と Permissions Boundary を適切に組み合わせることで、「開発者が自身で IAM ロールを作成・管理」と「管理者の想定を超えないガバナンス」を両立させることができます。

IAM の設計や権限移譲は複雑になりがちですが、一度強固なガードレールを敷いてしまえば、インフラ管理者の運用負荷は大きく下がり、開発チームも待ち時間なく開発に専念できるようになります。

本記事が、AWS アカウントの権限管理に悩む皆様の参考になれば幸いです。

おまけ

似たようなことを導入したよ！をCOOP札幌のNaomiさんの登壇資料でお見かけしました。すごい。

実際にわたしも導入して使い勝手を試してみたい所存です。