Cloud security: the shared-responsibility model, the common findings, and the case studies

Cloud security is the discipline of figuring out who’s responsible for what when the infrastructure isn’t under your roof. The shared-responsibility model that AWS popularized (now adopted in some form by every major provider) divides the work cleanly on paper: the provider secures the data center, the hypervisor, the hardware, and the underlying network; the customer secures everything they put on top of it. In practice the line is blurrier and the customer side is where the engagement findings live. Misconfigured IAM, public S3 buckets, exposed Kubernetes consoles, IMDS abuse, over-privileged service accounts. Every cloud breach in the news for the past decade fits one of those patterns.

This post covers what an operator should know about cloud security as of 2026: the shared-responsibility model, the controls and best practices that actually work (IAM, encryption, network isolation, logging and monitoring), the common findings on engagement, the tooling stack on both red and blue sides, and corrected case studies for the breaches everyone references but few people get the details right on.

A naming note: cloud service names have shifted significantly since the original drafts of posts like this one were written. Azure Active Directory was renamed Microsoft Entra ID in July 2023. Azure Security Center became Microsoft Defender for Cloud in November 2021. Azure Advanced Threat Protection became Microsoft Defender for Identity (the Azure ATP portal was decommissioned in February 2023). Google Cloud Security Command Center is now Security Command Center (SCC) with Standard, Premium, and Enterprise tiers. Google Chronicle became Google Security Operations (Google SecOps) on April 25, 2024. Amazon Inspector v2 replaced the original Inspector (now called Inspector Classic) in late 2021; Inspector Classic stopped accepting new customers May 20, 2025 and support ends May 20, 2026. Where this post uses current names, the older ones are still cited in older vendor documentation; expect the naming to keep shifting.

The shared-responsibility model

#

The cleanest one-paragraph version: the provider is responsible for security of the cloud (data centers, hardware, network fabric, hypervisor, the managed-service software itself). The customer is responsible for security in the cloud (data, IAM configuration, network configuration, OS patching on VMs the customer manages, application code). The split shifts based on the service model. IaaS (EC2, GCE, Azure VMs) puts most of the OS-and-up on the customer. PaaS (Lambda, App Service, App Engine) lifts the OS work onto the provider. SaaS (M365, Workspace, Salesforce) lifts almost everything onto the provider, leaving only data and access control with the customer.

The mistake operators see on engagement is the assumption that “we’re in the cloud” means the provider is handling everything. AWS will not stop you from making an S3 bucket public, will not stop you from giving an IAM role *:* permissions, will not stop you from exposing the EC2 instance metadata service to your application’s SSRF vulnerabilities. The shared-responsibility model says that’s the customer’s job. Most cloud breaches are customers losing track of which side of the line a given control sits on.

Identity and access management

#

IAM is the part of cloud security where the most engagements find the most findings. The three providers’ IAM systems are conceptually similar but architecturally different in ways that bite operators moving between them.

AWS IAM is principal-centric (users, roles, groups) with attached policies that grant permissions. Roles are how services and cross-account access work; the operator-side reality is that most production AWS environments have hundreds of roles with deeply nested trust relationships, and the auditing question is always “could anyone with role X eventually reach role Y.” Tools that map this (CloudMapper historically, modern alternatives like Prowler and Steampipe with the IAM access analyzer) are the operator’s standard kit.

Google Cloud IAM is resource-centric: permissions are granted on resources (projects, folders, organizations) to identities (users, groups, service accounts). The hierarchical inheritance model means a permission granted at the organization level applies to every project under it, which is how most over-permissioning incidents start. Workload Identity Federation lets external identities (Kubernetes service accounts, GitHub Actions tokens, OIDC providers) assume GCP identities without long-lived keys, which has eaten a meaningful chunk of the service-account-key compromise problem since around 2022.

Microsoft Entra ID (formerly Azure Active Directory, renamed July 2023) is the identity layer for everything in the Microsoft ecosystem. It’s also the identity provider that gets phished most often, since M365 accounts are everywhere and Evilginx-class AiTM toolkits target the M365 login flow specifically. Conditional Access policies (location-based, device-based, risk-based authentication) are the modern defense; passkeys (FIDO2) are the only phishing-resistant authentication factor that’s actually held up.

