Gouvernance d’un data lake et copie des données

Un data lake centralise des données brutes, transformées et parfois hautement sensibles dans un même plan de stockage. Le compromis est brutal : on gagne en disponibilité analytique et en réutilisation, on paie une explosion de la surface d’accès, des copies impossibles à recenser et une dette de gouvernance qui finit par coûter plus cher que le stockage.

→ Lire l’explication complète de la marmotte

Le compromis central : réutilisation contre perte de maîtrise

Un data lake ne doit pas être considéré comme une base de données géante. Il s’agit d’un espace de stockage partagé, généralement objet, qui accueille des fichiers de formats et de qualités hétérogènes. CSV (Comma-Separated Values), Parquet, JSON (JavaScript Object Notation), exports applicatifs, journaux techniques et jeux enrichis y coexistent. Cette souplesse attire les équipes comme une prise multiple attire les chargeurs douteux.

Le gain est réel : réduire les extractions point à point, permettre l’analyse transverse et conserver une source brute rejouable. La facture arrive lorsque chaque consommateur fabrique sa propre copie, applique ses propres filtres et republie un jeu dérivé dans une zone non inventoriée. Une donnée personnelle retirée de la source reste alors présente dans les exports, les tables matérialisées, les caches de moteur analytique et les sauvegardes. La suppression logique devient une fiction administrative avec des fichiers Parquet.

La position à tenir est simple : un data lake ne doit pas être un espace où l’on copie librement, mais une plateforme de produits de données gouvernés. Toute donnée déposée doit avoir un propriétaire métier, une finalité, une classification, une durée de conservation et une politique de partage. Sans ces cinq attributs, le dépôt doit être refusé ou placé en quarantaine avec expiration automatique.

La centralisation ne garantit pas l’unicité de la vérité. Elle réduit seulement le coût de produire des divergences à grande échelle. Une table dite « client » sans contrat de schéma, sans horodatage de fraîcheur et sans identifiant de source est un fichier ambigu très bien rangé. La gouvernance des données doit donc lier stockage, catalogue et responsabilités, pas seulement ajouter une interface de recherche aux objets existants. La page gouvernance complète ce sujet sur les décisions, rôles et contrôles transverses.

Zones de données, catalogues et contrats de schéma

La séparation en zones reste nécessaire : zone d’atterrissage pour les données reçues, zone brute immuable, zone préparée et zone de consommation. Ces zones ne sont pas une décoration de diagramme. Elles portent des contrôles distincts, des identités distinctes et des durées de vie distinctes.

La zone d’atterrissage reçoit les flux entrants avec un compte de service dédié. Aucun analyste ne doit y écrire directement. La zone brute conserve le contenu original, avec une immutabilité limitée dans le temps lorsque l’audit ou la rejouabilité l’exigent. La zone préparée applique normalisation, pseudonymisation et contrôles qualité. La zone de consommation n’expose que les jeux documentés et autorisés pour un usage défini.

Un catalogue de données associe chaque table, objet ou partition à des métadonnées : propriétaire, sensibilité, origine, schéma, niveau de qualité, date de dernière mise à jour et durée de conservation. Le catalogue ne protège rien à lui seul. Il rend les règles vérifiables et permet aux moteurs d’interroger les politiques. Un catalogue rempli à la main après le dépôt est un registre funéraire : il décrit ce qui a déjà échappé au contrôle.

Le contrat de schéma doit être versionné avec le producteur. Il décrit les colonnes, types, valeurs nulles autorisées, clés métier, classification des champs et comportement attendu lors d’une évolution. Ajouter une colonne peut être compatible. Changer une devise, recycler un identifiant ou transformer un champ texte en donnée sensible ne l’est pas. Les consommateurs ne doivent jamais déduire la sémantique depuis les noms de colonnes. status_final_v2_bis n’est pas une norme d’architecture, même si le tableur le prétend très fort.

Un identifiant de données doit être stable à travers les zones. Sans traçabilité de lignage, une alerte sur un jeu source ne permet pas de localiser les jeux dérivés. Le lignage doit enregistrer la source, la transformation, la version de code, le compte d’exécution et les sorties produites. Cette information doit être collectée lors de l’exécution des pipelines, pas reconstituée après incident par lecture de logs tronqués.

