Join us Sept 17 at .local NYC! Use code WEB50 to save 50% on tickets. Learn more >
MongoDB Event
Menu Docs
Página inicial do Docs
/ /
Centro de Arquitetura Atlas
/

Orientações para segurança de rede do Atlas

O Atlas fornece padrões de configuração de rede seguros para seus sistemas de banco de dados , como:

  • Criptografia obrigatória de conexão TLS/SSL

  • 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.

O Atlas impõe a criptografia TLS/SSL para todas as conexões com seus bancos de dados.

Recomendamos o uso de clusters dedicados M10+, pois todos os projetos Atlas com um ou mais clusters dedicados M10+ recebem seu próprio dedicado:

  • 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.

O Atlas impõe a criptografia TLS obrigatória das conexões com seus bancos de dados. TLS 1,2 é o protocolo padrão. Para aprender mais, consulte a seção Set Minimum TLS Protocol Version de Definir configurações adicionais.

Como administrador do Atlas, você pode:

Configure listas de acesso IP para limitar quais endereços IP podem tentar autenticar em 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.

Negue a servidores de aplicação e outros clientes acesso aos seus clusters Atlas se seus endereços IP não estiverem incluídos em sua lista de acesso IP.

Configure entradas de lista de acesso temporárias que expiram automaticamente após um período definido pelo usuário.

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 mongos para o 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.

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:

" Uma imagem representando como os endpoints privados do MongoDB Atlas funcionam."
clique para ampliar

O emparelhamento de rede permite que você conecte suas próprias VPCs a uma VPC Atlas para rotear o tráfego de forma privada e isolar seu fluxo de dados da Internet pública. O Atlas mapeia os projetos um a um do VPC para o 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. Note que a autenticação LDAP é preterida no Atlas 8 0com.. Recomendamos que você use a Federação de Identidade da Força de Trabalho e a 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.

" Uma imagem representando como o emparelhamento VPC/VNet do MongoDB Atlas funciona."
clique para ampliar

Recomendações que se aplicam apenas a sistemas em uma única região

As implantações de região única não têm considerações exclusivas para a segurança de rede do Atlas .

Recomendações que se aplicam apenas a implementações em várias regiões ou vários fornecedores de nuvem

As implantações de várias regiões protegidas com endpoints privados têm as seguintes considerações exclusivas:

  • 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 VPCsde aplicação e conectar suas VPCs de aplicação à VPC do MongoDB usando PrivateLink ou equivalente.

  • Você deve habilitar endpoints privados em todas as regiões em que você tem um Atlas cluster distribuído.

  • O Google Cloud Private Service Connect é específico da região. No entanto, você pode configurar o acesso global para acessar pontos de extremidade privados de uma região diferente.

    Para saber mais, consulte Suporte multirregional.

As recomendações a seguir se aplicam a todos os paradigmas de implantação do.

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 endpoints privados para cada projeto do Atlas , pois essa abordagem fornece a segurança mais granular e facilita a carga administrativa que pode resultar do gerenciamento de listas de acesso IP e grandes blocos de endereços IP à medida que a rede na nuvem é dimensionada. Há um custo associado a cada endpoint. Portanto, talvez você não precise de endpoints privados em ambientes inferiores, mas deve aproveitá-los em ambientes superiores para limitar a extensão do limite de confiança da rede.

Se as VPCs ou VNets nas quais seu aplicação está distribuído não puderem ser emparelhadas entre si, potencialmente devido a uma combinação de sistemas locais e na nuvem, convém considerar um endpoint privado regional.

Com endpoints privados regionais, você pode fazer o seguinte:

  • Conecte um único endpoint privado a várias VNets ou VPCs sem emparelhá-los diretamente uns aos outros.

  • Mitigar falhas parciais na região nas quais um ou mais serviços dentro de uma região falham.

Para rede com endpoints regionais, você deve fazer o seguinte:

  • Realize verificações de integridade regulares e robustas para ajudar a validar a conectividade e as operações bem-sucedidas entre o cluster e o aplicação. Você pode ping de seu cluster com o comando db.runCommand("ping") para confirmar a conectividade rapidamente ou pode executar rs.conf() para obter informações detalhadas sobre cada nó em seu cluster.

  • Use 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.

  • AWS: 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.

