The new encrypted storage engine in MongoDB 3.2 allows you to more easily build secure applications that handle sensitive data. Attend this webinar to learn how the internals work and discover all of the options available to you for securing your data.

2. A Technical Introduction to Native
Encryption in MongoDB
By: Osmar “Oz” Olivo
Product Manager
MongoDB Inc.

3. Agenda
• Motivation
• Encryption Internals
• Key Management
• When to use Native Encryption vs. Alternatives

4. Motivation

5. What is Encryption at Rest?
• Data at Rest generally refers to data stored in persistent storage
(disk, tape)
• Encryption at rest can be achieved in one of 4 ways
– At the hardware level
– At the filesystem level
– At the database level
– At the application level
• Encrypting data on the network is known as “In Flight Encryption”
– MongoDB provides this natively via TLS/SSL

6. Why do we need data encrypted?
• Applications may handle and store regulated or sensitive data
– Must meet federal regulations for PCI, HIPPA, FERPA, etc.
– Require that Personally Identifiable Information (PII) be protected
• Both at rest, in flight, and with access controls
• Encryption isn’t the only solution
• Internal compliance policy to protect sensitive data
– Do not necessarily store federally “sensitive” data
– May store data an entity may deem as private
• Keep your private data secure

7. MongoDB’s Native Encryption

8. Encryption Internals
• Leverages OpenSSL libraries
• Supported modes
– AES256-CBC
– AES256-GCM
– Use OpenSSL FIP’s mode to be FIPS 140-2 compliant
• Hardware Accelerated via AES-NI
• Encryption done at page level
– Don’t need to re-encrypt whole file with each change
• Encrypt data written out to the filesystem
– DataFiles, Journal, Rollback files, etc.
– Logs are not encrypted (Log redaction coming)
– Nothing is encrypted in memory

9. Internal Keystore
• MongoDB generates a key for each database
– Each database is encrypted with its own key
– Currently do not support unencrypted databases/collections
• Database keys are kept in an internal keystore
– Can’t be accessed by users
• Keystore is encrypted (“wrapped”) with an externally managed
Master Key
– OS level mechanisms are employed to ensure that keys are not paged or
written to disk in unencrypted form
– Master keys are never written to disk at all
• Must be externally managed

10. Master Key Management
• Local key file
– User generated base-64 encoded keyfile
– File is located on filesystem and must be managed by user
– NOT RECOMMENDED FOR PRODUCTION
• Won’t meet most compliance policies
• KMIP server (key management appliance)
– Users can plug into existing key management servers
• Appliance must support KMIP communication protocol
• MongoDB must have access to CA and client certificate files in order to
securely communicate
– Will securely generate and transmit Master Key
– Recommended approach to protect private data
– Level of compliance will depend on appliance used

11. • DB4
Key
• DB4
Key
• DB3
Key
• DB3
Key
• DB2
Key
• DB2
Key
• DB1
Key
• DB1
Key
How It all Fits Together
Master KeyMaster Key
Encrypted DatabasesEncrypted Databases

12. Key Rotation
• Approach will depend on requirements
– Re-encrypt all the data
• Perform rolling initial sync on each node in the replica set
• Rotates Master key as well as the internal keystore keys
– Only re-encrypt the internal keystore (KMIP ONLY)
• Restart the server with the --kmipRotateMasterKey parameter
• Only rotates the Master key
– Internal keystore keys stay the same but are re-encrypted
• Can be done in a rolling fashion to avoid downtime
• This is generally enough to meet most compliance requirements

13. Keys Per Node
• Master Keys & Internal keystore are decoupled from replication
– Each node in a cluster can utilize the same Master Key or a different one
• We recommend a different Master Key per instance
• Users have no control over database keys as they are internally generated

14. When to use Native Encryption

15. Deciding on a solution
• MongoDB Native Encryption
– Great if all sensitive data is stored on MongoDB
– Want to minimize number of technologies used in software stack
– Certified KMIP Appliances
• Safenet KeySecure
• Vormetric DSM

16. Deciding on a solution (continued)
• Filesystem Solutions
– Great if using several technologies alongside MongoDB
• Want to standardize on a single encryption platform
– If you require protection against privileged users such as root
– Certified Filesystem Solution Partners
• Safenet
• Vormetric
• Server General

17. More Data Protection Alternatives
• Encrypted Disks
• Tokenization
– Involves additional hop to tokenization software
– Sensitive data not stored in DB at all
• Application Encryption
– Cannot easily leverage database indexes
– Only applicable if not looking up by sensitive data

19. Questions?