Utiliser RBAC avec ABAC

Important

RBAC est en préversion publique. ABAC est généralement disponible. Cette page décrit comment les deux fonctionnent ensemble.

Le contrôle d’accès en fonction du rôle (RBAC) et le contrôle d’accès en fonction des attributs (ABAC) dans le catalogue Unity sont des contrôles complémentaires conçus pour fonctionner ensemble. Ils répondent à différentes questions :

• RBAC détermine sous quelle identité un utilisateur agit au cours d’une session. Un utilisateur endosse un rôle afin d’agir en utilisant les autorisations associées à ce rôle au lieu de ses propres autorisations. Utilisez RBAC pour donner à un utilisateur plusieurs ensembles d’autorisations distincts qu’ils basculent de manière explicite( par exemple, en séparant l’accès entre les essais cliniques, les projets ou les niveaux de confidentialité.
• ABAC contrôle les données que l’identité active peut voir, ligne par ligne ou colonne par colonne. Les stratégies s’attachent aux données via des balises régies et s’appliquent à l’identité qui exécute la requête. Utilisez ABAC pour le filtrage ou le masquage cohérents sur de nombreuses tables pilotées par des attributs de données.

RBAC définit l’identité active pour la session et ABAC évalue ses stratégies par rapport à cette identité. Cette page explique comment cette interaction s’exécute en pratique, le comportement des fonctions SQL liées à l’identité et les modèles d’utilisation combinée.

Comportement des fonctions d’identité lorsqu’elles assument un rôle

Les fonctions SQL du catalogue Unity liées à l’identité sont évaluées en fonction de l’identité active de la session, et non de l’utilisateur authentifié sous-jacent. Lorsqu’un utilisateur assume un rôle, l’identité de session active devient le rôle :

Function	Lorsque l’utilisateur agit sous sa propre identité utilisateur	Quand l’utilisateur assume un rôle
current_user()	Retourne le nom d’utilisateur de l’utilisateur	Renvoie le nom du rôle endossé
is_member(group)	Retourne true si l’utilisateur est membre du groupe (un groupe local d’espace de travail ou un groupe de comptes affecté à l’espace de travail)	Retourne true uniquement si le rôle assumé est lui-même membre de group. Retourne false pour les groupes auxquels l’utilisateur sous-jacent appartient, mais pas le rôle assumé.
is_account_group_member(group)	Retourne true si l’utilisateur est membre du groupe au niveau du compte	Identique à is_member: retourne true uniquement en fonction des appartenances de groupe du rôle supposées, et non des utilisateurs sous-jacents.

Les stratégies ABAC qui référencent ces fonctions sont évaluées par rapport au rôle supposé, et non à l’utilisateur. Le rôle supposé est l’identité active pour l’évaluation de la stratégie ABAC, la résolution d’octroi de catalogue Unity et l’attribution d’audit. Par conséquent, le fait d’assumer un rôle modifie le comportement des politiques et des vues existantes qui reposent sur l’identité de chaque utilisateur.

Note

Un rôle n’est pas automatiquement membre de lui-même. Lorsqu’un utilisateur endosse le rôle G, current_user() renvoie G, mais is_member('G') et is_account_group_member('G') renvoient false, sauf si G a été explicitement ajouté comme membre de lui-même. Pour faire correspondre le rôle assumé dans une stratégie, comparez avec current_user() au lieu de tester l’appartenance avec is_member ou is_account_group_member.

Piège courant : vues de sécurité au niveau des lignes reposant sur current_user()

Un modèle courant commun à l’ABAC et aux filtres de lignes au niveau de la table consiste à filtrer les lignes en effectuant une jointure avec une table de provisionnement (également appelée table de mappage ou liste de contrôle d’accès), indexée sur le nom d’utilisateur retourné par current_user(). Par exemple:

CREATE OR REPLACE FUNCTION facility_filter(facility_id STRING)
RETURN EXISTS (
  SELECT 1
  FROM governance.user_facility_provisioning p
  WHERE p.user = current_user()
    AND p.facility_id = facility_id
);

Lorsque le même utilisateur assume un rôle, current_user() ne retourne plus son nom d’utilisateur. Elle renvoie le nom du rôle. Étant donné que le rôle n’est pas dans la table d’approvisionnement, le filtre ne retourne aucune ligne et l’utilisateur semble perdre l’accès aux données qu’il a accordées.

Ajouter le rôle à la table d’approvisionnement

Traitez le rôle comme un autre principal dans vos données d’approvisionnement : insérez une ligne par rôle avec les installations (ou d’autres attributs) que le rôle doit voir. Le filtre vérifie ensuite si l’identité active est l’utilisateur ou le rôle endossé.

Modèles d’utilisation combinée

Voici des exemples de la façon dont les clients utilisent RBAC et ABAC ensemble pour résoudre des problèmes réels de contrôle d’accès. Ce sont des points de départ, pas des recettes exhaustives.

Filtres de lignes par projet basés sur le rôle assumé

Le filtrage des lignes par projet est un besoin courant dans la recherche sur les essais cliniques, le marketing externalisé, le conseil aux clients et d’autres contextes dans lesquels une équipe travaille sur plusieurs projets isolés. L’exemple suivant utilise des essais cliniques, mais le modèle se généralise à n’importe quelle isolation des données par projet.

Une organisation de recherche clinique exécute plusieurs essais simultanés, chacun dans son propre rôle d’accès. Étiquetez chaque table avec l’identificateur du projet. Les utilisateurs voient uniquement les lignes du projet correspondant au rôle qu’ils ont actuellement endossé.

Configuration :

• Les tables sous clinical_trials.* ont une colonne project_id taguée avec la clé balise governedproject.
• Chaque projet a un rôle d’accès correspondant nommé role-<project> (par exemple, role-alpha, role-beta).
• Les utilisateurs disposent de l’autorisation « Assume » uniquement sur les rôles des projets sur lesquels ils travaillent.

Fonction UDF du filtre de lignes :

CREATE FUNCTION project_match(project_id STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN current_user() = CONCAT('role-', project_id);

Politique:

CREATE POLICY per_project_row_filter
ON CATALOG clinical_trials
ROW FILTER project_match
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('project') AS project
USING COLUMNS (project);

Cette UDF met en corrélation l’identité active avec la valeur de la balise project de chaque ligne, de sorte que les clauses ciblant les principaux, comme TO / EXCEPT, ne permettent pas de l’exprimer — elles ciblent les principaux, pas le contenu des lignes. Comme l’explique le guide sur le ciblage du principal, préférez TO / EXCEPT pour un ciblage simple du principal et réservez les fonctions d’identité dans une UDF aux cas comme celui-ci, où une seule règle dépend à la fois de l’identité active et du contenu de la ligne.

Une stratégie unique couvre chaque projet : USING COLUMNS (project) passe la valeur d’étiquette de project chaque ligne dans la fonction UDF. Vous n’avez donc pas besoin d’une stratégie distincte par projet. Pour obtenir la forme générale de cette technique : conduire l’accès aux lignes à partir d’une table de recherche au lieu de la correspondance de nom de rôle , consultez Utiliser des tables de mappage pour le contrôle d’accès dynamique.

Comportement:

• Un utilisateur qui utilise sa propre identité ne voit aucune ligne dans aucun clinical_trials tableau. current_user() retourne leur nom d’utilisateur, qui ne correspond jamais au modèle d’affectation role-* de noms. Il s’agit du refus par défaut prévu.
• Un utilisateur qui suppose que role-alpha ne voit que les lignes où project_id est égal à alpha. Le passage à role-beta remplace les données visibles sans relancer d’autres requêtes.

Assouplissement du masquage des informations personnelles identifiables pour les utilisateurs assumant un rôle désigné

Par défaut, les colonnes PII (SSN, e-mail, téléphone) apparaissent masquées pour tout le monde. Pour voir les valeurs brutes, un utilisateur doit explicitement endosser un rôle désigné autorisé à accéder aux informations personnelles identifiables. Les journaux d’audit enregistrent l’événement de prise de rôle, de sorte que « J’ai eu besoin de consulter de véritables données personnelles (PII) » devient une demande explicite traçable plutôt qu’une autorisation permanente implicite.

Configuration :

• Les colonnes sensibles sont associées à la clé piigoverned tag (valeurs autorisées telles que ssn, email, phone).
• Un rôle d’accès nommé role-pii-cleared, « Assume », est accordé aux utilisateurs autorisés à consulter les données personnelles identifiables brutes.

Fonction UDF du masque de colonne (statique : la stratégie cible les principaux à masquer) :

CREATE FUNCTION mask_pii(val STRING) RETURNS STRING
DETERMINISTIC
RETURN '***';

Politique:

CREATE POLICY pii_default_mask
ON CATALOG customer_data
COLUMN MASK mask_pii
TO `account users`
EXCEPT `role-pii-cleared`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS pii_col
ON COLUMN pii_col;

La clause EXCEPT exclut entièrement role-pii-cleared de la stratégie, de sorte que la fonction UDF n’est jamais appelée lorsque ce rôle est l’identité active. Consultez Préférer TO/EXCEPT pour le ciblage principal pour obtenir des conseils généraux sur le ciblage principal via TO / EXCEPT.

Comportement:

• Un utilisateur agissant avec sa propre identité utilisateur voit *** dans chaque colonne de données personnelles identifiables. Il s’agit de l’état par défaut pour tout le monde, y compris les utilisateurs qui ont l’autorisation Assume sur role-pii-cleared.
• Après avoir pris en compte role-pii-cleared, la stratégie ne s’applique plus à la session, et le même utilisateur voit les valeurs brutes.
• Entrées du journal d’audit de la session enregistrée identity_metadata.run_as = role-pii-cleared, afin que les examinateurs puissent voir exactement quand les données personnelles ont été démasquées et par qui.

Stratégies de niveau de sensibilité qui varient selon le rôle assumé

Les données sont classées en niveaux de confidentialité (internal, confidential, restricted). Chaque niveau a un rôle d’accès correspondant, ce qui restricted implique l’accès à confidential et internal également. Une seule UDF de filtrage des lignes contrôle la visibilité des lignes en comparant le niveau de chaque ligne au rôle attribué à l’utilisateur.

Configuration :

• Les tables ont une sensitivity_level colonne étiquetée avec la clé sensitivity de balise régie (valeurs autorisées : internal, confidential, restricted).
• Trois rôles d’accès : role-sens-internal, role-sens-confidential, role-sens-restricted.

Fonction UDF du filtre de lignes :

CREATE FUNCTION sensitivity_allowed(row_sensitivity STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN CASE
  WHEN current_user() = 'role-sens-restricted' THEN TRUE
  WHEN current_user() = 'role-sens-confidential' THEN row_sensitivity IN ('internal', 'confidential')
  WHEN current_user() = 'role-sens-internal' THEN row_sensitivity = 'internal'
  ELSE FALSE
END;

Politique:

CREATE POLICY sensitivity_filter
ON CATALOG corp_data
ROW FILTER sensitivity_allowed
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('sensitivity') AS sens
USING COLUMNS (sens);

Étant donné qu’un rôle n’est pas membre de lui-même, cette fonction UDF se compare current_user() à chaque nom de rôle plutôt que de tester l’appartenance avec is_account_group_member(). Consultez la remarque ci-dessus pour savoir pourquoi les tests d’appartenance ne correspondent pas au rôle supposé. Consultez Considérations relatives aux performances des règles de filtrage des lignes et de masquage des colonnes pour connaître les incidences sur les performances des fonctions d’identité dans les UDF.

Comportement:

• Un utilisateur qui utilise sa propre identité utilisateur ne voit aucune ligne. La branche ELSE FALSE correspond à tout ce qui n’est pas l’un des trois rôles. Comme dans l’exemple par projet ci-dessus, il s’agit du refus par défaut prévu.
• En supposant que role-sens-internal n’affiche que internal lignes.
• En supposant que role-sens-confidential affiche les lignes internal et confidential.
• À condition que role-sens-restricted révèle toutes les lignes.

Les utilisateurs supposent le niveau le plus élevé dont ils ont besoin pour la session ; le filtre exclut automatiquement tout ce qui précède ce niveau sans exiger que l’utilisateur sache quelles tables contiennent les classifications.

Attribution de l’audit

Les évaluations de stratégie ABAC et les requêtes sous-jacentes respectent l’attribution RBAC run_as / run_by . Les entrées du journal d’audit enregistrent identity_metadata.run_by l’utilisateur d’authentification et identity_metadata.run_as le rôle supposé, quelles que soient les stratégies ABAC appliquées lors de l’évaluation. Consultez la référence de la table système du journal d’audit pour obtenir le schéma complet du journal d’audit.

Étapes suivantes

• Accès exclusif de modèle : appliquez des modèles pour configurer l’accès exclusif à l’aide d’un groupe local de compte ou d’un groupe synchronisé à partir de Microsoft Entra ID. Voir l’accès exclusif au modèle.
• Changer de rôle : assumez un rôle à l’aide du sélecteur de rôles, des clusters en mode d’accès dédié, de l’interface CLI, de l’API ou des outils décisionnels tiers. Consultez Changer de rôle.
• Gérer les autorisations Assume : Accorder ou révoquer Assume sur un groupe afin que les utilisateurs puissent assumer le rôle correspondant. Consultez Gérer les autorisations sur un groupe.
• Découvrez les concepts fondamentaux d’ABAC : découvrez comment fonctionnent les balises gouvernées, les politiques et l’évaluation des politiques. Consultez le contrôle d’accès basé sur les attributs dans le catalogue Unity.