Security and Trust Center

La sicurezza dei tuoi dati è la nostra priorità

immagine sfondo

Sappiamo che i dati sono una delle risorse più preziose e devono essere sempre protetti: per questo la sicurezza viene integrata in ogni livello della Databricks Lakehouse Platform. La nostra trasparenza consente di rispettare le normative, sfruttando nel contempo i vantaggi della piattaforma.

Esegui autonomamente una verifica di sicurezza di Databricks utilizzando il nostro pacchetto di due diligence, che comprende documentazione e materiali di conformità.
Wehkamp Logo
Wehkamp Logo
“Grazie a un'amministrazione e una governance semplificate, la piattaforma Databricks ci ha consentito di portare nei nostri team, in tutta l'organizzazione, processi decisionali basati sui dati. La facilità con cui si possono aggiungere utenti, le integrazioni di sicurezza native con i fornitori cloud e le "API per tutto" ci consentono di mettere a disposizione di ogni addetto di Wehkamp i dati e gli strumenti necessari”.

— Tom Mulder, Lead Data Scientist in Wehkamp

Adren Street Labs
Wehkamp Logo
Wehkamp Logo
“Abbiamo sviluppato quasi una dozzina di soluzioni, tutte basate su Azure Databricks come piattaforma principale. Questo ci ha consentito di sfruttare uno scherma di implementazione rapida "Lab to Operations", mantenendo al tempo stesso la sicurezza dei dati e la scalabilità di calcolo”.

— Jeff Feldman, CTO di Arden Street Labs

Credit Suisse
Wehkamp Logo
Wehkamp Logo
"Nonostante la progressiva convergenza fra Big Data e AI, la maggior parte delle società di servizi finanziari vive ancora grandi difficoltà con i dati in termini di tipologia, protezione e volumi. Credit Suisse sta superando questi ostacoli standardizzando l'attività su piattaforme aperte in cloud, fra cui Azure Databricks, per aumentare la velocità e la portata delle attività operative e del ML su tutta l'organizzazione".

— Credit Suise case study

immagine sfondo


Our trusted platform is built by embedding security throughout the software development and delivery lifecycle. We follow rigorous operational security practices such as penetration testing, vulnerability assessments and strong internal access controls. We believe transparency is the key to winning trust — we publicly share how we operate, and work closely with our customers and partners to address their security needs. We have offerings for PCI-DSS, HIPAA and FedRAMP compliance, and we are ISO 27001, ISO 27017, ISO 27018 and SOC 2 Type II compliant.

Impegno contrattuale

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

Gestione della vulnerabilità

Detecting and quickly fixing vulnerable software that you rely on is among the most important responsibilities of any software or service provider. We take this responsibility seriously and share our remediation timeline commitments in our Security Addendum.

Internally, we have automated vulnerability management to effectively track, prioritize, coordinate and remediate vulnerabilities in our environment. We perform daily authenticated vulnerability scans of Databricks and third-party/open-source packages used by Databricks, along with static and dynamic code analysis (SAST and DAST) using trusted security scanning tools, before we promote new code or images to production. Databricks also employs third-party experts to analyze our public-facing sites and report potential risks.

Databricks has funded a Vulnerability Response Program for monitoring emerging vulnerabilities before they’re reported to us by our scanning vendors. We accomplish this using internal tools, social media, mailing lists and threat intelligence sources (e.g., US-CERT and other government, industry and open-source feeds). Databricks monitors open vulnerability platforms, such as CVE Trends and Open CVDB. We have an established process for responding to these so we can quickly identify the impact on our company, product or customers. This program allows us to quickly reproduce reported vulnerabilities and resolve zero-day vulnerabilities.

Our Vulnerability Management Program is committed to treating Severity-0 vulnerabilities, such as zero days, with the highest urgency, prioritizing their fix above other rollouts.

Test di penetrazione e Bug Bounty

We perform penetration testing through a combination of our in-house offensive security team, qualified third-party penetration testers and a year-round public bug bounty program. We use a mixture of fuzzing, secure code review and dynamic application testing to evaluate the integrity of our platform and the security of our application. We conduct penetration tests on major releases, new services and security-sensitive features. The offensive security team works with our incident response team and security champions within engineering to resolve findings and infuse learnings throughout the company.

