Quand utiliser ABAC ou les filtres de ligne et masques de colonne au niveau de la table
Unity Catalog prend en charge deux approches pour la sécurité au niveau des lignes et des colonnes : les politiques ABAC et les filtres de lignes et masques de colonnes au niveau des tables. Aucune des deux approches n’accorde l’accès aux données à elle seule — les deux ajoutent des restrictions en plus des privilèges existants au niveau de l’objet. Vous devez accorder l'accès à la table de base séparément par le biais des autorisations au niveau de l'objet (GRANT).
La différence principale est l'endroit où les restrictions sont définies. Les filtres de ligne au niveau de la table et les masques de colonne appliquent des contrôles de sensibilité directement sur des tables individuelles à l’aide de ALTER TABLE. Les propriétaires de tables gèrent leur propre protection des données sans avoir besoin d'un système de tags gouvernés. Ceci est simple pour un petit nombre de tables, mais chaque table doit être configurée individuellement, et les propriétaires de tables peuvent modifier ou supprimer leurs propres filtres et masques.
Les politiques ABAC s'attachent au niveau du catalogue, du schéma ou de la table et correspondent dynamiquement aux tables et aux colonnes en fonction des balises régies. Une politique définie au niveau du catalogue s'applique à toutes les tables de ce catalogue, et les propriétaires de table individuels ne peuvent pas la supprimer, la modifier ou la contourner. La politique réside sur le catalogue et est évaluée par Unity Catalog avant que la query n'atteigne l'exécution. Ceci permet aux administrateurs de niveau supérieur d'appliquer des règles à l'échelle de l'organisation et de s'assurer que les administrateurs et les propriétaires de niveau inférieur ne peuvent pas les contourner.
Résumé détaillé de la comparaison
Ce tableau résume les différences entre les politiques ABAC et les filtres de ligne et les masques de colonne au niveau de la table.
Considération | Politiques ABAC | Filtres de ligne au niveau de la table et masques de colonne |
|---|---|---|
Syntaxe SQL |
|
|
Portée | Toutes les tables dans le cadre de la politique (catalogue, schéma ou table) et ses descendants. Les nouvelles tables taguées sont couvertes automatiquement. | Une table unique où le filtre ou le masque est configuré. Chaque table doit être configurée individuellement. |
Correspondance dynamique | Les tables et les colonnes sont mises en correspondance dynamiquement en fonction des tags gérés à l'aide de | Aucune correspondance dynamique. Les filtres et les masques sont liés à des tables et colonnes spécifiques. |
Principaux ciblés |
| Fonctions d'identité telles que |
Gouvernance des politiques | Les politiques peuvent être définies par les propriétaires de catalogues ou de schémas. Une fois définis à un niveau supérieur, les propriétaires de table ne peuvent pas les remplacer, les modifier ou les supprimer. | Géré par les propriétaires de tables, qui peuvent modifier ou supprimer les filtres et les masques sur leurs propres tables. |
Fonctionnalités non prises en charge | Les opérations comme le time travel, le clonage et OpenSharing peuvent être exécutées par des principaux dans la clause | Aucune clause |
Politiques efficaces |
| Directement visible sur la définition de la table. |
Auditabilité |
|
|
En général, utilisez les politiques ABAC lorsque :
- Vous avez besoin de règles d'accès cohérentes sur de nombreuses tables, schémas ou catalogues.
- Votre organisation applique la séparation des tâches. Par exemple, les auteurs de politiques définissent des règles, et les data stewards classent les données avec des étiquettes.
- Votre patrimoine de données s'accroît et vous souhaitez que les nouvelles tables soient automatiquement couvertes lorsqu'elles sont étiquetées.
- Vous avez besoin de la clause
EXCEPTpour permettre des opérations comme le time travel, OpenSharing ou l'optimisation complète des query pour des principaux spécifiques.
En général, utilisez les filtres de lignes et masques de colonne au niveau de la table lorsque :
- Chaque table possède une logique stricte et spécifique qui ne se généralise pas aux autres tables.
- Les propriétaires de tables devraient gérer leurs propres filtres et masques directement, sans système d'étiquettes centralisé.
- Vous disposez d'un petit ensemble stable de tables qui changent rarement.
Combinaison d'ABAC et de filtres de ligne et masques de colonne au niveau de la table
ABAC et les filtres de lignes au niveau de la table et les masques de colonnes peuvent coexister sur la même table. Au moment de la query, les politiques sont évaluées indépendamment pour l'utilisateur qui effectue la query, selon les règles suivantes :
- Un seul filtre de ligne distinct peut s'appliquer.
- Un seul masque de colonne distinct peut être résolu par colonne.
Databricks évalue les conflits en comparant les fonctions appliquées, et non les données de sortie. Si une politique ABAC et un filtre ou un masque au niveau de la table appliquent la même fonction de filtrage de ligne ou de masquage de colonne pour le même utilisateur, Databricks autorise l'exécution. S'ils appliquent différentes fonctions, Databricks bloque l'accès et renvoie une erreur, même si ces fonctions produisent des données de sortie identiques.
Pour plus de détails sur la résolution des conflits et le dépannage, consultez les règles pour plusieurs filtres et masques.
Sécurité au niveau des lignes et des colonnes avec des vues dynamiques
Les vues dynamiques peuvent également implémenter la sécurité au niveau des lignes et des colonnes en intégrant des fonctions d'identité comme current_user() et is_account_group_member() directement dans la définition de la vue. Les vues dynamiques, les filtres de lignes et les masques de colonnes appliquent tous une logique de filtrage ou de transformations au moment de la query, mais ils diffèrent dans la manière dont ils sont gérés, définis et exposés aux utilisateurs.
Fonctionnalité | S'applique à | Comment elle est gérée | Idéal pour |
|---|---|---|---|
Vues dynamiques | Vues | Logique SQL dans la définition de la vue | Contrôle d'accès précis qui s'étend sur plusieurs tables source ou qui remodèle les données pour le partage. |
Filtres de lignes et masques de colonne | Tables et colonnes | Politiques ABAC ou attribution au niveau de la table | Contrôle d'accès au niveau des lignes et des colonnes sans introduire de nouveaux objets |
Utilisez des vues dynamiques lorsque vous avez besoin d'un contrôle d'accès précis qui s'étend sur plusieurs tables sources ou qui remodèle les données pour le partage. Utilisez les filtres de ligne et les masques de colonne lorsque vous souhaitez contrôler l'accès sur des tables individuelles sans introduire de nouveaux objets.
Par exemple, une vue dynamique peut masquer une colonne d'e-mail pour les non-auditeurs :
CREATE VIEW sales_redacted AS
SELECT
user_id,
CASE
WHEN is_account_group_member('auditors') THEN email
ELSE regexp_extract(email, '^.*@(.*)$', 1)
END AS email,
country,
product,
total
FROM sales_raw
Les vues dynamiques prennent entièrement en charge l'optimisation des query et le report de prédicat, elles peuvent donc offrir de meilleures performances de query que les filtres de ligne et les masques de colonne. Ils empêchent également les utilisateurs de modifier les tables sous-jacentes.
Cependant, les vues dynamiques présentent deux inconvénients pour la gouvernance des données :
- **Audits limités** : Les vues dynamiques ne disposent pas de métadonnées sémantiques telles que des balises ou des définitions de politique dans les tables système, ce qui rend leur audit plus difficile à grande échelle.
- **Vulnérabilité au sondage** : Comme ils n'ont pas de
SecureViewbarrière, ils ne protègent pas contre les attaques par sondage, où un utilisateur crée un prédicat avec des effets secondaires pour déduire des informations sur les lignes filtrées. Consultez Comprendre le report de prédicat sur les tables protégées.