A customer-managed key (CMK) lets an organization control the lifecycle and access permissions for encryption keys protecting Atlas data. It supports stronger privacy, regulatory compliance, key rotation, and revocation when provider access must end. section 20.5.3
With AWS KMS, Atlas uses the CMK to create an encrypted data encryption key (DEK) for each deployment. Databases have distinct encryption keys, which are protected by MongoDB’s master key. At startup, Atlas decrypts each node’s DEK through KMS so MongoDB Server can access WiredTiger data while stored data and replication remain encrypted. section 20.5.3
Apply customer-managed keys with these operational considerations:
- Enable encryption at rest through AWS KMS, GCP KMS, or Azure Key Vault to keep key control with the customer, including when storage is compromised. section 20.7
- Plan rotation and revocation deliberately: revoking access can make protected data unreadable, while lifecycle control supports internal security and compliance policies. section 20.5.3
- Retain the required CMK, vault key, or service-account and IAM credentials for restoring encrypted Atlas backup snapshots. section 21.1.1
- Use customer-managed keys for encryption at rest alongside CSFLE or Queryable Encryption when especially sensitive fields require application-side protection or secure querying. section 20.7
Encrypted Atlas deployment
An Atlas deployment using AWS KMS receives a customer-controlled CMK. Atlas uses it to protect deployment and database DEKs; each replica-set node stores its DEK on disk and obtains its decrypted DEK at startup. Restoring an encrypted snapshot requires the CMK and corresponding IAM credentials. section 20.5.3 section 21.1.1
Figure 20.2 Atlas’s encryption architecture shows the interaction between MongoDB Server, AWS KMS, and Atlas’s internal security layers. (Image © MongoDB 2024 CC BY-NC-SA 3.0)
Follow the architecture showing how MongoDB Server, Atlas security layers, and AWS KMS exchange and protect encryption keys. section 20.5.3
