Segurança no MongoDB 101: recursos essenciais que todo desenvolvedor deve conhecer

O MongoDB oferece uma estrutura de segurança completa baseada em três princípios: autenticação, autorização e criptografia.

Esses pilares compõem uma defesa em camadas, garantindo que uma falha não comprometa todo o sistema. A autorização segue o princípio do menor privilégio (PoLP), assegurando que cada usuário ou aplicação tenha apenas as permissões mínimas necessárias para executar suas tarefas. 

Aplicar essa abordagem abrangente e em camadas fortalece sua postura de segurança e reduz significativamente a exposição a erros de configuração ou violações. 

Abrindo o primeiro portão: autenticação

A autenticação é o passo de segurança fundamental. Ela verifica a identidade de todo principal que tenta se conectar. No MongoDB, isso é feito ativando recursos de segurança que, por conveniência no desenvolvimento local, vêm desativados por padrão.

1. Entendendo a configuração padrão

Por padrão, sua implantação do MongoDB escuta apenas no localhost e permite acesso sem autenticação. Essa configuração é intencional para facilitar ao máximo a configuração inicial e a experimentação local.

Para qualquer ambiente de produção, duas definições exigem atenção dos desenvolvedores:

• Estado da autenticação: a autenticação vem desativada por padrão. Você pode habilitar a autorização usando --auth ou a opção security.authorization. Ativar a autenticação interna também habilita a autorização de clientes. Atenção: depois que o controle de acesso estiver ativo, os usuários precisam se autenticar.
• Vinculação de rede (bindIp): Por padrão, os binários do MongoDB (mongod e mongos) vinculam apenas ao localhost. Esse padrão seguro limita conexões à mesma máquina. Em produção, você deve configurar explicitamente a opção bindIp para listar os endereços IP dos seus servidores de aplicação autorizados. Se precisar de suporte a IPv6, defina a opção de configuração net.ipv6 no arquivo ou use a opção de linha de comando --ipv6, o que fará o binário também vincular ao endereço IPv6 de localhost. Sempre restrinja isso às interfaces de rede autorizadas.

2. Como habilitar a autenticação

Ativar a autenticação transforma o MongoDB de um playground local em um repositório de dados seguro. Isso é feito alterando o arquivo de configuração do MongoDB (geralmente mongod.conf) e reiniciando o servidor.

Definição no arquivo de configuração: defina a opção de autorização na seção security para habilitar o recurso:

  authorization: enabled

O primeiro usuário: assim que a autenticação é ativada, ninguém consegue se conectar até que você crie um usuário administrativo. Esse primeiro usuário, crítico, deve ser criado no banco de dados admin, concedendo os direitos iniciais para gerenciar o sistema e criar outros usuários.

3. Gestão de usuários e senhas (createUser)

Depois de habilitar a autorização, todo acesso ao banco é regido por usuários e seus respectivos papéis. Você usa o comando createUser para definir essas identidades.

Sintaxe e papéis: ao criar um usuário, você informa nome, senha e um array de roles. Os papéis definem as permissões (por exemplo, readWrite em um banco específico).

db.createUser(
   {
     user: "appUser",
     pwd: passwordPrompt(),  // Esta função solicita a senha,
                                              // evitando armazenar a senha em texto puro
                                              // no histórico do shell e em logs de comando.
     roles: [ { role: "readWrite", db: "inventory" } ]
   }
)

Padrão SCRAM: o MongoDB utiliza o Salted Challenge Response Authentication Mechanism (SCRAM) para tratar senhas com segurança. O SCRAM evita armazenar senhas em texto puro e usa hashing e salting criptograficamente fortes, tornando-o resistente a vetores comuns de ataque, como tabelas arco-íris.

4. Opções avançadas de autenticação

Para organizações com requisitos rígidos de conformidade ou infraestrutura complexa, o MongoDB permite integração com sistemas corporativos de autenticação já existentes:

