View all study notes here

---

Advanced Network Security Architecture

VPC Service Controls (VPC-SC)

Mitigates internal data exfiltration threats, stopping a principal with valid IAM keys from copying sensitive data to an external, unauthorized destination.

• Establishes a hard cryptographic service perimeter around multi-tenant Google managed services (e.g., BigQuery, Cloud Storage, Cloud Spanner).
• Even with a valid IAM identity, data cannot be moved across the perimeter unless explicit Ingress/Egress rules are defined.
• !! VPC-SC controls the data path, not the identity.
  • IAM controls who can authenticate; VPC-SC controls where that authenticated data can flow.
• Access Levels
  • Create exceptions to perimeter rules based on IP range or device policy.
  • Example: “Allow access to protected BigQuery datasets from corporate office IP ranges even though the perimeter normally blocks all external access.”
• Ingress/Egress Rules
  • Explicitly define which API clients, from which networks, can interact with resources inside the perimeter.
  • Ingress: Allows an external principal or API call to access a resource inside the perimeter.
  • Egress: Allows data inside the perimeter to flow to a resource outside it.
• Dry-Run Mode
  • VPC-SC can be placed in audit mode to log what would be blocked without actually enforcing the block.
  • Critical for safely rolling out perimeters in existing environments without causing unexpected outages.
• Supported Services: Not every GCP service supports VPC-SC. Check the compatibility list for specific services (BigQuery, GCS, Pub/Sub, Cloud KMS, Artifact Registry are commonly supported).

Identity-Aware Proxy (IAP)

• Provides secure, context-aware, VPN-less remote access to internal web applications hosted on GCP and direct administrative terminal access (SSH/RDP) to private VM instances.
• Verifies both user identity and device security posture before granting connection access.
• Sits in front of your application at the load balancer layer.
  • Unauthenticated requests never reach your backend.
• !! IAP replaces the need for a corporate VPN for accessing internal web apps. Users authenticate with their Google identity; no client VPN software required.
• IAP uses roles/iap.httpsResourceAccessor and roles/iap.tunnelResourceAccessor to control who can access which applications and tunnels.
• Context-Aware Access integrations allow IAP to enforce additional conditions (e.g., require the device to be a corporate-managed Chromebook before granting SSH access).

BeyondCorp Enterprise

• Google’s implementation of the Zero Trust model.
• Shifts access controls from network perimeter to individual users, enables secure work from any location without the need for a traditional VPN.
• Use a number of security policies including authentication, authorization, and access control to ensure that only authorized users can access corporate resources.
• Extends IAP by adding client-side contextual variables (device health, geographic location, managed device status) to access decisions.

Cloud Armor

• A global Web Application Firewall (WAF) and enterprise-grade Distributed Denial of Service (DDoS) mitigation fabric.
• Designed to protect workloads sitting behind HTTP/HTTPS external load balancers.
• Key Capabilities:
  • Pre-configured WAF rules for OWASP Top 10 threats (SQL injection, XSS, etc.).
  • IP allowlist/denylist rules (block specific CIDRs or known malicious IPs).
  • Adaptive Protection: Uses ML to automatically detect and suggest rules for emerging Layer 7 DDoS patterns.
  • Rate Limiting: Throttle abusive clients exceeding defined request-per-second thresholds.
  • Bot Management: Integrate with reCAPTCHA Enterprise to challenge or block automated bot traffic.
• Cloud Armor policies are applied to Backend Services on the load balancer, not individual VMs.

VPC-SC vs. Cloud Armor

\	Cloud Armor	VPC Service Controls
Threat	External attacks from the public internet	Internal data exfiltration by insiders
Layer	L3-L7 network edge (WAF/DDoS)	Data plane of GCP managed APIs
Protects	Applications behind HTTP(S) load balancers	Services like BigQuery, GCS, Cloud KMS
Typical Scenario	SQL injection, DDoS attacks, bot floods	Malicious employee copying data to personal GCS bucket

---

Data Protection, Encryption, & Compliance

