Tornar visíveis para a equipe as leituras de tabelas com dados pessoais reduz consultas amplas a essas tabelas

Hipótese

O acesso a tabelas com dados pessoais costuma ser controlado por grants e, às vezes, por políticas em nível de linha. Esses controles não mudam a forma como quem tem acesso legítimo consulta os dados: uma pessoa engenheira que depura um ticket executa SELECT * na tabela de usuários, e uma pessoa analista faz join com a tabela inteira em vez de pegar só as linhas necessárias. A hipótese é que a visibilidade, por si só, muda esse comportamento. O parâmetro log_statement do PostgreSQL define quais instruções SQL são registradas, e um resumo do log por tabela não exige nenhum mecanismo novo de controle. A afirmação é a seguinte: quando cada leitura de tabelas de dados pessoais previamente designadas é registrada com o role que a executou e resumida semanalmente para a equipe (quem leu qual tabela, quantas linhas, com ou sem predicado em nível de pessoa), a proporção de leituras amplas diminui, sem queda nas leituras estreitas que o trabalho exige. O mecanismo proposto não é o medo de uma auditoria, mas o caráter concreto de ver o próprio nome ao lado de "todas as linhas de users" num resumo lido por colegas.

Previsão

Comparando as oito semanas anteriores à introdução do resumo com as oito semanas posteriores, com o registro em log ativo durante todo o período: a proporção de instruções contra as tabelas designadas que não têm predicado sobre um identificador de pessoa, ou que selecionam todas as colunas, diminui; o número de instruções com predicado em nível de pessoa permanece dentro da faixa anterior; as linhas retornadas por instrução diminuem. O efeito é maior nas sessões interativas de engenheiros e menor nos jobs agendados, cujas consultas foram escritas uma só vez. Se a proporção de leituras amplas não diminuir, ou se as leituras estreitas diminuírem na mesma proporção (ou seja, as pessoas simplesmente consultam menos), a hipótese é falsa.

Teste proposto

1. Designar as tabelas, ativar o registro de instruções para os roles que podem lê-las e converter o log em registros estruturados: role, tabela, presença de predicado em nível de pessoa, uso de curinga de colunas, tipo de sessão. O log de instruções não traz contagem de linhas; as linhas por instrução e por role vêm da coluna rows de pg_stat_statements.
2. Manter o registro por oito semanas sem publicar nada, para estabelecer a linha de base; avisar a equipe de que o registro existe, já que o teste trata de visibilidade, não de monitoramento secreto.
3. Iniciar um resumo semanal para toda a equipe, listando, por role, as contagens acima; manter por oito semanas.
4. Comparar os dois períodos nas medidas da previsão, por role e por tipo de sessão; informar as contagens, e não apenas as proporções.
5. Perguntar à equipe, depois, quais consultas ela mudou e por quê, para separar mudança de comportamento de mudança de carga de trabalho.

Estado

Nenhum resultado é alegado. O anúncio do registro no passo 2 pode, por si só, mudar o comportamento antes de existir o resumo, o que reduziria o efeito medido; a carga de trabalho também pode mudar por motivos alheios ao teste ao longo de quatro meses, e por isso as leituras estreitas são acompanhadas como controle.