Os serviços do Atlas são acessados por meio de endpoints do GCP Private Service Connect nas portas 27015 a 27017. As portas podem mudar em circunstâncias específicas, incluindo (sem limitações) mudanças 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 connection strings armazenadas internamente que permita 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ó primary atribuído dinamicamente dentro do cluster e possa portanto, execute todas as operações no banco de dados, você pode fazer apenas um dos seguintes:

    • 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 na AWS ou em qualquer outra região do GCP.

    Para saber mais, consulte Por que os endpoints regionalizados estão disponíveis somente para clusters fragmentados?.

    Em clusters fragmentados, o tráfego entre nós é roteado por meio de processos mongos, que são conectados a todos os nós dentro do cluster por padrão. Dessa forma, você pode criar qualquer número de endpoints privados em uma determinada região.Consulte (Opcional) Endpoints privados regionalizados para clusters fragmentados em várias regiões para saber mais.

  • O Atlas cria anexos de serviço 50, cada um com um valor de máscara de sub-rede de 27. Você pode alterar o número de anexos de serviço e as máscaras de sub-rede que o Atlas cria, definindo os seguintes limites com o ponto de extremidade da API de administração do Atlas Definir um limite de projeto:

    • Defina o limite atlas.project.deployment.privateServiceConnectionsPerRegionGroup para alterar o número de anexos de serviço.

    • Defina o limite atlas.project.deployment.privateServiceConnectionsSubnetMask para alterar a máscara de sub-rede para cada anexo de serviço.

    Para saber mais, consulte Definir um limite de projeto.

  • Você pode ter até 50 nós ao criar projetos do Atlas que usam o GCP Private Service Connect em uma única região. Se você precisar alterar o número de nós, execute uma das seguintes ações:

    • Remova os pontos de extremidade privados existentes e, em seguida, altere o limite usando o ponto de extremidade da API de administração do Atlas Definir um limite de projeto.

    • Entre em contato com o suporte MongoDB .

    • Use projetos ou regiões adicionais para se conectar a nós além deste limite.

Importante

  • Cada endpoint privado no GCP reserva um endereço IP na VPC do GCP e encaminha o tráfego dos endereços IP dos endpoints para os acessórios de serviço. Você deve criar um número igual de endpoints privados para o número de acessórios de serviço. O número de anexos de serviço é padronizado 50 como.

Os alvos endereçáveis incluem:

  • Cada instância mongod em uma implantação de conjunto de réplicas (clusters fragmentados excluídos).

  • Cada instância mongos em uma implantação de cluster fragmentado.

  • Cada BI connector para instâncias do Atlas em todos os clusters dedicados no projeto.

  • Você pode ter até 40 nós ao criar projetos do Atlas que usam o GCP Private Service Connect em várias regiões. Esse total exclui as seguintes instâncias:

    • RegiõesGCP se comunicando umas com as outras

    • Clusters gratuitos ou clusters compartilhados

  • OGCP 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 do GCP para um Atlas cluster.

    Para saber mais, consulte a documentação NAT de nuvem da GCP.

  • OGCP 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.

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 de lista de acesso IP cobrindo os menores segmentos de rede possíveis. Para fazer isso, privilegie endereços IP individuais sempre que possível e evite grandes blocos CIDR.

Se você configurar o emparelhamento VPC ou VNet, recomendamos que:

  • Para manter limites rígidos de confiança na rede, configure grupos de segurança e ACLs de rede para impedir o acesso de entrada a sistemas dentro das VPCsde aplicação a partir da VPC do lado do Atlas.

  • Crie novos VPCs para atuar como intermediários entre a infraestrutura de aplicação sensíveis e seus Atlas VPCs. As VPCssão transitivas, permitindo que você exponha apenas os componentes do seu aplicação que precisam de acesso ao Atlas.

Os exemplos a seguir configuram conexões entre seu ambiente do aplicação e seus clusters Atlas usando listas de acesso IP, emparelhamento de VPC e endpoints privados.

Esses exemplos também incluem outras configurações recomendadas, tais como:

  • Camada do cluster configurada para M10 em 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 utilizam AWS, Azure e Google Cloud indistintamente. Você pode usar qualquer um desses três provedores de nuvem, mas deve alterar o nome da região para corresponder à do provedor de nuvem. Para saber mais sobre os provedores de nuvem e as respectivas regiões, consulte Provedores de nuvem.

  • Camada do cluster definida como M30 para 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 utilizam AWS, Azure e Google Cloud indistintamente. Você pode usar qualquer um desses três provedores de nuvem, mas deve alterar o nome da região para corresponder à do provedor de nuvem. Para saber mais sobre os provedores de nuvem e as respectivas regiões, consulte Provedores de nuvem.

Observação

Antes de configurar conexões com o Atlas CLI, você deve:

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 na lista de acesso IP com AWS, GCP e Azure, consulte Configurar um ponto de extremidade privado para um cluster dedicado

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:

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:

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>"
  • Instalar o Terraform

Sugerimos também a criação de um espaço de trabalho para o seu ambiente.

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:

# 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.

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:

# 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 seguinte comando para adicionar uma conexão de emparelhamento VPC 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.

Para criar um PrivateLink do seu aplicação VPC para o seu Atlas VPC, 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:

resource "mongodbatlas_privatelink_endpoint" "test" {
project_id = "<project-id>"
provider_name = "AWS/AZURE"
region = "US_EAST_1"
timeouts {
create = "30m"
delete = "20m"
}
}

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.

Voltar

Segurança

Nesta página