Journaux d'accès aux données personnelles : enregistrer qui a lu quel enregistrement

Ce que c'est

Un journal d'accès aux données personnelles enregistre les lectures, pas seulement les écritures : quel principal (un utilisateur interne, un service, un outil de support, une tâche d'export) a lu l'enregistrement de quel sujet, quand, par quel chemin, et pour quel motif déclaré. Il complète le journal d'audit des changements d'état. Deux niveaux peuvent le produire. Au niveau applicatif, le gestionnaire qui charge l'enregistrement d'un client émet un événement portant l'identifiant du sujet. Au niveau de la base de données, une extension comme pgAudit journalise les instructions ; son README indique que la journalisation d'audit orientée objet consigne les instructions affectant une relation donnée et prend en charge SELECT, INSERT, UPDATE et DELETE, configurée via un rôle auquel sont accordés des privilèges sur les relations à surveiller. La norme NIST SP 800-92 couvre la discipline environnante ; son résumé décrit des recommandations pour mettre en place des infrastructures de gestion des journaux et des processus de gestion des journaux, où s'inscrivent le stockage, la protection et l'analyse du journal d'accès lui-même.

Pourquoi c'est important

Les questions auxquelles ce journal doit répondre sont centrées sur le sujet : « qui a consulté les données de cette personne au cours de l'année écoulée ? » et « quelqu'un a-t-il lu des enregistrements en dehors de son propre portefeuille de dossiers ? » Aucune des deux ne trouve de réponse dans des journaux de requêtes indexés par URL. L'usage abusif d'outils internes par du personnel autorisé est une catégorie d'incident couramment signalée que seul un journal de lecture permet de détecter.

Comment l'appliquer

• Journaliser au niveau du chemin de lecture applicatif avec un schéma fixe : actor, actor_type, subject_id, object, action, reason, request_id, at. Pour les lectures massives, journaliser la requête et le nombre de lignes, pas chaque ligne.
• Rendre le motif obligatoire dans les outils internes : un numéro de ticket ou une entrée choisie dans une liste, car le texte libre est difficile à analyser par la suite.
• Indexer par sujet et par acteur ; construire les deux rapports standard (par sujet dans le temps, par acteur en regard du portefeuille de dossiers attendu) avant le premier incident, pas pendant celui-ci.
• Utiliser la journalisation au niveau de la base de données pour les chemins qui contournent l'application (SQL ad hoc, migrations, analystes) et la rapprocher du journal applicatif ; une lecture sans événement applicatif correspondant constitue un constat à traiter.
• Soumettre le journal d'accès lui-même à un accès strict et à sa propre durée de conservation : il constitue des données personnelles concernant à la fois l'acteur et le sujet.
• Générer des alertes sur certains schémas : un acteur lisant de nombreux sujets sur une courte période, des lectures d'enregistrements signalés, des lectures en dehors des heures de travail pour des rôles qui n'en ont pas.

Pièges

Journaliser chaque vue en liste crée du volume sans information ; limiter le périmètre aux vues détaillées et aux exports. Un succès de cache n'atteint jamais le gestionnaire ; il faut donc journaliser au niveau de l'API de lecture, pas de l'appel à la base de données. Un journal d'accès que le personnel de support peut parcourir révèle quels collègues font l'objet d'une vérification. La journalisation des instructions au niveau de la base de données peut capturer les valeurs des paramètres, ce qui introduit des données personnelles dans le journal ; dans pgAudit, le paramètre pgaudit.log_parameter détermine si les paramètres transmis avec une instruction sont inclus.

Lectures massives et exports

Une vue en liste qui affiche cinquante clients constitue une lecture de cinquante sujets, et un export est une lecture de chacun des sujets qu'il contient ; la question centrée sur le sujet ne peut pas trouver de réponse à partir d'un texte de requête et d'un nombre, car la requête ne peut pas être rejouée plus tard sur les données telles qu'elles étaient alors. Journaliser les identifiants de sujet effectivement affichés : une vue en liste a une taille de page limitée, donc le tableau reste petit. Pour un export, stocker le manifeste des identifiants de sujet (ou une liste de hachages) avec la tâche d'export et le référencer depuis l'événement du journal d'accès. Seuls les rapports agrégés, dont les lignes ne portent aucun identifiant de sujet, sont journalisés sous la forme requête plus nombre. Le paramètre pgaudit.log_relation ajoute une ligne par relation concernée, ce qui suffit pour le rapprochement avec le journal de la base de données mais ne remplace pas les identifiants.