8.3 Compliance Frameworks, Sensitive Data Protection & Security Command Center

Compliance Frameworks, Sensitive Data Protection & Security Command Center

Core Principle: Maintaining regulatory compliance and continuous security posture in Google Cloud requires three synchronized pillars: Data Governance (Sensitive Data Protection to discover, classify, and sanitize PII), Posture Management & Threat Detection (Security Command Center to detect misconfigurations and active runtime attacks), and Auditing & Oversight (Cloud Audit Logs, Access Transparency, and Access Approval to monitor both customer and Google administrative actions).

---

Sensitive Data Protection (Cloud DLP): Inspection & De-identification

Sensitive Data Protection (formerly Cloud DLP) is a fully managed service that provides automated discovery, classification, and transformation of sensitive data (Personally Identifiable Information [PII], Protected Health Information [PHI], credit card numbers, credentials) across Cloud Storage, BigQuery, and relational databases.

+-----------------------------------------------------------------------------------+
|                    SENSITIVE DATA PROTECTION TRANSFORMATION STACK                 |
+-----------------------------------------------------------------------------------+
|  1. DISCOVERY & INSPECTION                                                        |
|     - Scans text, images, structured tables, unstructured blobs                   |
|     - 150+ Built-in infoTypes (e.g., US_SOCIAL_SECURITY_NUMBER, CREDIT_CARD_NUMBER)|
|     - Custom infoTypes (Regex, Custom Dictionaries, Contextual Rules)             |
+-----------------------------------------------------------------------------------+
|  2. DE-IDENTIFICATION & SANITIZATION METHODS                                      |
|     ├── Redaction / Masking: Replace characters with fixed tokens                 |
|     ├── Bucketing: Replace exact numerical values with generalized ranges         |
|     ├── Date Shifting: Shift dates randomly per user by a consistent delta         |
|     ├── Crypto-Hashing: HMAC-SHA256 one-way pseudonyms                             |
|     ├── Deterministic Encryption: AES-SIV reversible; preserves relational joins  |
|     └── Format-Preserving Encryption (FPE): Preserves length/charset for schemas  |
+-----------------------------------------------------------------------------------+

Comprehensive De-identification Techniques Comparison

[!CAUTION] Format-Preserving Encryption (FPE) vs. Breaking Legacy Schemas: When migrating legacy on-premises applications to Google Cloud, database schemas often have strict column type constraints (e.g., VARCHAR(16) for credit card numbers or CHAR(9) for SSNs). Standard AES encryption outputs variable-length base64 ciphertext that breaks these schema constraints. In such scenarios, Format-Preserving Encryption (FPE) is the required architectural choice because it outputs ciphertext conforming strictly to the original length and character set.

---

Security Command Center (SCC): Architecture, Tiers & Threat Detection

Security Command Center (SCC) is Google Cloud's centralized security information and event management (SIEM) and cloud security posture management (CSPM) platform.

+-----------------------------------------------------------------------------------+
|                    SECURITY COMMAND CENTER (SCC) ARCHITECTURE                     |
+-----------------------------------------------------------------------------------+
|  ASSET INVENTORY       |  Real-time tracking of all GCP projects, IAM, and assets |
+------------------------+----------------------------------------------------------+
|  VULNERABILITY         |  - Security Health Analytics (Misconfiguration checks)   |
|  ASSESSMENT            |  - Web Security Scanner (XSS, flash injection in apps)   |
|                        |  - Rapid Vulnerability Detection (Zero-day CVE scans)    |
+------------------------+----------------------------------------------------------+
|  COMPLIANCE MAPPING    |  - CIS Google Cloud Benchmark                            |
|                        |  - PCI-DSS v4.0, NIST 800-53, ISO 27001, HIPAA           |
+------------------------+----------------------------------------------------------+
|  THREAT DETECTION      |  1. Event Threat Detection (Audit log stream analysis)   |
|  ENGINES               |  2. Container Threat Detection (GKE kernel inspection)   |
|                        |  3. VM Threat Detection (Hypervisor agentless RAM scan)  |
+-----------------------------------------------------------------------------------+

