Somewhere along the way, folks started treating “move it to the cloud” like a security strategy. It’s not. The cloud is someone else’s computer — and while that someone else is very good at securing the physical hardware, the networking fabric, and the hypervisor layer, everything you put on top of it is still your problem. Your misconfigurations. Your overpermissive IAM roles. Your S3 bucket that’s been publicly readable since 2019. The cloud didn’t make you less secure. It made you differently secure. And if you don’t understand exactly where the provider’s responsibility ends and yours begins, you’re rolling dice with other people’s data.

The TLDR

Cloud computing doesn’t eliminate security risk — it redistributes it. The shared responsibility model defines a line: below it, the cloud provider handles physical security, networking, and infrastructure. Above it, you own your data, identity management, access controls, and configurations. Most cloud breaches aren’t provider failures. They’re customer misconfigurations. Understanding where that line is — and what lives on your side of it — is the difference between a secure cloud deployment and a headline.

The Reality

The breach pattern is depressingly consistent. An S3 bucket left open. An IAM role with admin privileges attached to a Lambda function that didn’t need them. An EC2 instance metadata service queried by an SSRF vulnerability that coughed up temporary credentials. These aren’t exotic zero-days. They’re configuration mistakes at scale.

Capital One, 2019. A misconfigured web application firewall allowed an attacker to exploit the AWS metadata service (the now-infamous 169.254.169.254) and steal temporary credentials. Over 100 million records exposed. AWS infrastructure wasn’t breached — Capital One’s configuration was. MITRE ATT&CK T1552.005 — Cloud Instance Metadata API — documents this exact technique.

Twitch, 2021. An internal server misconfiguration exposed 125 GB of data, including source code and creator payout information. Not a sophisticated attack. A configuration gap.

Microsoft, 2023. A compromised signing key allowed threat actors to forge Azure AD tokens and access email accounts across multiple organizations including government agencies. The machine broke where nobody was watching.

According to Gartner’s research, through 2025, 99% of cloud security failures would be the customer’s fault. That number hasn’t improved.

How It Works

The Shared Responsibility Model

Every major cloud provider publishes a shared responsibility model. The concept is the same across all three; the details shift based on the service tier.

The Provider Secures:

You Secure:

IaaS vs PaaS vs SaaS — The Line Moves

The more managed the service, the more responsibility the provider absorbs — but you never hand off data classification, access management, or compliance.

IaaS (EC2, Azure VMs, GCE): You get a virtual machine. You own the OS, the patching, the firewall rules, the applications, the data. The provider owns the iron underneath.

PaaS (Lambda, Azure Functions, Cloud Run): The provider manages the runtime and OS. You own the code, the data, and the IAM configuration. Less surface area, but the configs you do control become more critical because there are fewer of them.

SaaS (Microsoft 365, Google Workspace, Salesforce): The provider manages almost everything. You still own identity management, data access policies, sharing settings, and what gets stored where. Every “share with anyone with the link” default is a you-problem.

NIST SP 500-292 — the Cloud Computing Reference Architecture — defines these service models formally and maps responsibilities. The Cloud Security Alliance (CSA) Cloud Controls Matrix maps specific security controls to each model.

Cloud-Native Security Controls

Every provider gives you the tools. Whether you use them correctly is another story.

IAM Policies: The most powerful and most dangerous control in your cloud environment. A single overpermissive policy — "Effect": "Allow", "Action": "*", "Resource": "*" — grants god mode to whatever principal it’s attached to. OWASP’s Cloud-Native Application Security Top 10 lists insecure IAM as a top risk.

Security Groups & NACLs: Your cloud firewall. Security groups are stateful (return traffic automatically allowed), NACLs are stateless (you define both directions). Default-deny inbound, explicit-allow only what’s needed. This is basic — and still misconfigured constantly.

VPC Design: Your network segmentation in the cloud. Public subnets for load balancers, private subnets for application and database tiers, no direct internet access to backend resources. If your database has a public IP, something went very wrong.

