Classifier les données avant de les protéger

Chiffrer sans connaître la sensibilité, la finalité et les flux d’une donnée produit surtout un faux sentiment de maîtrise. La classification doit donc précéder le chiffrement, le contrôle d’accès, la journalisation et la rétention, sinon chaque équipe invente son propre degré de panique.

→ Lire l’explication complète de la marmotte

Taxonomie de classification : peu de niveaux, des effets réels

La classification répond à une question opérationnelle : quelle conséquence acceptable résulte de la divulgation, de l’altération, de l’indisponibilité ou de la conservation excessive de cette donnée ? Elle ne répond pas à « quel est le niveau de sécurité de l’application ». Une application peut traiter simultanément des données publiques, internes et très sensibles. Lui coller une seule étiquette revient à repeindre un tableau électrique en rouge et à appeler cela une analyse de risque.

Une taxonomie à quatre niveaux suffit dans la majorité des architectures :

Niveau	Exemples	Conséquence minimale
Public	documentation publiée, clés publiques, catalogue produit	intégrité et disponibilité surveillées
Interne	procédures, inventaires techniques, schémas non publics	authentification, accès limité aux populations métier
Confidentiel	contrats, données RH, journaux contenant des identifiants, secrets applicatifs	chiffrement au repos et en transit, accès nominatif, journalisation des accès
Restreint	mots de passe, clés privées, pièces d’identité, données bancaires	minimisation, accès explicitement autorisé, chiffrement avec clés séparées, export contrôlé, traçabilité renforcée

Le compromis central est là : plus la taxonomie est fine, plus les contrôles peuvent coller au risque, mais plus le classement devient coûteux à maintenir et facile à contourner. Une grille de huit niveaux impressionne parfois en comité. En production, elle finit souvent convertie en deux valeurs : « urgent » et « à voir plus tard ». La recommandation est donc de limiter la taxonomie à trois ou quatre niveaux, puis de définir des obligations techniques mesurables pour chacun.

Une classe sans effet automatique n’est qu’un autocollant. Si restreint ne modifie ni les droits, ni le chiffrement, ni la conservation, ni les règles d’export, le champ de métadonnée sert surtout à rassurer les tableurs. Chaque niveau doit déclencher au moins une décision vérifiable par contrôle automatisé.

La classification ne remplace pas l’analyse de risque. Elle fournit le vocabulaire stable qui permet de relier une donnée à des contrôles, puis à des scénarios de menace. Les méthodes de gouvernance et les analyses de risques décrites dans la section gouvernance doivent identifier les conséquences métier ; l’architecture traduit ensuite ces conséquences en mécanismes techniques.

Unité de classification : donnée, champ, objet et flux

Classer une base de données entière au niveau maximal parce qu’elle contient une colonne sensible est défendable seulement si le moteur, les vues et les exports ne savent pas isoler cette colonne. Sinon, cette décision propage des contraintes coûteuses à des données qui ne les justifient pas. À l’inverse, classer uniquement les champs tout en laissant les sauvegardes, index, journaux et exports sans étiquette laisse les copies secondaires devenir le chemin le plus facile pour un attaquant.

L’unité de classification doit suivre le point où les contrôles peuvent réellement s’appliquer :

classer le champ pour les données structurées quand les politiques d’accès, de masquage ou d’export savent le reconnaître ;
classer le document entier lorsqu’il est impossible de garantir la séparation des contenus ;
classer le jeu de données lorsqu’il est distribué en bloc, sauvegardé en bloc ou chargé dans un entrepôt analytique ;
classer le flux lorsqu’une donnée traverse une file, un proxy, une passerelle ou un service tiers.

Les métadonnées héritent généralement de la classe la plus élevée de leur contenu. Un journal contenant une adresse électronique, un jeton d’accès ou un identifiant de session est au minimum confidentiel. Un nom de fichier, une taille, une date de création ou la relation entre deux identités peuvent révéler autant qu’un contenu chiffré. Le chiffrement de transport masque le paquet, pas nécessairement les journaux du proxy ni les traces de diagnostic. Les réseaux transportent souvent des données très bavardes sous prétexte qu’elles ne sont « que des métadonnées ».

Une donnée pseudonymisée ne descend pas automatiquement de classe. Si la table de correspondance existe, si le domaine de valeurs est faible ou si plusieurs jeux peuvent être recoupés, la réidentification reste possible. Le pseudonyme est un contrôle de réduction d’exposition, pas une gomme magique avec un budget marketing.

Étiquettes, propriétaires et règles de décision

Toute donnée classée doit porter quatre métadonnées minimales : son niveau de sensibilité, son propriétaire métier, sa finalité d’usage et sa durée de conservation. Sans propriétaire, personne ne tranche les accès exceptionnels ni les changements de niveau. Sans finalité, les copies analytiques prolifèrent. Sans durée, les archives deviennent une collection de risques fossiles.

