変更要約: SOA-C02 第4章を Associate 級に深掘り（比較表・シナリオ・FAQ・ひっかけ＋深掘り段落、図を日本語化）
4.1IAM とアクセス管理（運用視点）
IAM のアイデンティティベース/リソースベースポリシー、評価ロジック（明示的拒否が最優先・既定は拒否）、ロールと一時認証情報、最小権限の運用を理解します。SOA-C02 の「セキュリティとコンプライアンス」の出発点です。
運用では「誰が何にアクセスできるか」を正しく管理し、トラブル時に評価ロジックを理解していることが重要です。IAM のポリシー種別と評価順を押さえましょう。
4.1.1ポリシーと評価ロジック
- アイデンティティベース：ユーザー/グループ/ロールにアタッチ。リソースベース：S3 バケットポリシー等、リソース側に付与。
- 評価ロジック：明示的な拒否（Deny）が最優先。拒否がなく許可があれば許可。既定は暗黙の拒否。
- ロール＋一時認証情報：EC2/Lambda にロールを付与し、キーを埋め込まない。
「明示的拒否が最優先」「既定は拒否」「アクセスできない時はまず Deny と境界（SCP/権限境界）を疑う」「クロスアカウントアクセス＝リソースベースポリシー＋ロール」 は SOA で頻出です。
運用でのトラブルシュートは「評価順を辿る」のが基本です。アクセス可否は
①明示的 Deny があれば即拒否、
②組織の SCP で許可されているか、
③権限境界（Permissions Boundary） の上限内か、
④アイデンティティ/リソースのいずれかに Allow があるか——のすべてを満たして初めて許可され、どこにも Allow が無ければ 暗黙の拒否 です。「許可したのに使えない」ときは、まず Deny・SCP・権限境界・VPC エンドポイントポリシー・セッションポリシー を疑います。誰がどの権限を持つかの検証には IAM Policy Simulator や Access Analyzer（外部公開の検出）、未使用権限の特定には アクセスアドバイザー（最終アクセス情報） が使えます。EC2/Lambda には長期キーを置かずロール（一時認証情報） を付与し、クロスアカウントは相手のリソースベースポリシー＋ロールの AssumeRole で行います。条件キー（aws:SourceIp・aws:MultiFactorAuthPresent 等）で粒度の細かい制御もできます。
| 症状/目的 | 確認・手段 |
|---|---|
| 許可したのにアクセス不可 | 明示的 Deny / SCP / 権限境界を確認 |
| 権限の検証 | Policy Simulator / Access Analyzer |
| クロスアカウントアクセス | リソースベース＋AssumeRole |
| 未使用権限の削減 | アクセスアドバイザー |
シナリオ：開発者が S3 にアクセスできると思ったのに 403。 ロールには Allow がある——そこで SCP と 権限境界を確認すると、組織 SCP がそのリージョン/サービスを制限していた。あるいはバケットのリソースベースポリシーに明示的 Deny があるケースも。Policy Simulator で評価を再現し、原因（Deny/境界）を特定して是正します。
Q. 許可があるのにアクセス不可。 明示的 Deny か SCP/権限境界を疑う。Q. 既定の挙動は？ 暗黙の拒否。Q. クロスアカウントは？ リソースベース＋AssumeRole。Q. 権限を検証したい。 Policy Simulator / Access Analyzer。Q. キーは埋め込む？ いいえ、ロールで一時認証情報。
混同に注意：
①明示的 Deny は他のすべての Allow に勝つ。
②許可が無い＝暗黙の拒否（明示 Deny は不要）。
③SCP/権限境界は「上限」であり権限を付与しない（許可は別途必要）。
④長期アクセスキーの埋め込みは厳禁——ロールを使う。
Organizations の SCP や権限境界は「上限」を定めます。アイデンティティに許可があっても、SCP/境界で許可されていなければアクセスできません。
4.1.2この節のまとめ
- 明示的拒否が最優先・既定は拒否、上限はSCP/権限境界
- クロスアカウントはリソースベース＋ロール
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. あるユーザーにアクセス許可があるのにアクセスできない。最初に疑うべきものはどれですか？
Q2. S3 バケット側に付与してアクセスを制御するポリシーの種類はどれですか？
Q3. IAM で許可も拒否も明示されていない操作はどう扱われますか？