Client-Side Field Level Encryption: FAQ & Webinar

Last week we held a live webinar on MongoDB’s new Client-Side Field Level Encryption (FLE) security framework. The session was presented by Kenn White (@kennwhite), our Security Principal focused on applied encryption & distributed systems here at MongoDB. If you missed it, you can watch the replay here.

There were a lot of great questions during the session, and in this post, what I want to do is share the most frequently asked ones with you. Before getting to the FAQ, first some background on FLE.

What is Client-Side Field Level Encryption?

Starting with MongoDB 4.2, you can now selectively encrypt individual document fields, each optionally secured with its own key and decrypted seamlessly on the client.

Our implementation of FLE is totally separated from the database, making it transparent to the server, and instead handled exclusively within the MongoDB drivers on the client (hence the name Client-Side Field Level Encryption). All encrypted fields on the server – stored in-memory, in system logs, at-rest, and in backups – are rendered as ciphertext, making them unreadable to any party who does not have client access along with the keys necessary to decrypt the data.

This is a different and more comprehensive approach than the column encryption used in many relational databases. As most handle encryption server-side, data is still accessible to administrators who have access to the database instance itself, even if they have no client access privileges.

To check-out how FLE works, take a look at this handy animation.

Animation of MongoDB Client-Side Field Level Encryption in action

Where is FLE most useful for you?

Regulatory Compliance

FLE makes it easier to comply with “right to be forgotten” conditions in new privacy regulations such as the GDPR and the CCPA – simply destroy the customer key and the associated personal data is rendered useless.

Managed Database Services

Field Level Encryption is also especially powerful when using fully-managed database services in the cloud like MongoDB Atlas. In Atlas, all cluster storage and backups are encrypted at-rest by default. And of course all network connections are TLS-encrypted by default as well.

With the addition of FLE, encryption keys are protected in an isolated, customer-managed KMS account. Atlas SREs and Product Engineers have no mechanism to access FLE KMS keys, rendering data unreadable to any MongoDB personnel managing the underlying database or infrastructure for you.

By combining client-side and server-side encryption capabilities, you eliminate common security concerns when moving database workloads to managed services in the cloud. This is because you both control and manage the encryption keys, rather than having the database operator manage the keys for you.

FAQs for Client-Side Field Level Encryption

So what were the most commonly asked questions during the webinar?

What is the performance impact of FLE?

That depends on how many fields are being encrypted and on the exact workload. Latency overhead could be as low as a few percent, or it could be a lot higher if every single field is being separately encrypted while being read and written in every operation.

As all encryption and decryption activities happen at the client, there is no performance impact to the server.

What is the relationship between Client-Side FLE and regular at-rest encryption?

They are independent, but complementary to one another and address different threats. You can encrypt data at-rest as usual. Client-side FLE provides additional securing of data from bad actors on the server side or from unintentional data leaks.

What sort of queries are supported against fields encrypted with Client-Side FLE?

You can perform equality queries on encrypted fields when using deterministic encryption. With deterministic encryption, a given input value always encrypts to the same output value each time the algorithm is executed. You can query and search top level fields and fields nested in sub-documents. Regular find(), update(), and aggregation pipeline queries are supported.

Since the database server has no access to the encryption keys, certain query operations such as sorts, regexes, and range-based queries on encrypted fields are not possible server-side.

With this in mind, FLE is best applied to selectively protect just those fields containing highly sensitive, personally identifiable data such as email addresses, phone numbers, credit card information or social security numbers. Read operations against fields in the document that are not encrypted client-side will evaluate as normal – you can sort and query against them to your heart’s content. Depending on the system architecture and application requirements, it may make sense to retrieve or act on encrypted records by reference, such as retrieving an entire document by, say, customer ID, account code, or patient number.

Can I index fields that are encrypted client side? Can I use MongoDB’s Wildcard Indexes?

Yes to both questions, when you are using deterministic encryption.

How is key rotation handled?

This is more a function of the key manager you are using. In AWS KMS, automatic rotation can be specified when master keys are generated. Typically it is only the envelope-wrapping key that is rotated, rather than individual field-level data keys.

Which key management solutions are compatible with Client-Side FLE?

Two key managers are currently supported:

  1. AWS Key Management Service (KMS).
  2. A local keystore accessed using a simple key file for development, or via a remote web service call to a secrets manager or other key service. This approach allows you to use key management solutions such as Hashicorp Vault, Azure Key Vault, or Google Cloud KMS.

We have designed client-side FLE to be agnostic to specific key management solutions, and plan on adding direct native support for Azure and GCP in the future. Use the comments section below to let us know your requirements.

How do I start using Client-Side FLE with my existing unencrypted data?

We discourage in-place updates of existing data as that approach would likely leave cleartext remnants of the now-encrypted fields in the database or on the underlying operating environment, such as systems logs, temporary files and backups.

A better approach is live migration where you read data from your original database and then reinsert it into a new MongoDB cluster with FLE enabled on the relevant fields.

Where can I use Client-Side FLE?

As long as you are running MongoDB 4.2 and the latest supported drivers, you can use FLE everywhere: in MongoDB Atlas on AWS, Azure, and Google Cloud, in a local development environment, on infrastructure you run yourself with MongoDB Enterprise, or MongoDB community server.

One difference is that MongoDB Atlas and MongoDB Enterprise support automatic encryption of fields in read and white operations, while the community server requires the explicit encryption of fields. You can learn more from the documentation.

Where do I go to learn more?

When we polled the audience, interestingly nearly 70% of respondents said that FLE will make them more likely to bring even more sensitive workloads to MongoDB, while most of the remainder were going to start exploring it.

So for everyone, here are the best resources to get you started:

  1. The Client-Side Field Level Encryption documentation covers the implementation of FLE.
  2. The Client-Side Field Level Encryption Guide provides the end-to-end procedure for configuring FLE using select MongoDB 4.2-compatible drivers,

And of course if you wanted to check-out the webinar, watch the replay here.