Study guide
2.3 Security Concepts Relevant to Cloud (Domain 1.3)
Certified Cloud Security Professional CCSP
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current CCSP Exam Facts 1.2 CAT Format, Scoring & Logistics 1.3 Eligibility, Experience & Certification Maintenance
2 Domain 1: Cloud Concepts & Architecture Foundations
2.1 Cloud Computing Concepts (Domain 1.1) 2.2 Cloud Reference Architecture (Domain 1.2) 2.3 Security Concepts Relevant to Cloud (Domain 1.3)
3 Domain 1: Secure Design, CSP Evaluation & AI/ML
3.1 Design Principles of Secure Cloud Computing (Domain 1.4) 3.2 Evaluate Cloud Service Providers (Domain 1.5) 3.3 AI/ML in Cloud Security (Domain 1.6)
4 Domain 2: Data Concepts, Storage & Protection Technologies
4.1 Cloud Data Concepts (Domain 2.1) 4.2 Cloud Data Storage Architectures (Domain 2.2) 4.3 Data Security Technologies & Strategies (Domain 2.3)
5 Domain 2: Discovery, Classification & Information Rights Management
5.1 Data Discovery (Domain 2.4) 5.2 Data Classification (Domain 2.5) 5.3 Information Rights Management (Domain 2.6)
6 Domain 2: Retention, Auditability & AI/ML Data Protection
6.1 Retention, Deletion & Archiving (Domain 2.7) 6.2 Auditability, Traceability & Accountability (Domain 2.8) 6.3 AI/ML Data Protection (Domain 2.9)
7 Domain 3: Infrastructure Components, Data Center & Risks
7.1 Cloud Infrastructure Components (Domain 3.1) 7.2 Secure Data Center Design (Domain 3.2) 7.3 Infrastructure & Platform Risks (Domain 3.3)
8 Domain 3: Security Controls & Business Continuity / Disaster Recovery
8.1 Security Controls Implementation (Domain 3.4) 8.2 Business Continuity & Disaster Recovery (Domain 3.5)
9 Domain 4: Application Security Awareness & Secure SDLC
9.1 Application Security Training & Awareness (Domain 4.1) 9.2 Secure SDLC Process (Domain 4.2) 9.3 Apply Secure SDLC (Domain 4.3)
10 Domain 4: Software Assurance, Architecture & IAM
10.1 Cloud Software Assurance & Validation (Domain 4.4) 10.2 Verified Secure Software (Domain 4.5) 10.3 Cloud Application Architecture (Domain 4.6) 10.4 Identity & Access Management Solutions (Domain 4.7)
11 Domain 5: Build, Operate & Operational Controls
11.1 Build Physical & Logical Infrastructure (Domain 5.1) 11.2 Operate & Maintain Infrastructure (Domain 5.2) 11.3 Operational Controls & Standards (Domain 5.3)
12 Domain 5: Forensics, Stakeholder Communication & Security Operations
12.1 Digital Forensics Support (Domain 5.4) 12.2 Communication with Relevant Parties (Domain 5.5) 12.3 Manage Security Operations (Domain 5.6)
13 Domain 6: Legal Requirements, Privacy & Audit
13.1 Legal Requirements & Cloud Risks (Domain 6.1) 13.2 Privacy Requirements (Domain 6.2) 13.3 Audit Processes for Cloud (Domain 6.3)
14 Domain 6: Enterprise Risk Management & Cloud Contracts
14.1 Cloud Implications for Enterprise Risk (Domain 6.4) 14.2 Outsourcing & Cloud Contract Design (Domain 6.5)
2.3 Security Concepts Relevant to Cloud (Domain 1.3)
Key Takeaways Explain This Topic AI
Cloud cryptography is only as strong as key management: custody, rotation, separation of duties, and customer-managed vs provider-managed keys change residual risk.
Identity and access control spans user, privilege, and service/workload identities — automation identities often present the highest blast radius.
Sanitization in multi-tenant cloud prefers cryptographic erase and validated overwriting; physical destruction may not be available for shared media.
Network security (NSGs, traffic inspection, geofencing) and virtualization security (hypervisor, containers, ephemeral/serverless isolation) form layered defenses.
Hygiene — patching, baselining, immutable architecture, and hardening — plus awareness of common cloud threats turns architecture into operable security.
Last updated: July 2026
Security Concepts Relevant to Cloud Computing
Domain 1.3 connects architecture vocabulary to controls . The exam will not ask whether encryption is “good”; it will ask who holds the keys , which identity path is over-privileged , or how you sanitize multi-tenant media . Keep shared responsibility in view: the same control name (encryption, logging, patching) can sit on different sides of the customer/CSP line depending on SaaS vs PaaS vs IaaS.
Cryptography and Key Management
Cryptography protects confidentiality and integrity of data at rest , in transit , and — with confidential computing — increasingly in use . Algorithms and TLS versions matter, but key management is where CCSP scenarios live.
- Topic Cloud practice
- Key generation Prefer HSM/KMS-backed generation with strong entropy
Custody models Provider-managed keys (simpler) vs customer-managed keys (CMK/BYOK/HYOK patterns) for higher control
- Separation of duties Split rights to use a key vs administer a key vs delete a key
- Rotation and versioning Scheduled rotation; applications must handle key versions without downtime
- Envelope encryption Data keys encrypt payloads; master keys in KMS/HSM wrap data keys
- Key access logging Treat key use as a security-critical audit event
Exam trap: Encrypting object storage with a provider-managed key still leaves the CSP (and anyone who fully compromises the customer’s cloud identity with decrypt rights) able to access plaintext under policy. Customer-managed keys reduce some residual risk and support stronger separation, but the customer must protect key-admin identities as crown jewels. Losing keys without backups equals data loss — availability is part of the CIA triad.
In IaaS you often manage volume encryption and application-level crypto. In PaaS you configure platform encryption settings and CMKs. In SaaS you may only toggle encryption features and control export paths — yet you remain accountable for whether data should live in that SaaS tenant.
Identity and Access Control
Identity is the primary control plane of the cloud. Compromise of identity often equals compromise of the estate.
- Access type Description High-risk failures
- User access Human workforce and external users Phishing, weak MFA, stale accounts, over-broad groups
Privilege access Administrative and break-glass paths Standing admin rights, shared root accounts, unlogged elevation
Service access Workloads, pipelines, APIs, and machine identities Long-lived access keys in code, excessive role trust, CI/CD overreach
Core practices: central identity provider , strong MFA , least privilege , just-in-time elevation , short-lived credentials, workload identity federation (prefer role assumption over static keys), regular access reviews, and privileged session monitoring. Federation (SAML/OIDC) links enterprise IdP to CSP IAM so joiner-mover-leaver processes remain coherent.
Shared-responsibility note: The CSP authenticates API calls against its IAM service and protects the control plane. The customer designs roles, trust policies, SSO integration, and who may assume privileged roles. In SaaS, customer admins still decide which employees and OAuth apps receive access.
Data and Media Sanitization
When customers delete data or leave a provider, residual data on shared media is a classic multi-tenant concern.
Method How it works Cloud applicability
Overwriting Replace media contents with patterns Feasible for customer-controlled volumes/disks; hard to verify on opaque shared infrastructure
Cryptographic erase Delete or destroy encryption keys so ciphertext is unrecoverable Preferred in multi-tenant cloud when data was encrypted under customer-controlled keys
Physical destruction Shred/degauss media Usually provider-side end-of-life; not available per-tenant on shared disks
Best practice: encrypt early with keys you control (where the model allows), document deletion workflows, and obtain contractual/process assurances for provider-side media handling. Crypto-shredding entire tenants or data classes is a powerful reversibility tool when keys are well-managed — and a disaster if keys are destroyed accidentally.
Network Security
Cloud networks are software-defined. Controls must be as code-friendly as the infrastructure.
Control Purpose
Network security groups (NSGs) / security groups Stateful allow/deny rules on interfaces or subnets; default-deny with explicit least privilege
Traffic inspection IDS/IPS, NGFW, web proxies, or cloud-native firewall/mirror patterns for east-west and north-south visibility
Geofencing / geo-restriction Limit management or data-plane access by geography or region endpoints to support residency and reduce attack surface
Complementary patterns: private endpoints to PaaS services, hub-and-spoke or mesh segmentation, egress control to stop exfiltration, and DDoS protections at the edge. Remember: open management ports (SSH/RDP/WinRM) to the world remain an amateur failure mode even in advanced cloud estates.
Virtualization Security
Area Concerns Mitigations
Hypervisor security Escape, management plane compromise Patch hypervisors (CSP duty in public cloud), minimize guest tools attack surface, strong isolation features
Container security Poisoned images, breakout, orchestrator takeover Signed images, minimal base images, pod security, network policies, secrets not baked into images
Ephemeral computing Short-lived instances/tasks Bake security into images/templates; do not rely on long-term host hardening alone; centralize logs before instances die
Serverless Over-privileged functions, insecure dependencies, event injection Least-privilege execution roles, dependency scanning, input validation, per-function isolation
Isolation Tenant and workload separation Separate accounts/subscriptions/projects, VPC boundaries, compute isolation options, confidential computing where needed
Ephemeral and serverless models improve some hygiene (immutable, short lifetime) but demand excellent identity , logging , and supply-chain controls because you rarely SSH in to “fix” a host.
Common Cloud Threats
Threat catalogs (CSA Top Threats, provider advisories, and classical STRIDE applied to cloud) converge on recurring patterns:
Identity compromise and credential theft — still the dominant path to cloud breaches.
Misconfiguration and inadequate change control — public buckets, open security groups, verbose logging disabled.
Insecure interfaces and APIs — broken authz, excessive permissions, lack of rate limiting.
Account / tenant hijacking and insider threats (malicious or negligent).
System vulnerabilities in shared components, guest OS, or application dependencies.
Advanced persistent threats targeting cloud admin paths and CI/CD.
Data breaches and exfiltration via permissive egress, compromised SaaS OAuth apps, or analytics exports.
Denial of service against applications, APIs, or management planes.
Abuse of cloud resources (crypto-mining, spam relays) after compromise.
Shared technology issues — multi-tenant isolation faults (rare but high impact).
Map each threat to preventive, detective, and responsive controls. Example: against credential theft → MFA + conditional access (prevent), anomalous login analytics (detect), automated session revoke and key disable (respond).
Security Hygiene
Hygiene is unglamorous and heavily tested because it fails in real incidents.
Practice Cloud expression
Patching Guest OS and agents (customer in IaaS); consume provider-patched PaaS/SaaS; track shared responsibility explicitly
- Baselining CIS-style benchmarks, landing-zone guardrails, configuration baselines as code
- Immutable architecture Replace rather than mutate servers; golden images/containers; no snowflake hosts
Hardening Disable unused services, tighten kernels/images, remove default accounts, enforce secure defaults in org policies
Immutable infrastructure pairs with orchestration: pipelines build known-good artifacts, deploy new versions, and destroy old ones. Patching then becomes “rebuild from patched base,” which is faster and more consistent than SSH-and-hope — provided your pipeline is secured.
Integrated Scenario (Shared Responsibility)
A company runs a payment API on IaaS VMs, a managed relational database (PaaS), and a SaaS CRM. Attackers phish a developer’s cloud console credentials.
Customer failures: no MFA, standing admin role, SSH open to 0.0.0.0/0, secrets in user data, CRM OAuth app over-scoped.
CSP still responsible for: physical security, hypervisor patching on the IaaS hosts, managed database engine patching within the PaaS SLA, SaaS application code security.
Corrective design: SSO+MFA, JIT admin, NSGs limited to bastion or zero-trust access, CMKs for database and volumes, private database endpoints, CRM token review, immutable VM images, continuous config baseline scanning.
The exam answer is rarely “blame the CSP” for a wide-open security group.
Common Traps
Believing encryption without key-management discipline equals strong control.
Hardening only human users while automation roles have *:* permissions.
Assuming delete in the console equals cryptographically assured sanitization without understanding key custody.
Treating serverless as “no security work” because there is no guest OS to patch.