We typically perform 8-10 external third-party penetration tests and 15-20 internal penetration tests per year, and all material findings must be addressed before a test can be marked as passed. As part of our commitment to transparency, we publicly share our platform-wide third-party test report in our due diligence package.

Our public bug bounty program, facilitated by HackerOne, allows a global collective of cybersecurity researchers and penetration testers to test Databricks for security vulnerabilities. Some of the key decisions we’ve made to make the program successful include:

  • Encouraging an engaged community of hackers to be active on our program by providing transparency to our HackerOne program statistics such as response rate and payouts
  • Promptly responding to bug bounty submissions, with an average time-to-bounty under a week
  • Performing variant analysis on every valid submission to identify alternative ways that an exploit may be used, and verifying 100% of fixes
  • Adding bonuses that drive attention to the most important areas of the product

We work hard to make our program successful and to learn from each submission. Our open and collaborative approach to our bug bounty program has resulted in over 100 security researchers being thanked for over 200 reports. Thank you all for helping us keep Databricks secure!

We want our customers to have confidence in the workloads they run on Databricks. If your team would like to run a vulnerability scan or penetration test against Databricks, we encourage you to:

  1. Run vulnerability scans on data plane systems located inside of your cloud service provider account.
  2. Run tests against your code, provided that those tests are entirely contained within the data plane (or other systems) located in your cloud service provider account and are evaluating your controls.
  3. Join the Databricks Bug Bounty program to access a dedicated deployment of Databricks to perform penetration tests. Any penetration test against our multi-tenant control plane requires participation in the program.

Security investigations and incident response

We use Databricks as our SIEM and XDR platform to process over 9 terabytes of data per day for detection and security investigations. We ingest and process logs and security signals from cloud infrastructure, devices, identity management systems, and SaaS applications. We use structured streaming pipelines and Delta Live Tables to identify the most relevant security events using a data-driven approach and statistical ML models to generate novel alerts, or to correlate, de-duplicate and prioritize existing alerts from known security products. We model our runbooks on adversary tactics, techniques and procedures (TTP) tracked using the MITRE ATT&CK framework. Our security investigations team uses collaborative Databricks notebooks to create repeatable investigation processes, continually evolve incident investigation playbooks, and perform threat hunting against more than 2 petabytes of historic event logs handling complex searches over unstructured and semi-structured data.

Our incident response team stays up to date and helps Databricks prepare for incident management scenarios by:

  • Participating in industry-reputed courses from vendors like SANS and attending security conferences like fwd:cloudsec, Black Hat, BSides, RSA
  • Performing regular tabletop exercises with executive leadership and internal teams to practice security response scenarios relevant to Databricks products and corporate infrastructure
  • Collaborating with engineering teams to prioritize platform observability to allow effective security detection and response
  • Regularly updating hiring and training strategies based on an evolving incident response skills and capabilities matrix

Accesso interno

Applichiamo politiche e controlli rigorosi sull'accesso dei nostri dipendenti ai nostri sistemi di produzione, agli ambienti e ai dati dei clienti.

We require multifactor authentication to access core infrastructure consoles such as the cloud service provider consoles (AWS, GCP and Azure). Databricks has policies and procedures to avoid the use of explicit credentials, such as passwords or API keys, wherever possible. For example, only appointed security team members can process exception requests for new AWS IAM principals or policies.

Databricks employees can access the production system under very specific circumstances (such as emergency break-fix). Access is governed by a Databricks-built system that validates access and performs policy checks. Access requires that employees are connected to our VPN, and authenticate using our single sign-on solution with multifactor authentication.
Learn more →

Our internal security standards call for the separation of duties wherever possible. For example, we centralize our cloud identity provider’s authentication and authorization process to separate authorizing access (Mary should access a system) from granting access (Mary can now access a system).

We prioritize least privilege access, both in internal systems and for our access to production systems. Least privilege is explicitly built into our internal policies and reflected in our procedures. For example, most customers can control whether Databricks employees have access to their workspace, and we programmatically apply numerous checks before access can be granted and automatically revoke access after a limited time.
Learn more →

Ciclo di sviluppo sicuro del software

Databricks has a software development lifecycle (SDLC) that builds security into all design, development and production steps — from feature requests to production monitoring — supported by tooling designed to trace a feature through the lifecycle. We have automatic security scanning and automated vulnerability tracking of systems, libraries and code.

