Security & Trust Center

Ihre Datensicherheit ist unsere Priorität

Hintergrundbild

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.

Mit unserem Due-Diligence-Paket, das Dokumentations- und Compliance-Materialien enthält, führen Sie Sicherheitsüberprüfungen von Databricks selbst durch.
Accenture
Wehkamp Logo
Wehkamp Logo
„Dank der vereinfachten Administration und Governance der Databricks-Plattform können unsere Teams im gesamten Unternehmen nun datenbasierte Entscheidungen treffen. Das unkomplizierte Hinzufügen von Nutzern, die nativen Sicherheitsintegrationen mit Cloud-Anbietern und APIs, die alles Denkbare möglich machen, ermöglichen es uns, jedem Mitarbeiter bei Wehkamp die jeweils erforderlichen Daten und Tools zur Verfügung zu stellen.“

– Tom Mulder, Lead Data Scientist bei Wehkamp

Adren Street Labs
Wehkamp Logo
Wehkamp Logo
„Die knapp ein Dutzend Lösungen, die wir entwickelt haben, setzen alle auf Azure Databricks als zentraler Grundlage auf. So konnten wir ein schnelles Lab-to-Operations-Implementierungsmuster nutzen und gleichzeitig Datensicherheit und Skalierbarkeit der Berechnungen gewährleisten.“

– Jeff Feldman, CTO von Arden Street Labs

Credit Suisse
Wehkamp Logo
Wehkamp Logo
„Trotz der steigenden Akzeptanz von Big Data und KI sehen sich die meisten Finanzdienstleister immer noch mit erheblichen Herausforderungen bei Datentypen, Datenschutz und Umfang konfrontiert. Die Crédit Suisse überwindet diese Hindernisse durch Standardisierung offener und Cloud-basierter Plattformen wie Azure Databricks und erhöht so Geschwindigkeit und Umfang von Operationen und ML im gesamten Unternehmen.“

— Credit Suise case study

Hintergrundbild

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

Beyond the documentation and best practices you will find on our Security and Trust Center, we also provide a contractual commitment to security to all our customers. This commitment is captured in the Security Addendum, which is part of our customer agreement. The Security Addendum describes in clear language a list of security measures and practices we follow to keep your data safe.

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 →

Hintergrundbild
Netzwerkzugriff Cloud

Option to deploy into a VPC/VNet that you manage and secure. By default there are no inbound network connections to the data plane.

AWS, Azure

Privater Zugang (oder privater Link) von Nutzern oder Clients zu Benutzeroberfläche und APIs der Databricks-Steuerungsebene

AWS, Azure

Privater Zugang (oder privater Link) von der klassischen Datenebene zur Databricks-Steuerungsebene

AWS, Azure

Privater Zugang (oder privater Link) von der klassischen Datenebene zu Daten auf der Cloud-Plattform

AWS, Azure

IP-Zugriffslisten zur Steuerung des Zugriffs auf Benutzeroberfläche und APIs der Databricks-Steuerungsebene

AWS, Azure, GCP

Automatische hostbasierte Firewalls, die die Kommunikation beschränken

AWS, Azure, GCP

Nutzer- und Gruppenadministration Cloud

Nutzung des Identitätsmanagements des Cloud-Anbieters für eine nahtlose Integration mit Cloud-Ressourcen

AWS, Azure, GCP

Unterstützung der Azure Active Directory-Richtlinie für bedingten Zugriff

Azure (nicht verfügbar bei AWS und GCP)

SCIM-Bereitstellung zum Verwalten von Nutzeridentitäten und -gruppen

AWS, Azure, GCP

Single Sign-On mit Identitätsanbieterintegration (MFA kann über den Identitätsanbieter aktiviert werden)

AWS (nicht verfügbar bei Azure und GCP*)

Serviceprinzipale oder -konten zum Verwalten von Anwendungsidentitäten für die Automatisierung

AWS, Azure, GCP

Sperrung von Nutzerkonten, um den Zugang eines Nutzers zu Databricks vorübergehend zu unterbinden

AWS (nicht verfügbar bei Azure und GCP*)

Deaktivieren lokaler Passwörter mit Passwortberechtigung

AWS (nicht verfügbar bei Azure und GCP*)

Zugriffsverwaltung Cloud

Fine-grained permission based access control to all Databricks objects including workspaces, jobs, notebooks, SQL

AWS, Azure, GCP

