Ashni Mehta

Companies of all sizes are continuing to embrace the power of data. With that power, however, comes great responsibility — namely, the responsibility to protect that data and customers, comply with data privacy regulations, and to control and limit access to confidential and regulated data.

Though existing encryption solutions, both in-transit and [at-rest](https://en.wikipedia.org/wiki/Data_at_rest), do cover many of the use cases above, none of them protect sensitive data while it’s in use. However, in-use encryption is often a requirement for high-sensitivity workloads, particularly for customers in financial services, healthcare, and critical infrastructure organizations.

[Queryable Encryption](https://www.mongodb.com/docs/manual/core/queryable-encryption/), a new feature from MongoDB currently in **preview**, offers customers a way to encrypt sensitive data and keep it encrypted throughout its entire lifecycle, whether it’s in memory, logs, in-transit, at-rest, or in backups.

You can now encrypt sensitive data on the client side, store it as fully randomized encrypted data on the server side, and run expressive queries on that encrypted data. Data is never in cleartext in the database, but MongoDB can still process queries and execute operations on the server side.

Find more details on [Queryable Encryption](https://www.mongodb.com/products/queryable-encryption).

## Setting up Queryable Encryption with Java

There are two ways to set up Queryable Encryption. You can either go the automatic encryption route, which allows you to perform encrypted reads and writes without needing to write code specifying how the fields should be encrypted, or you could go the manual route, which means you’ll need to specify the logic for encryption.

To use Queryable Encryption with Java, you’ll need 4.7.0-beta0 (or later) of the [Java driver</u>](https://www.mongodb.com/docs/drivers/java/sync/current/), and version 1.5.0-rc2 (or later) of MongoCrypt. You’ll also need either MongoDB Atlas or MongoDB Enterprise if you want to use automatic encryption. If you don’t have Atlas or Enterprise, no worries! You can get a [free forever cluster](https://www.mongodb.com/developer/products/atlas/free-atlas-cluster/) on Atlas by [registering](https://www.mongodb.com/cloud/atlas/register).

Once you’ve completed those prerequisites, you can set up Queryable Encryption and specify which fields you’d like to encrypt. Check out [the quick start](https://www.mongodb.com/docs/manual/core/queryable-encryption/quick-start/#std-label-qe-quick-start) to learn more.

## Okay, but what does this have to do with James Bond?

Let’s explore the following use case. Assume, for a moment, that you work for a top-secret company and you’re tasked with keeping the identities of your employees shrouded in secrecy.

The below code snippet represents a new employee, James Bond, who works at your company:
```
Document employee = new Document()

       .append("firstName", "James")

       .append("lastName", "Bond")

       .append("employeeId", 1006)

       .append("address", "30 Wellington Sq");
```

The document containing James Bond’s information is added to an “employees” collection that has two encrypted fields, **employeeId** and **address**. Learn more about [encrypted fields](https://www.mongodb.com/docs/manual/core/queryable-encryption/quick-start/#create-your-data-encryption-keys-and-encrypted-collection).

Assuming someone, maybe Auric Goldfinger, wanted to find James Bond’s address but didn’t have access to an encrypted client, they’d only be able to see the following:
```
“firstName” : “James”,

“lastName” : “Bond”,

"employeeId": {"$binary": {"base64": "B5XwlQMzFkOmmW0VTcE1QhoQ/ZYHhyMqItvaD+J9AfsAFf1koD/TaYpJG/sCOugnDlE7b4K+mciP63k+RdxMw4OVhYUhsCkFPrhvMtk0l8bekyYWhd8Leky+mcNTy547dJF7c3WdaIumcKIwGKJ7vN0Zs78pcA+86SKOA3LCnojK4Zdewv4BCwQwsqxgEAWyDaT9oHbXiUJDae7s+EWj+ZnfZWHyYJNR/oZtaShrooj2CnlRPK0RRInV3fGFzKXtiOJfxXznYXJ//D0zO4Bobc7/ur4UpA==", "subType": "06"}},

"address": {"$binary": {"base64": "Biue77PFDUA9mrfVh6jmw6ACi4xP/AO3xvBcQRCp7LPjh0V1zFPU1GntlyWqTFeHfBARaEOuXHRs5iRtD6Ha5v5EjRWZ9nufHgg6JeMczNXmYo7sOaDJ", "subType": "06"}}
```
Of the four fields in my document, the last two remained encrypted (**employeeId** and **address**). Because Auric’s client was unencrypted, he wasn’t able to access James Bond’s address.

However, if Auric were using an encrypted client, he’d be able to see the following:

```
"firstName": "James", 

"lastName": "Bond", 

"employeeId": 1006, 

"address": "30 Wellington Sq"
```

…and be able to track down James Bond.

### Summary

Of course, my example with James Bond is fictional, but I hope that it illustrates one of the many ways that Queryable Encryption can be helpful. For more details, check out our [docs](https://www.mongodb.com/docs/manual/core/queryable-encryption/) or the following helpful links:

* [Supported Operations for Queryable Encryption](https://www.mongodb.com/docs/manual/core/queryable-encryption/reference/supported-operations/)
* [Driver Compatibility Table](https://www.mongodb.com/docs/manual/core/queryable-encryption/reference/compatibility/)
* [Automatic Encryption Shared Library](https://www.mongodb.com/docs/manual/core/queryable-encryption/reference/shared-library/)

If you run into any issues using Queryable Encryption, please let us know in [Community Forums](https://www.mongodb.com/community/forums/) or by filing [tickets](https://jira.mongodb.org/) on the JAVA project. Happy encrypting!

Learn more about Queryable Encryption and how it could keep one of literature's legendary heroes safe.

Ashni Mehta

Content by Ashni Mehta

How Queryable Encryption Can Keep James Bond Safe