Shared responsibility in cloud: what your provider secures vs you

TL;DR — In the cloud, your provider secures the underlying cloud systems, but you still secure what you put in them: accounts, app settings, data, access rules, backups, and day-to-day operations. The most useful rule of thumb is: if you can configure it, upload it, invite someone to it, or delete it, it is probably your responsibility. Reading time: ~7 min

What it is and where it sits

The shared responsibility model is the boundary between what the cloud provider protects and what you still must protect yourself.

A simple way to picture it:

• The provider secures the cloud itself: buildings, power, networking hardware, storage hardware, host machines, and the core services they run.
• You secure what you run in the cloud: user accounts, passwords, app code, database contents, firewall rules (network traffic filters), backups, and business decisions about who should access what.

This matters because many teams hear "it's in the cloud" and assume security is mostly handled. It is not. The provider usually prevents someone from walking into a data center and stealing a disk. They do not usually stop your employee from reusing a weak password, your app from exposing customer data, or your database from being left open to the internet.

Where it sits in a typical architecture

In a normal web app, a customer request passes through several layers. Some are mostly the provider's problem; some are mostly yours.

[User Browser] ---- 1. HTTPS request ----> [DNS/CDN]
                                         |
                                         | 2. route request
                                         v
                                   [Load Balancer]
                                         |
                                         | 3. forward
                                         v
                                      [App]
                                         |
                                         | 4. query
                                         v
                                    [Database]
                                         |
                                         | 5. store backups/logs
                                         v
                              [Object Storage/Backup]

In that flow:

• DNS/CDN (domain routing/content delivery): the provider runs the service, but you still control records, TLS certificate choices in many setups, caching rules, and who can edit them.
• Load balancer (traffic distributor): the provider runs the appliance/service; you choose which ports are open and where traffic goes.
• App: if you deploy code, dependencies, environment variables, and admin accounts, that is your responsibility.
• Database: the provider may patch the database engine in a managed service, but you still decide who can log in, whether data is encrypted with your chosen settings, retention periods, and whether backups are tested.
• Object storage/backup: the provider keeps the storage service alive; you decide whether buckets are public, whether old backups are deleted, and who can restore them.

What it replaces

It does not replace having your own security practices. It replaces only the parts of security that used to be about owning physical servers and networking gear yourself.

If you used to run servers in your office, you were responsible for the building, locks, power, disks, and operating system. In the cloud, some of that moves to the provider. But identity, data handling, app behavior, and access control do not disappear.

How it actually works

The model changes depending on what you buy.

• Infrastructure as a Service (IaaS): virtual machines, disks, networks. Provider secures hardware and virtualization layer; you secure the operating system, patches, firewall rules, runtime, and app.
• Platform as a Service (PaaS): app hosting or managed databases. Provider secures more of the stack; you still secure identities, data, configuration, secrets, and app behavior.
• Software as a Service (SaaS): email, CRM, file sharing. Provider secures the application platform; you still secure users, MFA (multi-factor authentication), sharing settings, retention, and exported data.

One realistic end-to-end example: a managed database exposed by bad configuration

Imagine your agency deploys a customer portal:

• frontend app hosted in the cloud
• managed Postgres database
• object storage for file uploads
• team members log in to the provider dashboard to manage it

Here is how responsibility plays out, step by step.

1. The provider secures the physical database host. They handle the data center, failed disks, host operating system for the managed service, and database engine patching if it is a fully managed database.
2. Your team creates the database. In the provider dashboard, this is usually something like Databases → Create database. During setup, you choose whether it is reachable only from private app networks or from the public internet.
3. A developer enables public access for convenience. This is often a toggle like Connectivity → Public access → On or a network rule allowing 0.0.0.0/0 (all IPv4 addresses). That decision is yours, not the provider's.
4. The app stores the database password in a plain text note or chat message. Again, your responsibility. The provider did not leak it; your process did.
5. An attacker finds the open database port and logs in using stolen credentials. The provider's infrastructure may be working perfectly. This is still a security incident in your environment.
6. Backups exist, but nobody tested restore. The provider may have successfully created snapshots, but if you never tried restoring one, you do not know whether you can recover quickly.
7. Audit logs show who changed the network rule. Most providers log control-plane actions (dashboard/API changes). Reading and acting on those logs is your job.

The lesson is concrete: the provider can secure the service platform while your configuration still creates risk.

The practical checklist hidden inside the model

For almost every cloud service you buy, ask these exact questions:

