Public cloud protection is the set of controls that secure the workloads, data, and identities you run on a provider like AWS, Azure, or Google Cloud, and the single most important thing to understand is that the provider secures the cloud while you remain responsible for security in the cloud. Most cloud breaches are not sophisticated attacks on the provider's infrastructure. They are misconfigured storage buckets, over-permissioned identities, and exposed services, meaning they are failures on the customer side of that line. Get the boring fundamentals right and you close off the paths attackers actually use.
The mental model that prevents most mistakes is the shared responsibility model, so start there.
The Shared Responsibility Model
Every major cloud provider draws a line between what they secure and what you secure. The provider is responsible for the security of the cloud: the physical data centers, the hardware, the hypervisor, and the managed-service infrastructure. You are responsible for security in the cloud: your data, your identity and access configuration, your network rules, your operating systems on unmanaged instances, and your application code.
The exact line shifts with the service model. For raw virtual machines you own patching the OS and everything above it. For managed databases and serverless functions the provider handles more of the stack, but your data, access policies, and configuration are always yours. The breaches make the news when a customer assumes the provider was handling something that was actually on their side of the line. Know where the line sits for each service you use.
Identity Is the New Perimeter
In the cloud there is no network edge to defend; there is an API that will do whatever a sufficiently privileged credential asks. That makes identity and access management the primary control.
Enforce least privilege ruthlessly. An identity should have exactly the permissions it needs and no more, which is harder than it sounds because broad wildcard policies are easy to write and rarely walked back. Require multi-factor authentication on every human account, especially the root or global-admin identity, which should be locked away and almost never used. Prefer short-lived, role-based credentials over long-lived access keys, and rotate anything long-lived. Most cloud incidents trace back to a leaked or over-permissioned credential, so this is where attention pays off most.
# example: find AWS IAM users with active long-lived access keys to review
aws iam list-users --query 'Users[].UserName' --output text \
| tr '\t' '\n' \
| while read u; do
aws iam list-access-keys --user-name "$u" \
--query 'AccessKeyMetadata[?Status==`Active`].[UserName,CreateDate]' \
--output text
done
Configuration Is Where Breaches Actually Happen
The classic cloud breach is a storage bucket set to public that should have been private. Beyond that: security groups open to the entire internet, databases reachable without authentication, unencrypted volumes, and logging turned off. None of these require an attacker to be clever; they require the attacker to be scanning, which they always are.
Cloud security posture management (CSPM) tooling continuously checks your configuration against known-good baselines and flags drift: a bucket that went public, an encryption setting that got disabled, a port opened to 0.0.0.0/0. The higher-leverage move is to define infrastructure as code and scan those templates before they deploy, so a misconfiguration fails a pull request instead of sitting live in production waiting to be found. Prevention at the template stage beats detection after the fact.
Data Protection and Encryption
Encrypt data at rest and in transit. Every major provider makes at-rest encryption a checkbox or a default, so there is little excuse to skip it, and enforcing TLS for data in transit is table stakes. The harder discipline is key management: use the provider's managed key service, control who can use each key through access policies, and keep key administration separate from data access. Classify your data so the sensitive stores get the strictest controls, and know where your regulated data lives, because residency and compliance obligations follow it across regions.
Visibility and Detection
You cannot protect what you cannot see. Turn on the provider's audit logging (CloudTrail on AWS, Activity Log on Azure, Cloud Audit Logs on GCP) across all accounts and regions, and centralize those logs somewhere an attacker who compromises one account cannot simply delete. Layer on threat detection services that flag anomalous API activity, and maintain an accurate inventory of what you actually run, because shadow resources spun up outside your standard process are exactly where problems hide.
Multi-account or multi-project structure helps here too: isolating workloads into separate accounts limits blast radius, so a compromise in a development account cannot pivot straight into production.
Where the Software Supply Chain Meets the Cloud
Cloud workloads run container images and pull in open-source dependencies, and a vulnerable component shipped into a cloud workload is a cloud exposure even if every bucket is locked down. Scanning images and dependencies before they deploy keeps known-vulnerable code out of your environment; software composition analysis such as Safeguard's SCA covers that layer. The two disciplines meet at the deployment gate: posture checks confirm the environment is configured safely, and composition analysis confirms the code you are deploying into it is not carrying known CVEs. Our common software vulnerabilities guide covers the application side in more depth.
FAQ
What does the cloud provider secure versus what I secure?
Under the shared responsibility model, the provider secures the underlying infrastructure: data centers, hardware, and the virtualization layer. You secure everything you put on top: your data, identity and access policies, network configuration, and, for unmanaged compute, the operating system and applications. The split shifts by service, but your data and access controls are always your responsibility.
What causes most public cloud breaches?
Overwhelmingly, customer-side misconfiguration and identity mistakes: public storage buckets, over-permissioned credentials, exposed services, and leaked access keys. These are far more common than attacks on the provider's own infrastructure, which is why identity and configuration hygiene deliver the biggest risk reduction.
Do I still need to patch if I use managed services?
It depends on the service. For managed databases, serverless functions, and similar offerings, the provider patches the underlying platform. For virtual machines and container hosts you manage, patching the operating system and runtime remains your responsibility. Check the shared responsibility split for each specific service.
How do I keep configuration from drifting into an insecure state?
Define your infrastructure as code and scan those templates before deployment so misconfigurations fail a pull request. Then run cloud security posture management continuously to detect drift in live resources. Combining pre-deployment scanning with ongoing posture monitoring catches both new mistakes and changes made outside your normal process.