Databricks leverages an Ideas Portal that tracks feature requests and allows voting both for customers and employees. Our feature design process includes privacy and security by design. After an initial assessment, high-impact features are subject to a security design review from the product security team in association with the security champions from engineering, along with threat modeling and other security-specific checks.

We use an agile development methodology that breaks up new features into multiple sprints. Databricks does not outsource the development of the Databricks platform, and all developers are required to go through secure software development training — including the OWASP Top 10 — when hired and annually thereafter. Production data and environments are separated from development, QA and staging environments. All code is checked into a source control system that requires single sign-on with multifactor authentication and granular permissions. Code merges require approval from the functional engineering owners of each area impacted, and all code is peer reviewed. The product security team manually reviews security-sensitive code to eliminate business logic errors.

Utilizziamo gli strumenti migliori della categoria per individuare pacchetti o codice vulnerabili. L'automazione in un ambiente di produzione esegue scansioni di vulnerabilità del sistema operativo su host e contenitore autenticati e pacchetti installati, oltre a scansioni di analisi del codice dinamico e statico. Vengono creati automaticamente ticket di progettazione per qualsiasi vulnerabilità, assegnandoli ai team di competenza. Il team di sicurezza del prodotto classifica inoltre le vulnerabilità critiche per valutarne la gravità nell'architettura Databricks.

We run quality checks (such as unit tests and end-to-end tests) at multiple stages of the SDLC process, including at code merge, after code merge, at release and in production. Our testing includes positive tests, regression tests and negative tests. Once deployed, we have extensive monitoring to identify faults, and users can get alerts about system availability via the Status Page. In the event of any P0 or P1 issue, Databricks automation triggers a “5 whys” root cause analysis methodology that selects a member of the postmortem team to oversee the review. Findings are communicated to executive leadership, and follow-up items are tracked.

Databricks has a formal release management process that includes a formal go/no-go decision before releasing code. Changes go through testing designed to avoid regressions and validate that new functionality has been tested on realistic workloads. Additionally, there is a staged rollout with monitoring to identify issues early. To implement separation of duties, only our deployment management system can release changes to production, and multiperson approval is required for all deployments.

We follow an immutable infrastructure model, where systems are replaced rather than patched to improve reliability and security and to avoid the risk of configuration drift. When new system images or application code is launched, we transfer workloads to new instances that launch with the new code. This is true both for the control plane and the data plane (see the Security Features section for more on the Databricks architecture). Once code is in production, a verification process confirms that artifacts are not added, removed or changed without authorization.

The final phase of the SDLC process is creating customer-facing documentation. Databricks docs are managed much like our source code, and documentation is stored within the same source control system. Significant changes require both technical and docs team review before they can be merged and published.
Visit documentation →

Security Policy and Communication Details

Databricks follows RFC 9116, ISO/IEC 30111:2019(E), and ISO/IEC 29147:2018(E) standards for security vulnerability handling and communications. For details on our secure communications and PGP signature, please refer to our security.txt file.

immagine sfondo
Accesso di rete 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

Accesso privato (o link privato) di utenti o client all'interfaccia e alle API del control plane di Databricks

AWS, Azure

Accesso privato (o link privato) dal data plane classico al control plane di Databricks

AWS, Azure

Accesso privato (o link privato) dal data plane classico ai dati sulla piattaforma cloud

AWS, Azure

Liste di accessi IP per controllare gli accessi all'interfaccia e alle API del control plane di Databricks via Internet

AWS, Azure, GCP

Firewall automatici basati su host che limitano la comunicazione

AWS, Azure, GCP

Amministrazione di utenti e gruppi Cloud

La gestione delle identità del fornitore di servizi cloud consente l'integrazione diretta con le risorse cloud

AWS, Azure, GCP

Supporto per le politiche di accesso condizionale alla Active Directory di Azure

Azure (non si applica ad AWS / GCP)

Provisioning SCIM per gestire identità di utenti e gruppi

AWS, Azure, GCP

Single Sign-On con integrazione del fornitore di identità (si può abilitare MFA tramite il fornitore di identità)

AWS (non si applica ad Azure/GCP*)

Principal o account di servizio per gestire identità di applicazione per l'automazione

