Comment minimiser les données collectées

La minimisation des données consiste à ne collecter, transformer et conserver que les attributs nécessaires à une finalité explicitement définie. Ce n’est pas une option de conformité ajoutée après coup : c’est une décision d’architecture qui réduit les fuites, les coûts d’exploitation et le rayon d’impact d’une compromission.

→ Lire l’explication complète de la marmotte

Le compromis de la minimisation des données

Collecter moins réduit l’observabilité, limite certaines analyses a posteriori et oblige à concevoir des flux métier plus précis. En échange, une exfiltration expose moins d’informations, une demande d’effacement touche moins de systèmes et une sauvegarde contient moins de matière sensible. Le compromis est net : on paie en capacité d’analyse, on gagne en réduction structurelle du risque.

La recommandation est de partir de la décision métier à prendre, puis de remonter vers les attributs strictement requis. Partir du schéma de base de données existant produit l’inverse : chaque colonne devient soudain « potentiellement utile », formule qui a détruit plus de programmes de minimisation que les pirates n’en détruiront jamais.

Une donnée est nécessaire si son absence empêche une action définie : authentifier un compte, livrer une commande, détecter une fraude identifiée ou produire une preuve attendue. Une donnée n’est pas nécessaire parce qu’elle pourrait servir à une future segmentation commerciale, à une analyse encore inconnue ou à un tableau de bord dont personne n’est propriétaire.

Le Règlement général sur la protection des données impose une logique de proportionnalité, mais l’argument principal reste technique. Une adresse de messagerie, un identifiant de terminal, une adresse Internet Protocol (IP), un horodatage précis ou une combinaison de métadonnées peuvent permettre de réidentifier une personne. La distinction confortable entre « donnée métier » et « donnée personnelle » ne tient pas longtemps face à une jointure bien placée.

La minimisation doit couvrir quatre dimensions :

Collecte : ne pas accepter un champ qui n’est pas requis par le flux courant.
Précision : stocker une date plutôt qu’une heure, une tranche géographique plutôt qu’une position exacte, un statut plutôt qu’un historique complet.
Durée : supprimer à échéance plutôt que promettre un nettoyage manuel, ce cimetière des bonnes intentions.
Diffusion : empêcher qu’un attribut collecté pour un service devienne disponible par défaut dans les journaux, exports et outils d’analyse.

Finalités, contrats de données et schémas minimaux

Chaque flux doit disposer d’un contrat de données : une description versionnée des attributs entrants, de leur finalité, de leur durée de conservation, de leurs destinataires et de leur niveau de sensibilité. Ce contrat appartient à l’architecture, pas à un tableur isolé entre deux dossiers d’audit.

Une finalité doit être formulée comme une opération vérifiable. « Améliorer l’expérience » n’est pas une finalité exploitable. « Empêcher plus de cinq tentatives de connexion échouées depuis un même identifiant sur quinze minutes » en est une. La première autorise une collecte sans plafond. La seconde permet de déduire les champs requis : identifiant pseudonymisé, résultat, fenêtre temporelle et compteur.

La pseudonymisation remplace un identifiant direct par une valeur dérivée, généralement calculée avec une fonction de hachage à clé. Elle réduit l’exposition opérationnelle, mais ne rend pas la donnée anonyme : celui qui possède la clé ou une table de correspondance peut relier la valeur à la personne. Une valeur pseudonymisée reste donc dans le périmètre de protection.

Pour des identifiants peu variés, un hachage sans clé est insuffisant. Hacher admin@example.net avec SHA-256 (Secure Hash Algorithm 256 bits) ne protège rien contre un dictionnaire d’adresses probables. Utiliser un HMAC (Hash-based Message Authentication Code) avec une clé secrète empêche cette attaque hors ligne, sous réserve de protéger et de faire tourner cette clé.

La granularité est souvent le levier le plus rentable. Un système de supervision n’a pas nécessairement besoin d’une adresse IP complète pour détecter un incident. Selon le cas, une catégorie réseau, un préfixe tronqué ou un compteur par zone suffit. Un moteur de recherche n’a pas nécessairement besoin du texte intégral d’un document pour afficher une statistique de consultation. La donnée brute est rarement la seule réponse, même si elle flatte beaucoup les présentations sur la « data-driven company ».