Le propriétaire métier décide de la sensibilité fonctionnelle. L’équipe technique décide des contrôles disponibles et refuse les exigences irréalisables. Cette séparation est nécessaire : demander au métier de choisir un algorithme cryptographique est absurde ; demander à l’infrastructure de décréter la nécessité d’une donnée est tout aussi fragile.

Les règles doivent être déterministes. Par exemple :

tout secret d’authentification est restreint ;
toute donnée permettant l’identification directe d’une personne est au moins confidentielle ;
tout export contenant une donnée restreinte reste restreint, même après conversion en fichier texte ;
toute agrégation dont la réidentification reste praticable conserve la classe de la source la plus sensible ;
toute donnée sans propriétaire explicite est refusée à l’ingestion ou placée en quarantaine.

Le Règlement général sur la protection des données (RGPD) peut influencer les obligations applicables aux données personnelles, mais la classification n’est pas un avis juridique. Elle doit modéliser des propriétés techniques vérifiables : identifiabilité, secret, criticité d’intégrité, durée de conservation et exposition à des tiers.

La révision doit être déclenchée par les événements qui changent le risque : nouveau flux, nouvel export, fusion de jeux de données, changement de sous-traitant, ouverture d’une interface de programmation applicative (API), modification de durée de rétention ou ajout d’une fonction d’intelligence artificielle. Revoir une classe une fois par an sans regarder les flux réels est une cérémonie administrative. Très décorative, comme un extincteur peint sur un mur.

Contrôles techniques liés à chaque classification

Une classification devient exploitable lorsque les plateformes consomment ses étiquettes. Cela impose des prérequis : un inventaire des actifs, un catalogue de données, une source d’identité centralisée, des groupes d’accès maintenus, une journalisation centralisée et une capacité à propager des métadonnées vers les stockages, sauvegardes et outils d’analyse.

Pour les données confidentielles et restreintes, les contrôles minimaux sont les suivants :

chiffrer en transit avec une version moderne de Transport Layer Security (TLS) et valider strictement les certificats ;
chiffrer au repos avec une clé distincte de la donnée, idéalement gérée par un Key Management Service (KMS) ou un Hardware Security Module (HSM) lorsque le niveau de menace le justifie ;
limiter les accès par rôle, finalité et environnement, plutôt que par appartenance vague à une équipe ;
masquer ou supprimer les champs sensibles dans les traces applicatives ;
interdire les exports non tracés et imposer un emplacement de dépôt contrôlé ;
appliquer une durée de conservation exécutable, avec purge des index, caches et sauvegardes selon une politique documentée.

Le chiffrement ne garantit pas qu’une personne autorisée n’exfiltrera pas les données après déchiffrement. Il ne garantit pas non plus la suppression d’une copie exportée, la confidentialité des captures d’écran ni la justesse d’une classification humaine. Ces garanties doivent venir des contrôles d’accès, de la prévention des pertes de données, de la surveillance, des procédures d’habilitation et de la conception applicative.

La gestion des clés mérite une décision distincte. Une clé de chiffrement de données, ou Data Encryption Key (DEK), protège le contenu. Une Key Encryption Key (KEK) protège une ou plusieurs DEK. La rotation d’une KEK peut souvent se faire par ré-enveloppement ; la rotation d’une DEK impose généralement de rechiffrer les données. Confondre les deux transforme une maintenance de clés en opération de migration massive, avec le calme habituel d’un éléphant dans une salle serveur. Les règles d’exploitation sont détaillées dans la section cryptographie.

Exemple de contrôle automatique des étiquettes

Un contrôle d’intégration doit refuser un manifeste qui déclare une donnée sensible sans propriétaire, sans durée de conservation ou sans chiffrement requis. Le script suivant fonctionne avec Python 3.11 ou version supérieure et ne dépend d’aucune bibliothèque externe.

#!/usr/bin/env python3
# exécution : python3 verifier_classification.py manifeste.json

import json
import sys

with open(sys.argv[1], encoding="utf-8") as fichier:
    objet = json.load(fichier)

niveaux = {"public", "interne", "confidentiel", "restreint"}
niveau = objet.get("classification")
erreurs = []

if niveau not in niveaux:
    erreurs.append("classification absente ou inconnue")

if not objet.get("proprietaire"):
    erreurs.append("proprietaire obligatoire")

if not objet.get("retention_jours"):
    erreurs.append("retention_jours obligatoire")

if niveau in {"confidentiel", "restreint"} and not objet.get("chiffrement_requis"):
    erreurs.append("chiffrement_requis obligatoire pour cette classification")

if niveau == "restreint" and not objet.get("journalisation_acces"):
    erreurs.append("journalisation_acces obligatoire pour restreint")

if erreurs:
    print("REFUS :", "; ".join(erreurs))
    sys.exit(1)

print("OK :", objet["nom"], "est classé", niveau)