• Certificados de cliente x.509: permitem que clientes se autentiquem com certificados digitais em vez de senhas, oferecendo uma camada robusta de verificação de identidade, muito usada para confiança entre máquinas.
• LDAP/Kerberos: integra o MongoDB a serviços externos como Active Directory ou OpenLDAP, permitindo que usuários aproveitem suas credenciais corporativas para acessar o banco.
• Autenticação OpenID Connect (OIDC) - Workforce e Workloads: para ambientes modernos cloud-native e híbridos, o MongoDB oferece Federação de Identidade tanto para Workforce (acesso de usuários via IdPs como Azure AD, Okta) quanto para Workload (autenticação entre serviços usando identidade do provedor de nuvem, como AWS IAM ou Google Cloud Service Accounts).

Autorização: definindo papéis com RBAC

A autenticação confirma quem é o usuário; a autorização determina o que esse usuário pode fazer. O sistema de controle de acesso baseado em função (RBAC) do MongoDB é o mecanismo central para gerenciar permissões, garantindo que usuários e serviços interajam apenas com os dados e comandos estritamente necessários.

1. Controle de acesso baseado em função

No modelo RBAC do MongoDB, permissões são agrupadas em funções (roles), e essas funções são atribuídas a usuários. Em vez de conceder centenas de permissões individuais, você atribui um único papel (por exemplo, inventoryReader), que já inclui o conjunto definido de permissões (por exemplo, leitura em inventory.products). Isso torna a gestão de permissões escalável e auditável.

2. Papéis nativos que todo desenvolvedor precisa conhecer

O MongoDB fornece um conjunto robusto de papéis nativos (built-in) que cobrem os padrões de acesso mais comuns. Abaixo, alguns exemplos. Para a lista completa, consulte o link acima.

• read e readWrite (acesso por banco de dados): são os papéis mais comuns para usuários de aplicação. Concedem acesso para executar operações somente leitura ou leitura/gravação, respectivamente, em todas as coleções não-sistema dentro de um banco especificado.
• dbAdmin: concede direitos administrativos necessários para gerenciar um banco específico, como criar, remover e modificar índices e coleções. É adequado para times de desenvolvimento ou scripts de manutenção de banco.
• clusterAdmin (acesso operacional): papel de alto privilégio geralmente reservado para equipes de operações (DevOps/Ops). Concede permissões para gerenciar toda a implantação do MongoDB, incluindo configuração de replica sets, sharding e execução de backups. Desenvolvedores de aplicação raramente precisam desse papel.

3. Implementando o princípio do menor privilégio

A pedra fundamental da segurança moderna em bancos de dados é o princípio do menor privilégio (PoLP). Ele dita que todo usuário (especialmente usuários de aplicação) deve receber apenas as permissões mínimas necessárias para executar suas tarefas — e nada além disso.

Exemplo de boa prática: em vez de usar um usuário readWrite global, crie usuários específicos por aplicação. Por exemplo, se seu serviço de inventário interage apenas com o banco app_data, conceda ao usuário da aplicação acesso readWrite apenas a esse banco. Essa compartimentalização impede que um serviço comprometido acesse indevidamente outros bancos (como billing ou users).

Exemplo de código: criando um usuário com menor privilégio

Este exemplo cria um usuário (inventory_service) com acesso de leitura/gravação estritamente limitado ao banco app_data.

use admin
db.createUser(
   {
     user: "inventory_service",
     pwd: passwordPrompt(),
     roles: [ 
       { role: "readWrite", db: "app_data" }
     ]
   }
)

4. Criando papéis personalizados (quando os nativos não bastam)

Embora os papéis nativos sejam poderosos, requisitos de conformidade ou lógicas complexas podem exigir controle mais granular. Nesses casos, o MongoDB permite definir papéis personalizados usando o comando db.createRole().

Definindo permissões granulares: papéis personalizados permitem especificar exatamente quais ações de privilégio (por exemplo, find, update, insert) podem ser executadas em recursos com escopo de cluster, banco ou coleção. Organizações podem aplicar técnicas como redação em nível de campo para proteger campos altamente sensíveis dentro de uma coleção pública.

