Qualité des données et erreurs silencieuses

Une donnée erronée peut produire le même effet opérationnel qu’une fuite : attribution d’un droit indu, exclusion d’un contrôle, mauvaise déclaration ou décision prise sur une information falsifiée. La différence est moins rassurante qu’elle en a l’air : la fuite est visible parce qu’elle sort, l’erreur silencieuse reste dedans et pilote le système.

→ Lire l’explication complète de la marmotte

Intégrité des données et impact sécurité

L’intégrité désigne la propriété selon laquelle une donnée est exacte, complète, cohérente et rattachable à une origine connue. En sécurité, ce n’est pas une qualité esthétique de tableur. Une erreur sur un attribut d’identité, un périmètre réseau ou une classification de données peut modifier une autorisation sans exploiter de vulnérabilité logicielle.

Un annuaire qui marque un compte désactivé comme actif, un référentiel qui associe un terminal à la mauvaise équipe ou une table de routage qui contient un préfixe erroné créent des privilèges involontaires. Le contrôle d’accès fonctionne alors exactement comme prévu, sur une donnée fausse. C’est plus gênant qu’un bug franc : aucun composant ne considère avoir échoué.

Le compromis central est brutal : contrôler chaque donnée ralentit les flux, augmente les rejets et impose une gouvernance coûteuse. Accepter les données au fil de l’eau préserve la disponibilité apparente, mais transforme les erreurs en dette de sécurité. Pour les données qui déterminent un droit, une exposition ou une obligation de conservation, il faut trancher en faveur du rejet bloquant. Une file qui attend vaut mieux qu’une autorisation accordée sur une identité bricolée.

Toutes les erreurs ne méritent pas le même traitement. Une faute dans un champ de commentaire peut être corrigée après coup. Une valeur absente dans un attribut is_privileged, un propriétaire de clé ou une étiquette de confidentialité doit interrompre le traitement. Le modèle de qualité doit donc classer les champs par effet de sécurité, pas par confort analytique. Les présentations vendeurs parlent volontiers de « data trust ». Un NULL dans une règle d’autorisation reste un NULL, même emballé dans un nuage pastel.

La confidentialité, l’intégrité et la disponibilité forment les trois propriétés classiques de sécurité. Une erreur silencieuse attaque surtout l’intégrité, mais peut provoquer une fuite secondaire. Une classification erronée peut envoyer un export restreint vers un stockage trop ouvert. Une adresse électronique mal résolue peut distribuer une pièce jointe au mauvais destinataire. La fuite n’est alors que la dernière étape d’une chaîne commencée bien plus tôt.

Les principes d’architecture cyber doivent traiter les sources de données comme des frontières de confiance. Une base interne n’est pas fiable par nature : elle peut recevoir des synchronisations incomplètes, des imports manuels, des corrections d’urgence ou des écritures applicatives concurrentes. Le réseau privé n’a jamais rendu une valeur vraie. Il rend seulement l’erreur plus difficile à observer.

Contrats de schéma, provenance et rejets bloquants

Un contrat de données définit les champs attendus, leurs types, leurs valeurs autorisées, leurs relations et la version du format. Il doit être exécutable, pas seulement dessiné dans un wiki destiné à prendre la poussière avec dignité. Une spécification non appliquée décrit l’état d’esprit, pas l’état des données.

Les contrôles minimums sont les suivants :

vérifier le type, le format et le domaine de chaque champ sensible ;
imposer les relations de référence, par exemple un propriétaire existant pour une ressource ;
refuser les valeurs ambiguës, notamment les identifiants vides, les dates sans fuseau ou les booléens représentés par texte libre ;
détecter les doublons sur les clés métier, pas seulement sur une clé technique générée ;
versionner le schéma et rejeter une version inconnue ;
conserver l’origine, l’horodatage d’ingestion et l’identifiant du lot ;
isoler les enregistrements rejetés dans une zone de quarantaine non consommée par les systèmes de décision.

La validation syntaxique ne suffit pas. owner_id=42 est syntaxiquement parfait même si l’identifiant 42 désigne une personne ayant quitté l’organisation. La validation sémantique doit vérifier la cohérence avec le référentiel d’autorité, c’est-à-dire la source qui a le droit de dire quel compte, équipement ou contrat existe réellement.

Les synchronisations d’identité illustrent bien le problème. Un flux peut supprimer temporairement un groupe lors d’un incident de source, puis le recréer. Si la cible interprète l’absence comme une suppression immédiate, elle coupe des accès légitimes. Si elle ignore l’absence, elle conserve des accès devenus indus. Le choix dépend du niveau de privilège : pour un groupe d’administration, appliquer une révocation rapide avec une alerte sur anomalie de volumétrie ; pour une population large, utiliser une période de grâce explicitement bornée. Il n’existe pas de réglage magique, seulement des conséquences à assumer.

