Désormais en GA : Développer des Databricks Apps respectant les autorisations grâce à l'autorisation au nom de l'utilisateur

Databricks Apps permet aux développeurs de créer et de déployer des applications de données et d'IA directement sur la plateforme Databricks, des tableaux de bord interactifs et outils opérationnels aux agents d'IA personnalisés.

Désormais disponible de manière générale, l'autorisation au nom de l'utilisateur (OBO) permet de créer des applications qui offrent des expériences personnalisées et respectueuses des autorisations, sans avoir à réimplémenter les règles de gouvernance des données dans le code de l'application. Lorsqu'une application appelle des API Databricks prises en charge avec OBO, elle agit en utilisant l'identité de l'utilisateur connecté : Unity Catalog applique les autorisations de données existantes de cet utilisateur, y compris les filtres de ligne et les masques de colonne, et les étendues d'API limitent les opérations que l'application peut effectuer au nom de l'utilisateur. Les applications peuvent continuer à utiliser leur principal de service dédié pour les opérations propres à l'application, comme la lecture d'une configuration partagée ou l'écriture de métriques d'application.

Par exemple, un assistant d'analyse des ventes peut répondre à des questions en utilisant uniquement les comptes et les champs auxquels un commercial est autorisé à accéder, sans donner à l'application de larges capacités SQL ou d'administration de l'espace de travail.

Commencer par l'identité qui régit chaque opération

Lors de la conception d'une application, posez-vous la question suivante : Quelles autorisations doivent régir cette opération particulière ?

Databricks Apps prend en charge deux modèles d'autorisation complémentaires : l'autorisation d'application et l'autorisation d'utilisateur. L'autorisation d'application utilise le principal de service dédié de l'application et convient aux opérations propres à l'application ou aux expériences qui doivent renvoyer le même résultat à chaque utilisateur. L'autorisation d'utilisateur utilise l'identité de l'utilisateur connecté lorsque les autorisations de cet utilisateur doivent régir une opération. La plupart des applications de production peuvent utiliser les deux modèles, en choisissant l'identité appropriée pour chaque chemin de requête. Consultez Configurer l'autorisation dans une application Databricks.

Prenons l'exemple d'une application qui répond à des questions telles que : Comment se comportent mes comptes ce trimestre, et comment s'explique ce changement ? L'application doit :

• Interroger les données de vente et de clientèle en tant qu'utilisateur demandeur.
• Respecter les autorisations Unity Catalog, y compris les filtres au niveau des lignes et les masques de colonnes.
• Renvoyer une analyse en lecture seule.
• Appeler éventuellement un service distinct pour résumer les résultats.
• Éviter de modifier les données ou de gérer les ressources SQL.

Cela convient parfaitement à l'autorisation d'utilisateur. L'application transmet le jeton d'accès transféré de l'utilisateur demandeur au connecteur SQL, et Databricks évalue la requête en utilisant l'entrepôt existant et les autorisations Unity Catalog de cet utilisateur. Un responsable régional peut ne voir que les comptes de sa région, tandis qu'un dirigeant national voit toutes les régions, sans que l'application ait à recréer ces règles dans le code. Lorsque les administrateurs mettent à jour les politiques Unity Catalog, les requêtes ultérieures de l'application reflètent ces modifications. 

L'autorisation de l'utilisateur détermine les données que la requête peut renvoyer. La décision de conception suivante concerne ce que l'application est autorisée à faire au nom de l'utilisateur avec le jeton d'utilisateur transféré.

Utiliser l'étendue d'API la plus restreinte correspondant à la tâche

L'assistant d'analyse des ventes doit exécuter des requêtes en lecture seule. Il n'a pas besoin d'un accès SQL étendu pour gérer les ressources ou effectuer d'autres opérations SQL. Pour cette raison, il doit demander sql:restricted-query plutôt que l'étendue plus large sql. 

