Revenir au contenu principal
Plateforme

Introduction au contrôle d'accès basé sur les attributs (ABAC) inter-moteurs

Définissez les politiques ABAC dans Unity Catalog et assurez-vous qu'elles sont respectées par n'importe quel moteur

par Alex Jiang, Alex Reid et Michelle Leon

  • Unity Catalog applique les contrôles d'accès basés sur les attributs (ABAC) sur les moteurs externes. Définissez des filtres de lignes basés sur des balises et des masques de colonnes une seule fois, et appliquez-les à partir de n'importe quel moteur.
  • La gouvernance centralisée au niveau du catalogue signifie que les politiques sont appliquées avant même que les données n'atteignent le moteur — aucune logique de politique n'est requise dans le moteur lui-même.
  • L'ABAC inter-moteurs est basé sur les API REST du catalogue Iceberg, une spécification ouverte que tout moteur peut adopter pour déléguer l'application des politiques au catalogue.

En décembre, nous avons partagé notre vision pour compléter le lakehouse : stockage ouvert, accès ouvert et gouvernance unifiée. Nous avons décrit un monde où les organisations pourraient définir des politiques d'accès granulaires une seule fois dans Unity Catalog et les faire appliquer sur tous les moteurs, sur toutes les tables, pour tous les utilisateurs. Aujourd'hui, nous étendons cette vision.

Nous annonçons la version Bêta du contrôle d'accès basé sur les attributs (ABAC) inter-moteurs, qui permet aux entreprises d'appliquer des contrôles d'accès basés sur les attributs (ABAC) sur les moteurs externes à l'aide des API REST du catalogue Iceberg. Avec l'ABAC inter-moteurs, Unity Catalog devient le premier et le seul catalogue à appliquer l'ABAC inter-moteurs, permettant aux filtres de lignes basés sur des balises et aux masques de colonnes d'être appliqués par tous les moteurs.

Pourquoi c'est important

Le lakehouse ouvert que Databricks a initié a rendu l'interopérabilité possible. Les formats de table ouverts comme Delta Lake et Apache Spark ont libéré les organisations du verrouillage ; n'importe quel moteur pouvait lire la même copie des données sans dupliquer ou convertir les données dans un format différent. Cependant, la gouvernance n'a pas suivi. Les politiques au niveau des lignes et des colonnes sont restées cloisonnées à l'intérieur des runtimes de moteurs individuels.

Cela a créé un compromis douloureux pour les équipes de sécurité : dupliquer manuellement les politiques sur tous les moteurs et espérer qu'elles restent synchronisées, maintenir des copies de tables séparées pour différents consommateurs, ou accorder un accès plus large que prévu et accepter le risque.

L'ABAC inter-moteurs élimine ce compromis.

Ce que l'ABAC inter-moteurs apporte

Avec cette version Bêta, Unity Catalog applique des politiques de contrôle d'accès granulaires sur les données lues par les moteurs externes. Cela inclut :

  • Filtres de lignes et masques de colonnes — toute l'expressivité des politiques Unity Catalog, y compris les règles basées sur des balises, la logique conditionnelle et les UDF SQL
  • Support multi-moteurs — puisque l'application des politiques s'exécute via les API REST du catalogue Iceberg, tout client REST Iceberg est pris en charge. L'ABAC inter-moteurs est ouvert par conception et n'est pas lié à un connecteur spécifique. Aujourd'hui, vous pouvez utiliser Apache Spark via les connecteurs Iceberg-Spark et Delta-Spark. D'autres intégrations de moteurs comme Starburst et DuckDB seront bientôt disponibles.

Définissez les politiques ABAC une seule fois dans Unity Catalog et assurez-vous qu'elles sont appliquées partout — sur Databricks ou tout moteur qui s'intègre au catalogue REST Iceberg.

Comment ça marche

