Mongo DB Encryption at rest

 Encryption at rest, when used in conjunction with transport encryption and good security policies that protect relevant accounts, passwords, and encryption keys, can help ensure compliance with security and privacy standards, including HIPAA, PCI-DSS, and FERPA.

Encrypted Storage Engine¶

Available in MongoDB Enterprise only, Available for the WiredTiger Storage Engine only. 

MongoDB Enterprise 3.2 introduces a native encryption option for the WiredTiger storage engine. This feature allows MongoDB to encrypt data files such that only parties with the decryption key can decode and read the data.

If encryption is enabled, the default encryption mode that MongoDB Enterprise uses is the AES256-CBC (or 256-bit Advanced Encryption Standard in Cipher Block Chaining mode) via OpenSSL. AES-256 uses a symmetric key; i.e. the same key to encrypt and decrypt text. MongoDB Enterprise for Linux also supports authenticated encryption AES256-GCM (or 256-bit Advanced Encryption Standard in Galois/Counter Mode). FIPS mode encryption is also available.

AES256-GCM and Filesystem Backups

For encrypted storage engines that use AES256-GCM encryption mode, AES256-GCM requires that every process use a unique counter block value with the key.

For encrypted storage engine configured with AES256-GCM cipher:

Restoring from Hot Backup

Starting in 4.2, if you restore from files taken via "hot" backup (i.e. the mongod is running), MongoDB can detect "dirty" keys on startup and automatically rollover the database key to avoid IV (Initialization Vector) reuse.

Restoring from Cold Backup

However, if you restore from files taken via "cold" backup (i.e. the mongod is not running), MongoDB cannot detect "dirty" keys on startup, and reuse of IV voids confidentiality and integrity guarantees.

Starting in 4.2, to avoid the reuse of the keys after restoring from a cold filesystem snapshot, MongoDB adds a new command-line option --eseDatabaseKeyRollover. When started with the --eseDatabaseKeyRollover option, the mongod instance rolls over the database keys configured with AES256-GCM cipher and exits.

In general, if using filesystem based backups for MongoDB Enterprise 4.2+, use the "hot" backup feature, if possible.

For MongoDB Enterprise versions 4.0 and earlier, if you use AES256-GCM encryption mode, do not make copies of your data files or restore from filesystem snapshots ("hot" or "cold").

The data encryption process includes:

Generating a master key.

Generating keys for each database.

Encrypting data with the database keys.

Encrypting the database keys with the master key.

The encryption occurs transparently in the storage layer; i.e. all data files are fully encrypted from a filesystem perspective, and data only exists in an unencrypted state in memory and during transmission.

Key Management¶

The database keys are internal to the server and are only paged to disk in an encrypted format. MongoDB never pages the master key to disk under any circumstances.

Only the master key is external to the server (i.e. kept separate from the data and the database keys), and requires external management. To manage the master key, MongoDB's encrypted storage engine supports two key management options:

Integration with a third party key management appliance via the Key Management Interoperability Protocol (KMIP). Recommended

Local key management via a keyfile.

Using a key manager meets regulatory key management guidelines, such as HIPAA, PCI-DSS, and FERPA, and is recommended over the local key management.

Your key manager must support the KMIP communication protocol.

To authenticate MongoDB to a KMIP server, you must have a valid certificate issued by the key management appliance.

Encrypt Using a New Key

To create a new key, connect mongod to the key manager by starting mongod with the following options:

mongod --enableEncryption --kmipServerName <KMIP Server HostName> \

  --kmipPort <KMIP server port> --kmipServerCAFile ca.pem \

  --kmipClientCertificateFile client.pem

When connecting to the KMIP server, the mongod verifies that the specified --kmipServerName matches the Subject Alternative Name SAN (or, if SAN is not present, the Common Name CN) in the certificate presented by the KMIP server. [1] If SAN is present, mongod does not match against the CN. If the hostname does not match the SAN (or CN), the mongod will fail to connect.

To verify that the key creation and usage was successful, check the log file. If successful, the process will log the following messages:

[initandlisten] Created KMIP key with id: <UID>

[initandlisten] Encryption key manager initialized using master key with id: <UID>

Local Key Management

Using the keyfile method does not meet most regulatory key management guidelines and requires users to securely manage their own keys.

The safe management of the keyfile is critical.

To encrypt using a keyfile, you must have a base64 encoded keyfile that contains a single 16 or 32 character string. The keyfile must only be accessible by the owner of the mongod process.

Create the base64 encoded keyfile with the 16 or 32 character string. You can generate the encoded keyfile using any method you prefer. For example,

openssl rand -base64 32 > mongodb-keyfile

Update the file permissions.

chmod 600 mongodb-keyfile

To use the key file, start mongod with the following options:

--enableEncryption,

--encryptionKeyFile <path to keyfile>,

mongod --enableEncryption --encryptionKeyFile  mongodb-keyfile

References:

https://docs.mongodb.com/manual/core/security-encryption-at-rest/