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

info

Aperçu

La politique d'ingestion basée sur le contexte au niveau du compte est en Beta.

Les stratégies basées sur le contexte Databricks offrent un cadre de sécurité unifié pour la gestion du trafic entrant et sortant vers vos Workspaces et les ressources au niveau du compte (par exemple, la console du compte et Genie One au niveau du compte). Les politiques au niveau du Workspace sont configurées sous Workspace level policies , avec une politique au niveau du Workspace par default attribuée à tous les workspaces sans attribution explicite. La politique au niveau du compte est configurée séparément sous Account level policy ; son ID de politique est account-policy.

Avec l'entrée basée sur le contexte, les administrateurs peuvent restreindre l'accès au workspace et au niveau du compte en fonction d'une combinaison d'identité, de source réseau et de type de requête. Les politiques de sortie Serverless étendent ce contrôle au trafic sortant en limitant les charges de travail Serverless aux destinations autorisées. Ensemble, ces politiques réseau contribuent à garantir que l'accès des utilisateurs et le mouvement des données restent dans des limites fiables au sein de votre organisation.

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
  • Inbound Private Link (en utilisant les paramètres d'accès privé)

• Serverless contrôle de sortie :

  • Private Link sortant (utilisant les configurations de connectivité réseau)

Avantages

Les politiques réseau d'entrée basées sur le contexte offrent les avantages suivants pour votre sécurité réseau :

• Sécurité renforcée : atténuer les risques d'accès non autorisé et d'exfiltration de données.
• Contrôle sensible à l'identité : Prend en charge les clients SaaS sans plages d'adresses IP stables en utilisant des règles basées sur l'identité.
• Application flexible : appliquez des règles différentes à différents types de requêtes, sources et identités.
• Gestion centralisée : configurer une seule fois au niveau du compte, appliquer à plusieurs workspaces.
• Test sécurisé : utilisez le mode simulation pour tester l’impact des stratégies avant l’application complète.

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 Databricks de niveau workspace et de niveau compte.	Connexions sortantes du compute Serverless vers des destinations externes.
Cas d'usage principal	Limitez qui peut accéder à vos ressources au niveau du workspace et du compte, d'où et ce qu'elles peuvent 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 Virtual Private Cloud (VPC) enregistrés) Type d’accès : pour les workspaces ( Interface utilisateur de workspace , API , runtime Apps , runtime Lakebase ), pour le compte ( Interface utilisateur du compte , API du compte )	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 Databricks de niveau workspace et de niveau compte.	Connexions sortantes du compute Serverless vers des destinations externes.
Cas d'usage principal	Limitez qui peut accéder à vos ressources au niveau du workspace et du compte, d'où et ce qu'elles peuvent 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 Virtual Private Cloud (VPC) enregistrés) Type d’accès : pour les workspaces ( Interface utilisateur de workspace , API , runtime Apps , runtime Lakebase ), pour le compte ( Interface utilisateur du compte , API du compte )	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

Comment les stratégies basées sur le contexte fonctionnent

Avec le contrôle d'entrée, vous pouvez :

• Bloquez l'accès aux réseaux non fiables en exigeant à la fois des informations d'identification valides et une source de réseau fiable.
• Autoriser les outils d'automatisation SaaS avec des IP dynamiques en utilisant des règles basées sur l'identité plutôt que des listes d'adresses IP autorisées.
• Limitez les opérations sensibles à l'interface utilisateur tout en autorisant un accès plus large à l'API.
• Limitez les Service Principal à privilèges élevés uniquement aux plages de réseau d'entreprise.

Avec le contrôle de sortie, vous pouvez :

• Empêchez l'exfiltration de données en limitant les APIs externes que le compute Serverless peut atteindre.
• Autoriser la connectivité uniquement vers les compartiments de stockage cloud et les bases de données externes approuvés.
• Bloquez les connexions sortantes vers des destinations non autorisées tout en autorisant les intégrations requises.
• Appliquez la conformité en limitant le mouvement des données aux régions et services approuvés.

• • Configurez les politiques d'entrée.
  • Configurez des règles d'autorisation et de refus qui combinent l'identité, la source réseau et le type d'accès pour contrôler les requêtes entrantes vers votre workspace.
• • Configurer les politiques de sortie
  • Définissez des règles de connexion sortantes pour contrôler les destinations externes que vos ressources de compute Serverless peuvent atteindre.

Modes d'application

Les politiques basées sur le contexte ont deux modes d'application différents :

• Mode appliqué : les règles sont activement appliquées. Les requêtes en infraction sont bloquées.
• **Mode simulation** : les violations sont enregistrées, mais ne sont pas bloquées. Utilisez ce mode pour tester l'impact des politiques avant leur application.

Databricks recommande de commencer en mode simulation afin d'éviter les disruptions d'accès imprévues.

Journalisation d'audit

Databricks enregistre toutes les évaluations de politique pour la conformité et le monitoring :

• Entrée : journalisée dans la table système system.access.inbound_network.
• Sortie : Enregistrée dans la table système system.access.outbound_network.

Interrogez ces Logs pour valider l'efficacité des stratégies et détecter les tentatives d'accès non autorisé.

Comment les politiques interagissent avec d'autres contrôles

• Listes d'accès IP : les listes d'accès IP et les politiques d'entrée basées sur le contexte d'accès public doivent toutes deux autoriser une requête. Si vous désactivez l'accès public dans vos paramètres d'accès privé, le système refuse toutes les requêtes publiques indépendamment des règles de politique d'entrée.

• Connectivité privée :

  • Pour que le trafic soit autorisé, les paramètres d'accès privé et l'entrée basée sur le contexte doivent tous deux autoriser l'endpoint. Par défaut, l'entrée basée sur le contexte est définie sur Autoriser l'accès depuis tous les private endpoints , ce qui reporte la décision d'accès au paramètre d'accès privé du workspace. Si vous souhaitez configurer des politiques d'accès privé basées sur le contexte, assurez-vous que votre workspace dispose d'un paramètre d'accès privé attaché, avec tous les endpoints privés enregistrés autorisés (voir plus ci-dessous). Ceci déférera la décision d’accès à la politique d’ingestion basée sur le contexte de votre workspace.
  • Pour la politique au niveau du compte, l'entrée basée sur le contexte est la source unique de vérité pour la politique d'accès privé.

• Profils de sécurité : les stratégies basées sur le contexte fournissent des contrôles au niveau du réseau qui complètent le compute et la gouvernance des données.

Bonnes pratiques

• start en mode simulation pour valider le comportement de la stratégie avant son application.
• Utilisez des règles basées sur l'identité pour les clients SaaS avec des adresses IP dynamiques.
• Appliquez d'abord les règles de refus aux Service Principal à privilèges élevés afin de limiter les risques.
• Surveillez régulièrement les Logs d'audit pour détecter les modèles d'accès inattendus.
• Testez les politiques de sortie pour vous assurer que les ressources externes requises restent accessibles.
• Utilisez des noms de politique descriptifs pour une maintenabilité à long terme.