La journalisation est l'endroit où les données s'échappent des systèmes

Je suis convaincu que la plupart des systèmes bien conçus gèrent raisonnablement bien les données personnelles au niveau primaire. Les enregistrements résident dans des tables définies, régis par des schémas, soumis à une logique de rétention qui reflète les décisions commerciales réelles. Vous pouvez les interroger, les supprimer et raisonner à leur sujet.

La journalisation, cependant, annule une grande partie de cela, non pas par négligence, mais par la manière dont les systèmes d'observabilité sont construits et par les paramètres par défaut qu'ils fournissent. Au moment où le problème se manifeste, les données sont déjà allées là où vous ne le vouliez pas.

Comment le second cycle de vie commence

Lorsqu'une requête arrive, l'instinct est de journaliser suffisamment de contexte pour la déboguer plus tard. Vous commencez par des identifiants de requête et des codes de statut. Vous ajoutez des identifiants d'utilisateur car ils facilitent le suivi des cas de support. Vous incluez des parties de la charge utile de la requête car elles aident à reproduire les cas limites. Une erreur se produit et le contexte complet l'accompagne - c'est-à-dire tout ce qui était dans la portée à ce moment-là. Chaque étape est raisonnable individuellement, et aucune d'entre elles ne ressemble à une décision de protection des données.

Mais considérez ce qui se passe en aval. Votre pipeline d'observabilité capture ces entrées de journal et les transmet à votre plateforme de gestion des journaux. Cette plateforme les conserve pendant 90 jours par défaut, ou 365, ou indéfiniment, car personne n'a modifié le paramètre par défaut lors de la configuration. Si vous utilisez une plateforme avec une région principale basée aux États-Unis, ces données ont également franchi une frontière sans décision de transfert délibérée. Si vous avez configuré la transmission des journaux vers un SIEM ou un outil d'analyse, les mêmes données existent maintenant dans un troisième emplacement sous son propre calendrier de rétention.

Vous n'avez rien décidé de tout cela. Vous avez configuré un logger. Le reste a suivi les paramètres par défaut.

Les données existent maintenant en parallèle. La copie principale suit le cycle de vie que vous avez conçu : structurée, supprimable, régie par vos règles de rétention. Les copies de journaux suivent un cycle de vie différent : moins structurées, conservées selon les paramètres opérationnels par défaut, réparties sur des systèmes qui ne faisaient pas partie de votre modèle de données. Ces deux cycles de vie divergent avec le temps, et l'écart entre eux est l'origine de la plupart des problèmes de conformité réels.

Où cela se manifeste

La divergence est invisible jusqu'à ce que le système soit tenu d'agir sur les données de manière contrôlée. La suppression est le test le plus clair.

Un utilisateur soumet une demande d'effacement. Vous supprimez son enregistrement de la base de données principale. Ensuite, quelqu'un demande si les données ont réellement disparu. Son adresse e-mail se trouve dans les journaux de requêtes écrits il y a six mois. Son identifiant d'utilisateur apparaît dans les traces d'erreurs sur trois services. Son activité de session se trouve dans un flux d'événements transmis conservé par une plateforme tierce avec un paramètre par défaut de 12 mois. Votre plateforme de gestion des journaux ne prend pas en charge la suppression au niveau de la ligne. Vous ouvrez un ticket de support et attendez, pendant que l'horloge de votre obligation de réponse de 30 jours tourne.

La rétention expose le même échec sous un angle différent. Vous appliquez une règle de rétention de 90 jours à votre base de données principale et considérez que c'est réglé. Votre système d'extraction de journaux fonctionne avec le paramètre par défaut de la plateforme de 12 mois. Les mêmes données ont maintenant deux périodes de rétention, appliquées indépendamment, sans rien pour assurer la cohérence entre elles. Si vous êtes jamais tenu de démontrer que les données ont été supprimées dans le délai que vous avez documenté, vous ne pouvez pas le faire : car la documentation décrit votre base de données, pas votre système.

Les décisions qui comptent

Définir une liste blanche de champs avant le début de l'instrumentation.

Le comportement par défaut de la plupart des bibliothèques de journalisation est de capturer tout ce qui est dans la portée. Ce paramètre par défaut produira des données personnelles dans les journaux. La seule solution fiable est de décider à l'avance ce qu'une entrée de journal est autorisée à contenir, non pas comme un exercice de filtrage après coup, mais comme une contrainte appliquée dès le départ au niveau de la configuration de la bibliothèque.

Pour la plupart des systèmes, la liste blanche est courte. Horodatages, identifiants de requête, identifiants de service, méthodes HTTP, codes de statut, temps de réponse, codes d'erreur structurés. Les identifiants d'utilisateur, les adresses e-mail, les adresses IP sous forme non tronquée, les jetons de session et tout fragment d'entrée fournie par l'utilisateur n'ont pas leur place sur cette liste sans raison documentée explicite. Si un champ n'est pas sur la liste blanche, il n'apparaît pas dans les journaux. Une seule décision, appliquée partout, ne nécessite aucune discipline continue pour être maintenue.

