|

Building a Sovereign Private Cloud on Google Cloud: Architectural Blueprint, NIS2/DORA Compliance, and Terraform Implementation for Nordic Enterprises

TL;DR

Data sovereignty under EU regulations (NIS2, DORA, and GDPR) requires technical controls, not just regional data hosting. A sovereign private cloud on Google Cloud uses software-defined isolation: Assured Workloads restricts operational regions and personnel; VPC Service Controls (VPC SC) prevents data exfiltration; and Cloud External Key Manager (Cloud EKM) ensures encryption keys remain under European jurisdiction via local partners (such as Thales or T-Systems). This guide provides a comparative architecture analysis across AWS, Azure, and Google Cloud, detailed Terraform code with line-by-line analysis, four production use cases, and resolutions for common operational bottlenecks.

Executive Summary

Organizations across Sweden, Norway, Denmark, and Finland operate under strict regulatory scrutiny from authorities such as Finanstilsynet, Finansinspektionen, and national cybersecurity agencies. With the European Union’s Digital Operational Resilience Act (DORA) and the NIS2 Directive in active enforcement, enterprise data architectures must demonstrate resilience against external legal claims, including the US CLOUD Act.

Returning workloads entirely to on-premises data centers resolves jurisdiction concerns, but introduces high capital expenditure, rigid hardware capacity limits, and loss of advanced managed data services. Google Cloud addresses this trade-off through a Software-Defined Sovereign Cloud architecture. Rather than requiring isolated, air-gapped infrastructure for every workload, it combines physical compute clusters in European regions (such as europe-north1 in Finland) with client-controlled external cryptographic keys and private network perimeters.

1. Business Context and Regulatory Requirements in the Nordics

Nordic enterprises in banking, insurance, healthcare, and energy face specific regulatory mandates that influence cloud architecture decisions:

  • DORA (Regulation EU 2022/2554): Requires financial institutions to maintain ICT operational resilience, strictly manage third-party risk, and retain full oversight of data access and processing.
  • NIS2 (Directive EU 2022/2555): Expands cybersecurity baseline requirements across essential and important sectors (energy, transport, health, public digital infrastructure), mandating strict access controls and supply chain security.
  • Schrems II and Cross-Border Transfers: Requires technical and contractual measures ensuring that foreign entities cannot access data stored within the European Economic Area (EEA) without legal authorization from European courts.
       +--------------------------------------------------------+
       |                  Enterprise Perimeter                  |
       |                                                        |
       |   +-------------------+        +-------------------+   |
       |   | European Key      |        | On-Premises /     |   |
       |   | Manager (EKM)     |        | Internal Users    |   |
       |   | (Thales / Partner)|        |                   |   |
       |   +---------+---------+        +---------+---------+   |
       +-------------|----------------------------|-------------+
                     | Dedicated / VPN            | Private Service
                     | Connection                 | Connect (PSC)
       +-------------|----------------------------|-------------+
       | GCP         v                            v             |
       |   +------------------------------------------------+   |
       |   | VPC Service Controls Perimeter                 |   |
       |   |                                                |   |
       |   |   +------------------+   +-----------------+   |   |
       |   |   | Compute / Cloud  |   | BigQuery / GCS  |   |   |
       |   |   | Run (Private IP) |-->| (CMEK Protected)|   |   |
       |   |   +------------------+   +-----------------+   |   |
       |   |                                                |   |
       |   |   Assured Workloads: EU_REGIONS_AND_SUPPORT    |   |
       |   +------------------------------------------------+   |
       |                                                        |
       | Google Cloud Platform (europe-north1 / Finland)        |
       +--------------------------------------------------------+

To meet these requirements without on-premises hardware limitations, architecture teams implement a sovereign private cloud. In this architecture:

  1. Infrastructure and compute capacity remain managed by the public cloud provider.
  2. Access control and identity are managed within defined operational perimeters.
  3. Cryptographic control is separated from the infrastructure provider through customer-managed or partner-managed external key infrastructure.

2. Google Cloud Sovereign Architecture: Core Components

Google Cloud’s sovereignty architecture relies on five technical controls that operate together.

+------------------------------------------------------------------+
|                     1. Assured Workloads                         |
|   (Enforces geographic boundaries and EU-only support personnel) |
+------------------------------------------------------------------+
                                |
                                v
