Aufbau einer Zero-Trust-KI-Plattform auf Azure Databricks

Die meisten Databricks-Deployments beginnen mit der Standardkonfiguration: öffentliche Endpunkte, permissives Netzwerk und Service-Principal-Geheimnisse in Umgebungsvariablen. Das funktioniert für einen Proof of Concept. Es funktioniert nicht für Unternehmen, die sensible Daten verarbeiten, unter regulatorischen Pflichten stehen oder Audit-Prüfungen ausgesetzt sind.

Dieser Beitrag erläutert die Sicherheitsarchitektur unserer Open-Source-Enterprise-Databricks-Plattform und zeigt, wie jede Schicht Zero-Trust-Prinzipien durchsetzt.

Das Sicherheitsproblem mit Standard-Databricks

Ein standardmäßiger Azure-Databricks-Workspace hat mehrere Sicherheitslücken:

• Öffentliche Endpunkte für Workspace-UI und API
• Compute-Knoten mit öffentlichen IPs, die direkt ins Internet gelangen können
• Geteilte Infrastruktur mit anderen Databricks-Kunden in der Steuerungsebene
• Service-Principal-Geheimnisse, die irgendwo gespeichert und rotiert werden müssen

Für regulierte Branchen — Finanzdienstleistungen, Gesundheitswesen, öffentliche Verwaltung, kritische Infrastruktur — ist jeder dieser Punkte ein Compliance-Blocker. Für NIS2-betroffene Organisationen ist die Kombination unhaltbar.

Schicht 1: Hub-Spoke-Netzwerktopologie

Das Fundament ist ein Hub-Spoke-Netzwerkdesign, bei dem gemeinsame Sicherheitsdienste im Hub und Workloads in isolierten Spokes leben.

Das Hub-VNet enthält:

• Azure Firewall (Forced-Tunneling-Subnetz)
• Azure Bastion (Managementzugang ohne öffentliches RDP/SSH)
• VPN Gateway mit Entra-ID-Authentifizierung
• Private DNS Resolver für VPN-Client-Namensauflösung
• 7 Private DNS Zones für Azure-Dienste

Das Spoke-VNet enthält:

• Databricks Public- und Private-Subnetze (VNet-Injection)
• Azure Functions-Integrationssubnetz
• Private-Endpoint-Subnetz
• NAT Gateway für kontrollierte ausgehende Konnektivität

VNet-Peering verbindet Hub mit Spoke. User-Defined Routes auf den Spoke-Subnetzen erzwingen die Weiterleitung allen ausgehenden Verkehrs durch die Hub-Firewall.

Schicht 2: Firewall-erzwungenes Tunneling

Azure Firewall sitzt an der Netzwerkgrenze mit expliziten Allow-Regeln:

Application Rules whitelisten FQDN-Ziele: Databricks Control Plane, PyPI, Ubuntu-Paketrepositories, GitHub.

Network Rules erlauben spezifische IP-Bereiche für Databricks-Infrastrukturdienste.

Alles andere wird standardmäßig abgelehnt. Wenn ein kompromittierter Knoten versucht, Daten an einen unbekannten Endpunkt zu exfiltrieren, blockiert die Firewall den Versuch und protokolliert ihn.

Schicht 3: Private Endpoints überall

Jeder PaaS-Dienst wird ausschließlich über Private Endpoints angesprochen:

Dienst	Private Endpoints	Warum
Databricks	4 (UI/API, Browser-Auth, DFS, Blob)	Eliminiert öffentlichen Workspace- und DBFS-Zugang
ADLS Gen2	2 (Blob, DFS)	Data Lake nur aus dem VNet erreichbar
Key Vault	1	Geheimnisse durchqueren nie öffentliche Netzwerke
Container Registry	1	Container-Images über privates Netzwerk gepullt

Öffentlicher Netzwerkzugang ist auf jedem Dienst deaktiviert. Selbst mit den korrekten Anmeldedaten können Sie diese Dienste nicht über das öffentliche Internet erreichen.

