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à.
Accenture
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

Fiducia

La nostra piattaforma affidabile è stata costruita integrando la sicurezza lungo tutto il ciclo di vita di fornitura e sviluppo del software. Seguiamo rigorose pratiche di sicurezza operativa come test di penetrazione, valutazioni di vulnerabilità e stretto controllo sugli accessi interni. Crediamo che la trasparenza sia la chiave per ottenere la fiducia: condividiamo pubblicamente le nostre modalità operative e lavoriamo a stretto contatto con clienti e partner per rispondere alle loro esigenze di sicurezza.

Impegno contrattuale

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.

Gestione della vulnerabilità

Rilevare e correggere velocemente software vulnerabili è una delle responsabilità più importanti per qualsiasi fornitore di software o servizi, sia che la vulnerabilità riguardi il proprio codice, sia che interessi un software che si utilizza. Prendiamo molto sul serio questa responsabilità e nel Security Addendum forniamo indicazioni sulle tempistiche di intervento.

Internamente utilizziamo numerosi strumenti di scansione di sicurezza fra i più noti per individuare vulnerabilità nella piattaforma. Databricks utilizza anche servizi di terze parti per analizzare siti Internet esposti al pubblico e individuare potenziali rischi. Le vulnerabilità di severità 0, come le falle zero-day che vengono sfruttate attivamente, vengono trattate con la massima urgenza e la loro correzione ha la priorità su tutti gli altri interventi.

Test di penetrazione e Bug Bounty

Eseguiamo test di penetrazione attraverso una combinazione di team interni di protezione contro gli attacchi, collaudatori qualificati di terze parti e un programma Bug Bounty pubblico attivo tutto l'anno. Solitamente effettuiamo 8-10 test di penetrazione con terze parti esterne e 15-20 test di penetrazione interni ogni anno. Condividiamo pubblicamente il rapporto sui test di terze parti su tutta la piattaforma nell'ambito del nostro pacchetto Due Diligence.

Siamo impegnati ad aiutare i clienti ad acquisire fiducia nei carichi di lavoro che eseguono su Databricks. Se il tuo team vuole effettuare un test di penetrazione su Databricks, ti invitiamo a:

  • eseguire scansioni di vulnerabilità nei sistemi data plane che si trovano sull'account del tuo fornitore di servizi cloud;
  • eseguire test sul tuo stesso codice, a condizione che tali test siano interamente contenuti nel data plane (o altri sistemi) sull'account del fornitore di servizi cloud e che valutino i controlli;
  • partecipare al programma Bug Bounty.

Unisciti al programma Databricks Bug Bounty tramite il canale agevolato di HackerOne e ottieni accesso a un'installazione di Databricks che non viene utilizzata dai clienti.

Accesso interno

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

È richiesta un'autenticazione a più fattori per accedere alle console principali dell'infrastruttura, ad esempio le console dei fornitori di servizi cloud (AWS, GCP e Azure). Databricks attua politiche e procedure per evitare l'uso di credenziali esplicite come password o chiavi API, laddove possibile. Ad esempio, solo addetti alla sicurezza incaricati possono elaborare richieste di eccezioni per nuovi ruoli di IAM Principal o politiche su AWS.

I dipendenti di Databricks possono accedere a un sistema di produzione solo in circostanze molto particolari. Qualsiasi accesso richiede l'autenticazione tramite un sistema realizzato da Databricks che convalida l'accesso ed esegue verifiche delle politiche di sicurezza. L'accesso richiede che i dipendenti siano sulla nostra VPN, mentre la nostra soluzione SSO (Single Sign-On) richiede l'autenticazione a più fattori. Maggiori informazioni →

I nostri standard di sicurezza interni prevedono la separazione dei compiti ovunque sia possibile. Ad esempio, centralizziamo il processo di autenticazione e autorizzazione del nostro fornitore di identità cloud per separare l'autorizzazione all'accesso (Mary dovrebbe accedere a un sistema) dalla concessione dell'accesso (Mary ora può accedere a un sistema).

Diamo priorità all'accesso con privilegio minimo, sia nei sistemi interni, sia per il nostro accesso a sistemi di produzione. Il privilegio minimo è integrato esplicitamente nelle nostre politiche interne e si rispecchia nelle nostre procedure. Ad esempio, la maggior parte dei clienti può controllare l'accesso dei dipendenti di Databricks al loro spazio di lavoro, mentre noi applichiamo automaticamente numerosi controlli prima di concedere l'accesso e revochiamo automaticamente l'accesso dopo un periodo di tempo limitato.
Maggiori informazioni →

Ciclo di sviluppo sicuro del software

