Microsoft AzureOverview
Enable sensitive data encryption at rest using Customer Managed Keys rather than Microsoft Managed Keys.
Rationale
By default, data at rest in the storage account is encrypted using Microsoft Managed Keys. All Azure Storage resources are encrypted, including blobs, disks, files, queues, and tables. All object metadata is also encrypted. However, if you want to control and manage this encryption key, specify a customer-managed key. That key is used to protect and control access to the key that encrypts your data. You can also automatically update the key version used for Azure Storage encryption whenever a new version is available in the associated Key Vault.
Impact
If the key expires after setting the 'activation date' and 'expiration date', the user must rotate the key manually. Using Customer-Managed Keys may also incur additional man-hour requirements to create, store, manage, and protect the keys as needed.
Default Value
By default, Encryption type is set to Microsoft-managed keys
References
- https://docs.microsoft.com/en-us/azure/storage/common/storage-service-encryption
- https://docs.microsoft.com/en-us/azure/security/fundamentals/data-encryption-best-practices#protect-data-at-rest
- https://docs.microsoft.com/en-us/azure/storage/common/storage-service-encryption#azure-storage-encryption-versus-disk-encryption
- https://docs.microsoft.com/en-us/security/benchmark/azure/security-controls-v3-data-protection#dp-5-use-customer-managed-key-option-in-data-at-rest-encryption-when-required
Remediation guidance
Azure Console
- Go to
Storage Accounts. - For each storage account, go to
Encryption. - Set Customer Managed Keys.
- Select the Encryption key and enter the appropriate setting value.
- Click
Save.
Multiple Remediation Paths
Azure
SERVICE-WIDE (RECOMMENDED when many resources are affected): Assign Azure Policy initiatives at management group/subscription scope and trigger remediation tasks.
az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>
ASSET-LEVEL: Apply the resource-specific remediation steps above to the listed non-compliant resources.
PREVENTIVE: Embed Azure Policy checks into landing zones and IaC workflows to block or auto-remediate drift.
References for Service-Wide Patterns
- Azure Policy overview: https://learn.microsoft.com/en-us/azure/governance/policy/overview
- Azure Policy remediation: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources
- Azure Policy initiative structure: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/initiative-definition-structure
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- Azure: assign policy initiatives at management group/subscription scope and run remediation tasks.
az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
Query logic
These are the stored checks tied to this control.
Storage for critical data is encrypted with Customer Managed Key
Connectors
Covered asset types
Expected check: eq []
{storageAccounts(where:{byokEncrypted_NOT:true}){...AssetFragment}}
