La minimisation des données comme discipline de schéma et de journalisation

Ce que c'est

La minimisation des données est cette habitude d'ingénierie qui consiste à ne stocker que les données personnelles dont une fonctionnalité a besoin, à la précision la plus grossière qui serve la finalité, et pas plus longtemps que cette finalité ne dure. Elle se manifeste à trois endroits : le schéma (quelles colonnes existent et à quelle précision), les journaux (quels champs sont émis), et les magasins dérivés (analytique, index de recherche, caches) qui copient depuis l'un et l'autre. Le NIST SP 800-122 pose la tâche ultérieure comme consistant à identifier les données à caractère personnel (PII) dans un système et à décider du niveau de protection approprié pour chaque instance ; la minimisation est l'étape qui précède, celle qui évite de créer l'instance en premier lieu. Le OWASP Logging Cheat Sheet énumère les données qui ne doivent pas être enregistrées directement dans les journaux, mais supprimées, masquées, hachées ou chiffrées, parmi lesquelles les valeurs d'identification de session, les jetons d'accès, les mots de passe, les données de carte de paiement et les données personnelles sensibles.

Pourquoi c'est important

Chaque champ stocké est un passif à coûts récurrents : il doit être protégé, exporté sur demande, supprimé à la fin de sa durée de conservation, et expliqué après un incident. Un champ qui n'a jamais été stocké ne coûte rien. Les journaux constituent la voie de fuite habituelle, parce qu'ils sont écrits par chaque couche, copiés vers plusieurs systèmes et lus par davantage de personnes que ne l'est la base de données.

Comment l'appliquer

• Se demander, pour chaque colonne lors de la revue de schéma : quelle fonctionnalité la lit, à quelle précision, pour combien de temps ? Stocker l'année de naissance quand seule une tranche d'âge est utilisée, une région plutôt qu'une adresse complète, un booléen « a un numéro de téléphone » quand seul le fait compte.
• Isoler les colonnes sensibles rarement nécessaires dans une table à part, avec un accès plus strict, de sorte que les jointures courantes ne les touchent jamais.
• Journaliser par liste blanche (allowlist) : l'aide de journalisation structurée accepte des champs nommés et ignore tout le reste ; un message en texte libre ne reçoit jamais un corps de requête ni un objet utilisateur déversé via %r ou JSON.stringify.
• Remplacer les identifiants dans les journaux par des pseudonymes stables (un hachage à clé) là où une corrélation est nécessaire, et par rien là où elle ne l'est pas.
• Appliquer les mêmes règles aux magasins dérivés : le schéma des événements analytiques énumère les champs autorisés et rejette les champs inconnus à l'ingestion.
• Étiqueter les colonnes et les champs de journal avec une classification (personal, sensitive, none) dans la définition du schéma, afin que les outils ultérieurs d'export, de suppression et de revue puissent les retrouver.

Pièges

La minimisation décidée à la conception s'érode sous l'effet de la journalisation de débogage « temporaire » laissée en place, des colonnes JSON qui acceptent n'importe quelle clé, et des SDK tiers qui collectent de leur propre initiative. Des données rendues plus grossières peuvent encore identifier une personne en combinaison (année de naissance plus région plus genre) ; le fait de rendre grossier est une réduction, pas une anonymisation. Un champ retiré du schéma continue d'exister dans les anciennes sauvegardes et dans l'archive des journaux jusqu'à leur expiration.