Databricks segue un ciclo di sviluppo del software (SDLC) che integra la sicurezza in tutti i passaggi, dalla richiesta delle feature al monitoraggio in produzione, con il supporto di strumenti concepiti per tracciare una feature lungo tutto il ciclo di vita. Eseguiamo la scansione automatica di sicurezza su sistemi, librerie e codice, oltre al tracciamento automatizzato delle vulnerabilità.

Databricks sfrutta un Ideas Portal che tiene traccia delle richieste di feature e consente votazioni da parte di clienti e dipendenti. Il nostro processo di design delle feature integra riservatezza e sicurezza "by design". Dopo una valutazione iniziale, le feature ad alto impatto vengono sottoposte a Security Design Review da un esperto di sicurezza in progettazione, oltre a eseguire la modellazione delle minacce e altri controlli specifici per la sicurezza.

Utilizziamo una metodologia di sviluppo agile e suddividiamo le nuove feature in molteplici sprint. Databricks non affida ad altri lo sviluppo della piattaforma Databricks e tutti gli sviluppatori devono svolgere la formazione per lo sviluppo di software sicuro, dimostrando di conoscere la OWASP Top 10 al momento dell'assunzione e poi nelle verifiche annuali. Dati e ambienti di produzione sono separati dagli ambienti di sviluppo, QA e staging. Tutto il codice viene inserito in un sistema di controllo sorgente che richiede l'accesso unico (SSO) con autenticazione a più fattori, con permessi granulari. Le richieste di fusione (merge) del codice richiedono l'approvazione da parte dei titolari della progettazione funzionale di ogni area coinvolta, e tutto il codice viene sottoposto a revisione paritaria (peer review).

Eseguiamo controlli di qualità (ad esempio test unitari e test completi) in diverse fasi del processo SDLC: alla fusione del codice, dopo la fusione del codice, al rilascio e in produzione. La nostra attività comprende test positivi, test di regressione e test negativi. Una volta effettuati i test, provvediamo a un monitoraggio su larga scala per individuare difetti, e gli utenti possono ricevere avvisi sulla disponibilità del sistema tramite la Status Page. In caso di un problema P0 o P1, l'automazione di Databricks attiva una metodologia di analisi delle cause profonde detta dei "5 perché", scegliendo un membro del team post-mortem per supervisionare la revisione, dopodiché vengono tracciate le attività di follow-up.

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.

Databricks applica un processo formale di gestione dei rilasci che prevede una decisione go/no-go prima che il codice venga rilasciato. Le modifiche vengono sottoposte a test progettati per evitare regressioni e validare che le nuove funzionalità siano state testate su carichi di lavoro realistici. Inoltre, viene effettuato un rollout per fasi con monitoraggio per individuare problemi nelle fasi iniziali. Per implementare la separazione dei compiti, solo il nostro sistema di gestione delle implementazioni può rilasciare modifiche in produzione; inoltre, per tutte le implementazioni è richiesta l'approvazione di più persone.

Seguiamo il modello dell'infrastruttura immutabile, nel quale i sistemi vengono sostituiti invece che "rappezzati", per aumentare l'affidabilità e la sicurezza evitando il rischio di deriva della configurazione. Quando lanciamo nuove immagini di sistema o nuovo codice applicativo, trasferiamo i carichi di lavoro a nuove istanze insieme al nuovo codice. Questo vale sia per il control plane sia per il data plane (vedi la sezione "Funzionalità di sicurezza" per maggiori dettagli sull'architettura Databricks). Una volta che il codice è in produzione, un processo di verifica conferma che non vengano aggiunti, rimossi o modificati artefatti.

L'ultima fase del processo SDLC è la creazione della documentazione per il cliente. I documenti di Databricks vengono gestiti in modo analogo al codice, conservando la documentazione nello stesso sistema di controllo sorgente. Modifiche significative richiedono una revisione tecnica e la revisione da parte dei team della documentazione, prima di essere integrate e pubblicate.
Visita la sezione della documentazione →

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

AWSAzureGCP

Gestione segreta integrata per evitare credenziali "cablate" nel codice

AWSAzureGCP

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

AWSAzureGCP

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

AWSAzureGCP

Revisioni e registro Cloud

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

AWSAzureGCP

Registro storico dei comandi SQL di Databricks

AWSAzure

Registro cluster Databricks

AWSAzure

Validazioni di sicurezza (conformità) Cloud

Conformità a ISO 27001, 27017, 27018

AWS, Azure, GCP

Disponibile report SOC 2 Type 2

AWS, Azure, GCP

Conformità GDPR e CCPA

AWS, Azure, GCP

Implementazioni PCI conformi a DSS

AWS (solo Single Tenant)

Conformità a FedRAMP Moderate

AWSAzure

Conformità a FedRAMP High

Azure

Implementazioni conformi a HIPAA

AWSAzure

HITRUST

Azure

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

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

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

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.

Conformità

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.

Download

Certificazioni e standard

immagine sfondo

Overview

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

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

Regioni

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