Cloud Security Guide: Shared Responsibility to CNAPP

Most cloud breaches are not failures of the provider's infrastructure but of what the customer configured, granted and forgot on top of it. Public storage, over-permissioned roles, long-lived keys, missing logs and unowned accounts recur, and multiply as an estate grows. This guide is the umbrella reference for a cloud security programme across AWS, Microsoft Azure and Google Cloud: shared responsibility, landing zones and account structure, preventive guardrails, identity, network, data, logging, posture management, incident response and multi-cloud trade-offs. It is written for cloud security architects, platform engineers and security leads; specialist topics such as CNAPP tooling and workload identity have their own guides, linked where they apply.

Key takeaways

• You always own data, identities and configuration: the provider's share grows from IaaS to SaaS, but Microsoft, AWS and the NCSC all state that configuring the service securely and deciding what data goes into it stay with the customer.
• Structure is a security control: separate accounts, subscriptions and projects per workload and environment are the strongest blast-radius boundary the platforms offer, and they are where guardrails attach.
• Guardrails beat reviews: SCPs and RCPs, Azure Policy and GCP Organization Policy stop whole classes of misconfiguration before they exist. Test them in audit or dry-run mode first.
• Identity is the cloud perimeter: federated humans with no standing admin, and workloads that use roles, managed identities or federation instead of static keys, remove the credential that most cloud attack paths start with.
• Turn on the logs that are off by default: AWS and Azure keep control plane events for 90 days by default, data access logging is mostly off, and both gaps hurt investigations.

Shared responsibility by service model

AWS puts it as security "of" the cloud versus security "in" the cloud: AWS protects the infrastructure, while "Customer responsibility will be determined by the AWS Cloud services that a customer selects." On Amazon EC2 the customer patches the guest operating system and configures security groups; for abstracted services such as Amazon S3 the customer still manages data, encryption options, classification and IAM permissions. Microsoft's model lists four responsibilities the customer keeps in every deployment type: data, endpoints, accounts and access management, and states "For all cloud deployment types, you own your data and identities."

Source: Microsoft's shared responsibility matrix. The NCSC's advice is to "delegate as much responsibility for security to your hyperscale cloud platform as you can": prefer SaaS where it meets the need, PaaS over IaaS for hosting applications, and managed services for storage, identity, logging and monitoring. It places serverless between PaaS and SaaS.

• Choosing a provider: the NCSC's 14 Cloud Security Principles (from Principle 1, data in transit protection, to Principle 14, secure use of the service) are designed "to help you choose a cloud provider that meets your security needs". Principles 9 to 13, from user management to audit information for customers, are where services differ most.
• Assessing providers at scale: the CSA Cloud Controls Matrix v4.1 has 197 control objectives in 17 domains, and its built-in CAIQ yes or no questionnaire replaces a bespoke questionnaire per supplier.
• Access control by model: NIST SP 800-210 treats the models as hierarchical, so IaaS access control guidance also applies inside PaaS and SaaS.

Landing zones and account structure

A landing zone is the pre-built, governed foundation that every workload lands in. Microsoft's Cloud Adoption Framework separates a platform landing zone (shared governance, security and connectivity) from workload landing zones where teams deploy "within the guardrails of the platform landing zone", with a management group hierarchy that "separates platform resources and workload resources". The same pattern exists on every platform under different names.

• Separate by workload and environment: production, non-production and sandbox in different accounts, subscriptions or projects, so a compromised developer sandbox cannot reach production data through a shared role.
• Dedicated security accounts: a log archive account that workload teams cannot write to or delete from, and a security tooling account for detection and posture services. Keep the AWS management account free of workloads: SCPs do not apply to it.
• Vend accounts through code: new accounts arrive with logging, guardrails, baseline roles, budget alerts and an owner tag applied.
• Keep an inventory that is reconciled: compare the organisation's account and project list, each provider's asset inventory and your vulnerability scanner's target list every week. Instances that exist in the cloud inventory but never appear in scan results are the forgotten assets attackers find first. See the Attack Surface Management Guide.

Preventive guardrails

Guardrails restrict what can be configured regardless of who asks, which is different from IAM. Google's documentation puts it plainly: IAM "focuses on who", Organization Policy "focuses on what". Microsoft says Azure Policy enforces compliance "without concern for who made the change". AWS is explicit that "No permissions are granted by an SCP": SCPs set the maximum permissions available in member accounts, and the effective permission is the intersection of SCPs and RCPs with identity and resource policies.

Testing and rolling back guardrails

• AWS: AWS "strongly recommends" not attaching SCPs to the organisation root without testing; create a test OU and move accounts into it one at a time, using IAM service last accessed data and CloudTrail to see what accounts actually use. Note that SCPs never restrict service-linked roles.
• Azure: Microsoft advises starting with audit or auditIfNotExists before enforcement effects (deny, modify, deployIfNotExists). Policies assigned at a management group evaluate resources in its subscriptions and resource groups.
• Google Cloud: dry-run organisation policies mean "violations of the policy are audit-logged, but the violating actions aren't denied". Policies inherit down the hierarchy and can be overridden, so review overrides too.
• Rollback: keep every guardrail in version control, deploy through a pipeline, and make detaching or switching to audit a documented one-step change owned by the platform team.

