Unified Data Foundation → Governance & Security

Encryption (At Rest & In Transit)

Ensures data is unreadable to anyone without proper authorization, whether it's sitting in storage or moving between services.

High-Level Design

Encryption covers every byte, whether stored or moving.

Data Source
Data Sources
Every touchpoint and business system
→
Ingestion
TLS 1.2+
Every ingestion transport is encrypted in transit
→
Processing
Azure Event Hubs
Encrypted in transit between services
→
Foundation
Encryption (At Rest & In Transit)
Azure Storage Service Encryption + Azure Key Vault
→
Intelligence
Azure Key Vault
Manages and rotates encryption keys
→
Activation
Every Stored & Moving Byte
Nothing in the platform is unencrypted

💼 Business Context

  • A baseline, non-negotiable control for any platform handling customer data — required by virtually every compliance framework and customer contract
  • Limits the blast radius of a storage-layer or network-layer breach even if other controls fail
  • Owned by Security / Platform Engineering

🔌 Technical Overview

Data at rest in Azure Data Lake Storage Gen2 is encrypted using Azure Storage Service Encryption (SSE), with keys managed and rotated through Azure Key Vault — customer-managed keys are used for sensitive-PII-classified data. Data in transit is encrypted via TLS 1.2+ across every hop: SDK-to-API Management, API Management-to-Ingestion API, Ingestion API-to-Event Hubs, and every internal service-to-service call, with mTLS for internal traffic where the Zero-Trust network policy requires it.

Coverage

At rest: Azure Storage Service Encryption In transit: TLS 1.2+ / mTLS Key management: Azure Key Vault

💾 Encryption Configuration

{
  "storage_account": "cxosdata",
  "encryption": "customer-managed-key",
  "keyvault_ref": "cxos-prod-cmk",
  "min_tls_version": "1.2"
}

🔗 Integration Points

  • Azure Storage Service Encryption — at-rest encryption for the Data Lakehouse
  • Azure Key Vault — key management and rotation
  • TLS 1.2+ / mTLS — in-transit encryption across every service boundary
  • Azure AD managed identities — used instead of long-lived keys where possible to reduce exposure further

🧰 Services Consumed

  • Owning microservice — Cxos.Foundation.Api (see the Full Application Service Map)
  • Database — ADLS Gen2 (Iceberg) + Azure Database for PostgreSQL (policy/retention state)

⚠️ Non-Functional Considerations

  • Scale: encryption/decryption overhead is negligible relative to network and query time at this scale
  • Latency: TLS handshake overhead is amortized via connection reuse across the platform's service mesh
  • Reliability: key rotation is automated and does not require downtime or a data re-encryption pass for most rotation types
  • Security/Privacy: a baseline, table-stakes control that complements classification, access control, and consent enforcement rather than replacing them

🎯 Enterprise Example

A misconfigured network ACL briefly exposes a storage endpoint. Because data at rest is encrypted with customer-managed keys the exposed endpoint's identity doesn't have access to, the exposure doesn't translate into a readable data breach — encryption limits the damage from a control failure elsewhere.

← Back to Governance & Security