trust? • Traditionally, DB encryption has relied on server-side trust • This has implications, many not so obvious • With a few caveats, the database operator typically has unrestricted technical access, including: • DBAs • system admins • hosting/infrastructure providers
architects • Most notably in healthcare, finance, and consumer tech • The benefits of managed, easily expanded compute & cloud storage have often been considered out of reach because of data confidentiality & privacy concerns.
in drivers & integrated into shell • All encryption/decryption is done in the driver, on the client • Drivers have expanded MQL awareness for automatic encryption • Individual fields within collections can be marked as encrypted • Keys can be used on a per-field or even per-document basis
with new “encrypt” property • Schema validation extended client-side • Key management services natively integrated into drivers • KMS envelope encryption used to protect field data keys • Server only sees encrypted binary data (BinData subtype-6)
persisted to disk (in-memory only) • Stored field keys protected by strong symmetric encryption • Field wrapping keys secured in HSM-backed external KMS • Key service master key rotation: scheduled or on-demand • Core constructions are Post-Quantum secure • Engaged with expert cryptography teams on design & security properties, and conducted independent security assessments
cloud, GovCloud, local • Targeting all supported drivers on all supported platforms • Encrypt at the collection-, field-, or document-level • Search on encrypted fields • Subdocuments, objects and aggregation pipeline support • Multiple enforcement options (client-side, server-side, or both) • Backwards compatible with existing admin & cluster tools
Java, Node.js, C# .Net, Python, Go • Server support on Atlas 4.2 clusters now • Shell update in flight • Additional language beta previews in coming weeks • 3rd party cryptography reviews & security assessments complete