Almost all of the posts out there reference the generic MongoDB security checklist as what you should implement to protect your MongoDB installation.
So with this being said, the following questions should be on your mind;
- How does this list apply to my mLab Cloud hosted MongoDB service?
- Are my mLab MongoDB databases as secure as they possibly can be?
With the new Sitecore Azure PaaS offering picking up steam, it's more important than ever to understand mLab's security considerations as mLab on Azure is the default option that clients are turning to.
The purpose of this post is to help you understand how secure your client's current mLab environment is, or how to secure a new database cluster that you may be working on.
The items being referenced can be found within mLab's security documentation at http://docs.mlab.com/security.
Dedicated Cluster
Every client should be on a Dedicated Cluster plan of some sort.
These plans offer a number of potential security enhancements, as well as a number of baseline security considerations, such that all deployments will always have auth enabled no matter what.
This feature allows for an mLab deployment to be created in a VPC such that another VPC can be peered to limit any connections to the customer-owned VPC. This is especially useful for applications that may have dynamic scaling and non-static IP address.
You can read more about mLab Private Environments at http://docs.mlab.com/private-environments/
These plans offer a number of potential security enhancements, as well as a number of baseline security considerations, such that all deployments will always have auth enabled no matter what.
Private Environment
An optional security enhancement is using an mLab Private Environment.This feature allows for an mLab deployment to be created in a VPC such that another VPC can be peered to limit any connections to the customer-owned VPC. This is especially useful for applications that may have dynamic scaling and non-static IP address.
You can read more about mLab Private Environments at http://docs.mlab.com/private-environments/
Encryption at Rest
This will encrypt any data as it resides on disk: http://docs.mlab.com/security/#encryption-at-rest.
The feature is currently only supported on AWS and Google Cloud Platform and NOT Azure.
Encryption during Transit (SSL)
Without this feature enabled, any communication with your mLab deployment that is not originating from within AWS or Azure is going to take place across the open internet and will be susceptible to packet sniffing.
Even with custom firewall rules in place to limit access to only the IP address(es) (or address ranges) you specify, traffic between the database and the client applications and networks is vulnerable to snooping.
Whether creating a new deployment or upgrading an existing deployment, you can enable SSL support for MongoDB connections directly from the mLab management portal.
It's an extra $80 a month, but it's well worth the investment in order to ensure privacy, critical security and data integrity.
The details around this feature can be found here: http://docs.mlab.com/ssl-db-connections/.
Access can be limited to specific IP address ranges and/or to Amazon EC2 security groups (AWS only).
If you are using AWS, your Security Group must be in EC2-Classic and exist in AWS us-east-1 (the same AWS Region as your database). If your app is in EC2-VPC, consider migrating this deployment to an mLab Private Environment: http://docs.mlab.com/private-environments/
More information about this feature can be found at http://docs.mlab.com/security/#custom-firewalls
Even with custom firewall rules in place to limit access to only the IP address(es) (or address ranges) you specify, traffic between the database and the client applications and networks is vulnerable to snooping.
Whether creating a new deployment or upgrading an existing deployment, you can enable SSL support for MongoDB connections directly from the mLab management portal.
It's an extra $80 a month, but it's well worth the investment in order to ensure privacy, critical security and data integrity.
The details around this feature can be found here: http://docs.mlab.com/ssl-db-connections/.
Custom Firewall Rules
Basically, the feature offers 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).
If you are using AWS, your Security Group must be in EC2-Classic and exist in AWS us-east-1 (the same AWS Region as your database). If your app is in EC2-VPC, consider migrating this deployment to an mLab Private Environment: http://docs.mlab.com/private-environments/
More information about this feature can be found at http://docs.mlab.com/security/#custom-firewalls
Two-factor Authentication for the mLab management console
2FA is optional by default for account users.
Access to the mLab management console provides full and complete access to any deployment within the account, including the ability to create and download backups as well as delete/modify deployments.
Making 2FA a requirement will reduce the potential for undesired access.
Final Note
These security enhancements are all optional, but also recommended.
mLab's baseline security practices provide a reasonable degree of security, but as you very well know, security is not a binary subject and there are always ways to increase the overall security of a deployment.
mLab's baseline security practices provide a reasonable degree of security, but as you very well know, security is not a binary subject and there are always ways to increase the overall security of a deployment.
0 comments:
Post a Comment