Remplacer les identifiants d'utilisateur par des identifiants de corrélation.

Si vous avez besoin de tracer une requête à travers les services (et vous en avez besoin), vous n'avez pas besoin d'un identifiant d'utilisateur dans chaque ligne de journal. Générez un identifiant de corrélation aléatoire en périphérie et propagez-le tout au long de la chaîne d'appels. Vous obtenez une traçabilité complète de bout en bout sans lier aucune entrée de journal à un individu. Lorsque vous avez besoin de reconstruire à quel utilisateur un identifiant de corrélation correspond, cette correspondance se trouve dans votre magasin de données principal sous ses propres règles de rétention et de suppression. Les journaux restent opérationnellement utiles. La classification de sensibilité de vos données de journal chute considérablement, et les demandes d'effacement cessent d'être un exercice d'archéologie multi-systèmes.

Traiter les niveaux de journalisation comme des limites de données.

Les journaux DEBUG sont destinés au développement et ne devraient pas s'exécuter en production. Lorsqu'ils le font, ils contiennent tout : l'état des variables, les entrées brutes, tout ce qui était pratique à joindre à l'époque. Les journaux INFO doivent enregistrer que quelque chose s'est produit, pas le contenu de ce qui s'est produit. Les journaux ERROR et WARN nécessitent le plus d'examen car les conditions d'erreur sont précisément là où les entrées sensibles sont les plus susceptibles d'apparaître : la charge utile qui a déclenché un échec de validation, le corps de la requête qui a provoqué un crash. Définissez ce que chaque niveau est autorisé à contenir comme politique écrite et appliquez-la lors de la revue de code. Les conventions s'érodent sous la pression des délais ; une politique révisable ne le fait pas.

Définir les périodes de rétention par destination de journal, pas par service.

Pour chaque destination de journal dans votre système (extraction principale, flux transmis, intégrations SIEM, outils d'analyse), définissez une période de rétention explicite liée à un objectif documenté. Les journaux de débogage opérationnel nécessitent rarement plus de 30 jours. Les journaux d'événements de sécurité peuvent justifier une rétention plus longue, mais cela nécessite un objectif et une base légale, pas un paramètre par défaut laissé en place depuis la configuration initiale. Lorsque votre plateforme ne prend pas en charge la suppression automatique au niveau de l'enregistrement, il s'agit d'une lacune à évaluer lors de la sélection du fournisseur, pas d'une contrainte à absorber silencieusement.

Mapper votre plateforme de gestion des journaux en tant que processeur de données.

Si vos journaux contiennent des données personnelles - même incidemment - votre plateforme de gestion des journaux les traite en votre nom. Cela nécessite un Accord de Traitement des Données (DPA), une compréhension de l'endroit où les données sont stockées géographiquement, une visibilité sur leur chaîne de sous-traitants, et une confirmation que leur DPA est compatible avec vos propres engagements clients. Pour les systèmes fonctionnant sous une réglementation sectorielle spécifique, le DPA standard de la plateforme, auquel on adhère par clic, ne sera souvent pas suffisant sans négociation.

La résidence des données est une lacune spécifique et courante ici. La plupart des plateformes majeures offrent des régions européennes mais ne les utilisent pas par défaut. L'endroit où vos journaux sont réellement stockés est une question de configuration avec une conséquence juridique : une hypothèse non vérifiée sur la résidence dans l'UE est l'un des échecs de conformité les plus faciles à éviter et l'un des plus fréquemment manqués.

Les paramètres par défaut sont la politique

Si votre système journalise les charges utiles complètes des requêtes, les conserve selon les paramètres par défaut de la plateforme et les transmet sans limites définies, c'est votre politique de traitement des données - indépendamment de ce que dit votre avis de confidentialité. Les décisions qui façonnent le comportement réel de votre système de journalisation sont prises lorsque vous configurez votre première extraction, écrivez votre premier gestionnaire, et définissez une période de rétention ou laissez le paramètre par défaut en place.

La journalisation est l'endroit le plus courant où un modèle de données primaire bien conçu échoue. Cela ne nécessite pas d'erreur. Cela nécessite seulement que l'observabilité ait été traitée comme une préoccupation d'ingénierie et le cycle de vie des données comme le problème de quelqu'un d'autre (et que personne n'ait géré le chevauchement).

Pourquoi tout cela ? Outre la raison juridique, il y a un autre aspect : le système qui fonctionne quand personne ne fait attention est le système qui est audité. Croyez-moi, je n'audite pas la nouvelle chose flashy - j'examine le système hérité, la pièce d'équipement intacte que tout le monde appelle fiable. Parce que c'est là que se trouvent les problèmes.