アカウントが20を超え、権限の申請が毎日来る。事業部ごとに IAM ユーザーが作られ、「とりあえず管理者権限で」と渡したロールが残っている。監査からは「組織の外にデータが出ない保証は」と聞かれ、開発チームからは「ロールくらい自分で作らせてほしい」と言われる。どれも権限の話ですが、1つのポリシーで全部を解こうとすると、誰も読めないポリシーが残ります。
AWS の権限は、組織・アカウント・人・セッションという層ごとに別の仕組みで絞れます。この記事は、ポリシーの評価の順番を土台に、どの要件をどの層で絞るかを判断の順番として整理します。
この記事の結論
- マルチアカウントの権限は、組織の上限（SCP・RCP）、人に配る権限（許可セット）、委任の上限（権限境界）、セッションの絞り込みの層に分け、1か所に全部を載せないように設計します。
- SCP と RCP は権限を与えず上限だけを決め、管理アカウントには効かないので、管理アカウントでワークロードを動かさないことが前提になります。
- 人の権限は IAM Identity Center の許可セットで職務ごとに配り、アカウントごとの IAM ユーザーと長期のアクセスキーを作らない形にします。
- チームや案件が増え続ける組織では、ABAC（人の属性とリソースのタグの一致）で許可セットの数を増やさずに範囲を分けられます。
- 作った権限は IAM Access Analyzer で外部への公開と使われていない権限を洗い出し、継続して減らします。
権限の設計で先に決める要件とは
仕組みを選ぶ前に、次の要件を書き出します。同じ「権限を絞りたい」でも、要件によって効く層が違います。
| 軸 | 何を確かめるか | 答えが変えるもの |
|---|---|---|
| 規模 | アカウントの数、人の数、チームと案件の増え方 | 職務ごとの許可セットで足りるか、ABAC が要るか |
| 規制 | 使ってよいリージョン、組織の外への共有の禁止、ログの保全 | SCP・RCP に何を書くか、データの境界をどこに引くか |
| 委任 | 各チームにどこまで任せたいか（ロールの作成、ポリシーの編集） | 権限境界を使うか、中央のチームが代行するか |
| 外部との関係 | ベンダーや SaaS にアカウントを見せるか | ロールの信頼ポリシーと外部 ID、RCP の例外 |
| 運用体制 | ポリシーを書いて見直す人がいるか、変更を CI で検査できるか | 中央で持つポリシーの量、Access Analyzer の使い方 |
AWS Well-Architected フレームワークのセキュリティの柱は、権限の管理について「最小権限を与える」「権限のガードレールを組織で定める」「継続的に権限を減らす」「第三者とは安全に共有する」をベストプラクティスとして挙げています。この記事の章立ても、この順に沿っています。
DESIGN INPUTS先に書き出す要件
同じ「絞りたい」でも効く層は要件で変わる
-
1.規模と増え方 — アカウント・人・案件の数
職務ごとの許可セットで足りるか、ABAC が要るか
-
2.規制 — リージョン、組織の外への共有、ログの保全
SCP と RCP に何を書くか。データの境界をどこに引くか
-
3.委任 — 各チームにどこまで任せるか
ロールの作成を任せるなら権限境界を必須にする
-
4.外部と体制 — ベンダーに見せるか、誰が見直すか
外部 ID 付きのロール、Access Analyzer と CI の検査
ポリシーはどの順で評価され、どこで絞るのか?
AWS はリクエストごとに、関係するすべてのポリシーを合わせて評価します。既定は拒否（暗黙の拒否）で、どこかに当てはまる明示的な拒否が1つでもあれば、ほかにどんな許可があっても拒否になります。
同じアカウントの中では、アイデンティティベースのポリシーとリソースベースのポリシーの許可は「足し算」で、どちらかが許せば許可の候補になります。一方、SCP・RCP・権限境界・セッションポリシーは「上限」で、上限の外にある操作は許可が書いてあっても通りません。組織のメンバーアカウントでは、プリンシパルのポリシー・SCP・RCP のすべてが許した操作だけが実行できます。
| 層 | 何に効くか | 権限を与えるか | 誰が持つか | 絞りたいもの |
|---|---|---|---|---|
| SCP | メンバーアカウントのユーザーとロール | 与えない（上限） | 組織の管理者 | 使ってよいリージョン、止めてはいけないログ、組織からの離脱 |
| RCP | メンバーアカウントのリソース | 与えない（上限） | 組織の管理者 | 組織の外のプリンシパルからのアクセス |
| 許可セット | 人が各アカウントで引き受けるロール | 与える | 中央の ID 管理者 | 職務ごとに要る操作 |
| 権限境界 | 特定のユーザーとロール | 与えない（上限） | 委任する側 | 委任先が作るロールの最大の権限 |
| セッションポリシー | そのセッションだけ | 与えない（重なりに絞る） | ロールを引き受ける側 | テナントや処理ごとの範囲 |
| リソースベースのポリシー | そのリソース | 与える | リソースの所有者 | 他アカウントからの到達 |
WHERE TO LIMITどこで絞るか
広い層では止めることだけを、狭い層で与えることを書く
-
組織
SCP と RCP — メンバーアカウントの上限
リージョン・ログの保全・組織の外からのアクセス。権限は与えない
-
人
許可セット — 職務ごとに与える
Identity Center が各アカウントにロールを作る。ABAC で数を抑える
-
委任
権限境界 — 任せた先の上限
ロールの作成を境界の付与つきでだけ許す
-
1回
セッションポリシー — その回だけ絞る
テナントや処理ごとに、ロールとの重なりに絞る
設計の原則は、広く効く層ほど「止めること」だけを書き、狭い層で「与えること」を書くです。組織のガードレールに業務の細かい許可を書き込むと、例外のたびに組織全体のポリシーを変えることになります。逆に、リージョンの制限のような組織の約束事を各許可セットに書くと、1つ書き漏らしただけで穴になります。
クロスアカウントのアクセスは足し算になりません。アカウント A のロールがアカウント B のバケットを読むには、A 側のアイデンティティベースのポリシーと、B 側のリソースベースのポリシー（または B 側のロールの信頼ポリシー）の両方が許す必要があります。「片方だけ直して拒否が消えない」ときは、まずこの両側を確かめます。
組織のガードレール ─ SCP と RCP で何を止めるか
SCP はルート・OU・アカウントに付けられ、配下に継承されます。よく使うのは次のような「組織としての約束」です。
- 承認したリージョン以外の操作を拒否する（グローバルサービスは除外する。条件キーは aws:RequestedRegion）
- CloudTrail の証跡の停止と削除を拒否する
- 組織からの離脱を拒否する
- 作成時にコスト配分のタグが無いリクエストを拒否する（aws:RequestTag と Null 条件）
RCP は、メンバーアカウントのリソースに許される操作の上限を組織で一元的に決めます。代表的な使い方は、aws:PrincipalOrgID が自組織でないリクエストを拒否して、バケットポリシーを誤って書き換えても組織の外から読めないようにすることです。SCP が「中の人が外で何をするか」を止めるのに対し、RCP は「外の人が中のリソースに何をするか」を止めます。両方を組み合わせると、データの境界（どこからどこへデータが出入りできるか）を組織の層で引けます。
SCP と RCP は管理アカウントには効きません。ルートに SCP を付けても、管理アカウントの中では制限がかかりません。管理アカウントは組織の管理と請求に限り、ワークロードはメンバーアカウントに置く、が前提になります。セキュリティサービスの管理も、委任管理者として専用のアカウントに移すと管理アカウントに入る人を減らせます。
AWS Control Tower を使う場合は、リージョン拒否のコントロールが SCP として OU に適用されます。データの置き場所に規制がある組織では、ここで使ってよいリージョンを最初に決めておくと、後から「別のリージョンに作られていた」という事故を防げます。
運用の注意として、新しい SCP はまず検証用の OU で試してから本番の OU に付けます。拒否の範囲を広げすぎると、障害対応に必要な操作まで止まるからです。セキュリティの柱も、緊急時にだけ使うアクセスの手順を平時に決めておくことを求めています。
CHECK 1ここまでの確認
SCP の許可リストに入っていないサービスを、そのアカウントで AdministratorAccess を持つロールが呼び出すとどうなる?
答えと解説
答え: 2. SCP の上限の外なので拒否される
SCP は権限を与えず、使える操作の上限を決めます。有効な権限は SCP とアイデンティティベースのポリシーの両方が許したものだけです（「ポリシーはどの順で評価され、どこで絞るのか」と「組織のガードレール」の章）。
人の権限 ─ 許可セットと ABAC で規模に耐える
人の権限は IAM Identity Center に集めます。社内の IdP を ID ソースにして SCIM でユーザーとグループを同期し、グループにアカウントと許可セットを割り当てます。許可セットはアカウントに配る権限のひな形で、割り当てると各アカウントに Identity Center が管理する IAM ロールが作られます。アカウントごとに IAM ユーザーを作る形と違い、退職や異動は IdP 側で止めれば全アカウントに反映されます。
許可セットは人ごとではなく職務ごとに作ります。読み取り専用・開発者・運用・セキュリティ監査のように役割で分け、本番と開発の違いはどのアカウントに割り当てるかで表します。1人に複数の許可セットを割り当てることもできます。
増え続けるなら ABAC
案件ごと・チームごとに許可セットを作ると、案件が増えるたびに許可セットと割り当てが増えます。ここで効くのが ABAC（属性ベースのアクセス制御）です。Identity Center の「アクセスコントロールの属性」で IdP のユーザー属性（部署・案件など）を選ぶと、サインインのときにセッションタグとして渡されます。許可セットのポリシーで aws:PrincipalTag と aws:ResourceTag の一致を条件にすれば、1つの許可セットで「自分の案件のタグが付いたリソースだけ」を扱えます。
| 観点 | 職務ごとの許可セット（RBAC） | ABAC（タグの一致） |
|---|---|---|
| 許可セットの数 | 職務×範囲の数だけ増える | 職務の数で止まる |
| 新しいリソース | ポリシーの更新が要る | 正しいタグを付ければ対象になる |
| 前提 | 特に無い | タグの付け方の統制（必須化・変更の禁止） |
| 向く組織 | チームや案件が少なく、増え方がゆっくり | チームや案件が増え続ける |
ABAC は「タグが正しいこと」に権限を預ける設計です。利用者が自分でリソースのタグを書き換えられると、他の案件のリソースに届いてしまいます。タグポリシーで表記を揃え、SCP でタグの付与を必須にし、許可を決めるタグの変更は限られた役割にしか許さない、という統制と組にして使います。
SCALE AND DELEGATION人の権限の配り方
増え方と任せ方の2軸で配り方が決まる
チームに任せたい範囲 →
権限境界で委任
チームは少ないが、ロールの作成は任せたい
権限境界＋ABAC
増え続け、任せたい。タグの統制が前提
職務ごとの許可セット
少なく、中央で配る。まずはここから
ABAC の許可セット
増え続けるが、ロールは中央で持つ
チームと案件の増え方 →
READ ALSO — 学習中向け・段2 構成
IAM Identity Center とは何か｜複数アカウントへのサインインを1か所にまとめ、許可セットで権限を配る
CHECK 2ここまでの確認
案件ごとに許可セットを作る運用が限界になった。許可セットを増やさずに案件ごとの範囲を分ける方法は?
答えと解説
答え: 2. ユーザーの属性をセッションタグとして渡し、リソースのタグと一致したときだけ許す
ABAC は、人の属性（aws:PrincipalTag）とリソースのタグ（aws:ResourceTag）の一致で許可を決めます。案件が増えてもタグを付けるだけで済みます（「人の権限」の章）。
委任とクロスアカウント ─ 権限境界とロールの信頼関係
権限境界で「任せても昇格させない」
開発チームにロールの作成を任せたいが、自分より強いロールを作られては困る。この要件には権限境界を使います。権限境界は、アイデンティティベースのポリシーがそのユーザーやロールに与えられる最大の権限を決める管理ポリシーで、それ自体は権限を与えません。
委任の形は次のとおりです。開発チームの iam:CreateRole を、決めた権限境界を付ける場合だけ許します（条件キーは iam:PermissionsBoundary）。あわせて、境界の付け外しと、境界に使うポリシー自体の編集を拒否します。こうすると、開発チームが作るロールは境界の内側にしか権限を持てません。なお、権限境界はリソースベースのポリシーが与える権限の上限にはならない点に注意します。
ロールの信頼関係と外部 ID
ロールの信頼ポリシーは「誰がこのロールを引き受けられるか」を決めます。組織内のクロスアカウントでは、引き受ける側のアカウントで sts:AssumeRole を許し、ロールの信頼ポリシーで相手を指定します。
第三者（監視やコスト分析の SaaS など）にロールを引き受けさせるときは、混乱した代理（confused deputy）の問題に備えます。事業者が多くの顧客のロールを引き受ける場合、別の顧客が自社のロールの ARN を事業者に渡すと、事業者経由で自社のアカウントに届いてしまうおそれがあるためです。信頼ポリシーで顧客ごとに一意の外部 ID（sts:ExternalId）を条件にすると、この経路を塞げます。AWS のサービスにロールを渡す場合は、aws:SourceArn と aws:SourceAccount で要求元を絞ります。
マルチテナントのアプリケーションが共通のロールを使うときは、ロールを引き受けるときにテナントの範囲だけを許すセッションポリシーを渡すと、そのセッションの権限をロールとの重なりに絞れます。
CHECK 3ここまでの確認
開発チームに Lambda 用のロールを自分で作らせつつ、自分より強いロールを作らせないためには?
答えと解説
答え: 1. ロールの作成を、決めた権限境界を付ける場合だけ許し、境界の変更は拒否する
権限境界はアイデンティティベースのポリシーが与えられる上限です。iam:PermissionsBoundary の条件で境界の付与を必須にすると、委任しても昇格を防げます（「委任とクロスアカウント」の章）。
作った権限をどう減らし続けるか?
権限は、作った日から余り始めます。セキュリティの柱も、不要な権限と使われていない ID を継続して見つけて外すことを求めています。そのための道具が IAM Access Analyzer です。
| 使い方 | 分かること | 設計のどこで使うか |
|---|---|---|
| 外部アクセスのアナライザー（信頼ゾーン＝組織） | 組織の外や匿名から届くバケット・キー・ロール | RCP の効き目の確認、共有の棚卸し |
| 未使用アクセスのアナライザー | 使われていないロール・アクセスキー・パスワード・権限 | 許可セットとロールの定期的な見直し |
| ポリシーの生成 | CloudTrail の記録から、実際に使った操作だけのたたき台 | 広すぎるロールを最小権限に寄せる |
| カスタムポリシーチェック | 変更が新たなアクセスを許すか | CI でデプロイ前に止める |
マルチアカウントの権限でやってはいけないこと
- 管理アカウントでワークロードを動かす（SCP が効かない場所に本番を置くことになる）
- アカウントごとに IAM ユーザーと長期のアクセスキーを作って人に配る
- 権限境界を付けずにロールの作成を委任する
- 第三者に引き受けさせるロールに外部 ID の条件を付けない
判断の順番
- 要件を書く。 規模と増え方・規制・委任・外部との関係・運用体制。
- 組織の上限を決める。 SCP で中の人が外でしてはいけないことを、RCP で外の人が中のリソースにしてはいけないことを止める。検証用の OU で試してから広げる。
- 人の権限を配る。 Identity Center の許可セットを職務ごとに作り、グループに割り当てる。増え続けるなら ABAC とタグの統制を組にする。
- 委任の上限を決める。 ロールの作成を任せるなら権限境界を必須にする。第三者には外部 ID を付けたロールで渡す。
- 減らし続ける。 Access Analyzer の検出結果を定期的に見て、未使用の権限を外し、ポリシーの変更を CI で検査する。
どの層で絞るかにも得るものと捨てるものがあります。組織の層で止めるほど漏れは減りますが、例外の申請が中央に集まります。チームに委任するほど速く動けますが、境界と監査の仕組みが要ります。アカウントの分け方そのものは、次に読む記事で扱います。
参照ソース
- Policy evaluation logic（IAM ユーザーガイド） と Cross-account policy evaluation logic — 明示的な拒否の優先、許可の足し算と上限の重なり、クロスアカウントの両側の許可（2026-09 時点の記載）
- Service control policies (SCPs)（AWS Organizations） — SCP が権限を与えず上限を決めること、管理アカウントに効かないこと（2026-09 時点の記載）
- Resource control policies (RCPs)（AWS Organizations） — リソース側の上限を組織で決める仕組みと、組織の外のプリンシパルを止める用途（2026-09 時点の記載）
- Permissions boundaries for IAM entities — 権限境界の定義と委任での使い方、リソースベースのポリシーには上限を課さないこと（2026-09 時点の記載）
- Manage AWS accounts with permission sets（IAM Identity Center） — 許可セットと、各アカウントに作られるロール（2026-09 時点の記載）
- Attribute-based access control（IAM Identity Center） と ABAC の定義（IAM ユーザーガイド） — アクセスコントロールの属性とセッションタグ、aws:PrincipalTag と aws:ResourceTag の比較（2026-09 時点の記載）
- The confused deputy problem — 外部 ID と aws:SourceArn・aws:SourceAccount による対策（2026-09 時点の記載）
- Using AWS IAM Access Analyzer — 外部アクセス・未使用アクセスのアナライザー、信頼ゾーン、ポリシーの検証と生成（2026-09 時点の記載）
- Configure the Region deny control（AWS Control Tower） — リージョン拒否のコントロールとグローバルサービスの除外（2026-09 時点の記載）
- Permissions management（Well-Architected セキュリティの柱）・SEC03-BP02 最小権限・SEC03-BP04 継続的な削減 — 権限管理のベストプラクティス（2026-09 時点の記載）
