Classification et masquage
Classification des données par colonne, stratégies de masquage, filtres de lignes et le moteur de politiques basé sur Rego qui les applique.
Chaque table managée porte une classification de données au niveau de la table et au niveau de la colonne. Combinée aux stratégies de masquage et aux filtres de lignes, cela vous donne un contrôle fin sur quels utilisateurs — ou quels workflows — voient quelles données.
Trois couches de gouvernance
| Couche | Rôle | Granularité |
|---|---|---|
| Classification de table | Marque la table entière à un niveau de sensibilité — public, interne, confidentiel, restreint. | Par table |
| Classification de colonne + stratégie de masquage | Marque les colonnes individuelles et décide si elles sont affichées, caviardées, hachées ou refusées par rôle. | Par colonne par rôle |
| Filtre de lignes | Un prédicat Rego qui restreint les lignes visibles par un appelant (ex. : « uniquement les lignes où org_unit correspond au département de l'appelant »). | Par ligne par appelant |
Les trois sont évalués ensemble au moment de la lecture. Il n'existe aucun chemin vers les données qui les contourne.
Classification de table
Choisie à la création de la table ; peut être modifiée par un administrateur d'espace de travail. Les classifications définissent qui peut utiliser la table :
| Classification | Qui peut lire la table |
|---|---|
| public | Tout membre de l'espace de travail |
| internal | Membres de l'espace de travail avec l'autorisation data:read-internal (par défaut pour les membres) |
| confidential | Administrateurs d'espace de travail et au-dessus |
| restricted | Propriétaires d'espace de travail et propriétaires d'organisation uniquement |
Les classifications plus élevées affectent également les stratégies de masquage par défaut sur les colonnes — voir ci-dessous.
Classification de colonne et stratégies de masquage
Chaque colonne peut déclarer sa propre classification. Lorsqu'elle est définie, la sensibilité effective de la colonne est le maximum entre sa propre classification et celle de la table. Une colonne restricted dans une table internal est toujours traitée comme restricted.
Pour chaque paire (colonne, rôle), vous pouvez déclarer une stratégie de masquage :
| Stratégie | Ce que le rôle voit |
|---|---|
clear | La valeur réelle |
redact | Une chaîne de masquage fixe ([REDACTED]) |
hash | Un hash déterministe — utile pour joindre des données masquées entre requêtes |
null | Une valeur NULL comme si la colonne n'existait pas pour eux |
deny | La requête échoue entièrement avec une erreur de permission |
Modèles courants :
| Type de colonne | Membre d'espace de travail | Administrateur d'espace de travail | Propriétaire d'espace de travail |
|---|---|---|---|
| Données personnelles (nom, email) | redact | clear | clear |
| Salaire / financier | null | null | clear |
| Identifiants internes | clear | clear | clear |
| Secrets externes | deny | deny | clear |
Filtres de lignes
Un filtre de lignes est un prédicat Rego qui décide si une ligne est visible par un appelant. Les filtres sont définis par rôle et par table. Exemples de concepts :
- Périmètre tenant —
row.org_unit == caller.org_unit - Périmètre région —
row.region in caller.allowed_regions - Périmètre projet —
row.project_id in caller.project_grants
Le filtre s'exécute dans le cadre de la décision de politique au moment de la lecture. Les lignes qui ne passent pas le filtre sont exclues du jeu de résultats ; l'appelant n'a aucun signal indiquant que des lignes exclues existent.
Le point de décision de politique
Les classifications, masques et filtres sont compilés en un bundle Rego par tenant par la plateforme. Chaque lecture d'une table managée évalue ce bundle. Le bundle est reconstruit lorsque :
- Une classification est modifiée.
- Une stratégie de masquage est ajoutée ou modifiée.
- Un filtre de lignes est ajouté ou modifié.
- Une définition de rôle change.
Les reconstructions sont rapides et s'appliquent à la prochaine lecture ; il n'y a pas de période d'attente.
OPA est le point de décision de politique par défaut. Un moteur de repli intégré est également supporté pour les déploiements qui préfèrent ne pas exécuter OPA comme sidecar. Les deux consomment le même bundle.
Audit
Chaque lecture d'une table managée émet un événement RESOURCE_ACCESS dans le journal d'audit avec :
- L'acteur et son rôle résolu.
- L'identifiant de table et les colonnes demandées.
- Le nombre de lignes retournées (pas les lignes elles-mêmes).
- Les stratégies de masquage et filtres de lignes appliqués.
Pour les audits de conformité, cela répond à la question « qui a vu quelle colonne quand » sans exposer les données elles-mêmes.
Voir aussi
- Tables managées — création et cycle de vie des tables.
- Sécurité → Autorisation — le modèle d'autorisation général dans lequel ces politiques s'inscrivent.
- Journal d'audit — ce qui est enregistré à chaque lecture.
- Conformité → RGPD — comment le masquage des colonnes se mappe aux exigences de minimisation des données.