AWS, Azure, GCP

Blocco dell'account utente per disabilitare temporaneamente l'accesso di un utente a Databricks

AWS (non si applica ad Azure/GCP*)

Disabilitazione di password locali con il permesso delle password

AWS (non si applica ad Azure/GCP*)

Gestione degli accessi Cloud

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

AWS, Azure, GCP

Accesso sicuro alle API con token di accesso personale con gestione dei permessi

AWS, Azure, GCP

Supporto di token OAuth

Azure, GCP

Segmentazione di utenti, carichi di lavoro e dati con diversi profili di sicurezza in molteplici spazi di lavoro

AWS, Azure, GCP

Sicurezza dei dati Cloud

Crittografia dei dati del control plane a riposo

AWS, Azure, GCP

Possibilità di realizzare una crittografia delle chiavi gestita dal cliente

AWS, Azure

Crittografia in transito di tutte le comunicazioni fra control plane e data plane

AWS, Azure, GCP

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

AWS, Azure

Sicurezza granulare dei dati e mascheratura con viste dinamiche

AWS, Azure, GCP

Controlli di amministrazione per limitare il rischio di esfiltrazione dei dati

AWS, Azure, GCP

Data governance Cloud

Governance dei dati granulare con 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

Sicurezza del carico di lavoro Cloud

Gestione efficace delle versioni di codice con repository


Gestione segreta integrata per evitare credenziali "cablate" nel codice


Aggiornamento periodico dell'immagine della macchina del data plane con patch, scansioni di sicurezza e hardening di base

AWS, Azure (GCP not applicable)

Contenere i costi, soddisfare le esigenze di sicurezza e convalida con le politiche dei cluster


Infrastruttura immutabile "con vita breve" per evitare derive di configurazione


Enhanced hardening with security monitoring and vulnerability reports of managed data plane images


Revisioni e registro Cloud

Registrazione completa e configurabile delle attività di revisione degli utenti di Databricks


Registro storico dei comandi SQL di Databricks


Registro cluster Databricks


Validazioni di sicurezza (conformità) Cloud

Conformità a ISO 27001, 27017, 27018

AWS, Azure, GCP

SOC 1 Type II, SOC 2 Type II, SOC 3

AWS, Azure, GCP

Conformità GDPR e CCPA

AWS, Azure, GCP

Implementazioni PCI conformi a DSS


Conformità a FedRAMP Moderate


Conformità a FedRAMP High


Implementazioni conformi a HIPAA




* Azure Databricks è integrato con Azure Active Directory, e Databricks su GCP è integrato con Google Identity. Questi non possono essere configurati in Databricks, ma si può configurare configure Azure Active Directory o Google Identity secondo necessità.

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, Azure 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

Shared Responsibility Model

The Databricks shared responsibility model outlines the security and compliance obligations of both Databricks and the customer with respect to the data and services on the Databricks platform.

View document

Architettura della piattaforma

L'architettura di Databricks Lakehouse è divisa in due piani separati per semplificare i permessi, evitare duplicazioni di dati e ridurre i rischi. Il control plane è il piano di gestione, dove Databricks esegue l'applicazione dello spazio di lavoro e gestisce notebook, configurazione e cluster. Tranne nel caso in cui si scelga di usare l'elaborazione senza server, il data plane gira all'interno dell'account del fornitore di servizi cloud, elaborando i dati senza estrarli dall'account. Databricks può essere incorporato nell'architettura di protezione contro l'esfiltrazione dei dati utilizzando funzionalità come VPC/VNet gestite dal cliente e opzioni della console di amministrazione che disabilitano l'esportazione.

Alcuni dati, come notebook, configurazioni, registri e informazioni degli utenti, sono presenti all'interno del control plane, ma queste informazioni sono crittografate a riposo nel control plane, e la comunicazione da e verso il control plane viene crittografata in transito. Inoltre si può scegliere dove risiedono alcuni dati. Ogni azienda può ospitare il proprio archivio di metadati relativi alle tabelle di dati (Hive metastore), conservare i risultati delle query sull'account del fornitore di servizi cloud (CSP), e decidere se utilizzare l'interfaccia Databricks Secrets API.

