Understanding Cloud Responsibility

Cloud security depends on making responsibility explicit. In this lesson, you will learn to:

• Explain the shared responsibility model
• Distinguish provider and customer responsibilities across service models
• Identify common unowned security gaps

The service models told you who manages what. This unit takes the same boundary and asks a sharper question: when something goes wrong, who was supposed to have prevented it? That question has a formal answer, and every major provider publishes their version of it. Understanding it is what stops you from being the person in the incident review who says "I assumed the provider handled that."

The shared responsibility model splits security into two halves with a memorable phrasing: the provider is responsible for the security of the cloud, and you are responsible for security in the cloud.

Security of the cloud is everything the provider owns and you can never touch. That means the physical buildings, the locked doors and guards, the servers and disks inside, the network backbone connecting their data centres, the virtualisation layer that carves physical machines into virtual ones, and the internal workings of their managed services. You cannot audit the padlock on their cage, and you don't need to. That half is contractual and comes with certifications.

Security in the cloud is everything you put there and every choice you make about it. That means identity and access, meaning who has accounts and what those accounts may do. It means your data and how you classify it, so that a public marketing image and a patient record are not treated the same way. It means your application code, the configuration of every service you switch on, and your backup policy, meaning how often copies are taken and how long they are kept.

The clearest way to see the split is a real failure. Cloud storage is organised into buckets (some providers call them containers), and each bucket has a setting controlling who may read it. If someone sets a bucket to publicly readable and confidential files appear on the open internet, nothing broke. The provider's storage worked exactly as designed. A customer flipped a switch.

• Nova: The files were exposed for six days. Is the provider going to take responsibility for that?
• Milo: No, and they'll be able to show why. The bucket had a setting for who can read it, and someone on our side set it to public.
• Nova: But it's their storage service.
• Milo: Their storage, our configuration. They're responsible for the building, the hardware, and the service running correctly. We're responsible for what we store in it and who we let see it.
• Nova: So there's no version of this where we're not the ones who answer for it.
• Milo: Not this one. The setting was ours to make.

Notice that Milo never argues about whether the provider is good or bad. He locates the specific control that failed and asks who owned it. That question, not blame, is the whole model in practice.