Key Management Service (KMS)

Cloud hosted service to generate, manage, and use cryptographic keys for encryption, decryption, and digital signing.

• Architecture
  • Key Ring
    • A grouping of keys that belong to a specific project and geographic location.
    • Used to organize keys and assign IAM permissions at a broader scope (e.g., granting access to all keys in the ring).
  • CryptoKey
    • The logical key resource used for cryptographic operations.
    • Contains zero or more CryptoKeyVersions (the actual key material).
    • Can be symmetric (AES-256) or asymmetric (RSA, EC).
  • CryptoKeyVersion
    • The actual bit-string used to perform encryption or decryption.
    • Key versions can be rotated automatically or manually, and they hold the lifecycle state (Enabled, Disabled, Destroyed) of the key material.
• Key Features
  • Supports symmetric and asymmetric keys, as well as hardware-backed keys using Cloud HSM.
  • Automatically rotates keys at set intervals to limit the impact of compromised keys.
  • Integrates with IAM to let you manage permissions on individual keys.
  • Provides the ability to use externally managed keys from partners like Equinix, Fortanix, or Thales.

KMS Tiers

Google Cloud enforces encryption at rest by default for all data. Organizations can scale control over cryptographic keys using three distinct models.

1. Google-Managed Keys (Default)
   • The platform default for all services.
   • Key lifecycle management, rotation schedules, and cryptographic storage are entirely automated by Google.
   • Zero operational overhead but zero customer visibility or control over the key material.
2. Customer-Managed Encryption Keys (CMEK)
   • Keys are generated, managed, and rotated by the customer utilizing the native Cloud KMS engine (or Cloud HSM for hardware-backed key storage).
   • Allows fine-grained IAM governance over who can invoke the keys (e.g., only the data warehouse service account can use the BigQuery encryption key).
   • !! Key Revocation: Disabling or destroying a CMEK key renders all data encrypted with it permanently inaccessible.
     • !! Use with extreme caution.
   • Useful for compliance frameworks requiring customer-controlled key lifecycle audit trails.
3. Customer-Supplied Encryption Keys (CSEK)
   • Keys generated entirely outside of Google Cloud’s infrastructure (e.g., on a customer’s HSM appliance).
   • These keys are passed inline with individual API requests (e.g., GCS upload or Compute Engine disk create).
   • Google uses them in volatile memory to encrypt or decrypt data and immediately purges them.
     • They are never stored or managed by Google.
   • If the customer loses their CSEK key material, the data is permanently unrecoverable.
   • Highest level of key sovereignty, highest operational risk.

KMS Tier Comparison

\	Google-Managed	CMEK	CSEK
Key Location	Google infrastructure	Cloud KMS / Cloud HSM	Customer-owned system
Customer Control	None	Full (via Cloud KMS)	Full (external)
Google Can Access Key?	Yes	No (customer controls)	No (never stored)
Operational Overhead	Zero	Medium	High
Typical Use Case	Default workloads	Regulated industries	Extreme sovereignty requirements

Cloud External Key Manager (Cloud EKM)

• Allows encryption keys to be held in a third-party, external key management system (e.g., Thales, Fortanix) outside of Google’s infrastructure entirely.
• GCP never materializes the key; it makes requests to the external KMS at encrypt/decrypt time.
• Provides the strongest possible key sovereignty guarantee for ultra-regulated environments.

Sensitive Data Protection (formerly DLP API)

• Automatically detects, classifies, and redacts sensitive data properties across major storage and analytical frameworks.
• Supported scan targets: Cloud Storage, BigQuery, Datastore/Firestore, and streaming data via Pub/Sub.
• Built-in detectors for: PII (names, email, phone), payment card numbers (PCI), government IDs (SSN, passport), healthcare data, credentials, and more.
• Can de-identify data via:
  • Redaction: Replace sensitive values with [REDACTED].
  • Masking: Replace characters (e.g., ****-****-****-1234).
  • Tokenization/Pseudonymization: Replace with a reversible token (can be re-identified with a key).
  • Bucketing: Replace specific values with ranges (e.g., age 34 → 30-39).
