MongoDB 101: 5 Configuration Options That Impact Security (And How to Set Them)

By
MongoDB Security

MongoDB SecurityAs with any database platform, MongoDB security is of paramount importance to keeping your data safe.  MongoDB and other data platforms like Redis and Elasticsearch are often in the news for data breaches because of misconfigured settings in the database.  So how do you keep you and your company’s data from being compromised and from becoming another statistic?

We’ll show you five configuration options, as well as others that are required to go along with them, for your MongoDB deployment that will help keep your data secure while allowing use by users and applications with least-privileged access using modern authentication methods, keeping your data encrypted on disk and over the wire, and to see who is accessing your data as well. These configuration options are across the following areas in security: authentication, authorization, encryption, and auditing.

MongoDB Security Overview

MongoDB security is composed of four main areas of focus, authentication (who), authorization(what), encryption (how), and auditing (when).  This section is intended to give you a high-level overview of the different security focus areas for MongoDB.

Authentication is how you identify yourself to MongoDB.  There are many ways to authenticate oneself to a MongoDB database, from standard username and password using the SCRAM (Salted Challenge Response Authentication Mechanism) protocol, certificate-based authentication to tying into an identity management solution such as LDAP (Lightweight Directory Access Protocol), Active Directory and Kerberos.

Authorization is how MongoDB determines what you, as an authenticated user, can do.  MongoDB supports authorization using the RBAC (Role-Based Access Control) method.  MongoDB lets you create roles which are groupings of privileges that any user granted that role can do.  MongoDB comes with a comprehensive set of built-in roles as well as giving you the flexibility to create your own custom roles.  Common roles like read-only and write are there of course, but also ones useful for monitoring any node, backup and restore, and user administration. Additionally, MongoDB also supports LDAP authorization which allows you to sync LDAP groups with roles to simplify management.

Encryption is how your data can be encrypted while in flight (Transport) and while on disk (At Rest).   Transport encryption keeps your data encrypted while it is sent to and from your application to MongoDB.  MongoDB supports TLS/SSL encryption for data in-flight using x.509 Certificates, and here’s an example of setting up Transport Encryption.  Encryption at Rest keeps your data safe from an external party who might get a copy of your data files as they’ll be completely unreadable in their encrypted form.

Auditing shows you when users connected, when privileges were changed, various admin events, users attempt something they shouldn’t, etc. based on filter criteria you can set.  This is helpful in compliance situations where you have to be able to show what who was on the database at what time, what privileges they had, when privileges were changed, etc.

Tip: Don’t confuse auditing as a way to track users’ activities in real-time, but rather think of it as a way to create a tamper-proof, append-only log file that you can go back to that shows what was happening and by whom during a specific time.

Tip:  Auditing is an expensive operation and will impact performance, be sure that you’re getting value from it and your IT Compliance team is able to actively use it, before setting it up.

Configuration Options

So while knowing the important areas of MongoDB Security is great, how do we ensure they are enabled or set up correctly?  And which ones are the most important?  We’ll now go through 5 configuration options that will help you secure your MongoDB environment!  We’ll also list some required configuration options that will work in conjunction with our 5 most important configuration options to keep your data safe.  We’ll break these configuration options into their security focus areas.

MongoDB uses a configuration file in the YAML file format.   The configuration file is usually found in the following locations, depending on your Operating System:

DEFAULT CONFIGURATION FILE

  • On Linux, a default /etc/mongod.conf configuration file is included when using a package manager to install MongoDB.
  • On Windows, a default <install directory>/bin/mongod.cfg configuration file is included during the installation.
  • On macOS, a default /usr/local/etc/mongod.conf configuration file is included when installing from MongoDB’s official Homebrew tap.

Authentication:

Our first configuration option, security.authorization, is perhaps the most important for enabling security on your MongoDB Deployment.  This configuration option not only enforces MongoDB using authentication so that a user must at least login using credentials but it also simultaneously engages role-based access control which limits what a user can do.

security:
  authorization: enabled

 

Tip:  If you set this configuration option up before creating a user in MongoDB, you could use the localhost exception in order to create your first user.  This is especially helpful in cases of automation or other situations where you want to have all your configuration options configured only once and then come in and add users.

There are several other authentication configuration options that are required for your MongoDB deployment:

  • security.clusterAuthMode – The authentication mode used between replica set or sharded cluster nodes to authenticate.  This will typically be either keyFile or x509.  Acceptable values are:
    • keyFile – default, only accepts keyfiles
    • x509 – uses only x509 certificates for cluster authentication
    • sendKeyFile – only used when transitioning from keyFile to x509 certificate authentication.   Accepts keyFiles and x509 certificates
    • sendX509 – only used when transitioning from x509 certificate authentication to keyFile authentication.   Accepts x509 certificates and keyFiles
  • security.keyFile – sets the destination of the keyFile if using keyFile based authentication.  Note that the user MongoDB is running as must have read-only or read/write level permissions on the keyfile, with no permissions granted to other users.

Authorization:

The security.authorization configuration option that enabled authentication is also the most important configuration option for setting up authorization since it also gives us roles that allow us to authorize users to have specific permissions.   While there are some authorization configuration options for the inbuilt authorization system, most of the options are useful for integrating LDAP or other external authentication mechanisms with your roles.  Read more about setting up LDAP Authorization, as well as a great blog post discussing how to set it up.

Encryption:

