MongoDB Client-Side Field Level Encryption

2019 MongoDB.local Toronto

Transcript

1. #MDBlocal Kenneth White Security Principal TORONTO New encryption capabilities in MongoDB 4.2: A deep dive into protecting sensitive workloads
2. New encryption capabilities in MongoDB 4.2: A deep dive into protecting sensitive workloads
3. New encryption capabilities in MongoDB 4.2: A deep dive into protecting sensitive workloads Agenda
4. New encryption capabilities in MongoDB 4.2: A deep dive into protecting sensitive workloads Agenda • A brief history of database security • Trust models: server vs. client • Encrypting data-in-use • Hands on deep dive • Q&A
5. A brief history of database security
6. A brief history of database security Evolution
7. A brief history of database security Evolution • access controls
8. A brief history of database security Evolution • access controls • passwords • plaintext > hashing > key derivation • bearer tokens • NTLM, Kerberos tickets, LDAP/S, SCRAM, web session • multi-factor auth • LCD fobs / SMS / 2FA apps / FIDO-U2F / WebAuthn / mobile enclaves • federated RBAC
9. A brief history of database security Evolution • network
10. A brief history of database security Evolution • network • (plaintext) native wire protocols • SSL encryption • TLS • TLS w/ PFS
11. A brief history of database security Evolution • storage
12. A brief history of database security Evolution • storage • plaintext / raw filesystem • encrypted
13. A brief history of database security Evolution • storage • volume-level / full disk encryption (FDE) • BitLocker, DMCrypt, FileVault, encrypted EBS • file-level encryption • whole database • per-database (WiredTiger ESE) • tablespace • database-level encryption • column / field
14. A brief history of database security These are all important defenses, but…
15. A brief history of database security What is the threat?
16. A brief history of database security Against whom/what are we defending?
17. A brief history of database security Against whom/what are we defending? • “hackers”?
18. A brief history of database security Against whom/what are we defending? • “hackers”? • criminal blackhats? • competitors? • activists? • unknown actors?
19. A brief history of database security Against whom/what are we defending? • “hackers”? • criminal blackhats? • competitors? • activists? • unknown actors? • insiders?
20. A brief history of database security Against whom/what are we defending? • “hackers”? • criminal blackhats? • competitors? • activists? • unknown actors? • insiders? • admins?
21. A brief history of database security Against whom/what are we defending?
22. A brief history of database security What is the threat?
23. A brief history of database security What is the threat?
24. A brief history of database security What is the threat?
25. The security model for many Prod databases
26. The security model for many Prod databases Source: Imgur (author unknown)
27. A brief history of database security
28. A brief history of database security Let’s talk about breaches.
29. A brief history of database security Every sector of the global economy has been impacted.
30. A brief history of database security Every sector of the global economy has been impacted • enterprise • consumer tech • retail • government • healthcare • finance …
31. A brief history of database security Major shifts in regulatory & privacy climate
32. A brief history of database security Major shifts in regulatory & privacy climate • GDPR • HIPAA • PCI DSS • NIST/FISMA • Consumer protection • State & provincial
33. A brief history of database security System architect & developer security challenges
34. A brief history of database security System architect & developer security challenges Meeting legal/regulatory obligations • Controls • Audit/attestation
35. A brief history of database security System architect & developer security challenges Meeting legal/regulatory obligations • Controls • Audit/attestation Defending real-world attacks • First Principles: C/I/A • Separation of duties • Access control • Identifying & protecting sensitive data
36. A brief history of database security System architects & develop security challenges Meeting legal/regulatory obligations • Controls • Audit/attestation Defending real-world attacks • First Principles: C/I/A • Separation of duties • Access control • Identifying & protecting sensitive data
37. Trust models: server vs. client
38. Trust models: server vs. client What is the source of trust?
39. Trust models: server vs. client What is the source of trust? • Traditionally, DB encryption has relied on server-side trust
40. Trust models: server vs. client What is the source of trust? • Traditionally, DB encryption has relied on server-side trust • This has implications, many not so obvious
41. Trust models: server vs. client What is the source of 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
42. Trust models: server vs. client What is the source of trust? • In a server-side encryption model, a leak or breach can be catastrophic
43. Trust models: server vs. client What is the source of trust? • In a server-side encryption model, a leak or breach can be catastrophic • This potentially includes: logs, backups, temp files, process memory…
44. Trust models: server vs. client What is the source of trust? • In a server-side encryption model, a leak or breach can be catastrophic • This potentially includes: logs, backups, temp files, process memory… • They who hold the keys controls the kingdom
45. Trust models: server vs. client This is particularly important in a cloud context, especially so when running highly sensitive workloads.
46. Trust models: server vs. client A common pain for system architects
47. Trust models: server vs. client A common pain for system 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.
48. Trust models: server vs. client The fundamental challenge is protecting the confidentiality of data while it’s in use.
49. Encrypting Data-in-Use
50. Encrypting Data-in-Use Introducing MongoDB Client-Side Field Level Encryption
51. Encrypting Data-in-Use Introducing MongoDB Client-Side Field Level Encryption • encryption as a first-class citizen • modern, authenticated encryption algorithms • strong security guarantees • customer-managed keys • sensitive content is opaque to server & server operator
52. Encrypting Data-in-Use Introducing MongoDB Client-Side Field-Level Encryption • major investment • 2 years in the making • 18+ engineers spanning core server, query, security, cloud, drivers • targeting 12+ languages • all major hardware & operating system platforms • Linux, MacOS, Windows
53. MongoDB Client-Side Field-Level Encryption
54. MongoDB Client-Side Field-Level Encryption Core design
55. MongoDB Client-Side Field-Level Encryption Core design • CSFLE is enabled 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
56. MongoDB Client-Side Field-Level Encryption Implementation
57. MongoDB Client-Side Field-Level Encryption Implementation • Extends existing JSON Schema 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)
58. MongoDB Client-Side Field-Level Encryption Cryptography
59. MongoDB Client-Side Field-Level Encryption Cryptography • Multiple encryption options, including deterministic search • Cloud key services are natively integrated • Modern authenticated encryption: AEAD AES-256 & HMAC-SHA512 • 2015 IETF draft: McGrew, Foley, Paterson • Abuse- & misuse-resistant derived HMACs w/ deterministic IVs • Native OS libraries used for crypto primitives
60. MongoDB Client-Side Field-Level Encryption Cryptography • Raw key material never 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
61. MongoDB Client-Side Field-Level Encryption How does it work?
64. View from application
65. View from application { firstName: "Pat", lastName: "Lee", ssn: "901-01-0001", email: "lee@example.com", mobile: "+1-212-555-1234", medRecNum: 235498 }
66. View from application View from database (admin, server, DB logs, process memory) { firstName: "Pat", lastName: "Lee", ssn: "901-01-0001", email: "lee@example.com", mobile: "+1-212-555-1234", medRecNum: 235498 }
67. { firstName: "Pat", lastName: "Lee", ssn: "901-01-0001", email: "lee@example.com", mobile: "+1-212-555-1234", medRecNum: 235498 } { firstName: "Pat", lastName: "Lee", ssn: "r6EaUcgZ4lGw…", email: "K4b5U3TlcIXh…", mobile: "oR72CW4Wf5Ej…", medRecNum: 235498 } View from application View from database (admin, server, DB logs, process memory)
68. Client-Side Field Level Encryption Step by Step
69. Client-Side Field Level Encryption Step by Step  Step 1: Identify fields to encrypt
70. Identify fields to encrypt { "medRecNum" : 235498, "firstName" : "Pat", "lastName" : "Lee", "ssn" : "901-01-0001", "mobile" : "212-555-1234", "email" : "lee@example.com" }
71. Client-Side Field Level Encryption Step by Step  Step 1: Identify fields to encrypt  Step 2: Set JSON data types & key(s) for encrypted fields
72. "test.patients" : { "bsonType" : "object", "properties" : { "ssn" : { "encrypt" : { "bsonType" : "string", "keyId" : [ myKey ], "algorithm" : encryption_mode, } } } }
73. Client-Side Field Level Encryption Step by Step  Step 1: Identify fields to encrypt  Step 2: Set JSON data types & key(s) for encrypted fields  Step 3: Create a new Mongo session with encryption options
74. var keystore = db.getCollection("__keystore") var clientSideFLEOptions = { "kmsProviders" : { "aws" : { "accessKeyId" : env.KMSKID , "secretAccessKey" : env.KMSKEY } }, "schemas" : { patientSchema } , "keyVaultCollection" : keystore } encryptedSession = new Mongo( "localhost", clientSideFLEOptions )
75. Client-Side Field Level Encryption Step by Step  Step 1: Identify fields to encrypt  Step 2: Set JSON data types & key(s) for encrypted fields  Step 3: Create a new Mongo session with encryption options  Step 4: Run your queries.
76. db.patients.insert({ "medRecNum" : 235498, "firstName" : "Pat", "lastName" : "Lee", "ssn" : "901-01-0001", "mobile" : "212-555-1234", "email" : "lee@example.com" }); ... db.patients.find({ "ssn": "901-01-1234" });
77. Client-Side Field Level Encryption Step by Step  Step 1: Identify fields to encrypt  Step 2: Set JSON data types & key(s) for encrypted fields  Step 3: Create a new mongo session with encryption options  Step 4: Run your queries. (That’s it)
78. Let’s go deeper
79. Example: Direct query on an encrypted field encryptedDb.patients.find({"ssn": "901-01-0001" })
80. Example: Direct query on an encrypted field encryptedDb.patients.find({"ssn": "901-01-0001" })
81. Example: Direct query on an encrypted field encryptedDb.patients.find({"ssn": "901-01-0001" }) encryptedDb.patients.find({ "ssn": BinData(6,"ASV2YBzOhUY…" )})
82. Auto-decryption for clients holding a valid key: { "medRecNum" : 235498, "firstName" : "Pat", "lastName" : "Lee", "ssn" : "901-01-0001", "mobile" : "212-555-1234", "email" : "lee@example.com" }
83. View to a DBA: { "medRecNum" : 235498, "firstName" : "Pat", "lastName" : "Lee", "ssn" : BinData(6,"ASV2YBzOhUZZu643i7Y..."), "mobile" : "212-555-1234", "email" : "lee@example.com" }
84. View to a client lacking a valid key: { "medRecNum" : 235498, "firstName" : "Pat", "lastName" : "Lee", "ssn" : BinData(6,"ASV2YBzOhUZZu643i7Y..."), "mobile" : "212-555-1234", "email" : "lee@example.com" }
85. View to database, server memory, logs, backups: { "medRecNum" : 235498, "firstName" : "Pat", "lastName" : "Lee", "ssn" : BinData(6,"ASV2YBzOhUZZu643i7Y..."), "mobile" : "212-555-1234", "email" : "lee@example.com" }
86. { "firstName" : "Pat", "lastName" : "Lee", "medRecNum" : 235498, "ssn" : BinData(6,"ASV2YBzOhUZZu643i7Y..."), "mobile" : "212-555-1234", "email" : "lee@example.com" } View to legacy clients: { "medRecNum" : 235498, "firstName" : "Pat", "lastName" : "Lee", "ssn" : BinData(6,"ASV2YBzOhUZZu643i7Y..."), "mobile" : "212-555-1234", "email" : "lee@example.com" }
87. Subdocuments & embedded fields supported
88. Subdocuments & embedded fields supported { "_id": 923452345, "name": "John Doe", "ssn": "555-55-5555, "addresses": { "home": { "street": "123 secret way", "state": "NV", "zip": "89429" } } }
89. Subdocuments & embedded fields supported { "_id": 923452345, "name": "John Doe", "ssn": "9+4/J%|]yr4t^(M", "addresses": "cEfgjCW,WqK+vB4V&fX1{G4XI*oi?OmQA7kT9>,}1vo SG!5\cJkl0?6ckTmL*9TmZ^[x`2gRkCYpP)~Ol5dpBz" }
90. Subdocuments & embedded fields supported { "_id": 923452345, "name": "John Doe", "ssn": "9+4/J%|]yr4t^(M", "addresses": { "home": { "street": "8u^,%k78`[l9*AqMM", "state": "NV", "zip": "89429" } } }
91. Sorts, range, and reference queries schema design { "firstName": ")2~Y8cJQuM", "lastName": "u?n<EzK9,G#agvq@", "DOB": 1978, "location": { "city": "u^fj,%k78*)qV", "state": "NV", }, "ssn": "9+4/J%|]yr4t^(M", "payerID": 62501, "medicalCode": "89K", "accountBalance": 4000.34 }
92. MongoDB Client-Side Field-Level Encryption Recap
93. MongoDB Client-Side Field-Level Encryption Recap • Run anywhere: Atlas, self-managed 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
94. MongoDB Client-Side Field-Level Encryption Roadmap
95. MongoDB Client-Side Field-Level Encryption Roadmap • Beta preview now – 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
96. THANK YOU
97. #MDBlocal Kenneth White Security Principal TORONTO New encryption capabilities in MongoDB 4.2: A deep dive into protecting sensitive workloads