La provenance doit être protégée contre l’altération. Un HMAC (Hash-based Message Authentication Code) permet de vérifier qu’un lot provient d’un émetteur détenant une clé partagée et qu’il n’a pas été modifié. Une signature asymétrique permet de dissocier la clé de signature de la clé de vérification, ce qui limite les systèmes autorisés à produire des lots. Le choix dépend de la frontière de confiance : HMAC entre composants sous même contrôle de clés, signature quand plusieurs consommateurs doivent vérifier sans pouvoir émettre.

Ni le HMAC ni la signature ne garantissent que le contenu est vrai. Ils garantissent l’origine cryptographique et l’intégrité du message signé. Une source compromise peut signer parfaitement une donnée fausse. La détection doit donc comparer les changements à des seuils métier : explosion d’attributions de rôles, disparition soudaine de propriétaires, modification massive de classifications. La cryptographie ne répare pas une réalité administrative cassée. Elle empêche seulement de prétendre que la cassure est arrivée en transit.

Validation relationnelle avec PostgreSQL

Les contraintes du moteur de base de données doivent porter les règles dont dépend une décision de sécurité. PostgreSQL 15 ou version ultérieure fournit les contraintes de domaine, d’unicité, de clé étrangère et de contrôle nécessaires à ce socle. L’application peut compléter les règles, mais ne doit pas être la seule gardienne : un script d’import, une interface d’administration ou une migration contournera tôt ou tard une validation purement applicative.

L’exemple suivant crée un référentiel minimal de ressources. Une ressource ne peut être classifiée qu’avec une valeur autorisée et son propriétaire doit exister et être actif. Une suppression de propriétaire est bloquée tant que des ressources le référencent.

-- PostgreSQL 15+ : exécuter avec psql sur une base de test.
CREATE TABLE identities (
  id uuid PRIMARY KEY,
  status text NOT NULL CHECK (status IN ('active', 'disabled'))
);

CREATE TABLE assets (
  id uuid PRIMARY KEY,
  owner_id uuid NOT NULL REFERENCES identities(id) ON DELETE RESTRICT,
  classification text NOT NULL
    CHECK (classification IN ('public', 'internal', 'restricted')),
  source_event_id uuid NOT NULL UNIQUE,
  received_at timestamptz NOT NULL DEFAULT now()
);

-- Rejet attendu : un propriétaire désactivé ne doit pas recevoir de ressource.
CREATE OR REPLACE FUNCTION enforce_active_owner()
RETURNS trigger LANGUAGE plpgsql AS $$
BEGIN
  IF NOT EXISTS (
    SELECT 1 FROM identities
    WHERE id = NEW.owner_id AND status = 'active'
  ) THEN
    RAISE EXCEPTION 'owner_id absent ou désactivé';
  END IF;
  RETURN NEW;
END;
$$;

CREATE TRIGGER assets_active_owner
BEFORE INSERT OR UPDATE OF owner_id ON assets
FOR EACH ROW EXECUTE FUNCTION enforce_active_owner();

La contrainte source_event_id UNIQUE apporte une propriété souvent oubliée : l’idempotence. Un même événement rejoué ne doit pas créer deux ressources ni déclencher deux effets secondaires. Les attaques par rejeu ne ciblent pas toujours les jetons d’authentification. Rejouer un événement de changement de rôle, de commande ou de révocation peut suffire à restaurer un état obsolète.

Le déclencheur ne remplace pas les contrôles du flux d’ingestion. Il protège l’état final de la base. Un lot invalide doit également être journalisé avec son identifiant, sa version de schéma, son émetteur et le motif précis du rejet. Ne pas conserver la charge utile sensible en clair dans les journaux : une plateforme d’observabilité devient vite un entrepôt de secrets avec un tableau de bord. La page sur les données doit rester la référence pour les règles de classification et de conservation applicables aux flux.

Surface d’attaque des flux de données

Une erreur silencieuse peut résulter d’un défaut, mais aussi d’une attaque. Les mêmes contrôles couvrent souvent les deux cas, ce qui évite de séparer artificiellement qualité et cybersécurité jusqu’à ce que les deux équipes se découvrent lors d’un incident.

L’attaque par substitution consiste à modifier un identifiant de référence sans casser le format. Une clé étrangère valide ne détecte pas qu’une ressource a été rattachée au mauvais propriétaire. Il faut comparer les transitions autorisées : un changement de propriétaire doit provenir d’un événement métier identifié, être attribué à un acteur et respecter une politique d’approbation pour les ressources sensibles.

L’attaque par réduction retire des lignes ou des attributs afin de faire disparaître une obligation. Une synchronisation partielle qui omet les comptes désactivés peut laisser des droits actifs sur la cible. Chaque lot doit publier son périmètre attendu, son nombre d’objets et un identifiant de séquence. Une chute hors seuil doit bloquer la propagation ou la placer en quarantaine. Le seuil seul ne protège pas contre une suppression graduelle ; il faut aussi suivre la dérive dans le temps.

L’attaque par confusion exploite les représentations multiples : caractères Unicode visuellement proches, casse variable, espaces invisibles, formats de date ambigus ou unités différentes. Normaliser avant comparaison, conserver la valeur brute à des fins de preuve et définir une représentation canonique. Une normalisation destructrice doit être documentée : supprimer les accents d’un identifiant peut créer une collision, ce qui est une propriété remarquablement peu poétique pour un système de droits.

