Security Architecture and Engineering
Security Architecture and Engineering
This domain tests secure design principles, cloud responsibility boundaries, cryptographic engineering, and resilience. Items typically describe a system and ask who owns a control, or which principle a design violates.
Design principles
Least privilege, defense in depth, complete mediation, economy of mechanism, open design (security by obscurity fails), separation of duties, least common mechanism, and fail-safe defaults - deny on failure. Fail-open is acceptable only where safety or availability genuinely outranks confidentiality, and then only with explicit justification and compensating monitoring.
Cloud shared responsibility
IaaS: the provider secures facilities, hardware, and hypervisor; you patch the guest OS, applications, data, identity, and configuration. PaaS: you own the application, data, and configuration; the runtime and OS belong to the provider. SaaS: you own data, identities, and usage configuration - including sharing settings. CASB brokers sanctioned and unsanctioned SaaS use; SASE converges network and security functions as a service. Getting the boundary wrong is the single most common cloud error.
Cryptographic engineering
Key management is the hard part: generation, rotation, storage, and destruction. HSMs perform key operations without exporting keys; TPMs bind keys to a device; KMS supports envelope encryption with data keys. Hashing gives integrity, HMAC gives integrity plus authenticity, digital signatures give authenticity plus non-repudiation, and AEAD modes give confidentiality plus integrity. Plan crypto agility so an algorithm can be replaced without redesigning the system.
Resilience, physical, and embedded
3-2-1 backups (three copies, two media types, one offsite or immutable), with tested restores - an untested backup is a hope, not a control. HA clustering and geographic redundancy address availability. Physical layers: perimeter, mantraps, CCTV, environmental controls. ICS and IoT devices often cannot be patched or run agents, so compensate with network segmentation and strict allow-listing.
Worked example
"In IaaS, who patches the guest operating system?" You do. The provider's responsibility ends at the hypervisor. In a SaaS deployment the equivalent patch is entirely the provider's job, and your obligation shifts to configuration and identity governance.
Traps
Encryption at rest does not replace access control - the keys and the identities that reach them still govern. Obscurity is not a control. Containers share the host kernel, so isolation differs materially from virtual machines.