Segurança · Infra·2026
Security Audit & Infrastructure
7 bancos MongoDB e 6,15M de arquivos com restauração validada a ~US$0,30/mês
- Papel
- Auditor de segurança e engenheiro de infraestrutura
- Período
- 2026 · laudo entregue; pipeline de backup em produção
Resumo
Dois trabalhos na mesma disciplina. Primeiro: auditoria white/black-box de um ERP multi-tenant sobre Supabase, onde o Row Level Security é a única coisa entre os dados de um tenant e os de outro. Segundo: uma VPS que já tinha sido sequestrada uma vez, precisando de backups que de fato restauram e de um host que pare de convidar invasores.
Arquitetura e decisões
- A auditoria tratou o RLS como a fronteira de segurança e o testou como tal: 14 tabelas revisadas, funções SECURITY DEFINER lidas linha a linha, JWT validado no servidor e os grants do papel anon revogados.
- Os achados foram entregues como plano de correção priorizado com SQL pronto para rodar, não um PDF de palavras assustadoras. Nada foi alterado no sistema do cliente; o escopo era auditar, não corrigir.
- O pipeline de backup é 3-2-1 com criptografia client-side: o rclone crypt cifra antes de qualquer coisa sair da máquina, então a Backblaze B2 nunca vê texto claro e a chave fica com o cliente.
- A retenção é GFS (7 diários, 4 semanais, 6 mensais) com versionamento, porque um ransomware que cifra seu primário cifra alegremente um espelho que sincroniza exclusões.
- Restauração só é backup se você já fez uma: quatro smoke tests ponta a ponta validam MongoDB (por contagem de documentos), MySQL, /etc e /var/www (diff bit a bit), cada um documentado no RESTORE.md.
Desafios
Problema: No ERP, um tenant conseguia reescrever a coluna que decide a que tenant ele pertence.
Solução: A policy de RLS de profiles permitia atualizar empresa_id: um tenant breakout em um único UPDATE. Um segundo achado permitia a um gerente se promover a admin global. Ambos foram reportados como críticos com a reescrita exata da policy, mais a recomendação de separar RLS por papel em vez de uma policy tentando servir todos os atores.
Problema: A VPS tinha sido extorquida em 2023. O cliente precisava saber como, e que não aconteceria de novo.
Solução: A forense identificou o vetor: MongoDB escutando em 0.0.0.0 sem autenticação. A produção foi confirmada intacta e uma captura forense de 4,1 GB foi preservada com SHA256. O vetor foi fechado (Mongo em 127.0.0.1) e o fail2ban instalado. Baniu 6 IPs nas primeiras horas, contra 49 tentativas de invasão registradas em ~12h.
Resultados
- Auditoria do ERP: 14 tabelas com RLS revisadas; falhas de tenant-breakout e escalação de privilégio encontradas, com correção SQL priorizada
- Backups: 7 bancos MongoDB (~6,7 GB) e 6,15M de arquivos, cifrados no cliente, a ~US$0,30/mês
- Restauração validada por 4 testes ponta a ponta, incluindo diff bit a bit de /var/www
- Vetor do ransomware fechado; fail2ban baniu 6 IPs contra 49 tentativas em ~12h