sql:restricted-query permet à l'application d'exécuter des requêtes SQL en lecture seule. Elle ne permet pas à l'application d'effectuer d'autres opérations SQL. Cela permet de mieux faire correspondre le comportement du produit de l'application et sa limite d'autorisation : l'application peut lire les données gouvernées pour l'analyse, mais elle ne peut pas utiliser l'identité de l'utilisateur comme un identifiant d'exploitation SQL étendu.

Si l'application appelle également Genie ou Unity Gateway au nom d'un utilisateur, demandez uniquement les étendues correspondantes, telles que genie ou ai-gateway. Ne demandez pas files, model-serving ou vector-search à moins que l'application n'utilise réellement ces fonctionnalités. 

Les étendues constituent un plafond de capacités, et non un octroi d'accès aux données. L'application doit disposer de l'étendue d'API appropriée, et l'utilisateur doit toujours avoir l'autorisation d'accéder à la ressource cible. Consultez Sécurité basée sur les étendues et élévation de privilèges.

Configurer l'application avec une étendue d'API explicite

Configurez l'autorisation d'utilisateur dans l'interface utilisateur de Databricks ou dans un Declarative Automation Bundle. 

Pour un assistant d'analyse en lecture seule, l'application peut déclarer :

Remarque : L'étendue d'API fait partie de la configuration d'autorisation d'utilisateur déclarée de l'application. Elle n'accorde pas d'accès à un entrepôt SQL ou aux données Unity Catalog. L'utilisateur demandeur doit toujours être autorisé à utiliser l'entrepôt SQL cible et disposer des privilèges Unity Catalog requis sur les données interrogées. 

Lorsqu'un utilisateur accède pour la première fois à une application autorisée par l'utilisateur, Databricks l'invite à accepter les étendues d'API demandées. 

Transmettre l'identité de l'utilisateur au connecteur SQL

Databricks transmet le jeton d'accès de l'utilisateur actuel dans l'en-tête HTTP x-forwarded-access-token. L'application doit récupérer ce jeton pour la requête qui nécessite un accès au contexte utilisateur et le transmettre au connecteur SQL.

L'exemple suivant utilise Flask et le Databricks SQL Connector for Python pour rendre le flux de jetons explicite. Si vous créez l'application avec Databricks AppKit, appliquez le même principe d'autorisation : utilisez le client de contexte utilisateur ou l'identité au moment de la requête pour les opérations spécifiques à l'utilisateur, et conservez les opérations propres à l'application sur l'identité de l'application.

Note : Le jeton transféré est de courte durée et spécifique à chaque requête. L'application le lit à chaque requête et ne le stocke jamais d'une requête à l'autre ou dans une session. 

La différence importante par rapport à l'autorisation de l'application est que le connecteur reçoit le jeton d'utilisateur transféré via access_token. La portée d'API sql:restricted-query limite l'application aux fonctionnalités SQL en lecture seule dont elle a besoin, tandis que Unity Catalog détermine les lignes et les colonnes auxquelles cet utilisateur peut réellement accéder. Consultez Requête avec autorisation de l'utilisateur.

Permettre aux administrateurs de l'espace de travail de définir la limite supérieure

Les développeurs spécifient les portées d'API dont leur application a besoin. Les administrateurs de l'espace de travail peuvent contrôler quelles portées d'API les développeurs d'applications sont autorisés à ajouter aux applications de l'espace de travail.

Cette politique permet aux équipes de créer des expériences d'analyse et d'AI en lecture seule tout en empêchant les applications de demander des fonctionnalités plus larges ou sans rapport. Un développeur d'applications ne peut pas étendre l'autorisation de l'application au-delà de la limite de portée d'API configurée pour l'espace de travail.

Cela donne aux organisations deux niveaux de contrôle :

• L'application déclare les portées d'API minimales requises pour son fonctionnement.
• L'administrateur de l'espace de travail définit les portées d'API maximales disponibles pour les applications de cet espace de travail.