SCC Service Tiers Comparison

Specialized SCC Threat Detection Engines

1. Event Threat Detection (ETD): Continuously parses Cloud Logging audit streams using machine learning and Google threat intelligence. It detects threats such as brute-force SSH attacks, IAM privilege escalation, abnormal service account creation, malware communication, and cryptocurrency mining API calls.
2. Container Threat Detection (CTD): Operates at the Linux kernel level on GKE worker nodes to detect active runtime container attacks, including added binary execution, suspicious library loading, and reverse shell execution inside pods.
3. Virtual Machine Threat Detection (VMTD): Performs agentless hypervisor-level memory analysis on Compute Engine VMs. Because it inspects memory directly from the Google Cloud hypervisor without running an in-guest OS agent, attackers cannot disable, tamper with, or detect the scanner. It detects kernel-level rootkits and in-memory cryptocurrency mining malware.

---

Cloud Audit Logs & SIEM Logging Sinks

Cloud Audit Logs provide immutable, cryptographically verifiable audit trails documenting administrative operations and data access across Google Cloud projects.

+-----------------------------------------------------------------------------------+
|                         CLOUD AUDIT LOGS ARCHITECTURE                             |
+-----------------------------------------------------------------------------------+
|  ADMIN ACTIVITY LOGS  |  - Configuration / resource creation (e.g., Create VM)    |
|                       |  - Always ON, FREE, 400-day retention in _Default bucket  |
+-----------------------+-----------------------------------------------------------+
|  SYSTEM EVENT LOGS    |  - Automated Google administrative events (Live Migration)|
|                       |  - Always ON, FREE, 400-day retention in _Default bucket  |
+-----------------------+-----------------------------------------------------------+
|  DATA ACCESS LOGS     |  - API calls reading/writing user data (BigQuery, GCS)    |
|                       |  - Admin Read, Data Read, Data Write                      |
|                       |  - DISABLED by default (except BigQuery); BILLABLE        |
+-----------------------+-----------------------------------------------------------+
|  POLICY DENIED LOGS   |  - Emitted when Org Policy / VPC-SC blocks an API call    |
|                       |  - Always ON, FREE, 30-day retention                      |
+-----------------------------------------------------------------------------------+

Audit Log Types Comparison

Centralized Log Sinks & Compliance Routing

To satisfy regulatory audit retention (e.g., 7-year SEC/HIPAA mandates) and enable real-time security operations, architects deploy Aggregated Log Sinks at the Organization or Folder level:

• Cloud Storage Sink: Streams logs to a locked WORM bucket with Bucket Lock for cost-effective, long-term 7-to-10 year compliance archiving.
• BigQuery Sink: Routes logs into BigQuery partitioned tables for rapid forensic SQL investigation and compliance audit queries.
• Pub/Sub Sink: Publishes log events in real-time to external Security Information and Event Management (SIEM) systems (e.g., Google Chronicle, Splunk, Datadog, IBM QRadar).

{
  "name": "org-audit-sink-to-pubsub",
  "parent": "organizations/1234567890",
  "destination": "pubsub.googleapis.com/projects/sec-mon/topics/siem-audit-stream",
  "filter": "logName:(\"logs/cloudaudit.googleapis.com%2Factivity\" OR \"logs/cloudaudit.googleapis.com%2Fdata_access\")",
  "includeChildren": true
}

---

Access Transparency & Access Approval

Enterprise organizations operating in highly regulated sectors require visibility not only into their own users but also into actions taken by Google staff.

+-----------------------------------------------------------------------------------+
|                    ACCESS TRANSPARENCY & APPROVAL WORKFLOW                        |
+-----------------------------------------------------------------------------------+
|  1. Google Support Engineer receives customer support ticket requiring VM debug   |
|  2. ACCESS APPROVAL REQUEST: Google engineer submits formal access request         |
|  3. Customer Security Admin receives email / Pub/Sub alert with justification      |
|  4. Customer Admin explicitly clicks "APPROVE" via Cloud Console or API           |
|  5. Google engineer performs maintenance action within approved time window       |
|  6. ACCESS TRANSPARENCY LOG: Real-time immutable audit log generated in project    |
|     - Log contains: Staff ID, Office Location, Reason, Resource Accessed         |
+-----------------------------------------------------------------------------------+

