Cloud Computing Pattern

Key Control Areas

• Access Control and Identity Federation (AC-01, AC-02, AC-03, AC-04, AC-13): Cloud environments require rigorous access control that spans both the cloud provider's management plane and the customer's workloads. AC-02 (Account Management) is critical because cloud accounts proliferate rapidly -- service accounts, machine identities, cross-account roles, and federated users all need lifecycle management. AC-03 (Access Enforcement) must be implemented at multiple layers: IAM policies on cloud resources, network-level security groups and NACLs, application-level authorisation, and data-level access controls. AC-04 (Information Flow Enforcement) addresses the need to control data movement between cloud regions, accounts, and services -- preventing unintended data exfiltration through misconfigured S3 buckets, overly permissive API gateways, or unrestricted egress rules. AC-13 (Supervision And Review) requires regular access reviews and entitlement audits, which in cloud environments should be automated using cloud-native tools (AWS IAM Access Analyzer, Azure AD Access Reviews, GCP IAM Recommender) to identify unused permissions and overly broad policies.
• Security Awareness for Cloud (AT-01, AT-02, AT-03): Cloud security failures are overwhelmingly caused by human error -- misconfiguration, not exploitation. AT-02 (Security Awareness) must include cloud-specific content: the shared responsibility model, the consequences of public storage buckets, the risks of hard-coded credentials in code repositories, and the importance of enabling MFA on all cloud console accounts. AT-03 (Security Training) must be role-specific: cloud architects need training on secure VPC design and encryption configuration; developers need training on secrets management and secure CI/CD pipelines; operations teams need training on cloud-native monitoring and incident response. AT-01 (Policy And Procedures) should establish clear cloud security policies covering acceptable use of cloud services, approved providers, data classification requirements for cloud storage, and the process for provisioning new cloud resources.
• Continuous Monitoring and Assessment (CA-01, CA-02, CA-03, CA-04, CA-06, CA-07, AU-06): The dynamic nature of cloud infrastructure makes point-in-time assessments insufficient. CA-07 (Continuous Monitoring) is arguably the most important control in cloud security -- implement cloud security posture management (CSPM) tools that continuously evaluate configurations against security baselines and alert on drift. CA-02 (Security Assessments) should include cloud-specific penetration testing (within provider terms of service) and architecture reviews of VPC designs, IAM policies, and encryption configurations. CA-03 (Information System Connections) addresses the proliferation of connections between cloud accounts, on-premises networks (via VPN or Direct Connect), SaaS applications, and third-party integrations -- each connection is a potential attack path. AU-06 (Audit Monitoring) requires centralised log aggregation from CloudTrail, CloudWatch, Azure Monitor, or GCP Cloud Logging with automated analysis for indicators of compromise such as root account usage, security group modifications, or unusual API call patterns.
• Configuration Management and Infrastructure as Code (CM-01, CM-02, CM-03, CM-04, CM-05): Cloud infrastructure should be defined and deployed as code (Terraform, CloudFormation, Pulumi), making CM-02 (Baseline Configuration) enforceable and auditable through version-controlled templates. CM-03 (Configuration Change Control) is implemented through pull request workflows on infrastructure code, with automated security scanning (Checkov, tfsec, cfn-nag) in the CI pipeline to catch misconfigurations before deployment. CM-04 (Monitoring Configuration Changes) leverages cloud-native change tracking (AWS Config, Azure Policy, GCP Security Command Center) to detect and alert on configuration drift from approved baselines. CM-05 (Access Restrictions For Change) ensures that only authorised pipelines and personnel can modify production infrastructure, typically through break-glass procedures for emergency changes and automated deployment for standard changes.
• Identity and Authentication (IA-01, IA-02, IA-03, IA-05): Authentication in cloud environments is more complex than traditional infrastructure because of the variety of identity types. IA-02 (User Identification And Authentication) must enforce MFA for all human access to cloud management consoles and APIs -- compromised cloud credentials without MFA protection are a leading cause of cloud breaches. IA-03 (Device Identification And Authentication) extends to cloud workloads themselves: instance metadata services, workload identity federation, and service mesh authentication (mTLS) ensure that only authorised compute resources can communicate with each other. IA-05 (Authenticator Management) must address the lifecycle of API keys, access tokens, service account credentials, and secrets -- these should be stored in dedicated secrets managers (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault), rotated automatically, and never committed to source code repositories.
• Vendor Management and External Services (SA-01, SA-02, SA-03, SA-04, SA-05, SA-09, SA-10, SA-11, PS-06, PS-07): Cloud computing is fundamentally an outsourcing arrangement, making the SA family critical. SA-09 (External Information System Services) requires formal agreements defining security responsibilities, data handling obligations, breach notification procedures, and service level commitments. SA-04 (Acquisitions) should include security evaluation criteria when selecting cloud providers and services. SA-11 (Developer Security Testing) must extend to cloud-native application code, serverless functions, container images, and infrastructure templates. PS-06 (Access Agreements) and PS-07 (Third-Party Personnel Security) ensure that cloud provider personnel with access to customer environments meet security requirements. The organisation should maintain a current inventory of all cloud services consumed, their data classification, and their compliance status.
• Communications Protection and Data Security (SC-01, SC-02, SC-03, SC-04, SC-05, SC-06, SC-07, SC-08, SC-09, SC-11, SC-12, SC-18, SI-02, SI-03, SI-04): Cloud networking requires defence in depth. SC-07 (Boundary Protection) is implemented through VPC architecture, security groups, NACLs, and private endpoints that eliminate public internet exposure for backend services. SC-08 (Transmission Integrity) and SC-09 (Transmission Confidentiality) require encryption in transit for all inter-service communication, typically via TLS or VPN tunnels for hybrid connectivity. SC-12 (Cryptographic Key Management) is particularly important in cloud -- customer-managed keys (CMK) versus provider-managed keys, key rotation policies, and cross-region key replication all require careful design. SC-04 (Information Remnance) addresses data sanitisation when decommissioning cloud resources -- ensuring that EBS volumes, S3 objects, and database snapshots are properly purged. SI-02 (Flaw Remediation) requires patching strategies appropriate to each service model: OS patching for IaaS, dependency updates for PaaS, and configuration reviews for SaaS. SI-04 (Information System Monitoring) must cover network flow logs, DNS query logs, and anomaly detection across the cloud estate.

