Gouverner un jeu de données clients avec les policy tags, les vues et le Time Travel

Objectif

Ce guide vous explique comment protéger une table clients contenant des données personnelles avec les policy tags, les groupes IAM, une vue gouvernée et le Time Travel. Vous classez ses colonnes avec les policy tags, restreignez chaque équipe avec les groupes IAM et des conditions CEL, publiez une vue qui donne aux analystes une version moins précise des données, et annulez une erreur destructive avec le Time Travel.

À la fin, vous disposerez d'une table clients classée colonne par colonne, de trois équipes dont l'accès correspond à leurs besoins, d'une vue gouvernée pour les analystes, et d'une méthode testée pour restaurer la table après une suppression accidentelle.

Prérequis

Pour suivre ce guide, vous devez :

• disposer d'un projet Data Platform. Ce guide utilise un projet nommé customer-governance.
• disposer d'un compte administrateur sur ce projet.
• disposer d'un second compte, non administrateur, pour un utilisateur de test : le compte d'une autre personne ou une autre de vos adresses, par exemple user+governance-test@example.com.
• télécharger le fichier clients :

Avant de commencer, nous vous recommandons de lire les guides sur les policy tags et les conditions CEL. Ce guide suppose que vous êtes à l'aise avec les principaux composants de la Data Platform.

Ce que vous allez construire

Trois groupes accèdent à la table crm.customers à des niveaux différents : Analysts ne voit que les colonnes low, Customer Support les colonnes low et medium, et Data Stewards toutes les colonnes. La vue gouvernée customer_profiles, construite sur la même table, donne aux Analysts une version moins précise de l'âge et du code postal.

En pratique

Étape 1 : charger les clients

Créer la source

1. Allez dans Connectors > Sources > New Source et cliquez sur File Upload en bas de la fenêtre.

   

2. Renommez la source customers.

3. Déposez customers.parquet dans la zone Files, puis cliquez sur Create.

   

Vérifier les types

Allez dans Connectors > Analyzer et ouvrez customers.parquet dans la source customers. L'extraction des métadonnées démarre automatiquement. Vérifiez ces 2 colonnes :

• zipcode doit être en String : des codes postaux comme 02760 perdraient leur zéro initial sous forme de nombres.
• age est en Double, ce qui convient aux tranches d'âge de l'étape 5.

Créer le dataset et la table

Un dataset dédié isole les règles de ce guide du reste du projet : le policy tag que vous lui attribuez à l'étape 2 s'applique à toutes les tables qu'il contient.

1. Allez dans Lakehouse Manager > Datasets > New Dataset, nommez-le crm et cliquez sur Create.

   

2. Allez dans Tables, cliquez sur la flèche du bouton New table et sélectionnez Create from a Connectors source.

3. Sélectionnez customers.parquet dans la source customers et cliquez sur Next.

   

4. Nommez la table customers, sélectionnez le dataset crm, laissez les 3 options automatiques activées et cliquez sur Create.

   

   Une fois le chargement terminé, la table customers affiche 16 attributs et 5k lignes.

   

Étape 2 : classer les colonnes

Les règles d'accès de l'étape 3 lisent un policy tag sur chaque colonne pour décider qui peut la lire.

Consulter le tag de sensibilité

Allez dans Lakehouse Manager > Policy Tags et cliquez sur sensitivity. Le projet fournit cette clé avec trois valeurs, que ce guide utilise ainsi :

Taguer le dataset

Taguez le dataset low : toute colonne sans tag propre en hérite.

Allez dans Datasets, ouvrez crm, puis l'onglet Policy Tags, cliquez sur + Add policy tag, sélectionnez la clé sensitivity, puis la valeur low. Les modifications sont enregistrées automatiquement.

Taguer les colonnes

Allez dans Tables, ouvrez customers, puis l'onglet Policy Tags. Dans Column-level policy tags, pour chaque colonne ci-dessous, cliquez sur + Add policy tag, puis sélectionnez sensitivity et sa valeur :

Les tags s'appliquent immédiatement, sans reconstruire la table.

Étape 3 : définir les règles d'accès

L'accès combine deux types de rôles, tous deux créés dans l'IAM du projet :

• un rôle de base permet d'ouvrir l'interface et d'exécuter des requêtes, sans accéder aux données ;
• un rôle de données donne accès aux données via Advanced Data Access Control, limité par une condition CEL définie sur chaque groupe.

Créer les rôles

Allez dans Identity Access Manager > Roles > New role et créez les 3 rôles ci-dessous en ajoutant leurs permissions avec Add permission, puis cliquez sur Create.

Lakehouse Explorer n'a aucune permission Advanced Data Access Control : à lui seul, il ne donne accès à aucune donnée.

