Direkt zum Hauptinhalt

Sicherheits- und Vertrauenscenter

Ihre Datensicherheit ist unsere Priorität

 

 

trust-image-new-header

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. Wir haben Angebote für PCI-DSS-, HIPAA- und FedRAMP-Compliance und sind konform mit ISO 27001, ISO 27017, ISO 27018 und SOC 2 Typ II.

Vertragliche Verpflichtung

Neben der Dokumentation und Best Practices, die Sie in unserem Security and Trust Center finden, verpflichten wir uns auch vertraglich zur Sicherheit für alle unsere Kunden. Diese Verpflichtung ist im Sicherheitszusatz unserer Kundenvereinbarung festgehalten. Er beschreibt mit einfachen Worten die Sicherheitsmaßnahmen und -praktiken, die wir befolgen, um Ihre Daten zu schützen.

Schwachstellenmanagement

Das Aufspüren und schnelle Beheben von Schwachstellen in der Software gehört zu den wichtigsten Aufgaben jedes Softwareanbieters und Dienstleisters. Wir nehmen diese Verantwortung ernst und teilen unsere Behebungsfristen in unserem Sicherheitszusatz mit.

Intern verfügen wir über ein automatisiertes Schwachstellenmanagement, um Schwachstellen in unserer Umgebung effektiv zu verfolgen, zu priorisieren, zu koordinieren und zu beheben. Wir führen täglich authentifizierte Schwachstellenscans von Databricks und Drittanbieter-/Open-Source-Paketen durch, die von Databricks verwendet werden. Außerdem führen wir statische und dynamische Codeanalysen (SAST und DAST) mit vertrauenswürdigen Sicherheits-Scan-Tools durch, bevor wir neuen Code oder Images in die Produktion überführen. Databricks beschäftigt auch externe Experten, um unsere öffentlich zugänglichen Websites zu analysieren und potenzielle Risiken zu melden.

Databricks hat ein Programm zur Reaktion auf Schwachstellen finanziert, um aufkommende Schwachstellen zu überwachen, bevor sie uns von unseren Scanning-Anbietern gemeldet werden. Wir erreichen dies mithilfe interner Tools, sozialer Medien, Mailinglisten und Quellen für Bedrohungsinformationen (z. B. US-CERT und andere Behörden-, Branchen- und Open-Source-Feeds). Databricks überwacht offene Schwachstellenplattformen wie CVE Trends und Open CVDB. Wir haben einen etablierten Prozess, um darauf zu reagieren, damit wir die Auswirkungen auf unser Unternehmen, unser Produkt oder unsere Kunden schnell erkennen können. Mit diesem Programm können wir gemeldete Schwachstellen schnell reproduzieren und Zero-Day-Schwachstellen beheben.

Unser Schwachstellenmanagement-Programm ist darauf ausgerichtet, Schwachstellen des Schweregrads 0, z. B. Zero Days, mit höchster Dringlichkeit zu behandeln und deren Behebung Vorrang vor anderen Rollouts zu geben.

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. Wir verwenden eine Mischung aus Fuzzing, sicherer Codeüberprüfung und dynamischen Anwendungstests, um die Integrität unserer Plattform und die Sicherheit unserer Anwendung zu bewerten. Wir führen Penetrationstests von Hauptversionen, neuen Diensten und sicherheitsrelevanten Funktionen durch. Das offensive Sicherheitsteam arbeitet mit unserem Vorfallreaktionsteam und Sicherheitsexperten im Engineering zusammen, um erkannte Probleme aufzuklären und Erkenntnisse im gesamten Unternehmen zu verbreiten.

Wir führen in der Regel 8–10 externe Penetrationstests von Drittanbietern und 15–20 interne Penetrationstests pro Jahr durch. Bevor ein Test als bestanden gewertet werden kann, müssen alle wesentlichen Feststellungen angegangen werden. Als Teil unseres Transparenzansatzes teilen wir unseren plattformweiten Testbericht von Drittanbietern öffentlich in unserem Due-Diligence-Paket.

