Considerazioni sulla sicurezza per lo spostamento dei dati in Azure Data Factory

• Versione corrente

APPLICABILE 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 su Azure'infrastruttura di sicurezza e usano tutte le possibili 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, incluso Azure Integration Runtime e Integration Runtime self-hosted, non archivia né memorizza nella cache dati temporanei o log, ad eccezione delle credenziali dei servizi collegati per gli archivi dati cloud, crittografate 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:

Se siete interessati alla conformità di Azure e al modo in cui Azure protegge la propria infrastruttura, visitare il Microsoft Trust Center. Per l'elenco più recente di tutte le offerte di conformità Azure, selezionare 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, ad esempio 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.

Scenari cloud

Proteggere le credenziali dell'archivio dati

• Store le credenziali crittografate in un archivio gestito Azure Data Factory. Data Factory consente di proteggere le credenziali dell'archivio dati crittografandole con 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 Archiviazione di Azure, vedere Archiviazione di Azure panoramica della sicurezza.
• Archiviare credenziali in Azure Key Vault. È anche possibile archiviare le credenziali dell'archivio dati in Azure Key Vault. Data Factory recupera la credenziale durante l'esecuzione di un'attività. Per altre informazioni, vedere Store credential in Azure Key Vault.

La centralizzazione dell'archiviazione dei segreti dell'applicazione in Azure Key Vault consente di controllare la distribuzione. Key Vault riduce notevolmente le probabilità che i segreti vengano accidentalmente persi. Invece di archiviare il stringa di connessione nel codice dell'app, puoi archiviarlo in modo sicuro in Key Vault. Le applicazioni possono accedere in modo sicuro alle informazioni necessarie tramite URI. Questi URI permettono alle applicazioni di recuperare versioni specifiche di un segreto. Non è necessario scrivere codice personalizzato per proteggere le informazioni segrete archiviate in 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.

Crittografia dei 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 consente di proteggersi dalla minaccia di attività dannose eseguendo la crittografia e la decrittografia in tempo reale dei dati inattivi. Questo comportamento è trasparente per il client. Per altre informazioni, vedere Secure a database in Azure Synapse Analytics.

database SQL di Azure

database SQL di Azure supporta anche Transparent Data Encryption (TDE), che consente di proteggersi dalla minaccia di attività dannose eseguendo la crittografia e la decrittografia in tempo reale dei dati, senza richiedere modifiche all'applicazione. Questo comportamento è trasparente per il client. Per ulteriori informazioni, vedere Crittografia dei dati trasparente per SQL Database e Data Warehouse.

Azure Data Lake Store

Azure Data Lake Store fornisce anche la crittografia per i dati archiviati nell'account. Se abilitata, Data Lake Store crittografa automaticamente i dati prima di salvare e decrittografare prima del recupero, rendendoli trasparenti al client che accede ai dati. Per altre informazioni, vedere Security in Azure Data Lake Store.

Archiviazione BLOB di Azure e Archiviazione tabelle di Azure

Archiviazione BLOB di Azure e Archiviazione tabelle di Azure supportano Storage Service Encryption (SSE), che crittografa automaticamente i dati prima di memorizzarli in modo permanente nell'archiviazione e li decrittografa prima del recupero. Per altre informazioni, vedere Archiviazione di Azure Service Encryption for Data at Rest.

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 ulteriori informazioni, consultare la sezione 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, all'interno di una rete virtuale (Azure) o all'interno di 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.

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 della data factory o essere referenziate dalla data factory durante il runtime da Azure Key Vault. Se si archiviano le credenziali all'interno della data factory, vengono sempre archiviate crittografate nel runtime di integrazione ospitato in locale.

• Archiviare le credenziali in locale. Se si usa direttamente il cmdlet Set-AzDataFactoryV2LinkedService con le stringhe di connessione e le credenziali in linea nel JSON, il servizio collegato viene crittografato e archiviato nell'ambiente di runtime di integrazione self-hosted. In questo caso, le credenziali passano attraverso il servizio back-end di Azure, estremamente sicuro, alla macchina 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 credenziali in Azure Key Vault. È anche possibile archiviare le credenziali dell'archivio dati in Azure Key Vault. Data Factory recupera la credenziale durante l'esecuzione di un'attività. Per altre informazioni, vedere Store credential in Azure Key Vault.

• Archiviare le credenziali in locale senza trasferire le credenziali tramite il back-end di Azure al runtime di integrazione auto-ospitato. Se si vogliono crittografare e archiviare le credenziali in locale nel runtime di integrazione self-hosted senza dover scorrere le credenziali tramite il back-end di Data Factory, seguire i passaggi descritti in Encrypt credentials for on-premises data stores 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 nel 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 ospitato autonomamente

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

scheda Impostazioni di

Crittografia dei dati in transito

Tutti i trasferimenti di dati sono tramite un canale protetto HTTPS e TLS su TCP per evitare attacchi 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 rete nel cloud. È possibile connettere una rete locale alla 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.

Le immagini seguenti illustrano l'uso del runtime di integrazione self-hosted per lo spostamento dei dati tra un database locale e i servizi Azure tramite ExpressRoute e VPN IPsec (con Rete virtuale di Azure):

ExpressRoute

VPN IPSec

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

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 è installato il runtime di integrazione self-hosted.

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

La tabella seguente fornisce i requisiti delle porte in ingresso per Windows Firewall:

Configurazioni IP e impostazione dell'elenco di 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 della macchina del runtime di integrazione autogestito sia autorizzato o configurato correttamente nel firewall.

Gli archivi dati cloud seguenti richiedono di poter inserire nell'elenco elementi consentiti 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.

• database SQL di Azure
• Azure Synapse Analytics
• Azure Data Lake Store
• Azure Cosmos DB
• Amazon Redshift

Domande frequenti

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

Sì. Altri dettagli sono disponibili 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 viene usato come origine o come destinazione, è necessario aprire anche la porta 1433. Per altre informazioni, vedere la sezione Configurazioni del firewall e impostazione dell'elenco consenti per gli indirizzi IP.

Contenuto correlato

Per informazioni sulle prestazioni dell'attività di copia di Azure Data Factory, vedere Copy Activity performance and tuning guide.