こんにちはますのです。
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の属性は以下を参考にしました。
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さんの登壇資料でお見かけしました。すごい。
実際にわたしも導入して使い勝手を試してみたい所存です。