Utiliser RBAC avec ABAC

info

Aperçu

RBAC est en Aperçu public. ABAC est généralement disponible. Cette page décrit comment les deux fonctionnent ensemble.

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

• **RBAC** contrôle *quelle identité* un utilisateur utilise pour une session. Un utilisateur assume un rôle pour agir avec les autorisations de ce rôle plutôt qu'avec les siennes. Utilisez le RBAC pour donner à un utilisateur plusieurs ensembles d'autorisations distincts entre lesquels il bascule explicitement — par exemple, en séparant l'accès entre les essais cliniques, les projets ou les niveaux de sensibilité.
• ABAC contrôle quelles données l'identité active peut voir, ligne par ligne ou colonne par colonne. Les politiques s'appliquent aux données via des tags gouvernés et à toute identité qui exécute la query. Utilisez ABAC pour un filtrage ou un masquage cohérent sur de nombreuses tables pilotées par les attributs de données.

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

Comportement des fonctions d'identité lors de l'attribution d'un rôle

Les fonctions SQL liées à l'identité de Unity Catalog se résolvent par rapport à l'identité active de la session, et non à l'utilisateur authentifiant sous-jacent. Lorsqu'un utilisateur assume un rôle, l'identité de session active devient le rôle :

Fonction	Lorsque l'utilisateur agit en tant que son identité d'utilisateur	Lorsqu'un utilisateur assume un rôle
current_user()	Retourne le nom d'utilisateur de l'utilisateur	Renvoie le nom du rôle assumé.
is_member(group)	Renvoie true si l'utilisateur est membre du groupe (un groupe local au workspace ou un groupe de comptes attribué au workspace)	Renvoie true uniquement si le rôle assumé est lui-même membre de group. Renvoie false pour les groupes dont l'utilisateur sous-jacent est membre, mais pas le rôle assumé.
is_account_group_member(group)	Renvoie true si l'utilisateur est membre du groupe au niveau du compte	Identique à is_member: renvoie true uniquement en fonction des appartenances aux groupes du rôle assumé, et non de celles de l'utilisateur sous-jacent.

Fonction	Lorsque l'utilisateur agit en tant que son identité d'utilisateur	Lorsqu'un utilisateur assume un rôle
current_user()	Retourne le nom d'utilisateur de l'utilisateur	Renvoie le nom du rôle assumé.
is_member(group)	Renvoie true si l'utilisateur est membre du groupe (un groupe local au workspace ou un groupe de comptes attribué au workspace)	Renvoie true uniquement si le rôle assumé est lui-même membre de group. Renvoie false pour les groupes dont l'utilisateur sous-jacent est membre, mais pas le rôle assumé.
is_account_group_member(group)	Renvoie true si l'utilisateur est membre du groupe au niveau du compte	Identique à is_member: renvoie true uniquement en fonction des appartenances aux groupes du rôle assumé, et non de celles de l'utilisateur sous-jacent.

Les politiques ABAC qui référencent ces fonctions sont évaluées par rapport au rôle assumé , et non par rapport à l'utilisateur. Le rôle assumé est l'identité active pour l'évaluation des politiques ABAC, la résolution des octrois Unity Catalog et l'attribution de l'audit. En conséquence, l'attribution d'un rôle modifie le comportement des politiques et des vues existantes qui ont été conçues autour de l'identité par utilisateur.

remarque

Un rôle n’est pas automatiquement membre de lui-même. Lorsqu’un utilisateur assume le rôle G, current_user() renvoie G, mais is_member('G') et is_account_group_member('G') renvoient false, à moins que G n’ait été explicitement ajouté en tant que membre de lui-même. Pour correspondre au rôle assumé dans une politique, comparez à current_user() plutôt que de tester l’adhésion avec is_member ou is_account_group_member.

Écueil courant : vues de sécurité au niveau des lignes basées sur current_user()

Un schéma courant à travers ABAC et les filtres de ligne 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 renvoyé par current_user(). Par exemple :

SQL

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
);

Lorsqu'un même utilisateur assume un rôle, current_user() ne renvoie plus son nom d'utilisateur. Il renvoie le nom du rôle. Étant donné que le rôle ne figure pas dans la table de provisionnement, le filtre ne renvoie aucune ligne et l'utilisateur semble perdre l'accès aux données qui lui ont été accordées.

Ajouter le rôle à la table de provisionnement

Traitez le rôle comme un autre principal dans vos données de provisionnement : insérez une ligne par rôle avec les installations (ou autres attributs) que le rôle devrait voir. Le filtre correspond alors à si l'identité active est l'utilisateur ou le rôle assumé.

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 contractuel, le conseil client et d'autres contextes où une équipe travaille sur plusieurs projets isolés. L'exemple suivant utilise les essais cliniques, mais le modèle se généralise à toute 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'identifiant du projet. Les utilisateurs ne voient que les lignes du projet dont ils ont actuellement assumé le rôle.

Installer :

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

Filtre de ligne UDF :

SQL

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

Politique :

SQL

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 tag project de chaque ligne, de sorte que les clauses ciblant les principaux, telles que TO / EXCEPT, ne peuvent pas l'exprimer — celles-ci ciblent les principaux, pas le contenu des lignes. Comme l'explique le guide de ciblage des principaux, préférez TO / EXCEPT pour un simple ciblage des principaux et réservez les fonctions d'identité à l'intérieur d'une UDF pour des cas comme celui-ci, où une seule règle dépend à la fois de l'identité active et du contenu de la ligne.

