[Live] – Coding Night – Mesa Redonda #222: Segurança na utilização de Bancos de Dados – OWASP, dicas e muito mais

Hey guys!

No dia 11 de junho, participei da Mesa Redonda #222 no canal Coding Night, em sua segunda edição, com foco total em segurança na utilização de bancos de dados. A proposta da live foi dar continuidade à edição anterior e aprofundar pontos críticos do material da OWASP, especialmente aqueles que continuam sendo negligenciados mesmo em ambientes corporativos maduros.

A conversa foi conduzida de forma aberta, prática e sem a preocupação de “embelezar” o tema. O objetivo foi discutir o que realmente acontece no dia a dia, os erros mais comuns e por que problemas de segurança continuam se repetindo, mesmo quando as recomendações são amplamente conhecidas.

Broadcast link:

OWASP Database Security Cheat Sheet como fio condutor

Utilizamos como base o OWASP Database Security Cheat Sheet, que reúne recomendações organizadas de A a Z sobre segurança em bancos de dados. Um ponto importante destacado logo no início foi que esse material não deve ser visto como uma lista teórica, mas como um checklist prático.

A maior parte dos incidentes graves de segurança não ocorre por falhas sofisticadas, mas pela não implementação de controles básicos, amplamente documentados há anos. SQL Injection, por exemplo, continua sendo explorado não por ser novo, mas por continuar sendo possível.

Autenticação, identidade e o problema de contas esquecidas

Uma parte significativa da live foi dedicada a autenticação e gestão de identidades. Discutimos como o uso de autenticação integrada (Active Directory, autenticação federada ou managed identities em cloud) reduz drasticamente riscos operacionais.

O problema recorrente está no uso de:

• Usuários locais no banco de dados

• Contas de aplicação com permissões excessivas

• Credenciais que permanecem ativas após desligamento de colaboradores

Expliquei que contas “esquecidas” são uma das maiores portas de entrada para incidentes. Muitas vezes, o usuário não precisa nem ser externo: alguém que saiu da empresa, mudou de área ou voltou como terceiro pode ainda ter acesso privilegiado se esse controle não for feito corretamente.

Princípio do menor privilégio aplicado de forma realista

Outro ponto central da discussão foi o princípio do menor privilégio, não apenas como conceito, mas como prática efetiva.

Falamos sobre:

• Evitar conceder acesso em nível de banco quando o necessário é em nível de tabela

• Evitar permissões de escrita quando o uso é apenas leitura

• O risco real de um simples acesso de leitura mal controlado gerar indisponibilidade (inclusive ataques de negação de serviço por leitura excessiva)

Foi reforçado que segurança não é apenas impedir escrita ou exclusão de dados, mas também garantir disponibilidade.

Segurança em aplicações: credenciais, configuração e erros clássicos

A live trouxe diversos exemplos reais envolvendo aplicações que armazenam credenciais em locais inadequados, como arquivos de configuração versionados em repositórios Git. Casos em que senhas foram expostas publicamente e exploradas em poucos segundos mostram que esse risco não é hipotético.

Discutimos práticas como:

• Uso de cofre de segredos ou, no mínimo, variáveis de ambiente

• Nunca versionar credenciais, mesmo em repositórios privados

• Cuidado extremo em demonstrações ao vivo, gravações e prints

Também comentamos como plataformas como GitHub evoluíram para detectar automaticamente vazamento de secrets, mas que isso não substitui boas práticas.

Hardening de banco de dados e sistema operacional

Outro ponto forte da live foi a discussão sobre hardening, tanto do banco de dados quanto do sistema operacional subjacente. Blindar apenas o SGBD não resolve o problema se o SO estiver exposto.

Foram abordados pontos como:

• Desativação de funcionalidades perigosas quando não utilizadas (ex: xp_cmdshell, CLR, SQL Browser)

• Evitar uso de usuários padrão ou amplamente conhecidos

• Separação clara entre contas administrativas do sistema e do banco de dados

A ideia central foi reduzir a superfície de ataque e dificultar qualquer tentativa de elevação de privilégio.

Backup como pilar de segurança, não apenas de recuperação

A estratégia de backup foi tratada como um elemento de segurança, e não apenas de continuidade de negócio. Casos reais foram citados onde empresas precisaram pagar resgates simplesmente por não possuírem backups válidos e externos.

Falamos sobre:

• Backup regular e testado

• Criptografia de backups

• Armazenamento externo e, preferencialmente, em nuvem

• Definição clara de RPO e RTO alinhados com o negócio

Foi reforçado que a estratégia de backup não deve ser definida apenas pela TI, mas em conjunto com a área de negócio, considerando impacto financeiro e operacional.

SQL Injection continua sendo um problema atual

Mesmo após décadas, SQL Injection ainda aparece com frequência em incidentes graves. A discussão deixou claro que o problema não está apenas na linguagem ou no banco, mas na forma como aplicações são desenvolvidas.

Destacamos:

• Uso obrigatório de parâmetros

• Riscos de SQL dinâmico mal implementado

• Falsa sensação de segurança ao usar ORMs de forma incorreta

• A necessidade de validação de entrada, independentemente da tecnologia utilizada

Também comentamos que bancos de dados não conseguem, por si só, diferenciar uma query legítima de uma query maliciosa se a aplicação entregar SQL inválido.

Granularidade de acesso e isolamento de ambientes

Outro tema recorrente foi a separação adequada entre ambientes de desenvolvimento, teste e produção. Compartilhar usuários e credenciais entre ambientes aumenta drasticamente o risco de erro humano.

Falamos também sobre:

• Segurança em nível de linha (Row-Level Security)

• Segurança em nível de coluna (Column-Level Security)

• Uso de views e procedures como camadas adicionais de controle

Esses mecanismos permitem reduzir exposição de dados sensíveis mesmo quando o acesso é legítimo.

Considerações finais

A Mesa Redonda #222 reforçou algo que considero fundamental: segurança não falha por falta de informação, mas por falta de disciplina. A maioria dos problemas discutidos envolve práticas básicas que continuam sendo ignoradas por pressa, falta de processo ou excesso de confiança.

Segurança em bancos de dados não é responsabilidade exclusiva de DBAs, desenvolvedores ou infraestrutura. É um esforço conjunto, contínuo e que precisa ser tratado como parte essencial da arquitetura, não como um complemento opcional.

Essa edição deixou claro que, enquanto as boas práticas não forem tratadas como padrão, continuaremos vendo os mesmos incidentes se repetirem, apenas com nomes e tecnologias diferentes.