This document discusses securing MongoDB clusters through authentication and authorization. It covers the basics of running MongoDB with authentication enabled and binding the process to an IP. It then discusses options for authentication like SCRAM-SHA-1, LDAP, certificates, and Kerberos. Role-based access control is implemented through built-in and custom roles. In-flight encryption can be enabled with TLS and encryption at rest uses keyfiles or a key management service. Auditing can monitor various event types and be configured with filters. Hosted MongoDB on Atlas applies security best practices out of the box.
April 2024 - NLIT Cloudera Real-Time LLM Streaming 2024
Beyond the Basics 4: How to secure your MongoDB database
1.
2. Beyond The Basics : Part 4
Securing Your MongoDB Cluster
-Authentication and Authorisation
Joe Drumgoole
Director of Developer Advocacy, EMEA
@jdrumgoole
V1.4
3. Complexity is the Enemy of Security
Security holes resulting from misconfiguration?
Under ‘time-to-market’ pressures, neglecting to apply a
security layer due to complexity?
4. Need Clearer Path To [Secure] Success
• Technologies need to keep things simple
– Especially around Security
• MongoDB’s security features are orthogonal yet
complimentary
– Using one feature doesn’t require learning and
configuring all other features
6. 6
The Basic Stuff
• Simple Security
–Run on a different port to 27017
–Use –bind_ip to lock down local instances
–Use IP tables or similar to control access to clients
–Run with auth: mongod --auth
16. Role Based Access Control
Built-in roles
• read, readWrite, dbAdmin,
clusterAdmin, root, etc..
User-defined roles
• Based on actions that can
be defined for a resource
@TheDonester
17. Defining & Using a Custom Role
Example: “Append-only” role
Define The Role & User Try Inserting & Querying Data
18. 18
LDAPAuthorization*
MongoDB Roles Mapped toLDAPGroups
* New in 3.4
Role membership is fluid &
managed dynamically in the
LDAP Directory
(rather than granting roles to
users in MongoDB)
LDAP Authorization is an optional
feature, if LDAP Direct
Authentication is enabled
19. 19
Read-Only Views* + Roles
For Record-levelAccess Control
Define a View (uses Agg Fwk) Lock Down User to Only the View
* New in 3.4
21. TLS (aka SSL)
CRUD API calls over TLS
Internal Traffic over TLS
DriverClient Machine
CA Certificates File
CA Certificates File
Server Key &
Certificate PEM File
CA Certificates File
Server Key &
Certificate PEM File
CA Certificates File
Server Key &
Certificate PEM File
22. TLS
• Can apply to client traffic or internal traffic or both
• Supported on all Drivers and MongoDB Tools
• Client Certificate authentication not mandated
– Any client and internal authentication methods can be used
– Can even have authentication / authorization completely disabled
24. Encrypted Storage Engine
• Native encryption inside the database
– Single-digit % overhead
– Based on WiredTiger
• Two Key Types for easy key rotation
– Master Key per replica
– Internal Key per database
• Options for sourcing Master Key:
– Via 3rd Party Key Management Appliance using KMIP (Key
Management Interoperability Protocol)
– Keyfile on local file-system (not recommended for Production)
Ever gone live with a Security Exception in place?
Otherwise an attacker could try to masquerade as a DB node to by-pass authentication
The Kerberos ticket contains that a random key + user's name, encrypted with the service's longterm key.
In 3.4, for x.509 Certificate authentication passing the ‘user’ field to auth() is not necessary as it is implied by the subject name in the client certificate file.
Driver support : https://docs.mongodb.com/manual/release-notes/3.0-scram/#considerations-scram-sha-1-drivers
Authorization flag applies to ALL Users – cluster-wide
Who is authorized?
Client Applications Tools
Nodes in a MongoDB cluster
A user role may have been defined in a different database, hence need to define db in createRole()
How MongoDB is mapped to roles, is defined in mongod.conf. Eg.
security:
ldap:
authz:
queryTemplate: "ou=Groups,dc=Acme,dc=com??sub?(&(objectClass=groupOfNames)(member={USER}))"
Use FQDNs and ensure used hostname matches certificate CN
PEM: Privacy Enhancement Mail container format (base64 encoded format)
"SSL cipher selection": non-documented flag "--sslCipherConfig" see: https://jira.mongodb.org/browse/SERVER-16073
net.ssl.mode: disabled | allowSSL | preferSSL | requireSSL
Without Client Auth sometimes referred to as “one-way-SSL” (poor name)
With Client Auth sometimes referred to as “two-way-SSL” (poor name)
Why 2 levels of keys:
Allow easy rotation of Master key (eg. once per year) without having to de-crypt and re-encrypt all data (could be time consuming and hurt performance) – new master key just de-crypts and re-encrypts keystore containing DB keys (which don’t need to change). No need to rotate DB keys as not accessible to administrators/users.
Some customers have security compliance item to encrypt each DB separately (eg. due to “multi-tenant” DBs)
In future could provide option to only encrypt select DBs for performance for DB’s not requiring encryption
Replication is independent of Encryption. Rotating replicas with emptied data files that initial sync is the way to enable re-encryption of DBs
AES = Advanced Encryption Standard
Tested KMIP Appliances
Vormetric DSM
Safenet Keysecure
Master key uuid is stored in WT metadata file WiredTiger.basecfg
For DB encryption, encrypts at page level.
HSMs: KMIP Appliances often use a hardware security module (HSM), which is a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server. HSMs may possess controls that provide tamper evidence such as logging and alerting and tamper resistance such as deleting keys upon tamper detection. Typically have with cryptographic acceleration. HSMs and/or the cryptographic modules they employ are typically certified to internationally recognized standards such as Common Criteria or FIPS 140 to provide users with independent assurance that the design and implementation of the product and cryptographic algorithms are sound. The highest level of FIPS 140 security certification attainable is Security Level 4 (Overall), to which very few HSMs have been successfully validated.
The auditing system writes every audit event to an in-memory buffer of audit events. MongoDB writes this buffer to disk periodically. If an audit event entry corresponds to an operation that affects the durable state of the database, such as a modification to data, MongoDB will always write the audit event to disk before writing to the journal for that entry.
Stdout is the output option called Console
MongoDB Atlas users to directly peer virtual private clouds (VPCs) in user’s AWS accounts with the MongoDB Atlas VPC created for your MongoDB clusters. Essentially enables creation of an extended, private network connecting your application servers and backend databases.