Whenever there is a data breach, the key question is whether the stolen information was encrypted. However, the best encryption in the world can’t do much if the attacker has administrator-level access on the server or if the log messages contain sensitive information from database queries. If the key is stored on the server, the attacker with access to the server can decrypt the information.
MongoDB’s engineers spent the last two years figuring out how to move encryption and decryption operations to the client application to protect sensitive data. All encrypted fields are rendered as ciphertext on the server, which means the only way to see the data is to go through the client application and have the right keys. Anyone who uses administrator credentials to access the data directly from the server just see encrypted blobs. Messages written to the logs display the sensitive information as ciphertext and not in plaintext.
Among customers hesitant to move their workloads to cloud providers and database platforms were saying, “It’s not that we don’t want to trust you. We can’t trust you. We have to manage it ourselves,” said Kenn White, MongoDB's product security lead. “We don’t want you to have to trust us.”
Field-level encryption on MongoDB 4.2 is intended for organizations that have regulatory requirements—such as healthcare and finance—to protect certain types of customer records. It can be useful for organizations concerned about user-level privacy, especially in light of the European Union’s General Data Protection Regulation, said White. Organizations can comply with requests to remove data since once the key associated with a customer is destroyed, the data is useless.
Server-side protections on the database puts the data at risk to external attackers with stolen credentials and insiders who have more access than they need. Field-level encryption reduces this particular risk because administrator-level access doesn’t expose sensitive fields. If a user’s credentials are stolen, the attacker will be able to see everything the user could (through the application), but curious server and database administrators (or attackers with stolen credentials) poking around won’t be able to see any sensitive customer data. MongoDB and cloud providers can’t see the information, either. In fact, the only way to access the information is to have a system login and the correct keys—which aren’t stored on the server.
“When it’s easy to do and built-in, it changes the discussion from ‘Should I move this workload to the cloud?’ to ‘How, or when, do I move?’” said Davi Ottenheimer, MongoDB's vice president of trust and digital ethics.
Inspecting the Scheme
MongoDB’s field-level encryption relies on the database’s client library to act as the driver and perform the operations separately from the database layer. When the application sends a database query, the driver determines if there are any encrypted fields, and if there are, obtains the fields’ encryption keys from an external key manager, such as Amazon’s key management service. Once the driver has the correct keys, the driver encrypts the sensitive fields and submits the query to the MongoDB server. As far as the server is concerned, the encrypted data from the application is just another type of data to store. The database returns the encrypted results to the driver, where they are decrypted and sent to the client.
The concept is similar to end-to-end messaging, in that only the intended recipient sees the contents.
Generally, client-side encryption is painful because developers have to make a lot of changes to the application calls and modify the queries, White said. Making field-level encryption transparent to the application so that developers do not have to modify the application code was necessary, or developers wouldn’t bother using the new feature. Developers use the new “encrypt” JSON attribute to use the encryption options and just need to update the driver.
“You are still using the database like a database,” said Ottenheimer.
It’s not a perfect mechanism, as there is a bit of a performance hit as it is harder for the database to perform certain types of sorts and search queries because the encrypted fields can’t be read. Organizations can opt to use the same key for all fields, or have a different key for each field, but regardless of the method, they are responsible for tracking and managing the keys. MongoDB isn’t going to do that.
Implementating the Scheme
Thousands of publicly exposed MongoDB and other noSQL databases have led to data breaches because the servers weren’t configured correctly. Criminals wiped, or otherwise locked up, MongoDB databases and demanded ransom. While the field-level encryption doesn’t explicitly address these issues there is a benefit: attackers may gain access to the database but the not be able to do anything with the blobs themselves.
“Administrators need to still protect the servers,” and follow the best practices on what needs to be done, Ottenheimer said. “Field-level encryption is a form of ‘defense-in-depth’ and ensures no one is putting all their eggs in the same basket.”
Instead of creating their own cryptography scheme, MongoDB’s engineering team decided to build field-level encryption with well-tested, public encryption standards available through the core libraries for major operating systems.
“Even if you are a seasoned engineer, you can still make mistakes,” White said. “If you trust Microsoft to do encryption, than we’ll do the same.”
MongoDB solicited the help of people who deal with “database encryption for a living” to vet the implementation, which is open source, White said. Audits have already begun, and include experts such as Brown University cryptographer Seny Kamara.
MongoDB is the first noSQL database provider to offer field-level encryption, but Ottenheimer said (hoped) other providers will take this step and incorporate field-level encryption. MongoDB plans to keep with cryptography experts to keep refining the implementation.
“We are taking things up a notch,” said Ottenheimer.
Photo credit: Mattt Antonioli from Unsplash.com