We’re architecting encryption for 30+ Azure SQL databases across different business units and debating centralized vs local key management. Currently evaluating two approaches:
Centralized Key Vault: Single Key Vault per region, all databases reference keys from there. Simplified rotation and audit, but creates single point of failure and potential blast radius if vault is compromised.
Local Key Vault: Each business unit gets their own Key Vault, databases only access keys from their unit’s vault. Better isolation, but rotation becomes complex across multiple vaults.
Our compliance requirements mandate 90-day key rotation and complete audit trails. Has anyone implemented either pattern at scale? Particularly interested in Key Vault integration experiences and how you handle audit/rotation workflows.
From compliance perspective, centralized makes audit much cleaner. You get unified logging and can prove to auditors that key access is properly controlled. The ‘blast radius’ concern is valid but mitigated by proper RBAC. What you want to avoid is business unit A’s DBA having any visibility into business unit B’s keys. Use separate resource groups with RBAC boundaries, all pointing to same Key Vault but with scoped access policies.
We went centralized with separate Key Vaults per environment (dev/test/prod) rather than per business unit. The key is using Azure RBAC and access policies to segment access. Each database’s managed identity only gets decrypt permissions on its specific key, not the entire vault. For rotation, we use Azure Automation runbooks that iterate through keys and trigger rotation. Takes about 2 hours to rotate 50 database keys. Audit is straightforward - Key Vault diagnostic logs go to Log Analytics, we query for all decrypt operations by database identity.
For rotation, always create the new key version first in Key Vault, then update database TDE protector to reference the new version. Never delete old key versions immediately - keep them for at least 30 days in case you need to rollback or restore an old backup. We use Azure Policy to enforce this retention. Our automation workflow: 1) Create new key version 2) Wait 5 minutes for replication 3) Update databases in batches of 5 4) Verify each batch before proceeding 5) Mark old version for deletion after 30 days.
One thing to consider: Key Vault has throttling limits (2000 requests per 10 seconds for standard tier). With 30 databases, if they all hit the vault simultaneously during heavy load, you could hit throttling. We solved this by implementing retry logic with exponential backoff in our applications and spreading database connections across time windows. Also, enable soft-delete and purge protection on your Key Vaults - we had an incident where someone accidentally deleted a key and soft-delete saved us from major outage.