Database security – how to use encryption to protect MongoDB data

Database security is a key factor for any application that includes very sensitive data, such as financial and health reports.

Data protection can be achieved through encryption at various levels, from the application itself to the files containing the data.

Since MongoDB is a non-relational database, there is no need to define columns before inserting data; and therefore documents in the same collection may have different fields from one another.

On the other hand, for SQL DBMS, it is necessary to define columns for data, so all rows have the same columns. You can decide to encrypt individual columns, the entire database file, or application data before participating in the database process.

Encryption of individual columns is preferable because it is cheaper and less data is encrypted, which increases the latency. In general, the overall performance affects the encryption result.

However, for DBMS NoSQL this approach will not be the best option. Considering that not all documents can have all fields that you want to use in your encryption, column-level encryption cannot be done.

Application-level data encryption is quite expensive and difficult to implement. That is why we are left with the option to encrypt data at the database level.

MongoDB provides built-in encryption, which requires no extra cost to protect your confidential data.

Data encryption in MongoDB

Any operation with a database includes either of these two forms of data: data at rest or data on the move.

Data on the move is the flow of data passing through any network, while data at rest is static, so it does not move anywhere.

Both of these two types of data are subject to external intervention by anonymous users unless encryption is used. The encryption process involves:

• Generation of the master key for the entire database
• Generation of unique keys for each database
• Encrypt your data with the database keys that you generated
• Encrypt the entire database with the master key

Data encryption during transmission

There are two ways to transfer data between MongoDB and the server application: via Transport Layer Security (TLS) and Secure Socket Layer Protocol (SSL).

These two encryption protocols are most often used to protect sent and received data between the two systems. Essentially, the concept is to encrypt connections to mongod and mongos instances so that network traffic is read-only by the intended client.

TLS/SSL is used in MongoDB with some certificates in the form of PEM files that are issued by a certificate authority or can be a self-signed certificate. The latter has a limitation in that despite the fact that the communication channel is encrypted, the identity verification of the server is not always verified, therefore it is vulnerable to external attacks halfway through. Thus, it is recommended to use trusted authority certificates, which allow MongoDB drivers to verify the server authenticity as well.

Besides encryption, TLS/SSL can be used for client authentication and internal authentication of the replica set members and segmented clusters through certificates.

TLS/SSL configuration for clients

There are various TLS / SSL settings that can be used when configuring these protocols.

For example, if you want to connect to a Mongod instance using encryption, you must run your instance as follows:

• Database security is a key factor for any application that includes very sensitive data, such as financial and health reports. Data protection can be achieved through encryption at various levels, from the application itself to the files containing the data.
• Since MongoDB is a non-relational database, there is no need to define columns before inserting data; and therefore documents in the same collection may have different fields from one another.

On the other hand, for SQL DBMS, it is necessary to define columns for data, so all rows have the same columns. You can decide to encrypt individual columns, the entire database file or application data before participating in the database process.

Encryption of individual columns is preferable because it is cheaper and less data is encrypted, which increases the latency. In general, the overall performance affects the encryption result.

However, for DBMS NoSQL this approach will not be the best option. Considering that not all documents can have all fields that you want to use in your encryption, column level encryption cannot be done.

Application-level data encryption is quite expensive and difficult to implement. That is why we are left with the option to encrypt data at the database level.

MongoDB provides built-in encryption, which requires no extra cost to protect your confidential data.

Data encryption in MongoDB

Any operation with a database includes either of these two forms of data: data at rest or data on the move.

Data on the move is the flow of data passing through any network, while data at rest is static, so it does not move anywhere.

Both of these two types of data are subject to external intervention by anonymous users unless encryption is used. The encryption process involves:

• Generation of the master key for the entire database
• Generation of unique keys for each database
• Encrypt your data with the database keys that you generated
• Encrypt the entire database with the master key

Data encryption during transmission

There are two ways to transfer data between MongoDB and the server application: via Transport Layer Security (TLS) and Secure Socket Layer Protocol (SSL).

These two encryption protocols are most often used to protect sent and received data between the two systems. Essentially, the concept is to encrypt connections to mongod and mongos instances so that network traffic is read only by the intended client.

TLS/SSL are used in MongoDB with some certificates in the form of PEM files that are issued by a certificate authority or can be a self-signed certificate. The latter has a limitation in that despite the fact that the communication channel is encrypted, the identity verification of the server is not always verified, therefore it is vulnerable to external attacks halfway through. Thus, it is recommended to use trusted authority certificates, which allow MongoDB drivers to verify the server authenticity as well.

Besides encryption, TLS/SSL can be used for client authentication and internal authentication of replica set members and segmented clusters through certificates.

