Domain 1 of 6 · Chapter 4 of 5

Secure Cloud Design Principles

Unlock the complete study guide + 1,040 practice questions across 16 full exams.

Bundled into the existing Certified Cloud Security Professional premium course — no separate purchase.

Included in this chapter:

  • The cloud secure data lifecycle
  • Security responsibility by service model
  • BC/DR sized by the business impact analysis
  • Portability, interoperability, and vendor lock-in
  • Cloud design patterns and DevSecOps
  • Exam-pattern recognition

Who owns which security control, by service model

Security responsibilityIaaSPaaSSaaS
Data classification & contentCustomerCustomerCustomer
Identity & access managementCustomerCustomerCustomer (configure)
Application securityCustomerCustomerProvider
Guest OS & runtime patchingCustomerProviderProvider
Virtualization / hypervisorProviderProviderProvider
Physical & network infrastructureProviderProviderProvider

Decision tree

What does the scenario ask?pick the design leverWho secures what?How resilient?Can we leave?Service model chosen?IaaS / PaaS / SaaS lineBIA cost justifies it?match RTO/RPO to costPortable by design?open formats + IaCLowHighCustomer owns data + IAMin every modelCheapest tierbackup or pilot lightWarm / multi-regiononly if cost-justifiedAbstract + reversibilitycontract clauseAlways: classify at Create; crypto-shred at Destroythe data lifecycle frames every lever
Cheat sheet

Cheat sheet

  • The cloud secure data lifecycle has six phases in fixed order
  • Destroy data in the cloud by crypto-shredding, not by wiping media
  • At-rest encryption does nothing for data in the Use phase
  • The shared-responsibility line moves with the service model
  • Data and identity stay with the customer in every service model
  • In PaaS and SaaS the provider patches the OS; in IaaS you do
  • Size BC/DR from a business impact analysis, not from technology
  • RTO sizes recovery speed; RPO sizes acceptable data loss
  • Pick the cheapest recovery tier that meets the RTO/RPO
  • Test the DR plan; an untested plan is not a plan
  • Vendor lock-in is an availability risk, not just a commercial one
  • Portability, interoperability, and reversibility are distinct properties
  • Preserve portability with open formats, abstraction, and IaC
  • Put reversibility (data return and verified deletion) in the contract
  • Classic secure-design principles still govern cloud
  • Well-Architected security pillars are vendor-neutral principles
  • CSA Enterprise Architecture maps controls, it is not a product
  • Each pipeline stage runs its own DevSecOps control
  • The CSA Enterprise Architecture was built from TOGAF, ITIL, SABSA, and Jericho
  • CSA EA has four domains: BOSS, ITOS, TSS, and SRM
  • CSA EA's TSS domain stacks four layers from Presentation down to Infrastructure

Unlock with Premium — includes all practice exams and the complete study guide.

Also tested in

References

  1. CSA Security Guidance for Critical Areas of Focus in Cloud Computing Whitepaper
  2. NIST Glossary — Data Loss Prevention (DLP)
  3. NIST SP 800-88 Rev. 1 — Guidelines for Media Sanitization Whitepaper
  4. NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems Whitepaper
  5. AWS Well-Architected Framework — Security Pillar Well-Architected
  6. Azure Well-Architected Framework — Security Well-Architected