Cinco Configurações Críticas de Segurança do MongoDB que Você Deve Implementar Agora

Os problemas de segurança do MongoDB geralmente começam com um erro simples: um banco de dados escuta onde não deveria, aceita usuários que não deveria ou envia tráfego sem criptografia. Sua configuração do MongoDB precisa de autenticação explícita, funções restritas, exposição de rede privada, TLS e registros de auditoria úteis.

Este guia mostra cinco verificações de produção que reduzem a chance de acesso não autorizado e tornam a atividade suspeita mais fácil de investigar.

---

1. Habilite o Controle de Acesso Obrigatório e Autenticação Forte

Comece certificando-se de que a autorização está habilitada. Sem ela, um cliente que consiga alcançar o servidor pode ser capaz de ler ou alterar dados, dependendo de como a implantação foi iniciada e configurada.

Como Habilitar a Autenticação

A autenticação é normalmente habilitada através do arquivo de configuração (mongod.conf) ou sinalizadores de linha de comando durante a inicialização.

Arquivo de Configuração (/etc/mongod.conf):

# Trecho de /etc/mongod.conf
security:
  authorization: enabled

Linha de Comando:

mongod --auth --dbpath /var/lib/mongodb

Criando o Usuário Administrador

Crie o primeiro usuário administrativo antes de habilitar a autorização, ou use a exceção de localhost do MongoDB durante a configuração inicial. Após a existência do primeiro usuário, reinicie com a autorização habilitada e use contas nomeadas para todo o acesso.

Exemplo: Criando o Usuário Root via mongosh

Primeiro, conecte-se ao banco de dados (se já estiver em execução sem autenticação, ou usando a exceção de localhost):

use admin
db.createUser(
  {
    user: "mongoAdmin",
    pwd: passwordPrompt(), // Solicita a senha de forma segura
    roles: [ { role: "root", db: "admin" } ]
  }
)

Aviso: Sempre use senhas fortes armazenadas em um gerenciador de segredos. Nunca codifique credenciais sensíveis em scripts ou arquivos de configuração.

2. Implemente Controle de Acesso Baseado em Funções Granular (RBAC)

Após habilitar a autenticação, o próximo passo é estabelecer o Princípio do Menor Privilégio (PoLP). Isso significa que cada usuário, aplicativo e conta de serviço deve ter apenas as permissões mínimas necessárias para realizar suas tarefas exigidas.

Evite usar as funções root ou readWriteAnyDatabase para conexões de aplicativos. Em vez disso, defina funções personalizadas que concedam permissões específicas em bancos de dados ou coleções específicas.

Passos Práticos de RBAC

1. Defina Funções Personalizadas: Se as funções internas (read, readWrite) forem insuficientes, crie funções com ações de acesso refinadas (por exemplo, apenas insert e find em uma coleção específica).
2. Separe Usuários de Aplicativos: Crie usuários dedicados para diferentes camadas de aplicativos (por exemplo, app_rw para o backend, reporting_ro para análises).
3. Limite o Acesso de Ferramentas Externas: Garanta que as ferramentas de administração se conectem usando contas privilegiadas apenas quando absolutamente necessário.

Exemplo: Criando um Usuário Somente Leitura para um Banco de Dados Específico

use users_db
db.createUser(
  {
    user: "reporting_svc",
    pwd: passwordPrompt(),
    roles: [ { role: "read", db: "users_db" } ] // Apenas acesso de leitura ao users_db
  }
)

3. Configure Vinculação de Rede Restrita e Firewalls

A configuração de rede é a defesa perimetral do seu banco de dados. Muitas instalações empacotadas do MongoDB vinculam-se ao localhost por padrão, mas imagens de contêiner, linhas de comando personalizadas e arquivos de configuração copiados podem expor 0.0.0.0. Sempre verifique o bindIp efetivo em vez de assumir que o padrão é seguro.

Restrinja bindIp

A principal medida de segurança é definir a configuração bindIp no seu arquivo de configuração. Isso diz explicitamente ao MongoDB em quais endereços IP ou nomes de host ele deve escutar.

Arquivo de Configuração (/etc/mongod.conf):

# Lista de IPs ou nomes de host para vincular
# Use 127.0.0.1 para acesso local apenas
# Use IP(s) interno(s) para acesso apenas de servidores de aplicativos
net:
  port: 27017
  bindIp: 127.0.0.1, 10.0.1.5, localhost