• Key exam scenario: “Analysts need access to BigQuery data but sensitive PII fields must be hidden…” → Sensitive Data Protection de-identification before exposing data to analyst datasets.

Assured Workloads

Allows businesses and government agencies to build and maintain secure, compliant environments in the public cloud. It automatically applies strict guardrails like data residency limits and personnel controls, so organizations can easily follow complex rules like HIPAA, FedRAMP, or regional data laws.

• Data Residency
  • Locks your data into specific countries or regions. It prevents data from being stored or processed anywhere else.
• Personnel Access Control
  • Limits exactly who can view your data. For example, it restricts Google support staff to background-checked individuals in specific locations.
• Encryption Keys
  • Gives full control over how your data is coded or scrambled. You can use your own Customer-Managed Encryption Keys (CMEK).
• Real time Monitoring
  • Constantly scans your cloud environment to alert you if any rules are broken.
• Assured Workloads uses Control Packages.
  • A preset packages is applied to a cloud folder.
  • The folder then enforces the correct rules for all the files and projects inside it.

Compliance Frameworks on GCP

GCP does not make a workload compliant automatically. Customers must configure resources to meet each framework’s requirements. The Shared Responsibility Model is foundational here.

Shared Responsibility Model

• Google’s responsibility: Security of the cloud.
  • Physical data centre security, hardware, network fabric, and hypervisor.
• Customer’s responsibility: Security in the cloud.
  • IAM configuration, data classification, OS patching, application security, and network design.

Key Frameworks

• PCI-DSS (Payment Card Industry Data Security Standard)
  • Governs storage, processing, and transmission of cardholder data.
  • GCP controls
    • VPC network segmentation, Cloud Armor WAF, Cloud KMS for encryption, VPC-SC perimeters around card data stores, and Data Access Logs for all cardholder data access.
• HIPAA (Health Insurance Portability and Accountability Act)
  • Governs Protected Health Information (PHI) in the US.
  • Requires a Business Associate Agreement (BAA) with Google. GCP offers BAAs for covered services.
  • GCP controls
    • CMEK for PHI at rest, VPC-SC around health data stores, IAP for access control, and Audit Logs for all PHI access.
• GDPR (General Data Protection Regulation)
  • EU regulation governing personal data of EU residents regardless of where data is processed.
  • Key requirements
    • Data residency (restrict processing to EU regions via Org Policy), right to erasure (delete data + CMEK key revocation), and data processing records (Audit Logs + BigQuery export).
  • GCP controls
    • Org Policy constraints/gcp.resourceLocations to pin resources to EU regions, Sensitive Data Protection for PII discovery, and Data Access Logs.

---

Audit Logging Strategy & Log Sinks

Cloud Audit Logs Types

Google Cloud generates four types of audit logs for every project, folder, and organization.

Log Type	Always On?	Billed?	What It Captures
Admin Activity	Yes — immutable	Free	Configuration and metadata changes (e.g., VM created, IAM policy changed, bucket deleted)
Data Access	No — must be enabled	Yes	Read/write operations on data (e.g., BigQuery SELECT, GCS object GET)
System Event	Yes — immutable	Free	GCP-automated actions (e.g., live migration of a VM)
Policy Denied	Yes — immutable	Free	When Org Policy or VPC-SC blocks an action

• !! Admin Activity Logs are always on, immutable, and free. They cannot be disabled by any principal, including Owner.
• !! Data Access Logs must be manually enabled per service, generate significant data volume, and introduce additional storage costs. They are off by default to prevent unexpected billing.
• Data Access Log subtypes:
  • DATA_READ — tracks read operations (e.g., BigQuery.jobs.query)
  • DATA_WRITE — tracks write/mutation operations
  • ADMIN_READ — tracks metadata reads of resource configurations

Log Sinks & Routing

