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 , 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.
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 , 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 on Atlas by .
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:
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.