Stratégies GRANT ABAC pour les modèles (Bêta)

info

Bêta

Les politiques ABAC GRANT sont en version bêta. En version bêta, les politiques GRANT peuvent accorder le privilège EXECUTE sur les modèles, attachés au niveau du catalogue ou du schéma. Des privilèges supplémentaires et des types sécurisables seront pris en charge dans les futures versions.

Cette page décrit les politiques ABAC GRANT, qui accordent dynamiquement des privilèges Unity Catalog aux objets sécurisables dont les balises régies correspondent à une condition. Elle couvre la façon de les créer, modifier, lister et supprimer dans l'Explorateur de catalogues, SQL et le SDK Databricks, comment les politiques GRANT interagissent avec les octrois directs, ainsi que la portée et les limitations actuelles de la version Bêta.

Pour un aperçu de l'ABAC et des concepts clés, y compris les tags régis et les fonctions intégrées telles que has_tag et has_tag_value, consultez Concepts clés du contrôle d'accès basé sur les attributs (ABAC).

Exigences en matière de compute

La création, la modification ou la suppression de stratégies GRANT avec SQL nécessite un cluster de calcul classique exécutant Databricks Runtime 18 ou version ultérieure.

remarque

Databricks Runtime 18 est plus récent que Databricks Runtime 18,0, 18,1 et 18,2. Les fonctionnalités qui auraient auparavant été livrées sous forme de version numérotée ultérieure sont désormais livrées sous forme de mises à jour datées pour Databricks Runtime 18 à la place. Pour plus de détails, consultez À propos des notes de version unifiées.

Qu’est-ce qu’une politique GRANT ?

Une politique GRANT est une politique de contrôle d'accès basée sur les attributs qui accorde dynamiquement des privilèges Unity Catalog aux objets sécurisables dont les tags régis correspondent à la condition de la politique. Unity Catalog évalue la condition WHEN de la stratégie par rapport aux tags régis sur chaque objet sécurisable dans le champ d’application de la stratégie chaque fois que l’accès est vérifié, et accorde le privilège sur chaque objet sécurisable qui correspond.

En comparaison, les instructions GRANT directes attribuent des privilèges sur des objets sécurisables identifiés par leur espace de noms à trois niveaux (catalog.schema.object).

En version bêta, les politiques GRANT prennent en charge un privilège sur un type sécurisable : EXECUTE sur les modèles. Les modèles MLflow enregistrés par les clients et les modèles de base hébergés par Databricks dans system.ai sont tous deux couverts. Consultez Gérer le cycle de vie des modèles dans Unity Catalog pour savoir comment les modèles MLflow sont enregistrés dans Unity Catalog, et Accéder aux modèles d'IA générative et aux modèles LLM depuis Unity Catalog pour les modèles de base hébergés par Databricks.

Les politiques GRANT peuvent faire référence soit à des tags gouvernés que vous créez vous-même, soit à des tags système prédéfinis par Databricks dans leurs conditions.

Par exemple, la politique suivante utilise le tag gouverné lifecycle appliqué aux modèles MLflow enregistrés par le client dans production.ml_models. La politique octroie EXECUTE uniquement sur les modèles tagués lifecycle = 'production':

SQL

CREATE POLICY grant_production_model_access
ON SCHEMA production.ml_models
COMMENT 'Grant EXECUTE on production MLflow models'
TO `analysts`
GRANT EXECUTE FOR MODELS
WHEN has_tag_value('lifecycle', 'production');

La politique suivante utilise la balise système ai.model_creator préappliquée pour accorder EXECUTE sur chaque modèle de fondation hébergé par Anthropic dans system.ai à data_scientists, à l'exception de contractors. La politique couvre automatiquement tout modèle Anthropic que Databricks ajoutera ultérieurement :

SQL

CREATE POLICY grant_anthropic_foundation_models
ON SCHEMA system.ai
COMMENT 'Grant EXECUTE on Anthropic foundation models'
TO `data_scientists`
EXCEPT `contractors`
GRANT EXECUTE FOR MODELS
WHEN has_tag_value('ai.model_creator', 'anthropic');

L'accès équivalent utilisant des octrois directs nécessite une instruction par modèle dans system.ai, rééditée à mesure que Databricks ajoute de nouveaux modèles Anthropic :

SQL