Exemplo de código: criando um papel personalizado

Este exemplo cria um papel personalizado (product_creator) que pode apenas inserir documentos na coleção products do banco app_data.

use app_data
db.createRole(
   {
     role: "product_creator",
     privileges: [
       {
         resource: { db: "app_data", collection: "products" },
         actions: [ "insert" ]
       }
     ],
     roles: []
   }
)

Proteção de dados completa: isolamento de rede e criptografia

Enquanto autenticação e autorização fortes controlam o acesso ao banco, uma segurança abrangente exige proteger os dados em si — tanto em trânsito (na rede) quanto em repouso (no disco).

1. Protegendo dados em trânsito com TLS/SSL

Toda transmissão de dados, seja na rede interna do data center ou na nuvem, deve ser criptografada para evitar escuta e ataques man-in-the-middle (MITM). O MongoDB usa Transport Layer Security/Secure Sockets Layer (TLS/SSL) para criptografar todas as comunicações entre clientes (como sua aplicação) e o servidor.

Sem TLS/SSL, credenciais, parâmetros de consulta e resultados sensíveis trafegam em texto puro, fáceis de interceptar. Ativar TLS/SSL assegura que os dados sejam embaralhados e protegidos durante a transmissão.

Habilitando TLS/SSL: isso é feito principalmente via configurações, especificando os certificados que o servidor deve usar para verificação de identidade e troca de chaves:

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem

• net.ssl.mode: requireTLS força todas as conexões a usarem TLS/SSL, rejeitando tentativas inseguras.
• certificateKeyFile aponta para o seu certificado TLS/SSL gerado e, quando aplicável, para o arquivo da autoridade certificadora.

2. Firewall e segmentação de rede

A segmentação de rede adiciona uma camada essencial de defesa ao limitar as interfaces físicas ou virtuais que podem se conectar ao banco. Mesmo que um invasor obtenha acesso à rede, ainda precisará atravessar o seu perímetro.

• Restringindo acesso via lista de IPs permitidos (whitelist): usando a opção bindIp ou configurando firewalls, você pode permitir apenas IPs específicos.
• Boa prática: o servidor do MongoDB deve ficar exposto apenas para seus servidores de aplicação, balanceador de carga ou camada de proxy. Ele nunca deve estar acessível diretamente pela internet pública. Essa segmentação mantém o banco protegido atrás do perímetro de segurança da infraestrutura da aplicação.

3. Criptografia em repouso (no mecanismo de armazenamento)

Proteger dados em repouso garante que, se o disco físico ou o host forem comprometidos, os arquivos permaneçam ilegíveis. O MongoDB faz isso com criptografia no mecanismo de armazenamento.

• Como funciona: o mecanismo de armazenamento WiredTiger pode ser configurado para criptografar todos os arquivos de dados, de configuração e de journal no disco. Os dados são criptografados de forma transparente ao serem escritos e descriptografados ao serem lidos, usando uma chave de criptografia gerenciada pelo sistema.
• Ponto crucial: embora seja uma camada crítica, a criptografia nativa em repouso é tipicamente um recurso da edição MongoDB Enterprise e depende de servidores KMIP (Key Management Interoperability Protocol) externos ou arquivos de chaves locais para gestão das chaves.

4. Client-Side Field Level Encryption (CSFLE): o padrão de ouro para desenvolvedores

Enquanto a criptografia em repouso protege todo o banco, a Client-Side Field Level Encryption (CSFLE) dá ao desenvolvedor precisão cirúrgica sobre dados sensíveis, permitindo criptografar campos específicos antes de enviá-los ao banco.

