GCP と AWS で比較する IAM とポリシー継承の仕組み
前回の記事（リソース階層編）で、GCP の Organization → Folder → Project → リソース が AWS の Organization → OU → Account → リソース とほぼ1対1で対応することを整理した。
この記事ではその続きとして、「誰が・何を・できるか」を決める IAM と、「組織として何を禁止するか」を上位から継承させるガードレール（GCP: Organization Policy / AWS: SCP） を、GCP と AWS で比較する。
全体像
権限まわりは大きく2層に分けて考えると整理しやすい。
| 層 | 役割 | GCP | AWS |
|---|---|---|---|
| ① 許可を与える | 「このユーザーはこの操作ができる」 | IAM ポリシー（allow） | IAM ポリシー（allow / deny） |
| ② 上限を絞る | 「組織としてここから先は誰にも許さない」 | Organization Policy（組織ポリシー） | SCP（Service Control Policy） |
ポイントは 「② はあくまで上限（ガードレール）であって、権限を 付与 はしない」 こと。これは GCP も AWS も共通の考え方。
実効権限 = 「IAM で許可された操作」∩「ガードレールが許す範囲」
① IAM：許可の与え方
継承の方向は共通
どちらも 上位に付けた許可は下位へ継承される。
ここに 大きな思想の差 がある。
| 観点 | GCP | AWS |
|---|---|---|
| IAM を付与できる階層 | Organization / Folder / Project / リソース の各階層 | 原則 Account 内（IAM はアカウント単位で閉じる） |
| 上位からの継承 | 上位階層の付与が下位へ自動継承 | アカウントをまたいだ継承は無い（クロスアカウントは信頼関係で都度許可） |
| 横断的な権限管理 | 階層に IAM を付ければ複数 Project へ一括適用しやすい | アカウントをまたぐ権限は IAM Role の AssumeRole（信頼ポリシー）で実現 |
まとめると：
- GCP は「階層に権限を継承させる」モデル。Folder に Role を付ければ配下の全 Project に効く。
- AWS は「アカウントは独立。またぐときは Role を引き受ける（AssumeRole）」モデル。
用語の対応
| 概念 | GCP | AWS |
|---|---|---|
| 誰に | メンバー（user / group / service account） | プリンシパル（IAM user / group / role） |
| 何が許される | Role（事前定義 / カスタム）に権限をまとめる | Policy（管理ポリシー / インライン）に権限を記述 |
| 紐付け | IAM ポリシー（バインディング） = リソース × メンバー × Role | Policy を user / group / role にアタッチ |
| マシン用ID | Service Account | IAM Role（EC2 などにアタッチ） |
GCP の「Role」は権限の束、AWS の「Role」は引き受け可能なID、と名前が同じでも指すものが違う点に注意。GCP で AWS の Role に近いのは Service Account。
② ガードレール：Organization Policy と SCP
「IAM で許可されていても、組織として一律に禁止したい」を実現する仕組み。
共通点
- 上位（Organization / Folder / OU）に設定 → 下位へ継承される
- 権限を付与しない（あくまで「許可の上限」を絞るだけ）
- ルートユーザー / 組織管理者であっても、原則として上限を超えられない
違い
| 観点 | GCP: Organization Policy | AWS: SCP |
|---|---|---|
| 設定する場所 | Organization / Folder / Project | Organization / OU / Account（管理アカウントには効かない） |
| 何を制御するか | 制約（Constraint） を有効化して設定。例：「特定リージョンのみ許可」「外部IP禁止」「公開バケット禁止」 |
IAM アクション単位で Allow / Deny を記述（JSON）。例：ec2:* を特定リージョン外で Deny |
| 記法 | 事前定義された制約のオン/オフ＋値（リスト/ブール） | IAM とほぼ同じ JSON ポリシー言語 |
| 継承の挙動 | 下位で inheritFromParent や上書き可否を制御 |
OU 階層を下るほど AND で重なる（どこかで Deny されれば最終的に Deny） |
よくあるユースケース
| やりたいこと | GCP | AWS |
|---|---|---|
| 使えるリージョンを限定 | 組織ポリシー gcp.resourceLocations
|
SCP で aws:RequestedRegion 条件付き Deny |
| 公開（パブリック）アクセスを禁止 |
storage.publicAccessPrevention 等 |
SCP で s3:PutBucketPublicAccessBlock の解除を Deny |
| サービスアカウントキー作成を禁止 | iam.disableServiceAccountKeyCreation |
SCP で iam:CreateAccessKey を Deny |
| 特定サービスの利用を禁止 | （組織ポリシー or VPC SC 等） | SCP でサービスの名前空間ごと Deny |
実効権限の判定フロー（まとめ）
最終的に「ある操作が通るか」は、両クラウドとも 「許可」と「上限」の両方を満たすか で決まる。
- GCP：IAM は「allow のみ」。明示的な deny は別途「IAM Deny ポリシー」で表現。基本は「上位からの allow の継承」＋「組織ポリシーの上限」。
- AWS：IAM は「明示 Deny > 明示 Allow > 暗黙 Deny」の評価順。さらに SCP の上限がかかる。1つでも Deny があれば最終結果は Deny。
まとめ：覚え方
-
階層継承の主役が違う
- GCP = IAM そのものが階層継承する（Folder に付けた Role が配下 Project に効く）
- AWS = IAM はアカウント内で閉じる。階層継承するのは主に SCP（ガードレール） の方
-
ガードレールは両方とも「上限を絞るだけ・権限は与えない」
- GCP: Organization Policy（制約のオン/オフ）
- AWS: SCP（IAM 記法の Deny ベース）
-
名前が同じでも中身が違うトラップ
- GCP の「Role」= 権限の束 / AWS の「Role」= 引き受け可能なID
- AWS の Role に近い GCP の概念は Service Account
関連記事：GCP のリソース階層を AWS と比較する（Organization / Folder / Project 編）