L'ABAC inter-moteurs est basé sur les API REST du catalogue Iceberg, une spécification ouverte que tout moteur peut adopter pour déléguer l'application des politiques au catalogue. Avec l'ABAC inter-moteurs, le catalogue gère l'application des politiques, et le moteur gère la requête. Les organisations obtiennent une sécurité granulaire sans sacrifier la flexibilité quant à l'endroit où leurs requêtes s'exécutent.

Lorsqu'un utilisateur interroge une table avec des politiques de contrôle d'accès granulaires à partir d'un moteur externe :

  1. Le moteur envoie une requête de scan à Unity Catalog via l'API REST du catalogue Iceberg
  2. Unity Catalog évalue les droits de l'utilisateur et toutes les politiques applicables
  3. Unity Catalog renvoie un plan de scan filtré limité aux données auxquelles l'utilisateur est autorisé à accéder
  4. Le moteur complète la requête par rapport aux fichiers filtrés dans le plan de scan

L'application se fait au niveau du catalogue, avant que les données n'atteignent le moteur. Le moteur n'a pas besoin de comprendre ou d'implémenter de logique de politique ; il traite uniquement les données qu'il reçoit. Cela signifie que l'ABAC inter-moteurs peut fonctionner pour n'importe quel moteur, même s'il n'a pas de runtime de gouvernance natif.

Perspectives

L'ABAC inter-moteurs offre aujourd'hui une gouvernance unifiée grâce à une application centralisée : le catalogue évalue les politiques et ne renvoie que les données auxquelles l'utilisateur est autorisé à accéder. C'est la meilleure approche pour les moteurs « non fiables » qui n'ont pas de runtime de gouvernance natif, et cela fonctionne immédiatement avec tout moteur qui adopte les API REST du catalogue Iceberg.

L'application centralisée n'est qu'une partie du tableau. L'industrie a également besoin d'une approche évolutive pour l'échange de métadonnées et de politiques — une approche où les catalogues peuvent partager des métadonnées de gouvernance afin que les politiques puissent être appliquées nativement dans les moteurs externes.

Nous contribuons à cette conversation au sein de la communauté Apache Iceberg avec une proposition pour que les catalogues échangent des étiquettes, qui portent un contexte de gouvernance et sémantique. Avec des étiquettes partagées, les moteurs à travers le lakehouse peuvent agir sur le même contexte de gouvernance et métier, où que les données soient lues.

L'application centralisée et l'échange de métadonnées sont complémentaires. Unity Catalog prendra en charge les deux à mesure que l'écosystème des données évolue.

Pour commencer

L'ABAC inter-moteurs est maintenant disponible en version Bêta. Pour l'essayer :

  1. Activez l'aperçu : Inscrivez-vous à "Cross-engine ABAC" dans le portail d'aperçu Databricks (voir Gérer les aperçus Databricks)
  2. Définissez vos politiques ABAC : Créez des filtres de lignes basés sur des balises et des masques de colonnes sur vos tables Unity Catalog (voir la documentation ABAC)
  3. Interrogez à partir d'un moteur externe : Connectez Apache Spark via les connecteurs Iceberg-Spark ou Delta-Spark et confirmez que les politiques sont appliquées à la lecture

Les instructions complètes de configuration et les détails sont disponibles dans la documentation sur l'ABAC inter-moteurs.

Nouveau sur Unity Catalog ? Suivez les guides de démarrage pour AWS, Azure, ou GCP.

Rejoignez-nous au Data and AI Summit 2026

Le Data and AI Summit 2026 est presque là ! Rejoignez-nous du 15 au 18 juin 2026 au Moscone Center à San Francisco, Californie, pour découvrir comment les organisations leaders utilisent Unity Catalog pour gouverner les données et l'IA sur tous les moteurs. Inscrivez-vous dès aujourd'hui pour avoir un premier aperçu de ce qui s'en vient pour la gouvernance ouverte et unifiée.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original

Recevez les derniers articles dans votre boîte mail

Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.