The Shared Responsibility Model

In the cloud, you do not deploy "on a server you control" — you rent capability, and the vendor's legal and operational boundaries define your slice of the security job. The Shared Responsibility Model is that split: the provider secures of the cloud (physical data centers, the hypervisor, the network fabric, the storage and compute infrastructure under its control), and you secure in the cloud (your accounts, IAM, data, configurations, applications, and the OS and network settings of what you run). A misconfigured S3 bucket is nobody's fault but yours — the provider built it to be locked, not to be open.

The Big Four Cloud Threats

  • Misconfiguration: public S3 buckets, open security groups (an AWS SG allowing 0.0.0.0/0 on 3306 is an "open database"), default passwords, and disabled auditing. It is historically the most common cause of data exposure.
  • Broken IAM / Identity: over-privileged roles, long-lived static keys, a root/owner account used for daily work, cross-account trust granted too wide. The password lesson meets the cloud: the blast radius of one stolen key is the size of its role.
  • Exposed services: databases, Kubernetes API servers, and storage consoles reachable from the internet because an SG or firewall rule says so.
  • The metadata beast: the instance-metadata SSRF (from the SSRF lesson) that hands out cloud role credentials to anything on the box.

IAM Is the Central Control

Everything in the cloud is an API call authorized by identity. So the hierarchy is your security: root only for billing (use it to create one admin role, then lock it — hardware MFA — and never touch it again); roles over static keys (attach the least-privilege role to the workload; even better, short-lived tokens via OIDC federation so the workload has no permanent secret at all); and groups over individuals so permission changes happen in one place. List who can do what, and set alarms when a role is created or a policy changes — the incident-response feed starts at identity-record changelogs.

Data, Keys, and Encryption at Rest=In the Cloud

Encrypt everything you store, at-rest, with KMS-style key management where the provider guards the key material in hardware and you control the policy (including who can use which key). Keep secrets out of code and container images — they belong in a secrets manager (Vault, the provider's parameter store), referenced at runtime, never baked. Prefer managed services over self-managed where security budget is thin: a managed database comes with built-in backups, encryption defaults, and patching, whereas the same workload hand-rolled on a VM inherits every OS-weekly patching problem in the pen-testing lesson.

Auditing: The Compliance View

The start of every cloud audit is a question your provider answers for you: "what is my actual inventory, and what is exposed?" The answer is a cloud-security scanner — Checkov, ScoutSuite/Prowler, s3 ls --recursive, and the provider's native AWS Config / Cloud Security dashboards. Run them continuously (CI + scheduled), harden against a published benchmark (CIS industry benchmarks map directly to cloud controls), and export logs to an immutable store so the incident-response lesson's "who did what when" trace exists before it is needed. In the cloud, the perimeter you control is your IAM policy and your bucket ACLs — everything else about the "castle" is rented.