MongoDB Encryption Guide: Secure Your Data

Protect your MongoDB data by encrypting it. We show you how to do this with examples.

Securing Data in Transit

To protect the communication between your MongoDB instance and the clients or applications that need to access it from potential hacker attacks, you can encrypt them. Configure them to require connections that use Transport Layer Security (TLS). Like its predecessor, Secure Sockets Layer (SSL), TLS is a cryptographic protocol that encrypts data as it is transmitted over a network.

Note that TLS only encrypts data as it is transmitted over a network - also known as data in transit. Even if you have configured MongoDB to require connections to be made using TLS, the static database data on the server, also known as data at rest, remains unencrypted. It is not possible to encrypt data at rest with the free Community Edition of MongoDB, but this is possible with the paid subscription-based Enterprise Edition of Mongo.

Encryption at Rest and In Transit

Even if both encryption at rest and encryption in transit are enabled, an unauthorised user could potentially still access your sensitive data. For example, imagine that you have deployed a sharded NoSQL document database to store data for an ice cream delivery application you have 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 shards as well as clients.

Example of a Security Vulnerability

In this example, when a customer places an order, they are asked to enter some sensitive information such as their home address or credit card number. The application then writes this information into the database into a document, such as:

<

"name" : "Andreas Müller",
"address" : {
  "street" : "Heganger 29",
  "city" : "Hallstadt",
  "state" : "Bayern",
  "zip" : 96103
},
"phone" : "0123 456789-0",
"creditcard" : "1231231231231231"
 }

This is a potential security vulnerability: Anyone with permissions could access the database, see your clients' sensitive information and misuse it.

Client-Side Field Encryption

To minimise this risk, since version 4.2 the official MongoDB drivers allow client-side field encryption to be performed. This means that an application, if properly configured, can encrypt certain fields within a document before the data is sent to the database. Once the data is written to the database, only applications or clients that can present the correct encryption keys can decrypt and read the data in those fields. Otherwise, the data document would look similar to this example (assuming the street, city, postcode, phone and credit card fields were encrypted on the client side):

"name" : "Andreas Müller",
"address" : {
  "street" : BinData(6,"eirefi3eid5feiZae9t+oot0noh9oovoch3=iethoh9t"),
  "city" : BinData(6,"xiesoh+aiveez=ngee1yei+u0aijah2eeKu7jeeB=oGh"),
  "state" : "Bayern",
  "zip" : BinData(6,"CoYeve+ziemaehai=io1Iliehoh6rei2+oo5eic0aeCh")
},
"phone" : BinData(6,"quas+eG4chuolau6ahq=i8ahqui0otaek7phe+Miexoo"),
"creditcard" : BinData(6,"rau0Teez=iju4As9Eeyiu+h4coht=ukae8ahFah4aRo=")
}

MongoDB stores encoded values as binary data, as indicated by the BinData class labels in the example above. The 6 in each value represents the binary subtype in which the data is stored and indicates what type of binary data has been encoded. Values that have been encoded using Mongo's client-side field encoding always use subtype 6. Guide: Secure Your Data