Aller au contenu principal
Dernière mise à jour le

Politiques DENY ABAC (bêta)

info

Bêta

Les politiques DENY ABAC sont en version bêta. Les politiques DENY sont attachées au niveau du catalogue ou du schéma et refusent le privilège MANAGE ACCESS CONTROL sur les types sécurisables pris en charge. Voir Types sécurisables et privilèges pris en charge.

Les politiques ABAC DENY refusent explicitement les privilèges Unity Catalog aux principaux sur des objets sécurisables dont les balises régies correspondent à une condition, prenant toujours le pas sur tout octroi. Cette page explique comment créer, modifier, répertorier et supprimer des politiques ABAC DENY, ce que signifie refuser MANAGE ACCESS CONTROL, ainsi que la portée et les limitations actuelles.

Vous pouvez créer et gérer des politiques DENY ABAC à l’aide de Catalog Explorer, de SQL, de l’ API REST, de Terraform ou des SDK Databricks.

Pour une vue d’ensemble de l’ABAC et des concepts fondamentaux, y compris les tags gouvernés et les fonctions intégrées telles que has_tag et has_tag_value, consultez Concepts fondamentaux du contrôle d’accès basé sur les attributs (ABAC).

Configuration requise pour le compute​

L’utilisation de SQL pour créer, modifier ou supprimer des politiques DENY nécessite une ressource de compute classique exécutant Databricks Runtime 18 LTS ou une 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 étaient auparavant livrées dans une version numérotée ultérieure sont désormais proposées sous forme de mises à jour datées de Databricks Runtime 18. Pour plus de détails, consultez À propos des notes de version unifiées.

Qu’est-ce qu’une politique DENY​

Une politique DENY est une politique de contrôle d’accès basée sur les attributs qui refuse explicitement un privilège Unity Catalog à des principaux spécifiés sur les objets sécurisables dont les tags gouvernés correspondent à la condition de la politique. Unity Catalog évalue la condition WHEN de la politique par rapport aux tags gouvernés sur chaque objet sécurisable dans la portée de la politique à chaque vérification d’accès, et refuse le privilège sur chaque objet sécurisable correspondant.

Une politique DENY prévaut sur tout octroi du même privilège et ne peut être annulée par un octroi individuel.

Une politique DENY est régie par les règles suivantes :

  • DENY a toujours la priorité. Une politique DENY remplace tout octroi du même privilège, y compris les octrois détenus par héritage, appartenance à un groupe ou implicitement par propriété d'objet. Aucun octroi individuel ne peut remplacer une politique DENY active.
  • Les administrateurs du métastore sont toujours implicitement exemptés. Un administrateur du métastore n'est jamais affecté par une politique DENY pour MANAGE ACCESS CONTROL, ce qui garantit qu'il existe toujours un moyen de modifier ou de supprimer toute politique DENY.
  • La commande DENY est héritée vers le bas. Le refus lui-même est hérité dans la hiérarchie des objets de la même manière que les octrois suivent l’ héritage des privilèges. Une politique DENY sur un catalogue refuse le privilège sur chaque objet actuel et futur au sein de ce catalogue, et une politique DENY sur un schéma le refuse sur chaque objet actuel et futur au sein de ce schéma.
  • Les politiques DENY qui se chevauchent sont combinées et le résultat le plus restrictif s’applique. Lorsque plusieurs politiques DENY s’appliquent au même principal, leurs effets sont réunis. Une politique DENY ne peut pas exempter un principal visé par une autre politique DENY. Si une politique applicable refuse le privilège, celui-ci est refusé.
  • Les politiques DENY sont indépendantes des octrois. Contrairement à un REVOKE, qui supprime uniquement un privilège explicitement accordé, une politique DENY ne dépend pas d'un octroi existant. Vous pouvez refuser un privilège qui n'a jamais été accordé, et la suppression d'un octroi ne supprime pas une politique DENY. Une politique DENY reste en vigueur jusqu'à ce qu'elle soit explicitement supprimée.

Les politiques DENY 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.

Les politiques DENY diffèrent des politiques de filtrage de lignes et de masquage de colonnes de deux manières :

  • Les politiques de filtre de ligne et de masque de colonne restreignent le contenu des données auxquelles un utilisateur a déjà accès. Les politiques DENY déterminent si un principal peut effectuer une action, telle que la gestion du contrôle d’accès, quelle qu’elle soit.
  • Les politiques de filtrage de lignes et de masques de colonnes nécessitent une fonction définie par l’utilisateur (UDF) pour implémenter le filtre ou le masque. Les politiques DENY n’utilisent pas d’UDF. La condition est exprimée en ligne dans la définition de la politique.