+------------------------------------------------------------------+
|                  2. VPC Service Controls (VPC SC)                |
|       (Blocks unauthorized API access and data exfiltration)     |
+------------------------------------------------------------------+
                                |
                                v
+------------------------------------------------------------------+
|                 3. Private Service Connect (PSC)                 |
|       (Eliminates public IPs; routes API traffic internally)     |
+------------------------------------------------------------------+
                                |
                                v
+------------------------------------------------------------------+
|                4. Cloud External Key Manager (EKM)               |
|      (Requires external cryptographic grant for data access)     |
+------------------------------------------------------------------+
                                |
                                v
+------------------------------------------------------------------+
|                     5. Confidential Computing                    |
|        (Memory encryption via AMD SEV-SNP or Intel TDX)          |
+------------------------------------------------------------------+

2.1. Assured Workloads

Assured Workloads is a resource hierarchy control applied to GCP Folders. When configured with the EU_REGIONS_AND_SUPPORT compliance regime, it establishes organizational policies that:

  • Block the deployment of resources in non-EU regions.
  • Restrict Google personnel support access exclusively to verified EU residents operating from EU locations.
  • Enforce logging and alerting on any support access requests (Access Approval and Access Transparency).

2.2. VPC Service Controls (VPC SC)

Standard Identity and Access Management (IAM) permissions grant access based on identity credentials alone. If an identity credential is leaked, an unauthorized actor can execute API calls from the public internet.

VPC Service Controls adds contextual, perimeter-based authorization. It treats managed services (such as Cloud Storage, BigQuery, and Vertex AI) as resources within a private network boundary. Requests from outside the defined perimeter are rejected at the Google API gateway level, regardless of the caller’s IAM role.

2.3. Private Service Connect (PSC)

Public cloud services typically resolve to publicly routable IP addresses, even when accessed within the provider’s network. Private Service Connect allows organizations to access Google APIs using private RFC 1918 IPv4 addresses defined directly in their VPC subnets. This configuration eliminates public internet dependencies, simplifies firewall filtering, and keeps all internal network traffic on dedicated, private paths.

2.4. Cloud External Key Manager (EKM)

Google Cloud encrypts all customer data at rest by default using Google-managed encryption keys (GMEK). For sovereign workloads, default encryption is insufficient because Google maintains custody of the key material.

Customer-Managed Encryption Keys (CMEK) via Cloud EKM delegate key custody to an external Hardware Security Module (HSM) managed by a European partner (such as Thales CipherTrust or T-Systems) or the enterprise itself.

  • When a service like BigQuery reads a table, it requests an unwrap operation from Google Cloud KMS.
  • Cloud KMS relays the request over a secure connection to the partner EKM gateway.
  • If the partner gateway denies the request, or if the enterprise severs the EKM network connection, the data cannot be decrypted by Google Cloud.

2.5. Confidential Computing

Standard encryption protects data at rest (in storage) and in transit (over the network). Confidential Computing protects data in use (within memory). By using hardware-level memory encryption (such as AMD Secure Encrypted Virtualization-Secure Nested Paging or Intel Trust Domain Extensions), the CPU encrypts memory contents with keys generated and held entirely on-chip. The Google Cloud hypervisor cannot inspect guest operating system memory spaces.

3. Cloud Provider Comparison: Google Cloud, AWS, and Azure

Enterprise architects must evaluate the structural differences between sovereign cloud models across the major providers:

Architectural DimensionGoogle Cloud (Assured Workloads + EKM)AWS (European Sovereign Cloud)Microsoft Azure (Cloud for Sovereignty)
Isolation ModelSoftware-defined perimeters on global physical infrastructureSeparate physical infrastructure and independent partitionSoftware-defined perimeters (Sovereign Landing Zones)
Identity and Access ManagementUnified global IAM governed by contextual perimeter policies (VPC SC)Independent, dedicated IAM per sovereign partitionUnified global Entra ID with regional policy enforcements
Key Custody ArchitectureExternal Key Management (Cloud EKM) via independent EU partnersNative AWS KMS run entirely within the dedicated EU partitionAzure Key Vault Managed HSM with optional Confidential Enclaves
Service Breadth at LaunchFull parity with standard GCP regions (subject to CMEK support)Reduced service catalog (~70 core services initially)Full parity with standard Azure regions
Application Migration ComplexityLow to moderate: existing Terraform modules adapt with policy changesHigh: requires migrating resources into a new AWS partitionLow to moderate: policy and landing zone reconfiguration

