Cloud Identity and Access Management
Identity is the primary attack surface in cloud, and this domain tests whether you can compute effective permission rather than read a single policy document. Expect CIEM scenarios: over-privileged roles, unused entitlements, trust relationships and non-human identities.
Effective permissions, not policy text
- AWS evaluates identity policy, resource-based policy, permissions boundary, SCP and session policy together, plus the role's trust policy for who may assume. Explicit deny wins; everything else needs an explicit allow. A trust policy grants no permissions by itself.
- Azure combines Microsoft Entra roles with Azure RBAC assignments at a scope (management group → subscription → resource group → resource), plus PIM activation and deny assignments.
- GCP bindings inherit down the resource hierarchy (organization → folder → project → resource), so an org-level grant silently applies everywhere beneath it.
Non-human identity and credential hygiene
Instance profiles, managed identities, service accounts and OIDC workload federation exist so workloads never hold long-lived keys. Prefer short-lived credentials; require IMDSv2 to blunt SSRF credential theft; hunt secret sprawl in repos, CI variables and container images.
Privilege escalation and trust abuse
Classic paths include iam:PassRole combined with compute creation, iam:CreatePolicyVersion, chained sts:AssumeRole, and cross-account trust policies with a wildcard principal or a missing ExternalId (confused deputy). CIEM surfaces these as identity risk paths, not just as unused permissions.
Least-privilege lifecycle
Discover actual usage → right-size (scope to resource ARNs, add conditions such as aws:PrincipalOrgID or aws:SourceVpce) → enforce → monitor drift. "Unused" should mean unused across a defensible lookback window, not a single day.
Worked example
An EC2 role carries s3:* on *. CIEM shows four of sixty actions used in ninety days, all against one bucket prefix. Reasoning: replace the wildcard with the four actions scoped to arn:aws:s3:::bucket/prefix/*, add an org-ID condition, remove unused actions, confirm no bucket policy independently grants access, then re-baseline. The trust policy stays untouched - it governs assumption, not S3 rights.
Traps that cost marks
Reading a trust policy as a permission grant; ignoring resource-based policies that bypass identity restrictions within the same account; removing "unused" permissions without checking quarterly jobs; forgetting inherited grants in GCP and Azure scopes; treating CIEM as a one-time audit instead of continuous drift detection.