Schicht 4: Managed Identities — Keine Geheimnisse

Die Plattform verwendet drei benutzerzugewiesene Managed Identities:

1. Databricks-Identität — Vom Access Connector für Unity Catalog zum Zugriff auf ADLS Gen2
2. Functions-Identität — Von Azure Functions für die Interaktion mit Service Bus und Key Vault
3. CI/CD-Identität — Von GitHub Actions über OIDC-Federation

Keine Identität hat ein Client Secret. Die Authentifizierung erfolgt über den internen Azure-Token-Dienst. Die CI/CD-Identität verdient besondere Aufmerksamkeit: GitHub Actions tauscht zur Laufzeit ein OIDC-Token gegen ein Azure-Zugriffstoken — keine Geheimnisse in GitHub gespeichert, keine Credentials zu rotieren.

RBAC-Zuweisungen folgen dem Least-Privilege-Prinzip:

• Databricks-Identität erhält Storage Blob Data Contributor auf dem Data Lake — nichts anderes
• Functions-Identität erhält Key Vault Secrets User und Service Bus Data Sender/Receiver — nichts anderes
• CI/CD-Identität erhält Contributor auf Ressourcengruppenebene — nicht auf Subscription-Ebene

Schicht 5: Datenverschlüsselung

Im Ruhezustand: ADLS Gen2 nutzt Customer-Managed Keys aus Key Vault mit Infrastructure-Level-Doppelverschlüsselung.

Während der Übertragung: Alle Verbindungen nutzen TLS. Private Endpoints stellen sicher, dass der Verkehr nie das Azure-Backbone verlässt.

Key-Management: Key Vault hat Soft-Delete (90 Tage) und Purge Protection aktiviert.

Schicht 6: Azure Policy Enforcement

Das Landing-Zone-Modul deployt Azure-Policy-Zuweisungen als Leitplanken:

• Tags erforderlich auf allen Ressourcen (Umgebung, Projekt, Besitzer, Kostenstelle)
• Standorte einschränken auf genehmigte Azure-Regionen
• HTTPS erzwingen auf Storage Accounts
• Diagnose erforderlich an Log Analytics senden

Schicht 7: Monitoring und Alerting

Die Plattform deployt:

• Log-Analytics-Workspace, der Diagnosen aller Dienste aggregiert
• Geplante Query-Alerts für anomale Muster
• Konfigurierbare Budget-Alerts (Standard 1.000$, pro Umgebung anpassbar)
• Application Insights für Azure-Functions-Telemetrie

Zuordnung zu Compliance-Frameworks

Diese Architektur unterstützt direkt:

• NIS2 — Netzwerksegmentierung, Vorfallserkennung, Zugangskontrolle, Lieferkettensicherheit
• ISO 27001 — Asset-Management, Zugangskontrolle, Kryptographie, Betriebssicherheit, Kommunikationssicherheit
• EU AI Act — Logging und Rückverfolgbarkeit, Cybersicherheit, Robustheit

Erste Schritte

Die vollständige Implementierung ist unter github.com/MedGhassen/databricks-enterprise-ai-platform unter der MIT-Lizenz verfügbar. Beginnen Sie mit den Verzeichnissen modules/networking und modules/firewall.

Weiterführende Ressourcen

• Zero-Trust-Architektur: Vom Buzzword zur Produktion in 6 Monaten — Das strategische Framework hinter dieser Implementierung.
• NIS2-Compliance: Ein technischer Fahrplan für IT-Verantwortliche — Wie diese Architektur NIS2-Anforderungen abbildet.
• Wir haben unseren Enterprise-Databricks-KI-Plattform-Blueprint als Open Source veröffentlicht — Überblick über die gesamte Plattform jenseits der Sicherheit.

Fragen zur Implementierung von Zero Trust für Ihre Databricks-Umgebung? Kontaktieren Sie uns — das ist unser Spezialgebiet.