The IAM controls that matter on engagement, regardless of which cloud:

• MFA on every privileged account, with phishing-resistant factors for admins. SMS is the floor; FIDO2 hardware tokens or passkeys are what actually stops AiTM phishing.
• Least-privilege role design. Every role gets exactly the permissions it needs and no more. *:* policies should be reserved for break-glass accounts that are themselves protected by additional controls.
• No long-lived access keys for service accounts. Use workload identity federation, IAM roles assumed via STS, or short-lived OIDC tokens. Long-lived access keys end up in GitHub repos and Slack messages and customer support tickets, where they get harvested.
• Just-in-time elevation for admin access. Tools like AWS Systems Manager Session Manager, GCP Identity-Aware Proxy, or Azure PIM (Privileged Identity Management) issue short-lived elevated permissions on request. The standing-admin model that most environments default to is what most insider-threat incidents exploit.
• Service Control Policies / Organization Policies at the org level. Set guardrails the individual project admins can’t override (no public S3 buckets, no IMDSv1, no resources outside approved regions). The aggregate of org-level policies is what actually keeps a large estate sane.

Encryption

#

Encryption at rest is mostly solved at the provider level. AWS S3, EBS, RDS, DynamoDB; GCP Cloud Storage, Persistent Disk, BigQuery, Cloud SQL; Azure Blob, Disk, SQL Database all encrypt by default. The question is who owns the keys.

The three meaningful tiers:

• Provider-managed keys (SSE-S3, GMEK on GCP, MMK on Azure). The provider handles everything. Convenient, default, no operational overhead. Doesn’t protect against the provider being compromised or compelled to disclose data.
• Customer-managed keys via the provider’s KMS (SSE-KMS on AWS, CMEK on GCP, customer-managed keys on Azure). The keys live in the provider’s HSM-backed key management service, but the customer controls access to the keys. Provides separation between data and key control; you can revoke the data by revoking the key.
• Customer-supplied keys or HYOK (Hold Your Own Key) (SSE-C on AWS, CSEK on GCP, BYOK on Azure). The keys never enter the provider’s environment. Highest control, highest operational overhead, breaks most managed-service integrations because the service can’t decrypt the data without the key. Reserved for regulated workloads where the policy explicitly requires it.

Encryption in transit is TLS by default for everything; the operator-side concern is verifying that the configuration is actually TLS 1.2+ with modern cipher suites and that internal service-to-service traffic isn’t bypassing TLS via plaintext sidecars or proxies.

Encryption in use (Confidential Computing) protects data being processed by an application from the host OS and hypervisor. AWS Nitro Enclaves, Azure Confidential Computing (VMs and Confidential Containers), and GCP Confidential VMs all offer this. Useful for high-regulation workloads; not a default and not something most engagements will encounter outside of finance, healthcare, and government.

Network controls

#

Cloud networking gives the customer roughly the same controls a physical network would: virtual networks (VPC on AWS and GCP, VNet on Azure), subnets, route tables, security groups (instance-level firewalls), network ACLs (subnet-level firewalls), and the ability to private-link services to avoid public internet exposure.

The findings that come up repeatedly on engagement:

• Default VPCs that accept inbound traffic from 0.0.0.0/0 on common ports. Either remove the default VPC or harden it; the new accounts that get created with the default VPC’s permissive rules are how operators get their first foothold.
• SSH and RDP exposed to the internet. Either move them behind Systems Manager Session Manager (AWS), IAP TCP forwarding (GCP), or Azure Bastion, or scope the source IPs to the operator’s VPN.
• Internal services exposed through misconfigured load balancers. The classic ALB or App Gateway routing rule that exposes an internal admin panel because the security group is too permissive on the load balancer side.
• Kubernetes API servers exposed to the internet without authentication. The Tesla 2018 case study is the canonical example. Still happens regularly in 2026.

VPC Flow Logs (AWS), VPC Flow Logs (GCP), and NSG Flow Logs (Azure) are the network-layer telemetry the blue team needs to detect post-compromise lateral movement. Turn them on, ship them to a SIEM, and write detections against the patterns that should never happen.

Logging and monitoring

#

The audit-trail story on each cloud:

• AWS CloudTrail logs all API calls. Always-on by default since 2017 with the 90-day “Event history”; longer retention requires a CloudTrail trail to S3. Should also be configured to log management events to a SIEM.
• GCP Cloud Audit Logs split into Admin Activity (always on, free), Data Access (off by default, expensive when on), System Event (always on, free), and Policy Denied (always on, free). The Admin Activity log is the baseline.
• Azure Activity Log for control-plane operations; Azure Monitor for resource-level metrics and logs. Microsoft Sentinel is the SIEM that ties it all together.

The detection-side products on each cloud:

• Amazon GuardDuty uses ML on CloudTrail, VPC Flow Logs, DNS logs, and EKS audit logs to surface threats. Solid baseline; doesn’t replace the SIEM but catches the common patterns (cryptocurrency mining, port scanning, account compromise).
• Google Security Command Center (the renamed Cloud SCC) with the Premium or Enterprise tier provides similar threat detection plus vulnerability scanning and compliance reporting.
• Microsoft Defender for Cloud (the renamed Azure Security Center, post-November-2021) does the same for Azure plus M365 plus the on-prem servers attached to it.

The SIEM layer for cloud telemetry in 2026:

• AWS Security Hub aggregates findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and third parties.
• Google SecOps (the renamed Chronicle) is Google’s SaaS SIEM, ingesting Cloud Audit Logs plus other telemetry.
• Microsoft Sentinel (the renamed Azure Sentinel) is Microsoft’s SaaS SIEM; eats both Azure-native and third-party logs.
• Splunk, Sumo Logic, Datadog Cloud SIEM, and Panther are the major cross-cloud third-party SIEMs.

The findings every cloud engagement turns up

#

The patterns the operator sees over and over again:

Public S3 buckets (or the equivalent on GCS or Azure Blob). Bucket policies that allow s3:GetObject from Principal: "*". Always check, always findable, has been driving breach disclosures since the 2017 Deep Root Analytics incident exposed 198 million American voter records. Tools to scan: AWS Trusted Advisor, AWS S3 Public Access Block (which you should turn on at the account level), Prowler, and the venerable bucket finder Python scripts.

IMDS abuse. The EC2 Instance Metadata Service (IMDS) lets a workload running on an EC2 instance retrieve the IAM role credentials attached to that instance, by making an HTTP request to http://169.254.169.254/latest/meta-data/iam/security-credentials/. If the workload has an SSRF vulnerability, the operator can use that vulnerability to retrieve the IAM credentials and pivot from web-application access to AWS-account access. This is the Capital One 2019 attack pattern. IMDSv2 (released November 2019) added session tokens that defeat the SSRF pattern, but IMDSv1 is still allowed by default for backward compatibility and a lot of older estates haven’t migrated. Force IMDSv2 at the account level.

Over-privileged IAM roles and service accounts. The pattern is always the same: the role was created with broad permissions during initial development, and nobody scoped it down before production. The blast radius from compromising one over-privileged role can be the entire account. Tools to find the over-privileged roles: AWS IAM Access Analyzer, GCP Policy Analyzer, the IAM analysis modules in Prowler and ScoutSuite. Or do it the hard way and manually walk the role tree.

Exposed Kubernetes consoles and APIs. Kubernetes is where a lot of the lateral-movement work happens. An exposed K8s dashboard without authentication is the Tesla 2018 case. An exposed kubelet API on port 10250 with anonymous access enabled is the Capital One-of-Kubernetes. An exposed kube-apiserver with a guessable bearer token is the same story. Scan for them; they’re still out there.

Long-lived access keys in source control. GitHub’s secret scanning catches a lot of this now, but pre-commit hooks that prevent the commit are better. Tools: gitleaks, trufflehog, GitHub’s native secret scanning, plus the cloud providers’ own scanners (AWS Trusted Advisor flags exposed access keys in some Git public-repo contexts).

Cryptojacking on stolen credentials. Once an attacker has cloud credentials, the highest-ROI use is to spin up large GPU or compute instances to mine cryptocurrency. The Tesla 2018 case fits this pattern. Detect via billing-anomaly monitoring and EDR on the workloads themselves; respond by rotating the credentials and shutting down the instances. Most cloud providers’ threat-detection products (GuardDuty, SCC) catch this within minutes.