Transport Encryption ensures that your data is encrypted between your application and the database, it also can be used to encrypt data between members of your replica set and sharded cluster.  The most important configuration option here is net.tls.mode. This configuration option is new in MongoDB 4.2, previous to MongoDB 4.2, this configuration option is named net.ssl.mode.   This configuration option decides how strictly you want to enforce TLS encryption.   The options for this configuration option are:

  • Disabled – signifies that there is no encryption whatsoever.
  • requireTLS – signifies that all traffic, regardless of origin, is encrypted.  requireTLS is the most secure setting for this configuration option.
  • allowTLS – signifies that there is no encryption going on between members of the replica set or sharded cluster, but the DB server will accept both encrypted and non-encrypted traffic from the application hosts.  Only used for transitioning between disabled to requireTLS in a rolling restart fashion.
  • preferTLS – signifies that there is encryption going on between members of the replica set or sharded cluster and that the DB server will accept both encrypted and non-encrypted traffic from the application hosts. Only used for transitioning between disabled to requireTLS in a rolling restart fashion.
net:
  tls:
    mode: requireTL

 

Additional required configuration options for transport encryption are:

  • net.tls.certificateKeyFile – location of the .pem file with the certificate and it’s key to be used for application connections.  Note that the user MongoDB is running as must have read permissions on this file.
  • net.tls.clusterFile – location of the .pem file used for transport encryption between replica set or cluster members.   Note that the user MongoDB is running as must have read permissions on this file.
  • net.tls.CAFile – location of the .pem file with the root certificate chain from the Certificate Authority.  Note that the user MongoDB is running as must have read permissions on this file.

Data at Rest Encryption ensures that your data can’t be read by someone who steals your database’s data files unless they also steal the key.  This prevents someone from reading your MongoDB data files at the file system level.  Here the most important configuration option is security.enableEncryption.

security:
  enableEncryption: true

Additional required configuration options for Data At Rest Encryption are:

  • security.encryptionCipherMode – form of encryption to use, options are AES256-CBC and AES256-GCM

Percona Server for MongoDB Specific Configuration Options:

Percona Server for MongoDB has integration with HashiCorp Vault for secret management for your Data at Rest Encryption. Read the documentation for Vault and Using Vault to Store the Master Key for Data at Rest Encryption on Percona Server for MongoDB.

Important configuration options for the Vault Integration are:

  • security.vault.serverName – server name that your vault server is on
  • Security.vault.port – port for vault connectivity
  • security.vault.tokenFile – location of file with vault token
  • Security.vault.secret – location for secrets, since these are set up per node, this should have a distinguishing characteristic such as node name in it
  • security.vault.serverCAFile – location of CAFile (Certificate Authority) on your local mongodb node
  • security.vault.rotateMasterKey – only used to rotate the master key

MongoDB Enterprise Specific Data At Rest Encryption Configuration Options:

Currently, MongoDB Enterprise does not have Vault Integration for Encryption at rest except in MongoDB Atlas.  MongoDB Enterprise does support the KMIP protocol and you can integrate MongoDB with any Key Management tool that utilizes the KMIP protocol.  Documentation can be found here.

Important configuration options to support Key Management through the KMIP protocol are:

  • security.kmip.serverName – server name where your Key Management tool resides
  • security.kmip.port – port for your key management tool
  • security.kmip.serverCAfile – path on your MongoDB hosts of a CA file (Certificate Authority) for secure connection to your Key Management Tool
  • security.kmip.clientCertificateFile – path to the client certificate used for authentication to your Key Management tool
  • security.kmip.rotateMasterKey – only used to rotate the master key

Auditing:

Auditing allows IT Security Compliance teams to track and log activities that are run against the MongoDB database.  There are several important auditing configuration options for MongoDB,  auditLog.filter is the most important as it decides what exactly you are setting up in your auditing log.

auditLog:
  filter:  { <field1>: <expression1>, ... }

 

For example, if we only wanted to have an audit log entry created every time someone created or removed a collection, we would set the auditLog.Filter as such:

auditLog:
  filter: { atype: { $in: [ "createCollection", "dropCollection" ] } }

 

If we wanted to audit everyone with a specific role, we could set the auditFilter as such:

auditLog:
  filter:{ roles: { role: "readWrite", db: "appdb" } }

 

Additional required configuration options for auditing are:

  • auditLog.destination – whether the audit log will be written to a file, to the console, or to the syslog
  • auditLog.path – if outputting to a file, the destination directory, and file name of the audit log.   Note that the user MongoDB runs as must have read and write permissions to this directory.
  • auditLog.format – the format the audit log is output to, options are JSON and BSON, with JSON being the more commonly used format.

Finally, while auditing is important to track and log activity in your database, including accessing PII or other sensitive data, you don’t want to expose PII in your auditing or other log files.  To accomplish this you must set up log redaction on your MongoDB Replica Set or Sharded Cluster.   The important configuration option for log redaction is security.redactClientLogData.   Acceptable values for this configuration option are true and false.

security:
  redactClientLogData: true

Summary

In this blog post, we’ve gone over five important MongoDB configuration options to ensure you have a more secure MongoDB deployment as well as some other configuration options that help the five keep your data secure.  We hope that these configuration options will help you build more secure MongoDB deployments and avoid being a statistic of a data breach.   Thanks for reading!

Additional Resources:

MongoDB Top Five Security Concerns

Securing MongoDB Webinar

Our latest resource, Using Open Source Software to Ensure the Security of Your MongoDB Database, documents how to deploy a secure, enterprise-grade, MongoDB deployment without worrying about license fees, giving organizations the flexibility to deploy consistent models across their entire infrastructure.

Download “Using Open Source Software to Ensure the Security of Your MongoDB Database”


by Mike Grayson via Percona Database Performance Blog

Comments

Post a Comment