Créer les groupes

Chaque groupe associe un rôle de données à une condition CEL :

Le contrôle d'accès descend du dataset à la table, puis à l'attribut, et chaque niveau doit être validé. Dans les conditions ci-dessous, les deux premières lignes laissent passer chaque groupe par crm et customers. La troisième détermine les niveaux de colonnes que le groupe peut lire. La quatrième sert à la vue de l'étape 5 : une vue ne peut pas encore porter de policy tag, le contrôle d'accès traite donc la vue et ses colonnes comme des ressources sans tag. Sans cette ligne, toute vue est refusée, même une vue construite uniquement sur des colonnes low. Elle n'ouvre pas d'autres ressources : les tables de crm héritent de low via le dataset, et un dataset sans tag reste refusé.

Analysts :

Service == "adac" && (
  (PolicyTags.sensitivity == "low" && Resource == "dataset")
  || (PolicyTags.sensitivity == "low" && Resource == "table")
  || (PolicyTags.sensitivity == "low" && Resource == "attribute")
  || (!has(PolicyTags.sensitivity) && Resource != "dataset")
)

Customer Support :

Service == "adac" && (
  (PolicyTags.sensitivity == "low" && Resource == "dataset")
  || (PolicyTags.sensitivity == "low" && Resource == "table")
  || (PolicyTags.sensitivity in ["low", "medium"] && Resource == "attribute")
  || (!has(PolicyTags.sensitivity) && Resource != "dataset")
)

Data Stewards :

Service == "adac" && (
  (PolicyTags.sensitivity == "low" && Resource == "dataset")
  || (PolicyTags.sensitivity == "low" && Resource == "table")
  || (PolicyTags.sensitivity in ["low", "medium", "high"] && Resource == "attribute")
  || (!has(PolicyTags.sensitivity) && Resource != "dataset")
)

Pour chaque groupe :

1. Allez dans Groups > New group et nommez le groupe.

2. Dans Roles & Conditions, cliquez sur + Add et sélectionnez son rôle de données.

3. Cliquez sur le lien de condition à côté du rôle, collez la condition du groupe donnée ci-dessus et cliquez sur Confirm.

   

4. Cliquez sur Create.

Étape 4 : vérifier les règles avec un utilisateur de test

Les administrateurs ne sont pas limités par les policy tags : faites donc les vérifications avec l'utilisateur de test. Le compte administrateur modifie les groupes de l'utilisateur de test, qui exécute les requêtes dans Lakehouse Manager > Explorer, en mode SQL.

Créer l'utilisateur de test

1. Dans l'IAM de l'organisation, invitez l'utilisateur de test via son adresse e-mail et ajoutez-le au groupe Viewers.

2. Dans l'IAM du projet, allez dans Users > + New User et ajoutez la même adresse en tant que Team Member.

3. Sur la page de l'utilisateur, ajoutez uniquement le rôle Lakehouse Explorer et le groupe Analysts, puis cliquez sur Save.

   

4. Acceptez l'invitation et connectez-vous avec l'utilisateur de test dans une fenêtre de navigation privée.

Vérifier le groupe Analysts

Avec l'utilisateur de test, exécutez :

Un policy tag refuse l'accès au lieu de masquer les valeurs : une seule colonne refusée fait échouer toute la requête.

Vérifier le groupe Customer Support

Avec le compte administrateur, allez dans Identity Access Manager > Users, ouvrez l'utilisateur de test. Dans Groups, cliquez sur l'icône de corbeille de la ligne Analysts, puis sur + Add, sélectionnez Customer Support et cliquez sur Save.

Avec l'utilisateur de test, exécutez :

Vérifier le groupe Data Stewards

Avec le compte administrateur, remplacez Customer Support par Data Stewards de la même façon. Avec l'utilisateur de test, exécutez :

Le texte de persona commence par le nom complet du client et cite souvent son âge : c'est pourquoi la colonne est taguée high.

Étape 5 : publier une vue pour les analystes

Les Analysts ne peuvent lire ni l'âge ni le code postal. La vue customer_profiles leur donne à la place une tranche d'âge et les trois premiers chiffres du code postal.

Créer la vue

1. Avec le compte administrateur, allez dans Lakehouse Manager > Views > New view.

2. Nommez la vue customer_profiles, sélectionnez le dataset cible crm et collez cette définition SQL :

   SELECT
       uuid,
       state,
       substr(zipcode, 1, 3) AS zip3,
       CASE
           WHEN age < 25 THEN '18-24'
           WHEN age < 35 THEN '25-34'
           WHEN age < 45 THEN '35-44'
           WHEN age < 55 THEN '45-54'
           WHEN age < 65 THEN '55-64'
           ELSE '65+'
       END AS age_band,
       occupation,
       education_level
   FROM customers
   

