Ambiente isolato

L'architettura dell'ambiente isolato eredita la baseline di connettività con protezione avanzata e aggiunge due requisiti: l'accesso all'area di lavoro privata e un firewall esterno necessario. L'accesso all'area di lavoro viene gestito da VPN o da collegamento privato in ingresso, mai dalla rete Internet pubblica. Tutto il traffico di uscita del calcolo classico passa attraverso il firewall per l’ispezione e l’applicazione dei criteri.

Questa architettura ha:

• Isolamento di rete completo: tutto il traffico passa attraverso connessioni private.
• Asto di accesso all'area di lavoro privata: SOLO VPN o collegamento privato in ingresso. L'area di lavoro non è raggiungibile dalla rete Internet pubblica.
• Ispezione obbligatoria del traffico in uscita: ispezione firewall di tutto il traffico in uscita del calcolo classico.
• Prevenzione dell'esfiltrazione dei dati: i controlli a livello di rete bloccano il trasferimento non autorizzato dei dati.

Usare questa architettura quando:

• L'accesso all'area di lavoro deve essere privato, ad esempio tramite VPN o collegamento privato in ingresso.
• Gestione dei dati in settori altamente regolamentati, ad esempio servizi finanziari, sanità, governo.
• I framework di conformità richiedono controlli in uscita (ad esempio, SOC 2, HIPAA, PCI DSS e FedRAMP).
• Implementazione di framework aziendali di sicurezza zero trust.
• La prevenzione dell'esfiltrazione dei dati è un requisito.

Prerequisiti

• Azure Azure Databricks livello Premium con un'area di lavoro inserita nella rete virtuale.

• Infrastruttura VPN esistente o connettività collegamento privato in ingresso.
• Firewall o dispositivo virtuale di rete (NVA).

Panoramica dell'architettura

L'architettura dell'ambiente isolato indirizza tutto il traffico attraverso connessioni private con ispezione del firewall:

Tipo di traffico	Percorso
Accesso utente	Utenti → VPN o collegamento privato in ingresso → area di lavoro
Calcolo classico → controllo	Calcolo → collegamento privato classico → Piano di controllo di Azure Databricks
Cloud di calcolo classico →	Calcolo → Endpoint di servizio o route definite dall'utente → servizi di Azure
Serverless → le tue risorse	Calcolo serverless → Endpoint privati NCC → Le tue risorse Azure
Calcolo classico → in uscita	Calcolo → firewall esterno (obbligatorio) → Internet controllato

Componenti richiesti

Inbound

L'area di lavoro è raggiungibile solo tramite connessioni private: VPN, collegamento privato in ingresso o entrambe a seconda dell'infrastruttura esistente. I clienti in genere selezionano uno anziché impilarli.

