CCSP · Domain 1
Cloud Concepts, Architecture and Design
About 17% of the exam
Five essential characteristics
- On-demand self-service
- provision without human provider contact
- Broad network access
- standard mechanisms, many client types
- Resource pooling
- multitenant pool, location independent
- Rapid elasticity
- scale out and in, appears unlimited
- Measured service
- metered, monitored, billed by use
NIST SP 800-145: five characteristics, three service models, four deployment models
Service models and shared responsibility
IaaS
- Provider: facility, hardware, hypervisor, network
- Customer: OS, middleware, apps, data
- Most customer control, most customer work
- Compute, block storage, virtual networks
PaaS
- Provider adds OS and runtime
- Customer: application code, data, access
- Databases, message queues, container platforms
- Patching the platform is provider work
SaaS
- Provider runs the whole application
- Customer: data, users, configuration
- Least control, least operational burden
- Contract and configuration are your levers
The customer is always responsible for its data, its users and its access decisions, whatever the model
Deployment models
- Public
- provider owned, open to anyone
- Private
- one organization, on or off premises
- Community
- shared by organizations with common needs
- Hybrid
- two or more models, bound by portability
- Multi-cloud
- several providers, avoids lock-in
Hybrid: sensitive processing stays private while elastic workloads burst to public
Cloud roles
- Cloud service provider
- makes the service available
- Cloud service customer
- consumes it, owns the data
- Cloud service partner
- supports provider or customer
- Cloud broker
- intermediates, aggregates, arbitrages
- Cloud auditor
- independent assessment of controls
- Cloud carrier
- network transport between parties
- Regulator
- sets the rules both must meet
Building blocks
- Compute: VMs, containers, functions
- Storage: block, object, file, ephemeral
- Network: virtual networks, SDN, load balancers
- Virtualization abstracts hardware into pools
- Orchestration coordinates services and resources
- Management plane: the console and APIs
- Compromise the management plane, own everything
Virtualization and hypervisors
- Type 1 hypervisor
- bare metal, smaller attack surface
- Type 2 hypervisor
- runs on a host OS
- VM escape
- guest breaks out to host
- VM sprawl
- unmanaged machines, unpatched risk
- Containers
- share host kernel, lighter isolation
- Serverless
- functions, provider runs the runtime
- Hardware-assisted
- strongest tenant isolation
Multitenancy risks
- Shared hardware, logical separation only
- Tenant isolation failure leaks data
- Noisy neighbor consumes shared capacity
- Side channels across shared CPU cache
- Data remanence after deprovisioning
- Misconfiguration is the top breach cause
- Dedicated hosts buy physical isolation
Isolation is the provider's promise; configuration is the customer's problem
Design principles
Resilience
- Design for failure, expect components to die
- Fault tolerance keeps running through faults
- Multiple availability zones per region
- Auto-scaling replaces unhealthy instances
- Circuit breakers stop cascading failures
Cloud-native
- Loosely coupled microservices
- Stateless services scale horizontally
- Immutable infrastructure, replace not patch
- Infrastructure as code, versioned and reviewed
- APIs first, everything automated
Trade-offs
- CAP: consistency or availability under partition
- Elasticity versus predictable cost
- Portability versus provider-specific features
- Interoperability through open standards
- Vendor lock-in and lock-out
Secure architecture
- Zero trust: verify every request, everywhere
- Identity is the new perimeter
- Defense in depth with segmented tiers
- Security groups between web, app, data
- Bastion host for administrative entry
- API gateway authenticates and throttles
- Encrypt in transit and at rest
- Least privilege for people and workloads
Cloud threats to name
- Misconfiguration and exposed storage
- Weak identity, credential and key management
- Insecure interfaces and APIs
- Account hijacking of the console
- Insider threat, including provider staff
- Metastructure and applistructure failures
- Limited visibility into provider layers
- Abuse of cloud for attack infrastructure
Frameworks and standards
- NIST SP 800-145
- the cloud definition
- NIST SP 500-292
- cloud reference architecture, roles
- ISO/IEC 17788, 17789
- vocabulary, reference architecture
- CSA CCM
- cloud controls matrix, mapped domains
- CSA STAR
- self-assessment, attestation, continuous
- ISO/IEC 27017
- cloud security controls
- ISO/IEC 27018
- PII protection in public cloud
- CSA Enterprise Architecture
- business, IT, security domains
Evaluating a cloud move
- Business requirements drive the architecture
- Total cost of ownership, not price
- Data classification decides placement
- Regulatory constraints on location
- Exit strategy before entry
- Verify provider claims through audits
- SLA defines uptime, penalties, remedies
- Pilot, then migrate by criticality
Read the SLA for what is excluded: maintenance windows, force majeure, credits capped at fees
Key numbers
- 99.9% uptime
- about 8.76 hours down yearly
- 99.95% uptime
- about 4.38 hours down yearly
- 99.99% uptime
- about 52.6 minutes down yearly
- 99.999% uptime
- about 5.26 minutes down yearly
- Characteristics
- five essential
- Service models
- three: IaaS, PaaS, SaaS
- Deployment models
- four: public, private, community, hybrid
- STAR levels
- 1 self, 2 third-party, 3 continuous
Reference strip: models, roles, standards, threats
Service models
- IaaS: you manage from OS up
- PaaS: you manage code and data
- SaaS: you manage users and configuration
- Control shrinks as the stack rises
Roles
- CSP provides, CSC consumes
- Broker aggregates and intermediates
- Auditor independently assesses
- Carrier connects, partner supports
Standards
- NIST 800-145, 500-292
- ISO 17788, 17789, 27017, 27018
- CSA CCM, STAR, Enterprise Architecture
- ISO 27001 for the ISMS
Architecture words
- Multitenancy, isolation, resource pooling
- Management plane, orchestration, SDN
- Immutable, stateless, microservices
- Zero trust, defense in depth
Threats
- Misconfiguration, exposed buckets
- Hypervisor escape, side channels
- Account hijacking, weak keys
- Lock-in, lock-out, provider exit
Quick exam traps
- Trap: In SaaS the provider is responsible for your data
- Trap: IaaS gives the customer the least security work
- Trap: A private cloud must be on the customer's premises
- Trap: Containers isolate tenants as strongly as virtual machines
- Trap: Hybrid cloud simply means using two public providers
- Trap: A Type 2 hypervisor has the smaller attack surface
- Trap: The cloud broker owns the customer's data
- Trap: 99.9% availability allows about one hour of downtime a year
cybercertprep.com · original revision sheet written from the public body of knowledge