Mechanisms: Storage, Compute, Scaling, and Pricing

Storage Mechanisms

  • Google Cloud: Stores data in standard regional or dual-region storage buckets (e.g., europe-north1 in Finland). Cryptographic isolation is enforced through envelope encryption, where the Key Encryption Key (KEK) is held by an external partner. Storage costs match standard regional pricing, but every decryption request generates a KMS and EKM API transaction charge.
  • AWS: In the European Sovereign Cloud, storage blocks reside strictly within dedicated sovereign data centers (beginning in Germany). Data replication cannot leave the partition. Pricing reflects a dedicated partition model, separate from standard AWS global discount structures.
  • Azure: Uses standard Azure Storage with customer-managed keys in Azure Key Vault Managed HSM, backed by FIPS 140-2 Level 3 HSMs.

Compute and Scaling

  • Google Cloud & Azure: Leverage their global scale within Europe. If an enterprise needs 5,000 additional cores or specialized GPU instances for machine learning, they scale elastically against standard regional capacity pools while maintaining logical and cryptographic perimeters.
  • AWS European Sovereign Cloud: Because it operates on dedicated physical infrastructure, resource pools are bound to specific physical sites. Elastic scaling is constrained by the capacity installed in those dedicated facilities.

FinOps and Cost Analysis

Deploying a sovereign architecture introduces specific cost components beyond standard cloud resource consumption:

Architecture LayerStandard Deployment CostSovereign Deployment Cost (Google Cloud)Notes
Regional ComputeStandard n2-standard-4 ($0.19/hr)Confidential n2d-standard-4 (~$0.23/hr)~20% hardware premium for AMD SEV memory encryption
Key ManagementDefault Google-managed (Free)Cloud KMS ($0.06/key/month) + EKM Partner License + API feesExternal HSM licensing and network egress to EKM gateway
Network InfrastructureCloud NAT ($0.045/hr + data processing)Private Service Connect ($0.01/hr per endpoint + data processing)Eliminates public IP usage; requires PSC endpoints
Security ControlsIAM (Free)Assured Workloads (Tiered based on support level)Compliance support coverage fee applies in regulated tiers

4. Step-by-Step Terraform Implementation Guide

The following production-ready Terraform (HCL) code deploys a baseline sovereign cloud environment on Google Cloud.

The configuration enforces:

  1. An Assured Workloads EU compliance folder.
  2. An isolated project with no public egress routes.
  3. Private Service Connect endpoints for Google APIs.
  4. VPC Service Controls perimeter enforcement.
  5. Cloud EKM external key binding.

Prerequisites

  • Terraform CLI (>= 1.5.0) installed.
  • google and google-beta providers configured with administrative privileges at the Organization level.
  • An established GCP Organization ID and Billing Account ID.
       +----------------------------------------------------------------+
       | Step 1: Assured Workloads Folder                               |
       |   Enforces EU_REGIONS_AND_SUPPORT & Project Creation           |
       +-------------------------------+--------------------------------+
                                       |
                                       v
       +----------------------------------------------------------------+
       | Step 2: Custom VPC & Private Subnet                            |
       |   Enforces private_ip_google_access = true                     |
       +-------------------------------+--------------------------------+
                                       |
                                       v
       +----------------------------------------------------------------+
       | Step 3: Private Service Connect (PSC)                          |
       |   Allocates internal IP & routes API traffic                   |
       +-------------------------------+--------------------------------+
                                       |
                                       v
       +----------------------------------------------------------------+
       | Step 4: VPC Service Controls                                   |
       |   Creates Service Perimeter & blocks data exfiltration         |
       +-------------------------------+--------------------------------+
                                       |
                                       v
       +----------------------------------------------------------------+
       | Step 5: External Key Manager (Cloud EKM)                       |
       |   Binds encryption key to partner endpoint                     |
       +----------------------------------------------------------------+

Step 1: Assured Workloads Folder and Sovereign Project

