Cloud and Resilience — Security+

The shared-responsibility model splits duties between provider and customer, and the split shifts by service model: IaaS leaves the most to the customer (OS and up), SaaS the least (just data, identity, and configuration). Misconfiguration — public storage buckets, over-broad IAM, exposed management ports — rather than provider breach, is the dominant cause of cloud incidents.

With SaaS the provider runs the entire stack; the customer is responsible only for their data, user identities, and in-app configuration (sharing settings, access roles). A CASB (Cloud Access Security Broker) provides cross-SaaS visibility, DLP, and policy enforcement, helping rein in shadow IT and risky sharing.

PaaS provides a managed runtime, OS, and middleware so developers deploy code without managing servers; the provider patches the platform while the customer stays responsible for application security, data, and identity. Examples include managed databases, app-engine platforms, and serverless runtimes.

IaaS provides virtualized compute, storage, and networking; the provider secures the physical and virtualization layers while the customer owns everything from the guest OS up — patching, security groups, IAM, and application security. Examples include EC2, Azure VMs, and Google Compute Engine.

Type 1 (bare-metal) hypervisors such as ESXi and Hyper-V run directly on hardware and dominate data centers; Type 2 hypervisors run atop a host OS (VirtualBox, VMware Workstation) for desktop use. VM escape — a guest breaking isolation to reach the host or sibling VMs — is the worst-case failure and the reason timely hypervisor patching is critical.

Containers share the host kernel, so they start fast and pack densely — but a kernel exploit can affect every container on the host, weaker isolation than a hypervisor’s. Harden the supply chain with image scanning, signed images, minimal base images, and admission controllers that reject noncompliant workloads.

IoT devices are constrained embedded systems that often ship with default credentials, lack update mechanisms, and run forgotten for years — the conditions that fueled botnets like Mirai. Treat them as untrusted: isolate them on dedicated VLANs, change defaults, disable unused services, and monitor for anomalous outbound traffic.

SCADA and broader ICS/OT systems run physical processes in utilities, plants, and factories — often on legacy protocols with no authentication and long patch cycles — so availability and safety outrank confidentiality. Protect them with air-gaps or unidirectional gateways, and segment IT from OT using the Purdue Model’s hierarchy of levels.

The 3-2-1 rule (3 copies, 2 media types, 1 offsite) is the baseline; current guidance adds a fourth principle — at least one immutable or air-gapped copy that ransomware can’t encrypt. Test restores on a schedule, because an untested backup is not a backup; recovery-time and recovery-point objectives (RTO/RPO) define how fast and how current those restores must be.

Failover automatically shifts load to a standby system when the primary fails, protecting availability. Active-active runs both nodes at once (maximizing capacity and enabling load balancing); active-passive keeps a warm or cold standby (simpler, but idle capacity). Failover paths must be tested and documented in the DR plan, or they may not work when they’re needed most.

A snapshot captures a VM or disk’s state at a point in time for fast rollback after a bad patch or change. It is not a true backup — it usually shares storage with the primary, so it shares fate in a hardware failure or ransomware event. Immutable, off-host snapshots resist tampering and help bridge the gap toward real backups.

Segmentation divides a network into zones so a breach in one can’t move laterally into others, shrinking the blast radius. VLANs, firewalls, and host-based policies layer together; micro-segmentation pushes the idea to per-workload rules in cloud and data-center environments and is a pillar of zero trust.