Shared responsibility: where the scope line falls in a cloud assessment

One sentence per provider

AWS splits the estate into security “of” the cloud and security “in” the cloud. AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud, meaning hardware, software, networking and facilities. The customer takes what sits on top, and for an IaaS service such as Amazon EC2 that includes management of the guest operating system, its updates and security patches, any application software or utilities the customer installs, and the firewall configuration.

Microsoft publishes a matrix rather than a sentence, and the matrix is more useful because it names the rows. Customer data, configurations and settings, and identities and users are the customer’s responsibility in all four columns: on-premises, IaaS, PaaS and SaaS. Physical hosts, physical network and physical datacentre are Microsoft’s in all three cloud columns. Operating system, network controls and applications move across the boundary as you go from IaaS to SaaS. Microsoft states the principle plainly: for all cloud deployment types, you own your data and identities.

Google Cloud describes the same split and then adds a second idea. Under shared responsibility, the bulk of the security responsibilities are the customer’s in IaaS with Google focused on underlying infrastructure and physical security; in PaaS, Google is responsible for more controls and the customer shares application-level controls and IAM management; in SaaS, Google owns the bulk of it and the customer remains responsible for access controls and the data they choose to store. Google then explains why it went further with the shared-fate model, and the explanation is the single most useful sentence in any of the three documents: most cloud security breaches are the direct result of misconfiguration.

Microsoft’s responsibility matrix, reproduced

Responsibility area	On-premises	IaaS	PaaS	SaaS
Customer data	Customer	Customer	Customer	Customer
Configurations and settings	Customer	Customer	Customer	Customer
Identities and users	Customer	Customer	Customer	Customer
Client devices	Customer	Customer	Customer	Shared
Applications	Customer	Customer	Shared	Shared
Network controls	Customer	Customer	Shared	Microsoft
Operating system	Customer	Customer	Microsoft	Microsoft
Physical hosts	Customer	Microsoft	Microsoft	Microsoft
Physical network	Customer	Microsoft	Microsoft	Microsoft
Physical datacenter	Customer	Microsoft	Microsoft	Microsoft

Reading the matrix as a scope document

Take the three rows that never move. Customer data, configurations and settings, and identities and users are the customer’s responsibility in every deployment model on every provider. Those three rows are the scope of a cloud security assessment. Everything above them in the matrix is testable to the extent the customer configures it; everything below is the provider’s, which means it is both outside the customer’s control and outside what any provider policy permits a customer to test.

This is why the provider rules of engagement and the responsibility model agree with each other. AWS prohibiting S3 bucket takeover, Microsoft prohibiting post-exploitation against its own online services, and Google requiring that your tests only affect your own projects are not three arbitrary restrictions. They are the same line, expressed as a prohibition rather than as a diagram.

What moves as you go up the stack

The rows that do move are where scoping conversations get interesting, because a single environment usually spans all of them.

IaaS: almost everything is yours

A virtual machine puts the guest operating system, the runtime, the application, the local firewall and the patching cadence on the customer. AWS names this explicitly for EC2. So the classic host-level questions still apply, but they are no longer the interesting ones: the identity attached to the instance usually reaches further than any local exploit would. An instance profile, a managed identity or a Compute Engine service account is a credential sitting on the host, retrievable by anything that can make an HTTP request from it, and its permissions are frequently broader than the workload requires.

PaaS: shared, and the sharing is the risk

Microsoft marks applications and network controls as shared in PaaS. In practice that means the provider patches the runtime and the customer owns everything about how the service is configured and reached: which principals can invoke it, what identity it runs as, what secrets its configuration holds, and what its network exposure is. The Microsoft rules of engagement explicitly permit attempting to break out of shared service containers such as Azure App Service or Azure Functions, subject to stopping and disclosing responsibly on success, which is a useful signal about where the line is drawn.

Abstracted storage and data services