Purpose and Sequence

We create the Assured Workloads boundary before provisioning any cloud resources. This guarantees that all downstream projects inherit the regional and support personnel restrictions from inception.

Terraform

terraform {
  required_version = ">= 1.5.0"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 5.0.0"
    }
    google-beta = {
      source  = "hashicorp/google-beta"
      version = ">= 5.0.0"
    }
  }
}

variable "organization_id" {
  type        = string
  description = "The GCP Organization ID."
}

variable "billing_account" {
  type        = string
  description = "The billing account ID to bind to the project."
}

# 1. Create the Assured Workloads compliance boundary
resource "google_assured_workloads_workload" "nordic_sovereign_folder" {
  provider             = google-beta
  compliance_regime    = "EU_REGIONS_AND_SUPPORT"
  display_name         = "nordic-sovereignty-workload"
  location             = "europe-west1" # Control plane location for metadata
  organization         = var.organization_id
  billing_account      = var.billing_account

  resource_settings {
    resource_type = "CONSUMER_FOLDER"
  }

  labels = {
    environment = "production"
    compliance  = "dora-nis2"
  }
}

# 2. Provision the production project inside the compliant folder
resource "google_project" "sovereign_project" {
  name            = "sovereign-core-prod"
  project_id      = "sovereign-core-prod-01"
  folder_id       = google_assured_workloads_workload.nordic_sovereign_folder.resources[0].resource_id
  billing_account = var.billing_account
  depends_on      = [google_assured_workloads_workload.nordic_sovereign_folder]
}

# 3. Enable mandatory APIs within the sovereign project
resource "google_project_service" "enabled_services" {
  for_each = toset([
    "compute.googleapis.com",
    "bigquery.googleapis.com",
    "cloudkms.googleapis.com",
    "accesscontextmanager.googleapis.com",
    "servicedirectory.googleapis.com",
    "dns.googleapis.com"
  ])

  project                    = google_project.sovereign_project.project_id
  service                    = each.key
  disable_dependent_services = false
  disable_on_destroy         = false
}

Detailed Explanation

  • compliance_regime = "EU_REGIONS_AND_SUPPORT": Instructs the Google Resource Manager to enforce European data residency and EU-only support operations.
  • google_project: Built directly inside the Assured Workloads folder, ensuring that attempts to provision resources in unauthorized regions (e.g., us-central1) fail automatically at the API validation layer.
  • google_project_service: Enables required services explicitly. In a sovereign context, unnecessary APIs should remain disabled to reduce the attack surface.

Step 2: Isolated Virtual Private Cloud (VPC)

Purpose and Sequence

Next, we provision the internal network. We disable default subnet creation and exclude internet gateways, establishing a network that has no direct route to the public internet.

Terraform

# 1. Define custom VPC without default subnets
resource "google_compute_network" "sovereign_vpc" {
  name                    = "sovereign-vpc-nordics"
  project                 = google_project.sovereign_project.project_id
  auto_create_subnetworks = false
  routing_mode            = "REGIONAL"
  depends_on              = [google_project_service.enabled_services]
}

