Azure Data Factory è un servizio cloud serverless totalmente gestito (PaaS). Viene utilizzato per l’orchestrazione di dati tramite numerosi connettori, ad oggi 90 e già presenti all’interno del servizio, che si interfacciano alle varie e diversificate fonti dati. I dati vengono estratti, trasformati e caricati (ETL, extraction, transformation, loading) tramite flussi di lavoro chiamati “pipeline”. Azure Data Factory, denominato anche Code-Free ETL as a service, permette l’integrazione con operazioni CI/CD delle pipeline tramite Azure DevOps e GitHub.
In questo articolo viene riportato nel dettaglio l’utilizzo dell’integration runtime di tipo self-hosted per permettere comunicazioni solo private verso i servizi Azure che per natura risultano essere esposti pubblicamente.
Azure Data Factory Integration Runtime (IR)
L’integration runtime è il componente fondamentale per permettere l’esecuzione delle attività verso i linked services (l’origine dei dati) configurati. L’integration runtime è di 3 tipologie:
- Azure
- Self-hosted
- Azure-SSIS
Self-hosted IR
Tramite IR di tipo self-hosted è possibile accedere al linked service in modo privato sfruttando private link, service endpoint o accedendo direttamente al servizio esposto da una Azure IaaS VM (rete vNet) o da un servizio on-premise (rete interna) nel datacenter on-premise.
Architettura
L’architettura Azure, per il posizionamento dell’integration runtime di tipo self-hosted, prevede l’installazione del componente all’interno di una Azure VM o se necessario, per i linked services da utilizzare, all’interno di una VM on-premise.
Procedura
L’attivazione del self-hosted integration runtime è costituito da due fasi. Nella prima fase viene eseguita l’installazione all’interno di Azure Data Factory.
Per architetture Azure che non necessitano di avere il self-hosted integration runtime in alta disponibilità oppure condiviso tra più Data Factory dovrà solo essere definito un nome e pochi settings come l’auto update.
Fondamentale invece sarà registrare la key da utilizzare successivamente nella seconda fase ossia l’installazione dell’integration runtime all’interno della VM.
Dopo aver eseguito il download dell’ultima versione sarà possibile procedere con l’installazione.
In caso di problematiche durante la registrazione del self-hosted IR verso Azure Data Factory occorre verificare che i flussi richiesti in uscita su Internet siano abilitati.
Riportiamo solo le URL necessarie per la registrazione e comunicazione verso Azure Data Factory:
- *.servicebus.windows.net HTTPS/443;
- {datafactory}.{region}.datafactory.azure.net HTTPS/443;
- microsoft.com HTTPS/443 (necessario solo se il setting di Auto update è stato abilitato);
Se viene utilizzato un flusso in uscita verso Internet invece di un flusso privato o sulla rete backbone di Microsoft, per raggiungere i linked services che vengono esposti su Internet, è necessario permettere la comunicazione anche verso le seguenti URL:
- *.core.windows.net HTTPS/433 (necessario per la comunicazione verso Azure Storage Account);
- *.database.windows.net TCP/1433 (necessario per la comunicazione verso Azure SQL DB e Azure Synapse Analytics);
- *.azuredatalakestore.net e microsoftonline.com/<tenant>/oauth2/token HTTPS/443 (utilizzato per la comunicazione e autenticazione verso Azure Datalake storage);
Per ulteriori analisi anche in seguito a verifiche di dettaglio verso le fonti dati è possibile utilizzare gli eventi registrati in Event Viewer nella raccolta eventi specifica.
Una volta installato l’integration runtime di tipo self-hosted e verificata la corretta comunicazione lato Azure Data Factory sarà possibile testare, all’interno del linked service, la corretta comunicazione utilizzando il nuovo IR.
Azure IR Managed Virtual Network (Preview)
Risulta possible, tramite la funzionalità in preview Managed Virtual Network, utilizzare comunicazioni private sfruttando l’integration runtime di tipo Azure. Tramite i Managed Private Endpoint sarà possibile utilizzare Azure Data Factory Managed Virtual Network per stabilire collegamenti privati verso il linked service.
Essendo ancora in preview ad oggi esistono ancora alcune limitazioni da tenere in considerazione se si decide di sfruttare questa nuova funzionalità.
Riferimenti
Si riportano alcuni riferimenti utili alla documentazione ufficiale Microsoft:
Conclusioni
Le comunicazioni private tramite private endpoint/private link e service endpoint consentono di prevenire l’esfiltrazione dei dati. Questo è possibile vincolando e abilitando l’accesso solo a quella specifica risorsa Azure (PaaS) invece che all’intero servizio Azure. L’integration runtime di tipo self-hosted permette di raggiungere questo livello di sicurezza nelle comunicazioni tra Azure Data Factory (servizio PaaS) e potenzialmente tutti i linked services/connettori utilizzabili. Se la comunicazione privata risulta essere un requisito obbligatorio (must have) di progetto bisognerà prevedere nell’architettura Azure del servizio Data Factory anche l’integration runtime di tipo self-hosted.