Hardening de segurança do MongoDB (autorização, TLS, roles, audit)

Runbook por cenários para aplicar hardening a um MongoDB em execução (servidor único, replica set ou sharded cluster) sem downtime: auditoria de segurança somente leitura, autorização rolling com keyFile + transitionToAuth, custom roles e usuários com privilégio mínimo, SCRAM-SHA-256, bindIp e firewall, transição allowTLS → preferTLS → requireTLS, autenticação de membros por x.509, audit log (Enterprise/Percona) e encryption at rest; ao final a auditoria é repetida para mostrar que os riscos foram fechados. Em sistemas instalados com os guias de instalação deste site, a autorização e o keyfile já estão habilitados: comece pela auditoria e aplique apenas os cenários que apontarem RISCO. A operação do dia a dia e o backup estão em guias separados de MongoDB.

Topologia: Servidor único, replica set com 3+ membros ou sharded cluster

Cenários

• Auditoria do estado de segurança (somente leitura) — Não altera nada. Acesso sem autenticação, endereços em escuta, TLS, mecanismos de autenticação, usuários com privilégios elevados, audit e encryption at rest são reportados como OK / AVISO / RISCO. Escolha esta opção se não souber por onde começar.
• Hardening completo (tudo em ordem) — Auditoria → internal auth + authorization (sem downtime com transitionToAuth) → usuários com privilégio mínimo → SCRAM-SHA-256 → bindIp/firewall → TLS (allowTLS → preferTLS → requireTLS) → audit (Enterprise/Percona) → auditoria final. Em replica set é feito de forma rolling; cada passo arriscado pede confirmação.
• Autorização desabilitada: habilitar authorization (keyFile, sem downtime) — Qualquer um consegue se conectar sem usuário e senha. Em replica set e sharded cluster, a autorização é habilitada de forma rolling e sem downtime com keyFile + transitionToAuth; em servidor único é necessário um reinício curto.
• Usuários com privilégio mínimo e custom roles (aplicação, backup, monitoramento) — As aplicações se conectam com root ou com uma conta de administrador compartilhada. É criada uma custom role que concede à aplicação apenas as operações necessárias no próprio banco de dados, além de usuários separados para backup e monitoramento; mostra-se também como guardar as senhas com segurança no lado do cron/da aplicação.
• Desabilitar SCRAM-SHA-1, somente SCRAM-SHA-256 — As credenciais de usuários antigos estão armazenadas com SHA-1, ou a auditoria encontrou SCRAM-SHA-1 habilitado. Os usuários são migrados para SHA-256 e, em seguida, authenticationMechanisms é restringido com um reinício rolling.
• Restringir o acesso de rede (bindIp 0.0.0.0, firewall) — O mongod escuta em todas as interfaces (0.0.0.0, bindIpAll) ou a porta está aberta para todos. O bindIp é reduzido a localhost + IP interno do servidor, e o firewall libera apenas os membros e a rede da aplicação. Rolling, sem downtime.
• Criptografar conexões: TLS (allowTLS → preferTLS → requireTLS) — O tráfego entre a aplicação e os membros, e entre os membros, não é criptografado. Os certificados são distribuídos, os membros passam primeiro para allowTLS com reinício rolling, depois para preferTLS em tempo de execução e para requireTLS quando as aplicações estiverem prontas. Opcional: autenticação x.509 entre os membros.
• Habilitar o audit log (Enterprise / Percona) — É preciso registrar quem fez login e quando, as alterações de usuários/roles e as operações de drop. No MongoDB Enterprise e no Percona Server for MongoDB isso é habilitado com auditLog; o Community não tem esse recurso (uma alternativa é mostrada).
• Encryption at rest (criptografar os dados em disco) — Se o disco ou um backup for roubado, os dados não podem ser lidos. No Enterprise/Percona, a criptografia do WiredTiger é habilitada reconstruindo os membros um a um com initial sync; no Community, o disco de dados é criptografado com LUKS.

Antes de começar

