Log de auditoria do banco
Registra cada consulta ao banco; serve para medir quanto dado alguém leu, sem contar duas vezes.
Um banco de dados pode guardar um log de auditoria: uma linha por consulta, com a hora, o usuário, de onde veio, a consulta em si e, muitas vezes, quantas linhas ela devolveu. Depois de um incidente, esse log responde a pergunta mais importante do relatório: quanto dado o atacante leu.
Ler esse log tem três cuidados.
- Separe quem é quem. A aplicação do site costuma aparecer com um usuário próprio (por exemplo
loja_app), vindo do servidor web, fazendo muitas consultas pequenas o dia todo (um produto, um cliente por vez). O atacante aparece diferente: outro usuário, de outro lugar (às vezes a própria máquina,127.0.0.1), e no horário do ataque. - Olhe a tabela certa. Só contam as consultas à tabela que tem o dado da pergunta. A tabela
clientestem os clientes;pedidostem os pedidos; são coisas diferentes. ESELECT count(*)devolve o número de registros, não registros de pessoas. - Não some linhas cegamente. O atacante costuma ler a mesma tabela mais de uma vez: inteira (
SELECT * FROM clientes) e de novo em páginas (LIMIT/OFFSET). Somar as linhas conta as mesmas pessoas duas vezes. O que importa é o número de registros distintos, que é o tamanho da tabela.
Exemplo. Se o log mostra SELECT * FROM clientes com 3609 linhas e, logo depois, três páginas de 1500, 1500 e 609 linhas da mesma tabela, a soma dá 7218, mas são as mesmas 3609 pessoas lidas duas vezes. O SELECT count(*) FROM clientes confirma: 3609. A resposta é 3609.
Isso importa porque o tamanho do vazamento decide quantas pessoas precisam ser avisadas. Contar linhas sem pensar exagera o número; medir registros distintos, por tabela, dá a conta certa que vai para o relatório e para a lei.