3. Cliquez sur Create. La vue affiche le statut Valid.

Vérifier la vue

L'utilisateur de test est dans Data Stewards. Exécutez ces requêtes, puis remettez-le dans Customer Support, puis dans Analysts, et réexécutez-les à chaque fois :

Étape 6 : annuler une erreur avec le Time Travel

Chaque modification d'une table du Lakehouse Manager crée un snapshot, et le Time Travel ramène la table à n'importe quel snapshot encore conservé.

Faire l'erreur

1. Avec le compte administrateur, exécutez ce comptage dans l'Explorer : il renvoie 5 000 clients, dont 591 en Californie.

   SELECT count(*) AS customers, count_if(state = 'CA') AS california FROM crm.customers

2. Allez dans Data Processing Engine > Actions > New action, créez une SQL Action et nommez-la Delete California customers.

3. Dans le panneau Tables, cliquez sur customers dans crm pour copier son nom complet, de la forme catalog.schema.table, par exemple "db_mv0m4qnl_crm"."crm".customers. Une action SQL a besoin de ce nom complet.

4. Saisissez cette requête en remplaçant <catalog>.crm.customers par le nom complet copié, puis cliquez sur Validate :

   DELETE FROM <catalog>.crm.customers WHERE state = 'CA'

   La simulation affiche 591 rows would be deleted.

   

5. Cliquez sur Create, puis lancez l'action avec Run. Relancez le comptage : il renvoie maintenant 4 409 clients, aucun en Californie.

Restaurer la table

1. Allez dans Lakehouse Manager > Tables, ouvrez customers, puis l'onglet Time Travel. Le dernier snapshot est Data deleted, au-dessus de deux snapshots Data inserted.

   

2. Vérifiez un snapshot avant de le restaurer, à l'aide de son ID (colonne Snapshot ID) :

   SELECT count(*) AS customers, count_if(state = 'CA') AS california
   FROM customers FOR VERSION AS OF <snapshot ID>

   Le snapshot Data inserted le plus récent contient 5 000 clients. Le plus ancien est vide : il enregistre la création de la table, avant le chargement.

3. Cliquez sur l'icône de rollback (↻) du snapshot Data inserted le plus récent, puis sur Rollback to snapshot.

   

   Une ligne Data rollbacked apparaît en haut de l'historique ; le snapshot Data deleted y reste. Relancez le comptage : il renvoie à nouveau 5 000 clients, dont 591 en Californie.

   

Bon à savoir

• Les policy tags refusent, ils ne masquent pas. Une requête qui inclut une colonne refusée échoue entièrement. Pour donner des données moins précises à une équipe, publiez une vue.
• Le rôle par défaut DM & AM Editor contourne les policy tags. Il inclut Advanced Data Access Control / Read sans condition. Donnez aux consommateurs de données un rôle de base personnalisé sans aucune permission Advanced Data Access Control.
• Vous ne pouvez pas vous ajouter à un groupe. L'IAM empêche les utilisateurs de s'attribuer des droits.
• Les droits s'additionnent. Un utilisateur dans plusieurs groupes, ou avec plusieurs rôles, obtient l'accès dès que l'un d'eux l'autorise.
• Vérifiez un snapshot avant d'y revenir. Le plus ancien snapshot d'une table peut être vide : il enregistre la création de la table, avant tout chargement de données.
• La validation montre l'impact d'une modification. Dans une action SQL, Validate exécute la requête en simulation et donne le nombre de lignes concernées, avant toute modification.
• Le Time Travel a une limite de temps. Les snapshots sont conservés 14 jours par défaut, entre 7 et 28 jours selon le réglage du dataset ou de la table. Au-delà, vous ne pouvez plus annuler une erreur de cette façon.

Ce que vous avez construit

Vous disposez d'une table clients classée colonne par colonne, de trois équipes dont l'accès correspond à leurs besoins, d'une vue gouvernée qui donne aux analystes des données moins précises, et d'un moyen d'annuler une erreur destructive. La même démarche s'applique à toute table contenant des données personnelles : classer, définir les rôles, tester avec un utilisateur non administrateur, et garder le Time Travel à portée de main.

Pour approfondir, consultez le guide « Tests et résolution des problèmes » des policy tags, l'exemple d'accès d'équipe avec des groupes et les réglages de rétention du Time Travel.

Aller plus loin

Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

Posez vos questions, faites-nous part de vos commentaires et interagissez directement avec l’équipe qui développe la Data Platform sur le canal Discord dédié.

Si vous avez besoin d'une assistance concernant vos services OVHcloud, créez une demande depuis notre centre d'aide.

Rejoignez notre communauté d'utilisateurs.