Data is always vulnerable to attack by hackers and other devices crawling for sensitive user information. If the data is not protected efficiently, it may lead to data leaks and security breach, which can cost a lot to the user as well as the company. As the online presence across the globe increases, so there is the need for tight security mechanisms to protect sensitive data.
MongoDB provides in-built mechanisms to ensure your data is safe at all times. MongoDB employs various techniques at different levels in the lifecycle of data to protect it from unauthorized access or attack.
While clients and applications provide some level of security, Security best practices enforce multiple layers of security, known as defense in depth. This means, each layer of the application architecture should handle security independently to provide a robust, reliant and resilient system.
MongoDB provides different mechanisms for securing your database data. These are:
If a user wants to use the service provided by a service provider, let us say, google mail, they need to have a valid account, i.e. user id and a password. They can access their email once they enter the right user id and password. This is called authentication. Authentication requires a password at the minimum. MongoDB supports the following authentication mechanisms of which the basic SCRAM and X.509 authentication is available for both the community and enterprise editions, and the others are available for only enterprise editions.
SCRAM stands for Salted Challenge Response Authentication Mechanism, and is the default authentication mechanism in MongoDB. The mechanism checks for the response from the user for the challenge it asked. For example, a user wants to check his email - SCRAM asks - what’s your username and password - and the user sends the response with the details. SCRAM verifies the same and authenticates the user.
X.509 is a digital certification authentication that uses X.509 public key infrastructure (PKI) standard to verify the identity of entities such as users, devices, or servers over a network. MongoDB uses it for client applications and intra cluster authentication to enforce a robust identity verification. Recently MongoDB 7.0 introduced flexible X.509 configuration to differentiate between node-to-node (intra node) authentication and client-database node authentication.
MongoDB also uses the replication key file (a secret handshake) to authenticate communication between the nodes within a replica set or sharded cluster. This mechanism ensures that only authorized MongoDB instances can join the cluster.
MongoDB Enterprise provides support for Kerberos authentication of MongoDB clients. Kerberos is an industry standard authentication protocol for large client/server systems. Kerberos allows MongoDB and applications to take advantage of existing authentication infrastructure and processes.
AWS IAM (AWS Identity and Access Management) is a web service provided by Amazon Web Services (AWS) to securely control access to AWS services and resources. Using IAM, MongoDB can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources. AWS IAM can be used to authenticate human and programmatic users; however, it is limited to use only with AWS - and not any other cloud.
Lightweight Directory Access Protocol (LDAP) is widely used for directory services authentication and to store information about users, groups, and other entities in an organization.
Users can use their LDAP credentials (e.g., corporate username and password) to authenticate with MongoDB.
MongoDB in turn searches the LDAP directory to retrieve user attributes and validate the user's identity.
The above methods posed challenges, for example, LDAP is a pre-cloud security mechanism, so there are setup complexities associated with cloud-based security, similarly SCRAM and X.509 require some password policies and user life-cycle management. To address the issues posed by the above authentication methods, with 7.0, MongoDB introduced a new authentication mechanism - Identity Federation.
The prime feature of identity federation is the single sign on, where a user can login once and then access multiple systems that he is authorized to use. It provides centralized authentication, thus enhancing user experience. MongoDB uses the OpenID Connect protocol, which is built on top of the OAuth protocol.
Once a user is authenticated, they need not be able to see all the data present in a database or cloud. For example, if you have written a blog post and want it to be reviewed, you could give suggestion/comment permissions to a reviewer and not direct edit permissions.
To restrict access to a user to be able to see or modify only the relevant data, MongoDB provides several authorization methods for role-based access control.
Each user can have one or more roles, each role can have one or more privileges. Each privilege refers to a group of actions and the resources the action is applied to. For example, read privilege, write privilege.
By default, MongoDB provides certain pre-defined roles with access permissions, for example, an admin role can have read-write-delete permissions, a developer role may have read-write permissions, and a tester role can have read permissions.
To achieve a finer control over role-based access, MongoDB allows administrators to create custom roles, as per specific project or database requirements. For example, grant temporary write access to the performance testing team only for 2 days.
This is a more granular control where certain users may not be able to access specific fields based on their roles. For example, while accessing a patient’s healthcare records, the medical team does not need to see their billing information, hence using field level control, those fields can be hidden from that particular user role (medical team). Note that field level access control is available in MongoDB Enterprise.
MongoDB has also introduced a variable named $user_role, using which only the information relevant to that particular role can be accessed by a user. For example, within a single view itself, one user can access only billing information and another user can access only the patient history and other medical information. Before this variable, MongoDB would have to create separate views for each type of user role.
MongoDB provides an option to encrypt data at all times, irrespective of whether your data is in disk, memory or transiting from one layer to another - no one without the right encryption keys can access your data.
When the data is stored on the disk, MongoDB’s WiredTiger storage engine encrypts the data files using a specific algorithm. This ensures that even if the physical media is compromised, the data cannot be accessed without the encryption key. MongoDB uses Advanced Encryption Standard (AES-256) mechanism to encrypt data at rest.
With the in-use approach, MongoDB ensures that data is safe and secure throughout its lifecycle. In-use data is first encrypted at client-side using encryption keys through customer-controlled keys, before it is sent, stored or received from the database. MongoDB provides two robust features for data encryption in-use.
This feature enables client applications to encrypt the sensitive data before storing it in the MongoDB database. This means it can be decrypted at the client-side. If some other client or MongoDB product tries to access the data, they cannot, as the encryption key is only with the particular client. You can use automatic encryption, where you don't need to write code to specify how the fields should be encrypted, and explicit encryption, where you need to write the logic for encrypting the fields using the MongoDB driver’s encryption library.
With the introduction of Query able encryption in MongoDB 7.0, now clients can query the encrypted data, without the need to decrypt it. This is a groundbreaking technology, which enables using equality matches (generally available), and range, prefix, suffix, and substring query capabilities to be added soon. The sensitive fields are stored as fully randomized encrypted data on the database server-side. This means that even if someone tries to snoop the database, they can only see some gibberish (encrypted text).
The WiredTiger storage engine uses journaling to log data before writing it to the database. Also, replaying the journal entries ensures data consistency, thus protecting against any data corruption. Further, tools and platforms like MongoDB OpsManager and MongoDB Atlas provide options for encrypted backups, secure storage, and controlled access to backup data.
MongoDB also provides several methods over the network to restrict access to resources, reducing the exposure to potential attacks.
You can configure to accept connections only from a set of listed IP addresses, known as Access Control Lists.
Firewalls can be configured to further restrict access to MongoDB instances based on IP address.
In this article, we have explored the various approaches deployed by MongoDB to ensure robust security and data integrity. Following these approaches protects your MongoDB deployments from potential threats and vulnerabilities. Although MongoDB provides basic security by default, it is important to ensure that your security settings have authorization enabled. It is also a good practice to implement Multi-Factor Authentication (MFA) for added security, particularly for accounts with admin access. For higher network security, always bind to Specific IP Addresses, use firewalls and security Groups and encrypt traffic using TLS/SSL protocol.
