Configure Security Features for Clusters (original) (raw)
You can use Atlas securely out of the box. Atlas comes preconfigured with secure default settings. You can fine-tune the security features for your clusters to meet your unique security needs and preferences. Review the following security features and considerations for clusters.
To learn about recommendations for Atlas network security, seeRecommendations for Atlas Network Security in the Atlas Architecture Center.
Important
As a security best practice, don't include sensitive information in namespaces and field names. Atlas doesn't obfuscate this information.
The following security features are part of the Atlas product:
Atlas automatically enables FIPS 140-2 level 2 for all databases.
Atlas requires TLS/SSL to encrypt the connections to your databases.
TLS/SSL certificates are:
- Valid for 90 days from the day Atlas issues the certificate.
- Rotated 42 days before the certificate's expiration date.
To learn more about TLS encryption, see the Atlas Security White Paper.
To configure SSL or TLS OCSP certificate revocation checking, seeOCSP Certificate Revocation Check.
All Atlas projects with one or more M10+ dedicated clusters receive their own dedicated VPC (or VNet if you use Azure).Atlas deploys all dedicated clusters inside this VPC or VNet.
By default, Atlas encrypts all data stored on your Atlas clusters.Atlas also supports Encryption at Rest using your Key Management.
You must configure the following security features:
Make sure your application can reach your MongoDB Atlasenvironment. To add the inbound network access from your application environment to Atlas, do one of the following:
- Add the public IP addresses to your IP access list
- Use VPC / VNet peering to add private IP addresses.
- Add private endpoints.
Tip
If your firewall blocks outbound network connections, you must also open outbound access from your application environment to Atlas. You must configure your firewall to allow your applications to make outbound connections to ports 27015 to 27017 to TCP traffic onAtlas hosts. This grants your applications access to databases stored on Atlas.
Note
By default, MongoDB Atlas clusters do not need to be able to initiate connections to your application environments. If you wish to enable Atlas clusters withLDAP authentication and authorization, you must allow network access from Atlas clusters directly to your secure LDAP. You can allow access to your LDAP by using public or private IPs as long as a public DNS hostname points to an IP that the Atlas clusters can access.
If you are not using VPC / VNet peering and plan to connect to Atlas using public IP addresses, see the following pages for additional information:
Atlas only allows client connections to the cluster from entries in the project's IP access list. To connect, you must add an entry to the IP access list. To set up the IP access list for the project, seeConfigure IP Access List Entries.
For Atlas clusters deployed on Google Cloud Platform (GCP) orMicrosoft Azure, add the IP addresses of your Google Cloud orAzure services to Atlas project IP access list to grant those services access to the cluster.
Atlas requires clients to authenticate to connect to the database. You must create database users to access the database. To set up database users to your clusters, seeConfigure Database Users. Atlas offers many security features for cluster authentication and authorization.
To access clusters in a project, users must belong to that project. Users can belong to multiple projects.
Tip
You may configure the following security features:
Atlas supports peering connections with other AWS, Azure, orGoogle Cloud network peering connections. To learn more, seeSet Up a Network Peering Connection.
Important
If this is the first M10+ dedicated paid cluster for the selected region or regions and you plan on creating one or moreVPC peering connections, please review the documentation on VPC peering connections before continuing.
Atlas supports private endpoints on:
- AWS using the AWS PrivateLinkfeature
- Azure using the Azure Private Link feature
- Google Cloud using the GCP Private Service Connectfeature
To use private endpoints, see Learn About Private Endpoints in Atlas.
Some Atlas features, including Data Federation and Encryption at Rest using Customer Key Management, use AWS IAM rolesfor authentication.
To set up an AWS IAM role for Atlas to use, seeSet Up Unified AWS Access.
Atlas offers the following security features for cluster authentication and authorization.
Atlas requires clients to authenticate to access clusters. You must create database users to access the database. To set up database users for your clusters, see Configure Database Users.
Atlas supports creating custom rolesfor database authorization in cases where the built-in Atlas roles don't grant your desired set of privileges.
You can set up authentication and authorization for your AWS IAMroles. To learn more, see Set Up Authentication with AWS IAM.
Atlas supports performing user authentication and authorization with LDAP. To use LDAP, seeSet Up User Authentication and Authorization with LDAP.
X.509 client certificates provide database users access to the clusters in your project. Options for X.509 authentication include Atlas-managed X.509 authentication and self-managed X.509 authentication. To learn more about self-managed X.509 authentication, see Set Up Self-Managed X.509 Certificates.
Organization owners can restrict MongoDB Production Support Employees from accessing Atlas backend infrastructure for any Atlascluster in their organization. Organization owners may grant a 24 hour bypass to the access restriction at the Atlascluster level.
Important
Blocking infrastructure access from MongoDB Support may increase support issue response and resolution time and negatively impact your cluster's availability.
To enable this option, see Configure MongoDB Support Access to Atlas Backend Infrastructure.
Atlas supports using AWS KMS, Azure Key Vault, and Google Cloud to encrypt storage engines and cloud provider backups. To use encryption at rest, see Encryption at Rest using Customer Key Management.
Atlas supports client-side field level encryption, includingautomaticencryption of fields. All Atlas users are entitled to use MongoDB's automatic client-side field level encryption features.
To learn more, seeClient-Side Field Level Encryption Requirements.
Note
Tip
Atlas supports auditing all system event actions. To use database auditing, see Set up Database Auditing.
Atlas surfaces authentication logs directly in the Atlas UI so that you can easily review successful and unsuccesful authentication attempts made against your clusters. To view your database access history, see View Database Access History.
Atlas supports MFA to help you control access to yourAtlas accounts. To set up MFA, see Manage Your Multi-Factor Authentication Options.
If you use any of the following Atlas features, you might have to add Atlas IP addresses to your network's IP access list:
Note
Send a GET request to the controlPlaneIPAddresses endpoint to fetch the current Atlas control plane IP addresses. TheAPI endpointreturns a list of inbound and outbound Atlas control plane IP addresses in CIDR notation categorized by cloud provider and region, similar to the following:
{
"inbound":{
"aws":{
"<region-name>":["<IP-address>", ...],
...
},
"azure":{
"<region-name>":["<IP-address>", ...],
...
},"gcp":{
"<region-name>":["<IP-address>", ...]
...
}
},
"outbound":{
"aws":{
"<region-name>":["<IP-address>", ...],
...
},
"azure":{
"<region-name>":["<IP-address>", ...],
...
},
"gcp":{
"<region-name>":["<IP-address>", ...],
...
}
}
}
Important
The Atlas Administration API uses the terms inbound and outboundin relation to the control plane, not your network. As a result:
- Your network's inbound rules must match the
outboundCIDRs listed in the Atlas Administration API. - Your network's outbound rules must match the
inboundCIDRs listed in the Atlas Administration API.
The following diagram shows the relationship between inbound andoutbound for the control plane and your network:
click to enlarge
To add the returned IP addresses to your cloud provider's KMS IP access list, see the prerequisites for managing customer keys with AWS,Azure, and GCP.
controlPlane.outbound lists the IP addresses of traffic coming from the control plane. Your network's inbound HTTP IP address list must allow access from the IP addresses listed in controlPlane.outbound.
We recommend that you use the Atlas Admin API to fetch the current outbound Atlascontrol plane IP addresses.
controlPlane.inbound lists the IP addresses traffic coming into the control plane. If your network allows outbound HTTP requests only to specific IP addresses, you must allow access to the IP addresses listed incontrolPlane.inbound so that Atlas can communicate with your webhooks and KMS.
We recommend that you use the Atlas Admin APIto fetch the current inbound Atlas control plane IP addresses.
If your network allows outbound HTTPS requests only to specific IP addresses, you must allow access from the inbound IP addresses on TCP port 27017 so that your requests can reach the federated database instance. We recommend that you use the Atlas Admin APIto fetch the current inbound Atlas control plane IP addresses.
If your network allows outbound requests to specific IP addresses only, to allow SSL or TLS OCSP certificate revocation checking, you must allow access toAtlas' CA (Certificate Authority) OCSP Responder servers that can be found in theOCSP URL of the SSL orTLS certificate.
To disable OCSPcertificate revocation checking, refer to the documentation for the MongoDB driver version that your application uses.