Lesson 1 of 4 · 8 min
The shared responsibility model
Cloud providers secure the infrastructure. You secure what you put in it. Most cloud breaches happen on the customer’s side of that line.
When a file is “in the cloud”, it sits on a server owned by a company you have never met and will never visit. That arrangement splits security responsibility between two parties, and most people never learn where the split falls until something goes wrong. Every major cloud provider documents this split explicitly, because getting it wrong in either direction — assuming the provider covers everything, or trying to secure things the provider already handles — causes real incidents.
Two sides of one line
Amazon Web Services calls its version of this split the shared responsibility model, dividing it into “security of the cloud” and “security in the cloud”. AWS is responsible for the first: “the hardware, software, networking, and facilities that run AWS Cloud services” — the physical data centres, the infrastructure patching, the parts you could never inspect or configure yourself even if you wanted to. The customer is responsible for the second, and AWS is specific about what that includes for cloud storage services: “managing their data (including encryption options), classifying their assets, and using IAM tools” — meaning who is allowed to access it.
The split moves depending on what you use
Microsoft’s documentation makes a point that matters for anyone choosing between different kinds of cloud services: the dividing line is not fixed, it moves depending on the service model. Its responsibility table lists customer data, account identities, and access management as always the customer’s job, in every model, on-premises or cloud. But as you move from infrastructure-as-a-service (renting a virtual machine you configure yourself) toward software-as-a-service (using a ready-made application like an email or file-sharing service), Microsoft takes on more: operating systems, application code, and network configuration increasingly become Microsoft’s job rather than yours. What never moves, in Microsoft’s own words, is that “you always retain” responsibility for your data, your accounts, your client devices, and your access controls.
| Always the customer’s job (per Microsoft) | Depends on the service model |
|---|---|
| Your data: classification, protection, encryption choices | Who manages the operating system (you, in IaaS; the provider, in most SaaS) |
| Identities and user accounts | Network security controls |
| Client devices (laptops, phones) that access the service | Application-level configuration and code |
| Access management: who can reach what, and with what permissions | Physical infrastructure (always the provider’s job once you are in any cloud model) |
Why the customer side matters more than it sounds
For an NGO using a ready-made file-sharing or email service — software-as-a-service, the model where the provider handles the most — it is tempting to assume the provider’s security is now the whole story. It is not. The provider’s side of the line (their servers, their network, their patching) is usually excellent for major services; that is precisely why attackers rarely bother attacking it directly. Instead they target the customer’s side: a weak or reused password, a link shared more broadly than intended, an account with no second factor. Every category on the “always the customer’s job” list above is also, not coincidentally, the subject of the next lesson in this course.
A question worth asking about any cloud service you use
Before trusting a cloud service with sensitive material, it is worth finding its own shared responsibility documentation (major providers all publish one) and asking two questions: what does the provider actually secure by default, and what is explicitly left to me? The answer usually clarifies exactly which of your own habits — covered in the rest of this course — the safety of that data actually depends on.
Key takeaways
- Cloud providers secure the infrastructure (“security of the cloud”); customers secure their own data, identities, and access (“security in the cloud”).
- The exact dividing line shifts by service model: the more ready-made the service (SaaS versus IaaS), the more the provider takes on.
- Your data, your accounts, your devices, and your access controls remain your responsibility in every cloud model, per Microsoft’s own documentation.
- Most real-world cloud incidents happen on the customer’s side of the line — weak passwords, over-shared links, missing multi-factor authentication — not through a break-in to the provider’s infrastructure.
- Every major provider publishes its own shared responsibility documentation; reading it for a service you rely on clarifies what you actually still have to secure.
Check yourself
1. In AWS’s shared responsibility model, what does "security of the cloud" refer to?
- The customer’s passwords and account settings
- AWS’s own infrastructure: hardware, networking, and facilities — Right.
- Third-party apps connected to an AWS account
- Data the customer chooses to encrypt
AWS is responsible for the underlying infrastructure; the customer is responsible for what happens with the services built on top of it ("security in the cloud").
2. According to Microsoft’s documentation, which responsibility never shifts to the provider, regardless of service model?
- Managing the physical data centre
- Patching the underlying operating system in a fully managed SaaS product
- Your data, accounts, devices, and access management — Right.
- Managing the physical network hardware
Microsoft states customers always retain responsibility for their data, identities, client devices, and access controls, across every deployment model.
3. Why do most real-world cloud security incidents happen on the customer’s side of the responsibility line?
- Cloud providers rarely secure their own infrastructure well
- Attackers find it easier to exploit weak passwords or misconfigured access than to breach a major provider’s data centre — Right.
- Customers are legally required to leave their side unsecured
- Shared responsibility does not apply to small organisations
Major providers invest heavily in infrastructure security, so attackers more often target the customer-controlled side: credentials, sharing settings, and access management.
Do it with FireAI
Put this lesson into practice on your own Mac.
- Find out where an app sends data, on the World map — See exactly which company and country one app is quietly talking to.
- Rules: app, website, domain, IP or a range, forever or until you restart — Write a rule as precise as one address or as broad as an entire domain.
- The Threats page: what looks wrong, and why — See the handful of connections worth your attention, instead of scrolling through thousands.
Sources
Put it into practice on your Mac
Try every feature free for 17 days, no card needed.