1. Access Transparency

• Emits real-time audit logs whenever Google personnel access customer content during manual administrative operations (e.g., responding to support tickets or diagnosing physical hardware failures).
• Captures the Google employee's physical office location, the affected resource URI, the exact timestamp, and the referenced support ticket justification ID.
• Integrates seamlessly with existing Cloud Logging sinks and SIEM routing pipelines.

2. Access Approval

• Adds a preventative control layer before Google staff can access customer content.
• When a Google engineer requires access to investigate an issue, an Access Approval Request is sent to the customer's designated administrators via email, Cloud Pub/Sub, or webhook.
• Google personnel cannot access the customer data until an authorized customer administrator explicitly reviews the business justification and issues an approval.

---

Concrete Architectural Scenario: Regulated Healthcare Compliance & Auditing Architecture

Scenario Profile

• Client: National Healthcare Information Network managing electronic health records (EHR).
• Requirements: Automatic detection and de-identification of Protected Health Information (PHI) before BigQuery ingestion; continuous compliance monitoring against HIPAA and CIS GCP benchmarks; 7-year immutable audit log retention for all administrative and data access events; mandatory approval before Google engineers can access production VMs during support incidents.

[ Medical Scans & EHR Records ] ===> [ Cloud Storage Ingestion Bucket ]
                                               │
                   [ Sensitive Data Protection (Cloud DLP Inspection & FPE) ]
                                               │
                                  [ Sanitized BigQuery Dataset ]
                                               │
  +────────────────────────────────────────────┴────────────────────────────────────────────+
  │  SECURITY COMMAND CENTER (SCC) PREMIUM                                                  │
  │  - Continuous HIPAA & CIS GCP Benchmark Compliance Auditing                             │
  │  - Event, Container & VM Threat Detection (Hypervisor Agentless Memory Scan)            │
  +────────────────────────────────────────────┬────────────────────────────────────────────+
                                               │
  +────────────────────────────────────────────┴────────────────────────────────────────────+
  │  GOVERNANCE & AUDITING ARCHITECTURE                                                     │
  │  ├── Aggregated Log Sink (Org Level) ──> Cloud Storage (7-Year Bucket Lock WORM)        │
  │  ├── Pub/Sub Log Sink ─────────────────> Real-Time Chronicle SIEM Ingestion             │
  │  ├── Access Transparency ──────────────> Logs all Google Admin Interactions             │
  │  └── Access Approval ──────────────────> Enforces Customer Sign-off for Google Support  │
  +─────────────────────────────────────────────────────────────────────────────────────────+

Architecture Blueprint

1. Data Sanitization: Sensitive Data Protection runs automated inspection jobs on incoming records in Cloud Storage, applying Format-Preserving Encryption (FPE) to patient medical identifiers to preserve legacy database column formatting before loading into BigQuery.
2. Security Posture & Compliance: SCC Premium deployed across the organization to enforce automated continuous compliance mapping against HIPAA and the CIS Google Cloud Benchmark, with VM Threat Detection monitoring Compute Engine nodes at the hypervisor level.
3. Audit Logging & Retention: Data Access logs enabled for BigQuery and Cloud Storage. An Aggregated Organization Log Sink routes all Admin Activity and Data Access logs to a dedicated Cloud Storage bucket configured with Bucket Lock set to 2,555 days (7 years).
4. Google Administrative Oversight: Access Transparency and Access Approval enabled at the organization root, requiring dual security officer approval for any Google support access requests.

---

[!IMPORTANT] Exam Watch: Remember the crucial difference between Access Transparency and Access Approval: Access Transparency provides detective visibility (logs generated after/during Google staff access), whereas Access Approval provides preventative governance (Google engineers are blocked until a customer administrator explicitly grants approval). For log retention, remember that Admin Activity logs are free and retained for 400 days by default, while Data Access logs are disabled by default (except BigQuery) and billable.