Field Level Encryption is GA

MongoDB 4.2 introduced the capability to selectively encrypt and decrypt individual document fields in the application before data is sent to the database. This feature has been in beta preview since we announced it at MongoDB World in June. Starting today, Client-Side Field Level Encryption is Generally Available (GA), and ready for your production applications.

Javascript/Node.js, Python, Java, Java Reactive Streams, Scala, C# .NET, and Go drivers are available now for all supported operating systems and platforms. The mongo shell v. 4.2.2 is shipping with fully integrated field level encryption as well. Additional languages are going through final testing and will be available soon.

Working closely with customers and developers during the beta, we got great feedback from UX testing studies, and have used that to refine our documentation & full tutorials, as well as language-specific "hello world" code examples.

Over the next few weeks, we will cover many topics related to FLE:

• Detailed step-by-step CSFLE tutorials for different languages/drivers
• In-depth look into the performance impacts of different encryption mode options, under varying workloads and reference query architectures.
• Production best practices, including supplementing local JSON Schema with server-side validation
• A deep-dive whitepaper on our cryptography implementation
• Independent security audit summaries

Testing in the Field

During our private beta program over the summer and fall, our engineering team had the opportunity to work very closely with a number of innovative customer organizations. Among these was Apervita, a company that services with some of the largest physician provider and insurer networks in the world on highly sensitive medical and prescription data. That partnership was invaluable in understanding use profiles and the demands of real-world applications.

In developing Client-Side Field Level Encryption (CSFLE), we worked with three international teams with deep expertise on cryptography and database encryption. Drawn from academia and industry, these teams have provided expert guidance and feedback on our CSFLE design and implementation, including conducting formal reviews of the software security. The cryptanalysis and software security audits are now complete and will be shared shortly.

Performance

We have also created and conducted multiple performance benchmarks to understand the potential impact of using field level encryption in typical enteprise applications. As expected, there is some additional latency incurred to encrypt and decrypt fields but generally well in line with our design goals of less than 5-10% net impact on high volume read-intensive applications. Most importantly - applications which don't read or write encrypted fields see no change in performance. Applications which encrypt a small number of fields incur smaller latency hit than ones that encrypt the majority of the fields in all documents, particularly when initially generating new data keys en masse.

Beyond Encryption-at-Rest

We recently presented an overview of the field level encryption features at AWS re:Invent which you can download here. To recap, while many security controls exist to encrypt confidential data-in-transit over a network (e.g., TLS and HTTPS) as well as data-at-rest (e.g., volume or file-level encryption), fewer options exist for developers to address data-in-use, that is, data operating inside a running, active database.

By using data-at-rest encryption, attackers obtaining database files from the filesystem would be typically be unable to read them. However, administrators and privileged users (including attackers) still have access to the data on a live, running instance. Using MongoDB CSFLE you can protect individual fields and documents with all key management, encryption, and decryption operations occurring exclusively outside the database server. With CSFLE enabled, a compromised administrator or user obtaining access to the database, the underlying filesystem, or the contents of server memory (for example, via scraping or process inspection) will only see unreadable encrypted data.

This approach enables greater separation of duties:

• System administrators who traditionally have access to operating systems, database server DBA access, logs, and backups cannot read encrypted data unless explicitly given client access along with the keys necessary to decrypt the data.
• In addition several regulatory obligations may be addressed by leveraging client side encryption architectures. Complying with the “right to be forgotten” provisions in new privacy regulations such as the GDPR are now much easier. By destroying keys tied to individual application users, the underlying data are irrecoverably destroyed.

Where Can You Use Client-Side FLE?

The automatic and transparent encryption option (requiring little or no change to existing CRUD queries) is an Atlas and EA-only feature, enabled through the mongocryptd application-side service module. The core cryptography framework C library has been released under an Apache license and is available on GitHub.

This effort has been two years in the making and we are thrilled to announce that it is Generally Available for production use beginning today.