12.7.1: Chapter 12

Overview

• Chapter: 12 — Security and Compliance at Scale
• Total Figures Proposed: 8
• Figure Types Used: Architecture Diagram, Flowchart, Conceptual Illustration, Comparison Table, Infographic, Network Diagram

Figure 12.1.1

Title: Cloud Shared Responsibility Model

Detailed Caption: A three-column matrix labels IaaS, PaaS, and SaaS across the top, with seven stacked technology layers running from Data and Application at the top down through Middleware/Runtime, Operating System, Hypervisor/Virtualization, Network, and Physical Infrastructure at the bottom. Each layer cell is filled either teal for "Customer Responsibility" or navy for "Provider Responsibility," and a thin warm-gold dividing line marks the boundary between the two zones in each column — appearing low in the IaaS column, mid-stack in the PaaS column, and near the very top in the SaaS column. Right-side and bottom annotations reinforce the pattern with vertical "Customer / Provider" brackets and a horizontal arrow reading "More customer responsibility" on the IaaS side and "More provider responsibility" on the SaaS side, while a legend identifies the teal, navy, and gold elements. The reader's takeaway is that the security boundary is not fixed but slides up the stack as the service model abstracts more away — and that Data sits above the line in every model, meaning the customer can never delegate responsibility for what they store.

Figure 12.1.2

Title: Common Cloud Threat Vectors

Detailed Caption: Four navy-headed cards arranged in a 2×2 grid radiate from a central gray oval labeled "Cloud Threat Landscape," each card pairing a threat category with concrete examples and teal-shielded mitigations. The top-left card, External Attacks, lists DDoS Attacks, Malware, and Application Exploits, with mitigations covering WAF, DDoS protection, vulnerability scanning, network segmentation, and endpoint protection; the top-right card, Insider Threats, lists Rogue Employees, Credential Misuse, and Privilege Escalation against least-privilege access, MFA enforcement, audit logging, and behavioral monitoring. The bottom-left card, Multi-Tenancy Risks, lists Side-Channel Attacks, Co-Residency Risks, and Data Leakage with dedicated tenancy, encryption at rest, resource isolation, and hypervisor hardening, while the bottom-right card, Misconfiguration, lists Open Storage Buckets, Overly Permissive Policies, and Exposed Ports/Services, defended by Cloud Security Posture Management (CSPM) and Infrastructure as Code scanning with Config rules. By placing four very different attack surfaces around a single hub, the figure shows that no one defense dominates cloud security — readers must reason about all four vectors and pair each with its specific mitigation playbook.

Figure 12.2.1

Title: Cloud IAM Authorization Flow

Detailed Caption: A horizontal flowchart traces a "Request Flow" from left to right, beginning with a navy "Principal (User / App)" box, advancing through a teal "Authentication — Credentials + MFA" box (marked with a small lock icon), then a navy "Request — Action + Resource" box, and into a large navy "Policy Evaluation" panel that internally lists three teal-checked sub-checks: Identity-based Policies, Resource-based Policies, and Conditions (IP, time, tags). Two warm-gold decision diamonds follow in sequence — "Explicit Deny?" and "Explicit Allow?" — with red "Yes/No" branches dropping down to two pink "DENIED" and "DENIED (default deny)" boxes, while the surviving path emerges right into a green-tinted "PERMITTED" box that finally connects to "Access Cloud Resource." The visual makes vivid the deny-by-default logic at the heart of cloud IAM: a request must clear authentication, satisfy at least one allow rule, and carry no explicit deny — and any single failure terminates the request before it touches a resource.

Figure 12.3.1

Title: Envelope Encryption and Key Hierarchy

Detailed Caption: The diagram stacks three labeled layers vertically — Layer 1: Source Data at the bottom, Layer 2: Encrypted Storage in the middle, and Layer 3: Key Management at the top — connected by labeled arrows that animate the encryption flow. The bottom layer shows plaintext files and database records, with an upward arrow "Encrypt with DEK" and a downward arrow "Decrypt with DEK" linking to the middle Ciphertext Layer, where two padlocked tiles labeled Encrypted Data and Encrypted DEK (ciphertext blob) sit side by side. Above them, a navy Cloud KMS rectangle holds a teal Customer Master Key (KEK) panel with a gold-bordered HSM (Hardware Security Module) inside and a separate dark "Root of Trust" tile, joined to the ciphertext layer by bidirectional arrows labeled "Encrypt DEK" and "Decrypt DEK"; a gold-bordered side note emphasizes "Master key never leaves HSM boundary." The layered geometry makes envelope encryption click as a hierarchy: data is wrapped by a working DEK, the DEK is wrapped by a master KEK, and the KEK is anchored in tamper-resistant hardware — so compromising the bulk ciphertext alone yields nothing without traversing the KMS.