• Apresentando a CSFLE: com CSFLE, a criptografia ocorre no driver da aplicação antes de os dados saírem do servidor da aplicação. Ou seja, o servidor do MongoDB nunca vê os dados sensíveis em texto puro; ele armazena apenas o ciphertext. Os dados sensíveis permanecem criptografados o tempo todo no servidor, inclusive em memória, logs e armazenamento.
• Ferramenta mais poderosa do desenvolvedor: a CSFLE é o padrão de ouro para conformidade (por exemplo, GDPR, HIPAA), pois garante que, mesmo em caso de violação completa do banco, campos sensíveis (como PII ou dados financeiros) permaneçam criptografados e protegidos. Os desenvolvedores devem decidir ativamente o que criptografar, integrando essa lógica diretamente no código.

5. Criptografia em uso com Queryable Encryption

Queryable Encryption é uma evolução da CSFLE que resolve o desafio de consultar campos criptografados. Ela permite executar consultas de igualdade (por exemplo, buscar documentos em que um campo criptografado seja igual a um valor) diretamente sobre o ciphertext. Assim, oferece a segurança da CSFLE mantendo a utilidade dos dados — efetivamente criptografando dados em uso.

Auditoria: a ferramenta de pós-incidente

Medidas de segurança tratam de prevenção, enquanto auditoria trata de responsabilização e detecção. A estrutura de auditoria nativa do MongoDB permite rastrear e registrar eventos relevantes de segurança, criando um registro imutável essencial para forense, conformidade e detecção proativa de ameaças.

1. O que é auditoria e por que ela importa?

A auditoria registra cada ação crítica executada no banco, criando um histórico detalhado. Inclui:

• Eventos de autenticação: tentativas de login bem-sucedidas e falhas.
• Alterações de autorização: criação, modificação ou exclusão de usuários e papéis.
• Mudanças de configuração: alterações em parâmetros do sistema que afetam a segurança.

Esse log é inestimável para equipes de segurança em análises pós-incidente (a ferramenta de "pós-mortem") ou para cumprir exigências regulatórias.

2. Configuração e filtragem

Habilitar a auditoria é simples e geralmente requer uma única linha no arquivo de configuração para ativar o sistema e especificar o destino do log (arquivo, syslog ou console).

auditLog:
  destination: file
  format: BSON
  path: /var/log/mongodb/audit.bson
  filter: '{ atype: { $in: [ "authenticate", "createRole", "dropUser" ] } }'

• Filtragem: o sistema de auditoria permite filtragem altamente granular usando uma sintaxe semelhante a consultas. Isso é crucial para gerenciar o volume de logs. Desenvolvedores devem focar o filtro em eventos críticos de segurança, como gestão de usuários, mudanças de configuração de segurança e tentativas de autenticação.

Resumo e próximos passos

O MongoDB oferece um conjunto completo de recursos de segurança que, quando bem implementados, criam uma estratégia poderosa de defesa em profundidade. Sua principal tarefa como desenvolvedor é ir além dos padrões de desenvolvimento e aplicar esses controles essenciais.

Antes de levar qualquer aplicação à produção, lembre-se destes três mandamentos de segurança:

• Criptografe dados em trânsito: use TLS/SSL em todas as conexões de rede (net.ssl.mode: requireTLS).
• Criptografe dados em repouso: garanta que os arquivos do banco no disco estejam protegidos usando criptografia no volume/sistema de arquivos ou a criptografia do mecanismo WiredTiger (disponível no MongoDB Enterprise) para evitar acesso não autorizado aos arquivos.
• Criptografe dados em uso: use Client-Side Field Level Encryption (CSFLE) e Queryable Encryption para campos altamente sensíveis, mantendo os dados criptografados mesmo com o banco em execução.

Segurança é uma disciplina em constante evolução. Para aprofundar e explorar configurações avançadas, use a documentação oficial:

• MongoDB Security center: explore guias de hardening de ambientes e práticas operacionais de segurança.
• Documentação de criptografia em uso: aprenda a implementar Client-Side Field Level Encryption (CSFLE) e seu recurso avançado, o Queryable Encryption (QE), para manter seus dados sensíveis confidenciais e ainda assim consultáveis de forma eficiente enquanto estão em uso.

Eu também recomendo conferir o curso Introduction to Using MongoDB for Data Science in Python.