Data Sovereignty and Residency

Introduction to Data Sovereignty

For a Professional Cloud Security Engineer (PSE), data sovereignty and residency go beyond simple "data location." Data Residency is about where data is stored physically. Data Sovereignty is about who has jurisdiction over that data and who can access it, including the cloud provider's staff.

In highly regulated sectors (Government, Finance, Healthcare) or regions (EU, Middle East), you must prove that neither foreign governments nor Google itself can access your data without your explicit, recorded consent.

白話文解釋（Plain English Explanation）

1. The Safe Deposit Box (Data Residency)

Data residency is like choosing a bank branch in a specific city to store your gold. You want the gold in Zurich, not New York.

2. The Two-Key System (Access Approval)

Sovereignty is like a high-security vault that requires two keys to open. One key is held by the bank (Google Support), and the other key is held by you (the Customer). Even if the bank needs to enter the vault for maintenance, they cannot do so unless you show up with your key and turn it at the same time.

3. The Security Camera in the Hallway (Access Transparency)

Access Transparency is like a 24/7 camera recording every time a bank employee even walks near your vault. Even if they don't open it, you have a log of who was there, when, and why.

Configuring Resource Location Restrictions

As covered in Org Policy, the constraints/gcp.resourceLocations constraint is the primary mechanism for residency.

Access Approval: Gatekeeping Google Support

Even with the best encryption, Google Support may occasionally need access to your data to resolve a critical ticket. Access Approval allows you to explicitly approve or deny these requests.

• Workflow:
  1. Google Support needs access.
  2. An email/notification is sent to your designated approvers.
  3. You review the "Justification" (e.g., "Fixing Case #123").
  4. You grant access for a limited time (e.g., 4 hours).
• PSE Task: Implement Access Approval at the Folder or Organization level to ensure no "Shadow Access" occurs.

Access Transparency: Visibility into Google Actions

Access Transparency provides near real-time logs of the actions Google personnel take when accessing your content.

• What is logged? The identity of the employee, their location, the reason for access, and the resource accessed.
• Integration: These logs are delivered to your Cloud Audit Logs and can be exported to SIEMs (like Chronicle or Splunk) for compliance reporting.

Sovereign Cloud Solutions on GCP

For customers with the highest sovereignty requirements (e.g., European governments), Google offers specialized solutions:

1. Google Distributed Cloud (GDC) Hosted: An air-gapped solution that does not connect to the public internet, managed by a local partner.
2. Partner-Led Sovereign Clouds: Collaborations with local entities (e.g., T-Systems in Germany, Thales in France) to provide "Local Control" over the cloud infrastructure.

Managing Data Movement Across Regions

Compliance often forbids data from crossing borders even for processing.

• VPC Service Controls (VPC-SC): Use perimeters to prevent data from being copied from a "Sovereign Project" in the EU to a "Standard Project" in the US.
• Regional Endpoints: Use regional endpoints for APIs (e.g., europe-west3-aiplatform.googleapis.com) to ensure that metadata and processing stay within the region.

Assured Workloads for Regulated Industries

Assured Workloads simplifies the creation of "Compliant Enclaves."

• Controls enforced: Resource locations, personnel access (based on citizenship/clearance), and encryption requirements.
• Compliance Regimes: Supports FedRAMP (High/Moderate), IL4/IL5, CJIS, HIPAA, and HITRUST.

Key Management for Regional Data Protection

To achieve true sovereignty, you must control the encryption keys.

• Cloud HSM: Use FIPS 140-2 Level 3 hardware to store keys.
• External Key Manager (EKM): Store keys outside of Google's infrastructure (e.g., in an on-premises HSM or a third-party provider like Thales/Fortanix).
• Key Access Justifications (KAJ): Works with EKM to allow your external HSM to deny a key request if the "Justification" provided by Google is not valid.

Auditing Data Access for Sovereignty

• Data Access Logs: Enable these for all sensitive services. They show who (including your own users) touched the data.
• Access Transparency Logs: They show when Google touched the data.
• Combined Audit: Use BigQuery to join these logs for a 360-degree view of data access.

Security Best Practices for PSE

1. Enable Access Transparency by Default: It is a low-overhead, high-value compliance win.
2. Define a "Sovereignty Boundary": Use VPC-SC to wrap all projects that handle sensitive regional data.
3. Use Blueprints: Deploy your "Sovereign Landing Zone" using Terraform blueprints provided by Google to ensure consistency.
4. Rotate Keys Regionally: If using CMEK, ensure the keys and the data they protect reside in the same region to avoid cross-border metadata leakage.

PSE Exam Scenarios

Scenario 1: Preventing Support Access

"Your company has a strict policy that no external entity, including the cloud provider, can access data without a record of approval. Which GCP services should you use?" Answer: Enable Access Transparency (for the record) and Access Approval (for the gatekeeping).

Scenario 2: Compliance for a US Government Agency

"A US government agency needs to store sensitive data (CUI) on GCP and requires that only US citizens can manage the underlying infrastructure. How do you meet this?" Answer: Use Assured Workloads with the FedRAMP High or IL4 regime. This automatically restricts Google support personnel based on citizenship.

Summary Checklist

• Differentiate between Data Residency and Data Sovereignty.
• Configure Access Approval and identify its approvers.
• Explain how Access Transparency logs are consumed.
• Describe the role of EKM and Key Access Justifications in sovereignty.
• Understand how Assured Workloads automates compliance guardrails.