Aller au contenu principal
Dernière mise à jour le

Accès exclusif au modèle

info

Aperçu

Cette fonctionnalité est en aperçu public.

L'accès exclusif est un modèle qui rend l'accès aux données **opt-in** plutôt qu'ambiant. Avec les permissions habituelles de Unity Catalog, les permissions suivent l'utilisateur : un utilisateur accumule des permissions au fil du temps et les transporte partout, de sorte que son accès est la somme des permissions qui lui ont été accordées directement et des permissions qu'il hérite de tous les groupes dont il est membre. Le modèle d'accès exclusif permet aux clients de modéliser l'accès aux données sensibles comme nécessitant une action délibérée — un utilisateur doit assumer activement un rôle pour atteindre les données, plutôt que d'y avoir un accès permanent. Cela les empêche d'accéder aux données en tant que leur propre identité et de mélanger les données entre les cas d'utilisation, les essais cliniques, les projets ou les clients.

Exemple d'accès exclusif : l'utilisateur 1 peut endosser le groupe Étude 1 ou le groupe Étude 2. En agissant en tant que leur propre identité, l'utilisateur 1 ne peut query les données d'aucune des études. En agissant comme le groupe Étude 1, l'utilisateur 1 peut query uniquement les données de l'Étude 1 ; en agissant comme le groupe Étude 2, uniquement les données de l'Étude 2.

Pour aider à décrire ce motif, nous utilisons deux termes pour les identités distinctes en jeu. Ce sont des libellés explicatifs, pas une terminologie Databricks formelle :

  • Rôle d'accès : un groupe sans membre qui détient des autorisations sur les données sensibles. Les utilisateurs assument ce rôle pour accéder aux données. Le rôle d'accès doit rester vide : tout membre du rôle d'accès hérite directement de ses autorisations et peut accéder aux données sensibles sans assumer le rôle, ce qui compromet l'accès exclusif. Dans Databricks, un rôle d'accès est implémenté en tant que groupe.
  • Groupe de membres : un groupe dont les membres sont les utilisateurs autorisés à attribuer le rôle d'accès. L'octroi du rôle d'attribution au groupe de membres permet à tous ses membres d'attribuer le rôle. Un groupe de membres est une commodité, pas une exigence — vous pouvez également accorder l'attribution directement à des utilisateurs individuels ou à des Service Principal. Cela vous évite de gérer les autorisations d'attribution un principal à la fois.

Une fois configurés, les utilisateurs assument le rôle d'accès par l'une des méthodes prises en charge : le sélecteur de rôle, les clusters de mode d'accès dédiés attribués à un groupe, la CLI, l'API ou les outils de BI tiers. Voir Changer de rôle.

Databricks prend en charge deux approches pour la création du rôle d'accès. Sélectionnez celle qui correspond le mieux à la façon dont votre organisation gère les identités :

  • **Rôle d'accès local au compte** : Créez un groupe Databricks local au compte en tant que rôle d'accès. Il est préférable de créer un groupe dans Databricks lorsque c'est plus simple que de créer un nouveau groupe de fournisseur d'identité (par exemple, lorsque les modifications du fournisseur d'identité nécessitent un ticket IT ou un examen interne).
  • Rôle d'accès synchronisé depuis votre fournisseur d'identité : Utilisez un groupe de fournisseur d'identité vide comme rôle d'accès, synchronisé avec Databricks via SCIM. Idéale lorsque vous gérez déjà les groupes dans votre fournisseur d'identité et préférez y maintenir l'ensemble du cycle de vie des groupes.

Exigences​

  • Un Workspace compatible avec Unity Catalog.
  • Autorisations d'administrateur de compte ou d'administrateur de Workspace pour créer des groupes et accorder le droit d'assumer un rôle.

Approche 1 : rôle d'accès local au compte​

Dans cette approche, le rôle d'accès est un groupe local au compte Databricks entièrement géré au sein de Databricks. Le groupe membre peut être n'importe quel groupe ayant l'autorisation d'assumer le rôle d'accès : généralement un groupe synchronisé depuis votre fournisseur d'identité contenant les utilisateurs autorisés à accéder aux données sensibles.

Rôle d'accès local au compte : un groupe local au compte Databricks sert de rôle d'accès, avec un groupe de membres auquel la permission d'Assumer est accordée.

Étape 1 : Créez le rôle d'accès et attribuez-le à votre workspace​

Créez un groupe au niveau du compte sans membres pour servir de rôle d'accès. Databricks recommande d'utiliser un préfixe de nommage cohérent (tel que role-) pour distinguer les rôles d'accès des groupes ordinaires. Par exemple, si votre groupe de membres pour les utilisateurs autorisés est clinical-trial-1-ds, vous pourriez nommer le rôle d'accès role-clinical-trial-1-ds.

Pour créer le rôle d'accès :

  1. En tant qu'administrateur de compte, connectez-vous à la console du compte.
  2. Dans la barre latérale, cliquez sur Gestion des utilisateurs .
  3. Sur l'onglet **Groupes**, cliquez sur **Ajouter un groupe**.
  4. Saisissez un nom pour le rôle d'accès. N'ajoutez pas de membres.
  5. Cliquez sur Confirmer .

Après avoir créé le rôle d'accès, attribuez-le au Workspace où il doit être disponible. Consultez Attribuer un groupe à un workspace.

Étape 2 : accorder l’accès aux données et aux assets de Workspace​

Accordez des autorisations de rôle d’accès sur vos données sensibles et vos assets Workspace à l’aide des outils Databricks standard :

  • Objets sécurisables Unity Catalog : Utilisez les instructions GRANT ou l’Explorateur de catalogues pour accorder des privilèges UC au rôle d’accès.
  • **Assets du Workspace** : Utilisez des listes de contrôle d'accès (ACL) pour accorder au rôle d'accès des autorisations sur les Notebooks, les Jobs, les SQL Warehouses et d'autres objets du Workspace.

Par exemple, pour accorder l’autorisation de rôle d’accès pour lire une table Unity Catalog :

SQL
GRANT USE SCHEMA ON <catalog>.<schema> TO `<access-role-name>`;
GRANT SELECT ON TABLE <catalog>.<schema>.<table> TO `<access-role-name>`;

Étape 3 : accorder l'autorisation d'assumer​

Accordez la permission **Assumer** aux utilisateurs, Service Principal ou groupes membres qui devraient être en mesure d'assumer ce rôle. Voir Gérer les permissions sur un groupe.

Étape 4 : Les utilisateurs assument le rôle​

Les utilisateurs qui ont l'autorisation d'endosser le rôle d'accès peuvent l'endosser. Consultez Changer de rôle pour connaître les méthodes disponibles.

Approche 2 : rôle d'accès synchronisé de votre fournisseur d'identité​

Utilisez cette approche pour gérer le rôle d'accès dans votre fournisseur d'identité et le synchroniser avec Databricks en utilisant SCIM, plutôt que de créer un rôle d'accès séparé géré par Databricks. Le rôle d'accès et le groupe de membres proviennent tous deux de votre fournisseur d'identité.

Rôle d&#39;accès synchronisé avec le fournisseur d&#39;identité : un groupe IdP vide synchronisé avec Databricks sert de rôle d&#39;accès, avec un groupe membre IdP auquel l&#39;autorisation d&#39;Assumer a été accordée.

Dans cette approche :

  • Le **rôle d'accès** est un groupe de fournisseur d'identité vide, synchronisé avec Databricks et auquel des autorisations ont été accordées sur les données sensibles.
  • Le **groupe de membres** est un groupe de fournisseurs d'identité existant dont les membres sont les utilisateurs autorisés à assumer le rôle d'accès. Vous accordez au groupe de membres la possibilité d'assumer le rôle d'accès, afin que tous ses membres héritent automatiquement de la possibilité d'assumer un rôle.
remarque

Le rôle d'accès doit rester vide dans votre fournisseur d'identité. Les membres ajoutés au rôle d'accès dans votre fournisseur d'identité sont synchronisés avec Databricks et héritent directement des autorisations du rôle, ce qui signifie qu'ils peuvent accéder aux données sensibles sans avoir besoin d'endosser le rôle. Cela rompt le modèle d'accès exclusif.

Étape 1 : Configurez des groupes dans votre fournisseur d'identité​

La manière dont vous configurez les groupes dépend de si vous partez de zéro ou si vous réutilisez un groupe de fournisseurs d'identité existant qui a déjà des autorisations dans Databricks.

Dans votre fournisseur d'identité :

  1. Créez un groupe vide pour servir de rôle d'accès. Par exemple : role-clinical-trial-1-ds.
  2. Identifiez ou créez le groupe de membres dont les membres devraient pouvoir assumer le rôle d'accès. Par exemple : clinical-trial-1-ds.
  3. Synchronisez les deux groupes avec Databricks à l'aide de votre connecteur SCIM. Voir Synchroniser les utilisateurs et les groupes depuis votre fournisseur d'identité à l'aide de SCIM.

Étape 2 : attribuez les deux groupes à votre Workspace​

Attribuez le rôle d'accès et le groupe de membres aux workspaces où ils doivent être disponibles. Consultez Attribuer un groupe à un workspace.

Étape 3 : Accorder l'accès aux données et aux assets du Workspace.​

remarque

Si vous avez réutilisé un groupe de fournisseur d'identité existant à l'étape 1, le rôle d'accès dispose déjà de ses autorisations Databricks et vous pouvez ignorer cette étape.

Accordez les autorisations de rôle d'accès sur vos données sensibles et vos assets de workspace, en suivant les mêmes étapes que l'approche 1, étape 2.

Étape 4 : accorder la permission « Peut supposer » au groupe membre​

Accordez au groupe membre l'autorisation d'Assumer sur le rôle d'accès . Tous les membres du groupe membre héritent automatiquement de l'autorisation d'Assumer. Voir Gérer les autorisations sur un groupe.

Étape 5 : les utilisateurs assument le rôle​

Les membres du groupe membre peuvent assumer le rôle d'accès. Consultez Changer de rôle pour connaître les méthodes disponibles.

Étapes suivantes​

  • Gérer les autorisations Assume : accordez ou révoquez Assume sur le rôle d’accès à l’aide de l’interface utilisateur ou de l’API. Voir Gérer les permissions sur un groupe.
  • Assumez le rôle : utilisez le sélecteur de rôle, les clusters de mode d'accès dédiés, la CLI, l'API ou les outils de BI tiers. Voir Changer de rôle.
  • **Restreindre le partage d'assets de Workspace** : Empêcher les utilisateurs qui endossent le rôle d'accès de partager les assets de Workspace dont le rôle est propriétaire. Consultez les contrôles de partage des actifs du Workspace.
  • Examen des limitations : Comprenez les fonctionnalités Databricks non prises en charge lors de l'assumation d'un rôle, ainsi que d'autres contraintes telles que les lacunes de l'API SCIM du Workspace pour la gestion des groupes. Consultez les limites du contrôle d'accès basé sur les rôles (RBAC).
Sur cette page