Que signifie refuser GÉRER LE CONTRÔLE D'ACCÈS ?​

MANAGE ACCESS CONTROL est un enfant du privilège MANAGE qui régit la gestion des accès, comme l'octroi et la révocation de privilèges, le transfert de propriété et la gestion des politiques ABAC. Il peut être refusé, mais pas accordé. Pour plus de détails, consultez GÉRER LE CONTRÔLE D'ACCÈS.

Les politiques DENY peuvent être utilisées pour refuser le privilège MANAGE ACCESS CONTROL afin d'empêcher des principaux spécifiés, y compris les propriétaires d'objets, d'effectuer des opérations de gestion des accès sur les objets dans le périmètre d'une politique. Cela supprime les capacités de gestion des accès régies par ce privilège, indépendamment de la manière dont un principal les détient, que ce soit par le biais du privilège MANAGE ou implicitement par la propriété de l'objet.

Sur les objets affectés, un principal refusé perd la capacité de :

Refuser MANAGE ACCESS CONTROL ne supprime pas la capacité d’un principal à visualiser les métadonnées d’un objet. Un principal disposant de MANAGE ou un propriétaire d’objet peut toujours voir que l’objet existe, et peut toujours exercer toutes les autres capacités que MANAGE, ses autres privilèges ou la propriété fournissent. Ils perdent uniquement les capacités de gestion des accès listées ci-dessus.

Le refus de MANAGE ACCESS CONTROL ne ferme pas tous les chemins par lesquels un principal peut partager des données. Voir Considérations relatives au Data Sharing.

Exemples de politique DENY​

La politique suivante refuse MANAGE ACCESS CONTROL sur chaque table taguée sensitive dans catalog_a à tous les utilisateurs du compte, à l’exception du groupe data_admins. Les principaux affectés, y compris les propriétaires de tables, perdent la capacité d’accorder ou de révoquer des privilèges, de modifier la propriété ou de gérer les filtres de lignes et les masques de colonnes sur ces tables :

SQL
CREATE POLICY deny_manage_access_control_sensitive_tables
ON CATALOG catalog_a
COMMENT 'Prevent non-admins from managing permissions on sensitive tables'
TO `account users`
EXCEPT `data_admins`
DENY MANAGE ACCESS CONTROL
FOR TABLES
WHEN has_tag('sensitive');

La politique suivante refuse MANAGE ACCESS CONTROL sur tous les schémas dans catalog_a à un groupe désigné, à l'exception de data_admins. Comme la commande DENY est héritée vers le bas, les principaux concernés perdent également la capacité de gérer l'accès aux objets au sein de ces schémas :

SQL
CREATE POLICY deny_designated_users_catalog_access
ON CATALOG catalog_a
COMMENT 'Prevent designated users from managing access on catalog objects'
TO `designated_users`
EXCEPT `data_admins`
DENY MANAGE ACCESS CONTROL
FOR SCHEMAS;

Types sécurisables et privilèges pris en charge​

Les politiques DENY prennent en charge un privilège, MANAGE_ACCESS_CONTROL, sur les types sécurisables suivants. Une politique s’applique à un seul type sécurisable. Unity Catalog valide le privilège par rapport au type sécurisable lorsque vous créez la politique.

Type sécurisable

MANAGE_ACCESS_CONTROL

Catalogue

✓

Schéma

✓

Table

✓

Volume

✓

Fonction

✓

Modèle

✓

Secret

✓

Type sécurisable

MANAGE_ACCESS_CONTROL

Catalogue

✓

Schéma

✓

Table

✓

Volume

✓

Fonction

✓

Modèle

✓

Secret

✓

Voici la liste des types sécurisables pris en charge dans la clause FOR. Lorsqu’une stratégie est associée à un catalogue ou à un schéma, le DENY est hérité par tous les objets au sein de ce catalogue ou de ce schéma, même les objets dont le type n’est pas pris en charge par la clause FOR.

En SQL, utilisez le type sécurisable au pluriel après FOR, tel que DENY MANAGE ACCESS CONTROL FOR TABLES ou FOR SCHEMAS. Les formes singulières ne sont pas acceptées. Dans l’API REST, définissez for_securable_type sur la forme singulière, par exemple TABLE.

Créer une politique DENY​

Vous pouvez créer une politique DENY via l'interface utilisateur de Catalog Explorer, avec l'instruction SQL CREATE POLICY ou avec l'API REST.

Pour créer une politique DENY, vous devez disposer de MANAGE sur le catalogue ou le schéma auquel la politique est rattachée, ou être propriétaire de cet objet sécurisable.

