5.2. Authorization Strategies

Authorization determines what an authenticated identity can do. Even with perfect authentication, overly permissive authorization creates risk — an employee who is properly authenticated but has AdministratorAccess can accidentally or maliciously access any resource in the account. Think of authorization like building key cards: authentication confirms you work here, but authorization determines which floors and rooms your card opens. If every employee's card opens every room, the building's security is effectively zero despite having a card reader on every door. What makes AWS authorization especially complex? Multiple policy types interact — identity policies, resource policies, SCPs, permissions boundaries, and session policies — and the effective permission is the intersection of all of them. Missing any one type in your analysis can lead to both over-permissive and under-permissive configurations.

This section covers authorization design patterns, the new Verified Permissions service, ABAC/RBAC strategies, least-privilege policy design, and troubleshooting authorization failures.

Scenario: A developer has an IAM policy granting s3:* on all buckets. Their manager's team has a permissions boundary limiting S3 access to specific buckets. An SCP restricts the account to specific Regions. What can the developer actually do? The effective permission is the intersection of all three.

Reflection Question: Why must you consider ALL policy types (identity, resource, SCP, boundary, session) to determine effective permissions, and what happens when you analyze only one?