Misconfigured serverless functions. Lambda functions with overly broad IAM execution roles, Lambda functions with environment variables containing secrets, Cloud Functions that don’t validate their HTTP-trigger inputs. The serverless attack surface is smaller than the VM attack surface (no OS to patch, shorter runtime) but the IAM-misconfiguration risk is the same.

The operator’s tooling stack in 2026

#

The cloud-security-posture-management (CSPM) tools that operators actually use:

• Prowler (Toni de la Fuente, originally at NCC Group). Open-source, supports AWS, GCP, Azure, Kubernetes, M365. Runs hundreds of checks per provider against benchmarks like CIS, NIST, PCI, HIPAA. Now also offered as a SaaS at prowler.com. Modern operator default.
• ScoutSuite (NCC Group). Open-source multi-cloud auditor. Less actively maintained than Prowler but still useful for second-opinion scans.
• Steampipe (Turbot). SQL interface to cloud APIs. Lets you query your infrastructure with SELECT * FROM aws_s3_bucket WHERE block_public_access IS FALSE style queries. Powerful for ad-hoc analysis and custom compliance reporting.
• CloudMapper (Duo Labs, Scott Piper). The historical AWS-network-mapping tool. Mostly unmaintained as of 2023; mentioned here because the older posts you’ll find still cite it. For new engagement work, Prowler and Steampipe cover the same ground.
• Wiz, Orca, Lacework, Palo Alto Prisma Cloud: the commercial CSPMs that have eaten the enterprise CSPM market. Wiz in particular went from founding (2020) to $32 billion acquisition by Google (announced 2025) in five years, which is the fastest enterprise software exit in history and a reasonable proxy for how much pain organizations are willing to pay to fix CSPM.

For Kubernetes specifically: kube-bench (Aqua Security, CIS benchmark checks), kube-hunter (Aqua, attack-path discovery), kubescape (ARMO, full-cluster Kubernetes security posture), and the cluster’s own Pod Security Standards.

For containers and images: trivy (Aqua), grype (Anchore), clair. SBOM generation: syft (Anchore), cyclonedx-cli.

The DDoS-testing tools that get cited in older posts (LOIC, HOIC, the original Anonymous-era tools from ~2010) are not relevant against any modern cloud DDoS protection in 2026. Cloudflare, AWS Shield Advanced, GCP Cloud Armor, Azure DDoS Protection Standard absorb attacks measured in terabits per second. Modern DDoS testing uses paid services like RedWolf Security or NCC Group’s testing services, or specific layer-7 tools (MHDDoS, hping3 with care) in a tightly-scoped lab. Don’t use the historical tools against cloud infrastructure; they don’t reach the bandwidth required to be useful and they get the operator blacklisted by the provider.

Case studies (corrected)

#

The cloud breaches that get cited the most often, with the actual details rather than the AI-summarized versions.

Capital One (July 2019)

#

The canonical SSRF + IMDSv1 + IAM compromise chain. Paige Thompson, a former AWS Systems Engineer, found a misconfigured ModSecurity Web Application Firewall fronting a Capital One application and used it as an SSRF primitive to reach the EC2 Instance Metadata Service at 169.254.169.254. The IMDSv1 endpoint returned the IAM role credentials attached to the EC2 instance, which had S3 read permissions across a wide set of buckets. Thompson downloaded approximately 106 million customer records (US and Canada) containing names, addresses, dates of birth, credit scores, transaction histories, and roughly 140,000 Social Security numbers.

The technique was not “a misconfigured firewall” in the simple sense; it was the chain of (1) the SSRF vulnerability in the WAF, (2) IMDSv1 being enabled (it was the default at the time), and (3) the EC2 instance role having broader S3 permissions than it needed. IMDSv2 (released by AWS in November 2019, two months after the breach was disclosed) added session tokens specifically to defeat the SSRF-to-IMDS attack pattern. AWS made IMDSv2 the default for new instance launches in 2023. Capital One settled with the OCC for $80 million in August 2020 and paid an additional $190 million class-action settlement. Thompson was convicted of wire fraud and computer fraud charges in 2022.