Figure 12.4.1

Title: Multi-Layered API Security Architecture

Detailed Caption: A horizontal "Request Flow Direction" arrow runs across the top of the figure, with a navy "API Client" tile on the far left and a navy "Backend Service" tile on the far right; between them stand five vertical barrier panels styled like security gates. The gates, in order, are API Key / Credential Check (navy, key icon), OAuth 2.0 / JWT Validation (teal, JWT badge), Rate Limiting & Throttling (gray, gauge icon), Input Validation & Sanitization (navy, funnel icon), and Continuous Monitoring & Security Testing (teal, eye icon), each topped with a warm-gold checkmark indicating successful passage. A dashed horizontal line carries the request through every gate, while red dashed arrows drop from each gate down into a single coral "Rejected Requests — Requests can be blocked at any layer" box at the bottom. The composition delivers the chapter's defense-in-depth message at a glance: an API isn't protected by one strong wall but by a sequence of independent checks, any one of which can stop a malicious request before it reaches business logic.

Figure 12.5.1

Title: Cloud Audit Logging and Monitoring Ecosystem

Detailed Caption: Three navy-headed source cards stack on the left — IAM / API Activity (CloudTrail, API logs), Resource Configurations (AWS Config changes), and Network / App Logs (VPC Flow Logs, ALB logs) — each feeding arrows into a central navy "Centralized Log Storage" tile labeled with S3, Log Analytics, and CloudWatch Logs. From that hub, three outbound paths fan out: an upward arrow leads to a teal "Threat Detection (GuardDuty / Security Command Center)" box that connects onward to an "Alerts & Notifications" tile with a bell icon; a rightward arrow runs to a "SIEM / Analytics (Splunk, Elastic, Athena)" box and then to "Incident Investigation"; and a downward arrow flows into a teal, gold-bordered "Compliance Dashboards (Security Hub / Azure Security Center)" tile that emits an arrow to "Audit Reports — SOC, HIPAA, GDPR." Drawn as a hub-and-spoke pipeline, the figure resolves what the prose only describes piecewise — that detection, investigation, and compliance are three downstream consumers of one centralized telemetry store, and that breaking any link from source to dashboard blinds an entire class of governance.

Figure 12.5.2

Title: Incident Detection and Response Workflow

Detailed Caption: Six numbered, color-coded stages run left to right above a long gray "Audit Trail & Evidence Preservation" bar that explicitly states "Logging runs continuously throughout all incident response phases." Stage 1 is a warm-gold "Anomaly Detected (GuardDuty / SIEM)" tile with a warning triangle; Stage 2 is a navy "Investigate — Review CloudTrail, access logs, network flow logs" tile with a magnifier icon; Stage 3 is a teal diamond "Confirm Incident?" with a curved dashed feedback arrow looping back to a "Continue Monitoring" pill if the answer is No, and a "Yes" arrow advancing to Stage 4. Stage 4 is a navy "Contain — Disable credentials, isolate resources, revoke sessions" tile, Stage 5 is a teal "Root Cause Analysis — Identify entry point, scope of impact" tile, and Stage 6 is a navy "Remediate & Improve — Patch vulnerability, add Config rules, update policies" tile. The numbered, gated layout teaches incident response as a disciplined sequence — alerts must be triaged before containment, containment before forensics, and forensics before lasting fixes — while the bottom evidence bar reminds readers that auditability is not a final step but a constant.

Figure 12.6.1

Title: Compliance Framework Comparison Matrix

Detailed Caption: A five-column comparison table places GDPR, HIPAA, SOC 2, ISO 27001, and NIST CSF across the top in navy headers, against seven teal row labels: Framework, Type, Geographic Scope, Primary Focus, Key Cloud Requirements, Enforcement, and Cloud Provider Support. Cells distill each framework into 2–4 word entries — for example, GDPR appears as Regulation (Law) covering EU/EEA Data Privacy with Encryption, access control, breach notification, fines up to 4% of global revenue, and DPAs; HIPAA as US-only Protected Health Information with BAAs and HIPAA-eligible services; SOC 2 as an International Audit Standard for Trust Criteria with audit reports; ISO 27001 as an International Certification of an ISMS with certified regions; and NIST CSF as a US-adopted Framework for Cybersecurity Risk with Identify/Protect/Detect/Respond/Recover and FedRAMP mappings. Three "Key Cloud Requirements" cells highlight Encryption and access control in gold, with a footnote explaining "Gold text = overlapping requirements across frameworks." The table makes immediately scannable what would otherwise require five separate readings: the frameworks differ in legal weight and geography but converge on the same technical controls, so a single well-implemented control set can carry an organization across multiple compliance regimes.