IAMポリシー設計｜基礎を学ぶ

このレッスンを終えると、複数のポリシーが重なった状態で「結局その API 呼び出しは通るのか」を、評価ロジックの順番どおりに追って判定できるようになります。

まず要件から

ある会社が、開発者グループに S3 の読み書きを許可しています。運用が進んだあとで監査部門から「バケット finance-reports だけは開発者に一切触らせないでほしい」と言われました。開発者グループのポリシーは 30 人以上のユーザーに効いていて、書き換えると影響範囲が読めません。

正解は、既存の Allow に手を入れず、finance-reports を対象にした明示的な Deny を足すことです。なぜそれで確実に止まるのかは、評価の順番を知っていれば一瞬で説明できます。

評価は3段で決まる

順	見るもの	結果
1	明示的な Deny があるか	あれば即拒否。以降は一切見ない
2	明示的な Allow があるか	あれば許可
3	どちらも無い	暗黙の Deny で拒否

押さえるべきは2点です。ひとつは明示的な Deny を Allow で打ち消す方法は無いこと。もうひとつは何も書かなければ拒否であること。SAA では「権限を確実に外したい」「例外だけ塞ぎたい」という要件が出たら、Allow の削除ではなく Deny の追加を選びます。削除は他の要件まで巻き込むからです。

ポリシーを読む

開発者グループに次が付いているとします。

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

ここに次を足します。

{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::finance-reports",
    "arn:aws:s3:::finance-reports/*"
  ]
}

バケット本体とオブジェクトで ARN が別物である点に注意します。バケット名だけを書くと ListBucket は止まりますが、GetObject は止まりません。オブジェクトを対象にするには末尾の /* が要ります。試験ではこの片方だけを書いた選択肢が「惜しい誤答」として並びます。

もうひとつ頻出なのが Condition です。

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" }
  }
}

これは「MFA を通していないなら全部拒否」です。Deny 側に条件を書くと「条件を満たさないときだけ塞ぐ」という表現になり、Allow を一つずつ直さずに全体へ制約をかけられます。

何を合わせて評価するのか

種類	付ける先	役割
アイデンティティベース	ユーザー、グループ、ロール	誰が何をできるか
リソースベース	バケット、キュー、鍵など	そのリソースに誰を通すか
権限境界	ユーザー、ロール	そのプリンシパルが持てる権限の上限
SCP	Organizations の OU、アカウント	アカウント全体の権限の上限

権限境界と SCP は上限を決めるだけで、権限を与えません。両方が絡む場合、最終的に通るのは「アイデンティティベースで Allow され、かつ上限にも含まれ、どこにも Deny が無い」ときだけです。

要件語から構成へ

要件文の言い回し	選ぶもの
特定のバケットだけ確実に触らせない	明示的な Deny を追加
開発アカウントで高額なリージョンを使わせない	SCP に Deny
委任した管理者が権限を昇格できないようにする	権限境界
MFA を通したときだけ操作させる	Condition 付きの Deny
別アカウントからこのバケットを読ませる	リソースベースポリシー

よくある引っ掛け

ひとつめは「SCP に Allow を書いたのに使えない」です。SCP は上限であって付与ではないので、ユーザー側の Allow が無ければ通りません。

ふたつめは「Deny があるが Allow のほうが具体的なので勝つ」という選択肢です。ポリシーの具体性で勝敗は決まりません。Deny が1つでもあれば、その時点で終わりです。

まとめ

評価は明示的 Deny、明示的 Allow、暗黙の Deny の順で、Deny が最優先
権限を外す要件では Allow の削除ではなく Deny の追加を選ぶ
バケットとオブジェクトは ARN が別。/* の有無で結果が変わる
権限境界と SCP は上限であって、権限を与えるものではない