Public, private, community, hybrid — and who is actually responsible for what. The shared responsibility model is the contract that defines cloud security obligations for every workload.
⚡ Quick Bite · 20s
APIs are your biggest cloud security risk — rate-limiting and strong authentication as essential gatekeeping mechanisms for every endpoint.
Watch this 20-second summary before diving into the full article. Sign in to earn 5 leaderboard points.
Where your cloud infrastructure lives determines your control, your compliance posture, and your attack surface.
Infrastructure is owned and operated by a third-party provider and shared among multiple tenants. AWS, Azure, and GCP are public clouds. Capital expenditure drops to zero; operational expenditure scales with usage. The trade-off: you have no physical access and must trust provider security certifications (SOC 2, ISO 27001, FedRAMP).
Dedicated infrastructure for a single organisation, either on-premises or hosted. OpenStack and VMware vSphere are common platforms. You control the hardware but absorb the full cost of capacity planning, maintenance, and security. Proxmox VE is used as the private-cloud platform in this course.
Shared infrastructure among organisations with common concerns — a government cloud, a healthcare cloud. NIC MeghRaj (India) is a community cloud for government departments. Compliance requirements align; cost is shared.
A composition of two or more cloud models connected by technology that enables data and application portability. A hospital might keep patient records in a private cloud and use public cloud for burst compute. Security policies must span the boundary consistently.
| Strategy | Description | Key Security Risk |
|---|---|---|
| Rehost (Lift-and-shift) | Move workloads to cloud VMs as-is | Legacy vulnerabilities migrate unchanged |
| Replatform | Minimal changes to leverage managed services | Misconfigured managed service settings |
| Refactor | Redesign for cloud-native architecture | Larger change surface during transition |
| Retire | Decommission systems | Incomplete data deletion |
| Retain | Keep on-premises | Hybrid connectivity expands attack surface |
The shared responsibility model defines what the cloud provider secures and what you must secure. It shifts depending on the service model.
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical infrastructure | Provider | Provider | Provider |
| Hypervisor / runtime | Provider | Provider | Provider |
| Operating system | Customer | Provider | Provider |
| Application code | Customer | Customer | Provider |
| Data | Customer | Customer | Customer |
| Identity & access | Customer | Customer | Customer |
| Network controls | Shared | Provider | Provider |
The most common cloud breach pattern: A customer misunderstands the shared responsibility boundary and leaves a layer they own (usually data or identity) without adequate controls.
An S3 bucket's access control is entirely the customer's responsibility. AWS secures the underlying storage hardware and provides the tools (bucket policies, ACLs, Block Public Access). When Capital One was breached in 2019, the attacker exploited an overly permissive IAM role — a customer responsibility, not AWS's. The provider was not liable.
Before deploying any workload to the cloud, map every component of your stack against the shared responsibility model. Document what you own. Treat provider-managed layers as trusted but not your problem to patch — and treat customer-managed layers as entirely your problem regardless of how the provider markets the service.
Sign in to mark this article as read and track your progress.