Where identity fits

Every cloud control plane call is authorised by an identity, which makes identity the effective perimeter, and non-human identities (roles, service principals, managed identities, service accounts, access keys) usually outnumber people. The AWS Well-Architected security pillar's first design principle is to "aim to eliminate reliance on long-term static credentials".

• Federate every human: AWS's first IAM best practice is to require human users to use federation with an identity provider and temporary credentials, with phishing-resistant MFA. Avoid local IAM users and cloud-only admin accounts except for documented break-glass. See the Break-Glass Account Guide.
• No standing administrator access: grant elevated cloud roles just in time and record approval. See the Cloud PAM and CIEM Guide.
• Workloads use platform identity: IAM roles, Azure managed identities and Google service accounts attached to the workload, with tokens issued by the metadata service; external systems such as CI pipelines use workload identity federation instead of exported keys. See the Cloud Workload Identity Guide.
• Right-size from evidence: AWS recommends IAM Access Analyzer to generate policies from access activity, last accessed information to remove unused roles and credentials, and Access Analyzer to verify public and cross-account access. Permissions boundaries let platform teams delegate role creation safely.
• Protect the metadata service: enforce IMDSv2 on AWS. In the Capital One breach, a server-side request forgery against a firewall retrieved the instance role's credentials, which then had read access to storage (ATT&CK T1552.005).
• Own every NHI: each role, service principal and key needs an owner, a purpose and a review date. See the Service Account Security Guide.

Network and data protection

• Private by default: reach PaaS services through private endpoints (AWS PrivateLink and VPC endpoints, Azure Private Link, Google Private Service Connect) and disable public network access on storage and databases that do not need it.
• Control egress, not just ingress: an outbound allowlist through a central firewall or NAT inspection point limits exfiltration and command-and-control from compromised workloads. See the Firewall Management Guide.
• VPC peering risk: peering is quick but joins two networks with broad routing, often across trust boundaries such as production and a vendor or test VPC. Prefer a hub with inspection, or service-level private endpoints, and review security groups on both sides. See the Network Segmentation Guide.
• Block public storage centrally: account-level S3 Block Public Access, Azure policies against anonymous blob access, and Google public access prevention, enforced as guardrails rather than per bucket.
• Treat shared access links as credentials: long-lived storage tokens are bearer secrets. The Microsoft SAS token exposure shared one over-permissive link and exposed 38TB of internal data.
• Encryption and keys: encryption at rest is on by default on the major platforms; the decision is whether to use customer-managed keys in KMS, Key Vault or Cloud KMS for separation of duties, revocation and audit. See the Cryptographic Key Management Guide and the Data Security Guide.
• Backups out of reach: copy critical backups to a separate account with immutability, so one stolen admin credential cannot delete both data and backups (T1485, T1486).

Logging and detection

• Centralise and protect: ship logs to a separate account or project with write-once storage, and alert on any change to trails, diagnostic settings or sinks. In ATT&CK v20, tampering with security tooling sits under Defense Impairment (TA0112), for example T1685 Disable or Modify Tools.
• Detect identity abuse first: new access keys, role trust changes and added role grants (T1098.003), console sign-ins from new locations, activity in unused regions (T1535) and sudden compute creation for cryptomining (T1496). See the Log Management and Retention Guide and the SIEM Guide.
• Use native threat detection: Amazon GuardDuty, Microsoft Defender for Cloud and Google Security Command Center add provider context a SIEM rule set lacks.

Posture management

Cloud security posture management (CSPM) compares live configuration against a baseline, usually a CIS Foundations Benchmark for each provider plus your own guardrail intent. Native services (AWS Security Hub, Defender for Cloud, Security Command Center) and open-source auditors such as ScoutSuite cover the basics; a CNAPP adds workload, identity and attack path context. See the CNAPP Guide for that tooling.

• Fix in code: route findings to the team owning the resource and fix the Terraform, Bicep or CloudFormation that created it, or the drift returns on the next deploy.
• Prioritise by path: internet exposure plus an exploitable flaw plus a privileged role plus sensitive data is a priority; any one alone rarely is. See the Vulnerability Management Guide.

Incident response in the cloud

1. Prepare access in advance: a pre-approved responder role in every account, a forensic account for snapshots, and provider support contacts recorded. The Well-Architected principle is to "Run incident response simulations".
2. Contain identity first: deactivate the access key, revoke active sessions (for AWS roles, a deny policy conditioned on token issue time; in Entra ID, revoke sign-in sessions), and remove added roles. See the Leaked Credential Response Playbook.
3. Preserve evidence before rebuilding: snapshot disks, export logs beyond the 90-day default window, record resource configuration and tag affected resources rather than deleting them.
4. Scope by the identity's reach: list everything the compromised principal could access, check for new identities, keys, trust relationships and cross-account resources it created, in every region.
5. Recover from known-good code: redeploy from infrastructure as code and rotate every secret the workload could read. See the Incident Response Guide and the Digital Forensics (DFIR) Guide.

