Aller au contenu principal
Dernière mise à jour le

Contrôle d'entrée basé sur le contexte

remarque

L’entrée basée sur le contexte nécessite l’ édition Enterprise.

L'entrée basée sur le contexte est généralement disponible (GA), mais certaines fonctionnalités associées sont en phase de Bêta:

  • Plateformes partenaires en tant que source réseau : ajoutez à la 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. Activez les fonctionnalités de version bêta de l’entrée basée sur le contexte ( Context-based ingress beta features ) dans la page des versions préliminaires de la console de votre compte pour start.
  • Cross-workspace access : contrôle quels workspaces sources peuvent accéder à 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.

Cette page donne un aperçu du contrôle d’accès entrant basé sur le contexte, notamment ses concepts fondamentaux, ses modes d’application, l’audit et son interaction avec d’autres contrôles réseau. Pour configurer les politiques, consultez la section Gérer les politiques d’accès entrant basées sur le contexte. Pour le contrôle de sortie serverless, consultez la section Qu’est-ce que le contrôle de sortie serverless ?.

Vue d'ensemble du contrôle d'entrée basé sur le contexte​

Le contrôle d'entrée basé sur le contexte fonctionne conjointement avec les listes d'accès IP et la connectivité privée front-end pour permettre aux administrateurs de compte de définir des règles d'autorisation et de refus qui combinent qui appelle, d'où ils appellent et ce qu'ils peuvent atteindre dans Databricks. Cela garantit que seules les combinaisons fiables d’identité, de type de requête et de source réseau peuvent atteindre votre workspace. Le contrôle d'ingestion basé sur le contexte est configuré au niveau du compte. Une seule stratégie peut régir plusieurs espaces de travail.

Grâce à l'entrée basée sur le contexte, vous pouvez :

  • Bloquez l'accès depuis les réseaux non fiables en exigeant un second facteur, une source de réseau fiable, en plus des identifiants.
  • Autoriser l’accès pour les clients SaaS sans IP de sortie stables en se basant sur l’identité au lieu des plages d’adresses IP.
  • Limitez l'accès en permettant aux sources moins fiables d'utiliser uniquement certains périmètres, comme les APIs Databricks ou l'interface utilisateur du Workspace.
  • Protéger l'automatisation privilégiée : Limitez les Databricks Service Principal de grande valeur aux réseaux de confiance élevée uniquement.
  • Auditez efficacement : capturez les journaux de refus détaillés dans les tables système Unity Catalog pour surveiller les requêtes bloquées.

Politiques au niveau du workspace et au niveau du compte​

Le contrôle d’entrée basé sur le contexte utilise deux types de politiques. Les politiques au niveau du Workspace régissent l’accès aux workspaces. Les politiques au niveau du compte régissent l’accès aux ressources au niveau du compte, telles que la console du compte et Genie One au niveau du compte.

Sur Google Cloud, le contrôle d’entrée basé sur le contexte fournit uniquement des politiques au niveau du workspace. Les politiques au niveau du compte ne sont pas disponibles. Pour gérer les politiques au niveau du workspace, consultez la section Gérer les politiques d’entrée basées sur le contexte du workspace.

Concepts fondamentaux du contrôle d'entrée basé sur le contexte​

Sources réseau​

Une source réseau définit l'origine des requêtes. Les types pris en charge incluent :

Politique d'accès public :

  • Toutes les adresses IP publiques : Toute source Internet publique.
  • IPs sélectionnées : Adresses IPv4 spécifiques ou plages CIDR.
  • Plateformes partenaires (Bêta) : adresses IP que les applications tierces (Power BI, Tableau Cloud et plateforme dbt) utilisent pour se connecter à Databricks. Databricks gère et met à jour ces listes d’adresses IP automatiquement.

Cross-workspace access (Beta) : contrôle quels Workspace sources peuvent accéder à ce Workspace via le trafic Serverless, en utilisant les mêmes identités ainsi que les mêmes règles d'autorisation et de refus que les autres sources réseau.

  • Workspaces sélectionnés : uniquement les workspaces dont vous listez les ID.

Vous pouvez également laisser cette politique en mode compatibilité ; dans ce cas, 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 à la fois pour l'entrée et la sortie, et pour examiner ses limitations, voir Accès inter-workspace.

Types d'accès​

Les règles s'appliquent à différentes portées de requêtes entrantes. Chaque portée représente une catégorie de requêtes entrantes que vous pouvez autoriser ou refuser :

Types d'accès aux politiques au niveau du Workspace :

  • Workspace UI : Accès au Workspace via le navigateur.

  • API : programmatic access through Databricks APIs, including SQL Endpoint (JDBC / ODBC). You can target any of the following:

    • Toutes les APIs.
    • Une portée d'API spécifique, utilisant IN . Par exemple, vous pouvez spécifier des applications, un tableau de bord ou le service de modèles.
    • Tous les champs d’application API, à l’exception de ceux sélectionnés, en utilisant NOT IN .

  • Exécution d’applications : Autoriser ou refuser l’accès aux déploiements Databricks Apps. See Databricks Apps. Seule l’option d’identité Tous les utilisateurs et Service Principal est prise en charge pour ce type d’accès.

