← AWSサービスの内部原理 コース
57. ポリシーには2つの役割がある — 権限を『与える』ポリシーと上限を『切る』ポリシー
AWSのポリシーは現在9種類ありますが、その一つひとつを暗記する必要はありません。すべては「権限を与える」か「上限を切る」かの2分類に収まり、片方は和集合、もう片方は積集合という集合演算で評価されます。この2つの演算がそのまま許可判定のロジックになっている様子を、図で追っていきます。
① 9種類あっても、役割は2つしかない
ポリシーは9種類identity-based / resource-based / VPC endpoint / boundary / SCP / RCP / ACL / RAM / session
合成のされ方が正反対
与える側permissionsをgrantする
identity-based / resource-based上限を切る側grantしない(maximumを定義)
boundary / SCP / RCP / session和集合(OR)許可を合算して広げる
積集合(AND)重なりだけに絞る
- 公式は「AWS supports nine types of policies」と明記(identity-based, resource-based, VPC endpoint, permissions boundaries, SCP, RCP, ACL, RAM, session)。
- 「上限を切る」側の各ポリシーは公式が揃って "do not grant permissions" と書く。permissions boundary: "does not grant permissions"、SCP: "SCPs do not grant permissions"、RCP: "RCPs do not grant permissions"、session policy: "limit permissions for a created session, but do not grant permissions"。
ポリシーは「権限を積み増すもの」と「権限の上限を定めるだけで一切与えないもの」の2種類しかない。この分類さえ持てば、9種類は暗記対象ではなくなる。
② 与える側は「和集合」— どちらかがAllowすれば通る
許可判定同一アカウント内のあるアクション
和集合(UNION / 論理OR)で合算
identity-baseduser/group/roleに付く
Principalは書けない(暗黙的にそのuser/role)resource-basedリソースに付く(S3バケットポリシー等)
Principal要素で誰に許すか明示ただしexplicit denyは和集合を貫いて優先
どちらかがAllow片方のAllowで足りる
Allow実効権限は2つの和
- 公式の言い回し: "The resulting permissions are the union of the permissions of the two types. If an action is allowed by an identity-based policy, a resource-based policy, or both, then AWS allows the action."(evaluation-logic.html)
- 明示的Deny(explicit deny)はこの和集合を貫いて優先する: "An explicit deny in either of these policies overrides the allow."
- resource-based policyの代表例はS3バケットポリシーとIAMロールのtrust policy(公式: "The most common examples of resource-based policies are Amazon S3 bucket policies and IAM role trust policies.")。identity-basedにはPrincipalを書けない(公式: "The principal is implied as that user or role.")。
与える側の2つは足し算(和集合)で合算される。identity-based か resource-based のどちらか一方がAllowすれば、そのアクションは通る。
③ 上限を切る側は「積集合」— 全部の関門がAllowして初めて通る
与える側の権限②の和集合の結果
Yes(SCPが許す)
SCPOrganizations SCP
許さなければ即・拒否Yes(RCPが許す)
RCPOrganizations RCP
許さなければ即・拒否Yes(boundaryが許す)
boundarypermissions boundary
許さなければ即・拒否Yes(全関門を通過)
session policy一時セッションの絞り込み
許さなければ即・拒否実効的に許可
- 前レッスン(評価順序)で見た各関門が、この編で分類した各ポリシー種(SCP・RCP・boundary・session)に1対1で対応する。関門の並び順も公式の評価フロー(Deny評価 → SCP → RCP → リソースベース → アイデンティティベース → boundary → session)に揃えてある。積集合なので論理的な結果は順序に依らない。
- 積集合の明言: identity-based × boundary は "the resulting permissions are the intersection of the two categories"。identity-based × SCP × RCP は、リソースベースポリシーが構成されていないリソースへのアクセスの場合、"an action must be allowed by all three policy types"。session は "the intersection of all three policy types"。
- どの関門でも explicit deny は即座に全体を拒否する: "An explicit deny in any of these policies overrides the allow."
- この図は「アイデンティティベースで得た権限」を各関門が絞る簡略図。公式は "Permissions boundaries do not define the maximum permissions that a resource-based policy can grant to an entity." と明記しており、リソースベースポリシーがユーザーARN等に直接与える権限は boundary/session の暗黙Denyには制限されない(explicit deny は常に有効)。この例外は上級論点として別レッスンで扱う。
上限を切る側は掛け算(積集合)。SCP・RCP・boundary・session はどれも権限を1つも与えず、フィルタとして働く。全関門がAllowして初めてリクエストは通る。
④ ベン図で見る — 和集合と積集合の対比
複数ポリシーの合成同じ「合成」でも向きが正反対
実効権限への効き方
和集合(∪)identity-based ∪ resource-based
どちらかにあれば許可積集合(∩)与える側の権限 ∩ 上限側が許す範囲
重なった所だけ許可広がる塗り足して範囲拡大
狭まる重なりだけに切り詰め
- 左(和集合): identity-based ∪ resource-based。塗られた領域全体が実効権限で、範囲は広がる方向。
- 右(積集合): 「与える側で得た権限」と「上限側が許す範囲」の重なり(∩)だけが残り、範囲は狭まる方向。公式もboundaryについて "when you add a permissions boundary to a user with existing identity-based policies, you might reduce the actions that the user can perform" と述べる。
- DynamoDB編でハッシュ関数を「数学の関数」として見たのと同じで、ここでは権限評価が「集合演算」として設計されている。
集合論の和集合(∪)と積集合(∩)が、そのままAWSの権限評価ロジックになっている。与える側は塗り足して広げ、上限側は重なりだけに切り詰める。CS基礎の集合演算を知っていれば、9種類の合成規則はこの2枚の図に還元できる。
⑤ 実例 — boundaryが iam:CreateUser のAllowを無効化する
iam:CreateUserユーザーShirleyのリクエスト
積集合(∩)を取る
identity-basediam:CreateUser → Allow
boundarys3:* / cloudwatch:* / ec2:* のみ
iamは含まれない = 暗黙のDenyboundaryの範囲外
Allow ∩ 暗黙Deny重なりは空
Access Denied実行不可
- 公式の Shirley の例そのまま: boundary が S3・CloudWatch・EC2 のみ(s3:* / cloudwatch:* / ec2:*)を許可 → identity-based に iam:CreateUser の Allow があっても "It fails because the permissions boundary does not allow the iam:CreateUser operation"。
- さらに公式はこう続ける: "Given these two policies, Shirley does not have permission to perform any operations in AWS." — permissions policy が iam:CreateUser しか許していないため、積集合は完全に空。boundary が「権限を与えない、上限を切るだけ」であることの直接的帰結。
「Allowしたのに動かない」の典型が boundary。与える側でどれだけ許可を積んでも、上限側の範囲外なら積集合は空になり、実行できない。
⑥ 周辺の3事実 — rootの特例・ACLの特異点
分類の外側2分類に収めた後に残る例外
rootユーザーidentity-basedもboundaryも付けられない
rootへの制御SCP / RCPはrootにも効く(上限は切れる)
ACLの特異点9種類で唯一JSONを使わない
S3のACLが生き残り- 公式: "You cannot attach identity-based policies to the root user, and you cannot set the permissions boundary for the root user." かつ組織所属なら "the root user is affected by SCPs and RCPs for the account." — root は「与える側/boundaryでは触れないが、組織レベルの上限(SCP/RCP)からは逃げられない」。なお root を resource-based policy や ACL の principal に指定することはできる。
- ACL: 公式 "they are the only policy type that does not use the JSON policy document structure." resource-based に似たクロスアカウントの許可で(同一アカウント内のエンティティには権限を付与できない)、S3・AWS WAF・Amazon VPC がサポート例。
- S3編で見たオブジェクトストレージのアクセス制御の古い機構(ACL)が、この分類の中で唯一の例外として残っている。
root は与える側とboundaryの外にいるが、組織のSCP/RCPという上限からは逃げられない。ACLは9種類で唯一JSONを使わない、resource-basedの古い親戚。