Considerazioni sulla sicurezza dello spostamento dei dati in Azure Data Factory

SI APPLICA A: Azure Data Factory Azure Synapse Analytics

Questo articolo descrive l'infrastruttura di sicurezza di base usata dai servizi di spostamento dei dati in Azure Data Factory per proteggere i dati. Le risorse di gestione di Data Factory si basano sull'infrastruttura di sicurezza di Azure e ricorrono a tutte le misure di sicurezza offerte da Azure.

In una soluzione Data Factory si creano una o più pipelinedi dati. Una pipeline è un raggruppamento logico di attività che insieme eseguono un'operazione. Queste pipeline si trovano nell'area in cui è stata creata la data factory.

Sebbene Data Factory sia disponibile solo in alcune regioni, il servizio di spostamento dati è disponibile a livello globale per garantire la conformità dei dati, l'efficienza e costi ridotti per il trasferimento di dati in uscita dalla rete.

Azure Data Factory inclusi Azure Integration Runtime e self-hosted Integration Runtime non archivia dati temporanei, dati o log della cache, ad eccezione delle credenziali del servizio collegato per gli archivi dati cloud, crittografati tramite certificati. Con Data Factory, è possibile creare flussi di lavoro basati sui dati per orchestrare lo spostamento di dati tra archivi dati supportati e l'elaborazione di dati usando i servizi di calcolo in altre aree o in un ambiente locale. È anche possibile monitorare e gestire i flussi di lavoro usando SDK e Monitoraggio di Azure.

Data Factory è stato certificato per:

Certificazione CSA STAR
ISO 20000-1:2011
ISO 22301:2012
ISO 27001:2013
ISO 27017:2015
ISO 27018:2014
ISO 9001:2015
SOC 1, 2, 3
HIPAA BAA
HITRUST

Se si è interessati alla conformità di Azure e alle modalità di protezione dell'infrastruttura da parte di Azure, visitare Microsoft Trust Center. Per un elenco aggiornato di tutte le offerte di conformità di Azure, consultare - https://aka.ms/AzureCompliance.

