Considerazioni sulla sicurezza dello spostamento dei dati in Azure Data Factory
SI APPLICA A:
Azure Data Factory Azure Synapse Analytics
Suggerimento
Provare Data Factory in Microsoft Fabric, una soluzione di analisi all-in-one per le aziende. Microsoft Fabric copre tutto, dallo spostamento dati al data science, all'analisi in tempo reale, alla business intelligence e alla creazione di report. Vedere le informazioni su come iniziare una nuova prova gratuita!
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, incluso Il runtime di integrazione di Azure e il runtime di integrazione self-hosted non archivia dati temporanei, memorizza nella cache dati o log, 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, 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.
Nota
È consigliabile usare il modulo Azure Az PowerShell per interagire con Azure. Per iniziare, 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).
Centralizzando l'archiviazione dei segreti delle applicazioni in Azure Key Vault è possibile controllare la distribuzione dei segreti. Key Vault riduce notevolmente le probabilità di divulgazione accidentale dei segreti. Invece di archiviare la stringa di connessione nel codice dell'app, è possibile archiviarla 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.
Nota
Tutte le connessioni a 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:
- 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.
- 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 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 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.
Azure Data Lake Storage
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.
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 a cui si fa riferimento 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 self-hosted.
Archiviare le credenziali in locale. Se si usa direttamente il cmdlet Set-AzDataFactoryV2LinkedService con i stringa 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 viene infine crittografato e archiviato. 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 attraverso il back-end di Azure al runtime di integrazione self-hosted. 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 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 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 da Integration Runtime Configuration Manager nella scheda Impostazioni:
Crittografia dei dati 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 | Configurazione del 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
VPN IPSec
Configurazioni del firewall e impostazione dell'elenco di 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 in base alle esigenze delle 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 dati tramite 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.netO *.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.netlogin.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 in base alle esigenze delle 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. |
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 del computer di 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 di 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
- Archiviazione Azure Data Lake
- 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 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 Guida alle prestazioni dell'attività di copia e all'ottimizzazione.
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per