# Cloud Security
Cloud security encompasses the policies, controls, technologies, and operational practices that protect cloud-based infrastructure, applications, and data. It covers every deployment model (IaaS, PaaS, SaaS, multi-cloud, hybrid), every provider (AWS, Azure, GCP, and hundreds of SaaS platforms), and every stakeholder (the cloud provider, the customer, and the shared responsibility boundary between them).
The cybersecurity industry has treated cloud security as a separate discipline for over a decade, spawning its own certifications (CCSP, CCSK), its own product categories (CSPM, CWPP, CNAPP, CASB, CIEM), and its own organizational structures (cloud security teams distinct from infrastructure security teams). This specialization reflects the scale of cloud adoption: by 2026, over 90% of organizations operate in at least one cloud provider, and cloud-native architecture (containers, serverless, microservices) is the default for new application development.
CDA does not treat cloud security as a separate domain. In the Planetary Defense Model, cloud is a theater, not a domain. The six PDM domains (DPS, VSD, SPH, IAT, TID, RGA) apply to cloud environments with the same structural completeness they apply to on-premises environments. What changes is the implementation. What does not change is the architecture of defense.
This article explains cloud security through the PDM's six domains, demonstrating that "cloud security" is not a seventh discipline. It is the existing six applied to a different operational theater.
Every major cloud provider operates under a shared responsibility model that defines which security controls the provider manages and which the customer manages. The boundary varies by deployment model:
IaaS (Infrastructure as a Service: AWS EC2, Azure VMs, GCP Compute Engine). The provider secures the physical infrastructure, hypervisor, and network backbone. The customer secures everything above: operating system, applications, data, identity, and network configuration. The customer has the most responsibility and the most control.
PaaS (Platform as a Service: AWS Lambda, Azure App Service, Google Cloud Functions). The provider secures the infrastructure and the runtime environment. The customer secures the application code, data, and access configuration. The provider manages patching and OS hardening. The customer is responsible for application-level vulnerabilities and data protection.
SaaS (Software as a Service: Microsoft 365, Salesforce, Google Workspace). The provider secures the infrastructure, platform, and application. The customer secures access configuration (user permissions, MFA, conditional access), data (classification, DLP, retention), and integration points (APIs, connected applications). The customer has the least responsibility but also the least visibility into the provider's security posture.
The shared responsibility model is where most cloud security failures originate. The customer assumes the provider handles a control. The provider's documentation states the customer is responsible. The control is implemented by neither. The gap is exploitable. Understanding exactly where the responsibility boundary falls for each service in each provider is the prerequisite for effective cloud security.
#### DPS: Data Protection and Sovereignty in the Cloud
Cloud shifts where data resides, who can access it, and what jurisdictions govern it. DPS in cloud environments covers:
Data residency and sovereignty. Which cloud region stores the data? Does the region fall under GDPR jurisdiction (EU regions), U.S. jurisdiction (U.S. regions), or other regulatory frameworks? Can the provider be compelled to disclose data under the laws of its headquarters jurisdiction regardless of where the data is stored (the issue at the center of the Microsoft Ireland warrant case and the U.S. CLOUD Act)?
Encryption and key management. Cloud providers encrypt data at rest by default (AWS S3, Azure Blob, GCP Cloud Storage all encrypt automatically). The sovereignty question is key management: does the provider control the key (provider-managed keys), does the customer control the key in the provider's KMS (customer-managed keys), or does the customer hold the key in their own HSM outside the provider entirely (customer-held keys)? CDA's SDP position: for Confidential and Restricted data, customer-managed or customer-held keys preserve sovereignty.
Data classification in SaaS. SaaS applications store and process organizational data outside the organization's infrastructure. Microsoft 365 stores email, documents, and collaboration data. Salesforce stores customer records. ServiceNow stores IT operations data. Each SaaS platform is a data repository that DPS must govern: what data is stored, how is it classified, who can access it, and what DLP controls restrict unauthorized sharing or exfiltration.
#### VSD: Vulnerability and Surface Defense in the Cloud
Cloud creates new attack surface categories that do not exist on-premises:
Cloud misconfiguration. The number one cloud security risk. Publicly accessible storage buckets, over-permissive IAM policies, unrestricted security groups, disabled logging, default configurations that expose management interfaces. Cloud misconfiguration is a VSD problem: the surface is exposed, and CSR (Continuous Surface Reduction) must identify and eliminate it.
Cloud Security Posture Management (CSPM) tools (Wiz, Orca, Prisma Cloud, Microsoft Defender for Cloud) continuously scan cloud environments for misconfigurations against security benchmarks (CIS Cloud Benchmarks, provider-specific best practices). CSPM is VSD's primary tool in cloud environments.
Container and serverless attack surface. Containerized applications (Docker, Kubernetes) and serverless functions (Lambda, Azure Functions) create ephemeral compute environments that traditional vulnerability scanners cannot assess effectively. Container image scanning (Trivy, Snyk Container, Aqua) identifies vulnerabilities in container images before deployment. Runtime security monitors container behavior for anomalies.
API attack surface. Cloud-native architectures expose functionality through APIs rather than traditional network services. Each API endpoint is an attack surface with its own authentication, authorization, input validation, and rate limiting requirements. API security (covered in the dedicated VSD wiki article) is a critical component of cloud VSD.
#### SPH: Security Posture and Hygiene in the Cloud
Cloud posture management is the operational discipline of maintaining cloud configurations in their intended state:
Infrastructure as Code (IaC) security. Cloud infrastructure defined through code (Terraform, CloudFormation, Pulumi, Bicep) enables consistent, repeatable, and auditable deployment. IaC security scanning (Checkov, tfsec, KICS) identifies misconfigurations in the code before deployment, shifting security left in the deployment pipeline.
Configuration drift. Cloud configurations drift just as on-premises configurations do: an administrator modifies a security group for troubleshooting and forgets to revert it. CSPM tools detect drift by continuously comparing actual configurations against defined baselines. APC (Autonomous Posture Command) applies: the posture adapts, the hygiene never sleeps.
Asset inventory. Cloud environments create and destroy resources dynamically. Auto-scaling groups spin up and terminate instances based on demand. Serverless functions exist only during execution. Containers have lifespans measured in minutes. Maintaining an accurate asset inventory in cloud requires integration with the cloud provider's resource APIs and continuous reconciliation.
#### IAT: Identity Access and Trust in the Cloud
Cloud IAM is the most critical control plane in any cloud environment:
Cloud IAM policies. AWS IAM, Azure RBAC, GCP IAM control who (users, roles, service accounts) can perform what actions on which resources. Over-permissive IAM policies (granting Administrator or Owner access when specific permissions would suffice) are the cloud equivalent of standing domain admin accounts. Cloud Infrastructure Entitlement Management (CIEM) tools identify over-permissive policies and recommend least-privilege alternatives.
Service accounts and machine identities. Cloud environments rely heavily on non-human identities: service accounts, managed identities, IAM roles assumed by applications, and API keys. These identities often have broader permissions than any human user. Governing them requires the same PAM discipline as on-premises service accounts: inventory, least privilege, rotation, and monitoring.
Federation and SSO. Enterprise cloud access typically federates through a centralized identity provider (Entra ID, Okta, Google Workspace) using SAML or OIDC. The identity provider is the trust anchor: its compromise provides access to every federated cloud service. Protecting the identity provider with phishing-resistant MFA, conditional access, and continuous monitoring is the highest-priority IAT control in a federated cloud environment.
#### TID: Threat Intelligence and Defense in the Cloud
Cloud environments generate different telemetry that requires different detection approaches:
Cloud-native logging. AWS CloudTrail, Azure Activity Log, GCP Audit Logs capture API-level events: who did what, to which resource, from where, and when. These logs are the cloud equivalent of on-premises security event logs. They must be ingested into the SIEM for correlation and analysis.
Cloud-specific threat detection. Threats in cloud environments include unauthorized API calls, privilege escalation through IAM policy modification, data exfiltration through cloud storage sharing, cryptomining on compromised compute instances, and persistence through backdoor IAM users or Lambda functions. Detection rules must be tuned to cloud-specific TTPs, many of which are documented in the MITRE ATT&CK Cloud Matrix.
Cloud provider security services. AWS GuardDuty, Azure Defender, GCP Security Command Center provide provider-native threat detection. These services detect common cloud threats (compromised credentials, unusual API activity, cryptocurrency mining) and feed into the organization's SIEM for correlation with non-cloud telemetry.
#### RGA: Risk Governance and Assurance in the Cloud
Cloud governance addresses the unique risk and compliance challenges of cloud operations:
Shared responsibility compliance. Compliance frameworks (SOC 2, ISO 27001, PCI DSS, HIPAA) apply to cloud environments, but the shared responsibility model means some controls are the provider's responsibility and some are the customer's. The provider's SOC 2 report covers the provider's controls. The customer must implement and demonstrate their controls independently.
Multi-cloud governance. Organizations using multiple cloud providers must maintain consistent security policies across providers with different IAM models, different logging formats, different security tooling, and different configuration paradigms. Governance frameworks must abstract above provider-specific implementations to enforce consistent policy.
Cloud cost as a governance concern. Cloud resources that are provisioned and forgotten (orphaned instances, unused storage, over-provisioned services) create both cost waste and security risk (unmanaged, unpatched, unmonitored resources). Cloud cost governance and security governance overlap: the orphaned instance that nobody pays attention to is both a budget leak and a security blind spot.
New applications are built cloud-native. Existing applications are migrating. The question is not whether an organization uses cloud. The question is how many cloud providers, how many SaaS applications, and how much data resides outside the traditional perimeter. Managing the security of this distributed, multi-provider, multi-model environment is the operational reality for every security team.
Cloud breaches are overwhelmingly caused by customer misconfiguration, not by provider infrastructure compromise. Public S3 buckets, over-permissive IAM policies, disabled logging, exposed management interfaces: these are configuration errors that the customer controls and the provider cannot prevent. The shared responsibility model means the customer is accountable for their configuration. CSPM tools and cloud security posture management processes address this risk.
Operating in cloud adds compliance complexity. Data may reside in multiple jurisdictions. Multiple providers have different certification scopes. The shared responsibility boundary means the customer must understand exactly which controls they own and which the provider covers. Multi-framework alignment (RGA-H01) becomes more complex when each framework must be mapped across on-premises and multiple cloud environments.
Cloud security is the clearest illustration of why the PDM never needs a seventh domain. Every cloud security concern maps to an existing PDM domain. Data protection in cloud is DPS. Cloud misconfiguration is VSD. Cloud posture management is SPH. Cloud IAM is IAT. Cloud threat detection is TID. Cloud governance is RGA. The six domains cover cloud completely because they describe what you defend (data, surfaces, posture, identity, threats, governance), not where you defend it.
CDA's approach to cloud security operates through the existing six domains with cloud-specific implementations:
The advantage of the PDM approach: cloud security is not a separate program with a separate team, separate tools, and separate reporting. It is the same six domains, the same campaign phases, the same mission structure, and the same posture score, applied to a different theater. The security team does not need a "cloud security strategy" and an "infrastructure security strategy." They need a security strategy that covers all theaters through the same six domains.
Word count: 2,186