MongoDB
MongoDB is a NoSQL database that stores its data in a JSON format, organized in collections, rather than a traditional relational database. Predominantly it is used to store unstructured or semi-structured data.
This guide showcases how you can enable data encryption in MongoDB, protected by a master key that is generated via KMIP and lives on a Securosys Primus HSM or CloudHSM.
Encryption options in MongoDB
MongoDB offers three distinct ways to encrypt data, addressing different threats. They are complementary rather than alternatives, and larger deployments often combine them.
| Option | Layer | What it protects against |
|---|---|---|
| Encryption at rest | Server, storage engine | Physical access to the disk: stolen or decommissioned drives, copied data directories, filesystem snapshots |
| Queryable Encryption (QE) | Client, per field | The database itself: fields stay encrypted in server memory and remain queryable while encrypted |
| Client-Side Field Level Encryption (CSFLE) | Client, per field | The database itself: the earlier field-level scheme, with more limited query support than QE |
Encryption at rest is transparent and covers the whole dataset on disk but offers no protection once data is loaded into memory or accessed by an authenticated client. QE and CSFLE are the inverse: they protect selected fields all the way through the database, but require application changes and cover only the fields you nominate.
This guide only covers encryption at rest. Queryable Encryption and CSFLE will be documented separately.
How it works
Encryption at rest works at the storage engine layer. MongoDB Enterprise uses the WiredTiger storage engine's native encryption to encrypt data files, indexes, and journal files on disk. The encryption is transparent to the application: no schema changes, no driver configuration, and no query changes. Data is encrypted when written to disk and decrypted when read back into memory.
Because decryption happens on read, any client with authorized database access sees plaintext. The protection applies to the data at rest on disk, not to data in use. See Limitations.
The master key lives on the HSM. At startup, each node in a cluster opens an mTLS session to the KMIP Server, retrieves (or on first run, creates) a master AES key, and uses it to unwrap the node's local keys into memory. These local keys are the database keys, of which MongoDB creates one per database, and they are what actually encrypt the data files. After startup there is no HSM round-trip per query, only at boot and at key rotation.
Each node manages its own master key, even though the data in the cluster is replicated. MongoDB recommends an individual master key per node rather than a shared one. For example, in a cluster of 5 nodes, the KMIP Server will hold 5 master keys. If the KMIP Server is unreachable or the master key is not available, the node will not be able to start. For debugging details, read the Troubleshooting section. If the nodes are already running and the connection to the KMIP Server is then lost, the nodes will continue to serve requests, as the master key is held in memory and can still unwrap the database keys.
For each node, two key types are involved.
| Key | Purpose |
|---|---|
| Master key | Generated and stored on the Securosys HSM, retrieved over KMIP. Encrypts (wraps) the node's database keys. Stored in memory alongside the data via a KMIP Get request. |
| Database keys | One per database, generated by MongoDB and stored locally in the node's keystore (key.store), wrapped by the master key. Encrypts the actual data files. |
Benefits
When your MongoDB master key is generated and stored in a Securosys Primus HSM or CloudHSM, you take advantage of the following benefits:
- Encrypt your data at rest: all data files, indexes, and journal files are encrypted on disk.
- Fully transparent to the application: no code, schema, or query changes are required.
- Protect sensitive data on disk: personal information, customer details, financial information, R&D data, and business secrets are unreadable in a stolen or decommissioned data directory.
- The master key is never stored with the data: It lives on the HSM and is retrieved over mTLS only at node startup.
- Rotate the master key without re-encrypting the entire dataset: only the database keys are re-wrapped.
- Ease of key management with KMS: the Securosys CyberVault KMS provides an intuitive UI for key lifecycle management.
Limitations
Encryption at rest defends against physical access to stored data, not against adversaries with access to a running system.
- It protects data on disk only. Data is decrypted into memory when read, so anyone able to read process memory, or any client with authorized database access, sees plaintext.
- It is transparent by design, so it does not defend against a malicious or compromised operator, application, or credential. A read on the running database returns decrypted results.
- Data is not encrypted over the wire. Combine at-rest encryption with TLS to protect data in transit.
- Logical backups are not inherently encrypted. A
mongodumpproduces plaintext output that must be secured separately. - Encryption via KMIP requires a
MongoDB Enterprise Advancedlicense. - On Windows, AES256-GCM is not supported as a block cipher; it is available on Linux only.
Further reading
- Read about the Securosys CyberVault KMS and the underlying Securosys KMIP Server
- Learn more about MongoDB's Encryption at rest