TLS/SSL configuration for clients

There are various TLS / SSL settings that can be used when configuring these protocols.

For example, if you want to connect to a Mongod instance using encryption, you must run your instance as follows:

mongo --ssl --host example.com --sslCAFile /etc/ssl/ca.pem

-ssl enables TLS / SSL connection.
-sslCAFile specifies a Certificate Authority (CA) pem file to verify the certificate submitted by mongod or mongos. Therefore, the Mongo shell will check the certificate issued by the mongod instance by the specified CA file and host name.

You can also connect a MongoDB instance that requires a client certificate. We use a sample code below

mongo --ssl --host hostname.example.com --sslPEMKeyFile /etc/ssl/client.pem --sslCAFile /etc/ssl/ca.pem

The option -sslPEMKeyFile specifies a .pem file that contains a mongo shell certificate and a key to represent to the instance mongod or mongos. During the connection process:

The mongo shell will check if the certificate was obtained from the specified certificate authority (-sslCAFile) and if not, the shell will not be able to connect.

Secondly, the shell will also check if the host name specified in -host, SAN/CN on the certificate submitted by mongod or mongos matches. If this hostname does not match either of the two, the connection will not be established.

If you do not want to use self-signed certificates, you must make sure that the connection network is trusted.

In addition, you need to reduce the vulnerability of the private key, especially where replica sets/protected cluster are involved. This can be achieved by using different certificates on different servers.

Additional parameters that can be used in connections:

• requireSSL : this will limit each server to use only encrypted TLS/SSL connections.
• -sslAllowConnectionsWithoutCertificates : this will allow checking only if the client presents a certificate, otherwise, if the client will still connect in encrypted mode. For example:

mongod --sslMode requireSSL --sslAllowConnectionsWithoutCertificates --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

• sslDisabledProtocols : this option prevents servers from accepting incoming connections using specific protocols. This can be done with the help of sslDisabledProtocols:

mongod --sslMode requireSSL --sslDisabledProtocols TLS1_0,TLS1_1 --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

Data Encryption at rest

Starting with version 3.2, MongoDB introduced a built-in encryption option for the WiredTiger storage mechanism. Access to data in this storage by a third party can only be achieved through the decryption key to decrypt the data in a readable format.

Typically used encryption algorithm in MongoDB is AES256-GCM. It uses the same secret key to encrypt and decrypt the data. The encryption bank is enabled in FIPS mode, ensuring that the encryption meets the highest standards and compliance requirements.

Files from the entire database are encrypted using Transparent Data Encryption (TDE) at the storage level.

Whenever a file is encrypted, a unique private encryption key is generated and it’s useful to understand how these keys are managed and stored. All the generated database keys are then encrypted with the master key.

The difference between the database keys and the master key is that the database keys can be stored together with the encrypted data itself, but for the master key MongoDB recommends to store it on a server other than the encrypted data, such as a third-party corporate key.

With replicated data, encryption criteria are not transferred to other nodes, as the data are not encrypted over the network. It is possible to use the same key for nodes, but it is best to use unique individual keys for each node.

Rotation of encryption keys

The managed key used to decrypt sensitive data should be rotated or replaced at least once a year. MongoDB has two options to achieve this.

KMIP – Master of Rotations

In this case, only the master key is changed as it is controlled from the outside. The key rotation process is described below.

The main key for additional elements in the replica set is rotated one by one. I.e. the main key of a replica set rotates one by one.

mongodenableEncryption --kmipRotateMasterKey \ --kmipServerName <KMIP Server HostName> \ --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem.

After the process is complete, mongod will finish and you will need to restart the secondary device without the kmipRotateMasterKey parameter.

mongodenableEncryption --kmipServerName <KMIP Server HostName> \.
--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

The primary set of replicas is disabled : using the rs.stepDown() method, the primary one is deactivated, which leads to the selection of a new primary one.

Check the nodes state using the rs.status() method and if the primary indicates that it was downgraded, turn its main key. Restart the step-by-step element, including the kmipRotateMasterKey parameter .

• mongodenableEncryption –kmipRotateMasterKey \.
• –kmipServerName <KMIP Server HostName> \.
• –kmipServerCAFile ca.pem –kmipClientCertificateFile client.pem

Logging

MongoDB always works with a log file to record some status or specified information at different time intervals.

However, the log file is not encrypted as part of the storage mechanism. This creates a risk that an instance of mongod working with logging may output potentially important data into the log files simply as part of normal log maintenance.

Since version 3.4 of MongoDB, there is a security.redactClientLogData parameter which prevents potentially sensitive data from being written to the log of the mongod process. However, this option may complicate the diagnostics of the log.