Les politiques DENY doivent être créées à partir d'un catalogue ou d'un schéma. Le type de politique Deny access n’est pas disponible lorsque vous start à partir d’un objet individuel tel qu’une table.

  1. Dans votre workspace Databricks, cliquez sur Icône de données. Catalog .

  2. Sélectionnez le catalogue ou le schéma auquel vous souhaitez appliquer la politique. Les politiques DENY ne peuvent être appliqué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 politique et une Description facultative.

  6. Sous Principaux et périmètre :

    • Dans Appliqué à , sélectionnez les principaux (utilisateurs, groupes ou Service Principal) auxquels la politique s’applique.
    • Dans Except for , sélectionnez éventuellement des principals à exclure de la politique.
    • Dans Étendue , confirmez le catalogue ou le schéma où la politique est appliquée.

  7. Sous Type de politique , sélectionnez Refuser l’accès .

  8. Sous Securable objects , sélectionnez le type sécurisable auquel la politique s'applique. Voir les types et privilèges pris en charge.

  9. Sous Condition , choisissez comment définir la portée de la politique aux objets sécurisables du type sélectionné dans le catalogue ou le schéma :

    • No condition applique la politique à tous les éléments sécurisables de ce type sous le catalogue ou le schéma sélectionné.
    • Les éléments sécurisables correspondant à l’un de ces tags appliquent la politique uniquement aux éléments sécurisables qui portent au moins l’un des tags régis sélectionnés.
    • Objets sécurisables correspondant à une expression personnalisée vous permet d’écrire une expression basée sur des tags pour déterminer les objets sécurisables auxquels la politique s’applique. Consultez Conditions et fonctions intégrées pour connaître les fonctions de condition disponibles.

  10. Sous Privileges , sélectionnez GÉRER LE CONTRÔLE D'ACCÈS . Il s’agit du seul privilège pris en charge par les politiques DENY.

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

Modifier une politique DENY​

Gérez les politiques DENY depuis l'onglet tab du catalogue ou du schéma parent auquel elles sont rattachées.

  1. Dans votre workspace Databricks, cliquez sur Icône de données. Catalog .
  2. Sélectionnez le catalogue ou le schéma auquel la politique est rattaché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 .

Supprimer une politique DENY​

Gérez les politiques DENY depuis l'onglet tab du catalogue ou du schéma parent auquel elles sont rattachées.

  1. Dans votre workspace Databricks, cliquez sur Icône de données. Catalog .
  2. Sélectionnez le catalogue ou le schéma auquel la politique est rattachée.
  3. Cliquez sur l’onglet tab .
  4. Sélectionnez la politique.
  5. Cliquez sur Supprimer la politique .

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 portées parentes, telles que les politiques au niveau du catalogue qui affectent un schéma.

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

Le résultat inclut le nom de la politique, le type de politique, le catalogue et le schéma de l’élément sécurisable sur lequel chaque politique est définie, ainsi que le type et le nom complet de cet élément sécurisable. Les politiques DENY sont renvoyées avec le type de politique DENY ainsi que toute politique de filtrage de lignes, de masquage de colonnes et GRANT attachée à la même portée. La colonne Table n’est remplie que lorsqu’une politique est définie sur une table. Ceci s’applique aux politiques de filtrage de lignes et de masquage de colonnes. Pour les politiques GRANT et DENY, la colonne Table est NULL.

Exemple :

SQL
SHOW EFFECTIVE POLICIES ON CATALOG catalog_a;
Text
Policy Name                                  Policy Type  Catalog    Schema  Table  Comment                                                           on_securable_type  on_securable_fullname
-------------------------------------------  -----------  ---------  ------  -----  ----------------------------------------------------------------  -----------------  ---------------------
deny_manage_access_control_sensitive_tables  DENY         catalog_a  NULL    NULL   Prevent non-admins from managing permissions on sensitive tables  CATALOG            catalog_a

SHOW GRANTS ne reflète pas les politiques DENY. Consultez les limitations.

Décrire une politique​

Utilisez DESCRIBE POLICY pour afficher les détails d’une politique DENY spécifique. Nécessite READ METADATA ou 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, notamment le nom, le type d’objet sécurisable, le nom de l’objet sécurisable, les principaux, les privilèges refusés et la condition WHEN.

Définitions de politique de query avec Information Schema​

Vous pouvez interroger les définitions de politique DENY dans le catalogue actuel en utilisant INFORMATION_SCHEMA.ABAC_POLICY_DEFINITIONS:

SQL
SELECT *
FROM information_schema.abac_policy_definitions
WHERE policy_type = 'DENY';

