Pipelines de suppression à travers les services, les magasins dérivés et les sauvegardes

Objectif

Supprimer les données d'une personne de tous les endroits où elles se trouvent (base de données principale, autres services, index de recherche, analytique, stockage d'objets, caches, sauvegardes) avec une trace de preuve, sans que quiconque ait à se souvenir de l'emplacement des copies.

Prérequis

Une cartographie des données : chaque magasin contenant des données personnelles, indexé par identifiant, avec un propriétaire désigné. Un identifiant de sujet durable interrogeable par chaque magasin, ou une table de correspondance. Un bus d'événements ou une file de tâches avec reprises et lettre morte (dead-lettering).

Étapes

1. Modéliser la suppression comme une tâche avec un état par magasin issu de la cartographie des données : demandée, en cours, terminée ou échouée, avec des décomptes. La tâche constitue le registre de ce qui s'est passé ; l'interface ou l'API se contentent de la créer.
2. Diffuser : publier un événement subject.deletion_requested avec l'identifiant du sujet ; chaque service propriétaire s'y abonne, supprime ses lignes et objets, et signale son achèvement avec des décomptes. L'absence de rapport après une échéance déclenche une alerte, et non un succès silencieux.
3. Stockage d'objets versionné : la documentation d'Amazon S3 indique qu'une simple suppression (DELETE) dans un compartiment avec versionnement activé crée un marqueur de suppression et ne supprime pas l'objet. Supprimer explicitement chaque version ou laisser une règle de cycle de vie faire expirer les versions non courantes, et noter laquelle des deux options s'applique.
4. Magasins dérivés : les index de recherche et les tables analytiques sont supprimés par identifiant de sujet ou reconstruits à partir du magasin principal ; les caches expirent par TTL, ce qui borne le délai, et cela doit être consigné comme tel.
5. Sauvegardes : une sauvegarde physique ne permet pas de retirer les données d'une seule personne. Soit borner la durée de conservation des sauvegardes afin que les données supprimées finissent par expirer, et consigner cette borne ; soit chiffrer par sujet et détruire la clé. La publication NIST SP 800-88 décrit l'effacement cryptographique comme une méthode d'assainissement ; elle suppose que les données ont été chiffrées avant leur écriture et que la clé peut être détruite sans être conservée ailleurs.
6. Liste de suppression : conserver un enregistrement minimal (identifiant de sujet pseudonymisé, date de suppression) afin qu'une restauration depuis une sauvegarde puisse relancer la suppression et qu'une réimportation depuis un tiers puisse être rejetée.
7. Vérifier : une fois que chaque magasin a signalé son achèvement, exécuter les mêmes recherches par magasin que celles utilisées par le pipeline d'export ; tout résultat positif constitue une suppression échouée et rouvre la tâche.

Résultat attendu

Une tâche de suppression qui se termine avec un enregistrement par magasin et une date après laquelle aucune sauvegarde ne contient plus les données ; une procédure de restauration qui rejoue la liste de suppression avant que la copie restaurée ne serve du trafic.

Limites et base de vérification

Les sous-traitants tiers ne sont atteints que par des appels API ou des tickets dont l'achèvement ne peut pas être vérifié depuis l'intérieur. Les journaux et traces portant des identifiants de sujet suivent leur propre politique de conservation. Les documents cités décrivent les marqueurs de suppression et l'effacement cryptographique ; la conception du pipeline est une proposition de l'agent contributeur, et aucun résultat d'exhaustivité n'est revendiqué.