Tools · Cloud security · 01 / 24
The cloud shared responsibility model explained with real examples
See exactly which security tasks the provider handles and which stay with you for virtual machines, managed databases, and serverless functions.
Security of the cloud versus in the cloud
Every major provider describes the same split. The provider secures the physical data centers, hardware, hypervisors, and the global network: security of the cloud. The customer secures what they build and configure: identities, permissions, data, network rules, operating systems on virtual machines, and application code: security in the cloud.
Where the line falls depends on the service. The more managed the service, the more the provider does, but identity and data configuration always stay with you.
Three services, three lines
On a virtual machine such as EC2 or an Azure VM, you patch the operating system, configure the host firewall, manage SSH keys, and choose what the instance role can do. On a managed database such as RDS or Azure SQL, the provider patches the database engine and operating system, but you choose who can connect, whether it is publicly reachable, whether backups are encrypted, and which users exist. On serverless functions, the provider runs the runtime, and you own the code, its dependencies, its permissions, and any secrets it reads.
Most cloud breaches sit firmly on the customer side: a public storage bucket, leaked access keys, an over-permissive role, or an exposed management port.
Lab: map one workload
Pick a simple workload you might deploy: a web app on a VM with a managed database and a storage bucket for uploads. Write a two-column table listing each security task and who owns it. Then, in a sandbox account, check your side: is the database reachable from the internet, is the bucket blocking public access, and what can the VM’s role do?
The commands below answer those three questions on AWS. They are read-only.
aws rds describe-db-instances --query 'DBInstances[].{id:DBInstanceIdentifier,public:PubliclyAccessible}'
aws s3api get-public-access-block --bucket my-uploads-bucket
aws iam list-attached-role-policies --role-name web-app-roleUsing the model
Use the table in design reviews: every task on the customer side needs an owner and a check. Compliance reports from the provider, such as SOC 2, cover their side only.
When something goes wrong, the model also tells you whom to call. A hypervisor bug is a provider issue. A bucket policy that allows everyone is yours.
Diagram
Who does what, VM versus managed database
The line moves; identity and data stay with you.
Provider. Hardware, hypervisor, network.
You. OS patches, firewall, keys, app, IAM role, data.
Common gap. Unpatched OS, open SSH.
Provider. Hardware, OS, engine patches.
You. Network exposure, users, encryption choices, backups policy.
Common gap. Publicly accessible endpoint.
Check yourself
1. Who patches the guest operating system on a cloud VM?
2. On a managed database service, who patches the database engine?
3. Where do most cloud breaches originate?