• Acesso root/sudo em todos os servidores mongod… e mongos…; SSH do primeiro servidor para os demais (para copiar keyfile e certificados).
• …Replica set saudável: todos os membros PRIMARY/SECONDARY, lag baixo. Não se faz operação rolling em cluster não saudável.…mongod em execução.…
• Lista de aplicações e responsáveis: antes de tornar autorização/TLS obrigatórios, a string de conexão de cada aplicação será atualizada. A string de conexão deve conter todos os membros e replicaSet= (para não cair durante o rolling).
• Janela de manutenção: as operações rolling não causam downtime, mas a cada troca de primary as escritas esperam alguns segundos. Em servidor único, habilitar autorização/TLS exige uma interrupção curta.
• Se a autorização já estiver habilitada no sharded cluster: no primary de cada shard deve existir um usuário shard-local (root) com o mesmo nome e senha de … do mongos. Os passos por membro (rs.stepDown no reinício rolling, setParameter, auditoria) se conectam diretamente aos membros do shard; lá os usuários do mongos não valem. Verificação: no membro do shard, mongosh --port <porta do shard> e db.getSiblingDB("admin").auth("…", passwordPrompt()).
• Backup completo recente, com restore já testado.
• Para audit e encryption at rest, licença do MongoDB Enterprise ou Percona Server for MongoDB. O Community não tem esses recursos.
• Os nomes dos membros são resolvidos em cada servidor (DNS ou /etc/hosts); com TLS, as conexões são feitas por esses nomes.

Fases do guia

• Preparação: rede de segurança e ferramentas auxiliares — Backup de configuração e estado · Instalar o PyYAML · Escrever a ferramenta de edição de YAML (dbatlas-yaml) · Escrever a ferramenta de reinício rolling (dbatlas-mongod-restart) · Gravar a senha do administrador em um arquivo temporário
• Auditoria de estado (somente leitura) — Rede, processo e permissões de arquivos: … · Rede e processo: … · Autorização, TLS e parâmetros: … · Autorização, TLS e parâmetros: … · Usuários, roles e mecanismos de autenticação · Associar os achados aos cenários
• Autorização: diagnóstico e keyfile — Diagnóstico: a autorização está mesmo desabilitada? · Inventariar as conexões das aplicações · Criar o keyfile · Copiar o keyfile para os outros servidores · Permissões do keyfile: … · Permissões do keyfile: …
• Autorização: usuário administrador — Criar o usuário administrador (…) · Administrador shard-local: …
• Usuários com privilégio mínimo e custom role — Criar a custom role da aplicação (…@…) · Criar o usuário da aplicação (…) · Usuários de backup e monitoramento · Verificar o privilégio mínimo (…) · Guardar as senhas com segurança na aplicação e no cron
• Autorização: verificar que não restam conexões sem autenticação — Conexões de cliente sem autenticação: …
• Tornar a autorização obrigatória (servidor único) — authorization: enabled · Reiniciar o serviço com segurança (…)
• Autorização: verificação — O acesso sem autenticação está sendo recusado? · Verificar o privilégio mínimo (…) · Caminho de reversão (se necessário)
• SCRAM-SHA-256: migrar os usuários — Usuários com credencial SHA-1 · Reduzir os usuários a somente SCRAM-SHA-256
• SCRAM-SHA-256: verificação — O login com SHA-1 está sendo recusado?
• Acesso de rede: firewall — Regras de firewall
• Acesso de rede: verificação — Endereços em escuta: …
• TLS: certificados — Estado atual do TLS · Gerar a CA interna e os certificados dos servidores · Distribuir os certificados · Permissões e validação dos certificados: … · Permissões dos certificados: …
• TLS: migrar as aplicações — Migrar as aplicações para TLS e contar as conexões TLS
• TLS: verificação — A conexão sem TLS está sendo recusada: …
• Audit log: verificação prévia — Este mongod suporta audit: …
• Audit log: verificação e rotação — Os registros de audit estão sendo gerados: … · Alternativa para Community: acompanhar os logs de autenticação
• Encryption at rest: verificação prévia e backup — Suporte a criptografia e espaço em disco: … · O backup completo foi feito?
• Encryption at rest: marcador de teste — Gravar um marcador em texto puro
• Encryption at rest (Community): disco de dados com LUKS — Preparar o disco LUKS: … · Mover os dados para o disco criptografado: …
• Auditoria final (depois do hardening) — Rede, processo e permissões de arquivos: … (estado final) · Rede e processo: … (estado final) · Autorização, TLS e parâmetros: … (estado final) · Autorização, TLS e parâmetros: … (estado final) · Usuários, roles e mecanismos de autenticação (estado final)
• Limpeza e próximos passos — Apagar o arquivo temporário de senha · Depois: monitoramento e tarefas periódicas