Gérer les politiques d'accès entrant basées sur le contexte du workspace

Cette page indique aux administrateurs de compte comment créer une politique réseau au niveau du workspace, configurer ses règles d'entrée pour l'accès public, privé et inter-workspace, et l'associer aux workspaces.

Pour obtenir un aperçu du contrôle d’accès entrant basé sur le contexte (y compris les modes d’application, l’audit, la manière dont le trafic entrant interagit avec d’autres contrôles réseau, ainsi que les options de l’API et de Terraform), consultez Context-based ingress control. Pour le contrôle de sortie serverless, consultez What is serverless egress control?.

Conditions requises

• Vous devez être administrateur du compte.
• Votre compte Databricks doit être sur le niveau Enterprise.

remarque

Pour appliquer votre politique réseau d'entrée aux connexions pouvant provenir de n'importe où dans le monde, Databricks distribue la configuration de votre politique à l'infrastructure d'application dans toutes les régions Databricks, y compris les régions où vous ne possédez pas de workspace.

Accéder aux politiques réseau

Utilisez une politique réseau pour définir les règles d’entrée et de sortie pour un ou plusieurs workspaces. Pour gérer les politiques réseau dans votre compte :

1. Depuis la console du compte, cliquez sur Sécurité .
2. Cliquez sur l'onglet Networking .
3. Sous Policies , cliquez sur Context-based ingress & egress control .

Les politiques au niveau du workspace sont définies sous Workspace level policies .

remarque

The default workspace-level policy applies to any workspace without another network policy. Databricks doesn't recommend modifying its ingress rules. Instead, create a new policy and attach it to specific workspaces.

Créer une politique de réseau pour le workspace

1. Cliquez sur Créer une nouvelle politique réseau .
2. Entrez un nom de politique .
3. Cliquez sur l’onglet tab . Pour définir des règles de sortie, consultez Set egress rules.
4. Sélectionnez un mode d’accès réseau (pour l’accès au réseau public et l’accès au réseau privé) :
   • Autoriser l'accès depuis toutes les sources : autoriser l'accès entrant sans restriction sur Internet.
   • Restreindre l’accès en fonction du contexte de la demande : refusez l’accès entrant par default et n’autorisez l’accès qu’au moyen de règles d’autorisation explicites.

Configurer les règles d’entrée

Lorsque vous utilisez le mode d'accès restreint :

• La politique refuse l'accès par default.
• La politique n’accorde l’accès que lorsqu’une requête correspond à une règle Allow explicite.
• Les Deny rules sont des exceptions aux Allow rules . Par exemple, vous pouvez autoriser une large plage de réseau tout en refusant l'accès à des identités spécifiques au sein de cette plage. Si une requête correspond à la fois à une règle d'autorisation et à une règle de refus, la requête est refusée.

Pour configurer une règle d'autorisation ou de refus :

1. Cliquez sur Add rule au-dessus des listes Allow rules ou Deny rules .

2. Sélectionnez un type d’accès :

   • Workspace UI : autoriser l'accès à l'interface utilisateur du workspace.

   • API : autoriser ou refuser l'accès aux API Databricks. Vous pouvez également sélectionner des champs d'application API spécifiques pour affiner la règle en choisissant IN pour ne faire correspondre que les champs sélectionnés ou NOT IN pour faire correspondre tous les champs d'application API à l'exception de ceux-ci. Les champs d'application API ne peuvent être spécifiés que dans les règles d'autorisation, et non dans les règles de refus :

     • All APIs : s’applique à tous les appels d’API Databricks.
     • Apps : s’applique aux Endpoint de l’API Databricks Apps.
     • Dashboard : s’applique aux Endpoint de l’API de Databricks.
     • Mise en service du modèle : s'applique aux Endpoint d'API de mise en service du modèle.

   • Apps runtime : autorisez l'accès aux déploiements de Databricks Apps.

3. Sélectionnez un type d’identité :

   • All users and service principals : autorisez l'accès à la fois aux utilisateurs et aux service principals.
   • All users : n'autoriser l'accès qu'aux utilisateurs du workspace.
   • All Service Principal : autorisez l'accès uniquement aux Service Principal du Workspace.
   • Selected identities : n’autoriser l’accès qu’à des utilisateurs ou des Service Principal spécifiques. Choisissez les identités dans la liste Subjects .

remarque

Pour les types d'accès Lakebase runtime et Apps runtime , le seul type d'identité pris en charge est All users and service principals . Impossible de sélectionner d'autres options d'identité.

4. Sélectionnez une source réseau. Les sources disponibles dépendent du fait que vous configurez un accès public, privé ou inter-workspace, comme décrit dans les sections suivantes.

