blog
A Security Checklist for MongoDB Production Deployments
When an application requires a large geographical area to perform an organization is often forced to store its data in the cloud. Applications built on MongoDB are not an exception to this concept. Failure to protect sensitive data may cause the business some serious setbacks including a ruined reputation, data inconsistencies, financial losses, and sometimes complete data loss.
Data stored in the cloud is prone to interest from criminal elements. People with malicious intent can more easily get access when no standard procedures have been laid out to ensure database security. Some of these substandard procedures include…
- Poor password management: some developers end up hard coding the passwords in the project source files hence if a hacker decompiles the application they can easily retrieve the contents.
- Reluctancy or failure to update the database and complimentary plugins. Newer database versions have new features may be in terms of security or rather have some features fixed from the predecessors.
- Substandard database configurations for instance not using encrypted decryption keys or rather not using any security protocol at all.
Database attacks are increasing day-in, day-out (and the trend is expected to continue), but you may not fall victim unless you employ the appropriate security considerations. In this article, we are going to discuss some of the procedures one can check with MongoDB installation in cloud. You do not need to apply all of them, but at least try best to pick the ones that if avoided, could put your data in a disastrous situation.
MongoDB Pre-Production Security Considerations
These are considerations one should ensure they are well configured when about to deploy MongoDB into the production environment. They include:
- Enabling and Enforcing authentication for Access Control
- Configure Role -Based Access Control
- Limit Network Exposure
- Encrypt Communications
- Encrypt data
- Audit System Activities
- Use Dedicated User to Run MongoDB
- Utilize Official and Updated MongoDB packages
- Disable Javascript executions if not needed
- Be updated with MongoDB security fixes
1. Enabling and Enforcing Authentication for Access Control
Access control is not enabled in MongoDB by default but this doesn’t mean you also deploy your database without this option enabled. Actually some database packages like Bitnami will require you to set up some access control before using your database. Failure to do so, anyone can have access to the database hence exposure to even very sensitive data. Specify some authentication mechanism such as the SCRAM so that clients who will be connected must provide some valid credentials before they can connect to the database.
The connection string should look something like:
mongodb://[username:password@]host[:port1][/[defaultauthdb]and not just
mongodb://host[:port1]/[defaultauthdb]2. Configure Role-Based Access Control
After adding users with administrative permissions, limit roles assigned to these users using Role-Based Access Control (RBAC). The roles a user can have include: read, write or both to specific or all collections. Therefore, a user cannot perform a role not assigned to them or can perform operations to assigned collections only.
User administrator is created first then additional users. If a user has privileges across different databases you can create a single user with roles that grant applicable database privileges instead of creating the user multiple times in different databases.
It is advisable to have a small number of users accessing the database whereby the users can be people or client applications.
To create and grant user permissions for certain roles in MongoDB you can use this example in the mongo shell
use finance
db.createUser(
{
user: "manager",
pwd: passwordPrompt(), // or cleartext password
roles: [
{ role: "read", db: "loans" },
{ role: "read", db: "interests" },
{ role: "read", db: "useraccounts" },
{ role: "readWrite", db: "wages" }
]
}
)Also, opt for external authentication options such as LDAP and Kerberos.
3. Limit Network Exposure
Network topology that hosts the database needs to be secured extensively and most importantly listen only to the localhost interface. This is to avoid exposure from outside connections like it was the case for MongoDB older versions. Ensure that MongoDB runs in a trusted network environment with security firewall enabled. Control inbound and outbound traffic with security groups that may not be used with other instances. Use IP whitelisting to allow access from trusted IP addresses hence allow connections to MongoDB instances with network interfaces and ports from only trusted clients.
Besides, disable the direct SSH root access.
4. Encrypt Communications
MongoDB configuration should restrict incoming and outgoing connections to TLS/SSL only. TLS/SSL encrypts communication between mongod and mongos components of a MongoDB deployment and all applications connected to it.
In the production environment, MongoDB deployment should use valid certificates generated and signed by a single certificate authority.
5. Encrypt The Data
Database data takes two forms: data at rest and in transit. Data in transit can be secured by using Client-Side Field Level Encryption but is only available in version 4.2. The TLS/SSL encryption also takes care of data in transit.
The WiredTiger storage engine from version 3.2 Enterprise provides data in storage layer encryption. This affirms that only authenticated users with decryption keys can access the data. If you are not using the WiredTiger’s encryption at rest, use File-System encryption. Data at rest encryption deters one from accessing the contents of your database if they get access to the physical server hence a crucial part in securing MongoDB.
6. Audit System Activities
This is an enterprise option that allows tracking of all changes to data and database configurations. The events are written to a syslog connection or some log file. The logs can contain DB authentication attempts including source IP addresses and the info can help to determine which hosts should be blocked by the firewall from accessing the database. Besides, one can grape fine which events to log.
Ths audit logs in general will help the administrator do some forensic analysis and hence set standard security controls.
7. Use Dedicated User to Run MongoDB
MongoDB processes should be run with a dedicated operating system user account which should have access permissions enabled.
8. Utilize Official & Updated MongoDB Packages
Pass authenticity checks on your packages to ensure they are the MongoDB official packages. Using the latest MongoDB drivers and the latest version of the database itself offer more security stability than the predecessors. For instance, version 4.2 offers the Client-Side Field Level Encryption. Ensure you therefore migrate to the most recent version of MongoDB.
9. Disable Javascript Executions if Not Needed
mapReduce and $where are some of the executable JavaScript codes within MongoDB and if not well managed they can result in some unwanted data inconsistency or allow one to access the data indirectly and apply some changes if they want to.
In general, this JavaScript code will allow external injections hence unvalidated data getting into your database. You can also opt to use packages such as mongoose to validate and connect to your database. Use MongoDB operators instead of JavaScript expressions.
10. Get Updated with MongoDB Security Fixes
Security protocols may be broken by attackers with time hence need one to involve advanced procedures. Staying up to date with top security updates and bug fixes from the MongoDB release notes is very important. The MongoDB alert page was basically created for such purpose.
Request for a security technical implementation guide if possible and make sure your deployment is inline with security standards compliances.
Conclusion
Databases in production are prone to security attacks, hence need one to invest heavily in protecting sensitive data. The security procedures range from data-in-transit, data-at-rest, and the connected client applications. Besides the mentioned practices above, server hardening undertakings will provide another layer of data protection.
It is important to use the most recent versions of MongoDB and plugins besides keeping up with the latest security and bug fixes related with your version.