導入
SAAでは短いIAMポリシーのJSONを読ませて、「このユーザーは何ができるか/できないか」を答えさせる問題が頻出します。構造さえつかめば怖くありません。
説明
IAMポリシーはJSON形式で、次の要素で構成されます。
| フィールド | 意味 |
|---|---|
| Version | ポリシー言語のバージョン（通常 "2012-10-17"） |
| Statement | 許可/拒否のルールの配列 |
| Effect | Allow（許可）または Deny（拒否） |
| Action | 対象となるAPI操作（例 s3:GetObject） |
| Resource | 対象となるAWSリソースのARN |
| Condition | 追加の条件（IPアドレス、MFAの有無など） |
例：特定のS3バケットからの読み取りだけを許可するポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::my-bucket/*",
"Condition": {
"IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
}
}
]
}このポリシーは「203.0.113.0/24 からのアクセスに限り、my-bucket 内オブジェクトの取得だけを許可」します。Conditionは「いつ・どこから・どのように」を絞り込む強力な仕組みで、SAAでは「特定のIP範囲からだけ」「MFA使用時だけ」許可する設計でよく登場します。
最重要なのが 評価順序 です。
flowchart TD
A["リクエスト発生"] --> B{"明示的なDenyがあるか"}
B -- ある --> C["拒否（最優先）"]
B -- ない --> D{"明示的なAllowがあるか"}
D -- ある --> E["許可"]
D -- ない --> F["暗黙のDeny（デフォルト拒否）"]
IAMのデフォルトはすべて拒否です。その上で、いずれかのポリシーに 明示的なAllow があれば許可されますが、明示的なDenyは他のどんなAllowよりも優先されます。複数のポリシーが絡む問題では、「Denyが1つでもあれば拒否」がSAAの鉄則です。
読んでみよう
SAAのポリシー問題は「複数のポリシーをアタッチされたユーザーは最終的に何ができるか」を聞いてきます。まず「明示的なDenyがないか」を探し、次に「Allowがあるか」を確認する順番で読むと、確実に正解にたどり着けます。