5. Cliquez sur Save .

remarque

You can define multiple allow and deny rules to control access based on client identity, client network source, or access scope (access type).

Accès au réseau public

Pour l'accès au réseau public, sélectionnez l'une des sources de réseau suivantes :

• All public IPs : autoriser l’accès depuis toutes les IP publiques.
• Selected IPs : Allow access from only specific IPs. Enter the IPs separated by commas.

info

Beta

Partner platforms as a network source is in Beta.

Sélectionnez Plateformes de partenaires pour autoriser par liste blanche les adresses IP que les applications tierces (Power BI, Tableau Cloud et dbt platform) utilisent pour se connecter à Databricks. Databricks gère et met à jour ces listes d'adresses IP automatiquement.

Pour les règles de refus avec des adresses IP sélectionnées, choisissez l'une des options suivantes :

• IN : refuse l'accès depuis les adresses IP situées dans la source de réseau spécifiée.
• NOT IN : refuse l'accès à partir d'adresses IP qui ne se trouvent pas dans la source réseau spécifiée.

Accès inter-workspace

info

Beta

Cross-workspace access is in Beta.

Les contrôles d'accès inter-workspace déterminent quels workspaces sources peuvent atteindre ce workspace via le trafic serverless, en utilisant les mêmes identités et règles d'autorisation et de refus que les autres sources réseau. Sélectionnez Selected workspaces comme source réseau et listez les identifiants de workspace à autoriser.

Si vous laissez la politique en mode de compatibilité, elle ne régit pas l'entrée inter-workspace et les contrôles réseau préexistants du workspace s'appliquent. Pour configurer l'accès inter-workspace du côté de l'entrée et de la sortie, et pour consulter ses limites, voir Configurer l'accès d'entrée inter-workspace.

Définir le mode d'application

Le mode simulation vous permet de tester votre politique et de surveiller les connexions entrantes sans bloquer aucun accès. Lorsque le mode simulation est activé, les demandes qui violent la politique sont enregistrées, mais ne sont pas bloquées. Pour plus de détails, consultez Modes d’application.

1. Définissez le mode d’application de la politique sur Enforced for all produits ou Dry run mode for all produits .
2. Cliquez sur Create .

Associer une politique aux workspaces

Si vous avez mis à jour votre politique default avec des configurations supplémentaires, elles sont appliquées automatiquement aux workspaces qui ne disposent pas d’une politique de réseau existante.

Pour associer votre Workspace à une autre politique, suivez ces étapes :

1. Dans la console du compte, cliquez sur Workspaces .
2. Sélectionnez un workspace.
3. Dans Network Policy , cliquez sur Update network policy .
4. Sélectionnez la politique réseau souhaitée dans la liste.
5. Cliquez sur Mettre la politique en application .

remarque

Policy changes, such as creating, updating, or attaching, typically take 10 to 15 minutes to take effect. During this window, enforcement might be inconsistent as the change propagates. Allow for this delay before relying on updated policies.

Configurer à l'aide de l'API ou de Terraform

En plus de la console de compte, vous pouvez configurer des politiques d'accès entrant basées sur le contexte à l'aide de l'API REST Databricks ou de Terraform. Consultez API et Terraform.

Vérifier les logs de refus

Les denial logs sont stockés dans la table system.access.inbound_network de Unity Catalog. Pour accéder aux denial logs, vérifiez que le schéma d’accès est activé sur votre métastore Unity Catalog. Consultez Activer les tables système. Pour connaître les champs capturés dans chaque entrée, consultez Auditing.

Utilisez une query SQL telle que l'exemple suivant pour afficher les événements de refus. Si les logs de simulation sont activés, la query renvoie à la fois les logs de refus et les logs de simulation, que vous pouvez distinguer à l'aide de la colonne access_type. Les logs de refus ont une valeur DROP , tandis que les logs de simulation affichent DRY_RUN_DENIAL .

L'exemple suivant récupère les logs des 2 dernières heures :

SQL

SELECT *
FROM system.access.inbound_network
WHERE event_time >= CURRENT_TIMESTAMP() - INTERVAL 2 HOUR
ORDER BY event_time DESC;

remarque

Il est possible que les logs n’apparaissent pas immédiatement. Un délai de plusieurs minutes peut s’écouler entre le moment de l’accès et l’apparition des logs de refus.

Limitations

remarque

Le contrôle d’accès entrant basé sur le contexte n’est pas disponible dans la région GCP Middle East Central 2.

Ressources supplémentaires

• Contrôle d’entrée basé sur le contexte
• Accès inter-workspace
• Qu’est-ce que le contrôle de sortie serverless ?