Implemente Firewalls Externos (Grupos de Segurança)

Além do bindIp (que restringe o processo do MongoDB), você deve usar um firewall externo (como iptables, Grupos de Segurança da AWS ou Grupos de Segurança de Rede do Azure) para filtrar o tráfego antes que ele chegue ao servidor.

Melhor Prática: Permita apenas tráfego de entrada na porta do MongoDB (padrão 27017) de seus servidores de aplicativos, balanceadores de carga e jump boxes administrativas.

4. Imponha Criptografia para Dados em Trânsito (TLS)

Os dados transmitidos entre clientes, shells, drivers e MongoDB devem ser criptografados com Segurança da Camada de Transporte (TLS). Enviar credenciais, consultas e resultados por conexões não criptografadas expõe os dados a espionagem e ataques de intermediário.

O MongoDB suporta configuração TLS nativa tanto para tráfego criptografado quanto para validação opcional de certificado do cliente.

Habilitando TLS

Para habilitar a criptografia, você deve gerar ou obter certificados TLS válidos e especificar sua localização no arquivo de configuração.

Arquivo de Configuração (/etc/mongod.conf):

net:
  tls:
    mode: requireTLS
    # Caminho para o arquivo combinado de certificado e chave
    certificateKeyFile: /etc/ssl/mongodb.pem
    # Caminho para o arquivo da Autoridade Certificadora (para validação do cliente)
    CAFile: /etc/ssl/ca.pem

Conexão do Cliente com TLS

Assim que o servidor exigir TLS, todos os clientes devem se conectar usando os sinalizadores seguros apropriados:

mongosh "mongodb://[email protected]/admin?authSource=admin" --tls --tlsCAFile /path/to/ca.pem

Dica: Use mode: requireTLS em produção para garantir que todas as conexões estejam seguras. O modo preferTLS é geralmente usado apenas durante migração ou testes.

5. Habilite Auditoria e Monitore Logs de Atividade

Mesmo com controle de acesso e criptografia fortes, as ameaças de segurança podem surgir de contas internas comprometidas ou escalonamento de privilégios. Habilitar a auditoria abrangente fornece um registro histórico de ações, que é crucial para conformidade, análise forense e detecção de comportamento suspeito.

O recurso de auditoria do MongoDB pode registrar ações administrativas, tentativas de autenticação, falhas de autorização e operações de dados selecionadas. A disponibilidade depende da sua edição ou plataforma do MongoDB; por exemplo, a auditoria está disponível no MongoDB Enterprise e no MongoDB Atlas, enquanto implantações da Comunidade autogerenciadas precisam de outras abordagens de registro e monitoramento.

Configuração para Auditoria

A auditoria é configurada através da seção auditLog no arquivo de configuração. Você pode especificar o destino (arquivo, syslog, console) e os critérios de filtro.

Arquivo de Configuração (/etc/mongod.conf):

auditLog:
  destination: file
  path: /var/log/mongodb/audit.log
  format: JSON
  # Foco em eventos-chave de segurança, como autenticação e alterações administrativas
  filter: '{ atype: { $in: [ "authenticate", "authCheck", "createCollection", "createUser", "dropDatabase" ] } }'

Áreas Essenciais de Foco de Monitoramento

• Tentativas de Autenticação Falhas: Um pico repentino indica um potencial ataque de força bruta.
• Criação/Exclusão de Usuário/Função: Todas as alterações de privilégio devem ser registradas e revisadas.
• Exclusões de Banco de Dados ou Coleções: Alertas imediatos são necessários para operações destrutivas.

Integre os logs de auditoria do MongoDB com sistemas centralizados de gerenciamento de logs, como Splunk, Elastic Stack ou Datadog, para alertas e retenção.

Conclusão

Revise esses cinco controles durante cada implantação do MongoDB: a autorização está habilitada, os usuários do aplicativo têm funções restritas, bindIp e firewalls limitam o acesso à rede, os clientes exigem TLS e os eventos de segurança fluem para o seu sistema de monitoramento. Essas verificações não substituem backups, aplicação de patches ou rotação de segredos, mas fecham primeiro as lacunas de configuração mais comuns.