Security & Trust Center
Ihre Datensicherheit ist unsere Priorität
Wir wissen, dass Daten zu Ihren wertvollsten Gütern gehören und jederzeit geschützt werden müssen. Deshalb ist Sicherheit in jeden Layer der Lakehouse-Plattform von Databricks integriert. Dank unserer Transparenz können Sie Ihre rechtlichen Anforderungen erfüllen und gleichzeitig die Vorteile unserer Plattform nutzen.
– Tom Mulder, Lead Data Scientist bei Wehkamp
– Jeff Feldman, CTO von Arden Street Labs
— Credit Suise case study
Vertrauen
Unsere vertrauenswürdige Plattform entsteht durch Integration von Sicherheitsmerkmalen im gesamten Lebenszyklus von Softwareentwicklung und -bereitstellung. Wir beachten strikte betriebliche Sicherheitspraktiken wie Penetrationstests, Schwachstellenbewertungen und strenge interne Zugangskontrollen. Wir sind davon überzeugt, dass Transparenz der Schlüssel zum Vertrauen ist. Daher sprechen wir offen darüber, wie wir arbeiten, und stimmen uns in Fragen der Sicherheit eng mit unseren Kunden und Partnern ab.
Vertragliche Verpflichtung
Neben der Dokumentation und Best Practices, die Sie in unserem Security & Trust Center finden, verpflichten wir uns auch vertraglich zur Sicherheit für alle unsere Kunden. Diese Verpflichtung ist im Sicherheitszusatz festgehalten, der Teil unserer Kundenvereinbarung ist. Der Sicherheitszusatz beschreibt in klarer Sprache eine Liste von Sicherheitsmaßnahmen und Praktiken, die wir implementieren, um Ihre Daten zu schützen.
Schwachstellenmanagement
Das Aufspüren und schnelle Beheben von Schwachstellen in Software gehört zu den wichtigsten Aufgaben jedes Softwareanbieters und Dienstleisters. Dabei spielt es keine Rolle, ob eine Sicherheitslücke in Ihrem Code oder in der von Ihnen genutzten Software vorhanden ist. Wir nehmen diese Verantwortung sehr ernst und informieren in unserem Sicherheitszusatz über Problembehebungsfristen.
Intern nutzen wir verschiedene etablierte Sicherheitsscanner, um Schwachstellen innerhalb der Plattform zu ermitteln. Databricks nimmt zudem die Dienste von Drittanbietern in Anspruch, um unsere öffentlichen Websites zu analysieren und potenzielle Risiken zu erkennen. Schwachstellen mit Schweregrad 0 – z. B. Zero-Day-Exploits, bei denen eine aktive Nutzung bekannt ist – werden mit der höchsten Dringlichkeit behandelt, und ihre Behebung hat Vorrang vor allen anderen Rollouts.
Penetrationstests und Bug Bounty
Die von uns durchgeführten Penetrationstests setzen auf eine Kombination aus internem offensivem Sicherheitsteam, qualifizierten externen Penetrationstestern und einem ganzjährigen öffentlichen Bug-Bounty-Programm. Pro Jahr führen wir in der Regel acht bis zehn externe (d. h. durch Drittanbieter ausgeführte) sowie 15 bis 20 interne Penetrationstests durch. Unser Due-Diligence-Paket umfasst auch die Veröffentlichung eines extern erstellten Testberichts für die gesamte Plattform.
Wir möchten unseren Kunden helfen, Vertrauen in die Workloads zu gewinnen, die sie auf Databricks ausführen. Wenn Ihr Team einen Penetrationstest von Databricks durchführen möchte, möchten wir Sie zu folgenden Schritten ermuntern:
- Führen Sie Schwachstellenscans auf den Datenebenensystemen durch, die Ihnen von Ihrem Cloud-Anbieter bereitgestellt werden.
- Testen Sie Ihren eigenen Code. Voraussetzung hierfür ist, dass diese Tests vollständig auf die von Ihrem Cloud-Anbieter bereitgestellte Datenebene (oder andere Systeme) beschränkt sind und Sie damit Ihre eigenen Sicherheitskontrollen bewerten.
- Machen Sie beim Bug-Bounty-Programm mit.
Beteiligen Sie sich am von HackerOne unterstützten Bug-Bounty-Programm von Databricks und erhalten Sie Zugang zu einer Databricks-Installation, die nicht von Live-Kunden genutzt wird.
Interner Zugriff
Wir wenden strikte Richtlinien und Kontrollen für den Zugriff interner Mitarbeiter auf unsere Produktionssysteme, Kundenumgebungen und Kundendaten an.
Für den Zugriff auf zentrale Infrastrukturkonsolen wie die Konsolen der Cloud-Anbieter (AWS, GCP und Azure) ist eine mehrstufige Authentifizierung erforderlich. Databricks verfügt über Richtlinien und Verfahren, um die Verwendung expliziter Zugangsdaten – wie Passwörter oder API-Schlüssel – nach Möglichkeit zu vermeiden. So können beispielsweise nur benannte Sicherheitsmitglieder Ausnahmeanträge für neue AWS IAM-Prinzipale oder -Richtlinien bearbeiten.
Databricks-Mitarbeiter können nur unter ganz bestimmten Umständen auf ein Produktionssystem zugreifen. Jeder Zugriff erfordert eine Authentifizierung über ein von Databricks entwickeltes System, das den Zugriff validiert und Richtlinienprüfungen durchführt. Der Zugriff des Mitarbeiters muss über unser VPN erfolgen, und unsere Single-Sign-On-Lösung erfordert eine mehrstufige Authentifizierung.
Erfahren Sie mehr →
Unsere internen Sicherheitsstandards sehen eine Trennung der Aufgaben vor, wo immer dies möglich ist. So zentralisieren wir beispielsweise den Authentifizierungs- und Autorisierungsprozess unseres Cloud-Identitätsanbieters, um die Autorisierung des Zugriffs (Sarah soll auf ein System zugreifen) von der Gewährung des Zugriffs (Sarah darf jetzt auf ein System zugreifen) zu trennen.
Wir achten darauf, dass der Zugriff auf interne wie auch auf Produktionssysteme mit möglichst stark eingeschränkten Rechten erfolgt. Dieses Prinzip minimaler Rechte ist ausdrücklich in unseren internen Richtlinien verankert und spiegelt sich in unseren Verfahren wider. So können beispielsweise die meisten Kunden den Zugriff von Databricks-Mitarbeitern auf ihren Workspace kontrollieren. Auch führen wir vor der Gewährung des Zugriffs automatisch zahlreiche Überprüfungen durch und sperren den Zugriff nach einer bestimmten Zeit automatisch.
Erfahren Sie mehr →
Sicherer Lebenszyklus bei der Softwareentwicklung
Databricks definiert einen Softwareentwicklungs-Lebenszyklus (Software Development Lifecycle, SDLC), der Sicherheit in alle Schritte vom Pflichtenheft bis zur Produktionsüberwachung einbezieht. Zur Unterstützung setzen wir Tools ein, die ein Produktmerkmal über den gesamten Lebenszyklus im Blick behalten. Wir führen automatisch Sicherheitsscans von Systemen, Bibliotheken und Code durch und nutzen einer Erkennungsautomatik für Schwachstellen.
Databricks nutzt ein Ideenportal, das Feature-Anfragen verfolgt und Abstimmungen sowohl unter Kunden als auch unter Mitarbeitern erlaubt. Bei der Konzipierung von Features sind Datenschutz und Sicherheit standardmäßig berücksichtigt (Privacy and Security by Design). Nach einer ersten Bewertung werden Features mit erheblichen Auswirkungen von einem Sicherheitsexperten aus dem technischen Bereich einem Security Design Review unterzogen, bei dem auch Bedrohungsmodelle geprüft und weitere sicherheitsspezifische Prüfungen durchgeführt werden.
Wir verwenden eine agile Entwicklungsmethodik und unterteilen neue Funktionen in mehrere Sprints. Die Entwicklung der Databricks-Plattform erfolgt vollständig intern. Zudem müssen alle Entwickler bei der Einstellung sowie nachfolgend jedes Jahr eine Schulung zur sicheren Softwareentwicklung (einschließlich OWASP Top 10) absolvieren. Die Produktionsdaten und -umgebungen sind von den Entwicklungs-, QA- und Staging-Umgebungen getrennt. Der gesamte Code wird in ein Quellcode-Kontrollsystem eingecheckt, das Single Sign-On mit mehrstufigen Authentifizierung kombiniert und differenzierte Berechtigungen implementiert. Code-Merges erfordern die Zustimmung der funktionalen technischen Verantwortlichen des jeweiligen betroffenen Bereichs, und der gesamte Code wird einem Peer Review unterzogen.
Wir führen Qualitätsprüfungen (z. B. Unit- und End-to-End-Tests) in mehreren Phasen des SDLC-Prozesses durch, u. a. bei und nach Code-Merges sowie bei der Veröffentlichung und in der Produktion. Unsere Tests umfassen Positivtests, Regressionstests und Negativtests. Nach der Bereitstellung führen wir eine umfassende Überwachung zur Fehlererkennung durch. Nutzer können sich auf der Statusseite über die Systemverfügbarkeit informieren. Im Falle eines P0- oder P1-Problems löst die Databricks-Automatisierung eine Ursachenanalyse nach der 5-Why-Methode aus. Bei dieser wird ein Mitglied des Postmortem-Teams ausgewählt, das die Überprüfung überwacht. Alle nachfolgend ergriffenen Maßnahmen werden nachverfolgt.
Wir verwenden die branchenweit besten Tools, um gefährdete Pakete oder anfälligen Code zu erkennen. Die Automatisierung in einer Vorproduktionsumgebung führt authentifizierte Host- und Container-Schwachstellenscans des Betriebssystems und der installierten Pakete sowie dynamische und statische Codeanalysescans durch. Für alle gefundenen Sicherheitslücken werden automatisch technische Tickets erstellt und den entsprechenden Teams zugewiesen. Das Produktsicherheitsteam prüft auch kritische Schwachstellen, um ihren Schweregrad in der Databricks-Architektur zu bewerten.
Databricks verfügt über einen formellen Release-Management-Prozess, der vor der Codefreigabe eine formelle „Go/No-Go-Entscheidung“ vorsieht. Änderungen werden getestet, um Rückschritte zu vermeiden und dafür zu sorgen, dass neue Funktionen unter realistischen Arbeitsbedingungen getestet wurden. Darüber hinaus erfolgt die Einführung stufenweise und überwacht, um Probleme frühzeitig zu erkennen. Um die Aufgabentrennung umzusetzen, kann nur unser Bereitstellungsmanagementsystem Änderungen an die Produktion freigeben, und für alle Bereitstellungen sind Genehmigungen durch mehrere Personen erforderlich.
Wir folgen dem Modell der unveränderlichen Infrastruktur, bei dem Systeme ersetzt und nicht gepatcht werden, um durch Vermeidung von Konfigurationsmodifikationen für mehr Zuverlässigkeit und Sicherheit zu sorgen. Wenn neue System-Images oder neuer Anwendungscode implementiert werden, übertragen wir die Workloads auf neue Instanzen mit dem neuen Code. Dies gilt sowohl für die Steuerungs- als auch für die Datenebene (weitere Informationen zur Databricks-Architektur finden Sie im Abschnitt Sicherheitsmerkmale). Sobald der Code in die Produktion überführt ist, bestätigt ein Verifizierungsprozess, dass keine Artefakte hinzugefügt, entfernt oder verändert wurden.
Die letzte Phase des SDLC-Prozesses ist die Erstellung der Dokumentation für den Kunden. Bei Databricks wird die Dokumentation ähnlich wie der Code verwaltet und auch im selben Quellcode-Kontrollsystem gespeichert. Bedeutende Änderungen erfordern eine technische Überprüfung sowie einen Review durch das Dokumententeam – erst dann erfolgen Zusammenführung und Veröffentlichung.
Dokumentation besuchen →
| Netzwerkzugriff | Cloud | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
| Nutzer- und Gruppenadministration | Cloud | |||||||||||||||||
| ||||||||||||||||||
| Zugriffsverwaltung | Cloud | |||||||||||||||||
| ||||||||||||||||||
| Datensicherheit | Cloud | |||||||||||||||||
| ||||||||||||||||||
| Workload-Sicherheit | Cloud | |||||||||||||||||
| ||||||||||||||||||
| Audits und Protokollierung | Cloud | |||||||||||||||||
| ||||||||||||||||||
| Sicherheitsbewertungen (Compliance) | Cloud | |||||||||||||||||
| ||||||||||||||||||
*Azure Databricks gliedert sich in Azure Active Directory ein, Databricks on GCP in Google Identity. Sie können diese nicht in Databricks selbst konfigurieren, aber können Azure Active Directory bzw. Google Identity nach Bedarf einrichten.
Databricks has worked with thousands of customers to securely deploy the Databricks platform, with the security features that meet their architecture requirements. This document provides a checklist of security practices, considerations and patterns that you can apply to your deployment, learned from our enterprise engagements.
View document for AWS
The Security Overview Whitepaper is designed to provide a summary of all aspects of Databricks for security teams to quickly review.
Databricks includes documentation on how to operate our security features and best practices to help our customers deploy quickly and securely. The documentation is targeted primarily at teams that deploy or use Databricks.
Plattformarchitektur
Die Databricks Lakehouse-Architektur ist in zwei separate Ebenen aufgeteilt, um Berechtigungen zu vereinfachen, Datenduplizierung zu vermeiden und Risiken zu senken. Die Steuerungsebene ist die Verwaltungsebene, auf der Databricks die Workspace-Anwendung ausführt und Notebooks, Konfiguration und Cluster administriert. Sofern Sie sich nicht für Serverless Compute entscheiden, wird die Datenebene im Rahmen Ihres Cloud-Anbieter-Kontos ausgeführt und verarbeitet Ihre Daten, ohne sie aus Ihrem Konto zu entfernen. Sie können Databricks zum Schutz vor Datenausschleusung in Ihre Architektur einbetten. Hierzu nutzen Sie Funktionen wie kundenseitig verwaltete VPCs/VNets und Optionen für die Verwaltungskonsole, die den Export deaktivieren.
Bestimmte Daten, wie z. B. Ihre Notebooks, Konfigurationen, Protokolldateien und Nutzerinformationen, befinden sich zwar auf der Steuerungsebene, sind aber im Ruhezustand auf der Steuerungsebene verschlüsselt, und auch bei laufender Übertragung wird die Kommunikation von und zur Steuerungsebene verschlüsselt. Sie können außerdem konfigurieren, wo bestimmte Daten gespeichert werden: Sie können Ihren eigenen Metadatenspeicher für Ihre Datentabellen hosten (Hive-Metaspeicher), Abfrageergebnisse in Ihrem Cloud-Anbieter-Konto speichern und entscheiden, ob Sie die Databricks Secrets-API verwenden möchten.
Angenommen, ein Data Engineer meldet sich bei Databricks an und schreibt ein Notebook, das Rohdaten in Kafka in einen normalisierten Datensatz umwandelt, der an einen Speicher wie Amazon S3 oder Azure Data Lake Storage gesendet wird. Der gesamte Vorgang umfasst sechs Schritte:
- Der Data Engineer authentifiziert sich nahtlos – auf Wunsch auch über Ihr Single Sign-On – bei der Databricks-Web-UI auf der im Databricks-Konto gehosteten Steuerungsebene.
- Wenn der Data Engineer Code schreibt, sendet sein Webbrowser diesen an die Steuerungsebene. JDBC-/ODBC-Anfragen folgen demselben Weg und werden bei einem Token authentifiziert.
- Zum erforderlichen Zeitpunkt die Steuerungsebene die APIs des Cloud-Anbieters, um einen Databricks-Cluster aus neuen Instanzen in der Datenebene in Ihrem Cloud-Anbieter-Konto zu erstellen. Administratoren können zum Erzwingen von Sicherheitsprofilen Cluster-Richtlinien anwenden.
- Sobald die Instanzen gestartet sind, sendet der Cluster-Manager den Code des Data Engineers an den Cluster.
- Der Cluster ruft die Daten aus Kafka in Ihrem Konto ab, wandelt sie in Ihrem Konto um und schreibt sie dann in einen Speicher in Ihrem Konto.
- Der Cluster meldet den Status und alle Ergebnisse an den Cluster-Manager zurück.
Der Data Engineer muss sich nicht um allzu viele Details kümmern: Er schreibt einfach den Code und Databricks führt ihn aus.
Compliance
Kunden weltweit vertrauen uns ihre sensibelsten Daten an. Databricks implementiert Kontrollen, um auch die speziellen Anforderungen stark regulierter Branchen zu erfüllen.
Due-Diligence-Paket
Für Self-Service-Sicherheitsüberprüfungen können Sie unser Due-Diligence-Paket herunterladen. Es umfasst allgemeine Konformitätsdokumente wie unsere ISO-Zertifizierungen und den Nachweisbericht zu unserem jährlichen Penetrationstest. Über Ihr Databricks-Kundenteam können Sie außerdem Kopien unseres Leitfadens für Unternehmenssicherheit und unseres SOC 2-Type-II-Berichts beziehen.
HerunterladenZertifizierungen und Normen
Überblick
Databricks nimmt den Datenschutz ernst. Uns ist bewusst, dass die Daten, die Sie mit Databricks analysieren, sowohl für Ihr Unternehmen als auch für Ihre Kunden wichtig sind und im Zweifelsfall einer Vielzahl von Datenschutzgesetzen und -vorschriften unterliegen.
Damit Sie besser verstehen, wie Databricks dem für Sie geltenden Rechtsrahmen entspricht, haben wir häufig gestellte Fragen zum Datenschutz sowie Dokumente vorbereitet, die transparent darlegen, wie Databricks das Thema Datenschutz angeht.
Hilfe bei der Untersuchung eines Sicherheitsvorfalls in Ihrem Databricks-Workspace
Wenn Sie den Verdacht haben, dass Ihre Workspace-Daten manipuliert wurden oder Sie Unstimmigkeiten oder Unrichtigkeiten in Ihren Daten erkannt haben, melden Sie dies bitte unverzüglich an Databricks.
Melden von Spam oder verdächtigen Mitteilungen, die von Databricks stammen
Wenn Sie Spam oder Mitteilungen erhalten, von denen Sie annehmen, dass sie in betrügerischer Absicht versandt wurden, oder die unangemessene oder unzulässige Inhalte oder Malware enthalten, wenden Sie sich bitte unverzüglich an Databricks.
Bericht eines internen Sicherheitslückenscans für ein Databricks-Produkt interpretieren
Wenn Sie Hilfe bei der Analyse eines Berichts zu einem Sicherheitslückenscan benötigen, stellen Sie bitte über Ihren Databricks-Supportkanal eine Support-Anfrage und übermitteln Sie dabei Ihre Produktversion, ggf. Angaben zu Ihrer spezifischen Konfiguration und die konkrete Berichtsausgabe und beschreiben Sie, wie der Scan durchgeführt wurde.
Auswirkungen einer CVE auf einen Databricks-Workspace oder eine Laufzeit verstehen
Wenn Sie Informationen zu den Auswirkungen einer CVE (Common Vulnerability and Exposure) eines Drittanbieters oder einer Databricks-CVE benötigen, stellen Sie bitte über Ihren Databricks-Supportkanal eine Supportanfrage und geben Sie die CVE-Beschreibung, den Schweregrad und die in der US-amerikanischen National Vulnerability Database gefundenen Referenzen an.
Fehler in Produkten oder bei Services von Databricks melden
Wenn Sie in einem unserer Produkte eine reproduzierbare Sicherheitslücke gefunden haben, bitten wir um Mitteilung, um sie zu beheben. Außerdem würden wir uns über Ihre Teilnahme an unserem von HackerOne unterstützten öffentlichen Bug-Bounty-Programm freuen.
HIPAA
HIPAA ist eine US-Verordnung, die eine Reihe von Schutzmaßnahmen für geschützte Gesundheitsdaten umfasst. Databricks bietet HIPAA-konforme Bereitstellungsoptionen.
Unterstützte Clouds
