Criptografia em repouso e TLS em trânsito

Proteger os dados do MongoDB exige proteção em dois pontos distintos: criptografia em trânsito (dados que se movem entre clientes e o MongoDB ou entre membros de um conjunto de réplicas) e criptografia em repouso (dados armazenados no disco). A autenticação controla quem pode se conectar, mas até mesmo um usuário autenticado operando por uma conexão não criptografada expõe credenciais e consultas à interceptação de rede. Juntos, o TLS e a criptografia em repouso fornecem defesa em profundidade.

TLS (Transport Layer Security) criptografa o canal de rede entre clientes do MongoDB, controladores e instâncias mongod/mongos. Ativar o TLS impede a espionagem e os ataques do tipo intermediário durante a transmissão. O MongoDB 4.2 ou posterior oferece suporte somente ao TLS 1.1 e versões posteriores, com TLS 1.3 disponível em plataformas modernas. Use sempre o TLS em qualquer ambiente em que o tráfego de rede possa ser interceptado — isso inclui VPCs na nuvem, apesar do isolamento no nível da VPC.

O TLS é configurado na seção net.tls do arquivo mongod.conf. Defina mode: requireTLS para rejeitar todas as conexões não criptografadas. É necessário fornecer um arquivo PEM contendo o certificado e a chave privada do servidor. Opcionalmente, forneça um CAFile para exigir que os clientes apresentem certificados assinados pela sua CA (TLS mútuo).

O controlador oficial do MongoDB para Node.js habilita o TLS quando o URI de conexão usa mongodb+srv:// (o Atlas sempre usa TLS) ou quando a opção tls: true é definida. Em implantações auto-hospedadas, talvez seja necessário fornecer o caminho do arquivo da CA para que o controlador possa verificar o certificado do servidor. Use variáveis de ambiente para os caminhos dos certificados, para que eles não sejam codificados diretamente no código-fonte.

O MongoDB oferece quatro modos de TLS durante as fases de migração. disabled aceita apenas conexões sem TLS (somente para desenvolvimento). allowTLS aceita conexões com TLS e sem TLS (para compatibilidade com versões anteriores). preferTLS usa TLS por padrão, mas aceita conexões não criptografadas. requireTLS rejeita todas as conexões sem TLS e é o único modo aceitável em implantações de produção.

O mecanismo de armazenamento padrão do MongoDB, WiredTiger, é compatível com o mecanismo de armazenamento criptografado (disponível no MongoDB Enterprise). Ele criptografa os arquivos de dados no disco usando AES-256-CBC ou AES-256-GCM. Mesmo que um invasor obtenha acesso ao disco físico ou a um instantâneo do disco, não poderá ler os dados sem a chave de criptografia. Isso atende a requisitos de conformidade, como GDPR, HIPAA e PCI-DSS, que determinam a proteção de dados em repouso.

O MongoDB Atlas oferece criptografia em repouso usando o gerenciamento de chaves do provedor de nuvem: AWS KMS, Azure Key Vault ou Google Cloud KMS. Os clientes podem trazer sua própria Customer Master Key (CMK), obtendo controle total — se você excluir sua CMK, o Atlas não poderá descriptografar seus dados. A criptografia em repouso do Atlas é habilitada por projeto nas configurações de segurança e se aplica a todos os clusters desse projeto.

A criptografia só é tão forte quanto a segurança de suas chaves. Siga estas práticas recomendadas para o gerenciamento de chaves: armazene as chaves de criptografia em um serviço dedicado de gerenciamento de chaves (KMS), em vez de armazená-las no mesmo servidor que o banco de dados; alterne as chaves de criptografia regularmente (o MongoDB permite alternar as chaves sem criptografar novamente todos os dados); use chaves separadas para desenvolvimento, preparação e produção; e habilite os registros de auditoria do KMS para acompanhar todos os eventos de acesso às chaves.

Os certificados TLS expiram, normalmente após 1–2 anos. O MongoDB permite a alternância de certificados online: você pode implantar um novo arquivo PEM e enviar o comando rotateCertificates ao mongod, que usará o novo certificado para todas as novas conexões sem reiniciar o processo. Planeje a renovação do certificado pelo menos 30 dias antes da expiração para evitar correria de última hora e indisponibilidade em produção.

O TLS e a criptografia em repouso protegem os dados em trânsito e no disco, mas os controles no nível da rede acrescentam outra camada. No MongoDB Atlas, use entradas da lista de acesso de IP para permitir somente os servidores da sua aplicação e os IPs dos desenvolvedores. Em produção, use emparelhamento de VPC ou AWS PrivateLink para que o tráfego entre sua aplicação e o Atlas nunca atravesse a internet pública, eliminando uma grande categoria de ataques baseados em rede antes mesmo que o TLS seja considerado.

Depois de habilitar o TLS, verifique se todas as conexões estão criptografadas consultando connPoolStats ou o registro de conexões do MongoDB. O MongoDB registra falhas no handshake TLS, permitindo identificar qualquer cliente antigo que ainda esteja tentando estabelecer conexões em texto simples. No Atlas, a aba Monitoramento mostra as conexões ativas e o status do TLS, facilitando a confirmação da aplicação completa da política antes de remover o modo allowTLS.

Nesta lição, você aprendeu que requireTLS em mongod.conf impõe conexões criptografadas dos clientes e deve ser o único modo usado em produção; o mecanismo de armazenamento criptografado WiredTiger protege os arquivos de dados no disco (Enterprise), enquanto o Atlas oferece criptografia na nuvem baseada em CMK; e controles no nível da rede, como listas de permissões de IP e emparelhamento de VPC, acrescentam camadas de proteção além do TLS. A seguir, abordaremos a criptografia de campos no lado do cliente.