Chapter 16: Cloud Security and Service Assurance

The shared responsibility model is the foundational concept for cloud security design. The cloud service provider (CSP) secures the infrastructure of the cloud, while the customer secures what they put in the cloud. Crucially, responsibility shifts depending on whether the deployment is IaaS, PaaS, or SaaS.

Provider responsibilities: Physical data center security, hypervisor integrity, core networking infrastructure, environmental controls, and compliance certifications (SOC 2, ISO 27001, FedRAMP).

Customer responsibilities: Identity and access management, network configuration (security groups, firewall rules, VPC design), application security, data encryption, logging and monitoring, and patch management (for IaaS).

Table 16-1: Shared Responsibility Matrix by Service Model

Figure 16.1: Shared Responsibility Model -- Responsibility Shifts by Service Model

Key Takeaway: The customer always retains responsibility for identity governance, access control, and data classification -- regardless of the service model. Designs must account for these non-delegable responsibilities.

A Cloud Access Security Broker (CASB) sits between cloud consumers and providers, enforcing security policies for cloud application access. CASBs deliver four pillars of functionality: Visibility (discovering sanctioned and shadow IT), Compliance (enforcing data residency and regulatory controls), Data Security (DLP, encryption, tokenization), and Threat Protection (malware, compromised accounts, insider threats).

Multimode CASBs operate in two modes: inline (proxy-based, real-time inspection) and out-of-band (API-based, scanning configurations and stored data). A well-designed architecture typically uses both.

Figure 16.2: CASB Deployment Modes -- Forward Proxy, Reverse Proxy, and API

SASE (Secure Access Service Edge) is a cloud-native architecture that converges networking and security into a single platform: SD-WAN, SWG, CASB, FWaaS, and ZTNA under a unified policy engine. Security follows the user regardless of location.

The design advantage is unified policy management -- rather than maintaining separate policies across disparate tools (which leads to policy drift and inconsistent enforcement), SASE consolidates everything into a single cloud-based platform.

Key Takeaway: SASE is not a product but an architectural framework. CASB is a component within SASE. The design question is never "CASB vs. SASE" -- it is "How do we architect a SASE deployment that properly implements zero-trust principles?"

Data must be encrypted both at rest and in transit. Transit options include IPsec tunnels (site-to-cloud), TLS 1.3 (application-layer), and MACsec (dedicated interconnects). For data at rest, the critical design decision is key management:

For multi-cloud environments, an external HSM or BYOK strategy provides consistent key management across providers, avoiding vendor lock-in for cryptographic operations.

SLAs are the quantitative foundation for design decisions about redundancy, failover, and provider selection. Core components include Service-Level Objectives (SLOs), exclusions, remedies/penalties, disaster recovery commitments (RPO/RTO), and security standards.

Table 16-5: Availability Tiers and Corresponding Downtime

Key Takeaway: SLA credits compensate for downtime but do not compensate for lost revenue or reputation. Design for the availability your business actually requires, not just what the SLA guarantees.

Active monitoring injects synthetic transactions to measure performance proactively. Passive monitoring observes actual user traffic in real time (NetFlow, sFlow, IPFIX, RUM). The recommended approach is hybrid monitoring -- active monitoring catches problems before users notice; passive monitoring reveals true user experience.

Redundancy follows a four-tier layered approach, each increasing both resilience and cost:

1. Intra-zone: Multiple instances within one AZ behind a load balancer. Protects against instance failure only.
2. Cross-zone: Instances across multiple AZs within a region. Minimum recommended for production.
3. Cross-region: Workloads replicated across geographically separated regions. Adds data sync and DNS failover complexity.
4. Multi-cloud: Distributed across different CSPs. Maximum resilience, highest operational complexity. Requires abstraction layers (Terraform, Kubernetes).

The design trade-off is always cost versus resilience. Match the redundancy tier to the business's RTO/RPO requirements and budget.

ZTNA replaces the implicit trust of VPNs with "never trust, always verify." Users authenticated via ZTNA can reach only the specific applications they are authorized to use -- the rest of the network is invisible. This dramatically reduces attack surface and prevents lateral movement.

Figure 16.3: ZTNA Access Flow -- Identity Verification and Per-Application Tunnel Establishment

Key Takeaway: ZTNA does not replace the network -- it replaces the assumption that being "on the network" means you should be trusted. ZTNA is the access model; SD-WAN, MPLS, or internet remain the transport.

Figure 16.4: Phased ZTNA Deployment -- Progressive Migration from VPN to Full Zero Trust

Micro-segmentation is the enforcement mechanism that makes zero trust operational at the network level. While macro-segmentation isolates entire networks, micro-segmentation provides fine-grained controls within a segment, governing east-west traffic between individual workloads.

Three design principles:

1. Visibility: Complete mapping of all assets, dependencies, and communication flows must precede any policy enforcement.
2. Granular Security: Policies enforced at the workload/application level, not the perimeter. Only explicitly permitted communication paths are allowed.
3. Dynamic Adaptation: Identity-based rules (tags, labels, service accounts) rather than IP-based rules that break when addresses change.

Implementation methods: cloud-native security groups/NSGs, software-defined perimeters, service mesh (Istio, Linkerd), and host-based firewalls.

Business impact: organizations implementing segmentation experience a 60% reduction in cyber attack costs (IBM research), and 88% of cybersecurity leaders consider micro-segmentation pivotal for zero trust.

SASE and ZTNA are complementary layers: ZTNA provides the access model (identity-verified, per-application), while SASE provides the delivery platform (cloud-native, converged networking and security).

Figure 16.5: SASE and Zero Trust as a Unified Architecture

Key Takeaway: In cloud environments, security and assurance must be identity-centric, policy-driven, and continuously verified. Static, perimeter-based approaches do not survive the transition to cloud.