# 2. Define secure subnet with Private Google Access enabled
resource "google_compute_subnetwork" "secure_subnet" {
  name                     = "snet-core-finland-01"
  project                  = google_project.sovereign_project.project_id
  ip_cidr_range            = "10.100.0.0/24"
  region                   = "europe-north1" # Hamina, Finland
  network                  = google_compute_network.sovereign_vpc.id
  private_ip_google_access = true

  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 1.0 # 100% flow logging for compliance audits
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

# 3. Explicitly deny all outbound egress to the public internet
resource "google_compute_firewall" "deny_all_egress" {
  name      = "deny-all-egress-default"
  project   = google_project.sovereign_project.project_id
  network   = google_compute_network.sovereign_vpc.name
  direction = "EGRESS"
  priority  = 65534

  deny {
    protocol = "all"
  }

  destination_ranges = ["0.0.0.0/0"]
}

Detailed Explanation

  • auto_create_subnetworks = false: Prevents Google Cloud from deploying subnets in non-EU regions.
  • private_ip_google_access = true: Enables workloads lacking public IPs to access Google APIs directly through internal Google routing.
  • log_config: Configures 100% network flow sampling (flow_sampling = 1.0), which is an explicit audit requirement under DORA Chapter II (ICT Risk Management).
  • deny_all_egress: A high-priority default rule that blocks all internet-bound egress, preventing data transfers over untrusted external networks.

Step 3: Private Service Connect (PSC) for Google APIs

Purpose and Sequence

To access Google APIs without resolving public IP addresses, we deploy Private Service Connect inside the isolated network.

Terraform

# 1. Allocate an internal IP for the PSC endpoint
resource "google_compute_global_address" "psc_internal_ip" {
  name         = "psc-ip-google-apis"
  project      = google_project.sovereign_project.project_id
  address_type = "INTERNAL"
  purpose      = "PRIVATE_SERVICE_CONNECT"
  network      = google_compute_network.sovereign_vpc.id
  address      = "10.100.0.200"
}

# 2. Deploy the global forwarding rule targeting all Google APIs
resource "google_compute_global_forwarding_rule" "psc_forwarding_rule" {
  name                  = "psc-rule-google-apis"
  project               = google_project.sovereign_project.project_id
  target                = "all-apis"
  network               = google_compute_network.sovereign_vpc.id
  ip_address            = google_compute_global_address.psc_internal_ip.id
  load_balancing_scheme = ""
}

# 3. Configure private DNS to resolve Google API hostnames to the PSC IP
resource "google_dns_managed_zone" "googleapis_private_zone" {
  name        = "private-zone-googleapis-com"
  project     = google_project.sovereign_project.project_id
  dns_name    = "googleapis.com."
  description = "Private DNS override for Google APIs"
  visibility  = "private"

  private_visibility_config {
    networks {
      network_url = google_compute_network.sovereign_vpc.id
    }
  }
}

resource "google_dns_record_set" "googleapis_cname" {
  name         = "*.googleapis.com."
  project      = google_project.sovereign_project.project_id
  managed_zone = google_dns_managed_zone.googleapis_private_zone.name
  type         = "CNAME"
  ttl          = 300
  rrdatas      = ["restricted.googleapis.com."]
}

resource "google_dns_record_set" "restricted_a_record" {
  name         = "restricted.googleapis.com."
  project      = google_project.sovereign_project.project_id
  managed_zone = google_dns_managed_zone.googleapis_private_zone.name
  type         = "A"
  ttl          = 300
  rrdatas      = [google_compute_global_address.psc_internal_ip.address]
}

Detailed Explanation

  • google_compute_global_address: Reserves an internal private IP (10.100.0.200) specifically for Private Service Connect.
  • google_compute_global_forwarding_rule: Binds the IP to the all-apis target, terminating Google API calls on private addresses.
  • google_dns_managed_zone and record_set: Overrides public DNS within the VPC. Any call to storage.googleapis.com or bigquery.googleapis.com resolves internally to 10.100.0.200, preventing direct public DNS lookups.

Step 4: VPC Service Controls (Security Perimeter)

Purpose and Sequence

With the network and routing established, we deploy the VPC Service Controls perimeter at the organization level. This blocks unauthorized access attempts to the data layer.

Terraform

variable "access_policy_title" {
  type        = string
  default     = "Nordic-Enterprise-Access-Policy"
  description = "The title of the organization access policy."
}

# 1. Retrieve or define the organization Access Policy
resource "google_access_context_manager_access_policy" "org_access_policy" {
  parent = "organizations/${var.organization_id}"
  title  = var.access_policy_title
}

# 2. Define the service perimeter enclosing the project
resource "google_access_context_manager_service_perimeter" "sovereign_perimeter" {
  parent = "accessPolicies/${google_access_context_manager_access_policy.org_access_policy.name}"
  name   = "accessPolicies/${google_access_context_manager_access_policy.org_access_policy.name}/servicePerimeters/nordic_sovereign_perimeter"
  title  = "nordic_sovereign_perimeter"
  
  perimeter_type = "PERIMETER_TYPE_REGULAR"

  status {
    resources = [
      "projects/${google_project.sovereign_project.number}"
    ]

    restricted_services = [
      "bigquery.googleapis.com",
      "storage.googleapis.com",
      "cloudkms.googleapis.com"
    ]

    vpc_accessible_services {
      enable_restriction = true
      allowed_services = [
        "bigquery.googleapis.com",
        "storage.googleapis.com",
        "cloudkms.googleapis.com"
      ]
    }

    # Zero-Egress Configuration: No data may leave this perimeter
    egress_policies {}
  }
}

Detailed Explanation

  • google_access_context_manager_service_perimeter: Defines the logical isolation boundary.
  • restricted_services: Declares which Google APIs are blocked from outside access. Any external API invocation targeting BigQuery or Cloud Storage in this project is rejected.
  • vpc_accessible_services: Restricts which APIs compute instances inside the perimeter are allowed to call. This prevents instances from connecting to unauthorized external Google services.
  • egress_policies {}: Leaving this block empty enforces a zero-egress rule. Data cannot be copied from within this perimeter to an external GCP project or public bucket.

Step 5: External Key Manager (Cloud EKM) Integration

Purpose and Sequence

Finally, we bind storage encryption to an external, partner-hosted Key Management Service via Cloud EKM.

Terraform

# 1. Establish an EKM connection pointing to the partner gateway
resource "google_kms_ekm_connection" "partner_ekm" {
  name        = "thales-ekm-nordic-connection"
  project     = google_project.sovereign_project.project_id
  location    = "europe-north1"
  key_management_mode = "MANUAL"

  service_resolvers {
    service_directory_service = "projects/${google_project.sovereign_project.project_id}/locations/europe-north1/namespaces/ekm-ns/services/thales-service"
    hostname                  = "ekm-gateway.nordic-partner.internal"
    endpoint_filter           = "10.100.0.50" # Partner appliance internal IP
  }

  depends_on = [google_project_service.enabled_services]
}

# 2. Create the Cloud KMS Key Ring in Finland
resource "google_kms_key_ring" "sovereign_keyring" {
  name       = "nordic-sovereign-keyring"
  project    = google_project.sovereign_project.project_id
  location   = "europe-north1"
  depends_on = [google_project_service.enabled_services]
}

# 3. Create a cryptographic key tied to the external key URI
resource "google_kms_crypto_key" "ekm_crypto_key" {
  name            = "ekm-master-data-key"
  key_ring        = google_kms_key_ring.sovereign_keyring.id
  purpose         = "ENCRYPT_DECRYPT"
  protection_level = "EXTERNAL_VPC"

  crypto_key_backend = "ekm://${google_kms_ekm_connection.partner_ekm.id}/keys/enterprise-root-key-01"
}

# 4. Deploy a BigQuery dataset encrypted with the EKM key
resource "google_bigquery_dataset" "sovereign_dataset" {
  dataset_id  = "dora_compliant_transactions"
  project     = google_project.sovereign_project.project_id
  location    = "europe-north1"

  default_encryption_configuration {
    kms_key_name = google_kms_crypto_key.ekm_crypto_key.id
  }
}

Detailed Explanation

  • google_kms_ekm_connection: Connects Google Cloud KMS to the partner’s on-premises or co-located HSM via an internal endpoint (10.100.0.50).
  • protection_level = "EXTERNAL_VPC": Guarantees that Google Cloud KMS does not hold the master key material. KMS acts solely as a routing proxy.
  • crypto_key_backend: Points directly to the key identifier on the external HSM.
  • google_bigquery_dataset: Every table created in this dataset automatically inherits CMEK encryption. The data cannot be read without successful real-time decryption authorization from the partner appliance.

5. Practical Production Use Cases

Case 1: Core Banking Ledger Migration (Sweden)

  • Context: A Swedish financial institution migrated its transactional ledger to Google Cloud while maintaining compliance with the Swedish Financial Supervisory Authority (Finansinspektionen) and DORA Article 6 (ICT Risk Management Framework).
  • Architecture: The core transaction engine was built on Cloud Spanner within europe-north1. Master keys were managed on a Thales CipherTrust cluster hosted in a local Stockholm data center.
  • Implementation: The connection between GCP and the on-premises HSM ran over dual dedicated Cloud Interconnect connections. When Spanner initiated an I/O operation, it obtained an unwrapped Data Encryption Key (DEK) via the external HSM. Access to Cloud Spanner management APIs was restricted via VPC Service Controls to on-premises IP subnets.

Case 2: Genomic Data Analysis Platform (Denmark)

  • Context: A Danish national research consortium needed to process sensitive genomic sequences in BigQuery without risking cross-border data exposure under GDPR Article 9.
  • Architecture: The team deployed Confidential Space enclaves on Google Cloud. Raw genome sequencing files were uploaded to a CMEK-protected Cloud Storage bucket.
  • Implementation: BigQuery processed data exclusively inside Confidential VM instances with AMD SEV-SNP memory encryption enabled. Cryptographic access was tied to an attestation policy: the EKM released the decryption key only after validating that the requesting VM image matched an authorized cryptographic checksum.

Case 3: Electrical Grid Telemetry Ingestion (Norway)

  • Context: A Norwegian energy grid operator required a centralized telemetry collection platform compliant with the NIS2 Directive for essential energy infrastructure.
  • Architecture: Hybrid edge architecture using Google Distributed Cloud Edge (GDC Edge) deployed on-premises, paired with a sovereign GCP perimeter in europe-north1.
  • Implementation: High-frequency smart meter readings were ingested locally by edge appliances. Aggregate metrics were transferred over a dedicated IPsec tunnel directly into a private BigQuery dataset enclosed within a VPC SC perimeter. The configuration used private DNS and Private Service Connect, preventing SCADA telemetry from traversing the public internet.

Case 4: Municipal Citizen Records System (Finland)

  • Context: A Finnish public-sector agency needed to modernize social service records while keeping all data within Finland’s jurisdiction and maintaining support controls.
  • Architecture: Project isolation deployed under an Assured Workloads folder set to EU_REGIONS_AND_SUPPORT located in europe-north1 (Hamina).
  • Implementation: The agency chose not to introduce external partner HSM hardware, relying instead on Cloud KMS with Customer-Managed Encryption Keys held in native Google Cloud HSMs in Finland. Access Approval was configured so that any emergency support access by Google engineering required digital multi-party sign-off from two agency officers.

6. Architectural Anti-Patterns

Anti-Pattern 1: “Paper Sovereignty” (Policy without Network Enforcement)

  • The Mistake: Enabling Assured Workloads at the folder level, but leaving the underlying network configured with default settings (auto-generated subnets, open outbound internet routes via Cloud NAT, and no VPC Service Controls).
  • The Failure Mode: The organization complies with regional placement on paper, but workloads remain vulnerable to data exfiltration. Any compromised compute instance or rogue service account can send data to an external public IP or an unauthorized cloud bucket.
  • The Correction: Always combine Assured Workloads with VPC Service Controls, Private Service Connect, and explicit egress firewall denial rules.

Anti-Pattern 2: Unbuffered, Single-Path EKM Integration

  • The Mistake: Implementing Cloud EKM by pointing directly to a single external on-premises HSM over a single VPN tunnel without local high-availability redundancy or cryptographic key caching.
  • The Failure Mode: When the external link experiences maintenance, packet loss, or fiber degradation, the cloud control plane cannot unwrap DEKs. Data operations halt across the entire environment: Cloud Storage reads fail, BigQuery queries abort, and VM instance restarts hang.
  • The Correction: Deploy EKM appliances across geographically separated data centers with redundant Cloud Interconnect connections. Implement application-level envelope key caching where permissible to maintain resilience during brief network interruptions.

7. Common Operational Problems and Solutions

Problem 1: Authorized Engineers Blocked by VPC Service Controls

  • Symptom: Developers receive HTTP 403 errors: VPC Service Controls: Request is prohibited by organization's policy when accessing BigQuery from corporate laptops.
  • Root Cause: The VPC Service Controls perimeter rejects calls originating from networks outside the VPC boundary, including corporate VPN IPs that have not been explicitly whitelisted.
  • Solution: Configure an Access Level in Access Context Manager.Terraformresource "google_access_context_manager_access_level" "corp_vpn_access" { parent = "accessPolicies/${google_access_context_manager_access_policy.org_access_policy.name}" name = "accessPolicies/${google_access_context_manager_access_policy.org_access_policy.name}/accessLevels/corp_vpn" title = "Corporate VPN Whitelist" basic { conditions { ip_subnetworks = ["194.100.50.0/24"] # Enterprise external egress range } } } Add this access level to the ingress_policies block of the service perimeter, allowing authorized corporate connections to reach internal APIs safely.

Problem 2: DNS Poisoning and Routing Collisions with Private Service Connect

  • Symptom: Internal workloads fail to connect to Cloud Storage (storage.googleapis.com), encountering TLS handshake failures or routing errors.
  • Root Cause: On-premises corporate DNS forwarders override the .googleapis.com zone incorrectly, returning public IP addresses rather than the internal Private Service Connect IP.
  • Solution: Deploy an authoritative Private Cloud DNS Zone within GCP for googleapis.com and use Cloud DNS Inbound Server Policies to handle hybrid DNS queries. Ensure that on-premises DNS forwarding rules direct queries for *.googleapis.com specifically to the Cloud DNS inbound listener addresses.

Problem 3: CI/CD Pipelines Blocked by Perimeter Policies

  • Symptom: Automated pipelines running on GitHub Actions or GitLab CI cannot apply Terraform configurations or deploy code to Cloud Run within the secure project.
  • Root Cause: Public CI/CD runners operate from dynamic public IP ranges that cannot be statically added to VPC SC access perimeters.
  • Solution: Deploy dedicated private CI/CD runners (such as Cloud Build Private Pools or self-hosted runners on Compute Engine) inside the secure VPC subnet. Use Workload Identity Federation to exchange pipeline tokens for short-lived GCP identities, keeping all deployment traffic within the private network.

Problem 4: Egress Billing Spikes from Misconfigured Multi-Region Setups

  • Symptom: The monthly bill shows unexpected inter-region networking charges under Data Transfer Out within GCP.
  • Root Cause: Compute workloads in europe-north1 (Finland) query BigQuery datasets or GCS buckets accidentally provisioned in multi-region EU (which defaults to metadata and storage facilities in Belgium and the Netherlands).
  • Solution: Enforce the constraints/gcp.resourceLocations organizational policy to restrict resource creation to europe-north1. Ensure that all storage buckets, BigQuery datasets, and compute clusters share the exact same geographic region.

Problem 5: Pipeline Performance Degradation Due to EKM Latency

  • Symptom: High-throughput streaming pipelines (e.g., Apache Beam on Cloud Dataflow) experience severe throughput drops when writing encrypted records.
  • Root Cause: The application performs field-level encryption by making a synchronous round-trip API call to Cloud EKM for every individual record, introducing network latency on each transaction.
  • Solution: Decouple record processing through envelope encryption caching. Use the Google Cloud KMS client library to generate a local Data Encryption Key (DEK), cache the wrapped DEK in memory for a short duration (e.g., 5 to 10 minutes), and encrypt records locally. The external EKM is then called only when rotating the DEK, preserving throughput while maintaining external key control.

8. Practical Recommendations

  1. Enforce Infrastructure as Code Exclusively: Deploy all sovereignty perimeters, folder hierarchies, and network routes using declarative tools like Terraform. Manual console changes risk missing critical parameters (such as flow logging or private Google access) that are required for regulatory audits.
  2. Phase VPC SC Rollouts with Dry-Run Mode: Never apply a VPC Service Controls perimeter directly in enforcement mode on production environments. Deploy perimeters with perimeter_type = "PERIMETER_TYPE_DRY_RUN" for at least 14 days. Query the generated audit logs in BigQuery to identify and permit valid application flows before switching to enforcement mode.
  3. Deprecate Service Account Keys: Service account private keys (.json files) bypass network perimeters if IAM policies are misconfigured. Enforce the organization policy constraints/iam.disableServiceAccountKeyCreation across all projects. Use Workload Identity Federation for external services and Compute Engine service accounts for cloud-native workloads.
  4. Perform Regular Disaster Recovery Drills for EKM: Test the behavior of cloud applications during an EKM outage at least once per quarter. Verify that applications fail closed gracefully when keys are revoked, and confirm that access is restored as expected once external connections are re-established.
  5. Audit IAM Privileges at the Organization Level: Ensure that no single identity holds the roles/accesscontextmanager.policyAdmin role alongside data access roles like roles/bigquery.admin. Enforce separation of duties between security administrators who configure network perimeters and data engineers who manage the data platform.

Similar Posts