Fala pessoal!
No dia 06 de fevereiro, participei da Mesa Redonda #212 no canal Coding Night, em uma conversa extensa e profundamente prática sobre segurança na utilização de bancos de dados, tendo como principal referência os materiais da OWASP. A proposta da live não foi apresentar novidades ou soluções sofisticadas, mas revisitar fundamentos que continuam sendo ignorados, mesmo após décadas de recomendações consolidadas.
Ao longo da discussão, ficou claro que a maior parte dos incidentes de segurança envolvendo bancos de dados não está associada a ataques complexos ou técnicas avançadas, mas sim à negligência de práticas básicas, amplamente documentadas e conhecidas pela comunidade técnica.
Link da transmissão:
OWASP como base conceitual e prática
Um dos primeiros pontos abordados foi a contextualização da OWASP. Mais do que uma lista de vulnerabilidades, a OWASP se consolidou como uma referência global em boas práticas de segurança, baseada na observação contínua dos ataques mais recorrentes no mundo real.
O conhecido OWASP Top 10 surgiu justamente da análise estatística dos ataques mais frequentes em aplicações. Com o amadurecimento da comunidade, esse trabalho evoluiu para materiais mais específicos, como:
-
OWASP Top 10 para APIs
-
OWASP Top 10 para CI/CD
-
OWASP Top 10 para Containers
-
OWASP Database Security Cheat Sheet
Esses materiais funcionam como checklists práticos, e não como teoria acadêmica. A live teve como foco justamente discutir como essas recomendações se aplicam ao dia a dia de quem trabalha com bancos de dados, desenvolvimento e infraestrutura.
Segurança básica ainda é o maior gargalo
Um ponto reforçado diversas vezes foi que a maioria das vulnerabilidades exploradas hoje são extremamente conhecidas. SQL Injection, exposição de credenciais, bancos acessíveis diretamente pela internet, permissões excessivas e ausência de criptografia continuam aparecendo em ambientes produtivos.
Não se trata de desconhecimento técnico profundo, mas de falta de disciplina, pressão por prazo e acúmulo de débito técnico que nunca é tratado.
Segurança costuma ser sacrificada quando o prazo aperta. O problema surge quando essa decisão não é registrada, priorizada ou revisitada posteriormente. O débito técnico de segurança é assumido, mas nunca pago.
Proteção do backend do banco de dados e isolamento de rede
Uma parte importante da conversa foi dedicada à proteção do backend do banco de dados, começando pelo isolamento em nível de rede. A primeira linha de defesa de qualquer banco deve ser garantir que ele não esteja acessível desnecessariamente.
Foram discutidas práticas como:
-
Restringir conexões apenas a hosts ou IPs específicos
-
Evitar exposição direta do banco à internet
-
Utilizar firewalls, regras de rede e, quando possível, DMZs
-
Garantir que apenas servidores de aplicação consigam se conectar
Mesmo que uma credencial seja comprometida, o atacante não deve conseguir estabelecer conexão se estiver fora do contexto esperado. Esse tipo de controle reduz drasticamente a superfície de ataque.
Autenticação e o problema de credenciais esquecidas
Outro ponto central foi a forma como a autenticação é implementada. Bancos que utilizam autenticação baseada apenas em usuário e senha criam um problema recorrente: credenciais que permanecem válidas indefinidamente.
Foi discutido como a autenticação integrada (por exemplo, Active Directory ou Single Sign-On) traz benefícios claros:
-
Não há senha trafegando pela rede
-
Desativar um usuário invalida automaticamente todos os acessos
-
Reduz drasticamente o risco de contas órfãs
Casos reais foram mencionados onde ex-funcionários mantiveram acesso indireto ao banco de dados simplesmente porque a credencial nunca foi removida.
Princípio do menor privilégio na prática
O princípio do menor privilégio foi tratado não como conceito abstrato, mas como prática diária. Conceder permissões amplas “por conveniência” é um dos erros mais comuns e perigosos.
Foi destacado que:
-
A maioria das aplicações não precisa de permissões administrativas
-
Acesso de leitura mal controlado também representa risco
-
Permissões devem ser concedidas no menor escopo possível
Além disso, permissões precisam ser revisadas periodicamente, e não apenas durante auditorias pontuais. Ambientes sem revisões regulares tendem a acumular acessos desnecessários ao longo dos anos.
Armazenamento seguro de credenciais
Grande parte da live abordou o armazenamento inadequado de credenciais em aplicações. Exemplos reais mostraram como senhas expostas em código-fonte ou arquivos de configuração são exploradas em questão de segundos.
As práticas recomendadas discutidas incluíram:
-
Nunca versionar credenciais
-
Utilizar cofres de segredos dedicados
-
Restringir acesso ao cofre apenas a quem realmente precisa
-
Preferir variáveis de ambiente apenas como alternativa intermediária
Foi enfatizado que cofres de senha não apenas protegem credenciais, mas também evitam exposição acidental durante compartilhamento de tela, gravações ou demonstrações.
Criptografia em repouso e em trânsito
A discussão sobre criptografia deixou claro que proteger apenas os dados armazenados não é suficiente. Dados também precisam estar protegidos durante o tráfego entre aplicação e banco.
Foi discutido o uso de:
-
TLS para conexões com o banco
-
Certificados válidos e versões seguras de protocolos
-
Evitar aceitar conexões inseguras mesmo com redirecionamento
A analogia utilizada foi simples: não adianta proteger o cofre se o transporte do dinheiro é feito sem escolta.
Gestão consciente de débito técnico em segurança
Um dos pontos mais maduros da conversa foi a discussão sobre débito técnico de segurança. Nem sempre é possível implementar tudo corretamente desde o início, especialmente em startups ou projetos com prazos agressivos.
O problema não é assumir o débito, mas não reconhecê-lo nem registrá-lo. Vulnerabilidades conhecidas precisam estar documentadas, priorizadas e com plano de correção definido. Segurança não pode depender apenas da memória das pessoas.
Uso de ferramentas e automação como apoio
A live também mostrou como ferramentas automatizadas podem ajudar a identificar vulnerabilidades básicas antes de investir em testes mais avançados. Ferramentas de análise estática (SAST), análise dinâmica (DAST) e scanners de API ajudam a eliminar o “básico mal feito”.
Essas ferramentas não substituem testes manuais nem profissionais especializados, mas reduzem drasticamente a quantidade de problemas triviais que chegam a uma auditoria formal.
Segurança como responsabilidade coletiva
Um ponto reforçado ao longo de toda a mesa redonda foi que segurança não é responsabilidade exclusiva de DBAs, desenvolvedores ou infraestrutura. Ela surge da interação entre todas essas áreas.
Decisões de desenvolvimento impactam o banco. Configurações de infraestrutura impactam a aplicação. Falhas de comunicação entre times criam brechas que não existiriam se o problema fosse tratado de forma conjunta.
Considerações finais
A Mesa Redonda #212 reforçou algo essencial: segurança falha, na maioria das vezes, pelo básico mal feito. Não é falta de conhecimento, nem de ferramentas, mas de disciplina, processo e maturidade.
Enquanto práticas fundamentais continuarem sendo tratadas como opcionais, incidentes continuarão acontecendo. Segurança não exige soluções complexas para começar, exige compromisso em fazer corretamente o que já é amplamente conhecido.
Essa live teve como objetivo justamente trazer essa realidade à tona, de forma direta, técnica e alinhada com o que realmente acontece no mercado.
Portuguese 
English