Impostazioni di accesso privato (disattivazione dell'accesso pubblico)

Si tratta del controllo di accesso che blocca effettivamente l'accesso pubblico in ingresso. Senza di esso, l'area di lavoro accetta ancora il traffico Internet anche con collegamento privato configurato. collegamento privato diventa un percorso aggiuntivo, non l'unico percorso.

Impostare Public Network Access dell'area di lavoro su Disabled nel portale di Azure. Questo blocca l'ingresso pubblico all'interfaccia utente e alle API dell'area di lavoro.

Controlli di ingresso dell'area di lavoro

Configura l'accesso all'area di lavoro tramite ingresso basato sul contesto (CBI), il framework di criteri di accesso consigliato. Le regole CBI combinano l'origine di rete (intervalli IP), l'identità, il meccanismo di autenticazione e l'ambito di accesso in un singolo modello di autorizzazione/negazione, quindi l'attributo di origine di rete esegue lo stesso processo della funzionalità dell'elenco di accesso IP autonomo e altro ancora.

Gli elenchi di accesso IP rimangono supportati e possono essere configurati insieme a CBI. Quando entrambi sono configurati, una richiesta deve essere consentita da entrambi i controlli.

Livelli di configurazione:

• Criteri CBI a livello di account: si applicano a tutte le aree di lavoro nell'account. Vedere Gestire i criteri di ingresso basati sul contesto.
• Elenchi di accesso IP a livello di area di lavoro: si applica a una singola area di lavoro. Vedere Configurare gli elenchi di accesso IP per le aree di lavoro.
• Liste di accesso IP a livello di account: Si applicano alla console dell'account. Vedere Configurare gli elenchi di accesso IP per la console dell'account.

Procedure consigliate:

• Iniziare in modo ampio, perfezionare in base all'utilizzo effettivo.
• Documentare gli intervalli IP con date di scadenza e scopo.
• Mantenere l'accesso amministratore tramite un intervallo IP valido noto.
• Rivedere trimestralmente gli intervalli e rimuovere quelli obsoleti.

Avvertimento

I criteri di ingresso e gli elenchi di accesso IP possono bloccare l'area di lavoro se non sono configurati correttamente. Mantenere sempre l'accesso amministratore tramite un intervallo IP valido noto.

Controllo dell'accesso del destinatario di Delta Sharing

Delta Sharing usa i propri elenchi di accesso IP configurati sugli oggetti destinatario. Questa opzione è separata dagli elenchi di accesso IP dell'area di lavoro e non è coperta dai dati in ingresso basati sul contesto. Si applica solo alla condivisione aperta (destinatari non Azure Databricks).

Vedere Limitare l'accesso dei destinatari alla condivisione delta tramite elenchi di accesso IP (condivisione aperta).

Connettività in ingresso

Stabilisce la connettività privata per l'accesso utente all'interfaccia utente e all'API dell'area di lavoro. Gli utenti raggiungono l'area di lavoro tramite VPN o collegamento privato in ingresso, mai la rete Internet pubblica.

Vedere Configurare il collegamento privato in ingresso.

DNS personalizzato

Configurare il DNS privato per risolvere gli endpoint Azure Databricks in indirizzi IP privati.

Azure crea automaticamente zone DNS private durante la creazione di endpoint privati.

In uscita

I controlli di uscita serverless (criteri di rete ed endpoint privati NCC) ereditano le impostazioni di base da connettività con protezione avanzata. Questa architettura rende il firewall esterno, facoltativo in Hardened, obbligatorio per l'ispezione completa del traffico in uscita del compute classico.

Firewall esterno (obbligatorio)

Instradare tutto il traffico in uscita attraverso un firewall per l'ispezione, la registrazione e l'applicazione dei criteri. Le opzioni includono:

• Firewall di Azure o appliance virtuali di rete di terze parti.

Suggerimento

Usare i criteri per gli endpoint di servizio per l'archiviazione degli artefatti di Azure Databricks per aggirare il firewall, riducendo i costi di trasferimento dei dati. La sola archiviazione degli artefatti può arrivare a rappresentare fino a 11 GB scaricati per ciascun nodo del cluster.

Consulta Indirizzi IP e domini per i servizi e le risorse di Azure Databricks per gli endpoint di Azure Databricks richiesti che devono essere consentiti dalle regole del firewall.

Suggerimento

Per il blocco massimo, prendere in considerazione l'hosting di un repository di pacchetti privati (ad esempio JFrog Artifactory o Sonatype Nexus) per i pacchetti Python, R e Maven. In questo modo si elimina la necessità di regole del firewall che consentono l'accesso a indici di pacchetti pubblici come PyPI.

Avvertimento

Il piano di controllo di Azure Databricks e le connessioni di inoltro SCC utilizzano TLS con il pinning dei certificati. Non abilitare l'ispezione TLS (decrittografare e crittografare nuovamente) sul traffico tra i tuoi cluster e il piano di controllo di Azure Databricks. Così facendo si causano malfunzionamenti del cluster. Configurare le regole del firewall per consentire queste connessioni in base al nome di dominio completo o all'indirizzo IP di destinazione senza intercettazione TLS. Per gli endpoint richiesti, vedere indirizzi IP e domini per i servizi e gli asset di Azure Databricks.

Importante

Le regole del firewall configurate in modo non corretto possono interrompere Azure Databricks funzionalità. Eseguire test approfonditi in un ambiente non di produzione.

Protezione dall'esfiltrazione dei dati

Configurare criteri di rete e controlli firewall per impedire l'esfiltrazione di dati non autorizzati:

• Controllo del traffico in uscita serverless tramite policy di rete.
• Calcolo classico in uscita tramite firewall/appliance virtuale di rete.
• Regole per gli endpoint privati per le destinazioni dei dati approvate.

Per indicazioni sull'implementazione, vedere Protezione dell'esfiltrazione dei dati .

Baseline di calcolo classica

La baseline di calcolo classica viene ereditata dalla sicurezza gestita e gli endpoint servizio cloud vengono ereditati dalla connettività con protezione avanzata. Per questa architettura non sono necessari componenti di calcolo classici aggiuntivi.

La configurazione di base include l'inserimento in una rete virtuale (VNet), la Connettività sicura del cluster (SCC) e collegamento privato classico. Gli endpoint servizio cloud includono route definite dall'utente ( UDR), endpoint di servizio ed endpoint privati per gli account di archiviazione gestiti dal cliente.

Modalità di uscita per l'accesso ai dati

Esistono due approcci per gestire l'accesso ai dati in uscita dalle risorse di calcolo:

• Gateway NAT con firewall: distribuire un gateway NAT per la connettività in uscita e instradare il traffico attraverso un firewall per l'ispezione. Questo approccio consente l'accesso controllato ai repository di pacchetti esterni e alle API e mantiene la visibilità dei modelli di traffico. Usare questo approccio quando è necessario accedere a risorse esterne, ma richiedere l'ispezione e la registrazione.

• Nessun gateway NAT (completamente privato): rimuovere completamente il gateway NAT per eliminare tutte le comunicazioni pubbliche dalle risorse di calcolo. L'accesso ai dati avviene solo tramite endpoint privati ed endpoint VPC. Questo approccio ha il massimo livello di sicurezza rimuovendo la possibilità di esfiltrazione dei dati tramite percorsi in uscita pubblici. Usare questo approccio quando l'organizzazione impedisce qualsiasi comunicazione Internet pubblica dalle risorse di calcolo.

Implementation

Parti da una configurazione di base di connettività rafforzata implementata. Le fasi seguenti aggiungono l'accesso all'area di lavoro privata e il firewall esterno necessario che definiscono questa architettura.

Fase 1: Controlli in ingresso

1. Configurare le collegamento privato in ingresso in modo che l'accesso utente all'interfaccia utente e alle API di Azure Azure Databricks venga instradato privatamente anziché tramite indirizzi IP pubblici. Vedere Configurare il collegamento privato in ingresso.
2. Impostare Public Network Access dell'area di lavoro su Disabled nel portale di Azure. Questo è ciò che blocca effettivamente l'ingresso pubblico. Senza di esso, l'area di lavoro accetta ancora il traffico Internet anche con i collegamento privato in ingresso configurati.
3. Testare l'accesso utente tramite VPN o collegamento privato per verificare che gli utenti autenticati possano raggiungere l'area di lavoro solo tramite il percorso di rete privato e che l'accesso pubblico sia bloccato.

Fase 2: Firewall esterno (obbligatorio)

1. Distribuisci Firewall di Azure o un dispositivo virtuale di rete (NVA) di terze parti in una VNet hub e connetti la VNet dell'area di lavoro tramite peering tra reti virtuali o un hub virtuale.
2. Configurare le route definite dall'utente (UDR) nelle subnet dell'area di lavoro con una route predefinita verso il firewall, in modo che il traffico in uscita dalle risorse di calcolo di Azure Databricks passi tramite il firewall dell'hub. Vedere Impostazioni di percorsi definiti dall'utente per Azure Databricks.
3. Configurare le regole di applicazione e di rete di Firewall di Azure per consentire solo gli endpoint necessari di Azure Databricks (vedere Indirizzi IP e domini per i servizi e gli asset di Azure Databricks) senza intercettazione TLS sul traffico del piano di controllo e di inoltro SCC.

Fase 3: Convalida

1. Verificare il controllo del traffico in uscita esaminando i log e la diagnostica di Firewall di Azure per accertarsi che il traffico di Azure Databricks venga ispezionato e limitato in conformità ai criteri.
2. Verificare che non siano assegnati indirizzi IP pubblici ai nodi del cluster o ad altre risorse di calcolo gestite da Azure Databricks nella rete virtuale dell'area di lavoro.
3. Verificare che tutto il controllo, i dati e il traffico in ingresso passino attraverso gli endpoint collegamento privato configurati e il firewall hub come progettato.

Il Azure Databricks Terraform SRA fornisce modelli di infrastruttura come codice come punto di partenza per questo modello di distribuzione.

Validation

Dopo aver distribuito l'architettura, eseguire i controlli seguenti per verificare che i controlli di isolamento completo della rete, connettività privata e uscita funzionino come configurato.

Controllo	Risultato previsto
Area di lavoro accessibile tramite VPN	Yes
Area di lavoro accessibile senza VPN	No
Avvio dei cluster con SCC	Sì, nessun IP pubblico
Accesso ai dati tramite connessioni private	Yes
Uscita bloccata senza approvazione del firewall	Yes
Il DNS si risolve in indirizzi IP privati	Yes

Risoluzione dei problemi

Se un controllo di convalida non riesce o un carico di lavoro non riesce a connettersi a un endpoint necessario, usare la tabella specifica del cloud seguente per diagnosticare i problemi comuni.

Issue	Motivo	Resolution
Il cluster non si avvia	Firewall che blocca gli endpoint necessari o endpoint privati configurati in modo errato per SCC, per il piano di controllo di Azure Databricks o per gli account di archiviazione (regole NSG, routing)	Esaminare i log del firewall e aggiungere le regole di infrastruttura di Azure Databricks; verificare che le regole NSG dell'endpoint privato consentano il traffico dalle subnet del cluster; controllare le UDR
La risoluzione DNS non riesce	DNS privato non configurato correttamente	Verificare le zone DNS private e i collegamenti di rete virtuale
Accesso all'archiviazione non riuscito	Endpoint privato o problema di routing	Controllare la configurazione e le tabelle di route degli endpoint privati
L'installazione del pacchetto non riesce	PyPI bloccato dal firewall	Aggiungere PyPI all'elenco elementi consentiti del firewall

Manutenzione costante

• Regole del firewall: esaminare e aggiornare regolarmente gli elenchi consentiti in uscita.
• Gestione DNS: aggiornare i record quando si aggiungono aree di lavoro.
• Monitoraggio degli endpoint: consente di monitorare lo stato di integrità degli endpoint privati e i costi di trasferimento dei dati.
• Criteri di rete: aggiungere endpoint privati per le nuove origini dati approvate.
• Rimuovi firewall: se il sovraccarico operativo del firewall è troppo elevato o i requisiti di conformità sono flessibili, è possibile rimuovere il componente firewall e mantenere la connettività privata e l'accesso VPN.
• Passa alla connettività rafforzata: Se l'accesso allo spazio di lavoro privato diventa un ostacolo alla produttività.

Passaggi successivi

risorsa	Description
Protezione dell'esfiltrazione dei dati	Architettura di riferimento dettagliata per la combinazione di controlli network e Unity Catalog per impedire l'esfiltrazione dei dati.
Networking	Opzioni e concetti di rete per Azure Databricks.