Une seule politique couvre chaque projet : USING COLUMNS (project) transmet la valeur de balise project de chaque ligne à la UDF, vous n'avez donc pas besoin d'une politique distincte par projet. Pour la forme générale de cette technique — qui gère l'accès aux lignes à partir d'une table de consultation plutôt que par une correspondance de noms de rôles —, consultez Utiliser des tables de mappage pour le contrôle d'accès dynamique.

Comportement :

• Un utilisateur agissant en tant que son identité d'utilisateur ne voit aucune ligne dans une table clinical_trials quelconque. current_user() renvoie son nom d'utilisateur, qui ne correspond jamais au modèle de nommage role-*. C'est la négation par default prévue.
• Un utilisateur assumant role-alpha ne voit que les lignes où project_id est égal à alpha. Le passage à role-beta échange les données visibles sans réinterroger quoi que ce soit d'autre.

Masquage des données à caractère personnel (DCP) assoupli pour les utilisateurs agissant en tant que rôle désigné

By default, les colonnes PII (SSN, e-mail, téléphone) apparaissent masquées pour tous. Pour voir les valeurs brutes, un utilisateur doit explicitement assumer un rôle désigné pour les IPI. Les logs d’audit enregistrent l’événement d’assomption de rôle, de sorte que « J’ai eu besoin de consulter de véritables IPI » devient une option auditable plutôt qu’une permission ambiante.

Installer :

• Les colonnes sensibles sont balisées avec la clé de balise gouvernée pii (valeurs autorisées telles que ssn, email, phone).
• Un rôle d'accès nommé role-pii-cleared accorde l'autorisation Assume aux utilisateurs qui sont autorisés à afficher les données à caractère personnel (DCP) brutes.

UDF de masque de colonne (statique — la politique cible les principaux à masquer) :

SQL

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

Politique :

SQL

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 role-pii-cleared entièrement de la politique, de sorte que l'UDF n'est jamais appelée lorsque ce rôle est l'identité active. Consultez Préférer À/SAUF pour le ciblage de principal pour obtenir des conseils généraux sur le ciblage de principal via TO / EXCEPT.

Comportement :

• Un utilisateur agissant en tant qu'identité d'utilisateur voit *** dans chaque colonne de PII. C'est l'état par default pour tout le monde, y compris les utilisateurs qui ont la permission d'assumer sur role-pii-cleared.
• Une fois role-pii-cleared assumé, la politique ne s'applique plus à la session, et le même utilisateur voit les valeurs brutes.
• Audit Logs pour l'enregistrement de session identity_metadata.run_as = role-pii-cleared, afin que les réviseurs puissent voir exactement quand les PII ont été démasquées et par qui.

Politiques de niveau de sensibilité qui varient selon le rôle assumé

Les données sont classées par niveaux de sensibilité (internal, confidential, restricted). Chaque niveau a un rôle d'accès correspondant, restricted impliquant également l'accès à confidential et internal. Un seul filtre de ligne UDF contrôle la visibilité des lignes en comparant le niveau de chaque ligne au rôle assumé par l'utilisateur.

Installer :

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

Filtre de ligne UDF :

SQL

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 :

SQL

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);

Parce qu'un rôle n'est pas membre de lui-même, cette UDF compare current_user() à chaque nom de rôle plutôt que de tester l'appartenance avec is_account_group_member(). Consultez la note ci-dessus expliquant pourquoi les tests d'appartenance ne correspondent pas au rôle assumé. Consultez les Considérations sur les performances pour les politiques de filtrage des lignes et de masquage des colonnes concernant les caractéristiques de performance des fonctions d'identité dans les UDF.

Comportement :

• Un utilisateur agissant en tant que sa propre identité d'utilisateur ne voit aucune ligne . La Branch 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 default prévu.
• En supposant que role-sens-internal ne révèle que internal lignes.
• En supposant role-sens-confidential, cela révèle internal et confidential lignes.
• En supposant que role-sens-restricted révèle toutes les lignes.

Les utilisateurs prennent le niveau le plus élevé dont ils ont besoin pour la session ; le filtre exclut automatiquement tout ce qui est au-dessus de ce niveau sans que l'utilisateur n'ait besoin de savoir quelles tables détiennent quelles classifications.

Attribution de l’audit

Les évaluations de politiques ABAC et les query sous-jacentes respectent l'attribution RBAC run_as / run_by. Les entrées de Logs d'audit enregistrent identity_metadata.run_by en tant qu'utilisateur d'authentification et identity_metadata.run_as en tant que rôle assumé, quelles que soient les politiques ABAC appliquées lors de l'évaluation. Consultez la référence de la table système de Logs d'audit pour le schéma complet des Logs d'audit.

Étapes suivantes

• Accès exclusif du modèle : Appliquez des modèles pour configurer l'accès exclusif à l'aide d'un groupe local au compte ou d'un groupe synchronisé à partir de votre fournisseur d'identité. Consultez Accès exclusif au modèle.
• Changer de rôle : assumez un rôle à l'aide du sélecteur de rôle, des clusters en mode d'accès dédié, de la CLI, de l'API ou d'outils de BI tiers. Voir Changer de rôle.
• **Gérer les permissions d'assumer** : accordez ou révoquez l'accès à un groupe afin que les utilisateurs puissent assumer le rôle correspondant. Voir Gérer les permissions sur un groupe.
• **Revoir les concepts fondamentaux de l'ABAC** : découvrez comment fonctionnent les tags gouvernés, les politiques et l'évaluation des politiques. Consultez le contrôle d'accès basé sur les attributs dans Unity Catalog.