IAM, chiffrement et contrôle d’accès aux copies

L’IAM (Identity and Access Management) doit distinguer l’identité humaine, le compte de service et le rôle d’exécution. Une identité humaine consulte ou administre selon son périmètre. Un pipeline lit une source et écrit une destination définie. Un moteur de requête obtient des droits temporaires, limités à son exécution. Donner au même rôle l’accès complet au stockage, au catalogue et au service de clés revient à construire une porte blindée dont la clé est collée dessus.

Le contrôle d’accès doit être appliqué à plusieurs niveaux : compte cloud ou tenant, compartiment de stockage, préfixe ou table, colonne et ligne lorsque le moteur le supporte. Le contrôle par préfixe est insuffisant pour une table partagée contenant des données de plusieurs entités. Dans ce cas, il faut filtrer les lignes selon un attribut vérifiable, tel qu’un identifiant d’organisation, et empêcher l’accès direct aux fichiers sous-jacents. Sinon, le filtre SQL devient une suggestion polie.

Le chiffrement au repos doit utiliser des clés séparées par domaine de sensibilité. Une DEK (Data Encryption Key) chiffre les données, tandis qu’une KEK (Key Encryption Key) chiffre ou protège la DEK. Le service de gestion de clés doit fournir l’audit des usages, la révocation des autorisations et la rotation des versions. La rotation d’une KEK ne rechiffre pas magiquement tous les objets historiques : il faut vérifier le mécanisme de réenveloppement du fournisseur et planifier le rechiffrement quand la menace le justifie. Les principes de cycle de vie sont détaillés dans cryptographie.

Le chiffrement ne garantit pas qu’une copie autorisée restera sous contrôle. Dès qu’un moteur analytique lit une table, il peut produire un export, un cache, un résultat temporaire ou un fichier de débogage. La protection doit donc inclure les destinations autorisées, les quotas d’export, l’interdiction des buckets personnels et l’expiration des résultats de requête. Un fichier chiffré exporté vers un poste compromis reste un incident, avec une enveloppe cryptographique très élégante.

Les journaux d’accès doivent contenir l’identité, la ressource, l’opération, l’heure, la décision de politique et le volume transféré. Ils ne doivent contenir ni valeur métier sensible ni jeton d’accès. La corrélation nécessite une horloge synchronisée par NTP (Network Time Protocol), une conservation cohérente et un stockage de journaux séparé du lake. Voir aussi l’architecture cyber pour les attentes d’observabilité.

Exemple : refuser un dépôt sans métadonnées minimales

Open Policy Agent (OPA) permet de contrôler un manifeste avant qu’un pipeline écrive dans une zone gouvernée. Le contrôle suivant refuse un jeu de données sans propriétaire, classification, durée de conservation ou chemin de sortie approuvé.

# fichier lake.rego
package lake

default allow := false

# Les chemins personnels et temporaires ne sont jamais des destinations gouvernées.
deny[msg] if {
  startswith(input.destination, "s3://lake-personnel/")
  msg := "destination personnelle interdite"
}

deny[msg] if {
  not input.owner
  msg := "proprietaire absent"
}

deny[msg] if {
  not input.classification
  msg := "classification absente"
}

deny[msg] if {
  input.retention_days <= 0
  msg := "duree de conservation invalide"
}

allow if {
  count(deny) == 0
  startswith(input.destination, "s3://lake-prepared/")
}

# Installer OPA, puis évaluer un manifeste de dépôt.
cat > manifest.json <<'JSON'
{
  "destination": "s3://lake-prepared/finance/invoices/",
  "owner": "finance-data-owner",
  "classification": "confidentiel",
  "retention_days": 365
}
JSON

opa eval --format pretty --data lake.rego --input manifest.json 'data.lake.allow'

Ce contrôle ne remplace pas les politiques du stockage. Il bloque un pipeline conforme au contrat, mais un compte disposant d’un droit d’écriture direct peut le contourner. La règle d’architecture est donc d’interdire l’écriture directe dans les zones gouvernées et de réserver cette écriture aux identités d’exécution soumises au contrôle.

Rétention, suppression et reprise après incident

