Explore Developer Center's New Chatbot! MongoDB AI Chatbot can be accessed at the top of your navigation to answer all your MongoDB questions.

Join us at AWS re:Invent 2024! Learn how to use MongoDB for AI use cases.
MongoDB Developer
MongoDB
plus
Sign in to follow topics
MongoDB Developer Centerchevron-right
Developer Topicschevron-right
Productschevron-right
MongoDBchevron-right

How Queryable Encryption Can Keep James Bond Safe

AM
Ashni Mehta2 min read • Published Sep 29, 2022 • Updated Apr 02, 2024
MongoDBJava
Facebook Icontwitter iconlinkedin icon
Rate this article
star-empty
star-empty
star-empty
star-empty
star-empty
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, 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, 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.

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
, 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 on Atlas by registering.
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 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:
1Document employee = new Document()
2
3       .append("firstName", "James")
4
5       .append("lastName", "Bond")
6
7       .append("employeeId", 1006)
8
9       .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.
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:
1“firstName” : “James”,
2
3“lastName” : “Bond”,
4
5"employeeId": {"$binary": {"base64": "B5XwlQMzFkOmmW0VTcE1QhoQ/ZYHhyMqItvaD+J9AfsAFf1koD/TaYpJG/sCOugnDlE7b4K+mciP63k+RdxMw4OVhYUhsCkFPrhvMtk0l8bekyYWhd8Leky+mcNTy547dJF7c3WdaIumcKIwGKJ7vN0Zs78pcA+86SKOA3LCnojK4Zdewv4BCwQwsqxgEAWyDaT9oHbXiUJDae7s+EWj+ZnfZWHyYJNR/oZtaShrooj2CnlRPK0RRInV3fGFzKXtiOJfxXznYXJ//D0zO4Bobc7/ur4UpA==", "subType": "06"}},
6
7"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:
1"firstName": "James", 
2
3"lastName": "Bond", 
4
5"employeeId": 1006, 
6
7"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 or the following helpful links:
If you run into any issues using Queryable Encryption, please let us know in Community Forums or by filing tickets on the JAVA project. Happy encrypting!

Facebook Icontwitter iconlinkedin icon
Rate this article
star-empty
star-empty
star-empty
star-empty
star-empty
Related
Tutorial

Building with Patterns: The Outlier Pattern


May 16, 2022 | 3 min read
Tutorial

Preparing Time Series Data for Analysis Tools With $densify and $fill


Sep 17, 2024 | 8 min read
Article

An Update on MongoDB's Ongoing Commitment to Swift


Jul 12, 2024 | 4 min read
News & Announcements

MongoDB's New Time Series Collections


Sep 09, 2024 | 8 min read
Table of Contents