What you still own in the cloud: the shared responsibility model

When people first move work to the cloud, a quiet assumption often comes along: "it's in AWS (or Azure, or Google Cloud) now, so it's secure." Half of that sentence is true. The provider really does look after a lot. The other half is yours, and the providers say so plainly in their own documentation.

This post explains where that line sits, using one picture the whole way: renting a flat. The landlord looks after the building. The tenant looks after what happens inside their own front door. And how much counts as "inside" depends on what kind of flat you rented.

First, three words: IaaS, PaaS, SaaS

The standard definitions come from NIST Special Publication 800-145, a short document from September 2011 that describes cloud computing as five essential characteristics, three service models and four deployment models. The three service models are the ones that matter here. In my own words, based on the full text:

• Infrastructure as a Service (IaaS): you get processing, storage and networks, and you can run any software on them, including your own operating system. You don't control the cloud infrastructure underneath, but you do control the operating system, storage and applications you deploy, and possibly some networking pieces such as host firewalls.
• Platform as a Service (PaaS): you deploy your own (or acquired) applications onto the provider's platform, using the languages and tools it supports. You don't manage servers or operating systems, but you control the deployed application and possibly settings for the hosting environment.
• Software as a Service (SaaS): you use the provider's application, usually through a browser. You don't manage the infrastructure or even most of the application, "with the possible exception of limited user-specific application configuration settings."

Notice the pattern: as you go from IaaS to SaaS, the list of things you control gets shorter. It never gets to zero.

The rental flat

Picture three ways to rent a home.

1. An empty flat (IaaS). The landlord gives you a sound building: foundations, walls, the main entrance, the wiring up to your meter. Inside, it's bare. You bring your own furniture, install your own door lock, choose who gets a key, and decide whether the windows stay shut.
2. A furnished flat (PaaS). The landlord also provides the furniture and the appliances and keeps them working. You still decide who gets a key, what you keep in the flat, and whether you leave the balcony door open.
3. A serviced apartment (SaaS). Cleaning, repairs and almost everything else are handled for you. But you still choose who you give your key card to, and you are still the one who leaves a laptop on the table by an open window.

In every version, the landlord can't stop you from handing a spare key to a stranger, and can't tell what you would or wouldn't want lying on your table. Those two things, who has keys and what you leave out, are the tenant's job in every kind of rental. In cloud terms they are identities and data.

                IaaS     PaaS     SaaS              .--.        
                ▀▀▀▀                              .(    ).      
        you  ██▒▒▒▒▒▒▒▒▒ data ▒▒▒▒▒▒▒▒▒██ ┐                     
                                          │                     
        you  ██▒▒ identities & access ▒██ │ always yours        
                                          │                     
        you  ██▒▒▒▒▒ configuration ▒▒▒▒██ ┘                     
                                                                
        you  ██▒▒▒▒▒▒ application ▒▒▒▒▒██                       
                                                                
        you  ██▒▒▒▒▒ OS / runtime ▒▒▒▒▒██                       
             ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ ◄ the line            
   provider  ██░░░░ virtualization ░░░░██                       
                                                                
   provider  ██░░░░░░░ hardware ░░░░░░░██  · · ▪ ·  racks       
                                                                
   provider  ██░░░░░░░ facility ░░░░░░░██  ▁▂▁▂▁                
                                                                

What the providers themselves say

You don't have to take my analogy on trust. All three big providers publish their own version of the split, and they agree on the shape even if the wording differs.

AWS: "of the cloud" versus "in the cloud"

AWS's shared responsibility page uses a neat pair of phrases. AWS is responsible for security of the cloud: the hardware, software, networking and facilities that run its services. The customer is responsible for security in the cloud, and what that means depends on the service you pick.

For Amazon EC2, which AWS describes as IaaS, the customer handles the guest operating system (including updates and security patches), any software they install, and the configuration of the AWS-provided firewall, called a security group. For more abstracted services like Amazon S3 and DynamoDB, AWS runs the infrastructure, operating system and platform, and the customer manages their data, encryption options and permissions.

The same page also sorts controls into three useful groups:

• Inherited controls, which you get entirely from AWS, such as physical and environmental controls.
• Shared controls, where each side does its own part. Patching is the classic example: AWS patches its infrastructure, you patch your guest OS and applications.
• Customer-specific controls, which are entirely yours, depending on what you build.

Microsoft: a table, and four things you always keep

Microsoft's page on shared responsibility gives a table with one row per layer and one column per model (on-premises, IaaS, PaaS, SaaS). Physical hosts, physical network and the physical datacenter move to Microsoft as soon as you are in any cloud model. The operating system moves to Microsoft at PaaS. Applications are marked "shared" at PaaS and SaaS, network controls are "shared" at PaaS (and Microsoft's at SaaS), and client devices become "shared" at SaaS.

Three rows are marked "Customer" in every column: customer data, configurations and settings, and identities and users. The page then lists what you always retain, whatever the deployment type: your data, your endpoints (the laptops and phones that reach the service), your accounts, and access management, which it spells out as role-based access control, multifactor authentication and conditional access policies.

Microsoft also adds a note worth reading twice: it uses "responsibility" in a governance sense (who is expected to configure, operate and monitor a control), and the article is illustrative guidance that does not change the terms of your agreement with them.

Google Cloud: shared responsibility, then "shared fate"

Google's Architecture Framework page describes the same split. For IaaS, most security duties sit with the customer while Google covers the infrastructure and physical security. For PaaS, Google takes on more, IAM and application-level controls are shared, and the customer keeps data security and client protection. For SaaS, Google owns most duties, but the customer still manages access controls and the data they store.