Unser öffentliches Bug-Bounty-Programm, das von HackerOne unterstützt wird, ermöglicht es einem globalen Kollektiv von Cybersicherheitsforschern und Penetrationstestern, Databricks auf Sicherheitslücken zu testen. Einige der wichtigsten Entscheidungen, die wir getroffen haben, um das Programm erfolgreich zu machen, sind:

  • Einbindung einer engagierten Hacker-Community, an unserem Programm teilzunehmen, indem wir unsere HackerOne-Programmstatistiken wie Rücklaufquote und Auszahlungen transparent machen
  • Sofortiges Reagieren auf Bug-Bounty-Übermittlungen mit einer durchschnittlichen Time-to-Bounty von weniger als einer Woche
  • Durchführen einer Variantenanalyse für jede gültige Einreichung, um alternative Möglichkeiten zu identifizieren, wie die Ausnutzung einer Schwachstelle verwendet werden könnte, und Verifizieren von 100 % der Problembehebungen
  • Hinzufügen von Boni, die die Aufmerksamkeit auf die wichtigsten Bereiche des Produkts lenken

Wir arbeiten hart daran, unser Programm erfolgreich zu machen und aus jeder Einreichung zu lernen. Unser offener und kooperativer Ansatz des Bug Bounty-Programms hat dazu geführt, dass über 100 Sicherheitsforscher für mehr als 200 Berichte belohnt wurden. Vielen Dank an alle, die uns dabei helfen, Databricks sicher zu halten!

Wir möchten, dass unsere Kunden Vertrauen in die Workloads haben, die sie auf Databricks ausführen. Wenn Ihr Team einen Schwachstellenscan oder Penetrationstest von Databricks durchführen möchte, empfehlen wir Ihnen Folgendes:

  1. Führen Sie Schwachstellenscans auf den Datenebenensystemen durch, die Ihnen von Ihrem Cloud-Anbieter bereitgestellt werden.
  2. Testen Sie Ihren 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 Sicherheitskontrollen bewerten.
  3. Nehmen Sie am Databricks Bug Bounty-Programm teil, um auf eine dedizierte Bereitstellung von Databricks zuzugreifen, die für Penetrationstests genutzt werden kann. Jeder Penetrationstest unserer mandantenfähigen Steuerungsebene erfordert die Teilnahme am Programm.

Sicherheitsuntersuchungen und Reaktionen auf Vorfälle

Wir verwenden Databricks als unsere SIEM- und XDR-Plattform, um über 9 Terabyte an Daten pro Tag für Erkennungs- und Sicherheitsuntersuchungen zu verarbeiten. Wir erfassen und verarbeiten Protokolle und Sicherheitssignale von Cloud-Infrastrukturen, Geräten, Identitätsverwaltungssystemen und SaaS-Anwendungen. Wir verwenden strukturierte Streaming-Pipelines und Delta-Live-Tables, um die relevantesten Sicherheitsereignisse mithilfe eines datengesteuerten Ansatzes und statistischer ML-Modelle zu identifizieren. Diese Ereignisse dienen dann dazu, neuartige Warnungen zu generieren oder bestehende Warnungen von bekannten Sicherheitsprodukten zu korrelieren, zu deduplizieren und zu priorisieren. Wir modellieren unsere Runbooks auf der Grundlage von Taktiken, Techniken und Verfahren (Tactics, Techniques and Procedures, TTP) des Gegners, die mit Hilfe des Frameworks MITRE ATT&CK verfolgt werden. Unser Team für Sicherheitsuntersuchungen verwendet kollaborative Databricks-Notebooks, um wiederholbare Untersuchungsprozesse zu erstellen, Playbooks zur Untersuchung von Vorfällen kontinuierlich weiterzuentwickeln und eine Bedrohungssuche anhand von mehr als 2 Petabyte historischer Ereignisprotokolle durchzuführen, wobei komplexe Suchen in unstrukturierten und halbstrukturierten Daten durchgeführt werden.

