Data Sovereignty Policies
Combine encryption policies with location restrictions to ensure data residency and compliance.
📋 Prerequisites
- Understanding of policy-as-code fundamentals (OPA, Sentinel).
- Knowledge of your organization's data residency requirements (e.g., GDPR, CCPA).
- Familiarity with cloud provider regions and availability zones (e.g., `us-east-1`, `europe-west3`).
- Experience reading resource configurations in JSON or HCL.
🎯 What You'll Learn
- The difference between data sovereignty and data residency.
- How to write policies that restrict resource creation to approved geographic regions.
- Techniques to enforce that data-at-rest is both in the correct location AND encrypted.
- Handling global or multi-regional services in your policies.
- Strategies for managing lists of approved regions for different compliance regimes.
🏷️ Topics Covered
💡 What is Data Sovereignty?
Data sovereignty is the principle that data is subject to the laws and legal jurisdiction of the country in which it is processed and stored. Implementing data sovereignty policies in the cloud means ensuring your data never physically leaves the geographic boundaries you define.
Mapping Requirements to Policies
Translating a legal requirement into a technical policy involves identifying two key pieces of information from your cloud resource data: its **location** and its **configuration** (like encryption status).
1️⃣ The Requirement
Requirement: "All sensitive EU data must be stored within EU data centers and must be encrypted at rest."
2️⃣ Identify Data Points
For an AWS S3 Bucket, this means we need the `location_constraint` (or region) and the `server_side_encryption_configuration` attributes.
3️⃣ Define Policy Logic
The policy must check two conditions: 1. Is the bucket's region in our approved list of EU regions? 2. Is server-side encryption enabled?
4️⃣ Write the Code
Implement a policy that denies the resource if either of the two conditions is false.
Implementation Examples
Let's see how to write policies that enforce both location and configuration rules using OPA/Rego and Sentinel.
Example: OPA/Rego for Azure Storage Accounts
This policy ensures that any new Azure Storage Account is created within an approved European region and has HTTPS traffic enabled.
📋 Rego Policy for Azure Storage Location & Encryption
package data_sovereignty.azure
# Define our list of approved EU locations
approved_eu_locations := {"westeurope", "northeurope", "francecentral"}
# Get the resource from the input
resource := input.resource.azurerm_storage_account.main
# --- Validation Rules ---
# Rule for checking the location
is_valid_location {
resource.location in approved_eu_locations
}
# Rule for checking encryption in transit
is_secure_transport_enabled {
resource.supports_https_traffic_only == true
}
# --- Deny Logic ---
deny[msg] {
not is_valid_location
msg := sprintf("Storage account '%s' is in a non-approved location: '%s'.", [resource.name, resource.location])
}
deny[msg] {
not is_secure_transport_enabled
msg := sprintf("Storage account '%s' must enforce HTTPS traffic only.", [resource.name])
}Example: Sentinel for GCP Compute Disks
This policy uses a Sentinel module to ensure that all Google Cloud compute disks are created in a specific region (`europe-west2` - London) and are encrypted with a customer-managed key (CMEK).
🛡️ Sentinel Policy for GCP Disk Location & CMEK
This example demonstrates combining multiple checks for a single resource.
import "tfplan/v2" as tfplan
# Rule to check all GCP compute disks
main = rule {
all tfplan.resource_changes as _, rc {
rc.type is "google_compute_disk" and
rc.change.after.zone is startswith("europe-west2") and
rc.change.after.disk_encryption_key is not null and
rc.change.after.disk_encryption_key.kms_key_self_link is not null
}
}Handling Global and Multi-Regional Services
Not all cloud services are tied to a single region. Services like AWS IAM, Route 53, or multi-region S3 buckets present a unique challenge for data sovereignty policies.
Restrict Global Service Usage
The strictest approach is to write policies that outright deny the creation of global resources or configurations that enable multi-region replication, unless explicitly approved.
Policy Exceptions
For necessary global services (like IAM), create specific policy exceptions. Your policy should check `if resource_type is "aws_iam_role"` then bypass the location check. This acknowledges that some resources don't have a location attribute.
Data-Centric Policies
For services like CDNs, focus the policy on the *origin* of the data. The policy should ensure that the CDN's origin server (e.g., the S3 bucket) is in an approved region, even if the data is cached globally.
💡 Implementation Best Practices
- Maintain Central Region Lists: Store your approved regions (e.g., for EU, US, APJ) in a central data file that your policies can import. This avoids hardcoding lists in every policy.
- Combine, Don't Separate: Whenever possible, write a single policy that checks for multiple conditions (e.g., location AND encryption) on a resource, rather than separate policies for each. This gives clearer violation messages.
- Be Explicit: Use an "allow-list" approach. Define the locations that are permitted, and deny everything else. This is safer than a "deny-list" approach where you might forget a region.
- Start with Storage and Databases: When beginning, focus your data sovereignty policies on storage services (like S3, Blob Storage, GCS) and databases (like RDS, SQL Database), as these are where persistent data resides.
- Remember Network Egress: True data sovereignty also involves controlling where data can be sent. Complement your resource location policies with network policies that restrict outbound traffic to unapproved regions.