Security

Overview

mLab takes the security of mLab accounts and deployments seriously and is continuously working to provide features and tools that increase the safety of your account and data.

Database and network security

Securely accessing and communicating with a mLab database involves not just having the proper credentials but proper placement of all entities that connect to your database. Custom firewall rules can also be configured for select deployments, limiting the ability of non-trusted entities to gain access to your database.

Database authentication

All mLab database servers are run in “auth mode” (mongod run with the –auth flag). Before the database can be accessed, you will need to create a database user and password in order to authenticate against the database.

Deployments running with MongoDB release version 3.0 and above are using Salted Challenge Response Authentication Mechanism or SCRAM as their authentication mechanism (see MongoDB’s documentation on SCRAM-SHA-1).

Securing communications to your database

You should always try to place your application infrastructure and your database in the same local network (i.e., datacenter / cloud region), as it will be the most secure method of deployment and will minimize latency between your application and database.

When you connect to your mLab database from within the same datacenter/region, you communicate over your cloud hosting provider’s internal network. All of our cloud hosting providers provide a good deal of network security infrastructure to isolate tenants. The hypervisors used do not allow VMs to read network traffic addressed to other VMs and therefore no other tenant can “sniff” your traffic.

However, when you connect to your mLab database from a different datacenter/region, your communications are less secure. While your database does require username / password authentication (with credentials that are always encrypted on the network), the rest of your data is transmitted unencrypted over the open internet. As such you are potentially vulnerable to others “sniffing” your traffic.

Using MongoDB with SSL connections

Available for Dedicated plans only

To further secure communications to your database, mLab offers SSL for MongoDB connections on Dedicated plans provisioned via mlab.com. Even when using SSL, we still recommend placing your application infrastructure and your database in the same datacenter/region to minimize latency and add another layer of security.

Configuring custom firewalls

Available for Dedicated plans only

Dedicated plans offer the ability for you to define custom firewall rules so that your database only allows network access from your application infrastructure. Access can be limited to specific IP address ranges and/or to Amazon EC2 Security Groups (AWS only).

Whitelisting IP addresses

mLab can configure your firewall to limit access to only the IP address(es) (or address ranges) you specify. We use CIDR rules to define the allowable address(es) and secure access to your mLab-hosted Dedicated plan databases.

Follow these instructions to add an IP address:

  1. Log in to the mLab management portal.
  2. Navigate to the MongoDB deployment that you wish to secure.
  3. Click the “Networking” tab.
  4. Click the “Add IP rule(s)” button.
  5. Enter the IP address and an optional description for the rule. img-firewallip
  6. Click the “Add” button.

Whitelisting Amazon EC2 Security Groups (AWS only)

If you’re interested in AWS VPC Peering, please visit our documentation on our Private Environments feature.

If your Dedicated plan deployment is hosted in AWS, you may also allow access to a Security Group. If your deployment is in EC2-Classic, note that the Security Group that you allow must also be in EC2-Classic. If your deployment is in EC2-VPC, note that the Security Group that you allow must be in peered VPC.

To control access to your mLab-hosted database using your EC2 Security Group, you’ll need to provide your AWS account ID (a 12-digit number) and Security Group ID (begins with “sg-“).

Follow these instructions to add a Security Group:

  1. Log in to the mLab management portal.
  2. Navigate to the MongoDB deployment that you wish to secure.
  3. Click the “Networking” tab.
  4. Click the “Add Security Group rule” button.
  5. Enter your AWS account ID, Security Group ID and an optional description.
  6. Click the “Add” button.

Are you using Heroku? In the past, Heroku published its AWS account ID and Security Group name so that you could grant your Heroku app access to your mLab database hosted on AWS, but as of October 24, 2013 they stopped recommending this practice. Today, given that Heroku apps run in multiple regions and in EC2-VPC, this approach would not work at all.

Copying rules from another deployment

For convenience, you can use the “Copy existing rules” button to copy rules already added to another deployment in your mLab account. This saves you the effort of having to add each rule and/or Security Group one by one for all the deployments in your account.

img-firewallcopy

Data security: Encryption at Rest

Available on AWS and Google Cloud Platform only

