本文へスキップ
BecomeCoder

AWS SAP（ソリューションアーキテクト プロフェッショナル）コース　·　第4章　エンタープライズの認証・認可とセキュリティ　·　レッスン20

高度なIAM ― 権限境界（Permissions Boundary）とABAC

導入

大きな組織では「開発者に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["暗黙の拒否"]

具体例

大企業の2つのジレンマを、権限境界とABACが解きます。

  • 「開発者に自分でIAMロールを作らせたいが、管理者級の強すぎるロールを作られては困る」→ 権限境界 … 開発者に「ロール作成権限」を与えつつ、作れるロールには権限境界を必須にする。すると開発者が何を作っても、その権限は境界の範囲（例：特定サービスの読み書きだけ）を超えられない。自由と安全を両立させる権限委譲の自動化。
  • 「プロジェクトが次々増え、そのたびにアクセス制御ポリシーを書き足すのが限界」→ ABAC … 従来のRBACだと、新プロジェクトごとに専用ポリシーを追加。ABACなら「リソースとユーザーのprojectタグが一致すれば許可」という1つのポリシーで表現でき、プロジェクトが100個に増えてもポリシーは増やさなくてよい。

そして全レイヤー共通の評価ロジックは「明示的Denyが最優先 → 次にAllowがあるか → どちらもなければ暗黙のDeny」。SCP・権限境界・IAMが重なるときも、すべての層でAllowが揃って初めて実行できます。「委譲の暴走防止＝権限境界、タグでスケールする制御＝ABAC」が対応です。

読んでみよう

「開発者に権限管理の自由を与えつつ、暴走を防ぎたい」→ 権限境界、「タグでリソースを分類していて、その単位でアクセス制御したい」「新規プロジェクトのたびにポリシーを増やしたくない」→ ABAC、という対応を押さえてください。試験ではポリシー評価ロジック（Explicit Denyの優先順位）を問う問題も頻出です。

次のレッスンへ →