Cloud providers rarely get breached. Their customers do, on the side of the line the provider was never responsible for.
The short answer
Cloud security is the set of controls protecting the part of your cloud environment that you configure and operate. The provider secures the physical infrastructure, the hypervisor and the managed services underneath. Everything above that line, meaning your configuration, your identities, your data and your applications, is yours. Almost every publicised cloud incident traces to that upper half.
Knowing where the line sits is the first cloud security control, because you cannot protect an obligation you assumed belonged to someone else.
On this page
The shared responsibility line
Every cloud security conversation should start here, because the model is contractual rather than technical and most teams have never read where it puts them.
Moving up the stack transfers work, not accountability. A managed database removes patching from your list and leaves access control, encryption settings and exposure entirely with you.
Where cloud security breaches happen
| Cause | How it happens |
|---|---|
| Storage left public | A bucket or blob opened for a legitimate reason and never closed. No exploit required, because it is simply readable |
| Over-permissioned identity | A role granted broad rights during setup and never narrowed. One compromised credential then reaches far more than it should |
| Exposed management interface | A database, dashboard or admin console reachable from the internet, often on a default port with a default password |
| Leaked keys | Access keys committed to a repository or embedded in a mobile app. Automated scanners find them within minutes of publication |
| Forgotten resources | A test environment spun up for a prototype, still running months later, unmonitored and unpatched |
None of these are provider failures, and none require a sophisticated attacker. They are configuration and identity problems, which is why cloud security work concentrates there rather than on exotic threats.
It also explains why cloud security spending is often misdirected. A team worried about a sophisticated attacker buys detection tooling while a storage bucket sits open and an unused administrator role from launch week still has full rights. The unglamorous work returns more.
The five cloud security layers
| Layer | What it covers |
|---|---|
| Posture | CSPM continuously checks configuration across accounts and flags what drifted, which addresses the largest single cause above |
| Identity | IAM governs who can do what, PAM controls the administrative accounts, and MFA stops a stolen password becoming access |
| Data | DSPM locates sensitive data including the copies nobody tracked, with encryption and data loss prevention around it |
| Network and access | Zero trust network access keeps management interfaces off the public internet entirely, which removes an entire breach category |
| Workload and application | Web application firewall and API protection in front, with application security controls in the pipeline behind |
Few teams build all five at once, and they should not. Posture and identity together address the majority of realistic cloud security risk, and they are the two that a small team can maintain without a dedicated hire.
CNAPP is the industry’s attempt to sell several of these as one product. The bundle is only worth the premium if it correlates findings across the layers rather than presenting them in adjacent tabs.
Identity is the cloud security perimeter
There is no network edge to defend
In a data centre, the firewall marked the boundary and most controls hung off it. In cloud, resources are reachable by design and the boundary is whatever a set of permissions allows. An attacker with valid credentials is not intruding in any technical sense, they are using the platform exactly as configured, which is why so much cloud activity looks normal in logs until someone examines what that identity had no business touching. Permissions granted during a hurried launch and never reviewed are the most common structural weakness in a young cloud estate.
This is also why detection in cloud depends on correlation rather than signatures. A sign-in, a permission change and a large read from storage are unremarkable individually. Together, in that order, from one identity, they are the shape of an incident, and only a system holding all three event types can see it.
Where Osto fits
Osto covers the customer side of the line across AWS, Azure and GCP from one platform, which for most teams is the entire cloud security requirement in a single place rather than four subscriptions. Posture management runs continuously against all three, flagging public storage, over-permissive rules and drift as configuration changes. Identity and access management with enforced multi-factor authentication narrows what a stolen credential reaches, and zero trust access puts cloud servers behind a private domain reachable only from a managed device, which removes exposed management interfaces as a category rather than monitoring for them.
In front of the applications, the web application firewall and API protection handle live traffic while dependency scanning and static analysis work in the pipeline behind them.
Because all of it runs in one stack, the correlation described above happens by default rather than requiring integration work. An unusual sign-in, a permission change and an outbound transfer arrive in the same SIEM and read as one sequence. The evidence produced covers the configuration, access control and monitoring expectations in SOC 2, ISO 27001 Annex A, PCI DSS and HIPAA.
Platform walkthrough
Cover your side of the line
Multi-cloud posture, identity, zero trust access and application protection in one platform, with every event correlated in one SIEM.
Book a demoEvidence from live controls · 200+ frameworks mapped · One platform, everything
Frequently asked questions
What is cloud security?
The controls protecting the part of a cloud environment the customer configures and operates, spanning posture, identity, data, network access and the applications running there. The provider secures the infrastructure underneath.
Is the cloud less secure than on-premise?
The infrastructure is generally more secure than most organisations could build themselves. The difference is that configuration mistakes are exposed to the internet immediately, so an error that would have been contained inside a data centre becomes reachable by anyone.
What is the shared responsibility model?
The division between what the provider secures and what you secure. The line moves depending on the service type, but identity, access and data always remain your responsibility.
What causes most cloud breaches?
Misconfiguration and identity, not provider failure. Public storage, over-permissioned roles, exposed management interfaces and leaked access keys account for the majority of publicised incidents.
What is the difference between cloud security and CSPM?
Cloud security is the whole discipline. CSPM is one layer within it, focused specifically on finding misconfiguration across accounts. It is usually the right first purchase, but it does not cover identity, data or the applications.