Jay Gordon is a Technical Account Manager with MongoDB and is available via our chat to discuss Cloud Manager at cloud.mongodb.com

Securing your MongoDB deployment can be done quite simply thanks to using AWS and Cloud Manager. Let’s discuss the process of determining if your AWS deployment has an enhanced security configuration to reduce exposure. If it’s not, we’ll provide you with some tips to properly secure it and ensure your data is not available to the world.

We will start with your Cloud Manager deployment in AWS Cloud. The most important part prior to deploying MongoDB is properly configuring your security group.

Security Groups are AWS virtual firewalls that allow you to isolate network environments similarly to a Software or Hardware firewall on your EC2 instances.

Our documentation page for Firewall Configuration has a list of ports and IPs that need access.

Let’s highlight some key points you should hit to improve your network security posture:

Outbound Firewall Rules

We must allow all outgoing HTTPS (port 443) traffic to pass in order for your Cloud Manager agents to function. Without this, the agents will not be able to communicate back to Cloud Manager. Typically, outbound traffic is not filtered by default. All security groups come with a default 0.0.0.0/0 rule for all outgoing traffic.

Prepping your Inbound Firewall Rules

This is the part where things can get complicated. Without properly configuring this, we will not be permitted to either access, configure and secure our systems. An empty security group provides you no real access.

Before you go to production, you should consider what other systems and people aside from MongoDB Cloud Manager are going to require access. This could be as simple as determining IP addresses of your office VPN, local computer or application servers. By limiting access to your MongoDB deployment to trusted connections only, you reduce your attack surface that can be exploited by remote attackers.

Important IPs for Cloud Manager

Please note, these IPs can change without notice, so always check our documentation on provisioning and restores for the latest addresses.

Auto-Provisioning

If you use Cloud Manager provisioning, you must grant SSH access to the following ranges at minimum:

• 4.71.186.128/25
• 4.35.16.128/25

Backup SCP Restores

If you use SCP as the delivery method when restoring a snapshot, you must grant SSH access to the following ranges at minimum:

• 4.71.186.128/25
• 4.35.16.128/25

TCP Ports to Consider

All MongoDB processes in a deployment must be accessible to all Cloud Manager agents managing or monitoring processes in that deployment. Therefore, all MongoDB ports must be open to every server that hosts an Automation, Monitoring or Backup Agent. For example, if you are running MongoDB processes on 27000,27017 and 27020, then those three ports must be open from all servers that are hosting an Agent.

This example is a minimum ingress ruleset for AWS provisioning and SCP restores. We have also configured our internal network to permit the 27000 - 28000 ports to talk to each other. You can assign multiple security groups to your instances if you’d like to create a separate Security Group to handle your authentication for any external access to the MongoDB systems via ssh or mongo shell.

Alerts

MongoDB Cloud Manager comes with a monitoring and alerting system. Part of this alerting set will notify you if your MongoDB deployment is exposed to the internet:

In the case of a situation like this, Cloud Manager will notify you via whichever integration, email or SMS, you’ve selected. This is just another benefit of using Cloud Manager, the idea that your total overhead can be reduced by allowing our software to replace the typical requirements around monitoring and alerting. If your organization already uses some other form of alerting, you can leverage our Public API which can allow you to hook these alerts into any system you may already be using.

User Authentication and SSL

Cloud Manager has many other security features built in such as SSL and user authentication which are extremely valuable. Our Automation Agent has the ability to enable these features for you with a few clicks, saving you time and operational overhead.

Authentication

Once you enable user authentication, we begin the process of automatically managing passwords for your application role users for backups and system management on your behalf. You also have the ability to use roles to create users with different sets of permissions in logical groups. Authentication methods available include SCRAM-SHA-1, Kerberos, LDAP and X.509 client certificate.

SSL

Some applications can support the ability to connect to a running MongoDB deployment that utilizes SSL to encrypt data in-transit between the application and the database. Tools must provide users the ability to connect with or without an SSL certificate. Users are able to supply a CA or self-signed certificate and connect to the MongoDB deployment.

MongoDB security best practices can assist in protecting your data from those who may seek to access it without your permission. Some of these tasks could include support overhead for your team during the configuration process if choosing to do manually. Thankfully Cloud Manager exists to help you implement these best practices with simplicity and speed.