Appliquez un garde-fous partenaire avec une politique de service externe
Bêta
Cette fonctionnalité est en version bêta. Les administrateurs de compte peuvent contrôler l'accès à cette fonctionnalité à partir de la page Previews de la console de compte. Consultez Gérer les aperçus Databricks.
Une stratégie de service externe applique les décisions d'un fournisseur de garde-fous que vous utilisez déjà, tel qu'un service de sécurité IA ou de prévention des pertes de données, au trafic transitant par Unity Gateway. À chaque appel gouverné, Databricks envoie le contenu évalué à l'endpoint de votre fournisseur. Le fournisseur renvoie allow ou deny, et Databricks applique cette décision, sans modification de vos applications.
Vous attachez une politique de service externe à un Model Service , un Model Provider Service ou un MCP Service de la même manière que vous attachez n’importe quelle politique de service.
Fonctionnement des politiques de service externe
Une politique de service externe se compose de trois parties :
- Une connexion HTTP Unity Catalog stocke l'URL de l'endpoint de votre fournisseur et ses identifiants OAuth. Plusieurs stratégies peuvent partager une même connexion.
- La politique de service externe est attachée à un service. Il nomme la connexion et définit la phase, le rang, le mode et une configuration de politique facultative. Databricks l’exécute à chaque requête et applique le résultat.
- Le guardrail de votre fournisseur inspecte le contenu et renvoie un verdict :
ALLOWouDENY, accompagné d'un motif facultatif.
Votre fournisseur doit implémenter l'API de politique externe Databricks, qui définit la requête envoyée par Databricks et le verdict attendu en retour. Demandez à votre fournisseur s'il le prend en charge ainsi que les détails de l'endpoint. Databricks ne crée ni ne maintient d'intégrations pour les fournisseurs individuels.
Avant de commencer
Vous avez besoin des éléments suivants :
- Un endpoint de votre fournisseur de garde-fous qui implémente l’API de politique externe Databricks.
- OAuth machine-to-machine (M2M) credentials for that endpoint: a client ID, a client secret, and the vendor's token endpoint URL. OAuth M2M est la seule méthode d’authentification prise en charge. API keys, basic authentication, and user-to-machine OAuth aren't supported.
- Permissions pour créer la connexion : le privilège
CREATE CONNECTION, ainsi queUSE CATALOGetUSE SCHEMAsur le catalogue et le schéma où la connexion est stockée. - Autorisations permettant de joindre la règle :
MANAGEsur le service que vous souhaitez régir,USE CONNECTIONsur la connexion, ainsi queUSE CATALOGetUSE SCHEMAsur le catalogue et le schéma de la connexion.
Les deux jeux d’autorisations peuvent appartenir à des personnes différentes. Si la personne qui associe la politique ne dispose pas de CREATE CONNECTION, la personne qui gère les identifiants du fournisseur peut créer la connexion à l’avance et lui accorder USE CONNECTION.
Étape 1 : Créez une connexion avec votre fournisseur
La connexion est un objet Unity Catalog qui stocke l'endpoint et les identifiants de votre fournisseur. Vous pouvez le créer de deux manières :
- Pendant l'association de la règle : dans le formulaire de la règle, sélectionnez Créer une nouvelle connexion . Il s'agit de l'option la plus rapide pour un seul garde-fou.
- En amont : créez une connexion HTTP avec l’authentification machine-to-machine OAuth dans Catalog Explorer ou avec
CREATE CONNECTION, puis sélectionnez Utiliser une connexion existante dans le formulaire de stratégie. Utilisez cette option lorsque plusieurs stratégies partagent un endpoint, ou lorsqu’une équipe différente gère les identifiants du fournisseur. Voir Créer une connexion au service externe.
Lorsque vous créez la connexion à partir du formulaire de politique, saisissez les informations suivantes :
Champ | Description |
|---|---|
Nom de la connexion | Nom de la connexion Unity Catalog, par exemple |
Catalog et Schema | Emplacement où la connexion est stockée dans Unity Catalog. |
Hôte | L’hôte de votre fournisseur, incluant le schéma, par exemple |
Chemin d’accès de l’API (facultatif) | Un chemin d'accès sur cet hôte, par exemple |
Type d'authentification | Toujours OAuth M2M . Ce champ ne peut pas être modifié. |
Client ID et Secret du client | Les identifiants de compte de service émis par votre fournisseur. |
Endpoint de jeton | URL du jeton OAuth de votre fournisseur, par exemple |
Champ d’application d’OAuth (facultatif) | Portées séparées par un espace, si votre fournisseur les exige, par exemple |
Les fournisseurs desservent généralement de nombreuses politiques à partir d’un endpoint et les distinguent grâce à la configuration de politique que vous définissez à l’étape 2. Vous créez généralement une connexion par endpoint de fournisseur, et non une par politique.
Étape 2 : attacher la politique de service externe
-
Dans la barre latérale du workspace, cliquez sur AI Gateway .
-
Sélectionnez le service à régir : un service de modèle sur le tab Models , un service de fournisseur de modèle sur le tab Providers , ou un service MCP sur le tab MCPs .
-
Ouvrez le tab Policies , puis cliquez sur New policy .
-
Saisissez un Nom pour la politique.
-
Sous Type de garde-fou , sélectionnez External .
-
Définissez le rang pour contrôler l'ordre d'évaluation par rapport aux autres politiques du service. The lowest rank runs first on the request and last on the response, and a
DENYstops all later ranks. Au même rang, seule uneDENYprovenant d'une politique de juge LLM bloquante ignore l'appel à votre fournisseur. UnDENYprovenant d'une politique SQL personnalisée ou d'une autre politique séquentielle au même rang ne le fait pas, de sorte que votre fournisseur reçoit toujours le contenu. Pour ignorer l’appel au fournisseur lorsque cette politique refuse, placez-la à un rang évalué avant le rang de la politique de service externe. Consultez l' ordre d’évaluation. -
Sous Phase , sélectionnez Garde-fous d’entrée (avant que le service ne soit appelé), Garde-fous de sortie (après sa réponse) ou les deux. Choisissez l’entrée uniquement si votre fournisseur n’inspecte que les requêtes. Chaque phase correspond à un appel distinct auprès de votre fournisseur, de sorte que la sélection des deux phases double approximativement le nombre d’appels.
-
Sélectionnez la connexion. Choisissez Utiliser une connexion existante et sélectionnez-la dans la liste, ou choisissez Créer une nouvelle connexion et remplissez les champs de l'étape 1.
-
(Facultatif) Dans Policy configuration , saisissez un objet JSON, par exemple
{"profile": "strict"}. Databricks ne lit pas cette valeur. Il transmet le texte à votre fournisseur à chaque requête, exactement comme vous l'avez saisi. La documentation de votre fournisseur répertorie les clés qu'il accepte. Laissez ce champ vide si votre fournisseur n'en a pas besoin. -
Développez Options avancées et sélectionnez un Mode :
- Appliquer applique la décision du fournisseur. Un objet
DENYbloque l'appel. - Log évalue la politique et enregistre le verdict potentiel sans rien bloquer. Examinez les résultats dans la table unifiée des traces, où chaque évaluation est un événement
policy_evaluatedavec le verdict potentiel danspolicy.dry_run_actionetpolicy.dry_run_reason. Voir Événements d'évaluation de politique. Si le service dispose d'une table d'inférence, les résultats y sont également enregistrés.
- Appliquer applique la décision du fournisseur. Un objet
-
Cliquez sur Créer une politique .
Databricks recommande de commencer en mode Log . Laissez le trafic réel traverser la politique, examinez ce qu'elle aurait bloqué, puis passez à Appliquer .
Le mode Logs ne bloque pas les appels, mais chaque évaluation appelle toujours votre fournisseur et utilise le quota ou les frais par appel inclus dans votre contrat avec le fournisseur. Configurez la table de suivi unifiée, ou une table d'inférence sur le service, avant de start, afin de pouvoir consulter les évaluations que vous payez.
Step 3: Test the policy
Après avoir joint ou modifié une politique, veuillez patienter pour laisser le temps à la modification de se propager avant de tester. La propagation prend généralement entre 60 et 90 secondes.
Envoyez ensuite une requête que le garde-fou de votre fournisseur devrait intercepter. En mode Enforce , Databricks bloque l'appel et renvoie une réponse positive (HTTP 200) avec un objet databricks_service_policy, comme pour toute politique de service de blocage. Consultez la section Policy decisions. Le bloc reason correspond à l'explication de votre fournisseur. Si votre fournisseur n'en renvoie pas, l'appelant voit la raison par default :
Accès refusé : cette requête n’est pas autorisée par une règle sur ce service.
Ce que Databricks envoie à votre fournisseur
À chaque évaluation, Databricks envoie à votre fournisseur le contenu évalué, le nom du service gouverné et la configuration de la stratégie que vous avez définie. Le contenu dépend du service et de la phase :
Service | Phase | Contenu envoyé |
|---|---|---|
Service MCP | Entrée | Le nom de l'outil et ses arguments. |
Service MCP | Résultat | The tool result, along with the originating tool call. |
Service de modèle ou service de fournisseur de modèle | Entrée | Le corps de requête complet du modèle, tel que les messages. |
Service de modèle ou service de fournisseur de modèle | Résultat | Corps de la réponse complète du modèle, ainsi que la requête d’origine. |
Les corps de requête et de réponse du modèle sont envoyés dans le format d'API utilisé par l'appelant, tel que OpenAI Chat Completions, OpenAI Responses, Anthropic Messages ou Gemini. Databricks ne les convertit pas en un format commun.
Databricks n’envoie que le contenu de votre fournisseur, et non l’identité de l’appelant. Lorsque la requête comporte une trace, Databricks envoie également son ID de trace, ce qui vous permet de faire correspondre une évaluation dans les logs de votre fournisseur avec la requête.
Vérifier le trafic de sortie du réseau avant d’attacher une politique
Une politique de service externe envoie le contenu en cours d’évaluation, qui peut inclure des requêtes et des réponses de modèles brutes ou des arguments et des résultats d’outils MCP, à un service tiers. Avant d’associer la politique, examinez les pratiques de traitement des données de votre fournisseur et confirmez la cible de la connexion.
Une connexion Unity Catalog régit les identifiants et la configuration de la connexion. Elle ne restreint pas les destinations réseau accessibles. Les politiques de service externe ne nécessitent pas de politique réseau restreinte. Par conséquent, si votre workspace n'en possède pas, l'accès sortant n'est pas restreint et une politique peut envoyer du contenu évalué vers n'importe quel endpoint accessible via une connexion configurée.
Databricks recommande d’appliquer une politique de réseau à accès restreint qui autorise uniquement les destinations de services de politiques approuvées. Consultez Connections and network policies et Manage network policies for serverless egress control.
Comportement de refus par défaut
Les politiques de service externe échouent en mode fermé. Si l'endpoint de votre fournisseur expire, renvoie une erreur, renvoie une réponse que Databricks ne peut pas analyser ou renvoie un verdict autre que ALLOW ou DENY, Databricks refuse l'appel. Vous ne pouvez pas configurer une politique de service externe pour laisser passer le trafic lorsque le fournisseur n'est pas disponible.
En mode Enforce , cela place la disponibilité et la latence de votre fournisseur sur le chemin critique de chaque appel régi :
- Confirmez la latence et la disponibilité de votre fournisseur avant d'appliquer la politique. Databricks attend environ 5 secondes pour une réponse. Les réponses plus lentes sont refusées.
- Log mode doesn't mask endpoint problems. A failing endpoint still records
DENYresults, so many unexpected denies in Log mode are a sign to fix the endpoint before you switch to Enforce.
Limitations
Les limitations suivantes s'appliquent :
- Autoriser et refuser uniquement : les politiques de service externe renvoient
ALLOWouDENY. Ils ne peuvent pas retenir un appel pour approbation humaine (ASK), et ils ne peuvent pas masquer ou réécrire du contenu. - Un service à la fois : vous associez une politique à un seul service. L’association d’une politique à plusieurs services à la fois n’est pas disponible.
- UI only : vous attachez des politiques de service externe via l’interface utilisateur de Unity Gateway. L’attachement via l’API REST ou Terraform n’est pas disponible.
- OAuth M2M uniquement : la connexion doit utiliser l'authentification OAuth machine à machine.
- Support fournisseur requis : votre fournisseur doit implémenter l’API Databricks external policy. Databricks doesn't provide per-vendor adapters.
Dépannage
Symptôme | Cause probable |
|---|---|
La politique n'a aucun effet immédiatement après son association. | Vous avez effectué le test pendant la fenêtre de propagation, ce qui prend généralement de 60 à 90 secondes. Patientez, puis réessayez. |
Chaque appel est refusé. | L'endpoint est inaccessible, renvoie des erreurs ou expire, de sorte que la politique échoue en mode fermé. Vérifiez l'hôte, le chemin d'accès et les identifiants de la connexion, puis vérifiez l'état de santé de l'endpoint auprès de votre fournisseur. |
Chaque appel est refusé et le motif indique que le résultat n'est pas reconnu. | Votre fournisseur a renvoyé un verdict autre que |
Les appels refusés affichent le motif default au lieu de celui de votre fournisseur. | Votre fournisseur n’a fourni aucun motif ; Databricks affiche donc le default text. |
Le mode Log ne montre aucun résultat. | Ni la table de suivi unifiée ni une table d’inférence sur le service ne sont configurées, de sorte que les résultats du mode Log ne sont enregistrés nulle part où vous pouvez effectuer une query. La politique appelle toujours votre fournisseur. |
La connexion s’enregistre, mais les appels échouent. | Les identifiants ou l'endpoint de jeton sont incorrects. Confirmez l'identifiant client, le secret du client, l'endpoint de jeton, ainsi que tous les périmètres requis auprès de votre fournisseur. |