CCSK · Domain 1
Cloud Computing Concepts and Architectures
About 12% of the exam
The five essential characteristics
- On-demand self-service
- provision without human interaction
- Broad network access
- reached over standard networks
- Resource pooling
- shared capacity, multi-tenancy follows
- Rapid elasticity
- scale out and back quickly
- Measured service
- metered, reported, billed by use
- Not just hosting
- remote hosting alone is insufficient
- Pooling implies
- isolation becomes a security control
- Metering enables
- cost governance and abuse detection
All five characteristics must be present, so remote hosting on somebody else's hardware is not cloud on its own
Service models
- IaaS
- you get compute, storage, network
- PaaS
- provider runs the platform runtime
- SaaS
- provider runs the whole application
- IaaS duty
- guest operating system and above
- PaaS duty
- your code, data and configuration
- SaaS duty
- identity, data and sharing settings
- Serverless
- platform runs code on demand
- Containers
- straddle the service model boundary
Deployment models
- Public
- open to the general public
- Private
- single organization, hosted anywhere
- Community
- shared by parties with common concerns
- Hybrid
- distinct clouds bound by technology
- Multi-cloud
- several providers, not one architecture
- Hosted private
- single tenant, third party operated
- Location
- does not decide the model
- Choice driver
- risk, control and obligation
The logical model layers
- Infrastructure
- compute, storage and network foundations
- Metastructure
- management plane and orchestration interfaces
- Infostructure
- the data itself
- Applistructure
- applications and platform services
- Metastructure is glue
- connects the other three layers
- Where control lives
- configuration happens in metastructure
- Where breaches land
- data sits in infostructure
- Model use
- assign responsibility layer by layer
Shared responsibility
- Responsibility shifts by service model
- Provider secures of the cloud
- Customer secures in the cloud
- Gaps must be found and assigned
- Contract and matrix record the split
- Data classification is never delegated
- Accountability never transfers to the provider
Metastructure and the management plane
Why it matters
- One console reaches the whole estate
- No physical equivalent on premises
- Interface calls replace data center access
Attacks
- Stolen administrator credentials scale instantly
- Compromise means create, copy, delete
- Recovery keys held in the same plane
Controls
- Strong authentication on every administrator
- Separate accounts for separate blast radius
- Log every management plane call
Reference architectures
- A template of components and relationships
- Vendor neutral, adapted rather than adopted
- Start from requirements, not the catalog
- Maps controls to risk and obligation
- Gives a shared vocabulary across teams
- Reusable abstraction, not a finished design
Abstraction and automation
- Abstraction hides some attack surface
- Abstraction also hides what you cannot see
- Automation enforces consistency at scale
- Automation replicates mistakes just as fast
- Declared infrastructure makes state reviewable
- Immutable deployment removes configuration drift
Multi-tenancy and isolation
- Pooling means neighbors share the hardware
- Isolation is enforced by the provider
- Hypervisor and network fabric stay opaque
- Tenant leakage bugs are provider failures
- Noisy neighbors affect performance not confidentiality
- Dedicated hardware buys isolation at cost
Building the security program
- Identify requirements
- Choose provider and model
- Define architecture
- Assess control gaps
- Manage and improve
Design top down from business and regulatory requirements so every control traces back to a real obligation
Where controls come from
- Provider controls you inherit
- Customer controls you implement
- Compensating controls close the remainder
- Contract fills what neither covers
- Document the gap, never ignore it
- Assurance evidence proves the inheritance
Concept mistakes
- Assuming private cloud means on premises
- Treating multi-cloud as one architecture
- Copying a reference architecture unchanged
- Leaving the management plane out of threat models
- Believing the provider owns your data risk
Rapid recall: model and layer
- Managed database service
- platform as a service
- Virtual machines and volumes
- infrastructure as a service
- Hosted email suite
- software as a service
- Shared by peer regulators
- a community cloud
- Console and orchestration
- the metastructure layer
- The data itself
- the infostructure layer
- Metering and billing
- measured service
- Nobody to ask for capacity
- on-demand self-service
Reference strip: characteristics, service, deployment, layers, program
Characteristics
- On-demand self-service provisioning
- Broad network access
- Resource pooling across tenants
- Rapid elasticity in both directions
- Measured and metered service
Service models
- IaaS gives raw building blocks
- PaaS gives a managed runtime
- SaaS gives a finished application
- Responsibility shrinks as abstraction grows
Deployment models
- Public, private, community, hybrid
- Location does not decide it
- Multi-cloud is a choice, not a model
Logical model
- Infrastructure under everything
- Metastructure is the glue
- Infostructure holds the data
- Applistructure runs the applications
Program
- Requirements before technology
- Architecture before control selection
- Gap analysis then compensation
- Document the responsibility split
Quick exam traps
- Trap: Any workload in a data center you do not own is cloud
- Trap: Private cloud has to be hosted on your own premises
- Trap: The provider becomes accountable for compliance of your data
- Trap: Multi-tenancy is only a performance concern
- Trap: A reference architecture can be adopted without tailoring
- Trap: PaaS removes your responsibility for application configuration
- Trap: The management plane has a direct on-premises equivalent
cybercertprep.com · original revision sheet written from the public body of knowledge