O Atlas fornece padrões de configuração de rede seguros para seus sistemas de banco de dados , como:
Criptografia de conexão TLS obrigatória
VPCs para todos os projetos com um ou mais clusters dedicados
Autenticação que utiliza listas de acesso IP e aceita apenas conexões de banco de dados de fontes que você declara explicitamente
Você pode configurar ainda mais essas proteções para atender às suas necessidades e preferências exclusivas de segurança.
Use as recomendações desta página para planejar a configuração de segurança de rede dos seus clusters.
Observação
O Modelo de responsabilidade compartilhada do MongoDB Atlas define os direitos complementares do MongoDB e de seus clientes em manter um ambiente de dados seguro e resiliente. Nesse framework, o MongoDB gerencia a segurança e a integridade operacional da plataforma subjacente, enquanto os clientes são responsáveis pelas políticas de configuração, gerenciamento e dados de suas implantações específicas. Para obter uma análise detalhada da propriedade em segurança e segurança operacional, consulte Modelo de responsabilidade compartilhada.
Recursos do Atlas Network Security
O Atlas força a criptografia TLS para todas as conexões com seus bancos de dados.
Recomendamos o uso de clusters dedicados M10+ porque todos os projetos do Atlas com um ou mais clusters dedicados M10+ recebem sua própria instância dedicada:
VPC na AWS ou no Google Cloud.
VNet no Azure.
O Atlas implementa todos os clusters dedicados dentro deste VPC ou VNet.
Por padrão, todo acesso aos seus clusters é bloqueado. Você deve permitir explicitamente uma conexão de entrada por um dos seguintes métodos:
Adicione endpoints privados, que o Atlas adiciona automaticamente à sua lista de acesso IP. Nenhum outro acesso é adicionado automaticamente.
Use emparelhamento VPC ou VNet para adicionar endereços IP privados.
Adicionar endereços IP públicos à sua lista de acesso IP.
Você também pode usar vários métodos juntos para aumentar a segurança.
TLS
O Atlas força a criptografia TLS obrigatória das conexões com seus bancos de dados. TLS 1.2 é o protocolo padrão. Para saber mais, consulte a seção Set Minimum TLS Protocol Version de Configurar Configurações Adicionais.
Listas de acesso IP
Como administrador do Atlas, você pode:
Configurar listas de acesso IP para restringir quais endereços IP podem tentar a autenticação no seu banco de dados.
Permitir o acesso somente a partir dos endereços IP e intervalos de IP do bloco CIDR que você adicionar à sua lista de acesso IP. Recomendamos que você permita o acesso aos menores segmentos de rede possíveis, como um endereço /32 individual.
Negar o acesso de servidores de aplicativo e outros clientes aos seus clusters do Atlas se os endereços IP deles não estiverem incluídos na sua lista de acesso IP.
Configurar entradas temporárias na lista de acesso que expiram automaticamente após um período definido pelo usuário.
Configuração de firewall
Ao se conectar dos servidores de aplicação do cliente ao Atlas e passar por um firewall que bloqueia conexões de rede de saída, você também deve configurar o firewall para permitir que seus aplicativos façam conexões de saída com o tráfego TCP nos hosts do Atlas. Isso concede aos seus aplicativos acesso aos seus clusters.
Os IPs públicos do cluster Atlas permanecem inalterados na maioria dos casos de mudanças no cluster, como dimensionamento vertical, mudanças na topologia ou eventos de manutenção. No entanto, certas alterações de topologia, como a conversão de um conjunto de réplicas para um cluster fragmentado, a adição de fragmentos ou uma mudança de região exigem que você use novos endereços IP.
No caso de converter de um conjunto de réplicas para um cluster fragmentado, a falha em reconectar os clientes do aplicação pode fazer com que seu aplicação sofra interrupções de dados. Se você usar uma string de conexão de lista de sementes de DNS , seu aplicação se conectará automaticamente ao cluster fragmentado. Se você utilizar uma string de conexão padrão , deverá atualizar sua string de conexão para refletir sua nova topologia de cluster .
No caso de adicionar novos shards, a falha em reconectar os clientes do aplicação pode fazer com que seu aplicação sofra uma interrupção de dados.
Endpoints privados
Um endpoint privado facilita uma conexão unidirecional de uma VPC, que você gerencia diretamente, para a VPC do Atlas, sem permitir que o Atlas inicie uma conexão recíproca. Isso permite que você use conexões seguras com o Atlas sem estender seu limite de confiança de rede. Os seguintes endpoints privados estão disponíveis:
AWS PrivateLink, para conexões do Amazon Web Services VPCs
Link privado do Microsoft Azure , para conexões do Microsoft Azure VNets
Private Service Connect para conexões VPCs do Google Cloud
Emparelhamento de VPC/VNet
O emparelhamento de rede permite que você conecte suas próprias VPCs a uma VPC do Atlas para rotear o tráfego de forma privada e isolar seu fluxo de dados da Internet pública. O Atlas mapeia VPCs uma a uma para os projetos Atlas.
A maioria das operações executadas por uma conexão VPC é originada do seu ambiente de aplicação, minimizando a necessidade de o Atlas fazer solicitações de acesso de saída para VPCsemparelhadas. No entanto, se você configurar o Atlas para usar a autenticação LDAP, deverá habilitar o Atlas para conectar a saída ao endpoint de autenticação da sua VPC de emparelhamento pelo protocolo LDAP. Observe que a autenticação LDAP está obsoleta no Atlas com 8.0. Recomendamos que você use Federação de Identidade da Força de Trabalho e Federação de Identidade do Volume de Trabalho.
Você pode escolher seu bloco CIDR do Atlas com o assistente de emparelhamento da VPC antes de distribuir seu primeiro cluster. O bloco CIDR do Atlas VPC não deve se sobrepor ao bloco CIDR de nenhuma VPC com a qual você pretende fazer o peering. O Atlas limita o número de instâncias do MongoDB por VPC com base no bloco CIDR. Por exemplo, um projeto com um bloco CIDR de /24 é limitado ao equivalente a 27 conjuntos de réplicas de 3nós.
Recomendações para o Atlas Network Security
Implantações de região única não têm considerações únicas para a segurança de rede do Atlas.
Implantações multirregionais protegidas com pontos de extremidade privados têm as seguintes considerações únicas:
Para endpoints privados globais, o Atlas gera automaticamente um registro SRV que aponta para todos os nós do Atlas cluster. O driver do MongoDB tenta se conectar a cada registro SRV do seu aplicação. Isso permite que o driver lide com um evento de failover sem esperar pela replicação do DNS e sem exigir que você atualize a string de conexão do driver.
Para facilitar a geração automática de registros SRV para todos os nós em seu Atlas cluster, você deve estabelecer uma conexão de emparelhamento de VPC entre suas VPCs de aplicação e conectar suas VPCs de aplicação à VPC do MongoDB usando PrivateLink ou equivalente.
Você deve habilitar pontos de extremidade privados em todas as regiões onde você tem um cluster Atlas implantado.
O Google Cloud Private Service Connect é específico da região. No entanto, você pode configurar o acesso global para acessar private endpoints de uma região diferente.
Para saber mais, consulte Suporte multirregional.
Todas as Recomendações de Paradigmas de Implantação
As seguintes recomendações se aplicam a todos os paradigmas de implantação.
Endpoints privados
Recomendamos que você configure pontos de extremidade privados para todos os novos projetos de homologação e produção para limitar a extensão do limite de confiança da sua rede.
Em geral, recomendamos o uso de pontos de extremidade privados para cada projeto Atlas, pois essa abordagem fornece a segurança mais granular e facilita a carga administrativa que pode surgir do gerenciamento de listas de acesso IP e grandes blocos de endereços IP à medida que sua rede na nuvem se expande. Há um custo associado a cada ponto de extremidade. Então, você pode não precisar de pontos de extremidade privados em ambientes de desenvolvimento, mas deve utilizá‑los em ambientes de produção para limitar a extensão do limite de confiança da sua rede.
Se as VPCs ou VNets nas quais seu aplicativo está implantado não puderem ser emparelhadas entre si, possivelmente devido a uma combinação de implantações no local e na nuvem, você pode considerar um ponto de extremidade privado regional.
Com os pontos de extremidade privados regionais, você pode fazer o seguinte:
Conectar um único ponto de extremidade privado a várias VNets ou VPCs sem emparelhamento direto entre si.
Mitigar falhas parciais de região nas quais um ou mais serviços dentro de uma região falham.
Para trabalhar em rede com pontos de extremidade regionais, você deve fazer o seguinte:
Realizar verificações de integridade regulares e robustas para validar a conectividade e operações bem‑sucedidas entre o cluster e o aplicativo. Você pode usar o comando
db.runCommand("ping")para pingar seu cluster e confirmar rapidamente a conectividade, ou executarrs.conf()para obter informações detalhadas sobre cada nó no seu cluster.Usar uma string de conexão distinta para cada região.
Use o roteamento entre regiões para o Atlas para manter a disponibilidade no caso de uma desconexão do Atlas VPC.
Para saber mais sobre pontos de extremidade privados no Atlas, incluindo limitações e considerações, consulte Saiba mais sobre pontos de extremidade privados no Atlas. Para saber como configurar endpoints privados para seus clusters, consulte Configurar um endpoint privado para um cluster dedicado.
Orientações específicas do provedor de nuvem
Amazon Web Services: recomendamos o emparelhamento de VPC em todas as suas VPCs autogerenciadas que precisam se conectar ao Atlas. Aproveite os endpoints privados globais.
Azure: recomendamos o emparelhamento VNet em todas as suas VNets autogerenciadas que precisam se conectar ao Atlas. Aproveite os endpoints privados globais.
GCP: O emparelhamento não é necessário em suas VPCs autogerenciadas ao usar o GlobalConnect. Todas as regiões do Atlas devem ser conectadas em rede com endpoints privados para sua VPC autogerenciada em cada região.
GCP Considerações e limitações de private endpoints
Os serviços do Atlas são acessados por meio de pontos de extremidade do GCP Private Service Connect em portas a partir de 1024. As portas podem mudar sob circunstâncias específicas, incluindo (mas não limitadas a) alterações de cluster.
O GCP Private Service Connect deve estar ativo em todas as regiões nas quais você implementa um cluster multirregional. Você receberá um erro se o GCP Private Service Connect estiver ativo em algumas regiões segmentadas, mas não em todas.
Para manter um número gerenciável de strings de conexão armazenadas internamente que permitam que um driver se conecte a todos os nós em um cluster multirregional (o que é necessário para garantir que o driver esteja conectado a um nó primário atribuído dinamicamente dentro do cluster e possa, assim, executar todas as operações no banco de dados), você pode fazer apenas uma das seguintes opções:
Distribua nós em mais de uma região e tenha um endpoint privado por região.
Tenha vários endpoints privados em uma região e nenhum outro endpoint privado.
Importante
Esta limitação se aplica a todos os fornecedores de nuvem. Por exemplo, se você criar mais de um endpoint privado em uma única região no GCP, não poderá criar endpoints privados no Amazon Web Services ou em qualquer outra região do GCP.
Para saber mais, consulte Por que os pontos de extremidade regionalizados estão disponíveis apenas para clusters fragmentados?.
Em clusters fragmentados, o tráfego entre nós é roteado através de processos mongos, que estão conectados a todos os nós do cluster por padrão. Assim, você pode criar qualquer número de pontos de extremidade privados em uma determinada região. Consulte (Opcional) Pontos de Extremidade Privados Regionalizados para Clusters Fragmentados Multirregionais para saber mais.
Você pode ter até 40 nós ao implantar projetos do Atlas que usam o GCP Private Service Connect em várias regiões. Esse total exclui as seguintes instâncias:
Regiões GCP se comunicando umas com as outras
Clusters gratuitos ou clusters compartilhados
Os alvos endereçáveis incluem:
Cada instância em um sistema de conjunto de réplicas (clusters fragmentados excluídos).
Cada instância em um sistema de cluster fragmentado .
Cada BI connector para instâncias do Atlas em todos os clusters dedicados no projeto.
O GCP Private Service Connect permite até 1024 conexões de saída por máquina virtual. Como resultado, você não pode ter mais de 1024 conexões de uma única máquina virtual GCP para um Atlas cluster.
Para saber mais, consulte a documentação NAT de nuvem da GCP.
O GCP Private Service Connect é específico da região. No entanto, você pode configurar o acesso global para acessar endpoints privados de uma região diferente.
Para saber mais, consulte Suporte multirregional.
Listas de acesso IP
Recomendamos que você configure uma lista de acesso IP para suas chaves de API e acesso programático para permitir o acesso somente de endereços IP confiáveis, como pipeline de CI/CD ou sistema de orquestração. Essas listas de acesso IP são definidas no plano de controle do Atlas após o provisionamento de uma conta de serviço e são separadas das listas de acesso IP que podem ser definidas no plano de dados do projeto Atlas para conexões com os clusters.
Ao configurar sua lista de acesso IP, recomendamos que você:
Utilize entradas temporárias na lista de acesso em situações onde os membros da equipe necessitam acessar seu ambiente a partir de locais de trabalho temporários ou durante cenários de emergência, onde o acesso humano à produção é necessário para resolver um cenário de interrupção de produção. Recomendamos que você desenvolva um script de automação para adicionar rapidamente acesso temporário e se preparar para esses incidentes.
Defina entradas da lista de acesso IP que cubram os menores segmentos de rede possíveis. Para fazer isso, favoreça endereços IP individuais sempre que possível e evite grandes blocos CIDR.
Emparelhamento de VPC/VNet
Se você configurar o emparelhamento VPC ou VNet, recomendamos que:
Para manter limites de confiança de rede rígidos, configure grupos de segurança e ACLs de rede para evitar o acesso de entrada a sistemas dentro de suas VPCs de aplicativo a partir das VPCs do lado do Atlas.
Crie novas VPCs para atuar como intermediárias entre a infraestrutura de aplicativo sensíveis e suas VPCs do Atlas. As VPCs são intransitivas, permitindo que você exponha apenas os componentes do seu aplicativo que precisam de acesso ao Atlas.
Exemplos de Automação: Segurança de Rede do Atlas
Os exemplos a seguir configuram conexões entre seu ambiente do aplicação e seus clusters Atlas usando listas de acesso IP, emparelhamento deVPC e endpoints privados.
Esses exemplos também incluem outras configurações recomendadas, tais como:
Camada do cluster configurada para
M10em um ambiente de desenvolvimento/teste. Use o guia de tamanho do cluster para saber qual a camada do cluster recomendada para o tamanho do seu aplicativo.Região única, 3-Conjunto de réplicas de nós/Topologia de implantação de fragmento.
Nossos exemplos usam Amazon Web Services, Azure e Google Cloud Platform de forma intercambiável. Você pode usar qualquer um desses três provedores de nuvem, mas deve alterar o nome da região para corresponder ao provedor de nuvem. Para saber mais sobre os fornecedores de nuvem e suas regiões, consulte Fornecedores de nuvem.
Camada do cluster definida como
M30para um aplicativo de porte médio. Use o guia de tamanho do cluster para saber qual a camada do cluster recomendada para o tamanho do seu aplicativo.Região única, 3-Conjunto de réplicas de nós/Topologia de implantação de fragmento.
Nossos exemplos usam Amazon Web Services, Azure e Google Cloud Platform de forma intercambiável. Você pode usar qualquer um desses três provedores de nuvem, mas deve alterar o nome da região para corresponder ao provedor de nuvem. Para saber mais sobre os fornecedores de nuvem e suas regiões, consulte Fornecedores de nuvem.
Observação
Antes de configurar conexões com o Atlas CLI, você deve:
Crie sua organização pagadora e crie uma chave de API para a organização pagadora.
Conecte a partir do Atlas CLI utilizando as etapas Programmatic Use para.
Criar uma entrada de lista de acesso IP
Execute o seguinte comando para cada conexão que você deseja permitir. Altere as entradas para utilizar as opções adequadas e os seus valores reais:
atlas accessList create 192.0.2.15 --type ipAddress --projectId 5e2211c17a3e5a48f5497de3 --comment "IP address for app server 2" --output json
Para mais opções de configuração e informações sobre este exemplo, consulte atlas accessLists create.
Para obter informações sobre como criar uma entrada de lista de acesso IP com Amazon Web Services, GCP e Azure, consulte Configurar um endpoint privado para um cluster dedicado
Criar uma conexão de emparelhamento VPC
Execute o código a seguir para cada VPC que você deseja emparelhar com o Atlas VPC. Substitua aws por azure ou gcp conforme apropriado, e altere as opções e valores para os apropriados para sua VPC ou 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 obter mais opções de configuração e informações sobre este exemplo, consulte:
atlas networking peering cria Amazon Web Services, para Amazon Web Services VPCs
atlas networking peering create Azure, for Microsoft Azure VNets
criar emparelhamento atlas de rede gcp, para VPCs do Google Cloud
Criar um endpoint privado
Execute o comando a seguir para cada endpoint privado que você deseja criar. Substitua aws por azure ou gcp conforme apropriado e altere as opções e valores para os apropriados para sua VPC ou VNet:
atlas privateEndpoints aws create --region us-east-1 --projectId 5e2211c17a3e5a48f5497de3 --output json
Para obter mais opções de configuração e informações sobre este exemplo, consulte:
atlas privateEndpoints criação do Amazon Web Services, para conexões do Amazon Web Services VPCs
atlas privateEndpoints azure create, para conexões de VNets do Microsoft Azure
atlas privateEndpoints gcp create, para conexões do GCP Private Service Connect
Observação
Antes de criar recursos com o Terraform, você deve:
Crie sua organização pagadora e uma chave de API para a organização pagadora. Armazene sua chave de API como variáveis de ambiente ao executar o seguinte comando no terminal:
export MONGODB_ATLAS_PUBLIC_KEY="<insert your public key here>" export MONGODB_ATLAS_PRIVATE_KEY="<insert your private key here>"
Também sugerimos criar um espaço de trabalho para seu ambiente.
Criar uma entrada de lista de acesso IP
Para adicionar uma entrada à sua lista de acesso IP, crie o seguinte arquivo e coloque-o no diretório do projeto ao qual deseja conceder acesso. Altere os IDs e nomes para usar seus 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" }
Depois de criar os arquivos, navegue até o diretório do seu projeto e execute o seguinte comando para inicializar o Terraform:
terraform init
Execute o seguinte comando para visualizar o Terraform plan:
terraform plan
Execute o comando a seguir para adicionar uma entrada à lista de acesso IP do seu projeto. O comando usa o arquivo e o Terraform MongoDB e HashiCorp para adicionar a entrada.
terraform apply
Quando solicitado, digite yes e pressione Enter para aplicar a configuração.
Criar uma conexão de emparelhamento VPC
Para criar uma conexão de emparelhamento entre seu aplicação VPC e seu Atlas VPC, crie o seguinte arquivo e coloque-o no diretório do projeto ao qual você deseja conceder acesso. Altere os IDs e nomes para usar seus 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" } }
Depois de criar o arquivo, navegue até o diretório do projeto e execute o seguinte comando para inicializar o Terraform:
terraform init
Execute o seguinte comando para visualizar o Terraform plan:
terraform plan
Execute o comando a seguir para adicionar uma conexão de emparelhamento VPC do seu aplicação ao seu projeto. O comando usa o arquivo e o Terraform MongoDB e HashiCorp para adicionar a entrada.
terraform apply
Quando solicitado, digite yes e pressione Enter para aplicar a configuração.
Criar um PrivateLink
Para criar um PrivateLink do seu aplicativo VPC para o seu Atlas VPC, use um dos seguintes módulos específicos do provedor de nuvem. Crie o seguinte arquivo e coloque-o no diretório do projeto ao qual deseja se conectar. Altere os IDs e nomes para usar seus valores:
For Amazon Web Services:
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 o Azure, utilize o módulo atlas-azure com o atributo privatelink_endpoints. Para obter exemplos completos, consulte exemplos de privatelink do atlas-azure.
Depois de criar o arquivo, navegue até o diretório do projeto e execute o seguinte comando para inicializar o Terraform:
terraform init
Execute o seguinte comando para visualizar o Terraform plan:
terraform plan
Execute o seguinte comando para adicionar um ponto de extremidade PrivateLink do seu aplicativo ao seu projeto. O comando utiliza o arquivo e o MongoDB & HashiCorp Terraform para adicionar a entrada.
terraform apply
Quando solicitado, digite yes e pressione Enter para aplicar a configuração.