Azure Data-at-Rest Requirements

Arbitex delegates all data-at-rest encryption to Azure infrastructure. There is no application-layer encryption of stored data — Azure Disk Encryption and Storage Service Encryption provide the encryption boundary. This page documents what Azure-level encryption is required and how to verify it.

For the full encryption posture including transit encryption and key management, see Encryption Everywhere.

Why infrastructure-layer encryption only

Arbitex does not implement application-layer data-at-rest encryption (beyond Fernet for specific configuration secrets). The rationale:

Same threat model. The threat model for data at rest is unauthorized physical or logical access to Azure storage. Azure Disk Encryption addresses this threat directly. Application-layer encryption on top of ADE protects against the same threat class with added operational complexity.
No security benefit from double encryption. If an attacker has access to the running VM memory (the only scenario where ADE does not protect), application-layer encryption keys are also in memory. Double encryption does not change the outcome.
Operational simplicity. A single encryption layer means a single key management path, a single rotation procedure, and a single recovery process.

Azure Disk Encryption (ADE)

Azure Disk Encryption is mandatory for all VMs hosting Arbitex components. ADE encrypts OS disks and data disks at the hypervisor level:

Linux VMs: dm-crypt with LUKS
Windows VMs: BitLocker

Keys are stored in Azure Key Vault and are never exposed to the VM operating system. ADE encryption is transparent to applications — Arbitex components read and write data normally; encryption and decryption happen at the storage layer.

What ADE protects

Threat	Protection
Physical disk theft or decommissioning	Data is encrypted on the physical media
Snapshot or disk export by unauthorized Azure admin	Exported VHDs are encrypted; decryption requires Key Vault access
Cross-tenant data leakage on shared hardware	Each tenant’s disks are encrypted with tenant-specific keys

Enabling ADE

ADE must be enabled on every VM in the Arbitex deployment:

# Enable ADE on an existing VM
az vm encryption enable \
  --resource-group arbitex-rg \
  --name arbitex-vm \
  --disk-encryption-keyvault arbitex-keyvault \
  --volume-type All

Verify encryption status:

az vm encryption show \
  --resource-group arbitex-rg \
  --name arbitex-vm

All disks should report EncryptionState: Encrypted.

Encrypted managed disks

All Docker volumes used by Arbitex containers must reside on encrypted managed disks. This covers all persistent data:

Data	Container / Service	Storage requirement
PostgreSQL data directory	`arbitex-db`	Encrypted managed disk
Redis data (if persistence enabled)	`arbitex-redis`	Encrypted managed disk
Audit logs (JSONL sink)	`arbitex-platform`	Encrypted managed disk
Policy cache	`arbitex-outpost`	Encrypted managed disk
Audit buffer	`arbitex-outpost`	Encrypted managed disk
CredInt bloom filter	`arbitex-platform`	Encrypted managed disk
GeoIP MMDB database	`arbitex-outpost`	Encrypted managed disk

Azure managed disks support two encryption models:

Platform-managed keys (PMK) — Azure manages the encryption key. No customer action required beyond enabling encryption. Enabled by default on all new managed disks.
Customer-managed keys (CMK) — Customer provides the encryption key via Azure Key Vault. Required for organizations with key custody requirements.

For Arbitex production deployments, CMK is recommended. See the next section.

Azure Key Vault key wrapping (CMK)

Customer-managed keys provide full control over the encryption key lifecycle. The key wrapping architecture:

Customer's Azure Key Vault
        │
        ▼
  KEK (Key Encryption Key)
  RSA 2048+ or RSA-HSM
        │
        ▼
  Wraps the DEK (Data Encryption Key)
  Azure-generated, per-disk
        │
        ▼
  DEK encrypts the disk data (AES-256)

Key Vault configuration

Create a Key Vault with soft-delete and purge protection enabled:

az keyvault create \
  --name arbitex-encryption-kv \
  --resource-group arbitex-rg \
  --location eastus2 \
  --enable-soft-delete true \
  --enable-purge-protection true

Create the key encryption key (KEK):

az keyvault key create \
  --vault-name arbitex-encryption-kv \
  --name arbitex-disk-kek \
  --kty RSA \
  --size 4096

Create a disk encryption set referencing the KEK:

az disk-encryption-set create \
  --name arbitex-des \
  --resource-group arbitex-rg \
  --key-url "$(az keyvault key show \
    --vault-name arbitex-encryption-kv \
    --name arbitex-disk-kek \
    --query key.kid -o tsv)" \
  --source-vault "/subscriptions/{sub}/resourceGroups/arbitex-rg/providers/Microsoft.KeyVault/vaults/arbitex-encryption-kv"

Grant the disk encryption set access to Key Vault:

az keyvault set-policy \
  --name arbitex-encryption-kv \
  --object-id "$(az disk-encryption-set show \
    --name arbitex-des \
    --resource-group arbitex-rg \
    --query identity.principalId -o tsv)" \
  --key-permissions get wrapKey unwrapKey

Key rotation

Azure supports automatic key rotation for disk encryption sets. Configure a rotation policy:

az keyvault key rotation-policy update \
  --vault-name arbitex-encryption-kv \
  --name arbitex-disk-kek \
  --value @rotation-policy.json

When the KEK rotates, Azure automatically re-wraps the per-disk DEKs with the new KEK. No downtime is required.

Storage account encryption (SSE)

Azure Blob Storage used for configuration backups and artifact storage uses Storage Service Encryption (SSE):

SSE encrypts all data written to Azure Blob Storage with AES-256
Enabled by default on all Azure storage accounts (cannot be disabled)
Supports both platform-managed keys and customer-managed keys

For CMK:

az storage account update \
  --name arbitexbackups \
  --resource-group arbitex-rg \
  --encryption-key-vault "$(az keyvault show \
    --name arbitex-encryption-kv \
    --query properties.vaultUri -o tsv)" \
  --encryption-key-name arbitex-storage-kek \
  --encryption-key-source Microsoft.Keyvault

Deployment checklist

Use this checklist to verify data-at-rest encryption before going live:

#	Check	How to verify	Required
1	ADE enabled on all VMs	`az vm encryption show --name <vm>` — all volumes report `Encrypted`	Yes
2	Managed disks use encryption	`az disk show --name <disk>` — `encryptionSettings.enabled: true`	Yes
3	Key Vault created with purge protection	`az keyvault show --name <kv>` — `enablePurgeProtection: true`	Yes
4	KEK created in Key Vault	`az keyvault key show --vault-name <kv> --name <key>`	Yes (CMK)
5	Disk encryption set configured	`az disk-encryption-set show --name <des>` — references correct KEK	Yes (CMK)
6	Storage account uses CMK	`az storage account show --name <sa>` — `encryption.keySource: Microsoft.Keyvault`	Recommended
7	Key rotation policy configured	`az keyvault key rotation-policy show --vault-name <kv> --name <key>`	Recommended
8	Secrets backend is Key Vault	`SECRETS_BACKEND=azure_keyvault` in platform config	Yes