Le schéma minimal doit aussi séparer les domaines. L’identifiant de facturation ne doit pas devenir l’identifiant universel des journaux d’accès. Créer des identifiants distincts par finalité limite les rapprochements accidentels et réduit la portée d’un export. Cette séparation complète les principes traités dans la page sur les identités et leurs frontières.

Exemple de stockage minimisé pour les événements d’accès

L’exemple suivant crée une table PostgreSQL destinée à mesurer les refus d’accès sans stocker d’adresse IP, d’agent utilisateur complet ni d’adresse de messagerie. L’identifiant est pseudonymisé par HMAC côté application avant insertion. La base conserve une date, pas une précision à la milliseconde qui ne sert ici qu’à reconstruire des biographies involontaires.

-- PostgreSQL 15 ou version ultérieure.
-- La valeur subject_tag provient d'un HMAC-SHA-256 calculé hors de la base.
CREATE TABLE access_denial_daily (
    event_day date NOT NULL,
    subject_tag char(64) NOT NULL,
    denial_reason text NOT NULL CHECK (
        denial_reason IN ('bad_password', 'locked_account', 'disabled_account')
    ),
    attempts smallint NOT NULL CHECK (attempts BETWEEN 1 AND 255),
    PRIMARY KEY (event_day, subject_tag, denial_reason)
);

-- Conservation limitée à 30 jours, à exécuter quotidiennement
-- par le planificateur de la plateforme.
DELETE FROM access_denial_daily
WHERE event_day < current_date - INTERVAL '30 days';

-- Agrégation sans conserver l'événement brut ni l'adresse réseau.
INSERT INTO access_denial_daily (
    event_day, subject_tag, denial_reason, attempts
) VALUES (
    current_date,
    'b7f9c6ecf48f7d59aa8d692f933a17f6d2fe8df6ef4b6040ec58f0fc0eeffab0',
    'bad_password',
    1
)
ON CONFLICT (event_day, subject_tag, denial_reason)
DO UPDATE SET attempts = access_denial_daily.attempts + 1;

Ce modèle ne permet pas d’enquêter sur l’origine réseau exacte d’une tentative refusée. C’est assumé. Si cette information est réellement requise pour une détection donnée, il faut la conserver dans un flux séparé, avec une durée plus courte, des accès distincts et une justification opérationnelle documentée.

Le secret HMAC doit résider dans un gestionnaire de secrets ou un HSM (Hardware Security Module) lorsque la plateforme en dispose. Une rotation de clé casse la corrélation historique si aucun mécanisme de versionnement n’est prévu. La solution consiste à stocker une version de clé non secrète avec le tag, puis à accepter temporairement deux versions lors de la rotation. Ne jamais recalculer en masse les anciens tags avec une nouvelle clé à partir des identifiants source : cela suppose précisément de conserver ce que l’architecture cherche à éliminer.

Surface d’attaque des données collectées

Chaque attribut supplémentaire crée au moins quatre chemins d’exposition : accès applicatif, journalisation, sauvegarde et export. À cela s’ajoutent les environnements de test, les outils de support, les copies analytiques et les index de recherche. La donnée n’est jamais « dans une table ». Elle voyage, se duplique, s’indexe et finit parfois dans un fichier CSV, forme de vie qui survit manifestement à toutes les politiques de sécurité.

Les attaques les plus fréquentes contre un patrimoine de données trop large sont prévisibles :

Exfiltration applicative : une injection, une autorisation défaillante ou un compte de service compromis donne accès à plus d’attributs que nécessaire. La contre-mesure est l’accès par vue ou requête dédiée, jamais SELECT * sur la table de référence.
Réidentification : plusieurs attributs peu sensibles, combinés, identifient une personne. Réduire la précision, séparer les jeux de données et interdire les jointures non justifiées réduisent ce risque.
Collecte indirecte : les en-têtes Hypertext Transfer Protocol (HTTP), paramètres d’URL, traces d’erreur et journaux de proxy capturent des identifiants sans que le schéma métier ne les mentionne. Il faut filtrer avant écriture, pas seulement masquer à l’affichage.
Vol de sauvegardes : une suppression dans la base primaire ne retire pas les copies historiques. Les sauvegardes doivent être chiffrées, cataloguées, accessibles avec des identités séparées et soumises à une durée de rétention définie.