Unser Vorfallreaktionsteam bleibt auf dem Laufenden und unterstützt Databricks bei der Vorbereitung auf Vorfallmanagementszenarien durch:

  • Teilnahme an branchenweit anerkannten Kursen von Anbietern wie SANS und Teilnahme an Sicherheitskonferenzen wie fwd:cloudsec, Black Hat, BSides, RSA
  • Durchführung regelmäßiger Tabletop-Übungen mit Führungskräften und internen Teams, um Sicherheitsreaktionsszenarien zu üben, die für Databricks-Produkte und die Unternehmensinfrastruktur relevant sind
  • Zusammenarbeit mit Engineering-Teams zur Priorisierung der Plattformbeobachtbarkeit, um eine effektive Sicherheitserkennung und -reaktion zu ermöglichen
  • Regelmäßige Aktualisierung von Einstellungs- und Schulungsstrategien auf der Grundlage einer sich entwickelnden Kompetenz- und Fähigkeitsmatrix für Vorfallreaktionen

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 unter ganz bestimmten Umständen (z. B. Notfall-Break-Fix) auf das Produktionssystem zugreifen. Der Zugriff wird durch ein von Databricks erstelltes System geregelt, das den Zugriff validiert und Richtlinienüberprüfungen durchführt. Für den Zugriff müssen die Mitarbeiter mit unserem VPN verbunden sein und sich über unsere Single-Sign-On-Lösung mit Multifaktor-Authentifizierung authentifizieren.
Weitere Informationen →

Unsere internen Sicherheitsstandards fordern, wo immer möglich, eine Aufgabentrennung. 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 der geringsten 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.
Weitere Informationen →

Sicherer Lebenszyklus bei der Softwareentwicklung

Databricks definiert einen Software-Entwicklungszyklus (Software Development Lifecycle, SDLC), der Sicherheit in alle Entwurfs-, Entwicklungs- und Produktionsschritte 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 verfügen über automatische Sicherheitsscans und eine automatisierte Schwachstellenverfolgung von Systemen, Bibliotheken und Code.

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 High-Impact-Features einer Überprüfung des Sicherheitsdesigns durch das Produktsicherheitsteam in Zusammenarbeit mit den Sicherheitsexperten der Engineering-Abteilung unterzogen. Dies umfasst auch Thread Modeling und andere sicherheitsspezifische Prüfungen.

Wir verwenden eine agile Entwicklungsmethodik, die neue Features in mehrere Sprints unterteilt. 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 eingepflegt, 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. Das Produktsicherheitsteam überprüft sicherheitsrelevanten Code manuell, um Fehler in der Geschäftslogik zu beseitigen.

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.

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 „5-Warum“-Methodik zur Ursachenanalyse aus. Daraufhin wird ein Mitglied des Post-Mortem-Teams ausgewählt, um die Überprüfung zu überwachen. Die Ergebnisse werden der Geschäftsführung mitgeteilt und Folgemaßnahmen werden überprüft.

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 gibt es einen gestaffelten Rollout mit Monitoring, 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 Sicherheitsfeatures). Sobald der Code in die Produktion überführt ist, bestätigt ein Verifizierungsprozess, dass keine Artefakte ohne Autorisierung 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 eine Überprüfung durch das Dokumententeam – erst dann erfolgen Zusammenführung und Veröffentlichung.
Dokumentation ansehen →

Sicherheitsrichtlinie und Kommunikationsdetails

Databricks befolgt die Standards RFC 9116, ISO/IEC 30111:2019(E) und ISO/IEC 29147:2018(E) für die Behandlung und Kommunikation von Sicherheitsschwachstellen. Einzelheiten zu unserer sicheren Kommunikation und PGP-Signatur finden Sie in unserer Datei security.txt.