GRANT EXECUTE ON MODEL `system`.`ai`.`databricks-claude-sonnet-4-6` TO `data_scientists`;
GRANT EXECUTE ON MODEL `system`.`ai`.`databricks-claude-opus-4-7` TO `data_scientists`;
GRANT EXECUTE ON MODEL `system`.`ai`.`databricks-claude-haiku-4-5` TO `data_scientists`;

Les politiques GRANT diffèrent des politiques de filtres de lignes et de masques de colonne de deux manières :

• Les politiques de filtre de lignes et de masque de colonne restreignent le contenu des données auxquelles un utilisateur peut déjà accéder. Les politiques GRANT déterminent si l'utilisateur peut accéder à l'objet.
• Les politiques de filtre de ligne et de masque de colonne nécessitent une fonction définie par l’utilisateur (UDF) pour implémenter le filtre ou le masque. Les politiques GRANT n’utilisent pas les UDF. La condition est exprimée en ligne dans la définition de la politique.

Comment les politiques de GRANT interagent avec les autorisations directes

Les privilèges effectifs sur un objet sont l'union des octrois directs et de toute politique de GRANT applicable. Un principal détient EXECUTE sur un modèle lorsque l'une des conditions suivantes est vraie :

• Une politique GRANT attachée au catalogue ou au schéma du modèle répertorie le principal dans TO (et non dans EXCEPT), et la condition WHEN de la politique correspond aux tags du modèle.
• Une GRANT EXECUTE directe sur le modèle, son schéma ou son catalogue est en vigueur pour ce principal, qu'elle soit accordée directement, par l'intermédiaire de l'appartenance à un groupe, ou par d'autres privilèges administratifs.

Parce que l'accès est l'union de ces sources, une politique GRANT plus sélective ne signifie pas qu'un principal exclu manque de EXECUTE. Le principal peut toujours détenir le privilège par le biais d'une attribution directe sur le modèle, ou son schéma ou catalogue parent. Si vous avez l'intention d'utiliser des politiques GRANT comme moyen principal de contrôler EXECUTE sur les modèles, déterminez d'abord si des grants directs déjà en place pourraient outrepasser la politique :

• Utilisez SHOW EFFECTIVE POLICIES ON SCHEMA <parent_schema> (ou ON CATALOG <parent_catalog>) pour lister chaque politique GRANT dont la portée couvre les modèles dans ce schéma ou ce catalogue. SHOW EFFECTIVE POLICIES ne prend pas en charge ON MODEL directement. L'API REST équivalente est GET /api/2.1/unity-catalog/policies/{on_securable_type}/{on_securable_fullname}?include_inherited=true (Python SDK : w.policies.list_policies(..., include_inherited=True)).
• Utilisez SHOW GRANTS sur le modèle et ses ancêtres pour énumérer les autorisations directes. L'API REST équivalente pour les autorisations directes sur un objet sécurisable est GET /api/2.1/unity-catalog/permissions/{securable_type}/{full_name} (SDK Python : w.grants.get(...)) ; pour l'union des autorisations directes et héritées, utilisez GET /api/2.1/unity-catalog/effective-permissions/{securable_type}/{full_name} (SDK Python : w.grants.get_effective(...)).

Créer une politique GRANT

Vous pouvez créer une stratégie GRANT via l’interface utilisateur de Catalog Explorer, avec l’instruction SQL CREATE POLICY, ou avec le SDK Databricks.

Pour créer une stratégie GRANT, vous devez disposer de MANAGE sur le catalogue ou le schéma où la stratégie est appliquée, ou être propriétaire de cet objet sécurisable.

Catalog Explorer

1. Dans votre workspace Databricks, cliquez sur Catalogue .

2. Sélectionnez le catalogue ou le schéma où vous souhaitez associer la politique. Les politiques GRANT en version Beta ne peuvent être attachées qu'au niveau du catalogue ou du schéma.

3. Cliquez sur l'onglet tab .

4. Cliquez sur Nouvelle politique .

5. Sous Identification de la politique , saisissez un Nom de la politique et une Description facultative.

6. Sous Principals et périmètre :

   • Dans Appliqué à , sélectionnez les principaux (utilisateurs, groupes ou Service Principal) auxquels la politique s’applique.
   • Dans À l'exception de , sélectionnez éventuellement les principaux à exclure de la stratégie.
   • Dans Scope , confirmez le catalogue ou le schéma où la politique est attachée.

7. Sous Type de politique, sélectionnez Accorder l'accès.