AWS describes the abstracted case for services such as Amazon S3 and DynamoDB: customers access the endpoints to store and retrieve data, and customers are responsible for managing their data including encryption options, classifying their assets, and using IAM tools to apply the appropriate permissions. Nothing about the service implementation is testable. Everything about the bucket policy, the access control list, the key policy, the Block Public Access configuration and the snapshot exposure is.

SaaS and third-party integrations

A SaaS platform is not covered by your cloud provider’s testing policy at all, because it is not your cloud provider. Each vendor sets its own terms, and testing one without written vendor authorization is testing a system you do not own. What remains in scope on your side is the integration: the cross-account role a vendor assumes, the OAuth application consent granted in your identity provider, the service account key issued to a supplier, and the scope of what any of them can reach.

Why the assessment looks like configuration review

A classic network penetration test starts from reachability. You enumerate hosts, find services, identify versions and look for a flaw that gives you execution. Cloud estates do not respond well to that method, for three structural reasons.

• The interesting surface is an API, not a port. The control plane of every provider is a global, authenticated HTTPS API. There is no version to fingerprint and no unpatched daemon to exploit. What decides whether an action succeeds is a policy evaluation, so the question is which principal can call which action against which resource, and that is a configuration question.
• Reachability is not permission. Two resources in the same account may be network-adjacent and completely unable to act on each other, or on opposite sides of the world and joined by a role trust policy. Network position tells you very little; the identity graph tells you almost everything.
• The provider has already patched the layers you would attack. The hypervisor, the host fleet and the managed service internals are maintained continuously and are out of bounds. What is left unmaintained is the part the customer configures, and that part changes every deployment.

So the method inverts. Read the account first, comprehensively and read-only, against a published baseline such as the CIS Benchmark for that provider. Build the identity graph from role trust policies, delegation permissions and impersonation grants. Then, and only then, prove the paths that matter from a credentialed low-privilege principal. The identity attack paths guide covers the second and third steps in detail.

Where the model creates gaps rather than clarity

The responsibility model is honest about what each side owns, but it is silent about three things that decide whether an environment is actually defended.

The first is the seam. Responsibility is drawn per layer, while attacks cross layers. A workload in a managed Kubernetes cluster that can reach the cloud metadata endpoint is using a customer-configured network permission to obtain a customer-owned cloud credential attached to a provider-managed node group. Every layer is correctly assigned; the path between them is nobody’s row in the table.

The second is the default. A provider can make a control available without making it the default, and the responsibility model puts the consequence of that on the customer. AWS notes that new buckets, access points and objects do not allow public access by default, and equally that users can modify bucket policies, access point policies or object permissions to allow it. Google’s shared-fate model exists precisely to address this: rather than dividing responsibility and stopping there, it commits the provider to secure defaults, best-practice guidance and infrastructure-as-code blueprints, on the stated basis that customers need opinionated best practices to keep up.

The third is organisational. In most estates the rows of the matrix belong to different teams. Identity sits with a platform group, network with infrastructure, application configuration with the product team, and data classification with nobody in particular. A finding that spans two rows will be assigned to one of them and closed by neither. This is why a cloud report has to name the responsible party per finding rather than dumping a severity list on a single owner.

Writing the scope down

A cloud assessment scope that will survive the kick-off call names the following, in this order: the accounts, subscriptions and projects by identifier; the service models present in each, because a subscription running IaaS, PaaS and SaaS spans three different responsibility splits; the identity providers and federations that grant access to them; the third-party integrations with standing access; and the environments, distinguishing production from copies.

Then the exclusions, stated as facts rather than as apologies. Provider infrastructure is excluded because it is not yours. Denial of service is excluded because it is prohibited. Tenants, projects and subscriptions not named are excluded because reaching them would be an intrusion. Any SaaS platform without vendor authorization is excluded for the same reason.

What is left is a scope that matches both the responsibility model and the published provider rules, which is the only combination that produces an engagement nobody has to renegotiate mid-flight. It is also, not coincidentally, the scope that produces the findings: identity, configuration and data are the three rows the customer owns everywhere, and they are where the report comes from.