In questo articolo vengono prese in esame le considerazioni sulla sicurezza nei due scenari di spostamento di dati seguenti:

  • Scenario cloud: in questo scenario l'origine e la destinazione sono accessibili pubblicamente tramite Internet. Questi includono servizi di archiviazione cloud gestiti come Archiviazione di Azure, Azure Synapse Analytics, database SQL di Azure, Azure Data Lake Store, Amazon S3, Amazon Redshift, servizi SaaS come Salesforce e protocolli Web come FTP e OData. Per un elenco completo delle origini dati supportate, vedere Archivi dati e formati supportati.
  • Scenario ibrido: in questo scenario l'origine o la destinazione si trova dietro un firewall o in una rete aziendale locale oppure l'archivio dati si trova in una rete privata o in una rete virtuale (il più delle volte l'origine) e non è accessibile pubblicamente. Anche i server di database ospitati nelle macchine virtuali rientrano in questo scenario.

Nota

Questo articolo è stato aggiornato per usare il modulo Az di Azure PowerShell. Il modulo Az di PowerShell è ora il modulo di PowerShell consigliato per l'interazione con Azure. Per iniziare a usare il modulo Az PowerShell, vedere Installare Azure PowerShell. Per informazioni su come eseguire la migrazione al modulo AZ PowerShell, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.

Scenari cloud

Proteggere le credenziali dell'archivio dati

  • Archiviare credenziali crittografate i un archivio gestito di Azure Data Factory. Data Factory consente di proteggere le credenziali dell'archivio dati crittografandole con i certificati gestiti da Microsoft. Questi certificati ruotano ogni due anni. In questo arco temporale è compreso il rinnovo del certificato e la migrazione delle credenziali. Per altre informazioni sulla sicurezza di Archiviazione di Azure, vedere Panoramica sulla sicurezza di Archiviazione di Azure.
  • Archiviare le credenziali in Azure Key Vault. È anche possibile archiviare la credenziale dell'archivio dati in Azure Key Vault. Data Factory recupera la credenziale durante l'esecuzione di un'attività. Per altre informazioni, vedere Store credentials in Azure Key Vault (Archiviare credenziali in Azure Key Vault).

Crittografia di dati in transito

Se l'archivio dati cloud supporta HTTPS o TLS, tutti i trasferimenti di dati tra i servizi di spostamento dei dati in Data Factory e un archivio dati cloud avvengono tramite un canale TLS o HTTPS sicuro.

Nota

Tutte le connessioni database SQL di Azure e Azure Synapse Analytics richiedono la crittografia (SSL/TLS) mentre i dati sono in transito da e verso il database. Quando si crea una pipeline usando JSON, aggiungere la proprietà encryption e impostarla su true nella stringa di connessione. Per Archiviazione di Azure è possibile usare HTTPS nella stringa di connessione.

Nota

Per abilitare la crittografia in transito durante lo spostamento dei dati da Oracle seguire uno delle opzioni seguenti:

  1. Nel server Oracle passare a Oracle Advanced Security (OAS) e configurare le impostazioni di crittografia, che supporta la crittografia Triple DES (3DES) e Advanced Encryption Standard (AES). Per informazioni dettagliate, vedere qui. Azure Data Factory negozia automaticamente il metodo di crittografia per usare uno dei due configurati in OAS per stabilire la connessione a Oracle.
  2. In Azure Data Factory è possibile aggiungere EncryptionMethod = 1 nella stringa di connessione (nel servizio collegato). Questo userà SSL/TLS come metodo di crittografia. Per usarlo, è necessario disabilitare le impostazioni di crittografia non SSL in OAS sul lato server Oracle per evitare conflitti di crittografia.

Nota

La versione TLS usata è 1.2.

Crittografia di dati inattivi

Alcuni archivi di dati supportano la crittografia dei dati inattivi. È consigliabile abilitare il meccanismo di crittografia dei dati per gli archivi dati.

Azure Synapse Analytics

Transparent Data Encryption (TDE) in Azure Synapse Analytics protegge dalla minaccia di attività dannose eseguendo la crittografia e la decrittografia in tempo reale dei dati in pausa. Questo comportamento è trasparente per il client. Per altre informazioni, vedere Proteggere un database in Azure Synapse Analytics.

database SQL di Azure

Il database SQL di Azure supporta anche la funzionalità Transparent Data Encryption (TDE), che consente di proteggersi da attività dannose eseguendo in tempo reale la crittografia e la decrittografia dei dati, senza dover apportare modifiche all'applicazione. Questo comportamento è trasparente per il client. Per altre informazioni, vedere Transparent Data Encryption per il database SQL e Data Warehouse.

Archivio Azure Data Lake

Azure Data Lake Store offre anche la possibilità di crittografare i dati archiviati nell'account. Se abilitato, Data Lake Store crittografa automaticamente i dati prima di renderli persistenti e li decrittografa prima di recuperarli, rendendoli quindi trasparenti per il client che accede ai dati. Per altre informazioni, vedere Sicurezza in Archivio Azure Data Lake.

Archiviazione BLOB di Azure e Archiviazione tabelle di Azure

Archiviazione BLOB di Azure e Archiviazione tabelle di Azure supportano la crittografia del servizio di archiviazione, che crittografa automaticamente i dati prima di renderli persistenti nella risorsa di archiviazione e li decrittografa prima di recuperarli. Per altre informazioni, vedere Crittografia del servizio di archiviazione di Azure per dati inattivi.

Amazon S3

Amazon S3 supporta la crittografia client e server dei dati inattivi. Per altre informazioni, vedere Protezione dei dati mediante la crittografia.

Amazon Redshift

Amazon Redshift supporta la crittografia cluster per i dati inattivi. Per altre informazioni, vedere Amazon Redshift Database Encryption (Crittografia database Amazon Redshift).

Salesforce

Salesforce supporta il servizio Shield Platform Encryption, che consente la crittografia di tutti i file, gli allegati e i campi personalizzati. Per altre informazioni, vedere Understanding the Web Server OAuth Authentication Flow (Comprendere il flusso di autenticazione OAuth per il server Web).

Scenari ibridi

Gli scenari ibridi richiedono l'installazione del runtime di integrazione self-hosted in una rete locale, in una rete virtuale (Azure) o in un cloud privato virtuale (Amazon). Il runtime di integrazione self-hosted deve essere in grado di accedere agli archivi dati locali. Per altre informazioni sul runtime di integrazione self-hosted, vedere Come creare e configurare il runtime di integrazione self-hosted.

Canali di runtime di integrazione self-hosted

Il canale di comando consente la comunicazione tra i servizi di spostamento dei dati in Data Factory e nel runtime di integrazione self-hosted. La comunicazione contiene informazioni relative all'attività. Il canale di dati viene usato per trasferire i dati tra gli archivi dati locali e quelli nel cloud.

Credenziali dell'archivio dati locale

Le credenziali possono essere archiviate all'interno di data factory o essere referenziati da data factory durante il runtime da Azure Key Vault. Se le credenziali vengono archiviate data factory, vengono sempre archiviate crittografate nel runtime di integrazione self-hosted.

  • Archiviare le credenziali in locale. Se si usa direttamente il cmdlet Set-AzDataFactoryV2LinkedService con le stringhe di connessione e le credenziali inline nel codice JSON, il servizio collegato viene crittografato e archiviato nel runtime di integrazione self-hosted. In questo caso le credenziali passano attraverso il servizio back-end di Azure, estremamente sicuro, al computer di integrazione self-hosted in cui vengono infine crittografate e archiviate. Il runtime di integrazione self-hosted usa Windows DPAPI per crittografare i dati sensibili e le informazioni sulle credenziali.

  • Archiviare le credenziali in Azure Key Vault. È anche possibile archiviare la credenziale dell'archivio dati in Azure Key Vault. Data Factory recupera la credenziale durante l'esecuzione di un'attività. Per altre informazioni, vedere Store credentials in Azure Key Vault (Archiviare credenziali in Azure Key Vault).

  • Archiviare le credenziali in locale senza passare le credenziali tramite il back-end di Azure al runtime di integrazione self-hosted. Se si vuole crittografare e archiviare le credenziali in locale nel runtime di integrazione self-hosted senza dover eseguire il flusso delle credenziali tramite il back-end di data factory, seguire la procedura descritta in Crittografare le credenziali per gli archivi dati locali in Azure Data Factory. Tutti i connettori supportano questa opzione. Il runtime di integrazione self-hosted usa Windows DPAPI per crittografare i dati sensibili e le informazioni sulle credenziali.

  • Usare il cmdlet New-AzDataFactoryV2LinkedServiceEncryptedCredential per crittografare le credenziali del servizio collegato e i dettagli sensibili nel servizio collegato. È quindi possibile usare il codice JSON restituito (con l'elemento EncryptedCredential nella stringa di connessione) per creare un servizio collegato usando il cmdlet Set-AzDataFactoryV2LinkedService.

Porte usate durante la crittografia del servizio collegato nel runtime di integrazione self-hosted

Per impostazione predefinita, quando l'accesso remoto da Intranet è abilitato, PowerShell usa la porta 8060 nel computer con runtime di integrazione self-hosted per la comunicazione sicura. Se necessario, questa porta può essere modificata dal Integration Runtime Gestione configurazione nella Impostazioni seguente:

Integration Runtime Gestione configurazione della scheda Impostazioni proprietà

Porta HTTPS per il gateway

Crittografia in transito

Tutti i trasferimenti di dati avvengono attraverso un canale HTTPS e TLS sicuro su TCP per impedire attacchi di tipo "man-in-the-middle" durante la comunicazione con i servizi di Azure.

È anche possibile usare VPN IPSec o Azure ExpressRoute per proteggere ulteriormente il canale di comunicazione tra la rete locale e Azure.

Rete virtuale di Azure è una rappresentazione logica della propria rete nel cloud. È possibile connettere una rete locale alla propria rete virtuale configurando VPN IPSec (da sito a sito) o ExpressRoute (peering privato).

La tabella seguente riassume i consigli di configurazione di rete e del runtime di integrazione self-hosted in base alle diverse combinazioni di percorsi di origine e destinazione per lo spostamento dei dati ibridi.

Source (Sorgente) Destination Configurazione di rete Impostazione runtime di integrazione
Locale Servizi cloud e macchine virtuali distribuiti nelle reti virtuali VPN IPSec (da punto a sito o da sito a sito) Il runtime di integrazione self-hosted deve essere installato in una macchina virtuale di Azure nella rete virtuale.
Locale Servizi cloud e macchine virtuali distribuiti nelle reti virtuali ExpressRoute (peering privato) Il runtime di integrazione self-hosted deve essere installato in una macchina virtuale di Azure nella rete virtuale.
Locale Servizi basati su Azure con un endpoint pubblico ExpressRoute (peering Microsoft) Il runtime di integrazione self-hosted può essere installato in locale o in una macchina virtuale di Azure.

Le immagini seguenti mostrano come usare il runtime di integrazione self-hosted per spostare i dati tra un database locale e i servizi di Azure con ExpressRoute e la VPN IPSec (con Rete virtuale di Azure):

Express Route

Usare ExpressRoute con il gateway

IPSec VPN

VPN IPSec con gateway

Configurazioni del firewall e configurazione dell'elenco elementi consentiti per gli indirizzi IP

Nota

Potrebbe essere necessario gestire le porte o configurare l'elenco di indirizzi consentiti per i domini a livello di firewall aziendale come richiesto dalle rispettive origini dati. Questa tabella usa solo database SQL di Azure, Azure Synapse Analytics e Azure Data Lake Store come esempi.

Nota

Per informazioni dettagliate sulle strategie di accesso ai Azure Data Factory, vedere questo articolo.

Requisiti del firewall per la rete locale/privata

In un'azienda il firewall aziendale viene eseguito nel router centrale dell'organizzazione. Windows Firewall viene eseguito come daemon nel computer locale in cui è stato installato il runtime di integrazione self-hosted.

La tabella seguente indica la porta in uscita e i requisiti di dominio per i firewall aziendale:

Nomi di dominio Porte in uscita Descrizione
*.servicebus.windows.net 443 Richiesta dal runtime di integrazione self-hosted per la creazione interattiva.
{datafactory}.{region}.datafactory.azure.net
o *.frontend.clouddatahub.net
443 Richiesta dal runtime di integrazione self-hosted per connettersi al servizio Data Factory.
Per i nuovi data factory creati, trovare il nome di dominio completo nella chiave del runtime di integrazione self-hosted, nel formato {datafactory}.{region}.datafactory.azure.net. Per i data factory precedenti, se il nome di dominio completo non è visibile nella chiave di integrazione self-hosted, usare invece *.frontend.clouddatahub.net.
download.microsoft.com 443 Richiesta dal runtime di integrazione self-hosted per il download degli aggiornamenti. Se l'aggiornamento automatico è stato disabilitato, è possibile evitare di configurare questo dominio.
*.core.windows.net 443 Usata dal runtime di integrazione self-hosted per connettersi all'account di archiviazione di Azure quando si usa la funzionalità di copia temporanea.
*.database.windows.net 1433 Obbligatori solo quando si esegue la copia da o nel database SQL di Azure o in Azure Synapse Analytics, facoltativi in caso contrario. Usare la funzionalità di copia temporanea per copiare i dati nel database SQL o in Azure Synapse Analytics senza aprire la porta 1433.
*.azuredatalakestore.net
login.microsoftonline.com/<tenant>/oauth2/token
443 Obbligatori solo quando si esegue la copia da o in Azure Data Lake Store, facoltativi in caso contrario.

Nota

Potrebbe essere necessario gestire le porte o configurare l'elenco di indirizzi consentiti per i domini a livello di firewall aziendale come richiesto dalle rispettive origini dati. Questa tabella usa solo database SQL di Azure, Azure Synapse Analytics e Azure Data Lake Store come esempi.

Nella tabella seguente vengono indicati i requisiti relativi alla porta in ingresso per Windows Firewall:

Porte in ingresso Descrizione
8060 (TCP) Richiesta dal cmdlet di crittografia PowerShell, come descritto in Crittografare le credenziali per gli archivi dati locali in Azure Data Factory, e dall'applicazione di gestione delle credenziali per impostare in modo sicuro le credenziali per gli archivi dati locali nel runtime di integrazione self-hosted.

Requisiti relativi alla porta del gateway

Configurazioni IP e configurazione dell'elenco elementi consentiti negli archivi dati

Alcuni archivi dati nel cloud richiedono anche di consentire l'indirizzo IP del computer che accede all'archivio. Assicurarsi che l'indirizzo IP del computer del runtime di integrazione self-hosted sia consentito o configurato nel firewall in modo appropriato.

Gli archivi dati cloud seguenti richiedono di consentire l'indirizzo IP del computer del runtime di integrazione self-hosted. Alcuni di questi archivi dati, per impostazione predefinita, potrebbero non richiedere l'elenco elementi consentiti.

Domande frequenti

Il runtime di integrazione self-hosted può essere condiviso tra diverse data factory?

Sì. Ulteriori dettagli qui.

Quali sono i requisiti delle porte per il corretto funzionamento del runtime di integrazione self-hosted?

Il runtime di integrazione self-hosted stabilisce connessioni basate su HTTP per accedere a Internet. La porta in uscita 443 deve essere aperta per permettere al runtime di integrazione self-hosted di stabilire una connessione. Aprire la porta in ingresso 8060 solo a livello di computer (non a livello di firewall aziendale) per l'applicazione di gestione delle credenziali. Se database SQL di Azure o Azure Synapse Analytics come origine o destinazione, è necessario aprire anche la porta 1433. Per altre informazioni, vedere la sezione Configurazione del firewall e configurazione dell'elenco elementi consentiti per gli indirizzi IP.

Passaggi successivi

Per informazioni sulle prestazioni dell'attività di copia di Azure Data Factory, vedere Guida alle prestazioni dell'attività di copia e all'ottimizzazione.