4.1.1. Cloud and Infrastructure Concepts
💡 First Principle: The cloud doesn't eliminate security responsibilities — it redistributes them between you and the cloud provider according to the shared responsibility model. What changes is who manages each layer, not whether it needs protection.
Responsibility matrix across service models:
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Data | You | You | You |
| Applications | You | You | Provider |
| Runtime | You | Provider | Provider |
| OS | You | Provider | Provider |
| Virtualization | Provider | Provider | Provider |
| Physical | Provider | Provider | Provider |
Whatever the model, the customer always keeps the data and the settings that control who can reach it: access policies, sharing and permission configuration, and deprovisioning accounts when people leave. The provider secures the platform; it cannot know which of your users should still have access or which resources you meant to expose.
Deployment models (NIST SP 800-145): public cloud is shared, multi-tenant infrastructure owned by a provider and open to any customer; private cloud is provisioned for the exclusive use of a single organization, whether on-premises or hosted by a third party, giving it dedicated hardware and the most control; community cloud is shared by a specific group of organizations with common requirements, such as agencies under the same compliance rules; hybrid cloud combines two or more of these, so each workload can be placed where its sensitivity and cost requirements are best met.
Hybrid considerations — most organizations use a mix of on-premises, public cloud, and private cloud. Hybrid architectures require consistent security policies across environments and secure connections between them (VPN, dedicated connections).
Third-party vendors introduce risk through API integrations, shared data, and access permissions. Vendor security must be assessed through contracts, SLAs, and regular audits.
Infrastructure as Code (IaC) defines infrastructure through code templates (Terraform, CloudFormation, ARM templates). IaC enables repeatable, auditable, version-controlled deployments. Security benefit: configuration drift is detectable because the code defines the expected state. Risk: secrets hardcoded in templates become vulnerabilities.
Serverless architectures eliminate server management but introduce new considerations: each function needs minimal permissions (least privilege), execution time should be limited, and dependencies must be scanned for vulnerabilities.
Microservices decompose applications into small, independently deployable services. Security implication: more services means more network connections to secure, but compromise of one service doesn't necessarily compromise all.
Containerization packages applications with their dependencies. Containers share the host OS kernel, which means container escape vulnerabilities can compromise the host. Container images must be scanned for vulnerabilities, pulled from trusted registries, and run with minimal privileges.
⚠️ Exam Trap: In IaaS, you're responsible for the OS and everything above it. In SaaS, you're only responsible for your data and access management. If a question asks who is responsible for patching the OS in a PaaS deployment, it's the provider — not you.