Encryption: At rest (server-side encryption with provider-managed or customer-managed keys) and in transit (TLS everywhere, no exceptions). NIST SP 800-175B applies here as much as anywhere.

Identity Is the New Perimeter

In cloud environments, there’s no corporate firewall to hide behind. Identity — who you are, what you’re allowed to do, how that’s verified — is the security boundary. Every API call is authenticated. Every action is tied to a principal. If an attacker compromises a credential, they don’t need to “break in” — they just log in.

This is why IAM isn’t just important in the cloud. It IS the security model.

CSPM — Watching the Watchers

Cloud Security Posture Management tools continuously scan your cloud environment for misconfigurations, compliance violations, and drift from security baselines. AWS Security Hub, Azure Defender for Cloud, GCP Security Command Center — each provider has a native option, and third-party tools like Prowler, ScoutSuite, and Wiz fill the gaps. You can’t secure what you can’t see, and cloud environments change fast enough that manual auditing is a losing game.

How It Gets Exploited

S3 Bucket Misconfigurations

The classic. A bucket created with public access, or a bucket policy that grants s3:GetObject to *. Automated scanners trawl the internet for these constantly. The data inside has included customer PII, medical records, military intelligence, and source code. AWS has added increasingly aggressive guardrails (S3 Block Public Access, account-level defaults), and people still find ways to misconfigure them.

Over-Permissive IAM

When a developer needs access quickly, the path of least resistance is a broad policy. AdministratorAccess attached to a service account that runs a single Lambda function. A role assumable by any principal in the account. Permissions that were “temporary” three years ago. The principle of least privilege isn’t just a CISSP talking point — it’s the single most effective control in cloud security. CIS Benchmarks for AWS, Azure, and GCP all flag overpermissive IAM as a critical finding.

Instance Metadata Service Exploitation

The metadata service at 169.254.169.254 is how cloud instances discover their own identity, network configuration, and — critically — temporary security credentials. If an application running on that instance has an SSRF vulnerability, an attacker can query the metadata service through the application and steal those credentials. AWS IMDSv2 mitigates this by requiring a session token, but IMDSv1 is still the default in many configurations. MITRE ATT&CK T1552.005 documents this technique explicitly.

Credential Leaks in CI/CD

Hardcoded AWS access keys in GitHub repos. Service account JSON files committed to version control. Environment variables logged to plaintext CI output. The CISA advisory on CI/CD security risks has flagged this pattern repeatedly. Automated scrapers find exposed credentials within minutes of a public commit.

What You Can Do

Know where the line is. Read your cloud provider’s shared responsibility documentation. Understand exactly what they secure and what’s on you. If you’re running IaaS, you own more than you think.

Enforce least privilege IAM. Every role, every policy, every service account — scope it to exactly what’s needed. Use IAM Access Analyzer (AWS), Entra ID access reviews (Azure), or IAM Recommender (GCP) to find and remove excess permissions. No principal should have *:* unless you can justify it in writing.

Enable logging and don’t turn it off. AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs — these are your forensic record. If someone compromises your environment and you don’t have logging enabled, you won’t know what they did or when they did it. Ship logs to a separate account that the compromised environment can’t modify.

Apply CIS Benchmarks. The Center for Internet Security publishes free, detailed benchmarks for AWS, Azure, and GCP. They tell you exactly what to configure and why. Run them. Remediate. Run them again.

Use CSPM tooling. Automated posture management catches the drift that manual reviews miss. Whether it’s native (Security Hub, Defender for Cloud) or third-party, continuous scanning is non-negotiable in environments that change hourly.

Block public access by default. S3 Block Public Access at the account level. Azure Storage default to private. GCP uniform bucket-level access. Make public access an explicit, documented exception — not a default.

Enforce IMDSv2. If you’re running EC2, require IMDSv2 at the instance level or the account level. It’s one setting that eliminates an entire class of credential theft attacks.

Sources & Further Reading