• Who patches the operating system and runtime?
• Who controls user accounts and MFA?
• Who sets network exposure: private only, office IPs only, or public internet?
• Who manages secrets like API keys and database passwords?
• Who decides backup retention and tests restore?
• Who reviews logs and alerts?
• Who classifies the data and decides whether it should be there at all?

If the answer is "us," that is your side of the shared responsibility line.

When to use it (and when not to)

You do not "adopt" the shared responsibility model as a product. It applies automatically when you use cloud services. The real decision is how much responsibility you want to keep by choosing one service model over another.

You probably don't need this if...

More precisely: you probably do not need to run lower-level cloud infrastructure if:

• your application is standard web software
• you do not need custom networking
• your team cannot commit to patching, monitoring, and access reviews
• your main goal is reliability and speed, not deep infrastructure control

In that case, ask your agency for a design that uses managed app hosting, managed databases, and a small number of admin accounts protected by MFA.

Trade-offs

Every reduction in responsibility usually costs money or flexibility.

The mistake to avoid is wanting the control of raw infrastructure with the effort level of SaaS. Usually you must choose one side to optimize.

In practice

Below are two concrete examples you can adapt today. The first uses a provider dashboard path because that is how many non-engineering teams actually work. The second shows the equivalent kind of control in config/CLI.

Example 1: Lock down who can reach a database

In your provider's dashboard, look for a path similar to:

• Databases → your database → Connectivity / Network / Security
• Turn Public access off, or
• Replace Allow from anywhere with specific source IPs, office IPs, or your app's private network

If your provider shows firewall-style rules, the safe pattern is usually:

{
  "inbound_rules": [
    {
      "protocol": "tcp",
      "port": 5432,
      "source": "10.0.0.0/16",
      "description": "Allow Postgres only from private app network"
    }
  ]
}

This represents the idea you want: allow Postgres traffic only from your private app network, not the whole internet. Gotcha: if you lock this down before confirming where your app actually connects from, you can break production traffic.

⚠️ Changing network rules can cause immediate downtime if your app currently connects from a public IP you forgot to allow.

If your team uses a CLI for cloud firewalls or security groups, the equivalent pattern often looks like this:

# Example pattern only: remove world-open Postgres and allow only app subnet
cloud-cli firewall delete-rule --port 5432 --source 0.0.0.0/0
cloud-cli firewall add-rule --port 5432 --source 10.0.0.0/16 --protocol tcp

This removes internet-wide access and replaces it with app-network-only access. Gotcha: command names vary by provider, so treat this as a template and use your provider's help pages for the exact syntax.

Example 2: Enforce MFA and reduce admin access

In your provider dashboard, look for a path similar to:

• Account / Organization → Users / Members
• Security → Multi-factor authentication
• Roles / Permissions

The target state is:

1. Turn on required MFA for all users.
2. Change daily users from full admin to narrower roles like billing-only, read-only, or database-operator.
3. Remove former employees and unused service accounts.

If your identity system supports policy files, a simple example looks like this:

{
  "mfa_required": true,
  "session_max_hours": 8,
  "roles": {
    "finance@example.com": ["billing.read", "billing.write"],
    "devlead@example.com": ["app.deploy", "logs.read", "db.connect"],
    "auditor@example.com": ["logs.read", "config.read"]
  }
}

This shows the principle of least privilege: people get only the permissions they need. Gotcha: broad legacy admin roles often exist because nobody mapped real job needs, so expect one cleanup pass after users report missing access.

Example 3: Backups are your responsibility only if you can restore them

If your managed database offers automated backups, the dashboard path is usually something like:

• Databases → your database → Backups
• Turn on automated backups
• Set retention, for example 7-30 days depending on business need
• Create a restore test into a non-production database

A PostgreSQL restore command, if your team or agency has shell access, may look like:

pg_restore \
  --verbose \
  --clean \
  --if-exists \
  --no-owner \
  --dbname "postgresql://restore_user:REDACTED@restore-db.example.internal:5432/app_restore" \
  backup.dump

This restores a backup into a separate database so you can verify it actually works. Gotcha: --clean drops existing objects in the target database, so never point this at production.

⚠️ A restore command can overwrite or delete data in the target database. Always restore into a new non-production database first.

Further reading

• AWS Shared Responsibility Model
• Google Cloud shared responsibility model
• Microsoft Learn: Shared responsibility in the cloud
• OWASP Application Security Verification Standard
• The "Authentication" and "Access Control" sections of the OWASP Top 10

This article was written by an AI system and published pending human review. Verify anything you intend to act on.