Aller au contenu principal

Stratégies réseau basées sur le contexte

Les politiques réseau basées sur le contexte de Databricks offrent un cadre de sécurité unifié pour la gestion du trafic entrant et sortant de vos Workspace.

Databricks prend en charge deux types de contrôle basé sur le contexte :

  • Contrôle d’entrée basé sur le contexte : restreint les utilisateurs pouvant accéder à vos ressources, leur provenance et les éléments accessibles, en fonction d’une combinaison d’identités, de sources réseau et de types de demandes.
  • Contrôle de sortie Serverless : restreint les emplacements vers lesquels vos charges de travail Serverless peuvent envoyer des données en limitant les connexions sortantes aux destinations autorisées.

Aperçu des politiques réseau basées sur le contexte​

Les stratégies réseau basées sur le contexte permettent aux administrateurs de compte de définir des règles d'autorisation et de refus qui associent qui appelle, d'où la personne appelle et ce qu'elle peut atteindre, et de contrôler les destinations externes auxquelles les workloads serverless peuvent se connecter. Cela vous aide à répondre aux exigences de sécurité et de conformité, et réduit le risque d'accès non autorisé et d'exfiltration de données.

Les politiques réseau basées sur le contexte vous permettent de :

  • Bloquez l’accès aux réseaux non fiables en exigeant une source de réseau approuvée en plus des identifiants.
  • Autorisez l’accès aux clients software as a service (SaaS) sans IP de sortie stables en vous basant sur l’identité plutôt que sur les plages d’adresses IP.
  • Limitez l'accès en autorisant les sources moins fiables à n'utiliser que certains périmètres, tels que les Databricks APIs ou l'interface utilisateur du workspace.
  • Appliquez une posture de refus par default pour les connexions sortantes des workloads serverless.
  • Auditez efficacement en capturant les logs de refus détaillés dans les tables système de Unity Catalog.

Les stratégies réseau basées sur le contexte complètent ces fonctionnalités de sécurité existantes :

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

    • Listes d'accès IP du Workspace
    • Listes d'accès IP du compte
    • Private Service Connect entrant (utilisant les paramètres d'accès privé)
  • Serverless contrôle de sortie :

    • Private Service Connect sortant (utilisant des configurations de connectivité réseau)

Types de politiques comparés​

Les stratégies réseau basées sur le contexte incluent deux types : le contrôle d'entrée et le contrôle de sortie. Le tableau suivant résume les principales différences :

Attribut

Contrôle d'entrée

Contrôle d'extraction

Ce qu'il contrôle

Requêtes entrantes vers les Endpoints de workspace Databricks.

Connexions sortantes du compute Serverless vers des destinations externes.

Cas d'usage principal

Restreindre qui peut accéder à votre workspace, d'où et ce qu'il peut atteindre.

Empêchez l'exfiltration de données en contrôlant les Ressources externes auxquelles Serverless compute peut se connecter.

Critères de politique

Identité (plusieurs utilisateurs ou plusieurs Service Principals)

Source réseau (plage CIDR, Endpoint privés enregistrés)

Type d'accès ( interface utilisateur du Workspace , API , environnement d'exécution des applications , environnement d'exécution Lakebase )

Emplacements autorisés

FQDNs

Conteneurs de stockage cloud

Journalisation d’audit

system.access.inbound_network table système

system.access.outbound_network table système

Attribut

Contrôle d'entrée

Contrôle d'extraction

Ce qu'il contrôle

Requêtes entrantes vers les Endpoints de workspace Databricks.

Connexions sortantes du compute Serverless vers des destinations externes.

Cas d'usage principal

Restreindre qui peut accéder à votre workspace, d'où et ce qu'il peut atteindre.

Empêchez l'exfiltration de données en contrôlant les Ressources externes auxquelles Serverless compute peut se connecter.

Critères de politique

Identité (plusieurs utilisateurs ou plusieurs Service Principals)

Source réseau (plage CIDR, Endpoint privés enregistrés)

Type d'accès ( interface utilisateur du Workspace , API , environnement d'exécution des applications , environnement d'exécution Lakebase )

Emplacements autorisés

FQDNs

Conteneurs de stockage cloud

Journalisation d’audit

system.access.inbound_network table système

system.access.outbound_network table système

Contrôle d’entrée et de sortie basé sur le contexte​

Le contrôle d'accès basé sur le contexte permet aux administrateurs de compte de définir des règles d'autorisation et de refus qui combinent l'identité, la source réseau et le type de requête, afin que seules les combinaisons de confiance puissent atteindre vos ressources.

Les politiques au niveau du workspace régissent l'accès aux workspaces. Chaque compte comprend une politique par default au niveau du workspace qui s'applique à tous les workspaces éligibles sans attribution explicite.

Pour en savoir plus sur les sources de réseau, les types d’accès, les identités, l’évaluation des règles, les modes d’application, l’audit et la manière dont le trafic d’entrée interagît avec les autres contrôles réseau, consultez la section Contrôle d’entrée basé sur le contexte.

Contrôle de sortie serverless​

Le contrôle de sortie serverless gère les connexions réseau sortantes de vos ressources de compute serverless, réduisant ainsi le risque d'exfiltration de données. Une politique réseau est un objet au niveau du compte, associé à un ou plusieurs Workspace, qui définit le mode d'accès sortant pour les workloads Serverless :

  • Accès complet : les charges de travail Serverless disposent d'un accès sortant illimité à Internet et à d'autres ressources réseau.
  • Accès restreint : l’accès sortant est limité aux emplacements externes Unity Catalog ainsi qu’aux FQDN et aux buckets Google Cloud Storage que vous répertoriez explicitement dans la politique.

Pour connaître la posture de sécurité à accès restreint, les produits serverless pris en charge et les étapes de configuration, consultez Qu’est-ce que le contrôle de sortie serverless ?.

Modes d'application​

Les politiques d'entrée et de sortie prennent en charge le mode En enforced , dans lequel les règles sont appliquées et les requêtes non conformes sont bloquées, ainsi que le mode Dry run , dans lequel les violations sont enregistrées sans être bloquées. Databricks recommande de commencer en mode simulation pour éviter les disruptions d'accès non intentionnelles.

Journalisation d'audit​

Databricks enregistre les évaluations de politiques à des fins de conformité et de monitoring : les refus d’entrée dans system.access.inbound_network et les événements de sortie dans system.access.outbound_network. Interrogez ces logs pour valider l’efficacité des politiques et détecter les tentatives d’accès non autorisées.

Comment les politiques interagissent avec d'autres contrôles​

Les politiques d’accès entrant basées sur le contexte fonctionnent parallèlement aux listes d’accès IP et à la connectivité privée front-end, et le contrôle de sortie serverless fonctionne parallèlement à la connectivité privée sortante (à l’aide de configurations de connectivité réseau). Pour savoir comment l'accès entrant interagit avec chacun de ces contrôles, y compris le comportement de connectivité privée par cloud, consultez Relation avec les autres contrôles.

astuce

Pour réduire la complexité, Databricks 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.