Supponiamo che un data engineer acceda a Databricks e scriva un notebook che trasforma dati grezzi in Kafka in un set di dati normalizzato, inviato poi a uno storage come Amazon S3 o Azure Data Lake Storage. Sei passaggi per raggiungere questo obiettivo:

  1. Il data engineer si autentica, tramite Single Sign-On se desiderato, sull'interfaccia utente web di Databricks nel control plane, ospitato sull'account Databricks.
  2. Mentre il data engineer scrive il codice, il browser lo invia al control plane. Anche le richieste JDBC/ODBC seguono lo stesso percorso, con autenticazione tramite token.
  3. Una volta pronto, il control plane usa le API del fornitore di servizi cloud per creare un cluster Databricks, costituito da nuove istanze sul data plane, nell'account CSP dell'azienda. Gli amministratori possono applicare politiche di cluster per attivare profili di sicurezza.
  4. Una volta lanciate le istanze, il cluster manager invia il codice del data engineer al cluster.
  5. Il cluster preleva i dati da Kafka sull'account CSP, trasforma i dati all'interno dell'account aziendale e li scrive in uno storage nell'account.
  6. Il cluster riporta lo stato ed eventuali output al cluster manager.

Il data engineer non si deve preoccupare di molti dettagli: deve solo scrivere il codice e Databricks si occuperà di eseguirlo.


Clienti in tutto il mondo affidano a noi i loro dati più sensibili. Databricks ha implementato controlli per soddisfare le esigenze uniche di conformità di settori industriali altamente regolamentati.

Pacchetto Due Diligence

Per effettuare revisioni della sicurezza in modalità self-service, si può scaricare il pacchetto Due Diligence. Questo pacchetto contiene documenti di conformità come le nostre certificazioni ISO e la lettera di conferma del test di penetrazione annuale. Inoltre, il team clienti di Databricks è a disposizione per fornire copie della nostra Enterprise Security Guide e del report SOC 2 Type II.


Certificazioni e standard

immagine sfondo


Databricks prende sul serio la riservatezza. Sappiamo che i dati analizzati con Databricks sono importanti per ogni organizzazione e i suoi clienti, e possono essere soggetti a leggi e regolamenti sulla privacy.

Per capire come Databricks si inquadra nel contesto regolatorio di ciascuna organizzazione, abbiamo preparato FAQ e documenti che illustrano in modo molto trasparente l'approccio di Databricks alla privacy.

immagine sfondo

Aiutaci a investigare su un incidente di sicurezza avvenuto nel tuo spazio di lavoro Databricks

Se sospetti che i dati nel tuo spazio di lavoro possano essere stati compromessi o hai notato incoerenze o imprecisioni nei dati, segnalalo IMMEDIATAMENTE a Databricks.

Segnala SPAM o messaggi sospetti provenienti da Databricks

Se hai ricevuto SPAM o comunicazioni che ritieni siano fraudolente, o che abbiano contenuti inappropriati, impropri o dannosi (malware), contatta SUBITO Databricks.

Come leggere un report di scansione di vulnerabilità interne per un prodotto Databricks

Per aiutare ad analizzare un report di scansione di vulnerabilità, invia una richiesta di assistenza attraverso il canale di assistenza di Databricks, indicando la versione del prodotto, eventuali configurazioni specifiche, l'esito del report e come è stata effettuata la scansione.

Scopri come un CVE impatta sullo spazio di lavoro o sul runtime di Databricks

Se desideri informazioni sull'impatto di un CVE di terze parti o un CVE di Databricks, invia una richiesta di assistenza attraverso il canale di assistenza di Databricks, fornendo la descrizione del CVE, il livello di severità e i riferimenti trovati sul National Vulnerability Database

Segnala un bug nei prodotti o servizi di Databricks

Se hai trovato una vulnerabilità riproducibile in uno dei nostri prodotti, vogliamo essere informati per risolvere il problema. Partecipa al nostro programma Bug Bounty pubblico promosso da HackerOne.

immagine sfondo


HIPAA è un regolamento in vigore negli Stati Uniti che prevede svariate protezioni per dati sanitari sensibili. Databricks prevede opzioni di implementazione conformi a HIPAA.

Cloud supportati


Azure Multi-Tenant — Tutte le regioni

AWS Single Tenant — Tutte le regioni

AWS Multi-Tenant — us-east-1, us-east-2, ca-central-1, us-west-2