The core idea
When you use a cloud service, security is divided between you and the provider. The provider secures the cloud itself: the buildings, hardware and core systems it operates. The customer secures what they put in the cloud and how they use it: their data, accounts, settings and often their software.
This split is usually called the shared responsibility model. It is a simple idea with an easy-to-miss consequence: using a reputable provider does not mean everything is protected. Many cloud data exposures come from customer-side settings and account handling, not from the provider’s data centers failing.
An everyday analogy
Renting an apartment is a helpful comparison. The landlord is responsible for the building structure, the main entrance and the shared utilities. You are responsible for locking your own door, not handing out spare keys freely and deciding who you let in. If you leave your door open, a well-built building does not help.
What the provider typically handles
The details vary by provider and product, so read the provider’s own documentation. In general, the provider looks after:
- physical security of data centers, including access controls, power and cooling
- the hardware and the network equipment inside the facilities
- the virtualization layer that separates customers from each other
- the availability and basic security of the underlying services it operates
- for managed services, additional layers, such as the operating system or the application
What the customer typically handles
Regardless of service type, the customer is nearly always responsible for:
- Identity and access. Who has accounts, what they may do, and how they sign in. Strong access management, multi-factor authentication and regular access reviews belong here.
- Data. Deciding what to store, how sensitive it is (see data classification), and whether it is encrypted. Whether data is protected in storage and in transit comes down to data encryption.
- Configuration. Settings for storage, networks and services. A storage container left open to everyone is a classic example.
- Legal and compliance duties. Obligations about personal data stay with the customer, which ties into data privacy and the privacy regulations that apply.
- Endpoints and users. The laptops, phones and people who use the services.
How the split changes by service type
The more the provider runs for you, the more it covers. The service types are the cloud service models, and the security boundary shifts accordingly.
| Task | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical facilities | Provider | Provider | Provider |
| Virtualization | Provider | Provider | Provider |
| Operating system updates | Customer | Provider | Provider |
| Application code and its flaws | Customer | Customer | Provider |
| Configuration of the service | Customer | Customer | Customer |
| Accounts and permissions | Customer | Customer | Customer |
| Data and its classification | Customer | Customer | Customer |
The exact lines vary between products, so treat this as a general guide. Notice that the bottom three rows are the customer’s in every column.
Common mistakes
- Assuming “the cloud” is secure by default. Defaults are sometimes convenient rather than strict.
- Misconfigured storage or networks. Publicly readable storage and wide-open network rules are frequent causes of exposure. Reviewing firewall rules is as relevant in the cloud as elsewhere.
- Weak account protection. Passwords alone, shared logins and forgotten accounts are risky. Administrator accounts need the most care. Unused service accounts should be reviewed too.
- Excessive permissions. Giving everyone broad rights is easy at first and hard to undo. Least privilege and role-based access help.
- No logging or monitoring. If nobody looks at activity records, problems go unnoticed. Good system logs and alerting from system monitoring matter.
- Forgetting backups. The provider’s durability is not a recovery plan. Keep your own backup strategy and do restore testing.
- Leaving accounts after people leave. Prompt account offboarding closes a common gap.
Putting it into practice
A workable way to apply the idea:
- Read the provider’s responsibility description for each service you use, and write down which items are yours.
- Turn that into a checklist and assign owners. Unowned tasks are the ones that get missed.
- Start with identity. Turn on multi-factor sign-in, remove unneeded accounts and limit administrator rights.
- Review configurations regularly. Many providers offer tools that flag risky settings. Use them, and treat the output as a prompt to investigate rather than a guarantee.
- Encrypt and classify data according to how sensitive it is.
- Plan for incidents. Know how you would detect and respond, using an incident response approach that covers cloud accounts too.
- Review after every change such as a new service or a migration.
Contracts and service level agreements describe the provider’s commitments, such as availability, but they usually do not move your own responsibilities to the provider. Having a written policy, as in IT policies and wider IT governance, helps make the customer’s duties explicit.
A note on limits
Following good practice reduces risk but cannot remove it. Threats change, and mistakes happen. The value of the shared responsibility idea is mainly clarity: knowing what you must do yourself so that nothing important is left to a party who never agreed to do it.