How Queryable Encryption Can Keep James Bond Safe
Rate this article
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.
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.
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:
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:
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:
…and be able to track down James Bond.
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!
Rate this article