Pour les colonnes disponibles et des exemples supplémentaires, voir ABAC_POLICY_DEFINITIONS.

Quotas de politique​

Ressource

Limite

Politiques par métastore

10 000

Politiques par catalogue ou schéma

100

Ressource

Limite

Politiques par métastore

10 000

Politiques par catalogue ou schéma

100

Ces quotas sont distincts des quotas pour les politiques de filtrage des lignes et de masquage des colonnes et des quotas pour les politiques GRANT.

Journalisation d’audit​

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

Bonnes pratiques​

  • 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 avoir à modifier la politique elle-même.
  • Exemptez toujours un groupe de confiance de la politique, afin de ne pas bloquer accidentellement tout le monde. Ceci est particulièrement important lorsqu’une politique s’applique au groupe account users. Utilisez la clause EXCEPT pour nommer un groupe qui conserve le privilège, afin qu’au moins un ensemble de principals puisse toujours gérer l’accès aux objets concernés.
  • Attachez les politiques à la portée la plus restreinte couvrant les cibles. Une portée plus large inclut des éléments sécurisables non liés dans la correspondance de tags de la politique, et pourrait refuser l’accès là où vous ne l’aviez pas prévu.

Considérations relatives au Data Sharing​

Le refus de MANAGE ACCESS CONTROL bloque uniquement les fonctionnalités contrôlées par la propriété et le privilège MANAGE. Cela ne ferme pas tous les chemins par lesquels un principal peut partager des données. Une politique DENY n’empêche pas les éléments suivants :

  • Copie de données avec CTAS. Un principal disposant de SELECT sur une table et de CREATE TABLE sur un schéma (ainsi que USE CATALOG et USE SCHEMA) peut copier les données dans une nouvelle table avec CREATE TABLE ... AS SELECT. Pour restreindre cela, évitez d'accorder CREATE TABLE.
  • Exposer des données via une vue. Un principal disposant de SELECT sur une table et de CREATE TABLE sur un schéma (ainsi que USE CATALOG et USE SCHEMA) peut créer une vue sur la table. Parce qu’une vue s’exécute avec les privilèges de son propriétaire, les principaux auxquels SELECT a été accordé sur la vue peuvent lire les données sous-jacentes sans accès direct à la table source. Pour restreindre cela, évitez d’accorder CREATE TABLE, qui autorise également la création de vues.
  • Application ou suppression de tags gouvernés. Un principal disposant de APPLY TAG sur un objet et du privilège ASSIGN sur un tag gouverné peut toujours modifier ce tag sur l'objet, ce qui peut affecter les politiques basées sur les tags. Pour restreindre cela, limitez les personnes détenant ASSIGN sur le tag gouverné et APPLY TAG sur l’objet. Consultez Gérer les autorisations sur les tags gouvernés.
  • OpenSharing. Un propriétaire de partage disposant du privilège requis sur un objet peut l’ajouter à un partage. Pour restreindre cela, évitez d’accorder CREATE SHARE sur le métastore.
  • Credential vending. Un principal peut partager l’accès à des objets via le credential vending. Pour restreindre cela, évitez d’activer l’accès aux données externes sur le métastore et n’accordez pas EXTERNAL USE SCHEMA.
  • Gestion de groupe. Un principal disposant de l'autorisation Gérer sur un groupe Databricks (y compris les administrateurs de compte et de workspace, qui l'ont automatiquement) peut modifier l'appartenance au groupe, ce qui peut changer les personnes héritant de l'accès via ce groupe. Pour restreindre cela, limitez les personnes disposant de l'autorisation Gérer sur les groupes.

Limitations​

  • Seul le privilège MANAGE ACCESS CONTROL peut être refusé. Les autres privilèges, tels que SELECT et MODIFY, ne sont pas pris en charge par les politiques DENY.
  • Le privilège MANAGE ACCESS CONTROL peut être refusé, mais pas accordé.
  • Une politique peut être attachée à un catalogue ou à un schéma, mais pas à un objet sécurisable individuel.
  • Une politique s’applique à un seul type d’objet sécurisable. Pour refuser le privilège sur plusieurs types d’objets sécurisables dans la même portée, créez une politique distincte pour chaque type, ou créez une politique FOR SCHEMAS afin que MANAGE ACCESS CONTROL soit refusé sur tous les types d’objets au sein du schéma.
  • SHOW GRANTS, GetPermissions et GetEffectivePermissions ne reflètent pas les politiques DENY. Pour voir les politiques DENY en vigueur, utilisez SHOW EFFECTIVE POLICIES sur le catalogue ou le schéma de l’objet.

Plus d’informations​

Sur cette page