La rétention doit être définie par classe de données, pas par capacité disponible. Une durée de conservation à « illimitée » signifie généralement « aucune décision n’a été prise ». Chaque objet ou table doit porter une date d’expiration calculable, y compris les partitions historiques et les sorties de calcul intermédiaires.

La suppression doit être propagée selon le lignage. Lorsqu’un enregistrement doit disparaître, le mécanisme doit identifier les tables dérivées, les index, les exports et les sauvegardes concernés. Les sauvegardes ne doivent pas être modifiées à chaud : elles suivent leur propre durée de conservation et doivent être chiffrées, isolées et restaurables. Il faut documenter le délai maximal avant extinction naturelle de la donnée supprimée dans les sauvegardes. Promettre une disparition instantanée dans tous les médias relève de la poésie opérationnelle.

Une reprise après incident exige un inventaire des dépendances : catalogue, politiques IAM, clés, métadonnées de partition, code de transformation et données elles-mêmes. Restaurer les fichiers sans le catalogue rétablit un tas d’objets. Restaurer le catalogue sans les clés rétablit un inventaire d’objets inutilisables. Les exercices de reprise doivent vérifier la restauration d’un jeu chiffré, l’application des politiques d’accès et la reconstitution du lignage.

Les clés de chiffrement, secrets de connexion et jetons de pipeline doivent être stockés hors des scripts et hors des tables de configuration. Une rotation de secret doit permettre une période de recouvrement contrôlée, puis révoquer l’ancienne valeur. Les identités de service doivent être revues périodiquement : un pipeline retiré mais encore autorisé à lire les données est une archive vivante, et les archives vivantes ont une fâcheuse tendance à parler.

🐝 Ce qui arrive si on s’en passe

Sans ces contrôles, la porte de la ruche reste ouverte et chaque flux entrant devient indistinguable d’un usage légitime. Une exfiltration prend l’apparence d’une requête analytique ordinaire : même identité, même moteur, même volume moyen, donc aucun seuil de détection ne se déclenche. La réponse à incident ne peut plus délimiter le périmètre touché, faute de savoir quels jeux dérivent du jeu compromis, ni estimer le nombre de personnes concernées. Une demande d’effacement ou un audit ne peut recevoir qu’une réponse invérifiable, puisque rien ne prouve l’absence de copie résiduelle. Les comptes de service accumulés restent autorisés bien après l’arrêt des traitements qu’ils servaient, et une clé révoquée n’empêche pas la lecture d’exports déjà déchiffrés. Enfin, la restauration produit un ensemble d’objets sans propriétaire ni politique applicable, donc réouvert à des droits plus larges qu’avant la panne.

🦫 Explication de la marmotte 🍫

Un data lake est un espace central où plusieurs équipes déposent et lisent des données. Pour éviter le désordre, les données entrent d’abord dans une zone contrôlée. Elles sont ensuite conservées dans leur forme d’origine, puis préparées pour être utilisées par des outils d’analyse. Chaque étape doit enregistrer d’où viennent les données, qui les a modifiées et quels nouveaux fichiers ont été créés.

Avant un dépôt, un contrôle vérifie que le jeu de données a un responsable, une catégorie de sensibilité, une durée de conservation et une destination autorisée. Sans ces informations, le dépôt doit être bloqué. Les personnes et les programmes n’ont pas les mêmes droits : un programme reçoit seulement l’autorisation de lire et écrire ce dont il a besoin pour sa tâche.

Les données stockées sont chiffrées avec des clés gardées séparément. Cela protège les fichiers volés, mais ne bloque pas une personne déjà autorisée à exporter leur contenu. Il faut donc limiter les exports, surveiller les accès et supprimer les résultats temporaires.

Quand une donnée doit être supprimée, il faut rechercher les copies créées pendant les transformations. Les sauvegardes peuvent conserver une ancienne version jusqu’à leur expiration prévue. En cas de panne, il faut restaurer à la fois les fichiers, les règles d’accès, les informations décrivant les données et les clés de chiffrement. Si un seul de ces éléments manque, le système restauré peut être inutilisable ou dangereux.

Pages voisines

La citent

Gouvernance d'un data lake et copie des données

Elle cite