La minimisation ne garantit ni la confidentialité ni l’intégrité. Une table réduite mais ouverte à Internet reste une mauvaise idée, même si elle ne contient que des couleurs préférées. Le reste doit venir du contrôle d’accès, du chiffrement, du cloisonnement réseau et de la supervision. Les principes de cryptographie appliquée complètent la réduction des données, ils ne la remplacent pas.

Exploitation, rétention et suppression vérifiable

Une règle de rétention sans mécanisme d’exécution est un souhait formulé en langage administratif. Chaque jeu de données doit avoir une date d’expiration calculable, une tâche de suppression automatisée, une métrique d’exécution et une alerte sur échec. Mesurer le nombre de lignes supprimées, l’âge maximal observé et le nombre de jeux hors délai permet de détecter rapidement une dérive.

La suppression doit couvrir les index, caches, files de messages, exports et sauvegardes. Pour les sauvegardes immuables, la suppression immédiate est souvent impossible. Il faut alors définir une durée de rétention compatible avec la sensibilité des données avant de les intégrer à ces sauvegardes. Chiffrer une sauvegarde et détruire la clé de chiffrement peut rendre son contenu irrécupérable, mais cette destruction doit être attestée et la clé ne doit pas avoir été dupliquée dans trois coffres différents, ce qui arrive avec une régularité presque artistique.

Les journaux exigent une discipline particulière. Interdire les données personnelles dans les messages applicatifs, filtrer les en-têtes sensibles au niveau du proxy et remplacer les valeurs par des identifiants de corrélation éphémères. Un identifiant de corrélation doit être aléatoire, non dérivé d’un compte, et expirer avec le diagnostic qu’il sert.

La supervision doit détecter les régressions de schéma : apparition d’une colonne non approuvée, hausse brutale de taille, journal contenant un motif d’adresse de messagerie ou de numéro de téléphone, export vers une destination non déclarée. La minimisation n’est pas un état stable. Une fonctionnalité, un logiciel de suivi ou un connecteur d’analyse peut la défaire en une livraison. Le contrôle doit donc être intégré à la revue de conception et à l’intégration continue.

🐝 Ce qui arrive si on s’en passe

Sans minimisation, la question posée après un incident devient insoluble : déterminer qui est concerné suppose de reconstituer le périmètre exact d’attributs présents dans chaque copie, exercice impossible quand aucun contrat de données ne décrit la finalité ni les destinataires. Le délai de notification se consomme alors en inventaire. Une demande d’effacement se propage mal : chaque export non déclaré, chaque environnement de recette alimenté par une copie de production réintroduit ce qui a été supprimé en base primaire. Le coût opérationnel suit la même pente, puisque volume conservé signifie volume à chiffrer, à sauvegarder, à indexer et à auditer. Enfin, une réquisition judiciaire ou une demande d’un tiers porte sur ce qui existe, pas sur ce qui était utile : conserver davantage revient à élargir mécaniquement ce qui devra être remis.

🦫 Explication de la marmotte 🍫

Réduire les données consiste à commencer par une question précise : quelle action doit être réalisée ? Pour chaque action, on liste les informations indispensables et on refuse les autres. Si un service doit compter des échecs de connexion, il peut conserver un identifiant transformé, la raison de l’échec et la date. Il n’a pas forcément besoin de garder le nom complet, l’adresse de messagerie, l’adresse réseau ou tous les détails du téléphone utilisé.

Les informations conservées doivent aussi être moins précises quand la précision ne sert à rien. Une date peut remplacer une heure exacte. Une zone générale peut remplacer une position détaillée. Les informations sont séparées selon leur usage pour éviter qu’un même identifiant permette de tout relier.

La suppression doit être programmée dès la création de la donnée. Un programme efface les informations arrivées à expiration et vérifie que cette opération a bien eu lieu. Les copies, les journaux techniques et les sauvegardes doivent suivre la même règle, sinon les données supprimées restent accessibles ailleurs.

Cette méthode ne bloque pas une attaque à elle seule. Il faut toujours limiter les accès, protéger les secrets et surveiller les systèmes. Mais si une fuite survient, moins de données existent à voler, à recouper ou à utiliser contre les personnes concernées.

Pages voisines

La citent

Comment minimiser les données collectées

Elle cite

Comment minimiser les données collectées

Comment minimiser les données collectées

Le compromis de la minimisation des données

Finalités, contrats de données et schémas minimaux

Exemple de stockage minimisé pour les événements d’accès

Surface d’attaque des données collectées

Exploitation, rétention et suppression vérifiable

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines