Modèle d’accès exclusif

Important

Cette fonctionnalité est disponible en préversion publique.

L’accès exclusif est un principe qui rend l’accès aux données explicite au lieu d’être implicite. Avec les autorisations de catalogue Unity standard, les autorisations suivent l’utilisateur : un utilisateur accumule les autorisations au fil du temps et les transporte partout, de sorte que leur accès est la somme des autorisations qu’ils ont accordées directement et les autorisations dont ils héritent de tous les groupes dont ils sont membres. 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 accéder en mode permanent. Cela les empêche d’accéder aux données comme leur propre identité et de mélanger les données entre les cas d’usage, les essais cliniques, les projets ou les clients.

Exemple d’accès exclusif : l’utilisateur 1 peut supposer le groupe Study 1 ou le groupe Study 2. Agissant comme leur propre identité, l’utilisateur 1 ne peut pas interroger les données de l’étude. Agissant en tant que groupe d’études 1, l’utilisateur 1 peut interroger uniquement les données de l’étude 1 ; agissant en tant que groupe d’études 2, seules les données de l’étude 2.

Pour vous aider à décrire ce modèle, nous utilisons deux termes pour les identités distinctes impliquées. Il s’agit d’étiquettes explicites, pas de terminologie Azure Databricks formelle :

  • Rôle d’accès : groupe sans membres disposant d’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 atteindre les données sensibles sans assumer le rôle, ce qui élimine l’accès exclusif. Dans Azure Databricks, un rôle d’accès est implémenté en tant que groupe.
  • Groupe de membres : groupe dont les membres sont les utilisateurs autorisés à assumer le rôle d’accès. Accorder l’autorisation « Assume » sur le rôle d’accès au groupe de membres permet à tous ses membres d’endosser ce rôle. Un groupe de membres est une commodité, et non une exigence. Vous pouvez également accorder Assume directement aux utilisateurs individuels ou aux principaux de service. Cela vous évite de gérer les autorisations Assume pour un principal à la fois.

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

Azure Databricks prend en charge deux approches pour créer le rôle d’accès. Sélectionnez celui qui convient le mieux à la façon dont votre organisation gère les identités :

  • Rôle d’accès local de compte : créez un groupe Azure Databricks local de compte en tant que rôle d’accès. À privilégier lorsque la création d’un groupe dans Azure Databricks est plus simple que la création d’un nouveau groupe Microsoft Entra ID (par exemple, lorsque les modifications apportées à Microsoft Entra ID nécessitent un ticket informatique ou un examen interne).
  • Rôle d’accès synchronisé à partir de Microsoft Entra ID : utilisez un groupe de Microsoft Entra ID vide comme rôle d’accès, synchronisé avec Azure Databricks via SCIM. Mieux quand vous gérez déjà des groupes dans Microsoft Entra ID et que vous préférez conserver tout le cycle de vie des groupes.

Exigences

  • Un espace de travail avec catalogue Unity.
  • Autorisations d’administrateur de compte ou d’administrateur d’espace de travail pour créer des groupes et accorder Assume.

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

Dans cette approche, le rôle d’accès est un groupe Azure Databricks local géré entièrement dans Azure Databricks. Le groupe membre peut être n’importe quel groupe autorisé à assumer le rôle d’accès : généralement un groupe synchronisé à partir de Microsoft Entra ID contenant les utilisateurs autorisés à accéder aux données sensibles.

Rôle d’accès local de compte : un groupe local de compte Databricks sert de rôle d’accès, avec un groupe membre qui lui a accordé l’autorisation Assume.

Étape 1 : Créer le rôle d’accès et l’affecter à votre espace de travail

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

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

Console de compte

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

API Groupes de comptes

databricks api post /api/2.0/account/scim/v2/Groups --json '{
  "displayName": "<access-role-name>"
}'

Après avoir créé le rôle d’accès, affectez-le aux espaces de travail où il doit être disponible. Voir Affecter un groupe à un espace de travail.

Étape 2 : Accorder l’accès aux ressources de données et d’espace de travail

Accordez les autorisations de rôle d’accès sur vos ressources de données sensibles et d’espace de travail à l’aide des outils de Azure Databricks standard :

  • Éléments sécurisables du catalogue Unity : utilisez GRANT des instructions ou l’Explorateur de catalogues pour accorder des privilèges UC au rôle d’accès.
  • Ressources de l’espace de travail : utilisez des listes de contrôle d’accès (ACL) pour accorder les autorisations de rôle d’accès sur les blocs-notes, les travaux, les entrepôts SQL et d’autres objets d’espace de travail.

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

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 le rôle

Accordez aux utilisateurs, aux principaux de service ou aux groupes membres qui doivent être en mesure d’assumer ce rôle l’autorisation Assume . Consultez Gérer les autorisations sur un groupe.

Étape 4 : Les utilisateurs assument le rôle

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

