Your most sensitive data, such as PII, is automatically encrypted by the MongoDB drivers before leaving the application, and so the database server only ever works with it as ciphertext. Client-Side encryption protects data while it is in-use by the database, securing it against sophisticated exploits that target server memory.
The flow of a query submitted by an authenticated client using FLE
Client-side encryption dramatically reduces the risk of unauthorized access or disclosure of sensitive data. Fields are encrypted before they leave your application, protecting them everywhere: in-motion over the network, in database memory, at-rest in storage and backups, and in system logs.
“We’ve ended up with a nuclear launch-code level of security. It works at scale, it works with the tools that developers understand, and it removes a huge layer of concern and management of security.”
Michael Oltman, CTO, Apervita
Client-Side FLE uses standard NIST FIPS-certified encryption primitives including AES at the 256-bit security level, in authenticated CBC mode: AEAD AES-256-CBC encryption algorithm with HMAC-SHA-512 MAC. Data encryption keys are protected by strong symmetric encryption with standard wrapping Key Encryption Keys, which can be natively integrated with external key management services backed by FIPS 140-2 validated Hardware Security Modules (HSMs). Client-Side FLE is available with Amazon KMS, Azure Key Vault and Google Cloud KMS. You can also use remote secure web services to consume an external key or secrets manager such as Hashicorp Vault.
All encryption and decryption happen at the client so there is minimal performance impact to the database server itself.
The performance impact to the client depends on how many fields are being encrypted and on your specific workload. Latency overhead is as low as a few percent, or it can be higher if every single field in every document is being separately encrypted while being read and written in every operation. To give an indication of performance impact, Apervita saw a 10-15% overhead for multiple fields in heavily encrypted, high volume medical records.
Client-Side FLE supports two modes of field encryption: deterministic and randomized.
By using deterministic encryption, you can perform equality queries on encrypted fields. You can query both top level document fields and fields nested in sub-documents and arrays. Regular find(), update(), and aggregation pipeline analytical queries are supported, and indexes can be used to efficiently access the encrypted fields.
Randomized encryption does not allow any read operations to match directly against the encrypted field.
Reads against fields in the document that are not encrypted client-side will evaluate as normal, as part of any query, search, or aggregation pipeline operation.
As long as you are running MongoDB 4.2 and above with supported drivers, you can use FLE everywhere:
Client-Side FLE is supported on 20+ platforms and by multiple programming language drivers.
One difference in where you choose to use Client-Side FLE is that MongoDB Atlas and MongoDB Enterprise support automatic encryption of fields in read and write operations, while the community database requires the explicit encryption of fields in application code. The core cryptography libraries themselves are identical.
Client-Side FLE is best applied selectively to those fields of your documents that you classify as containing the most sensitive data, such as PII.
Using Client-Side FLE alongside in-flight and at-rest encryption gives you an end-to-end, complementary approach in building applications that provide a defense-in-depth security posture to address different threat models.