MongoDB (part 3): How to secure data

MongoDB is a NoSQL document database designed to make it easy for developers to work with data in any form and from any programming language. This article is the third in a three-article series that briefly covers how to create, manage and secure data in MongoDB. If you are unfamiliar with MongoDB, check out the first article in this series, MongoDB (part 1): How to design a schemaless, NoSQL database. 

Database security

So what is database security? Database security refers to the range of tools, controls and measures designed to establish and preserve database confidentiality, integrity and availability. Depending on your deployment model, you will want to enable the security of different aspects of your database, such as identification and access control, patching and so on.

Lucky for us, MongoDB Atlas is a fully managed database service that delivers all security best practices out of the box. This means we do not have to worry about keeping our database patched or whether or not the database itself is secure. However, you should make some basic changes to ensure your data is not compromised.

Best practices

MongoDB has seven best practices they recommend to help keep your data safe from compromises. These best practices include the following configurations (MongoDB, 2020):

Pre-production

Before putting your database into production, you’ll want to ensure the following tasks are complete. This will minimize your risk of data compromise when your database is live:

• Create separate, least privilege credentials – Each user or application must have their own credentials to access the database with the least amount of access required to perform their role or function. With MongoDb, you should create a user administrator first.
• Limit database connections – Limit connections to your database to specific sources (i.e. IP address).
• Encrypt your data – Encrypt both data at rest and data in transit. By default, all in-transit data is encrypted using TLS/SSL.

Production

Once your database is “Live,” you should do the following:

• Implement Field Level Redaction – Field level redaction lets you hide data in your database by storing access criteria in a document. Use the $redact operator to make use of this feature.
• Enable access control and enforce authentication – Always use role-based access, in which permissions are attached to a role which is then assigned to a user.
• Harden Network Configuration –Configure firewall rules to limit incoming traffic from trusted sources. Also, make use of VPNs (Virtual Private Networks). VPNs provide a secure tunnel between a trusted source and your database, preventing man-in-the-middle attacks.
• Add extra encryption for sensitive data – Add extra encryption such as client-side field-level encryption. This type of encryption ensures only relevant parties can read their own data on the client-side, using their unique decryption key.
• Audit database logs – Review database log activity to identify events and activities taking place within your IT infrastructure.

Security features vary, depending on the edition of Mongo you are using. You should be aware that MongoDB Enterprise Server offers additional security and performance features not available in the community edition, such as Kerberos authentication, encryption and more.

For detailed information about the security how to secure your database, check out other resources such as:

• MongoDB Security Checklist (located in the MongoDB Manual”
• MongoDB Security Architecture Whitepaper
• MongoDB Security Technical Implementation Guides (STIGs) 
• Regulatory requirements documentation such as HIPPA, PCI-DSS, NIST, etc.
• OWASP Database Security Cheat Sheet

There is no shortage of security controls and mitigation strategies freely available. Ultimately, the policies and procedures you follow will depend on your organization’s strategy and regulatory requirements. In addition to the resources listed above, we can also use security tools such as database scanners.

Database scanners are specialized tools used to identify vulnerabilities in database applications. They carry out exploits such as password cracking to identify vulnerabilities that need remediation. Some examples of database scanners include Scuba or AppDetectivePro. Vulnerability scanners such as Nessus can also check for security issues.

How to secure data in MongoDB

In the upcoming examples, we will look at how to apply security settings to the database ‘myDB’ that we created in the first article, MongoDB (part 1): How to design a schemaless, NoSQL database.  We will look at how to review audit logs and implement security controls to enforce access control and limit network exposure. Keep in mind that we stored our data in MongoDB Atlas, which is a managed service. Although we are not required to patch, there are some security changes we can make to further secure access to our data.

Enforce access control

Access control determines who can view or use a resource. Security best practices dictate that you conduct a periodic review of user permissions to ensure proper access control. The goal of reviewing user permissions is to detect excessive privileges and prevent unauthorized users from starting MongoDB data and processes. For example, suppose that we decided to have our data reviewed by an independent database administrator we’ll call Gino. We would limit Gino’s rights to “read” so he can review it.

Let’s use the web interface and create a new user to give a user access to the database. On the left sidebar, navigate to ‘Database Access ‘under the security section and click the green ‘’+ Add a New Database User’ button.

You can choose any authentication method, but we will simply choose the standard username and password for this example. 

The database admin has estimated five hours to review our database. Since this is temporary employment for this user, we will limit his account access over time. Scroll down and enable ‘Temporary User duration.’

Limit network exposure

In addition to restricting use access, we may also want to restrict access to certain systems or clients. We can edit the network rules to allow Gino’s system to access our database cluster from a particular IP address. You can restrict network access by IP address, CIDR block or Security Group ID. 

On the left sidebar, navigate to ‘Network Access ‘under the security section and click the green ‘’+ IP Address” button. Now we will enter the IP address for Gino’s workstation:

There are also options to set up peering or limit access to a private endpoint such as AWS PrivateLink, Google Cloud Private Service Connect or Azure Private Link.

Now the outsource administrator can access the database to perform the audit/review.

Securing a MongoDB database

We learned how to secure a MongoDB database! We also briefly covered external resources such as regulations or STIGS that provide instruction on implementing database security. We also looked at how to control user access and how to restrict network access to our database. For more in-depth information on how to secure your database, visit mongodb.com and review the MongoDB Security Architecture Whitepaper.

In this series, we looked at the basics of creating, managing and securing data in a MongoDB database. But don’t stop here! Review the documentation and see what you can create to support your next project.

Sources

•  7 Best Practices For MongoDB Security, MongoDb.com
• Security Checklist — MongoDB Manual, MongoDb.com