The defender-side lesson: force IMDSv2 at the AWS account level, scope EC2 IAM roles narrowly, and treat WAF SSRF vulnerabilities as critical even when they only seem to reach internal addresses.

Tesla Kubernetes cryptojacking (February 2018)

#

RedLock (later acquired by Palo Alto Networks and folded into Prisma Cloud) discovered that Tesla’s Kubernetes administration console was exposed on the public internet without authentication. Inside the console, attackers had found AWS access credentials and deployed cryptocurrency mining containers to Tesla’s AWS environment. The miners ran for at least several weeks before discovery, and the attackers were sophisticated enough to throttle mining intensity to avoid CPU-based detection and route traffic through an unlisted mining pool to avoid IP-based detection.

The defender-side lesson: Kubernetes consoles should never be exposed on the public internet, full stop. Use Kubernetes RBAC, run the API server behind a private endpoint, and require authentication for any administration UI. The lesson is exactly the same in 2026 as it was in 2018, and the same exposure still shows up regularly on Shodan.

Marriott / Starwood breach (announced November 2018)

#

The Marriott breach is actually a Starwood breach. The compromise of the Starwood Hotels reservation system began in July 2014, before Marriott’s $13 billion acquisition of Starwood Hotels in 2016. The breach went undetected for over four years until Marriott’s security team flagged unusual database activity on September 8, 2018. Initial reports said 500 million customer records exposed; revised estimates settled at approximately 339 million records globally (about 131.5 million US), including names, addresses, passport numbers, payment card data, and Starwood loyalty account information. The breach was attributed by US and UK government reporting to Chinese state-sponsored actors (specifically the Ministry of State Security, per New York Times and Washington Post coverage), though no specific named threat group has been formally identified in public attributions.

The defender-side lessons: due diligence on the security posture of acquisition targets matters, because you inherit the technical debt and the active intrusions; and long-dwell intrusions in legacy systems are exactly what state-sponsored actors specialize in.

Deep Root Analytics voter data exposure (June 2017)

#

Chris Vickery at UpGuard discovered an unsecured Amazon S3 bucket belonging to Deep Root Analytics, a data analytics firm hired by the Republican National Committee. The bucket contained approximately 198 million American voter records (names, dates of birth, addresses, phone numbers, party affiliations, and various derived analytics fields). The bucket was configured to allow public read access, meaning anyone who knew or guessed the bucket name could download the entire dataset.

The defender-side lesson: turn on S3 Block Public Access at the account level. It defaults to allowing public buckets for backward compatibility, but in 2018 AWS added the account-level setting that overrides per-bucket policies. Apply it and the entire class of “accidentally public bucket” findings disappears.

Docker Hub breach (April 2019)

#

Approximately 190,000 Docker Hub user accounts were exposed via unauthorized access to a single Hub database containing a subset of non-financial user data. Stolen data included usernames, hashed passwords, and the access tokens for GitHub and Bitbucket integrations connected to those accounts. The integration tokens were the more serious exposure, because they allowed the attacker to potentially modify build images and source code in the connected repositories.

The defender-side lesson: integration tokens for OAuth-style flows have a long blast radius. Treat them like passwords (rotate on schedule, revoke on suspicion), and audit which integrations have which permissions on a regular cadence.

What this comes down to

#

Cloud security is mostly the customer’s responsibility regardless of how the provider markets it. The provider gives you the tools to do the work; the work is yours to do. The findings that show up on engagement after engagement (public buckets, IMDS abuse, over-privileged IAM, exposed Kubernetes consoles, long-lived credentials in source control) are the same findings that have shown up since cloud became mainstream, and the case studies show the same patterns repeating at the breach scale.

The defenders who do this well take a few practices seriously. Force IMDSv2 (or the equivalent on other clouds). Scope IAM roles narrowly and audit them on a schedule. Run a CSPM (Prowler at minimum, Wiz or equivalent at scale) and treat its findings as a backlog rather than a wishlist. Ship cloud audit logs to a SIEM and write detections against the patterns that shouldn’t happen. Turn on MFA with phishing-resistant factors for every privileged account. Treat the cloud as a network you can’t fully see, monitor what you can, and assume the unmonitored parts have surprises in them.

The operators on the engagement side keep finding the same things because the same things keep being broken. That’s the entire job.