Event
{Event}  Tune in to the .local NYC keynote on June 22 at 9:30 a.m. ET for all the latest updates

MONGODB SECURITY

MongoDB Data Encryption

MongoDB offers robust encryption features to protect data while in-transit, at-rest, and in-use — providing encryption of your data through its full lifecycle.
Get Started
MongoDB Security Hub
Encryption in-transit

MongoDB Enterprise Advanced supports encryption in-transit using Transport Layer Security (TLS).

In Atlas, all network traffic to MongoDB clusters is protected by TLS by default. TLS cannot be disabled and the default version is TLS v1.2. Data that is transmitted to MongoDB clusters, as well as data transmitted between nodes of your MongoDB clusters, is encrypted in-transit using TLS.

Learn more about Encryption In-Transit →

Encryption at-rest

Encryption at-rest is a database-level protection layer to guarantee that the written files and data are encrypted while stored. MongoDB Enterprise Advanced (EA) has implemented the at-rest encryption in WiredTiger, the database storage engine. The default at-rest encryption that WiredTiger uses is AES-256 via OpenSSL. You can configure at-rest encryption in MongoDB EA with a KMIP-enabled key provider.

In Atlas, customer data is encrypted at-rest by default using AES-256 to secure all volume (disk) data. The process is automated by the transparent disk encryption of your selected cloud provider, and the cloud provider fully manages the encryption keys. You may also choose to enable database-level encryption, which allows you to bring your own encryption keys in AWS Key Management Service (KMS), Google Cloud KMS, or Azure Key Vault. You can rotate or revoke these encryption keys at any time.

Encryption At-Rest → MongoDB Enterprise and MongoDB Atlas

In-Use Encryption

Data is encrypted client-side with customer-controlled encryption keys, before being sent, stored, or retrieved from the database. The benefits of this approach are:

  • Data encrypted throughout its lifecycle The strongest technical control to ensure that data always remains encrypted in-use, in backups, at-rest, and in-transit.

  • Faster application development cycle MongoDB takes the complexity out of developing applications for sensitive workloads. Developers don’t have to be security or cryptography experts to build encryption into their applications.

  • Enables critical data privacy use cases Allow customers to meet strict data privacy requirements for confidentiality using standards-based cryptography.

MongoDB has two features for encryption in-use to meet your data protection needs.

Client-Side Field Level Encryption

Client-Side Field Level Encryption (FLE) is an in-use encryption capability that enables a client application to encrypt sensitive data before storing it in the MongoDB database. Sensitive data is transparently encrypted, remains encrypted throughout its lifecycle, and is only decrypted on the client side.

Learn more → Client-Side Field Level Encryption

Queryable Encryption (Preview in 6.0)

Queryable Encryption, now in Preview in 6.0, is an in-use encryption capability that enables an application to encrypt sensitive data from the client-side, store the encrypted data in the MongoDB database, and run expressive queries on the encrypted data using an industry-first searchable encryption scheme. Data can be queried using equality matches (in Preview) with range, prefix, suffix, and substring query capabilities planned.

Try preview in 6.0 → Queryable Encryption

Resources
cloud_managed

Encryption at-rest in Atlas using customer key management

Configure encryption at-rest with your encryption keys using AWS KMS, Google Cloud KMS, Azure Key Vault.

FAQ

Help your organization with strong technical controls. Need more information?
Contact us
How does In-Use Encryption compare with in-transit and at-rest encryption?

In-Use Encryption is best applied selectively to those fields of your documents that you classify as containing the most sensitive data, such as PII or PHI

Using Client-Side FLE or Queryable Encryption alongside in-transit and at-rest encryption provides encryption of data throughout its lifecycle, using complementary approaches that provide a defense-in-depth security posture to address different threat models.

  • In-transit encryption protects all data traversing the network but does not encrypt data in-use or at-rest.
  • At-rest encryption protects all stored data but does not encrypt data in-use or in-transit.
  • With in-use encryption, your most sensitive data never leaves your application in plaintext. Fields that are encrypted client-side cannot be decrypted by the server and remain encrypted in-transit, at-rest, and in-use even as queries are being processed.
Do the customer provided encryption keys used for Atlas at-rest encryption need to be stored in the same cloud provider as the data is?

Your encryption keys can be stored in any cloud provider of your choosing and do not need to be in the same cloud provider as your data. For example, you can store your data in Azure but have your encryption keys in AWS KMS, or have your data in AWS but your keys in GCP Cloud KMS. This approach applies both to at-rest encryption and in-use encryption capabilities.

For more information, refer to our documentation
Can I use cloud-provider KMS for Encryption at-rest with MongoDB Enterprise?
MongoDB Enterprise supports KMIP-enabled key providers for encryption at-rest. Cloud-provided KMS (Key Management Systems) is not supported.
For more details refer to the documentation
How does Queryable Encryption differ from Client-Side Field Level Encryption?

Queryable Encryption uses Structured Encryption to add additional encrypted data structures on the server side, enabling the processing of expressive queries on encrypted data. Since the database does the query processing, there’s no need to bring extra results back to the client or write additional application code for client-side query handling.

Client-Side Field Level Encryption provides related functionality, in that it encrypts data on the client side before inserting it into the database. Querying is limited to equality queries and deterministic encryption must be used for equality.

For more information, refer to our documentation
How do I use the preview release of Queryable Encryption, and whom to contact if I have more questions?

Preview release gives you the functionality as per the feature documentation for Queryable Encryption. Since it's a preview release it is not recommended to be used in production environments as breaking changes may be introduced during the preview period. This is meant to be used for evaluation in test and development environments.

If you have any further questions, please reach out to your assigned account manager or contact sales.

What query types are supported with Queryable Encryption (Preview)?

The Queryable Encryption preview supports equality queries on encrypted data.

Future releases will support range, prefix, suffix, and substring query types.