先に要点
- AWS IAM の権限制御は 6 つの異なるレイヤ がある: ① アイデンティティベースポリシー(ユーザー/グループ/ロールに付与)、② リソースベースポリシー(S3 バケットポリシーなど)、③ 権限境界(IAM Permission Boundary)、④ Organizations SCP(Service Control Policy)、⑤ セッションポリシー(AssumeRole 時)、⑥ ACL(古い形式、ほぼ使わない)。
- 評価ロジックは 各レイヤで Allow が必要、いずれかで Deny されると拒否(AND で絞り込み、明示 Deny 優先)。「複数のレイヤで Allow を重ねても権限は増えない」 のが原則。最終的に許可される権限は すべてのレイヤの Allow の AND。
- 使い分けの目安: 個人のアクセス制御 = アイデンティティポリシー」 「S3 バケットや KMS 鍵への外部からのアクセス制御 = リソースベースポリシー」 「委任した管理者の暴走を防ぐ = 権限境界」 「組織全体で禁止したい操作 = SCP」 `一時的に権限を狭める = セッションポリシー。
- ロール vs ユーザー: 「ユーザー = アクセスキー(長期)」、「ロール = 一時クレデンシャル(STS で短時間有効)」。現代の AWS では 「ロール優先」。「人間は SSO + IAM Identity Center 経由でロールを引き受け、アクセスキーを使わない」 のが標準。
- 多くの組織が踏むパターン: 開発者向けに権限境界」 「本番アカウントに対する破壊的操作は SCP で禁止」 「EC2 / Lambda に IAM ロールを付与」 `S3 / KMS にリソースベースポリシーで細かい制御。一度この階層を整理すれば、「新しい権限要求」 が来た時の判断が速くなる。
「IAM ポリシーを書いたのに API が呼べない」 「権限境界って何のためにある?」 「SCP は組織全体に効くと聞いたけど具体的に?」 ── AWS IAM は 似たような名前のレイヤが複数あって混乱する のが最初の壁です。
ざっくり言うと、AWS IAM の権限制御は 6 つの異なるレイヤが AND で評価される 仕組みです。「どの層で何を制御するか」 を分けて理解すれば、「どこに何を書けばいいか」 「なぜ動かないか」 が見えてきます。
この記事では、IAM の基本(ユーザー・グループ・ロール・ポリシー)を理解している前提で、各ポリシー種類の使い分け と 評価ロジック を実務目線で整理します。
6 つの権限レイヤ
AWS IAM の権限制御を司る要素を一覧で整理します。
| レイヤ | どこに付ける | 主な用途 | 典型例 |
|---|---|---|---|
| アイデンティティベースポリシー | ユーザー / グループ / ロール | 「 誰が何をできるか」 を直接定義 | Lambda の実行ロールに 「S3:GetObject」 を許可 |
| リソースベースポリシー | リソース自体(S3 バケット、KMS 鍵、Lambda 関数など) | 「 リソース側から誰のアクセスを許すか」 を制御 | S3 バケットを OAC 経由の CloudFront だけ許可 |
| 権限境界(Permission Boundary) | ユーザー / ロール | そのアイデンティティが 持てる権限の最大値 を制限 | 開発者ロールが 「IAM 操作」 までは行えないように上限設定 |
| SCP(Service Control Policy) | Organizations の OU / アカウント | 組織全体で 絶対に許さない操作 を Deny | 「本番アカウントでは IAM ユーザー作成禁止」 「特定リージョン以外禁止」 |
| セッションポリシー | AssumeRole の引数で渡す | 一時的に 引き受けるロールの権限を狭める | サードパーティに渡す一時クレデンシャルを 「特定バケットだけ」 に制限 |
| ACL(Access Control List) | S3 など一部の古いリソース | 古い形式の権限制御。現代ではほぼ使わない | S3 のオブジェクト ACL は 新規では無効化推奨 |
「似た名前」 でも 付与する場所と評価のされ方が違う ので、「どこに書くべきか」 の判断軸を持つことが重要です。
評価ロジック — 「AND で絞り込み、明示 Deny 優先」
複数のレイヤで権限が定義されているとき、AWS はどう判断するか。これが分かると 「動かない時の原因切り分け」 が一気に楽になります。
ざっくり覚えるなら SCP / 権限境界 / アイデンティティ / リソースポリシー / セッションポリシー の AND、いずれかの Deny で即拒否。「権限を増やしたいなら全レイヤで Allow が必要」、「権限を絶対禁止したいなら一箇所で Deny」 が原則です。
アイデンティティポリシー — 「誰が何をできるか」
最も基本的で、最も書くことが多いのがこのレイヤ。
どこに付ける
ユーザー / グループ / ロール。「グループに付けてメンバーで共有」 が運用上シンプル。ロールに付ける場合は 「Lambda / EC2 / ECS タスク / EKS Pod」 など実行コンテキストの定義になる。
マネージドポリシー vs インラインポリシー
「 AWS 管理 / 顧客管理 / インライン」 の 3 種類。顧客管理ポリシーを再利用する のが運用上推奨。インラインは 「1 つのアイデンティティ専用」 で、削除すると一緒に消える。
最小権限の原則
「 AdministratorAccess を付けて済ます」 は事故のもと。必要な Action / Resource / Condition に絞る のが基本。「AWS IAM Access Analyzer」 で 「実際に使われた権限」 を分析し、不要な権限を削る運用が現代的。
Condition で文脈を絞る
「 特定 IP からだけ」 「MFA 認証済みのときだけ」 「特定タグのリソースだけ」 のような条件を 「Condition」 で追加。Effective な権限を文脈で狭める のが上級者の使い方。
リソースベースポリシー — 「リソース側から制御」
「 S3 バケット」 「KMS 鍵」 「Lambda 関数」 「SQS / SNS」 などに直接付くポリシー。「クロスアカウントアクセス」 と相性が良い。
クロスアカウントの典型
「 A アカウントの S3 バケットを、B アカウントの IAM ロールから読みたい」。バケットポリシーで B アカウントのロール ARN を Principal に Allow」 + `B アカウント側のロールに s3:GetObject を Allow の両方が必要(両側で Allow)。
S3 + CloudFront + OAC
「 S3 バケットは Public 禁止のまま、CloudFront からだけ読める」 構成は、バケットポリシーで CloudFront の ARN を Principal に許可。S3 公開設定の落とし穴と OAC 移行 で詳述。
KMS 鍵ポリシー
KMS の鍵は 必ず鍵ポリシーが付く(これ無いと誰も使えない)。「鍵管理者(KeyPolicy 編集できる人)」 と 「鍵利用者(暗号化/復号できる人)」 を分けるのが鉄則。
Lambda 関数ポリシー
「 Lambda を API Gateway / S3 イベント / SNS から呼ばれるよう許可」 する際のポリシー。「Invoke 権限を誰に許すか」 を関数側で制御。
権限境界(Permission Boundary)— 「委任した管理者の暴走防止」
「権限境界」 は理解しづらいが、委任した管理者が自分以上の権限を作れないようにする 用途で使う特殊なレイヤ。
典型ユースケース
「 開発者にユーザー作成権限を委譲したいが、開発者が AdministratorAccess を持つユーザーを作るのは防ぎたい」。開発者ロールに権限境界を設定 → 開発者が新しく作るユーザーには、その境界以下の権限しか付けられない。
境界 = 最大値
「 持てる権限の上限」 を定義するもので、「それ自体が権限を付与する」 のではない。境界に書いてあっても、アイデンティティポリシーで Allow しなければ権限なし。「境界 ∩ アイデンティティポリシー」 が実効権限。
よく使うパターン
「 SaaS のサブテナント / 子プロジェクトに、独立したリソース管理権限を委譲する」。`境界で 「Account-Wide 操作禁止」 を縛れば、サブテナントが他テナントを壊せない」 設計が組める。
よくある誤解
「 権限境界 = 権限を制限するポリシー」 と思いがちだが、直接の権限制限は SCP やアイデンティティポリシーで十分。境界は 委譲された管理者が自分以上のものを作らせない の用途が本来。
SCP(Service Control Policy)— 組織レベルの禁止
「 AWS Organizations」 を使っている場合、組織全体に効く SCP は どんなに強い権限を持つ管理者でも超えられない上限 として機能する。
典型ユースケース
「 本番アカウントでは、特定リージョン(東京/バージニア)以外でリソース作成禁止」 「本番アカウントでは、IAM ユーザー作成禁止(Identity Center 経由のみ)」 「本番アカウントでは、組織の CloudTrail を無効化禁止」。
許可リスト vs 拒否リスト
SCP は 「許可リスト(FullAWSAccess を取り去る形)」 か 「拒否リスト(個別 Deny)」 で運用。拒否リスト方式」 が現実的で、`基本は許可、危険な操作だけ Deny で運用するのが一般的。
アカウント管理者にも効く
「 Root ユーザーも含めて、SCP で禁止された操作は実行できない」。これが SCP の最大の価値で、どんなに権限の強い人でも超えられない組織レベルのガードレール になる。
運用上の注意
「 SCP を厳しくしすぎると、運用に支障が出る」 ので、まず CloudTrail で実際の操作を観察 → 不要なものを Deny → 段階的に厳格化。`過剰な SCP で 「アクセスできない理由が分からない」 トラブルがよく起きる。
セッションポリシー — 一時的に権限を狭める
「 AssumeRole」 でロールを引き受ける時に渡せるオプションで、そのセッションだけ権限を狭める 用途で使う。
サードパーティへの一時クレデンシャル発行
` サードパーティ業者に 「S3 の特定プレフィックスだけ」 読める一時クレデンシャルを渡す」 場合、`元のロールは広い権限を持つが、AssumeRole 時にセッションポリシーで 「Resource を特定プレフィックスに限定」」 で 一時的にスコープを絞れる。
同一アカウント内でも有効
` 自社内で管理者が 「今この操作だけ」 一時的に行う時、フルアクセスではなく 「今回必要な権限だけ」 でセッションを開始」 する使い方。CloudShell から AssumeRole する時などに有用。
権限境界との違い
「 権限境界 = アイデンティティに固定で付くもの」 「セッションポリシー = AssumeRole の都度動的に渡すもの」。セッションポリシーは時間軸が短い、権限境界は半永続的。
アプリ実装で有効
` Web アプリが 「今回の操作に必要な権限だけ」 でクレデンシャルを取得する」 設計に組み込める。「攻撃を受けた時の被害縮小」 効果あり。
ロール vs ユーザー — 「現代は基本ロール」
「 IAM ユーザー(長期アクセスキー)」 と 「IAM ロール(短期一時クレデンシャル)」 の使い分け。
「現代の AWS では、人間ユーザーは IAM Identity Center 経由でロールを引き受け、長期アクセスキーは作らない」 のが標準ライン。CI/CD も GitHub Actions の OIDC 連携でロールを引き受ける 方式に移行するのが推奨です。
IAM の使い分けに関するよくある質問
Q. ポリシーが効かない時、まず何を確認すべき?
A. 評価ロジックの順序で 1 つずつ確認。「SCP で禁止されていないか」 「権限境界に含まれているか」 「アイデンティティポリシーで Allow されているか」 「リソースポリシーで Allow されているか(クロスアカウントの場合)」 「どこかに明示 Deny がないか」 を順に。AWS IAM Policy Simulator や Access Analyzer を使うとデバッグが早い。
Q. グループとロールはどう違いますか?
A. グループ = ユーザーをまとめる箱」 `ロール = 引き受けて使う一時クレデンシャル発行体。グループは 「ユーザーを束ねて同じポリシーを共有」、ロールは 「誰か(ユーザー / EC2 / Lambda / 外部 IdP)が引き受けて使う」。「AssumeRole」 はロールにしかない概念。
Q. なぜ Lambda は実行ロールを持っているのに、API Gateway 連携でも別途権限が要りますか?
A. 実行ロール = Lambda が AWS リソースを叩く時の権限」 `API Gateway → Lambda 呼び出し = Lambda 関数ポリシーで Invoke 許可。「Lambda が S3 を読む」 のと 「API Gateway が Lambda を呼ぶ」 は別レイヤなので、両方の権限が必要です。コンソールで 「API Gateway を Lambda のトリガーに追加」 すると自動で関数ポリシーが追加されます。
Q. SCP は新規アカウントにすぐ効きますか?
A. Organizations にアカウントを追加した時点で、所属する OU の SCP が即適用。「既存アカウントを別 OU に移動」 した場合も即時。新規アカウント作成時のセキュリティガードレールとして SCP を整える のが企業 AWS の運用上重要です。
Q. リソースポリシーとアイデンティティポリシーの両方で許可が必要?
A. 同一アカウント内のリソースアクセスは 「どちらか一方で Allow」 で十分(同一アカウント内では両方 OR で評価される) ですが、クロスアカウントは両側で Allow が必要。「A アカウントの S3 を B アカウントから読む」 場合、「A 側のバケットポリシーで B を許可」 + 「B 側のアイデンティティで S3:Get を許可」 の両方。
Q. 権限境界をいつ使うべきですか?
A. 委任した管理者の暴走を防ぎたい時だけ。「普通の権限制限なら SCP やアイデンティティポリシーで十分」。「権限境界 = 委任の上限」 という発想で、「サブ管理者を作る時」 「SaaS のサブテナント機能」 のような 階層的な権限委譲 シナリオで活躍します。
Q. IAM Identity Center(旧 AWS SSO)はどう使うべき?
A. 人間ユーザーの認証/認可は Identity Center 経由が現代の標準。「各人に IAM ユーザーを作らず、SSO 経由でロールを引き受ける」。MFA / セッション時間制限 / 監査ログが整い、「退職時にアカウント無効化で全 AWS アクセスが止まる」 ような中央管理が可能。Cognito は B2C 向けで、IAM Identity Center は内部メンバー向け、と棲み分け。
まとめ
AWS IAM の権限制御は 6 つの異なるレイヤが AND で評価される 仕組みです。「どこに何を書くか」 を分けて理解すれば、「動かない時の切り分け」 と 「必要なだけ絞る設計」 の両方が楽になります。
「アイデンティティポリシーで日常の権限定義 → リソースポリシーで横断的なアクセス制御 → 権限境界で委任管理者の上限 → SCP で組織レベルの絶対禁止 → セッションポリシーで一時的な絞り込み」 という階層を意識すれば、「IAM が分かる人」 と呼ばれるレベルに到達できます。「新規システムは IAM Identity Center + ロール優先、長期アクセスキーは作らない」 が、現代 AWS の標準です。
参考リンク
- AWS Docs: IAM ポリシーと権限
- AWS Docs: IAM ポリシーの評価論理
- AWS Docs: SCP(Service Control Policies)
- AWS Docs: 権限境界(Permission Boundary)
- AWS Docs: IAM Access Analyzer