Rendre visibles à l'équipe les lectures des tables de données personnelles réduit les requêtes larges sur ces tables

Hypothèse

L'accès aux tables contenant des données personnelles est en général contrôlé par des privilèges (grants) et parfois par des politiques au niveau des lignes. Ces contrôles ne changent rien à la façon dont les personnes disposant d'un accès légitime interrogent les données : une personne qui développe et qui débogue un ticket exécute un SELECT * sur la table des utilisateurs, une personne qui analyse joint la table entière au lieu des seules lignes nécessaires. L'hypothèse est que la seule visibilité change ce comportement. Le paramètre log_statement de PostgreSQL contrôle quelles instructions SQL sont journalisées, et une synthèse du journal par table ne nécessite aucun nouveau mécanisme de contrainte. L'affirmation est que, lorsque chaque lecture adressée aux tables désignées comme contenant des données personnelles est journalisée avec le rôle qui l'a exécutée et résumée chaque semaine à l'équipe (qui a lu quelle table, combien de lignes, avec ou sans prédicat au niveau d'une personne), la part des lectures larges diminue, sans diminution des lectures étroites que le travail exige. Le mécanisme proposé n'est pas la crainte d'un audit, mais le caractère concret de voir son propre nom associé à « toutes les lignes de users » dans une synthèse lue par des collègues.

Prédiction

En comparant les huit semaines précédant l'introduction de la synthèse aux huit semaines suivantes, la journalisation tournant sans interruption : la part des instructions adressées aux tables désignées qui n'ont aucun prédicat sur un identifiant de personne, ou qui sélectionnent toutes les colonnes, diminue ; le nombre d'instructions comportant un prédicat au niveau d'une personne reste dans sa fourchette précédente ; le nombre de lignes renvoyées par instruction diminue. L'effet est le plus marqué pour les sessions interactives des personnes qui développent et le plus faible pour les tâches planifiées, dont les requêtes ont été écrites une fois pour toutes. Si la part des lectures larges ne diminue pas, ou si les lectures étroites diminuent dans la même proportion (les personnes interrogeant simplement moins souvent), l'hypothèse est fausse.

Test proposé

1. Désigner les tables, activer la journalisation des instructions pour les rôles pouvant les lire, et analyser le journal pour en extraire des enregistrements : rôle, table, présence d'un prédicat au niveau d'une personne, joker sur les colonnes, type de session. Le journal des instructions ne porte pas le nombre de lignes ; le nombre de lignes par instruction et par rôle provient de la colonne rows de pg_stat_statements.
2. Faire tourner la journalisation pendant huit semaines sans rien publier, afin d'établir la référence ; informer l'équipe que la journalisation existe, car le test porte sur la visibilité, non sur une surveillance secrète.
3. Démarrer une synthèse hebdomadaire adressée à toute l'équipe, listant, par rôle, les décomptes ci-dessus ; poursuivre pendant huit semaines.
4. Comparer les deux périodes sur les mesures de la prédiction, par rôle et par type de session ; rapporter les décomptes, pas seulement les parts.
5. Demander ensuite à l'équipe quelles requêtes elle a modifiées et pourquoi, afin de distinguer un changement de comportement d'un changement de charge de travail.

Statut

Aucun résultat n'est revendiqué. L'annonce de la journalisation à l'étape 2 peut elle-même modifier le comportement avant même l'existence de la synthèse, ce qui réduirait l'effet mesuré ; la charge de travail peut également changer pour des raisons sans rapport sur quatre mois, raison pour laquelle les lectures étroites sont suivies comme témoin.