Hacer visibles al equipo las lecturas de las tablas de datos personales reduce las consultas amplias sobre esas tablas

Hipótesis

El acceso a las tablas que contienen datos personales suele controlarse mediante concesiones (grants) y, a veces, mediante políticas a nivel de fila. Esos controles no cambian la forma en que las personas con acceso legítimo consultan los datos: un ingeniero que depura un ticket ejecuta SELECT * sobre la tabla de usuarios, un analista une la tabla entera en lugar de las filas necesarias. La hipótesis es que la sola visibilidad cambia este comportamiento. El parámetro log_statement de PostgreSQL controla qué sentencias SQL se registran, y un resumen por tabla del registro no requiere ninguna imposición nueva. La afirmación es que, cuando cada lectura sobre las tablas designadas de datos personales se registra junto con el rol que la ejecutó y se resume al equipo semanalmente (quién leyó qué tabla, cuántas filas, con o sin un predicado a nivel de persona), la proporción de lecturas amplias disminuye, sin que disminuyan las lecturas acotadas que el trabajo requiere. El mecanismo propuesto no es el temor a una auditoría, sino lo concreto de ver el propio nombre junto a «todas las filas de users» en un resumen leído por los compañeros.

Predicción

Al comparar las ocho semanas anteriores a la introducción del resumen con las ocho posteriores, con el registro funcionando durante todo el periodo: la proporción de sentencias sobre las tablas designadas que carecen de un predicado sobre un identificador de persona, o que seleccionan todas las columnas, disminuye; el número de sentencias con un predicado a nivel de persona se mantiene dentro de su rango anterior; las filas devueltas por sentencia disminuyen. El efecto es mayor en las sesiones interactivas de los ingenieros y menor en los trabajos programados, cuyas consultas se escribieron una sola vez. Si la proporción de lecturas amplias no disminuye, o si las lecturas acotadas disminuyen en la misma proporción (es decir, si las personas simplemente consultan menos), la hipótesis es falsa.

Prueba propuesta

1. Designar las tablas, habilitar el registro de sentencias para los roles que pueden leerlas, y analizar el registro convirtiéndolo en registros de datos: rol, tabla, presencia de un predicado a nivel de persona, comodín de columna, tipo de sesión. El registro de sentencias no incluye el número de filas; las filas por sentencia y por rol se obtienen de la columna rows de pg_stat_statements.
2. Ejecutar el registro durante ocho semanas sin publicar nada, para establecer la línea base; informar al equipo de que el registro existe, ya que la prueba trata de la visibilidad y no de una monitorización secreta.
3. Iniciar un resumen semanal dirigido a todo el equipo que enumere, por rol, los recuentos anteriores; continuar durante ocho semanas.
4. Comparar los dos periodos según las medidas de la predicción, por rol y por tipo de sesión; informar los recuentos, no solo las proporciones.
5. Preguntar después al equipo qué consultas cambiaron y por qué, para separar el cambio de comportamiento del cambio de carga de trabajo.

Estado

No se afirma ningún resultado. El propio anuncio del registro en el paso 2 puede cambiar el comportamiento antes de que exista el resumen, lo cual reduciría el efecto medido; la carga de trabajo también puede cambiar por razones ajenas a lo largo de cuatro meses, razón por la cual las lecturas acotadas se registran como control.