Encryption has become an important function in the database industry, as most companies are taking extra care to keep their data safe. It is important to keep the data safe on disk as well as when it is moving in the network. This restricts any unauthorized access to the data. These two types of protection are known as encryption at REST for the data in storage, and encryption in TRANSPORT for the data moving in the network.
In upstream MongoDB software, data encryption at rest is available – but in the Enterprise version only. So those who are using the community version and want to implement encryption at rest have to use disk level encryption or file system encryption (like LUKS or DM-crypt) to achieve the same effect. This seems to solve for encrypting the data, but it comes with the added complexity of implementing and maintaining an extra set of operations. We have seen some customers face trouble after implementing the encryption at storage level due to the bugs in the encryption software.
Now the good NEWS!
Percona Server for MongoDB now provides WiredTiger encryption at rest with Percona Server for MongoDB 3.6.8-2.0 in BETA, and it is free to use. This useful feature applies encryption to only the MongoDB data, rather than full storage encryption. More importantly, it requires very minimal steps and is easy to implement when starting the DB. This is available only for the WiredTiger engine now, and can encrypt the data with the local key management via a keyfile. We expect that future releases will support third-party key management and vaults.
How to implement encryption:
Local key management Deprecation Note:
This article describes using the security.encryptionKeyFile option, which is not recommended if you can use Hashicorp Vault server for key management instead. Please see documentation or the blog post Using Vault to Store the Master Key for Data at Rest Encryption on Percona Server for MongoDB on how to use the server.vault.* options instead.”
The example below shows how to implement WiredTiger encryption at rest in Percona Server for MongoDB:
Add the encryption options below into mongod.conf:
1 2 3 4 | [root@app ~]# grep security -A2 /etc/mongod.conf security: enableEncryption: true encryptionKeyFile: /data/key/mongodb.key |
By default, Percona Server for MongoDB uses the AES256-CBC cipher mode. If you want to use the AES256-GCM cipher mode, then use the encryptionCipherMode parameter to change it. In general, CBC and GCM cipher modes work differently. CBC is faster and GCM is safer (compared to each other). I found some interesting discussion and benchmark here and here.
1 | encryptionCipherMode: AES256-GCM |
Create your key with openssl as below:
1 2 3 | [root@app ~]# mkdir /data/key [root@app ~]# openssl rand -base64 32 > /data/key/mongodb.key [root@app ~]# chmod 600 /data/key/mongodb.key |
Now start Percona Server for MongoDB:
1 2 | [root@app ~]# systemctl start mongod [root@app ~]# |
How to confirm that you have enabled encryption at rest in Percona Server for MongoDB:
To check whether you have enabled the encryption successfully in the database, you can use the command below to check:
1 2 | > db.serverCmdLineOpts().parsed.security { "enableEncryption" : true, "encryptionKeyFile" : "/data/key/mongodb.key" } |
Search for the string “percona_encryption_extension_init” in your log file:
1 2 | [root@app ~]# grep -i "percona_encryption_extension_init" /var/log/mongo/mongod.log 2018-10-30T10:32:40.895+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=256M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),cache_cursors=false,compatibility=(release="3.0",require_max="3.0"),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),encryption=(name=percona,keyid="/default"),extensions=[local=(entry=percona_encryption_extension_init,early_load=true,config=(cipher=AES256-CBC)),],cache_size=256M |
Hope this helped with how to encrypt your MongoDB data with the Percona Server MongoDB 3.6.8-2.0 package. We will let you know as we make future versions support third-party key management and vaults soon!
—
Photo by Wayne Chan on Unsplash
Great feature addition, with one caveat:
Other than being able to check of an item during an audit, what is the value of an encrypted system when you keep the key in plain-text on the hard drive? It’s a pattern I see rather often.. With local key management it’ll probably happen that the key is stored with the data and is available at rest rendering the whole encryption moot.
This is great to measure the impact of encryption, but in production I’d rather have some other way to supply the key (even just obtaining it from a command instead would be enough).
Nils, the idea is that the key file is readable by only the process that runs mongodb (chmod 600). If you are using a non-login account, then only the root user can read the file. Yes, KMIP would be better, but if your root user is compromised, they probably have all the credentials they need to just do in and dump the data anyways.
I have the same observation as Nils. Love the feature. Wish I had integration with a key provider, and I only mention that as a story for a future release.
How does this work, when i am migrating the existing encrypted data on the Percona server to AWS document DB? i am quite confused here please explain me
Preetham,
I believe both work differently. In PSMDB, the data files are encrypted by database when you enable this option on first startup. In AWS, you enable the storage encryption while you create the instance. See here – https://docs.aws.amazon.com/documentdb/latest/developerguide/encryption-at-rest.html
I have setup new mongodb server with encryption enabled by following all the steps mentioned in https://www.percona.com/blog/2020/04/21/using-vault-to-store-the-master-key-for-data-at-rest-encryption-on-percona-server-for-mongodb/. I took dump of non-encrypted data using mongodump and restored on new server with encryption enabled using mongorestore. Now I am not sure how to verify whether restored data is encrypted or not. When I compare the data size it is almost same.