Multi-cloud trade-offs and exit strategy

• Federate identity once: one workforce identity provider for every cloud is the highest-value multi-cloud control.
• Write an exit plan early: data export formats, key ownership, re-targetable infrastructure as code and contract terms. The CCM's Interoperability and Portability (IPY) domain is a useful checklist. Regulated firms should map this to sector rules; see the DORA Guide.
• Small organisations: one provider, its native landing zone accelerator, default-on logging and native threat detection deliver most of the value. Large estates need a platform team and guardrails as code.

Implementing the programme

1. Discover: enumerate every account, subscription and project, including ones created outside procurement, and assign an owner to each.
2. Lock the top: secure the management account, root and Global Administrator identities with phishing-resistant MFA and break-glass procedures.
3. Turn on logging: organisation-wide trails, diagnostic settings and audit log sinks to a protected log account, plus native threat detection in every region.
4. Build the landing zone: hierarchy, account vending, baseline network and identity, applied to new accounts first.
5. Introduce guardrails in audit mode: test OU, auditIfNotExists or dry-run; review a few weeks of findings with workload teams; then enforce in rings, sandbox first and production last.
6. Remove static credentials: migrate workloads to roles, managed identities and federation; block new key creation with a guardrail and an exception process.
7. Run posture and response as routines: findings with owners and due dates, and a cloud incident exercise at least twice a year.

Detection and measurement

• Coverage: percentage of accounts, subscriptions and projects inside the landing zone with logging, guardrails and threat detection enabled (target 100%).
• Static credentials: number of long-lived access keys and service account keys, and the percentage older than 90 days.
• Standing privilege: human identities with permanent administrator roles, trending to zero outside break-glass.
• Posture debt: open critical misconfigurations and median time to remediate by severity.
• Inventory reconciliation: cloud assets not seen by the vulnerability scanner in the last 30 days.
• Guardrail exceptions: count of active exceptions and the share past their expiry date.

Framework mapping

ATT&CK v20 Cloud matrix techniques this guide addresses include T1078.004 Cloud Accounts, T1190 Exploit Public-Facing Application, T1552.005 Cloud Instance Metadata API, T1580 Cloud Infrastructure Discovery, T1098.003 Additional Cloud Roles, T1666 Modify Cloud Resource Hierarchy, T1535 Unused/Unsupported Cloud Regions, T1530 Data from Cloud Storage, T1537 Transfer Data to Cloud Account and T1496 Resource Hijacking.

Common failure patterns

• Long-lived keys in code and config: the 230 Million AWS environments campaign harvested access keys from exposed .env files, and in the Codefinger S3 ransomware attacks stolen AWS keys were used to encrypt buckets with AWS's own encryption. Guardrails against key creation and secret scanning close this.
• Accounts outside governance: a forgotten test tenant without MFA was the start of the Microsoft Midnight Blizzard breach. Anything outside the landing zone has no guardrails, logs or owner.
• Over-permissioned workload roles: a role written for convenience turns a single application flaw into data access, as in the Capital One case above.
• Logging assumed, not verified: data access logs left off, 90-day defaults never extended, and investigators find the evidence window has already closed.
• Stolen credentials used for compute abuse: in the AWS crypto-mining campaign, compromised IAM credentials had miners running within minutes. Budget alerts and detection on unusual instance creation shorten that window.
• SaaS treated as the provider's problem: the Snowflake breach used customer credentials without MFA; the platform worked as designed, and the customer-side identity controls were missing.

Practitioner checklist

• Inventory every account, subscription and project and give each a named owner.
• Secure root, management account and Global Administrator identities with phishing-resistant MFA and tested break-glass.
• Enable organisation-wide control plane logging to a protected log account, plus data access logs for sensitive stores.
• Deploy guardrails for logging protection, regions, public access and key creation, tested in audit or dry-run first.
• Federate all human access and remove standing administrator roles.
• Move workloads to roles, managed identities and workload identity federation; track remaining static keys to zero.
• Reconcile cloud inventory with vulnerability scan coverage every week.
• Keep backups and log archives in separate accounts with immutability.
• Run a cloud-specific incident exercise covering key revocation, session revocation and evidence capture.
• Document an exit and portability plan for each critical workload.

Standards and references

• NCSC: The Cloud Security Principles
• NCSC: Cloud security shared responsibility model
• NIST: SP 800-210 General Access Control Guidance for Cloud Systems
• Cloud Security Alliance: Cloud Controls Matrix and CAIQ v4.1
• Microsoft: Shared responsibility in the cloud
• AWS: Service control policies (SCPs)
• Google Cloud: Introduction to the Organization Policy Service
• AWS: Well-Architected Framework security pillar design principles

Related NHI Mgmt Group resources: Cloud Workload Identity Guide · Cloud PAM and CIEM Guide · CNAPP Guide · Data Security Guide · Secrets Management Guide