Identités​

Les règles peuvent cibler différents types d’identité. Pour les types d'accès **runtime d'applications** et **runtime Lakebase**, la seule option prise en charge est **Tous les utilisateurs et les principaux de service**.

  • Tous les utilisateurs et Databricks Service Principal : utilisateurs humains et automatisation.
  • Tous les utilisateurs : Utilisateurs humains uniquement.
  • Tous les Service Principal Databricks : identités d'automatisation uniquement.
  • Identités sélectionnées : Utilisateurs spécifiques ou Service Principals Databricks.

Évaluation des règles​

  • default deny : en mode restreint, l'accès est refusé sauf s'il est explicitement autorisé.
  • Refuser avant d'autoriser : Les règles de refus vous permettent de définir des exceptions à vos règles d'autorisation.
  • default Workspace-level policy : Chaque compte dispose d’une politique d’entrée par default au niveau du Workspace appliquée à tous les Workspaces éligibles sans affectation de politique explicite.

Modes d'application​

Les politiques d'entrée basées sur le contexte permettent deux modes :

  • Appliqué à tous les produits : Databricks applique activement les règles et bloque les requêtes non conformes.
  • Mode de simulation pour tous les produits : Databricks enregistre les violations, mais ne bloque pas les requêtes. Utilisez ce mode pour évaluer l'impact de la politique avant son application.
remarque

Une politique réseau ne prend en charge qu’un seul mode d’application à la fois.

Databricks recommande de commencer en mode simulation pour observer l’impact de la politique avant de l’activer.

Audit​

Les requêtes refusées ou simulées sont enregistrées dans la table système system.access.inbound_network. Si vous n'avez pas accès aux tables système, un administrateur de métastore peut vous accorder des autorisations. Consultez Accorder l'accès aux tables système.

Chaque entrée de Logs comprend :

  • Heure de l'événement
  • ID du Workspace
  • Étiquette de la règle (de la règle ayant refusé la requête)
  • Type de requête
  • Identité
  • Source réseau
  • Type d'accès (DENIED ou DRY_RUN_DENIAL)

Interrogez ces logs pour vérifier que vos règles fonctionnent comme prévu et pour détecter les tentatives d'accès inattendues.

Relation avec d'autres contrôles​

  • Listes d'accès IP du Workspace : évaluées avec la politique d'entrée basée sur le contexte à l'aide d'un ET logique, sans séquence stricte entre les deux. Une requête est autorisée uniquement si la liste d’accès IP et la politique d’entrée le permettent. Les listes d’accès IP du Workspace peuvent restreindre davantage l’accès, mais ne peuvent pas l’élargir.
  • Contrôle de la sortie Serverless : complète les politiques d'entrée en contrôlant le trafic réseau sortant du compute Serverless. Voir Gérer les politiques de réseau.
  • Accès inter-workspace : contrôle quels workspaces sources peuvent atteindre un workspace via le trafic serverless, en plus des contrôles d'identité et de source réseau présents sur cette page. Voir Accès inter-workspace.
  • Listes d'accès IP des destinataires OpenSharing : l'entrée basée sur le contexte ne s'applique pas aux listes d'accès IP des destinataires OpenSharing. Il s'agit d'un contrôle distinct pour les destinataires ouverts que les fournisseurs configurent par destinataire. Voir Restreindre l'accès des destinataires OpenSharing à l'aide de listes d'accès IP (partage Databricks vers Open).
astuce

Pour réduire la complexité, Databricks vous recommande d'utiliser la politique d'entrée basée sur le contexte comme unique moteur de politique plutôt que de maintenir également des listes d'accès IP. Si vos workspaces possèdent déjà des listes d'accès IP, consultez la page Migrer les listes d'accès IP du workspace vers une entrée basée sur le contexte.

  • Connectivité privée front-end : appliquée parallèlement aux politiques d'entrée lorsque l' accès public est activé est True . Si l' accès public activé est False , tout accès public entrant est bloqué et les stratégies d'entrée ne sont pas évaluées. Voir Gérer les paramètres d'accès privé.

Gérer les politiques d’entrée basées sur le contexte​

Configurez et attachez des politiques au niveau qui correspond à la ressource que vous souhaitez protéger :

API et Terraform​

Outre la console de compte, vous pouvez gérer les politiques d’entrée basées sur le contexte par programmation :

  • API REST : utilisez l’API REST Databricks pour gérer les politiques réseau.
  • Terraform : utilisez le fournisseur Databricks Terraform pour gérer les politiques d’entrée en tant qu’infrastructure sous forme de code.

Bonnes pratiques​

  • Commencez par le mode de simulation pour observer les impacts sans interrompre l’accès.
  • Utilisez des règles basées sur l'identité, si possible pour les clients SaaS qui font tourner les adresses IP.
  • Appliquez d'abord les règles de refus aux Service Principals Databricks privilégiés afin de limiter la zone affectée.
  • Maintenez les noms de politique clairs et cohérents.

Disponibilité​

remarque

Le contrôle d'ingestion basé sur le contexte n'est pas disponible dans la région GCP Middle East Central 2.

Sur cette page