AWS Security · Domain 4
Identity and Access Management
About 20% of the exam
How a request is evaluated
- Any explicit deny
- SCP and RCP ceiling
- Permissions boundary
- Session policy
- Identity or resource allow
- Explicit deny
- beats every allow, always
- Service control policy
- ceiling on member account principals
- Resource control policy
- ceiling on access to resources
- Permissions boundary
- ceiling on one principal
- Identity policy
- what the principal may do
- Resource policy
- what the resource permits
- Session policy
- narrows the assumed session
- Implicit deny
- the default when nothing allows
Deny wins first, then every ceiling must let it through, and only then does an allow matter
Principals and credentials
- IAM user
- long-lived credentials, avoid where possible
- IAM role
- temporary credentials on every assume
- Instance profile
- delivers a role to EC2
- Service-linked role
- created and owned by a service
- Access key
- programmatic, rotate and monitor
- STS session
- expires, up to twelve hours
- Role chaining
- caps the session at one hour
- Credential report
- age, MFA and key status
Trust policies
- The trust policy says who may assume
- Principal is an account, service or federation
- sts:ExternalId defeats the confused deputy
- aws:PrincipalOrgID keeps assumption internal
- iam:PassRole controls handing roles over
- sts:SourceIdentity carries the human behind it
- Removing the principal blocks new sessions
Organizations guardrails
- Service control policy
- maximum permissions for member principals
- Resource control policy
- maximum access to your resources
- Tag policy
- allowed tag keys and values
- Backup policy
- central backup plans per account
- AI opt-out policy
- excludes data from service improvement
- Management account
- SCPs never apply there
- Organizational unit
- group accounts by guardrail need
- Deny list model
- allow broadly, deny specifics
Permissions boundaries
- A boundary grants nothing by itself
- Effective permissions are the intersection
- Lets juniors create roles safely
- Condition iam:PermissionsBoundary forces the attachment
- Different from an SCP in scope
- Applies to users and roles
Federation and workforce access
IAM Identity Center
- Central workforce access across accounts
- Permission sets become account roles
- SCIM provisions users and groups
- Session duration set per permission set
SAML and OIDC
- AssumeRoleWithSAML for browser federation
- AssumeRoleWithWebIdentity for OIDC tokens
- No IAM user per employee
- Attribute mapping drives tag based access
Workload identity
- OIDC federation from the build provider
- IAM Roles Anywhere uses X.509 certificates
- Task and pod roles beat keys
- Cognito identity pools for app users
Condition keys worth memorizing
- aws:SourceIp
- caller address, not endpoint traffic
- aws:SourceVpce
- request came through that endpoint
- aws:PrincipalOrgID
- caller belongs to your organization
- aws:ResourceOrgID
- resource belongs to your organization
- aws:SecureTransport
- true only over TLS
- aws:MultiFactorAuthPresent
- session was MFA authenticated
- aws:RequestedRegion
- which Region the call targets
- kms:ViaService
- call arrived through that service
Policy grammar traps
- NotAction is not the same as deny
- NotResource widens far more than expected
- Wildcards in Action hide real privilege
- ForAllValues over an empty set passes
- Null tests whether a key exists
- An unresolved variable breaks the ARN
- Deny with a condition can fail open
Access analysis tooling
- Access Analyzer finds external access
- Unused access findings show stale permissions
- Policy generation reads CloudTrail history
- CheckNoNewAccess gates a pipeline change
- CheckAccessNotGranted blocks banned actions
- Last accessed data right-sizes policies
- Policy simulator tests before you deploy
Cross-account access patterns
Role assumption
- Role lives in the target account
- Trust policy names the caller
- Both sides must allow it
- External id for vendor roles
Resource policies
- Bucket policy grants another account
- KMS key policy must allow too
- Lambda function policy for invocation
- Secret resource policy for sharing
Data perimeter
- RCP denies untrusted principals
- Endpoint policy limits identities
- s3:ResourceAccount pins trusted accounts
- aws:PrincipalOrgID on bucket policies
Cross-account access to encrypted data needs the resource policy and the key policy, never just one
Root user and break glass
- Root should hold no access keys
- MFA on root in every account
- Alarm on any root console sign-in
- A few tasks still need root
- Break glass roles stay MFA protected
- Centralized root access removes member root
Least privilege in practice
- Start from deny, add what fails
- Use last accessed data to trim
- Tag based access scales better
- Separate duties across two roles
- Recertify entitlements on a schedule
- An unreviewed entitlement should be revoked
Identity incidents
Leaked key
- Deactivate the key immediately
- Review CloudTrail for its use
- Rotate and redeploy the replacement
Stolen session
- Deny by aws:TokenIssueTime cutoff
- Deleting a key leaves sessions alive
- Fix the trust policy as well
Privilege creep
- Access Analyzer unused findings
- Attach a boundary to the role
- SCP blocks the dangerous action
Service names to know
- Workforce single sign-on
- IAM Identity Center
- App user directory
- Amazon Cognito user pools
- On-premises workloads
- IAM Roles Anywhere
- External access findings
- IAM Access Analyzer
- Temporary credentials
- AWS Security Token Service
- Organization guardrails
- service control policies
- Key and password inventory
- IAM credential report
Rapid recall: which control
- Cap one role
- permissions boundary
- Cap a whole account
- service control policy
- Cap who reaches a bucket
- resource control policy
- Delegate to a vendor
- role plus external id
- Keep humans off keys
- federation into roles
- Prove least privilege
- last accessed data
- Stop the confused deputy
- aws:SourceArn and aws:SourceAccount
Reference strip: evaluation, principals, guardrails, conditions, tooling
Evaluation
- Explicit deny always wins
- Organization policies set the ceiling
- Boundary intersects the identity policy
- Something must explicitly allow
Principals
- Users, groups and roles
- Service and service-linked roles
- Federated and web identities
- Instance profiles carry roles
Guardrails
- SCP, RCP and tag policy
- Permissions boundary per principal
- Session policy on assume
- Endpoint and resource policies
Conditions
- Organization id and Region keys
- MFA present, secure transport
- Source VPC endpoint
- Principal and resource tags
Tooling
- Access Analyzer findings and checks
- Credential report and last accessed
- Policy simulator before rollout
- CloudTrail for every API call
Quick exam traps
- Trap: An SCP by itself grants the accounts in an OU permission to act
- Trap: Deleting an access key ends the role sessions that key started
- Trap: A permissions boundary grants the permissions it lists
- Trap: SCPs restrict the management account like any other account
- Trap: NotAction with Allow behaves the same as an explicit deny
- Trap: A bucket policy alone is enough for cross-account access to SSE-KMS objects
- Trap: Role chaining still gives you a twelve hour session
- Trap: Federated users must exist as IAM users in the account
cybercertprep.com · original revision sheet written from the public body of knowledge