L’attaque par ordre vise les systèmes qui appliquent les événements selon leur arrivée. Un événement ancien reçu après une révocation peut restaurer un privilège. Chaque objet doit porter une version monotone ou un horodatage fiable, et le consommateur doit refuser les retours en arrière. L’horloge doit être synchronisée par NTP (Network Time Protocol), mais une heure correcte ne suffit pas si l’émetteur peut choisir librement son horodatage.

Exploitation, rotation et reprise des contrôles

Les contrôles de qualité doivent être supervisés comme des contrôles de sécurité. Mesurer le taux de rejet, la proportion de valeurs inconnues, les violations de référentiel, les événements rejoués et le retard entre émission et ingestion. Une alerte doit être associée à une action : bloquer, basculer en quarantaine, ouvrir une investigation ou déclencher une resynchronisation. Une métrique sans décision associée est une décoration murale avec plus de cardinalité.

Les clés de signature ou de HMAC doivent être stockées dans un KMS (Key Management Service) ou un HSM (Hardware Security Module) lorsque l’exposition le justifie. Leur rotation impose une période où le consommateur accepte l’ancienne et la nouvelle clé, identifiées par un key_id. Retirer l’ancienne clé avant la fin de rétention des lots rend la vérification historique impossible. La conserver indéfiniment transforme la rotation en cérémonie folklorique.

Les sauvegardes doivent contenir les données, les schémas versionnés, les règles de validation et les journaux d’audit nécessaires à la relecture. Restaurer une base sans restaurer les contraintes ou les référentiels d’autorité recrée un état exploitable mais non fiable. Tester la reprise avec des lots invalides, des événements anciens et des signatures sous clé retirée. Une reprise qui ne vérifie que la disponibilité redémarre volontiers l’erreur avec une ponctualité admirable.

La qualité ne garantit pas la confidentialité, l’autorisation correcte ou l’absence de compromission de source. Ces garanties doivent venir du contrôle d’accès, du chiffrement, de la segmentation réseau et de la supervision. Les mécanismes de qualité réduisent le risque de prendre une mauvaise décision à partir d’une donnée admise. Ils ne transforment pas une source compromise en oracle de vérité. Les mécanismes de gouvernance doivent donc désigner les propriétaires de données et les règles de correction, faute de quoi la quarantaine devient simplement un cimetière mieux rangé.

🐝 Ce qui arrive si on s’en passe

Sans contrats exécutables, quarantaine et journal des rejets, la porte reste ouverte à des enregistrements que rien ne distingue des enregistrements légitimes. Le coût se paie surtout après coup : impossible d’établir a posteriori quelles décisions (attributions de rôles, classifications, exports) reposaient sur une valeur fausse, donc impossible de délimiter le périmètre à rejouer ou à corriger. La revue d’accès perd son sens : elle valide une donnée erronée et la transforme en état de référence approuvé. Sans identifiant de lot, version de schéma et motif de rejet conservés, l’analyse ne peut plus trancher entre un défaut d’ingestion et une manipulation volontaire, ce qui retarde la qualification de l’incident. La remédiation se réduit alors à une resynchronisation globale, coûteuse, qui efface les traces nécessaires à la preuve et laisse les correctifs eux-mêmes sans contrôle.

🦫 Explication de la marmotte 🍫

Une erreur silencieuse apparaît quand un système reçoit une information fausse ou incomplète, l’accepte, puis continue à travailler sans signaler de problème. Cela peut concerner le nom du responsable d’un fichier, le niveau de secret d’un document, l’état d’un compte ou le droit d’accéder à une application. Si cette information sert à décider qui peut faire quoi, une erreur peut ouvrir un accès interdit ou envoyer une donnée à la mauvaise personne.

Pour éviter cela, le système doit d’abord vérifier la forme de chaque information : type attendu, valeur autorisée et présence des champs obligatoires. Il doit ensuite vérifier les liens entre les informations. Par exemple, un fichier ne peut pas avoir pour responsable une personne absente de la liste officielle ou désactivée.

Chaque arrivée de données doit aussi indiquer sa provenance et son ordre. Une preuve cryptographique peut montrer que le message n’a pas été modifié pendant le transport, mais elle ne prouve pas que son contenu est vrai. Il faut donc surveiller les changements inhabituels, comme une hausse brutale des accès accordés.

Quand un contrôle échoue, la donnée ne doit pas être utilisée pour décider. Elle est mise à part, enregistrée avec la raison du refus, puis corrigée par la source responsable. Les sauvegardes doivent conserver les règles de vérification, sinon une restauration peut remettre des données sans leurs protections.

Pages voisines

La citent

Qualité des données et erreurs silencieuses

Elle cite

Qualité des données et erreurs silencieuses

Qualité des données et erreurs silencieuses

Intégrité des données et impact sécurité

Contrats de schéma, provenance et rejets bloquants

Validation relationnelle avec PostgreSQL

Surface d’attaque des flux de données

Exploitation, rotation et reprise des contrôles

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines