Atlas proporciona configuraciones de red seguras por defecto para sus implementaciones de la base de datos, tales como:
Obligatorio Cifrado de conexión TLS/SSL
VPCs para todos los proyectos con uno o más clústeres dedicados
Autenticación que utiliza listas de acceso IP y solo acepta conexiones a la base de datos desde fuentes que se declaren explícitamente
Puedes configurar aún más estas protecciones para satisfacer tus necesidades y preferencias únicas de seguridad.
Usa las recomendaciones de esta página para planificar la configuración de seguridad de red de tus clústeres.
Nota
El Modelo de Responsabilidad Compartida de MongoDB Atlas define los deberes complementarios de MongoDB y sus clientes en el mantenimiento de un entorno de datos seguro y resiliente. Bajo este marco, MongoDB gestiona la seguridad y la integridad operativa de la plataforma subyacente, mientras que los clientes son responsables de la configuración, gestión y políticas de datos de sus implementaciones específicas. Para obtener un desglose detallado de la propiedad en materia de seguridad y excelencia operativa, consulta Modelo de responsabilidad compartida.
Funcionalidades para la seguridad de red de Atlas
Atlas aplica el cifrado TLS/SSL para todas las conexiones a tus bases de datos.
Recomendamos usar clústeres dedicados M10+ porque todos los proyectos de Atlas con uno o más clústeres dedicados M10+ reciben sus propios recursos dedicados:
VPC en AWS o Google Cloud.
VNet en Azure.
Atlas implementa todos los clústeres dedicados dentro de este VPC o VNet.
Por defecto, se bloquea todo acceso a los clústeres. Debes permitir explícitamente una conexión entrante mediante uno de los siguientes métodos:
Agregar nodos privados, que Atlas agrega automáticamente a la lista de acceso IP. Ningún otro acceso se añade automáticamente.
Utilizar el emparejamiento de VPC o VNet para agregar direcciones IP privadas.
Agregue direcciones IP públicas a su lista de acceso IP.
También se pueden usar varios métodos juntos para mayor seguridad.
TLS
Atlas aplica el cifrado TLS obligatorio para las conexiones a sus bases de datos. TLS 1.2 es el protocolo por defecto. Para obtener más información, consulta la Set Minimum TLS Protocol Version sección de Configurar configuraciones adicionales.
Listas de acceso IP
Como administrador de Atlas, puedes:
Configura listas de acceso IP para limitar qué direcciones IP pueden intentar la autenticación en tu base de datos.
Permite el acceso solo desde las direcciones IP y los rangos de IP de bloque CIDR que agregues a tu lista de acceso IP. Se recomienda permitir el acceso a los segmentos de red más pequeños posibles, como un individuo /32 dirección.
Deniega el acceso de servidores de aplicaciones y otros clientes a tus clusters de Atlas si sus direcciones IP no están incluidas en tu lista de acceso IP.
Configura entradas temporales de la lista de acceso que expiran automáticamente después de un período definido por el usuario.
Configuración del Firewall
Al conectarte desde tus servidores de aplicaciones de cliente a Atlas y al pasar por un firewall que bloquea las conexiones de red salientes, también debes configurar tu firewall para permitir que tus aplicaciones realicen conexiones salientes a TCP en los hosts de Atlas. Esto concede a tus aplicaciones acceso a tus clústeres.
Las IP públicas del clúster de Atlas siguen siendo las mismas en la mayoría de los casos de cambios en el clúster como escalado vertical, cambios de topología o eventos de mantenimiento. Sin embargo, ciertos cambios en la topología, como una conversión de un set de réplicas a un clúster, la incorporación de particiones, o un cambio de región requieren que se utilicen nuevas direcciones IP.
En el caso de convertir de un set de réplicas a un clúster, la incapacidad de reconectar los clientes de la aplicación podría hacer que tu aplicación experimente interrupciones del servicio. Si utilizas una cadena de conexión de lista de nodos iniciales DNS, tu aplicación se conecta automáticamente al mongos para tu clúster. Si utilizas una cadena de conexión estándar, debes actualizar tu cadena de conexión para reflejar tu nueva topología de clúster.
En el caso de añadir nuevas particiones, la imposibilidad de reconectar los clientes de la aplicación puede hacer que tu aplicación sufra una interrupción de datos.
Nodos privados
Un nodo privado facilita una conexión unidireccional desde una VPC, gestionada directamente, a la VPC de Atlas, sin permitir que Atlas inicie una conexión recíproca. Esto permite utilizar conexiones seguras con Atlas sin ampliar los límites de confianza de la red. Los siguientes nodos privados están disponibles:
Amazon Web Services PrivateLink, para conexiones desde AWS VPCs
Microsoft Azure Private Link, para conexiones desde VNets de Microsoft Azure
Private Service Connect, para conexiones desde VPCs de Google Cloud
Emparejamiento VPC/VNet
El emparejamiento de red permite conectar sus propios VPCcon un VPC de Atlas para enrutar el tráfico de forma privada y aislar el flujo de datos de la red pública. Atlas asigna VPCuno a uno a los proyectos Atlas.
La mayoría de las operaciones realizadas a través de una VPC conexión se originan en el entorno de tu aplicación, minimizando la necesidad de que Atlas realice solicitudes de acceso salientes a pares VPC . Sin embargo, si configuras Atlas para utilizar la autenticación LDAP, debes permitir que Atlas se conecte de forma saliente al extremo de autenticación de tu VPC peer mediante el protocolo LDAP. Tenga en cuenta que la autenticación LDAP está obsoleta en Atlas con 8.0. Recomendamos que utilices Federación de identidad de Workforce y Federación de identidad de carga de trabajo en su lugar.
Puedes elegir tu bloque CIDR de Atlas con el asistente de emparejamiento VPC antes de implementar tu primer clúster. El bloque CIDR de la VPC de Atlas no debe superponerse con el bloque CIDR de ninguna VPC con la que planeas establecer un emparejamiento. Atlas limita la cantidad de instancias de MongoDB por VPC en función del bloque CIDR. Por ejemplo, un proyecto con un bloque CIDR de /24 está limitado al equivalente de 27 sets de réplicas de 3nodos.
Recomendaciones para la seguridad de la red Atlas
Las implementaciones de una sola región no tienen consideraciones únicas para la seguridad de red de Atlas.
Las implementaciones multiregión protegidas con nodos privados tienen las siguientes consideraciones especiales:
Para los endpoints privados globales, Atlas genera automáticamente un registro SRV que apunta a todos los nodos del clúster de Atlas. El controlador de MongoDB intenta conectar con cada registro SRV desde tu aplicación. Esto permite que el controlador maneje un evento de conmutación por error sin esperar la replicación DNS y sin requerir que actualices la cadena de conexión del controlador.
Para facilitar la generación automática de registros SRV para todos los nodos en el clúster de Atlas, se debe establecer una conexión de emparejamiento VPC entre la aplicación VPC, y se debe conectar el VPCde la aplicación al VPC de MongoDB usando PrivateLink o un equivalente.
Debes habilitar nodos privados en cada región donde tengas un clúster Atlas implementado.
Google Cloud Private Service Connect es específico de la región. Sin embargo, puedes configurar el acceso global para acceder a nodos privados desde una región diferente.
Para aprender más, consulta Soporte Multiregión.
Todas las recomendaciones paradigmáticas de implementación
Las siguientes recomendaciones aplican a todos paradigmas de implementación.
Nodos privados
Recomendamos configurar nodos privados para todos los nuevos proyectos de staging y producción para limitar la extensión del límite de confianza de tu red.
En general, se recomienda utilizar nodos privados para cada Proyecto de Atlas, ya que este enfoque ofrece la seguridad más detallada y alivia la carga administrativa que puede derivarse de gestionar listas de acceso IP y bloques grandes de direcciones IP a medida que su red en la nube escala. Hay un costo asociado con cada punto final. Por lo tanto, es posible que no necesite nodos privados en entornos inferiores, pero debería aprovecharlos en entornos superiores para limitar la extensión del límite de confianza de su red.
Si las VPC o las VNet en las que se implementa tu aplicación no pueden emparejarse entre sí, posiblemente debido a una combinación de implementaciones on-premises y en la nube, tal vez quieras considerar un nodo privado regional.
Con nodos privados regionales, puedes hacer lo siguiente:
Conecte un único nodo privado a varias VNet o VPC sin emparejarlas directamente entre sí.
Mitigar fallos parciales de región en los que fallan uno o más servicios dentro de una región.
Para conectarse con puntos finales regionales, debe hacer lo siguiente:
Realiza verificaciones de estado regulares y robustas para ayudar a validar la conectividad satisfactoria y las operaciones entre el clúster y la aplicación. Puedes hacer ping al clúster con el comando
db.runCommand("ping")para confirmar la conectividad rápidamente, o ejecutarrs.conf()para obtener información detallada sobre cada nodo del clúster.Utiliza una cadena de conexión distinta para cada región.
Use enrutamiento de región cruzada a Atlas para mantener la disponibilidad en caso de desconexión de VPC de Atlas.
Para obtener más información sobre los nodos privados en Atlas, incluidas las limitaciones y consideraciones, consulta Obtenga más información sobre los nodos privados en Atlas. Para aprender cómo configurar nodos privados para tus clústeres, consulta Configura un nodo privado para un clúster dedicado.
Orientaciones específicas del proveedor de nube
AWS: Recomendamos el emparejamiento VPC en todos tus VPC autogestionados que necesiten conectarse a Atlas. Aproveche nodos privados globales.
Azure: Recomendamos el emparejamiento de VNet en todas sus VNets autogestionadas que necesiten conectarse a Atlas. Aproveche los nodos privados globales.
GCP: El emparejamiento no es necesario entre tus VPC autogestionadas cuando utilizas GlobalConnect. Todas las regiones de Atlas deben estar interconectadas con nodos privados a tu VPC autogestionada en cada región.
GCP Consideraciones y limitaciones de nodos privados
Se accede a los servicios de Atlas a través de los puntos finales de GCP Private Service Connect en puertos que comienzan desde 1024. Los puertos pueden cambiar en circunstancias específicas, incluyendo (pero no limitándose a) cambios en el clúster.
Private Service Connect de GCP debe estar activo en todas las regiones en las que implementes un clúster multiregional. Recibirás un error si Private Service Connect de GCP está activo en algunas, pero no en todas, las regiones de destino.
Para mantener un número manejable de cadenas de conexión almacenadas internamente que permitan a un driver conectarse a todos los nodos en un clúster multiregional, lo que se requiere para asegurar que el driver esté conectado a un nodo primario asignado dinámicamente dentro del clúster y, por lo tanto, pueda realizar todas las operaciones contra la base de datos, solo se puede hacer uno de los siguientes:
Implementar un nodo en más de una región y tener un nodo privado por región.
Ten varios nodos privados en una región y ningún otro nodo privado.
Importante
Esta limitación se aplica a todos los proveedores de nube. Por ejemplo, si crea más de un nodo privado en una sola región de GCP, no podrá crear nodos privados en AWS ni en ninguna otra región de GCP.
Para obtener más información, consulta ¿Por qué los endpoints regionalizados solo están disponibles para clústeres particionados?
En los clústeres fragmentados, el tráfico entre nodos se enruta a través de procesos mongos, que por defecto están conectados a todos los nodos dentro del clúster. Por lo tanto, puedes crear cualquier número de nodos privados en una región determinada. Consulta (Opcional) Endpoints privados regionalizados para clusters fragmentados en multiregión para obtener más información.
Puede tener hasta 40 nodos cuando implemente proyectos de Atlas que utilicen GCP Private Service Connect en varias regiones. Este total excluye las siguientes instancias:
Regiones de GCP que se comunican entre sí
Clusters gratuitos o Clusters compartidos
Los objetivos direccionables incluyen:
GCP Private Service Connect admite hasta 1024 conexiones salientes por máquina virtual. Por lo tanto, no se pueden tener más de 1024 conexiones desde una sola máquina virtual de GCP a un clúster de Atlas.
Para obtener más información, consulta la documentación de GCP nube NAT
GCP Private Service Connect es específico por región. Sin embargo, puedes configurar acceso global para acceder a nodos privados desde una región diferente.
Para aprender más, consulta Soporte Multiregión.
Listas de acceso IP
Recomendamos que configures una lista de acceso IP para tus claves API y acceso programático, de modo que permitas el acceso solo desde direcciones IP confiables, como tu pipeline de CI/CD o sistema de orquestación. Estas listas de acceso de IP se configuran en el plano de control de Atlas al aprovisionar una cuenta de servicio y son independientes de las listas de acceso de IP que se pueden configurar en el plano de datos del Proyecto de Atlas para conexiones a los clústeres.
Cuando configure su lista de acceso IP, le recomendamos que:
Utilice entradas temporales en la lista de acceso en situaciones en las que los miembros del equipo requieran acceso a su entorno desde ubicaciones de trabajo temporales o durante escenarios de emergencia, donde se necesite acceso de personas para resolver un escenario de caída en producción. Te recomendamos que crees un script de automatización para añadir rápidamente acceso temporal como preparación para estos incidentes.
Defina las entradas de la lista de acceso IP que cubran los segmentos de red más pequeños posibles. Para ello, se recomienda favorecer las direcciones IP individuales siempre que sea posible y evitar los grandes bloques CIDR.
Emparejamiento VPC/VNet
Si configura el emparejamiento de VPC o VNet, le recomendamos que:
Para mantener límites estrictos de confianza en la red, configure grupos de seguridad y ACL de red para evitar el acceso entrante a sistemas internos de la VPCde la aplicación desde la VPC del lado de Atlas.
Cree nuevas VPCspara actuar como intermediarios entre la infraestructura sensible de aplicaciones y sus VPCsde Atlas. VPCson intransitivas, lo que permite exponer solo aquellos componentes de la aplicación que necesiten acceso a Atlas.
Ejemplos de automatización: Atlas Network Security
Los siguientes ejemplos configuran conexiones entre el entorno de su aplicación y sus clústeres Atlas usando listas de acceso IP, VPC Peering y nodos privados.
Estos ejemplos también aplican otras configuraciones recomendadas, entre ellas:
El nivel de clúster se establece en
M10para un entorno de desarrollo/pruebas. Utilice la guía de tamaños de clúster para conocer el nivel de clúster recomendado para el tamaño de su aplicación.Topología de implementación de un solo set de réplicas/región con 3nodos y partición.
Nuestros ejemplos utilizan AWS, Azure y Google Cloud indistintamente. Puedes usar cualquiera de estos tres proveedores de nube, pero debes cambiar el nombre de la región para que coincida con el proveedor de nube. Para obtener información sobre los proveedores de nube y sus regiones, consulte Proveedores de nube.
Nivel de clúster establecido en
M30para una aplicación de tamaño mediano. Utiliza la guía de tamaños de clúster para conocer el nivel de clúster recomendado para el tamaño de tu aplicación.Topología de implementación de un solo set de réplicas/región con 3nodos y partición.
Nuestros ejemplos utilizan AWS, Azure y Google Cloud indistintamente. Puedes usar cualquiera de estos tres proveedores de nube, pero debes cambiar el nombre de la región para que coincida con el proveedor de nube. Para obtener información sobre los proveedores de nube y sus regiones, consulte Proveedores de nube.
Nota
Antes de que pueda configurar conexiones con la Atlas CLI, debe:
Crea tu organización pagadora y crea una clave de API para la organización pagadora.
Conéctese desde la Atlas CLI utilizando los pasos para Programmatic Use.
Crear una entrada de lista de acceso IP
Se puede ejecutar el siguiente comando para cada conexión que se desee permitir. Se pueden cambiar las entradas para usar las opciones apropiadas y los valores reales:
atlas accessList create 192.0.2.15 --type ipAddress --projectId 5e2211c17a3e5a48f5497de3 --comment "IP address for app server 2" --output json
Para más opciones de configuración e información sobre este ejemplo, consulta atlas accessLists create.
Para obtener información sobre cómo crear una entrada en la lista de acceso IP con AWS, GCP y Azure, consulta Configura un endpoint privado para un clúster dedicado
Cree una conexión de emparejamiento de VPC
Ejecuta el siguiente código para cada VPC que quieras conectar mediante emparejamiento a tu VPC de Atlas. Reemplaza aws por azure o gcp, según corresponda, y ajusta las opciones y valores a los adecuados para tu VPC o VNet:
atlas networking peering create aws --accountId 854333054055 --atlasCidrBlock 192.168.0.0/24 --region us-east-1 --routeTableCidrBlock 10.0.0.0/24 --vpcId vpc-078ac381aa90e1e63
Para obtener más opciones de configuración e información sobre este ejemplo, consulta:
atlas networking emparejamiento create aws, para VPC s de AWS
atlas networking emparejamiento create azure, para VNets de Microsoft Azure
atlas networking emparejamiento create gcp, para Google Cloud VPCs
Crear un endpoint privado
Ejecuta el siguiente comando para cada nodo privado que desees crear. Reemplace aws por azure o gcp, según corresponda, y cambie las opciones y valores por los correspondientes a su VPC o VNet:
atlas privateEndpoints aws create --region us-east-1 --projectId 5e2211c17a3e5a48f5497de3 --output json
Para obtener más opciones de configuración e información sobre este ejemplo, consulta:
atlas privateEndpoints aws create, para conexiones desde AWS VPCs
atlas privateEndpoints azure create, para conexiones de Microsoft Azure VNets
atlas privateEndpoints gcp crear, para conexiones desde GCP Private Service Connect
Nota
Antes de poder crear recursos con Terraform, debe:
Crea tu organización pagadora y crea una clave de API para la organización pagadora. Guarde su clave API como variables de entorno ejecutando el siguiente comando en el terminal:
export MONGODB_ATLAS_PUBLIC_KEY="<insert your public key here>" export MONGODB_ATLAS_PRIVATE_KEY="<insert your private key here>"
También sugerimos crear un espacio de trabajo para tu entorno.
Crear una entrada de lista de acceso IP
Para añadir una entrada a tu lista de acceso IP, crea el siguiente archivo y colócalo en el directorio del proyecto al que deseas otorgar acceso. Cambia los ID y los nombres para utilizar tus valores:
accessEntryForAddress1.tf
# Add an entry to your IP Access List resource "mongodbatlas_access_list_api_key" "address_1" { org_id = "<org-id>" ip_address = "2.3.4.5" api_key_id = "a29120e123cd" }
Después de crear los archivos, navega hasta el directorio de tu proyecto y ejecuta el siguiente comando para inicializar Terraform:
terraform init
Ejecute el siguiente comando para ver el plan de Terraform:
terraform plan
Ejecuta el siguiente comando para agregar una entrada a la lista de acceso IP para tu Proyecto. El comando utiliza el archivo y MongoDB y HashiCorp Terraform para agregar la entrada.
terraform apply
Cuando se le indique, escriba yes y presione Enter para aplicar la configuración.
Cree una conexión de emparejamiento de VPC
Para crear una conexión de emparejamiento entre la VPC de tu aplicación y la VPC de Atlas, crea el siguiente archivo y colócalo en el directorio del Proyecto al que se desea otorgar acceso. Cambia los ID y nombres para usar tus valores:
vpcConnection.tf
# Define your application VPC resource "aws_default_vpc" "default" { tags = { Name = "Default VPC" } } # Create the peering connection request resource "mongodbatlas_network_peering" "mongo_peer" { accepter_region_name = "us-east-2" project_id = local.project_id container_id = one(values(mongodbatlas_advanced_cluster.test.container_id)) provider_name = "AWS" route_table_cidr_block = "172.31.0.0/16" vpc_id = aws_default_vpc.default.id aws_account_id = local.AWS_ACCOUNT_ID } # Accept the connection resource "aws_vpc_peering_connection_accepter" "aws_peer" { vpc_peering_connection_id = mongodbatlas_network_peering.mongo_peer.connection_id auto_accept = true tags = { Side = "Accepter" } }
Después de crear el archivo, navegue a su directorio de proyecto y ejecute el siguiente comando para inicializar Terraform:
terraform init
Ejecute el siguiente comando para ver el plan de Terraform:
terraform plan
Ejecute el siguiente comando para agregar una conexión de emparejamiento VPC desde su aplicación a su proyecto. El comando utiliza el archivo y la MongoDB & HashiCorp Terraform para agregar la entrada.
terraform apply
Cuando se le indique, escriba yes y presione Enter para aplicar la configuración.
Crear un enlace privado
Para crear un PrivateLink desde la VPC de su aplicación a su VPC de Atlas, utilice uno delos siguientes módulos específicos del proveedor de nube. Cree el siguiente archivo y colóquelo en el directorio del proyecto al que desea conectarse. Modifique los ID y nombres para usar sus propios valores:
Para AWS:
privateLink.tf
module "atlas_aws" { source = "terraform-mongodbatlas-modules/atlas-aws/mongodbatlas" version = "~> 0.3" project_id = "<project-id>" privatelink_endpoints = [ { region = "<aws-region>" subnet_ids = ["<subnet-id>"] } ] }
Para Azure, utilice el módulo atlas-azure con el privatelink_endpoints atributo. Para ver ejemplos completos, consulte los ejemplos de enlaces privados de atlas-azure.
Después de crear el archivo, navegue a su directorio de proyecto y ejecute el siguiente comando para inicializar Terraform:
terraform init
Ejecute el siguiente comando para ver el plan de Terraform:
terraform plan
Ejecuta el siguiente comando para agregar un endpoint de PrivateLink desde tu aplicación a tu proyecto. El comando utiliza el archivo y MongoDB & HashiCorp Terraform para agregar la entrada.
terraform apply
Cuando se le indique, escriba yes y presione Enter para aplicar la configuración.