Le manifeste associé peut être versionné avec le schéma de données :

{
  "nom": "export-facturation",
  "classification": "restreint",
  "proprietaire": "finance",
  "retention_jours": 365,
  "chiffrement_requis": true,
  "journalisation_acces": true
}

Ce type de vérification ne découvre pas automatiquement les données sensibles. Il empêche seulement qu’un objet déclaré contourne les règles minimales. La détection de contenu, par expressions régulières, dictionnaires ou modèles statistiques, produit des faux positifs et des faux négatifs. Elle doit assister la classification, jamais la remplacer sans validation humaine.

Surface d’attaque et exploitation durable

Les attaques contre la classification visent souvent ses angles morts plutôt que son référentiel : copie vers un stockage personnel, export de support, journal trop bavard, environnement de test alimenté par la production, sauvegarde hors périmètre, droits hérités ou compte de service surprivilégié. Un attaquant n’a pas besoin de casser le chiffrement s’il peut demander une exportation légitime à un compte légitime.

La contre-mesure consiste à relier les classes aux chemins de données : bases, objets, files, journaux, sauvegardes, postes d’administration et services externes. Chaque nouvelle destination doit accepter l’étiquette, ou le flux doit être refusé. Les outils qui perdent les métadonnées lors d’une exportation sont incompatibles avec une classification pilotant la sécurité. Ce défaut doit être traité comme une limite d’architecture, pas comme une note de bas de page.

La supervision doit détecter les changements de classe, les exports de données confidentielles, les accès hors plages habituelles, les échecs de chiffrement et les objets sans étiquette. Un système d’information et de gestion des événements de sécurité, ou Security Information and Event Management (SIEM), centralise ces événements, mais ne répare pas une source qui ne journalise rien. Un tableau de bord sans événements fiables reste un aquarium vide, avec de très beaux graphiques.

Les sauvegardes héritent de la classe des données restaurables qu’elles contiennent. Elles exigent chiffrement, contrôle d’accès, inventaire, durée de conservation et tests de restauration. La destruction d’une donnée primaire sans destruction coordonnée des sauvegardes ne réduit pas l’exposition au rythme espéré. Elle la déplace vers l’endroit que personne ne regarde, ce qui est rarement une stratégie brillante.

🐝 Ce qui arrive si on s’en passe

Sans classification, rien ne garde la porte au moment où il faudrait trier. La qualification d’un incident devient impossible à borner : on constate un accès, mais pas la nature des enregistrements touchés, donc ni le périmètre de notification, ni la priorité de reprise, ni l’ordre de restauration des sauvegardes. Les règles de détection de fuite n’ont plus de critère à appliquer, faute de niveau attaché à l’objet. Les demandes de suppression ou d’extraction ne sont plus traçables, puisque personne ne sait où les copies sont parties. Le budget de protection se répartit au hasard : contrôles lourds sur du catalogue produit, contrôles absents sur des secrets. Enfin, toute ouverture vers un tiers se négocie sans référence commune, ce qui rend les engagements contractuels invérifiables techniquement.

🦫 Explication de la marmotte 🍫

La classification consiste à attribuer un niveau de sensibilité à chaque donnée ou groupe de données. Ce niveau dépend des dégâts possibles si la donnée est vue par une mauvaise personne, modifiée, perdue ou gardée trop longtemps. Une adresse électronique, un document interne, un mot de passe et une clé de chiffrement ne reçoivent donc pas les mêmes règles.

Le travail commence par repérer les données, leurs propriétaires, leurs usages et leurs destinations. Chaque élément reçoit ensuite une étiquette, par exemple public, interne, confidentiel ou restreint. Cette étiquette doit être enregistrée avec la donnée et transmise quand elle est copiée, exportée ou sauvegardée.

Les outils appliquent alors des règles selon le niveau : demander une authentification, limiter les personnes autorisées, chiffrer le contenu, enregistrer les accès, interdire certains exports ou supprimer la donnée après une durée définie. Les données les plus sensibles demandent davantage de preuves avant un accès et davantage de traces après cet accès.

Le système échoue si une copie perd son étiquette, si un journal contient des secrets, si une sauvegarde reste accessible ou si personne n’est responsable de la donnée. Le chiffrement ne suffit pas : une personne autorisée peut encore copier ce qu’elle lit. Il faut donc combiner classement, droits d’accès, surveillance, sauvegardes protégées et suppression contrôlée.

Pages voisines

La citent

Classifier les données avant de les protéger

Elle cite

: les deux pages se citent l’une l’autre.

Classifier les données avant de les protéger

Classifier les données avant de les protéger

Taxonomie de classification : peu de niveaux, des effets réels

Unité de classification : donnée, champ, objet et flux

Étiquettes, propriétaires et règles de décision

Contrôles techniques liés à chaque classification

Exemple de contrôle automatique des étiquettes

Surface d’attaque et exploitation durable

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines