What Is MongoDB Encryption?
MongoDB is a distributed document database supporting large data volumes. For MongoDB databases that store sensitive data, administrators can encrypt data at rest while it is stored in permanent data and backups, and also encrypt it in transit while transferred over the network. When users work with data on the MongoDB server, data can be encrypted at the field level to protect sensitive fields within a dataset.
Encryption is a key part of a MongoDB security strategy. It ensures that only authenticated entities can read the encrypted data, and protects sensitive data from eavesdropping and unauthorized access.
In this article:
MongoDB Encryption Features
1. MongoDB Network Encryption
MongoDB can encrypt network traffic for clients. A client is an entity that can connect to a MongoDB server, including users, administrators, applications that interface with the MongoDB database, nodes that make up the MongoDB cluster, and MongoDB tools like mongodump.
MongoDB supports TLS, allowing clients to connect over an encrypted channel. TLS protocol is also supported with x.509 certificates and Forward Secrecy, so even if the server’s private key is compromised, the user’s session key remains secure.
You can mix encrypted and unencrypted connections on the same port. This is useful for applying fine-grained encryption controls to internal and external traffic, and helps avoid downtime when upgrading a MongoDB cluster to support TLS.
MongoDB Enterprise Advanced supports FIPS 140-2 encryption. This requires running the database in FIPS Mode with a FIPS-validated Cryptographic module, configuring mongod and mongos 9 processes with the sslFIPSMode setting, and deploying these processes together with an OpenSSL library that has the FIPS 140-2 module.
2. MongoDB Data at Rest Encryption
There are several ways to encrypt data at rest using MongoDB, including external disk and filesystem-based encryption and application-level encryption. However, these approaches require additional technology, increasing complexity and costs.
The MongoDB Encrypted Storage Engine lets you build at-rest data protection into the database. Administrators can natively encrypt database files on disk to eliminate performance and management overhead. The engine adds a layer of defense—only staff members with the appropriate database credentials can access the encrypted data.
The engine encrypts raw database content using an algorithm to generate ciphertext from random encryption key inputs, requiring a decryption key to read. The process is entirely transparent to the application.
MongoDB supports various encryption schemas, including the default AES-256 in CBC mode and AES-256 in GCM mode. It lets you configure the schema for FIPS 140-2 compliance. The engine encrypts each database with a separate key. The key-wrapping schema in MongoDB wraps each internal database key with an external master key for each server. It supports two key management options with the master key as the only key managed outside MongoDB:
- Local key management via a key file
- Integration with a third-party key management appliance via KMIP (the recommended option)
Most regulations require the (at least) annual rotation and replacement of encryption keys. MongoDB can rotate keys without downtime, performing rolling restarts of a replica set. You don’t need to re-encrypt database files when using a KMIP appliance, eliminating the performance overhead of key rotation in other databases. MongoDB only rotates the master key and re-encrypts the internal database key store.
3. MongoDB Field Level Encryption
When the database server handles data encryption and decryption, users with elevated privileges (i.e., administrators) can potentially read memory used by the host operating system. To completely protect your data from compromised administrator accounts, ensure the database engine never exposes the plaintext of the encrypted data.
MongoDB’s Client-Side Field Level Encryption (FLE) lets you selectively encrypt document fields and secure them with individual keys. FLE is separate from the database, transparent to the server, and handled exclusively in the MongoDB drivers on the client.
FLE renders all encrypted fields on the server (stored in memory, system logs, and backups) as ciphertext, unreadable to anyone without client access and the necessary decryption keys. This approach is more comprehensive than column encryption (common in relational databases), with server-side encryption allowing administrators to access the data without client access privileges.
MongoDB partnered with leading database cryptography authorities to develop FLE, including a co-author of the IETF Network Working Group Draft on Authenticated AES Encryption. These academic and industry-based authorities provided expert guidance for FLE’s design and reviewed its software implementation.
Configure Encryption in MongoDB
When using MongoDB Atlas, the data is already encrypted. MongoDB provides cloud provider-level management for Atlas encryption, but you can manage keys with another solution.
MongoDB Enterprise 3.2 offers a native WiredTiger Storage Engine encryption option. Outside Atlas, only enterprise installations using this storage engine can use encryption.
Key Management
MongoDB Enterprise lets you transfer keys securely using a KMIP-compliant key management appliance. You can expect any appliance vendor with KMIP support to be compatible with MongoDB.
mongod --enableEncryption --kmipServerName <KMIP Server HostName> \ --kmipPort <KMIP server port> --kmipServerCAFile ca.pem \ --kmipClientCertificateFile client.pem
When mongod connects to a KMIP server, it verifies that the –kmipServerName specified matches the subject alternative name (SAN) or the common name (CN) from the server’s certificate if the SAN is unavailable. If the SAN is available, mongod will not use the CN. If the specified hostname doesn’t match either the SAN or the CN, mongod will not be able to connect.
Check the log file to see if your key was successfully created and used. If the key’s creation was successful, you should see these messages:
[initandlisten] Created KMIP KEY WITH id: <UID> [initandlisten] Encryption KEY manager initialized USING master KEY WITH id: <UID>
Managing Keys Locally
You need a base64-encoded key file containing a single 16- or 32-character string to enable key file-based encryption. The file must be accessible only to the mongod process owner. Use the following steps to manage keys locally:
- Create the base64-encoded key file with the 16- or 32-character string. You can use any method you like to generate the encoded key file. Here’s one example:
openssl rand -base64 32 > mongodb-keyfile
2. Configure the file permissions:
chmod 600 mongodb-keyfile
- Launch mongod to start using the key file. You can use start one of these options:
- –enableEncryption
- –encryptionKeyFile <path to keyfile>
- mongod –enableEncryption –encryptionKeyFile mongodb-keyfile
Use any additional required options for your configuration.
- Verify whether the encryption key manager initialized successfully with the key file. A successful operation should generate a log this message:
[initandlisten] Encryption KEY manager initialized WITH KEY file: <path TO keyfile>
MongoDB Security with Satori
To learn more about how Satori helps secure your cloud data, go here. MongoDB support is coming soon, and we’d love to understand your needs.
