IAMポリシー評価ロジックの理解 明示的Deny・境界・SCPの優先順位を読み解く
「権限を付けたはずなのにアクセスできない」「制限したはずなのに通ってしまう」。SCS-C02 では、複数のポリシーが重なったときに最終的にどう判定されるかを問う設問が頻出します。暗記ではなく評価の順番を理解すると、選択肢を一気に絞り込めます。
覚え方は「拒否が最強・許可は全層必要・暗黙は拒否」
評価ロジックは3つの原則に集約できます。どこか1か所でも明示的Denyがあれば拒否、許可されるには関係するすべての層でAllowが必要、どこにもAllowがなければ暗黙的Denyで拒否。この3つで、ほぼすべての設問に答えられます。
層ごとの役割を押さえる
アイデンティティベースポリシーは「この主体が何をできるか」、リソースベースポリシー(S3バケットポリシー、KMSキーポリシー等)は「このリソースに誰が触れるか」を定めます。権限の上限だけを決めたいときはパーミッションバウンダリー、組織全体で絶対に踏ませたくない操作があるときはSCP(サービスコントロールポリシー)を使います。バウンダリーとSCPはどちらも「ガードレール」で、単体では権限を与えません。ここが最頻出の論点です。
典型シナリオでの当てはめ
例えば「開発者が誤って本番リージョン以外にリソースを作らないようにしたい」ならSCPで Condition に aws:RequestedRegion を使って拒否します。「業務委託メンバーが自分より強い権限のロールを作れないようにしたい」ならパーミッションバウンダリーを必須化するポリシーを付けます。「特定のVPCエンドポイント経由でしかS3を読めないようにしたい」ならバケットポリシーで aws:SourceVpce を条件にした明示的Denyを書きます。
| ポリシーの種類 | 付ける対象 | 単体で許可できるか | 主な使いどころ |
|---|---|---|---|
| アイデンティティベース | ユーザー・グループ・ロール | できる | 通常の権限付与 |
| リソースベース | S3・KMS・SQSなど | できる(別アカウントにも) | クロスアカウント共有 |
| パーミッションバウンダリー | ユーザー・ロール | できない | 権限委譲時の上限設定 |
| SCP | OU・アカウント | できない | 組織全体のガードレール |
| セッションポリシー | AssumeRole時に指定 | できない | 一時的な絞り込み |
チェックリスト
- 明示的Deny・暗黙的Deny・Allowの優先順位を説明できる
- パーミッションバウンダリーとSCPが単体では許可しないことを説明できる
- クロスアカウントアクセス時に両側のAllowが必要な条件を整理できる
- aws:RequestedRegion や aws:SourceVpce などの条件キーの用途を挙げられる
- SCPが管理アカウントに効かない点を理解している
まとめ
評価ロジックは「拒否が最強・許可は全層必要・暗黙は拒否」の3原則で読み解けます。 理解度の確認にはクイズが便利です。試験範囲や申し込みの最新情報はAWS認定 公式ページもあわせて確認してください。
SCS(セキュリティ) におすすめの教材
要点整理から攻略する AWS認定 セキュリティ−専門知識 改訂2版
AWS認定 セキュリティ−専門知識 SCS-C02 練習問題集
AWS認定SCS(SCS-C03)対策トレーニングコース
AWS認定SCS 本番模試(4回分/260問)
本セクションにはAmazonアソシエイト・Udemyアフィリエイトのリンクが含まれます。