When to Use

Any organisation that consumes cloud services for production workloads, development and testing, data storage, or SaaS applications. This pattern applies whether the organisation uses a single cloud provider or multi-cloud strategy, and regardless of service model (IaaS, PaaS, SaaS). It is essential for organisations migrating workloads from on-premises to cloud, adopting cloud-native architectures (containers, serverless, microservices), or evaluating cloud providers for regulated workloads subject to compliance requirements such as PCI DSS, HIPAA, SOX, or GDPR.

When NOT to Use

Organisations that operate entirely on-premises with no cloud service consumption, including SaaS, may not need this pattern. However, this is increasingly rare -- even organisations with strict on-premises policies typically consume SaaS services (email, collaboration, HR systems) that fall under this pattern's scope. The pattern should not be applied without first completing a data classification exercise to understand what data will be stored in cloud environments and what regulatory constraints apply.

Typical Challenges

The shared responsibility model is widely misunderstood. Organisations frequently assume that 'moving to the cloud' transfers security responsibility to the provider, when in practice the customer remains responsible for data protection, access control, and application security in all service models. Cloud misconfigurations are the leading cause of cloud data breaches -- public S3 buckets, overly permissive security groups, disabled logging, and unencrypted storage are discovered by automated scanners constantly probing cloud provider IP ranges. Identity and access management complexity grows exponentially with cloud adoption: cross-account access, service account sprawl, overprivileged roles, and the challenge of implementing least privilege across thousands of fine-grained permissions. Vendor lock-in is a strategic risk -- data portability, API compatibility, and the cost of migration make provider changes expensive and disruptive. Compliance in multi-region deployments requires understanding data sovereignty laws, which vary by jurisdiction and change frequently. Shadow IT flourishes when cloud services are easy to provision with a credit card, bypassing security review processes. Cost management intersects with security when cryptomining attackers exploit compromised credentials to provision expensive compute resources.

