2.3 Security Concepts Relevant to Cloud (Domain 1.3)
Key Takeaways
- 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.
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.
A customer enables default encryption on object storage using provider-managed keys. Which statement is most accurate?
Which identity category most often creates the largest automated blast radius when over-privileged in cloud environments?
In a multi-tenant public cloud, which sanitization approach is generally most practical for making deleted customer data unrecoverable when the customer controlled the encryption keys?
Which hygiene strategy best matches immutable architecture in cloud operations?