Google's one-line summary matches the rental picture: the provider always remains responsible for the underlying network and infrastructure, and customers always remain responsible for their access policies and their data.

Google then goes one step further with an idea it calls shared fate: the provider takes an active part in helping customers get their half right, instead of drawing a line and stepping back. In practice that means things like secure-by-default blueprints (the enterprise foundations blueprint and landing zone guides), tools such as Assured Workloads and Security Command Center, and a Risk Protection Program run with cyber insurers. In flat terms, it's a landlord who doesn't just fix the roof but also leaves you a good lock, a checklist and an honest look at your windows.

What is always yours

Put the three pages side by side and the same short list falls out:

The middle layers (application, OS, network controls) move between you and the provider depending on the model. The bottom layers (hardware, facility) belong to the provider in every cloud model.

Where the gaps usually are

Here is the part that matters for day-to-day security. The provider's half is built and run by large specialist teams. The customer's half is set by whoever clicked through the console that afternoon. Google's page lists misconfiguration among the challenges of shared responsibility, noting that many cloud breaches result from it, and the common gaps all live on the tenant's side of the line.

1. Storage left open to the public

The classic case is a storage bucket that anyone on the internet can read. The providers have moved their defaults toward safety. Since April 2023, new Amazon S3 buckets have Block Public Access turned on and ACLs disabled by default, and for Azure Resource Manager storage accounts, anonymous access to blob data is prohibited by default.

But a default is only where the switch starts. The S3 documentation is clear that users can still change bucket policies or object permissions to allow public access, and that removing a Block Public Access setting makes a bucket with a public policy public again. AWS recommends turning on all four Block Public Access settings at the account level so that they cover current and future buckets.

 INTERNET                /              ╎                       
                        /               ┆                       
            ┊          /                ┆                       
            ┊         /                 ┆   ┌─────┐  ┌─────┐    
            ┊        /                  ┆   │ · · │  │ ▪ ▪ │    
            ┊       ┌──────────┐        ┆   │     │  │     │    
            ┊       │ ▤  ▤  ▤  │        ┆   │ ▪ · │  │ · ▪ │    
            ┊       │ ▤  ▤  ▤  │        ┆   │     │  │     │    
            ┊       └──────────┘   o─┬  ╎   └─────┘  └─────┘    
            ┊         bucket      key   ╎                       
            ┊      public: yes          ╎    locked  ✓          
            ┊                           ╎                       
                                        ╎                       
               YOUR HALF                ╎    PROVIDER'S HALF    

2. Roles that can do far too much

The second gap is identities with more permission than they need. AWS's IAM best practices start with temporary credentials for people and workloads, require MFA wherever an IAM user or the root user is still needed, and then come to the core idea: grant only the permissions required to perform a task, and work toward least privilege as a workload matures. The same page notes that AWS managed policies are written for all customers, so they might not be least-privilege for yours, and suggests using IAM Access Analyzer to generate policies from actual activity and to find public and cross-account access.

In flat terms: don't hand out master keys when someone only needs to water the plants.

3. Logs you assumed were there

The third gap shows up only after something goes wrong: you go looking for the record of who did what, and it isn't there, or it doesn't go back far enough.

• On AWS, CloudTrail event history is on by default, but it keeps 90 days of management events per Region and doesn't show data events. For an ongoing record, you create a trail or an event data store yourself.
• On Google Cloud, Admin Activity audit logs are always on, but Data Access audit logs are disabled by default for all services except some BigQuery services. If you want to know who read your data, you have to turn that on.

The provider runs the logging service. Deciding what to keep, for how long, and who looks at it is your half.

And for SaaS?

SaaS feels like the provider does everything, but identities, data and settings are still yours. That's why CISA's Secure Cloud Business Applications (SCuBA) project publishes secure configuration baselines for Microsoft 365 and Google Workspace, with free tools (ScubaGear and ScubaGoggles) that check a tenant against them. Even in the serviced apartment, someone has to check the windows.

A responsibility table you can adapt

Here's a starting table built from the three providers' pages. It's deliberately simplified. Treat it as a conversation starter for your own team, and check your provider's page for each service you use, because the split can differ from one service to the next.

A practical way to use it: add a column called "Who on our side?" and write a name or a team next to every "You" and "Shared" row. Any row where nobody can answer is a row worth looking at this week.

The short version

The landlord keeps the building standing, and does it well. Whatever kind of flat you rent, the keys you hand out, the things you leave on the table and the windows you leave open are still yours. The cloud doesn't remove those jobs. It just makes them easier to forget.

Sources

• NIST SP 800-145, The NIST Definition of Cloud Computing (publication page)
• NIST SP 800-145, full text (DOI)
• AWS, Shared Responsibility Model
• Microsoft Learn, Shared responsibility in the cloud
• Google Cloud Architecture Framework, Shared responsibilities and shared fate on Google Cloud
• AWS News Blog, Heads-Up: Amazon S3 Security Changes Are Coming in April of 2023
• Amazon S3 User Guide, Blocking public access to your Amazon S3 storage
• Microsoft Learn, Remediate anonymous read access to blob data
• AWS IAM User Guide, Security best practices in IAM
• AWS CloudTrail User Guide, Working with CloudTrail event history
• Google Cloud Logging, Enable Data Access audit logs
• CISA, Secure Cloud Business Applications (SCuBA) Project