Threat Resistance

This pattern addresses cloud-specific threats including: misconfiguration of cloud resources exposing data to public access; credential compromise enabling unauthorised access to cloud management planes; insider threats from both the customer organisation and the cloud provider; data exfiltration through overly permissive egress rules or compromised API keys; denial of service attacks targeting cloud-hosted applications; supply chain attacks through compromised container images, serverless dependencies, or infrastructure modules; cross-tenant attacks exploiting vulnerabilities in the cloud provider's isolation mechanisms; cryptojacking where attackers use compromised cloud accounts to mine cryptocurrency; data sovereignty violations from unintended data replication across jurisdictions; and loss of availability from cloud provider outages or account suspension.

Assumptions

The organisation has evaluated and selected cloud service providers based on documented security and compliance requirements. A shared responsibility model is understood and formally documented, with clear delineation of which controls are the provider's responsibility and which are the customer's. Network connectivity between on-premises and cloud environments (if applicable) uses encrypted tunnels or dedicated connections. The organisation has personnel with cloud security skills or is investing in upskilling. Data classification exists and informs decisions about which data can be stored in which cloud environments and regions.

Developing Areas

• Cloud-Native Application Protection Platforms (CNAPP) are consolidating previously separate capabilities -- CSPM, CWPP, CIEM, and cloud code security -- into unified platforms, but the market is still in flux. Vendors like Wiz, Prisma Cloud, and Orca each take different architectural approaches (agentless vs agent-based, graph-based vs policy-based), and organisations struggle to evaluate which capabilities are genuinely integrated versus bolted-on acquisitions. The risk of consolidation fatigue is real: organisations deploy a CNAPP expecting comprehensive coverage but discover gaps that require supplementary point solutions.
• Cloud-native identity federation complexity is increasing as organisations operate across multiple cloud providers, SaaS applications, and on-premises identity stores. The number of machine identities (service accounts, workload identities, API keys) now exceeds human identities by a factor of 10-45x in typical cloud environments, and tools for managing this machine identity sprawl are immature. Cross-cloud identity federation (AWS roles assuming Azure managed identities, GCP workload identity federation with external providers) introduces trust chains that are difficult to audit and easy to misconfigure.
• Sovereign cloud requirements driven by EU data sovereignty regulations, Schrems II implications, and national security concerns are fragmenting the cloud market. Hyperscale providers are responding with sovereign cloud offerings (AWS European Sovereign Cloud, Microsoft Cloud for Sovereignty, Google Distributed Cloud), but these come with reduced service availability, higher costs, and operational complexity. Organisations operating across jurisdictions must navigate an increasingly complex matrix of data residency, operational residency, and encryption key sovereignty requirements that existing cloud security frameworks do not fully address.
• Cloud Detection and Response (CDR) is emerging as a distinct discipline that applies detection engineering principles specifically to cloud control plane events. Unlike traditional EDR which monitors endpoint behaviour, CDR analyses CloudTrail, Azure Activity Log, and GCP Audit Log events to detect attacker techniques such as privilege escalation through IAM policy manipulation, persistence via backdoor role creation, and defence evasion through log disabling. The tooling is maturing rapidly (Vectra AI, Lacework, native cloud provider offerings) but detection rule libraries are still being developed, and cloud-specific threat intelligence is less mature than endpoint threat intelligence.
• The intersection of FinOps and cloud security is creating a new operational challenge. Cryptomining attacks that exploit compromised cloud credentials can generate tens of thousands of dollars in compute costs within hours, and cost anomaly detection is increasingly viewed as a security detection mechanism. Conversely, aggressive cost optimisation (shutting down logging, deleting snapshots, reducing instance sizes) can inadvertently weaken security controls. Organisations are beginning to recognise that FinOps and CloudSecOps teams need shared visibility and coordinated policies, but the tooling and processes for this integration are nascent.