Les administrateurs de l'espace de travail configurent cette liste d'autorisation sous Paramètres > Développement > Applications. Le paramètre est défini par défaut sur toutes les API prises en charge, peut être restreint à des portées d'API sélectionnées, ou peut être défini sur Aucun pour désactiver l'autorisation de l'utilisateur. Consultez Restreindre les portées d'autorisation de l'utilisateur.

Les administrateurs de compte peuvent ajouter des portées même si ces portées ne sont pas incluses dans la liste d'autorisation de l'espace de travail. Si un administrateur supprime ultérieurement une portée autorisée, les applications déjà en cours d'exécution avec cette portée peuvent continuer à fonctionner, mais elles ne peuvent pas être démarrées, déployées ou mises à jour tant que la portée non autorisée n'est pas supprimée.

Séparer les opérations appartenant à l'application et celles appartenant à l'utilisateur

De nombreuses applications utiles ont besoin des deux modèles d'autorisation. L'assistant d'analyse des ventes pourrait utiliser :

• Un client avec portée d'application pour écrire des métriques d'application ou lire une configuration partagée.
• Un client avec portée d'utilisateur avec sql:restricted-query pour interroger les données de l'utilisateur actuel.
• Une portée d'API utilisateur distincte s'il doit appeler un autre service Databricks au nom de l'utilisateur.

Il est conseillé de rendre cette limite d'identité explicite dans le code de l'application au lieu de créer un seul client générique et de le réutiliser partout. Des dépendances, des noms et des tests distincts permettent d'éviter qu'un identifiant d'application ne soit utilisé pour un chemin spécifique à l'utilisateur ou qu'un jeton d'utilisateur ne soit conservé pour des tâches en arrière-plan.

Si une requête nécessite l'autorisation de l'utilisateur et que le jeton transféré est manquant, échouez de manière sécurisée plutôt que de basculer silencieusement vers le principal de service de l'application. Sinon, l'application pourrait renvoyer une réponse qui semble valide mais qui a été générée avec des autorisations différentes. C'est pourquoi query_as_user dans l'exemple ci-dessus commence par require_user_token au lieu de gérer l'en-tête manquant de manière intégrée.

Appliquer le même modèle aux agents

Les agents personnalisés déployés sur Databricks Apps peuvent utiliser le même modèle. Initialisez le client d'espace de travail avec portée d'utilisateur à l'intérieur du gestionnaire invoke ou stream au moment de la requête — et non au démarrage de l'application — car le jeton d'utilisateur transféré n'est disponible que lors d'une requête utilisateur active. Utilisez l'autorisation de l'application pour les ressources partagées et les opérations en arrière-plan. Consultez Authentification pour les agents.
 

Sécuriser l'implémentation

• Ne demandez que les portées d'API minimales requises.
• Séparez les clients appartenant à l'application et ceux autorisés par l'utilisateur dans le code, les tests et le câblage des dépendances.
• N'affichez, ne journalisez ou ne conservez jamais les jetons d'accès transférés.
• Limitez la gestion des applications aux développeurs de confiance et exigez une révision par les pairs pour les modifications liées aux autorisations.
• Utilisez l'autorisation de l'application pour les opérations partagées et en arrière-plan plutôt que de conserver les jetons d'utilisateur.
• Testez avec des utilisateurs dont les accès Unity Catalog diffèrent, puis répétez ces tests après toute modification de politique.

Pour commencer

L'autorisation au nom de l'utilisateur vous offre personnalisation et gouvernance à partir du même mécanisme. Les autorisations Unity Catalog de l'utilisateur décident des données auxquelles une application peut accéder, et la portée d'API correspondante la plus restreinte décide de ce qu'elle peut faire en son nom. Pour commencer, consultez notre documentation d'aide pour obtenir plus de ressources et de bonnes pratiques.

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