Approche 2 : Accès au rôle synchronisé à partir de Microsoft Entra ID

Utilisez cette approche pour gérer le rôle d’accès dans Microsoft Entra ID et le synchroniser avec Azure Databricks à l’aide de SCIM, au lieu de créer un rôle d’accès distinct Azure Databricks géré. Le rôle d’accès et le groupe de membres proviennent de Microsoft Entra ID.

Rôle d’accès synchronisé par le fournisseur d’identité : un groupe IdP vide synchronisé avec Databricks sert de rôle d’accès, avec un groupe de membres IdP qui lui a accordé l’autorisation Assume.

Dans cette approche :

  • Le groupe d’accès est un groupe Microsoft Entra ID vide synchronisé avec Azure Databricks, auquel des autorisations sur les données sensibles ont été accordées.
  • Le groupe de membres est un groupe Microsoft Entra ID existant dont les membres sont les utilisateurs autorisés à assumer le rôle d’accès. Vous accordez Assume au groupe de membres pour le rôle d’accès ; ainsi, tous ses membres héritent automatiquement de l’autorisation Assume.

Note

Le rôle d’accès doit rester vide dans Microsoft Entra ID. Les membres ajoutés au rôle d'accès dans Microsoft Entra ID sont synchronisés avec Azure Databricks et héritent directement des autorisations du rôle, ce qui signifie qu'ils peuvent accéder aux données sensibles sans avoir à assumer le rôle. Cela interrompt le modèle d’accès exclusif.

Étape 1 : Configurer des groupes dans Microsoft Entra ID

La façon dont vous configurez les groupes dépend du fait que vous partiez de zéro ou que vous réutilisiez un groupe Microsoft Entra ID existant qui dispose déjà d’autorisations dans Azure Databricks.

Nouvelle configuration

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 doivent être en mesure d’assumer le rôle d’accès. Par exemple : clinical-trial-1-ds.
  3. Synchronisez les deux groupes pour Azure Databricks à l’aide de votre connecteur SCIM. Voir Synchroniser les utilisateurs et groupes de Microsoft Entra ID à l'aide de SCIM.

Réutiliser l’existant

Utilisez cette variante si vous avez déjà un groupe synchronisé à partir de Microsoft Entra ID dont les membres ont reçu des autorisations pour les données sensibles dans Azure Databricks. La réaffectation du groupe existant en tant que rôle d’accès évite d’accorder à nouveau toutes ses autorisations à un nouveau groupe.

Dans votre fournisseur d’identité :

  1. Créez un groupe Microsoft Entra ID pour servir de groupe membre. Par exemple, si votre groupe existant est clinical-trial-1-ds, créez clinical-trial-1-ds-members.
  2. Déplacez tous les membres du groupe Microsoft Entra ID existant dans le nouveau groupe de membres.
  3. Le groupe Microsoft Entra ID existant est désormais vide dans Microsoft Entra ID et est converti en rôle d’accès. Étant donné qu’il conserve ses autorisations de Azure Databricks existantes, vous pouvez ignorer l’étape 3 ci-dessous.
  4. Synchronisez les deux groupes pour Azure Databricks à l’aide de votre connecteur SCIM. Voir Synchroniser les utilisateurs et groupes de Microsoft Entra ID à l'aide de SCIM.

Étape 2 : Affecter les deux groupes à votre espace de travail

Attribuez le rôle d’accès et le groupe de membres aux espaces de travail où ils doivent être disponibles. Voir Affecter un groupe à un espace de travail.

Étape 3 : Accorder l’accès aux ressources de données et d’espace de travail

Note

Si vous réaffectez un groupe de Microsoft Entra ID existant à l’étape 1, le rôle d’accès dispose déjà de ses autorisations de Azure Databricks et vous pouvez ignorer cette étape.

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

Étape 4 : Accorder l’autorisation d’assumer au groupe membre

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

Étape 5 : Les utilisateurs assument le rôle

Les membres du groupe de membres 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 : Accorder ou révoquer Assume sur le rôle d’accès à l’aide de l’interface utilisateur ou de l’API. Consultez Gérer les autorisations sur un groupe.
  • Assumez le rôle : utilisez le sélecteur de rôles, les clusters en mode d’accès dédié, l’interface CLI, l’API ou les outils décisionnels tiers. Consultez Changer de rôle.
  • Restreindre le partage des ressources de l’espace de travail : empêchez les utilisateurs d’assumer le rôle d’accès pour partager les ressources de l’espace de travail dont le rôle appartient. Consultez les contrôles de partage des ressources de l’espace de travail.
  • Passer en revue les limitations : comprendre quelles fonctionnalités Azure Databricks ne sont pas prises en charge lors de l’hypothèse d’un rôle, ainsi que d’autres contraintes telles que les lacunes dans l’API SCIM de l’espace de travail pour la gestion des groupes. Consultez les limitations du contrôle d’accès en fonction du rôle (RBAC).