Encryption is the process of converting a piece of information from plaintext, the information’s original form, into ciphertext, an unreadable form that can only be read by a person or computer that has the right cipher to decrypt it. If a malicious actor were to intercept a piece of encrypted data, they wouldn’t be able to read it until they’re able to decrypt it.
You can encrypt communications between your MongoDB instance and whatever clients or applications need access to it by configuring it to require connections that use Transport Layer Security, also known as TLS. Like it’s predecessor, Secure Sockets Layer (SSL), TLS is a cryptographic protocol that uses certificate-based authentication to encrypt data as it’s transmitted over a network.
Note that TLS only encrypts data as it moves over a network, otherwise known as data in-transit. Even if you’ve configured Mongo to require connections to be made with TLS, the static data stored on the database server, called data at rest, will still be unencrypted. It isn’t possible to encrypt data at rest with the free Community Edition of MongoDB, but it is possible with Mongo’s paid subscription-based Enterprise Edition.
Even with both encryption-at-rest and encryption-in-transit enabled, though, your sensitive data could potentially still be accessed by an unapproved user. Consider, for example, a scenario where you’ve deployed a sharded NoSQL document database to store data for an ice cream delivery application you’ve developed. The database management system allows you to encrypt data at rest, which you enable, and you also configure it to require encrypted TLS connections between the shards as well as any clients.
In this example situation, when a customer places an order they’re asked to submit a few pieces of sensitive information, like their home address or their credit card number. The application then writes this information to the database in a document, like this:
{
"name" : "Sammy Shark",
"address" : {
"street" : "602 Surf Ave",
"city" : "Brooklyn",
"state" : "New York",
"zip" : 11224
},
"phone" : "555-555-1234",
"creditcard" : "1234567890123456"
}
This is a potential security vulnerability, since anyone who has privileges to access the database could see and take advantage of your customers’ sensitive information.
To help mitigate this type of risk, since version 4.2 the official MongoDB drivers allow you to perform client-side field level encryption. This means that, when properly configured, an application can encrypt certain fields within a document before the data is sent to the database. Once the data has been written to the database, only applications or clients that can present the correct encryption keys will be able to decrypt and read the data in these fields. Otherwise, the data document would look similar to this, assuming the street, city, zip, phone, and creditcard fields have been encrypted on the client’s side:
{
"name" : "Sammy Shark",
"address" : {
"street" : BinData(6,"eirefi3eid5feiZae9t+oot0noh9oovoch3=iethoh9t"),
"city" : BinData(6,"xiesoh+aiveez=ngee1yei+u0aijah2eeKu7jeeB=oGh"),
"state" : "New York"
"zip" : BinData(6,"CoYeve+ziemaehai=io1Iliehoh6rei2+oo5eic0aeCh")
},
"phone" : BinData6,"quas+eG4chuolau6ahq=i8ahqui0otaek7phe+Miexoo"),
"creditcard" : BinData6,"rau0Teez=iju4As9Eeyiu+h4coht=ukae8ahFah4aRo="),
}
MongoDB stores encrypted values as binary data, as indicated by the BinData class labels in the previous example. The 6 in each value represents the binary subtype in which the data is stored, and indicates the kind of binary data that’s been encoded. Values that have been encrypted with Mongo’s client-side field level encryption always use subtype 6.
Related Resources
Originally posted on DigitalOcean Community Tutorials
Author: Mark Drake