The core idea
When an organization moves to the cloud, a natural assumption is that the provider now “does the security.” That is only partly true. Cloud providers secure some things, customers secure others, and problems often arise in the gap between what each side believes the other is handling.
The shared responsibility model is the common way of describing this division. Providers generally describe it in their own documentation, and the details differ, but the basic pattern is consistent across the industry.
Security of the cloud and security in the cloud
A helpful shorthand separates two ideas:
- Security of the cloud is the provider’s side: the physical data centers, power and cooling, the hardware, the networking equipment and the core software that makes the platform run.
- Security in the cloud is the customer’s side: how they configure the services they use, who they let in, what data they put there, and how they protect it.
An analogy is renting an apartment. The landlord is responsible for the building structure, the main entrance lock and the shared systems. The tenant decides whether to lock their own door, who gets a key and what to leave visible near the window. A secure building does not help much if the tenant leaves the door open.
How the split changes by service type
The boundary moves depending on how much of the technology stack the customer manages, which is why it connects directly to the cloud service models.
| Layer | Infrastructure service (IaaS) | Platform service (PaaS) | Software service (SaaS) |
|---|---|---|---|
| Physical facilities and hardware | Provider | Provider | Provider |
| Core virtualization and network | Provider | Provider | Provider |
| Operating system | Customer | Provider | Provider |
| Application platform and runtime | Customer | Shared or provider | Provider |
| The application itself | Customer | Customer | Provider |
| Configuration of settings and features | Customer | Customer | Customer |
| User accounts and access | Customer | Customer | Customer |
| The customer’s data | Customer | Customer | Customer |
Exact allocations vary between providers and individual services, so this table is a simplification. Two rows stay with the customer in nearly every case: who has access, and the data itself. Even with a fully managed application, the customer chooses who gets an account, how strong their sign-in is and what is shared.
Serverless platforms push even more tasks to the provider, but code, permissions and data remain the customer’s concern.
What customers commonly handle
Depending on the service, customer responsibilities often include:
- Identity and access. Deciding who can sign in and what they can do. Practices like multi-factor authentication and least privilege are usually the customer’s to enable, as are the wider disciplines of identity and access management.
- Configuration. Correctly setting up storage, networks and services. Misconfiguration, such as leaving a storage area open to the public by mistake, is widely reported as a frequent cause of cloud data exposure.
- Data protection. Classifying data, choosing whether and how to use encryption, managing keys, and deciding what is stored at all.
- Software updates. For anything the customer runs, such as an operating system or application, keeping up with software patching.
- Monitoring and response. Watching for unusual activity and having an incident response plan.
- Backup and recovery. A provider’s service being available is not the same as your data being recoverable after a mistake or attack. Customers typically need their own data backup approach.
- Compliance. Understanding what laws and standards apply to the organization, and how the use of cloud services fits. Providers may offer certifications or reports for their part, but these do not make a customer compliant automatically.
What providers commonly handle
Providers typically manage physical security of facilities, hardware maintenance, resilience of core systems, separation between customers, and the security of the platform services they operate. Many publish documentation and independent audit reports describing these controls, which customers can review as part of choosing a cloud service provider.
Where things go wrong
- Assuming the provider covers everything. This leaves access settings, data and configurations unchecked.
- Weak account protection. Stolen or reused passwords remain a major route in. Strong sign-in methods help.
- Excessive permissions. Accounts and automated tools given more access than they need magnify the impact of any mistake or compromise. Insider threats, whether accidental or deliberate, are another reason to limit access.
- Unclear ownership. In larger organizations, no one may be named responsible for particular settings.
- Differences between providers. Teams using more than one provider, as in a multi-cloud setup, must learn each model.
- Changing services. Features and defaults change, so a configuration that was fine once may need review.
Practical questions to ask
- Which parts of this service does the provider secure, and where is that written down?
- Which settings are ours to configure, and who owns each one?
- Who has administrative access, and how is it protected?
- How would we detect and respond to a problem?
- What happens to our data if we need to restore it or leave?
Writing the answers down, and assigning an owner to each customer-side duty, is a simple habit that closes many gaps.
A note on advice
This article is general information, not legal, compliance or IT-security advice. Responsibilities depend on the specific provider, contract and service, so consult qualified professionals.