導入
大きな組織では「開発者にIAMロールを自由に作らせたいが、自分より強い権限のロールを作られては困る」というジレンマが生じます。また、数百人・数百リソースに対して個別にポリシーを書き続けるのも非現実的です。この2つの課題を解決するのが、権限境界とABACです。
説明
権限境界（Permissions Boundary） は、IAMユーザーやロールが持てる権限の上限を定義する仕組みです。実際に有効な権限は「アイデンティティベースポリシー」と「権限境界」の共通部分（AND）になります。これにより、「開発者自身にIAMロール作成権限を与えつつ、作成できるロールの権限は権限境界の範囲内に制限する」という権限委譲の安全な自動化が可能になります。
flowchart LR
A["アイデンティティベース<br/>ポリシー（付与された権限）"] --> C{"共通部分（AND）<br/>が実際の有効権限"}
B["権限境界<br/>Permissions Boundary<br/>（許可できる上限）"] --> C
ABAC（Attribute-Based Access Control、属性ベースアクセス制御） は、IAMポリシーの条件に タグ を使い、リソースやプリンシパルの属性が一致する場合だけアクセスを許可する方式です。従来の RBAC（ロールベース） は「役割ごとにポリシーを作る」ため、リソースが増えるたびにポリシーを増やす必要がありますが、ABACは「project タグが一致するリソースにだけアクセスできる」といった条件を1つのポリシーで表現でき、リソースが増えてもポリシーを増やす必要がありません。
| 方式 | 仕組み | スケールへの強さ |
|---|---|---|
| RBAC（ロールベース） | 役割ごとに個別のポリシーを用意 | リソース増加のたびにポリシー追加が必要 |
| ABAC（属性ベース） | タグの一致条件で1つのポリシーが多数のリソースをカバー | リソースが増えてもポリシー不変 |
ポリシー評価の全体ロジックも整理しておきましょう。明示的な拒否（Deny）が常に最優先され、次に許可（Allow）があるかを確認し、どちらもなければ暗黙の拒否になります。SCP・権限境界・IAMポリシーが重なる場合も、すべての層で許可されていて初めてアクセスできます。
flowchart TD
S["すべてのレイヤー<br/>（SCP/権限境界/IAMポリシー等）"] --> D{"どこかにExplicit Deny?"}
D -- あり --> DENY["拒否"]
D -- なし --> AL{"すべての適用レイヤーで<br/>Allowが揃っているか"}
AL -- はい --> ALLOW["許可"]
AL -- いいえ --> DENY2["暗黙の拒否"]
読んでみよう
「開発者に権限管理の自由を与えつつ、暴走を防ぎたい」→ 権限境界、「タグでリソースを分類していて、その単位でアクセス制御したい」「新規プロジェクトのたびにポリシーを増やしたくない」→ ABAC、という対応を押さえてください。試験ではポリシー評価ロジック（Explicit Denyの優先順位）を問う問題も頻出です。