• Log Sinks export copies of log entries from Cloud Logging to external destinations for long-term retention, analytics, or compliance archiving.
• Sinks are configured with a filter (which log entries to export) and a destination.
• Supported Destinations:

Destination	Best For
Cloud Storage	Long-term compliance archiving (cheap, immutable object storage)
BigQuery	Log analytics, SQL queries against audit trails, dashboards
Pub/Sub	Real-time streaming to SIEM tools (Splunk, Datadog, Chronicle)
Cloud Logging Bucket	Centralized log aggregation with extended retention across projects
Chronicle	Google’s native Security Operations (SecOps) / SIEM platform

• Aggregated Log Sinks: Sinks can be created at the Organization or Folder level to capture logs from all child projects in a single export, rather than configuring individual project sinks.
• Log Exclusion Filters: Before exporting, you can define exclusion rules to drop high-volume, low-value log entries (e.g., verbose health check logs from load balancers) to reduce storage costs.

Log Retention

• Default Cloud Logging retention is 30 days for most log types (_Default bucket).
• Admin Activity and System Event logs are retained for 400 days by default at no cost.
• For longer retention (regulatory requirements often specify 1–7 years), export to Cloud Storage via a Log Sink.

---

Architecture Best Practices

Identity Provisioning Best Practices

• Always assign IAM roles directly to Cloud Identity Groups rather than individual email addresses.
  • Manage group membership dynamically via your identity provider (GCDS syncing from AD).
  • Reduces administrative overhead.
    • Onboarding and offboarding users only requires group membership changes, not IAM policy edits across dozens of projects.
• Use Groups as the abstraction layer between human identities and GCP resources.

Service Account Security Best Practices

• Never download service account JSON keys to developer machines or check into source control.
  • Prefer Workload Identity Federation or short-lived tokens via gcloud iam service-accounts generate-access-token.
• Avoid granting broad primitive roles (Editor, Owner) to service accounts.
• Create dedicated service accounts per workload.
  • One service account per microservice or application component.
• A service account can act as both a principal (being granted roles) and a resource (having IAM policies placed on it to control who can impersonate it).
• Periodically audit service account key usage via Cloud Audit Logs and rotate or delete stale keys.

Zero Trust Security Posture

• Never trust network location alone; always verify identity and device posture.
• Use IAP instead of VPNs for human access to internal apps and SSH tunnels.
• Use Workload Identity Federation instead of service account keys for machine-to-machine access across clouds.
• Use VPC-SC to add a data-plane perimeter beyond IAM for your most sensitive managed services.
• Enforce IAM Conditions for just-in-time, time-bound access grants rather than permanent bindings.

---

Key Terms & Definitions

• Organization Policy — Governance control over what resources can be configured; enforces blanket technical restrictions (e.g., ban external IPs) regardless of IAM identity.
• IAM Condition — Attribute-based access control logic embedded in an IAM binding (e.g., time-of-day, resource tags).
• Workload Identity Federation — Allows external workloads (AWS, GitHub Actions, on-prem) to authenticate to GCP using short-lived OIDC/SAML tokens without long-lived service account keys.
• VPC Service Controls — Data-plane perimeter around Google managed services to prevent data exfiltration; separate from and additive to IAM.
• Cloud Armor — L3-L7 WAF and DDoS protection for workloads behind external HTTP(S) load balancers.
• IAP (Identity-Aware Proxy) — Context-aware, VPN-less access control for internal web apps and SSH/RDP tunnels; verifies identity + device posture.
• CMEK — Customer manages keys in Cloud KMS; GCP uses them for encryption but customer controls the lifecycle.
• CSEK — Customer supplies keys inline with API calls; Google uses them in volatile memory only and never stores them.
• Sensitive Data Protection — Scans, classifies, and de-identifies PII and sensitive data across GCS, BigQuery, and streaming pipelines.
• GCDS — One-way sync from on-premises AD/LDAP → Cloud Identity. Never modifies on-premises directory.
• Shared Responsibility Model — Google owns security of the cloud; customer owns security in the cloud.