8. Sous Objets sécurisables , sélectionnez Modèle . Le modèle est le seul type sécurisable pris en charge pour les politiques GRANT en version bêta. Les autres types de la liste (Table, Volume, Schema, Catalog) ne peuvent pas être combinés avec Accorder l'accès .

9. Sous Condition , choisissez comment définir la portée de la politique aux modèles dans le catalogue ou le schéma sélectionné :

   • Aucune condition applique la politique à tous les modèles sous le catalogue ou le schéma sélectionné.
   • Objets sécurisables correspondant à l'un de ces tags applique la politique uniquement aux modèles qui portent au moins un des tags régis sélectionnés.
   • Éléments sécurisables correspondant à une expression personnalisée vous permet d'écrire une expression basée sur des balises pour déterminer à quels modèles la politique s'applique. Consultez Conditions et fonctions intégrées pour les fonctions de condition disponibles.

10. Sous Privilèges , sélectionnez EXECUTE . EXECUTE est le seul privilège pris en charge pour les modèles en bêta.

11. Cliquez sur Afficher le code pour examiner l'instruction SQL équivalente avant d'enregistrer, puis cliquez sur Créer une politique .

SQL

La syntaxe SQL d'une politique GRANT utilise un corps GRANT ... FOR ... WHEN ... à la place de ROW FILTER ou COLUMN MASK.

SQL

CREATE [OR REPLACE] POLICY policy_name
ON { CATALOG catalog_name | SCHEMA schema_name }
[COMMENT description]
TO principal [, ...]
[EXCEPT principal [, ...]]
GRANT EXECUTE FOR MODELS
[WHEN condition]

Paramètres :

• policy_name: Un nom pour la politique. Doit être unique parmi toutes les politiques définies sur le même objet sécurisable.
• ON { CATALOG | SCHEMA }: Le périmètre où la politique est attachée. En version Beta, les politiques GRANT peuvent être attachées au niveau du catalogue ou du schéma, et non à un modèle individuel.
• TO principal [, ...]: Les utilisateurs, les groupes ou les Service Principal auxquels la politique s'applique.
• EXCEPT principal [, ...]: Principaux exempts de la politique.
• GRANT EXECUTE FOR MODELS: Spécifie le privilège et le type sécurisable. En Beta, EXECUTE sur MODELS est la seule combinaison prise en charge.
• WHEN condition: Une expression booléenne basée sur des balises qui détermine les modèles auxquels la politique s'applique dans le périmètre. Utilise les fonctions intégrées has_tag('tag_name') et has_tag_value('tag_name', 'tag_value'). Si omis, la valeur par défaut est TRUE (s'applique à tous les modèles du périmètre). Consultez Conditions et fonctions intégrées pour les fonctions de condition disponibles.

Python SDK

Pour une documentation complète, veuillez consulter la documentation du SDK Databricks pour Python.

Cet exemple crée une politique GRANT qui octroie EXECUTE sur chaque modèle de fondation hébergé par Anthropic dans system.ai à data_scientists, à l'exception des contractants :

Python

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.catalog import (
    GrantOptions,
    PolicyInfo,
    PolicyType,
    SecurableType,
)

w = WorkspaceClient()

w.policies.create_policy(PolicyInfo(
    name="grant_anthropic_foundation_models",
    comment="Grant EXECUTE on Anthropic foundation models",
    on_securable_type=SecurableType.SCHEMA,
    on_securable_fullname="system.ai",
    for_securable_type=SecurableType.MODEL,
    policy_type=PolicyType.POLICY_TYPE_GRANT,
    to_principals=["data_scientists"],
    except_principals=["contractors"],
    grant=GrantOptions(privileges=["EXECUTE"]),
    when_condition="has_tag_value('ai.model_creator', 'anthropic')",
))

Modifier une politique GRANT

Catalog Explorer

1. Dans votre workspace Databricks, cliquez sur Catalogue .
2. Sélectionnez le catalogue ou le schéma auquel la politique est attachée.
3. Cliquez sur l'onglet tab .
4. Sélectionnez la politique que vous souhaitez modifier.
5. Mettez à jour les champs que vous souhaitez modifier.
6. Cliquez sur **Mettre à jour la politique**.

SQL

Pour modifier une politique GRANT avec SQL, exécutez CREATE OR REPLACE POLICY avec le même nom et la même cible. Consultez Créer une politique GRANT.

Python SDK

