Cloud Security: The Shared Responsibility Model in Practice

Ask what caused the last dozen major cloud breaches and the answer is rarely a sophisticated exploit. It's a storage bucket left public, an access key committed to a repository, an over-permissioned role, an unrotated credential, a forgotten test environment. Cloud providers' infrastructure is very hard to break; the configuration customers layer on top is where attackers look, and where security effort pays off.

Shared responsibility, precisely

The provider secures the physical data centres, the hardware, the hypervisor and the services' control planes. The customer secures what they deploy: identities and their permissions, data and its encryption, application code, network configuration and operating systems where they manage them. The line moves with the service model — a managed database shifts OS patching to the provider; a virtual machine doesn't — but three things are always the customer's: who can access what, how data is protected, and how the environment is configured. Nearly every breach lives in those three.

Identity is the new perimeter

In the cloud, everything is an API call authorised by an identity. Identity and access management is therefore the control that matters most.

• MFA on every human identity, phishing-resistant (hardware keys or passkeys) for administrators. Root or organisation-owner accounts should be locked away and never used day-to-day.
• Least privilege, enforced. Start from zero and grant what's needed; use the providers' access analysers to find and strip unused permissions. Wildcards in policies are a finding, not a convenience.
• No long-lived keys. Workloads should assume roles and receive short-lived credentials automatically; humans should use SSO with session limits. A static access key in a config file is the single most common initial-access vector in cloud incidents.
• Separate accounts or projects per environment and workload so a compromise is contained by a hard boundary, not just a policy.

Protecting data

Encryption at rest is now on by default on the major platforms — the meaningful decisions are about keys: who controls them, whether you use provider-managed, customer-managed or externally held keys, and how rotation and access are logged. Encryption in transit should be enforced, not optional. Beyond that:

• Block public access at the account level for storage, and alert on any exception.
• Classify data so that regulated or sensitive stores get stricter controls — data-loss-prevention scanning, tighter access, shorter retention.
• Backups that an attacker can't reach. Ransomware operators delete cloud backups first. Immutable or object-locked backups in a separate account are the answer.
• Secrets in a secrets manager, injected at runtime, scanned for in every repository and image.

Configuration drift and posture management

Cloud environments change constantly and misconfigurations creep in. Two disciplines keep them in check. Infrastructure as code with policy checks in CI — tools that reject a template opening port 22 to the world before it's ever deployed. And cloud security posture management (CSPM), which continuously scans the live environment against benchmarks (CIS, the provider's own well-architected checks) and flags drift. The newer generation of platforms combines posture, workload vulnerability scanning and identity analysis to prioritise the misconfigurations that are actually exploitable — a public bucket that contains nothing sensitive is less urgent than an internal role with a path to admin.

Detection and response

You cannot respond to what you don't log. Turn on the provider's audit trail (CloudTrail, Azure Activity Log, Cloud Audit Logs) for every account and ship it somewhere the attacker can't delete. Add the native threat-detection services, which watch for known-bad patterns like credential use from unusual locations or crypto-mining on compute. Feed all of it into a SIEM or detection platform with rules for the cloud-specific attacks: new admin user created, MFA disabled, logging turned off, snapshot shared externally, mass download from storage.

Then rehearse. An incident playbook for the cloud is different from on-premises: revoking a role's sessions, isolating a compromised instance by security group, rotating every key the attacker might have touched, and preserving evidence via snapshots. Teams that have done a tabletop exercise contain incidents in hours; teams that haven't take days.

Where it's heading

Three developments shape the next few years. Zero-trust architectures — every request authenticated and authorised regardless of network location — fit the cloud's identity-centric model naturally and are becoming the default. AI-assisted detection is improving the signal-to-noise of alerting, while AI workloads themselves (model endpoints, vector databases, agent tooling with broad permissions) are a new attack surface that most security programmes haven't yet mapped. And regulation — from the EU's NIS2 and DORA to sector rules everywhere — is turning cloud security posture into something that gets audited, not just recommended.