Contrôle d’accès dans le catalogue Unity

Cette page présente une vue d’ensemble du contrôle d’accès dans le catalogue Unity, notamment les privilèges, les stratégies et les contrôles au niveau des données.

Couches de contrôle d’accès

Le contrôle d’accès dans le catalogue Unity repose sur les modèles complémentaires suivants :

• Les restrictions au niveau de l’espace de travail contrôlent où les utilisateurs peuvent accéder aux données, en limitant les objets à des espaces de travail spécifiques.
• Privilèges et contrôle de propriétéqui peuvent accéder à quoi, en utilisant des subventions sur des objets sécurisables.
• Les stratégies basées sur des attributs (ABAC) contrôlent les données auxquelles les utilisateurs peuvent accéder, à l’aide de balises régies et de stratégies centralisées.
• Le filtrage au niveau de la table et le masquage contrôlent les données que les utilisateurs peuvent voir dans les tables à l’aide de filtres et de vues spécifiques à la table.

Ces modèles fonctionnent ensemble pour appliquer un accès sécurisé et précis dans votre environnement de données.

Restrictions au niveau de l’espace de travail

La liaison d’espace de travail limite les espaces de travail de votre compte qui peuvent accéder à des catalogues, des emplacements externes et des informations d’identification de stockage spécifiques. Ce contrôle d’accès se produit au niveau de l’espace de travail et s’applique indépendamment des privilèges d’utilisateur ou de groupe.

Par défaut, tous les catalogues, emplacements externes et informations d’identification de stockage dans le catalogue Unity sont accessibles à partir de n’importe quel espace de travail attaché au même metastore. À l’aide de liaisons, vous pouvez :

• Restreindre l’accès à un ou plusieurs espaces de travail désignés
• Rendre l'accès au catalogue en lecture seule depuis certaines zones de travail.
• Isoler des environnements, par exemple, restreindre les données de production aux espaces de travail de production
• Limiter l’utilisation des emplacements externes et des identifiants de stockage à des espaces de travail spécifiques

Ces liaisons remplacent les autorisations au niveau de l’utilisateur. Si un utilisateur dispose de privilèges sur un objet mais tente de l’accéder à partir d’un espace de travail indépendant, l’accès est refusé.

Pour plus d’informations, consultez Limiter l’accès au catalogue à des espaces de travail spécifiques.

Privilèges et propriété

L’accès dans le catalogue Unity est principalement régi par les privilèges et la propriété d’objet. Ce modèle définit qui peut accéder ou gérer des données et des métadonnées en affectant des rôles d’administrateur et en accordant des privilèges et en gérant la propriété entre les objets sécurisables. Cette section décrit comment les privilèges sont accordés, comment fonctionne la propriété et quels rôles d’administrateur peuvent gérer l’accès dans différentes étendues.

Rôles d’administrateur

Unity Catalog prend en charge plusieurs rôles d’administrateur :

• Administrateur de compte : peut créer des metastores, gérer des identités, affecter des administrateurs de metastore et gérer des fonctionnalités au niveau du compte telles que le partage Delta et les tables système.
• Administrateur du metastore : rôle facultatif mais puissant qui peut gérer tous les objets du metastore, transférer la propriété et attribuer des privilèges de niveau supérieur comme CREATE CATALOG, CREATE EXTERNAL LOCATIONetc.
• Administrateur de l’espace de travail : gère les identités, les paramètres au niveau de l’espace de travail et le catalogue d’espaces de travail.

Pour plus d’informations, consultez Les privilèges d’administrateur dans le catalogue Unity.

Propriété des objets

Chaque objet sécurisable, tel qu’un catalogue, un schéma ou une table, dans le catalogue Unity a un propriétaire. La propriété accorde un contrôle total sur cet objet, y compris la possibilité de :

• Lire ou modifier l’objet et ses métadonnées
• Accorder des privilèges à d’autres utilisateurs
• Transférer la propriété vers un autre principal

Unity Catalog prend également en charge un MANAGE privilège, qui permet aux utilisateurs d’accorder l’accès et de modifier des objets sans les rendre propriétaires.

Pour plus d’informations sur la propriété, consultez Gérer la propriété de l’objet Catalogue Unity.

Privilèges sur les objets sécurisables

Dans le catalogue Unity, le contrôle d’accès commence par des privilèges. Vous attribuez des privilèges tels que SELECT, MODIFY et USE SCHEMA aux utilisateurs et groupes sur des objets sécurisables tels que des catalogues, des schémas, des tables, des vues, des volumes et des fonctions.

L’application des privilèges est la suivante :

• Hiérarchique : accorde des droits sur les objets de niveau supérieur, tels que des catalogues, qui se propagent en cascade aux objets de niveau inférieur, tels que des tables.
• Délégable : chaque objet a un propriétaire qui peut le gérer et accorder l’accès à d’autres personnes.
• Explicite : l’accès est autorisé uniquement lorsqu’un utilisateur ou un groupe a reçu les privilèges appropriés. Un utilisateur reçoit l’union des autorisations de tous les groupes dont il est membre.

Les utilisateurs peuvent demander l’accès aux objets qu’ils peuvent découvrir, par le biais du BROWSE privilège ou d’une URL directe vers l’objet, ou lorsqu’ils rencontrent une erreur d’autorisation refusée dans les blocs-notes ou l’éditeur SQL. Databricks recommande d’accorder BROWSE des catalogues au All account users groupe pour rendre les objets détectables et autoriser les utilisateurs à demander l’accès. Les demandes d’accès sont envoyées à des destinations configurées, telles que l’e-mail, Slack, Microsoft Teams, les points de terminaison de webhook ou une URL de redirection. Si aucune destination n’est configurée, les utilisateurs ne peuvent pas demander l’accès à l’objet.

Pour plus d’informations, consultez Gérer les privilèges dans le catalogue Unity et les privilèges de catalogue Unity et les objets sécurisables.

Mise en cache des autorisations pour l’accès en fonction du chemin d’accès

Pour améliorer les performances de l’accès basé sur le chemin d’accès au stockage cloud, Unity Catalog peut mettre en cache les résultats de la vérification des autorisations pendant jusqu’à 60 secondes par utilisateur et par chemin d’accès. Cette mise en cache s’applique à :

• Opérations de système de fichiers à l’aide de commandes dbutils.fs
• Requêtes basées sur des chemins à l’aide de Spark SQL

En raison de ce comportement de mise en cache, une autorisation ou une révocation peut ne pas refléter immédiatement. Ce comportement affecte uniquement l’accès basé sur le chemin. L’accès en fonction du nom (par exemple) SELECT * FROM catalog.schema.tablen’est pas affecté par ce cache.

Contrôle d’accès basé sur les attributs (ABAC)

ABAC est une infrastructure de stratégie basée sur des balises centralisée pour appliquer le contrôle d’accès dans le catalogue Unity. Il permet aux administrateurs de définir des stratégies évolutives qui s’appliquent dynamiquement dans les catalogues, les schémas et les tables en fonction des balises régies. Les stratégies peuvent filtrer des données ou masquer des valeurs sensibles. Databricks recommande d’utiliser ABAC pour la gouvernance centralisée et évolutive, plutôt que d’appliquer des filtres ou des masques individuellement sur chaque table.

ABAC est conçu comme infrastructure à usage général pour appliquer des stratégies de contrôle d’accès basées sur des attributs de métadonnées. Il complète les contrôles basés sur des privilèges et prend en charge l’application affinée sans nécessiter de configuration par objet.

Fonctionnalités clés :

• Stratégies basées sur des balises : Définissez des stratégies une fois à l’aide de balises régies et de fonctions définies par l’utilisateur (UDF) et appliquez-les de manière cohérente dans de nombreuses ressources de données.
• Application hiérarchique : appliquez des stratégies au niveau du catalogue, du schéma ou de la table avec un héritage automatique pour les objets enfants.
• Gouvernance centralisée et évolutive : Gérez l’accès à grande échelle sans attribuer des privilèges individuels sur chaque objet.
• Évaluation dynamique : Les décisions d’accès sont évaluées en temps réel en fonction des balises et du contexte utilisateur.

Pour plus d’informations, consultez Contrôle d’accès basé sur les attributs du catalogue Unity (ABAC).

Filtrage et masquage au niveau de la table

Cette section traite des mécanismes qui contrôlent les données que les utilisateurs peuvent voir au moment de la requête à l’aide d’une logique spécifique à la table. Voici quelques-uns des éléments suivants :

• Filtres de lignes et masques de colonne : appliquez une logique directement aux tables.
• Vues dynamiques : définissez une logique à l’aide de SQL sur une ou plusieurs tables.

Ces approches peuvent être utilisées indépendamment ou en même temps qu’ABAC, en fonction de votre modèle de gouvernance.

Filtres de lignes et masques de colonne

Les filtres de lignes et les masques de colonnes appliquent directement une logique de filtre ou de masque à des tables individuelles à l’aide de fonctions définies par l’utilisateur. Elles sont utiles lorsque vous souhaitez appliquer la logique par table sans gestion centralisée des stratégies.

Pour plus d’informations, consultez Filtres de lignes et masques de colonne.

Vues dynamiques

Les vues dynamiques vous permettent de définir une logique sur une ou plusieurs tables à l’aide de SQL. Ils sont en lecture seule et utiles pour :

• Application d'une logique de transformation (par exemple, des jointures et des instructions CASE)
• Partage de données filtrées via Delta Sharing, où ABAC n’est pas pris en charge.

Pour plus d’informations, consultez Créer un affichage dynamique.

Quand utiliser chaque mécanisme de contrôle d’accès

Les liaisons d’espace de travail, les privilèges et les stratégies ABAC évaluent tous l’accès à différents niveaux et sont conçus pour être utilisés ensemble. Le tableau suivant les compare aux critères de contrôle d’accès courants :