The content contained herein is correct for deployments created on or after February 2, 2017. mLab’s security policies and systems may change going forward, as we continually improve protection for our customers and their data.

Data disk encryption

AWS

On AWS, mLab offers the option to use Amazon EBS encryption on EBS-backed Dedicated plans (i.e., Standard and High Storage lines). It is important to note the following:

Azure

mLab currently does not support encrypted data disks on Azure.

Google Cloud Platform

On Google Cloud Platform, data is always stored encrypted at rest.

Backup encryption

Backups

When using mongodump:

When using block storage snapshot:

Restore considerations

For restores of backups taken using mongodump, whether the target for the restore is encrypted depends on whether the target has disk encryption enabled.

For restores of backups taken using block storage snapshots, the target of the restore will be encrypted if the volume from which the snapshot was taken was encrypted.

Exceptions

Be aware that:

Web management portal security

The mLab management portal is run entirely over HTTPS.

Account-level security settings

The mLab management portal offers a number of security-related settings that determine what users can or cannot do in terms of securing their user profiles and other mLab features. In this section we provide instructions on how to set these global security options as well as an explanation for each of the available options.

Adjusting the account-level security settings

The Admin User of an account is the only user who can adjust the account-level security settings. All users on the account, including the Admin User, are subject to these settings.

To adjust the account-level security settings, the Admin User can follow these instructions:

  1. Log in to the mLab management portal.
  2. Click “Account” in the upper right-hand corner to open the Account Settings page.
  3. Click the “Security” tab to display the Security Settings page.
  4. Make changes to each of the available options as desired.
  5. Click the “Save changes” button to save any updates.

img-accountsecurity

Account-level security settings explained

Two-factor authentication

Username recovery

Password reset

Data API access

Two-factor authentication

Available only for accounts created via mlab.com

Two-factor authentication provides an extra layer of security for your mLab account and can be enabled on a per-user basis. Each account user who has activated the feature will be prompted for more than just a password when logging in to mlab.com. A second piece of information is also required (hence, two-factor) which in mLab’s case is an authentication code that can be retrieved from an application that the user installs on a mobile phone or device. Requiring two separate pieces of information (a password and an authentication code) helps protect your mLab account from unauthorized access.

Even though it is an optional feature, we strongly recommend that you enable it for your mLab account.

Enable two-factor authentication

Before you follow the instructions below, if you do not already have an authenticator application installed on your mobile phone/device, you will need to install one. Any application that supports the Time-based One-Time Password (TOTP) protocol should work, for example the Google Authenticator which works on iOS, Android, and Blackberry devices or Authenticator for Windows Phone 7 which works for Windows Phone devices.

  1. Log in to the mLab management portal.
  2. Click your username (not the account name) in the upper right-hand corner to open your account user profile.
  3. In the section titled “Two-Factor Authentication”, follow the instructions to activate this setting.
  4. Check your inbox to confirm you have received an email reporting successful enablement of two-factor authentication.
  5. Set up a fallback SMS number (required for Admin Users, optional for non-admin users).

It is important to keep your fallback SMS number up-to-date. Without a valid and accessible fallback number, then you will permanently lose the ability to access your mLab account if your authenticator application is also deleted, lost, or stolen. You would then need to manually migrate your data to a new account which will probably entail significant downtime for your application.

Fallback SMS number

If you should ever be without your authenticator device, a fallback SMS number is a secondary mechanism by which mLab can deliver to you the authentication code. This feature is mandatory for Admin Users who have enabled two-factor authentication for their user login. For non-admin users, this is an optional though strongly recommended feature.

To take advantage of this feature, you must provide the fallback SMS number in your account profile, as part of the two-factor authentication setup process described in the preceding section. When you set up a fallback SMS number, you will receive an SMS message confirming that the number has been configured as your fallback number. If you do not receive the message, you can test whether or not you’ve entered the correct number by using this phone number lookup tool.

Once your fallback SMS number is set up and confirmed, you can request an authentication code to be sent to that number by clicking the “Send the code via SMS” link that appears on the screen where you would enter your authentication code.

API security

Connecting to your database via our API is secured via HTTPS and an API key.

Be sure to read this section on API authentication to learn more about security as it relates to mLab’s RESTful Data API.