SQL: Melhores Práticas de Segurança

Introdução

Os números que abrem este artigo não são abstratos: US$ 4,45 milhões é o custo médio de uma violação, e credenciais comprometidas ou uso indevido de privilégios estão entre as causas mais citadas ano após ano nos relatórios da Verizon. As práticas abaixo existem porque, historicamente, foi assim que as violações mais caras aconteceram.

Princípio do menor privilégio

Audite periodicamente quem tem acesso a quê. É comum um privilégio concedido "temporariamente" para resolver um problema pontual nunca ser revogado, isso se acumula ao longo de anos até que praticamente todo mundo tem acesso a tudo, o oposto do que Griffiths & Wade propuseram.

Nunca concatenar SQL, sempre parametrizar

-- PERIGOSO: concatenação direta permite SQL Injection
"SELECT * FROM usuarios WHERE email = '" + email_do_usuario + "'"

-- SEGURO: query parametrizada
SELECT * FROM usuarios WHERE email = ?

SQL Injection continua, décadas depois, sendo uma das vulnerabilidades mais exploradas do OWASP Top 10 — e a defesa é simples: nunca construir SQL por concatenação de string com input externo.

Criptografia em trânsito e em repouso

Conexões com o banco devem usar TLS/SSL (em trânsito), e dados sensíveis (senhas, dados de pagamento, documentos) devem ser criptografados no armazenamento (em repouso) de forma que, mesmo se alguém acessar o disco fisicamente ou um backup vazar, os dados não sejam legíveis.

Auditoria e Logging

Manter registro de quem executou o quê, e quando, especialmente para operações sensíveis (DELETE, mudanças de permissão, acesso a tabelas com dados pessoais). Sem isso, uma violação pode passar meses sem ser percebida.

Separação de ambientes e contas de serviço

A aplicação em produção não deveria conectar no banco com uma conta de administrador. Cada serviço deve ter sua própria conta, com privilégios mínimos e escopados exatamente ao que aquele serviço faz, se uma aplicação for comprometida, o estrago fica contido.

Backups testados

Segurança não é só impedir acesso indevido, é também garantir recuperação. Um backup que nunca foi restaurado em teste é, na prática, um backup que você não sabe se funciona.