Cloud Security
What this domain tests
Cloud Security tests identity, storage, network, logging, and metadata exposure in cloud environments. The shared responsibility model means the provider secures the platform, while the customer secures configuration, identity, and data.
Core rules
- Identity is the perimeter. Prefer roles and short-lived credentials over long-lived access keys. Avoid wildcard actions and resources, and scope trust policies to specific principals.
- Storage controls include bucket policies, object ACLs, public access blocks, and encryption. A private bucket can still contain a public object if the object ACL allows it.
- Instance metadata is sensitive. IMDSv1 can be reached with a simple GET; IMDSv2 requires a token and should be enforced with a low hop limit.
- Security groups and network ACLs are different layers; neither replaces application authorization.
- Enable audit logging and alert on privilege changes, key use, and public exposure.
Worked example
A web application fetches a user-supplied URL. You point it at http://169.254.169.254/latest/meta-data/iam/security-credentials/ and receive the instance role name, then request the credentials path and obtain temporary keys. The reasoning: the server made an outbound request to a link-local address and IMDSv1 did not require a token. The fix is IMDSv2 enforcement, egress filtering, and a destination allowlist after DNS resolution. Also reduce the role's permissions so stolen credentials have limited blast radius.
Traps
- Confusing a public bucket with a public object.
- Missing confused-deputy issues in role trust policies.
- Assuming the provider backs up or encrypts application data by default.
- Forgetting that CI/CD roles and build logs can leak credentials.