Sicherer API-Zugang mit persönlichen Zugangstoken und Berechtigungsverwaltung

AWS, Azure, GCP

Unterstützung von OAuth-Token

Azure, GCP

Segmentierung von Anwendern, Workloads und Daten mit unterschiedlichen Sicherheitsprofilen in mehreren Arbeitsbereichen

AWS, Azure, GCP

Datensicherheit Cloud

Verschlüsselung ruhender Daten auf der Steuerungsebene

AWS, Azure, GCP

Verschlüsselung mit kundenseitig verwalteten Schlüsseln verfügbar

AWS, Azure

Verschlüsselung der gesamten Kommunikation zwischen Steuerungs- und Datenebene bei laufender Übertragung

AWS, Azure, GCP

Intra-cluster Spark encryption in transit or platform-optimized encryption in transit

AWS, Azure

Differenziert konfigurierbare Datensicherheit und Maskierung mit dynamischen Sichten

AWS, Azure, GCP

Administrationsfunktionen zur Begrenzung des Risikos der Datenausschleusung

AWS, Azure, GCP

Data governance Cloud

Differenziert konfigurierbare Datenverwaltung mit Unity Catalog

AWS, Azure

Centralized metadata and user management with Unity Catalog

AWS, Azure

Centralized data access controls with Unity Catalog

AWS, Azure

Data lineage with Unity Catalog

Preview on AWS and Azure

Data access auditing with Unity Catalog

AWS, Azure

Secure data sharing with Delta Sharing

AWS, Azure

Workload-Sicherheit Cloud

Effizientes Verwalten von Codeversionen mit Repositorys

AWSAzureGCP

Integrierte Geheimnisverwaltung zur Vermeidung der Eincodierung von Zugangsdaten in den Code

AWSAzureGCP

Verwaltetes Image für das Datenebenensystem, wird regelmäßig mit Patches, Sicherheitsscans und Basishärtung aktualisiert

AWS, Azure (GCP not applicable)

Kosteneindämmung sowie Vollzug von Sicherheits- und Validierungsanforderungen mit Cluster-Richtlinien

AWSAzureGCP

Unveränderliche und kurzlebige Infrastruktur zur Vermeidung von Konfigurationsmodifikationen

AWSAzureGCP

Audits und Protokollierung Cloud

Umfassende und konfigurierbare Audit-Protokollierung der Aktivitäten von Databricks-Nutzern

AWSAzureGCP

Protokollierung des Databricks SQL-Befehlsverlaufs

AWSAzure

Protokollierung von Databricks-Clustern

AWSAzure

Sicherheitsbewertungen (Compliance) Cloud

Erfüllt die Anforderungen von ISO 27001, 27017 und 27018

AWS, Azure, GCP

SOC 2-Type-II-Bericht verfügbar

AWS, Azure, GCP

Einhaltung von DSGVO und CCPA

AWS, Azure, GCP

PCI DSS-konforme Implementierungen

AWS (nur Single-Tenant)

Einhaltung von FedRAMP Moderate

AWSAzure

Einhaltung von FedRAMP High

Azure

HIPAA-konforme Implementierungen

AWSAzure

HITRUST

Azure

*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.

Security Best Practices

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 and GCP

Security Analysis Tool

Security Workspace Analysis Tool (SAT) monitors your workspace hardening by reviewing the deployments against our security best practices. It programmatically verifies workspaces using standard API calls and reports deviations by severity, with links that explain how to improve your security.

View blog for more detail, and GitHub to get started.
(Currently available for AWS)

Databricks Security Documentation

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.

Access documentation for AWS, GCP or Azure

Databricks Security and Trust Overview Whitepaper

The Security Overview Whitepaper is designed to provide a summary of all aspects of Databricks for security teams to quickly review.

View document

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:

  1. 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.
  2. 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.
  3. 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.
  4. Sobald die Instanzen gestartet sind, sendet der Cluster-Manager den Code des Data Engineers an den Cluster.
  5. 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.
  6. 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.

Herunterladen

Zertifizierungen und Normen

Hintergrundbild

Ü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.

Hintergrundbild

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.

Hintergrundbild

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

Regionen

Azure Multi-Tenant (alle Regionen)

AWS Single Tenant (alle Regionen)

AWS Multi-Tenant (USA (Ost) 1, USA (Ost) 2, Kanada (Zentral) 1, USA (West) 2)