Contrairement à CREATE OR REPLACE POLICY dans SQL, update_policy prend en charge les mises à jour partielles. Utilisez le paramètre update_mask pour spécifier les champs à modifier. Seuls ces champs sont mis à jour. Si update_mask est "*" ou vide, tous les champs de policy_info sont appliqués.

Python

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.catalog import PolicyInfo

w = WorkspaceClient()

w.policies.update_policy(
    on_securable_type="SCHEMA",
    on_securable_fullname="system.ai",
    name="grant_anthropic_foundation_models",
    policy_info=PolicyInfo(
        except_principals=["contractors", "interns"],
    ),
    update_mask="except_principals",
)

Supprimer une politique GRANT

Catalog Explorer

1. Dans votre workspace Databricks, cliquez sur Catalogue .
2. Sélectionnez le catalogue ou le schéma auquel la politique est attachée.
3. Cliquez sur l'onglet tab .
4. Sélectionnez la politique.
5. Cliquez sur Supprimer la politique .

SQL

Pour supprimer une politique GRANT avec SQL, exécutez DROP POLICY:

SQL

DROP POLICY IF EXISTS grant_anthropic_foundation_models ON SCHEMA system.ai;

Python SDK

Python

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

w.policies.delete_policy(
    on_securable_type="SCHEMA",
    on_securable_fullname="system.ai",
    name="grant_anthropic_foundation_models",
)

Afficher les politiques

Utilisez SHOW POLICIES pour lister les politiques définies sur un objet sécurisable. Utilisez SHOW EFFECTIVE POLICIES pour inclure également les politiques héritées des étendues parentes, telles que les politiques de niveau catalogue qui affectent un schéma.

SQL

SHOW [EFFECTIVE] POLICIES ON { CATALOG | SCHEMA } securable_name

Le résultat inclut le nom de la stratégie, le type de stratégie et le catalogue ou le schéma où chaque stratégie est définie. Les stratégies GRANT sont renvoyées avec le type de stratégie GRANT ainsi que toutes les stratégies de filtre de lignes et de masque de colonnes attachées au même périmètre. La colonne table est renseignée uniquement pour les stratégies à l'échelle de la table (filtre de lignes et masque de colonnes) ; pour les stratégies GRANT attachées à un catalogue ou un schéma, elle est NULL.

Exemple :

SQL

SHOW EFFECTIVE POLICIES ON SCHEMA system.ai;

policy_name	policy_type	catalogue	Schéma	Table	Commentaire
grant_anthropic_foundation_models	Accorder	système	AI	NULL	Octroyer EXECUTE sur les modèles de fondation Anthropic.

policy_name	policy_type	catalogue	Schéma	Table	Commentaire
grant_anthropic_foundation_models	Accorder	système	AI	NULL	Octroyer EXECUTE sur les modèles de fondation Anthropic.

SHOW GRANTS n'inclut pas les privilèges accordés via une politique GRANT. Pour voir tout l'accès EXECUTE sur un modèle, combinez la sortie SHOW GRANTS pour le modèle avec les politiques GRANT renvoyées par SHOW EFFECTIVE POLICIES sur son schéma ou catalogue parent.

Décrire une politique

Utilisez DESCRIBE POLICY pour consulter les détails d'une politique GRANT spécifique. Nécessite MANAGE sur l'objet sécurisable cible ou la propriété de l'objet.

SQL

{ DESC | DESCRIBE } POLICY policy_name ON { CATALOG | SCHEMA } securable_name

Le résultat affiche les propriétés de la politique sous forme de paires clé-valeur, y compris le nom, le type d'objet sécurisable, le nom d'objet sécurisable, les principaux, les privilèges et la condition WHEN.

Exemple :

SQL

DESCRIBE POLICY grant_anthropic_foundation_models ON SCHEMA system.ai;

info_name	info_value
Nom	grant_anthropic_foundation_models
Sur le type sécurisable	Schéma
Sur Sécurisable	system.ai
À Principals	data scientists
Sauf Principals	prestataires
Pour le type sécurisable	Modèle
Type de politique	Accorder
Privilèges octroyés	EXÉCUTER
Condition	has_tag_value('ai.model_creator', 'anthropic')

info_name	info_value
Nom	grant_anthropic_foundation_models
Sur le type sécurisable	Schéma
Sur Sécurisable	system.ai
À Principals	data scientists
Sauf Principals	prestataires
Pour le type sécurisable	Modèle
Type de politique	Accorder
Privilèges octroyés	EXÉCUTER
Condition	has_tag_value('ai.model_creator', 'anthropic')

