The cloud provider secures the cloud; you secure what you put in it — and almost every cloud breach is a customer-side misconfiguration. Learn where your responsibility starts and what "cloud posture" means.
Cloud security is split: the provider secures the infrastructure (hardware, hypervisor, managed-service internals), and you secure everything you configure on top — identity, data, network rules, and application code. Nearly every headline cloud breach is on the customer side of that line: a public bucket, an over-permissive role, an exposed database. Knowing exactly what is yours to secure is the first control.
Responsibility shifts with the service model:
IaaS (EC2) PaaS (RDS) SaaS
data + access YOU YOU YOU <- always yours
app / config YOU YOU provider
OS / runtime YOU provider provider
hypervisor / hw provider provider provider
The line moves, but IDENTITY, DATA, and NETWORK CONFIG are ALWAYS
yours. That is exactly where the breaches happen.On-prem, an attacker had to get through a network perimeter. In the cloud, the control plane is an internet-facing API, so a single wrong setting — a public storage bucket, a security group open to the world, a leaked access key with broad rights — is directly exploitable from anywhere. The adversary is not breaking in; they are logging in or reading what you left open.
The four misconfigurations behind most cloud incidents:
1. Public data store S3/blob bucket set public -> data leak
2. Over-broad IAM a role/key with Action:"*" -> total compromise
3. Open network security group 0.0.0.0/0 -> SSH/DB/RDP -> brute force
4. Leaked credentials access key in git/logs -> instant account access
Notice: none require an exploit. They're settings. So cloud security
is largely about finding and fixing settings at scale -> "posture".Cloud Security Posture Management (CSPM) is the practice of continuously checking your cloud configuration against a known-good baseline and fixing the drift. Because settings change constantly and accounts sprawl, you cannot audit by hand — you scan. This lesson frames the goal; lesson 5 runs the actual tools. Posture is the cloud-native equivalent of the system-hardening baseline.
Posture management loop (continuous, not one-time):
define baseline (CIS Benchmark, org policy)
|
scan the account for drift <-- Prowler / ScoutSuite / native (lesson 5)
|
prioritize findings (public data + broad IAM first)
|
remediate (fix the setting, ideally in the IaC, not the console)
|
prevent recurrence (IaC scan in CI + guardrails) --> back to scan
You'll automate this loop across every account and region.A fix clicked into the console drifts back the next time someone applies infrastructure-as-code — and leaves no audit trail. The durable fix lives in the IaC (Terraform, CloudFormation) and is checked by an IaC scanner in CI before it ever deploys. This ties cloud security to the DevSecOps Pipeline: the same misconfigurations become build-time failures.
Two ways to fix a public bucket:
Console click: fixed now, but drifts back on next 'terraform apply',
no review, no record of who/why.
In the IaC: the desired state IS private; a scanner (Checkov/tfsec)
fails the PR if someone makes it public. Durable + reviewed.
Rule: the cloud's source of truth is your IaC repo. Remediate there.
Manual console changes are incidents waiting to un-happen your fix.