Balises système sur les modèles de fondation dans system.ai

Les modèles de fondation que Databricks héberge dans system.ai sont pré-balisés avec des tags système que les politiques GRANT peuvent référencer directement. Vous n'avez pas besoin de taguer vous-même ces modèles pour les utiliser dans une politique.

Tag	Exemples de valeurs
ai.model_creator	anthropic, openai, google, meta
ai.model_family	claude-opus, gpt, gemini, qwen

Tag	Exemples de valeurs
ai.model_creator	anthropic, openai, google, meta
ai.model_family	claude-opus, gpt, gemini, qwen

Pour les modèles que vous enregistrez dans vos propres catalogues et schémas, appliquez des tags gouvernés par le biais du workflow de tags standard de Unity Catalog. Voir Governed tags.

Quotas de politique

Ressource	Limite
Stratégies par métastore.	10 000
Stratégies par catalogue ou schéma	100

Ressource	Limite
Stratégies par métastore.	10 000
Stratégies par catalogue ou schéma	100

Ces quotas sont distincts des quotas pour les stratégies de filtre de ligne et de masque de colonne.

Journalisation d'audit

Les opérations de création, de modification et de suppression des politiques GRANT sont enregistrées sous les mêmes actions createPolicy, deletePolicy, getPolicy et listPolicies que les politiques de filtrage des lignes et de masquage des colonnes. Voir Journalisation d'audit pour des exemples de requêtes de log d'audit.

Bonnes pratiques

Les recommandations suivantes vous aident à concevoir des stratégies GRANT plus faciles à maintenir, à auditer et à comprendre.

• Utilisez des groupes dans TO et EXCEPT, et non des utilisateurs individuels. L'ajout ou la suppression d'utilisateurs d'un groupe nommé dans une politique modifie les personnes auxquelles la politique s'applique, sans modifier la politique.
• Joignez les politiques à la portée la plus restreinte qui couvre les cibles. Utilisez la portée la plus étroite qui contient les objets sécurisables auxquels la politique doit s’appliquer. Une portée plus large inclut des éléments sécurisables non pertinents dans la correspondance des tags de la politique, et peut accorder un accès non intentionnel.
• Utilisez l'héritage des tags pour des default sûres. Appliquez les valeurs de tag par default au catalogue ou au schéma parent afin que les descendants les héritent. Outrepassez le tag hérité uniquement sur les objets spécifiques qui nécessitent une valeur différente. Combinez cela avec EXCEPT pour gérer les exceptions contrôlées à une politique.
• Ne mélangez pas les stratégies GRANT et les octrois directs pour le même privilège. Pour un privilège donné sur une ressource sécurisable, choisissez soit les stratégies GRANT, soit les octrois directs, pas les deux. Les politiques GRANT s'unissent aux octrois directs, de sorte que les mélanger sur le même élément sécurisable rend plus difficile de comprendre qui a accès et d'auditer les modifications.
• Utilisez des GRANTs directs pour USE CATALOG et USE SCHEMA, les politiques de GRANT pour EXECUTE. Les politiques GRANT n’octroient pas les prérequis USE CATALOG et USE SCHEMA nécessaires pour accéder à un modèle. Accordez-les directement et utilisez une politique GRANT pour définir la portée de EXECUTE sur les modèles individuels par balise.

Limitations

• Seul le privilège EXECUTE sur les modèles est pris en charge. CREATE MODEL, CREATE MODEL VERSION et APPLY TAG ne sont pas pris en charge par les politiques GRANT et doivent être accordés directement.
• Les autorisations préalables USE SCHEMA et USE CATALOG, dont un utilisateur a besoin pour atteindre un modèle, ne sont pas prises en charge par les stratégies GRANT et doivent être accordées directement.
• Une stratégie peut être attachée au catalogue ou au schéma, pas au modèle.
• SHOW GRANTS ne retourne pas les privilèges accordés par une politique GRANT.
• INFORMATION_SCHEMA n'inclut pas les politiques GRANT.
• La suppression d'un modèle ou d'une version de modèle n'est pas couverte par les politiques GRANT. Consultez Gérer le cycle de vie des modèles dans Unity Catalog pour savoir comment supprimer les versions de modèle et les modèles.
• Vous ne pouvez pas utiliser Delta Sharing pour partager des modèles sur lesquels des politiques GRANT sont définies.

Plus d'informations

Voir aussi Gérer les privilèges dans Unity Catalog.