Archivi categoria: Networking

Funzionalità da Next-Generation Firewall con Azure Firewall Premium

L’adozione di una efficace strategia di protezione dell’ambiente Azure è fondamentale e richiede anche una attenta valutazione delle funzionalità erogate dalla soluzione firewall che si intende utilizzare. Da tempo è disponibile Azure Firewall, il servizio gestito e totalmente integrato nel cloud pubblico di Microsoft, che consente di mettere in sicurezza le risorse presenti sulle Virtual Network di Azure. In specifiche realtà aziendali, particolarmente sensibili alla sicurezza e che necessitano di un elevato livello di regolamentazione, sono necessarie funzionalità avanzate tipiche di un next generation firewall. Per questa ragione Microsoft ha rilasciato Azure Firewall Premium, la soluzione di firewall-as-a-service (FWaaS) che garantisce diverse funzionalità avanzate per proteggere al meglio gli ambienti Azure. In questo articolo vengono approfondite le caratteristiche di Azure Firewall Premium.

Azure Firewall è un servizio di sicurezza di rete, gestito e basato su cloud, in grado di proteggere le risorse attestate sulle Virtual Network di Azure e di governare in modo centralizzato i relativi flussi di rete. Inoltre, ha funzionalità intrinseche di alta disponibilità e di scalabilità.

La versione Premium permette di ottenere un livello di protezione ulteriore dalle minacce di sicurezza, mediante funzionalità come TLS Inspection e IDPS che garantiscono un maggior controllo del traffico di rete al fine di intercettare e bloccare la diffusione di malware e virus. Le funzionalità di TLS Inspection e IDPS richiedono maggiori prestazioni, motivo per il quale Azure Firewall Premium, rispetto alla tier Standard, utilizza SKU più potenti per le proprie istanze ed è in grado di garantire elevati livelli di performance. Come lo SKU Standard, lo SKU Premium può scalare fino a 30 Gbps e si integra con le availability zones per garantire un service level agreement (SLA) pari al 99,99 percento. Azure Firewall ha ottenuto la certificazione ICSA Labs, inoltre la versione Premium è conforme allo standard di sicurezza PCI DSS (Payment Card Industry Data Security Standard).

Le funzionalità di Azure Firewall Premium

Le nuove funzionalità di Azure Firewall Premium sono configurabili esclusivamente tramite Firewall Policy. Le regole del firewall in modalità “classic” continuano ad essere supportate e possono essere utilizzate solamente per configurare la versione Standard di Azure Firewall. Le Firewall Policy possono essere gestite in modo indipendente oppure con Azure Firewall Manager.

Azure Firewall Premium garantisce tutte le funzionalità presenti nel tier Standard di Azure Firewall e in più aggiunge le seguenti funzionalità tipiche di un next generation firewall.

Figura 1 – Panoramica di Azure Firewall Premium

Nei capitoli seguenti vengono riportate le nuove funzionalità introdotte in Azure Firewall Premium.

TLS inspection

La tecnologia di sicurezza standard che consente di stabilire un collegamento crittografato tra un client ed un server è il Transport Layer Security (TLS), precedentemente noto come Secure Sockets Layer (SSL). Questo standard garantisce che tutti i dati che transitano tra i client ed il server rimangano privati e crittografati. Azure Firewall Premium è in grado di intercettare ed ispezionare le connessioni TLS. Per farlo viene effettuata una de-crittografia completa delle comunicazioni di rete, vengono eseguiti i controlli di sicurezza necessari e viene crittografato nuovamente il traffico che deve essere inviato alla destinazione.

La soluzione TLS Inspection di Azure Firewall Premium risulta ideale per i seguenti casi d’uso:

  • Terminazione TLS in uscita.

Figura 2 – TLS Inspection di Azure Firewall per il traffico in uscita

  • Terminazione TLS tra virtual network di spoke (est-ovest).
  • Terminazione TLS in ingresso con Application Gateway. Nei flussi di comunicazione Azure Firewall può essere distribuito dietro ad un Application Gateway. Adottando questa configurazione, il traffico Web in ingresso passa sia attraverso il WAF dell’Application Gateway sia attraverso il firewall di Azure. Il WAF fornisce una protezione a livello di applicazione Web, mentre Azure Firewall funge da punto centrale di controllo e di registrazione per ispezionare il traffico tra l’Application Gateway e i server di back-end. L’Azure Firewall può infatti de-crittografare il traffico ricevuto dall’Application Gateway per un’ulteriore ispezione e crittografarlo nuovamente prima di inoltrarlo al Web server di destinazione. Per maggiori dettagli su codesto caso d’uso è possibile consultare questo documento Microsoft.

Figura 3 – Implementazione dell’Application Gateway prima dell’Azure Firewall

Per abilitare la TLS Inspection in Azure Firewall Premium è opportuno utilizzare un certificato presente in un Azure Key Vault. L’accesso di Azure Firewall verso il key vault per recuperare i certificati avviene utilizzando una managed identity. Per maggiori informazioni in merito all’utilizzo dei certificati, per questa funzionalità di Azure Firewall Premium, è possibile consultare la documentazione ufficiale Microsoft.

Questi casi d’uso consentono ai clienti di adottare un modello zero trust e di implementare una segmentazione della rete tramite crittografia end-to-end.

IDPS

Un Intrusion Detection and Prevention system (IDPS) di rete consente di monitorare le attività di rete per rilevare quelle dannose, registrare informazioni su queste attività, segnalarle e, facoltativamente, tentare di bloccarle. Azure Firewall Premium fornisce IDPS basato sulle firme ed è in grado di consentire il rilevamento degli attacchi cercando pattern specifici, come sequenze di byte nel traffico di rete oppure sequenze di istruzioni dannose note utilizzate dai malware. Le firme IDPS sono automaticamente gestite e continuamente aggiornate.

Questa capacità funziona per tutte le porte ed i protocolli, ma nonostante alcuni rilevamenti possono essere eseguiti anche con il traffico crittografato, l’abilitazione della TLS Inspection è importante per utilizzare al meglio l’IDPS.

Figura 4 – Modalità dell’IDPS

URL filtering

La funzionalità di URL filtering permette di filtrare l’accesso in uscita verso specifici URL, e non solo per determinati FQDN. Vengono infatti estese la capacità di filtro FQDN di Azure Firewall per considerare un intero URL. Ad esempio, www.microsoft.com/a/b anziché solo www.microsoft.com. Questa funzionalità è efficace anche per il traffico crittografato se la TLS Inspection è abilitata.

L’URL filtering può anche essere utilizzata insieme alla categorizzazione Web per estendere una determinata categoria aggiungendo più URL in modo esplicito oppure per consentire/negare l’accesso agli URL all’interno della intranet dell’organizzazione.

Figura 5 – URL filtering nelle application rules

Categorizzazione Web

La categorizzazione Web nei criteri di Azure Firewall permette di consentire oppure negare l’accesso degli utenti a Internet in base a specifiche categorie, come ad esempio, social network, motori di ricerca, giochi d’azzardo, etc.

Questa funzionalità è possibile usarla come tipologia di destinazione nelle application rules nelle SKU sia Standard sia Premium di Azure Firewall. La differenza principale è che lo SKU Premium permette di ottenere un livello maggiore di ottimizzazione, classificando il traffico in base all’URL completo, tramite la funzionalità di TLS Inspection, mentre lo SKU standard classifica il traffico solamente in base all’FQDN. Questa funzione permette di avere la visibilità ed il controllo nell’utilizzo del traffico Internet di un’organizzazione ed è ideale per controllare la navigazione web per i client Azure Virtual Desktop.

Figura 6 – Categorizzazione Web in una regola di accesso

Il passaggio dalla versione Standard alla versione Premium

Per coloro che utilizzano lo SKU Standard di Azure Firewall e che necessitano di passare allo SKU Premium possono effettuare la migrazione mediante i seguenti step.

  • Come prima cosa, nel caso non siano già in uso, è necessario adottare le Azure Firewall Policy. Per farlo è possibile effettuare la trasformazione delle Azure Firewall rules (Classic) esistenti:

Figura 7 – Migrazione delle classic rule verso le Azure Firewall Policy

  • Creare un nuovo Azure Firewall Premium associandolo all’Azure Firewall Policy esistente:

Figura 8 – Creazione di un nuovo Azure Firewall Premium associando una Azure Policy esistente

NOTA: un aspetto importante da tenere in considerazione nella migrazione è il mantenimento dell’indirizzo IP oppure degli indirizzi IP assegnati ad Azure Firewall.

Il costo di Azure Firewall Premium

Come per lo SKU Standard, i prezzi di Azure Firewall Premium sono dati sia dal deployment, sia dall’elaborazione dei dati. Il costo per il deployment è superiore di circa il 40% rispetto ad Azure Firewall Standard, mentre i costi per l’elaborazione dei dati sono gli stessi previsti per Azure Firewall Standard. Per maggiori dettagli sui costi è possibile consultare la pagina ufficiale Microsoft.

Conclusioni

L’adozione di una soluzione firewall per proteggere e segregare al meglio i flussi di rete è una scelta ormai obbligata per garantire una protezione ed una gestione efficace dell’infrastruttura network in ambienti Azure. Per le realtà aziendali con esigenze avanzate di controllo e di sicurezza possono utilizzare la SKU Premium di Azure Firewall per ampliare il set di funzionalità a disposizione. Azure Firewall Premium può competere, in termini di funzionalità, con Network Virtual Appliances (NVAs) fornite dai vendor di terze parti più noti, per le quali sono però necessarie configurazioni più articolate e sono previsti costi tendenzialmente superiori.

Progettazione di architetture di rete sicure per Azure Kubernetes Service (AKS)

La tendenza nell’adottare applicativi basati su microservizi impone l’utilizzo di soluzioni all’avanguardia in grado di gestire un numero elevato di container e le modalità con le quali questi interagiscono applicativamente tra di loro, come Azure Kubernetes Service (AKS). Nell’ambito della progettazione delle architetture Azure Kubernetes Service (AKS) diversi sono gli elementi che devono essere valutati per ottenere una topologia di rete appropriata in grado di garantire la massima efficienza e sicurezza. In questo articolo vengono riportati i principali aspetti da prendere in considerazione, accompagnati da alcune proposte, per effettuare delle scelte consapevoli nella progettazione delle architetture di rete per AKS.

Che cos’è Azure Kubernetes Service (AKS)?

Azure Kubernetes Service (AKS) è il servizio Azure completamente gestito che permette l’attivazione di un cluster Kubernetes, ideale per semplificare il deployment e la gestione di architetture basate su microservizi. Grazie alle funzionalità offerte da AKS è possibile scalare automaticamente in base all’utilizzo, utilizzare controlli per garantire l’integrità dei servizi, implementare politiche di bilanciamento del carico e gestire i secret. In architetture basate su microservizi è frequente anche l’adozione del componente Azure Container Registry che consente di creare, archiviare e gestire le immagini dei container e gli artifacts in un registry privato. L’utilizzo di questo servizio gestito viene integrato con le pipeline di sviluppo e di deployment dei container.

Figura 1 – Esempio di architettura di Azure Kubernetes Service (AKS)

La topologia di rete

Nell’architettura di rete di tipologia Hub and Spoke, l’Hub è una rete virtuale in Azure che funge da punto di connettività verso la rete on-premises. Tale connettività può avvenire tramite VPN Site to site oppure tramite ExpressRoute. Gli Spoke sono le reti virtuali che eseguono il peering con l’Hub e possono essere usate per isolare i carichi di lavoro.

Figura 2 – Topologia di rete Hub and Spoke

Questa topologia di rete è consigliata anche per le architetture AKS in quanto è in grado di offrire diversi vantaggi, tra i quali:

  • Segregazione dell’ambiente per applicare più agevolmente politiche di governance ed ottenere un maggiore controllo. Questa topologia supporta anche il concetto di “landing zone” contemplando la separazione dei compiti.
  • Riduzione al minimo dell’esposizione diretta delle risorse di Azure alla rete pubblica (Internet).
  • Possibilità di contemplare workload attestati su differenti subscription Azure, diventando di fatto una scelta naturale in questi scenari.
  • Possibilità di estendere facilmente l’architettura per accogliere nuove funzionalità oppure nuovi workload, semplicemente aggiungendo ulteriori virtual network di spoke.
  • Possibilità di centralizzare in un’unica posizione i servizi Azure condivisi da più workload (attestati su VNet differenti), come ad esempio i server DNS ed eventuali appliance virtuali di rete. Si riducono inoltre i VPN Gateway necessari per fornire connettività verso l’ambiente on-premises, con un conseguente risparmio sui costi Azure ed una semplificazione dell’architettura.

Figura 3 – Topologia di rete Hub and Spoke per AKS

Hub Virtual Network

Nella rete di Hub è possibile valutare l’adozione dei seguenti servizi:

  • Gateway VPN oppure ExpressRoute: necessario per fornire connettività verso l’ambiente on-premises.
  • Soluzioni Firewall, necessarie nel caso si voglia controllare il traffico dal proprio ambiente AKS, come pod oppure nodi del cluster, in uscita verso servizi esterni. In questo ambito la scelta può ricadere tra:
    • Azure Firewall, la soluzione di firewall-as-a-service (FWaaS) che consente di mettere in sicurezza le risorse presenti nelle Virtual Network e di governare i relativi flussi di rete.
    • Network Virtual Appliances (NVAs) fornite da vendor di terze parti. Tali soluzioni sono numerose e possono offrire funzionalità avanzate, ma tipicamente la configurazione di queste soluzioni è più articolata e il costo è tendenzialmente più elevato rispetto alla soluzione fornita dalla piattaforma Azure. Una comparativa tra il nuovo Azure Firewall e le virtual appliance di terze parti è possibile consultarla in questo articolo.
  • Azure Bastion, il servizio PaaS che offre un accesso RDP ed SSH sicuro e affidabile alle macchine virtuali, direttamente tramite il portale di Azure.

Spoke Virtual Network

Nella rete di Spoke viene posizionato il cluster AKS insieme ad altre risorse strettamente correlate al suo funzionamento. La VNet di Spoke viene suddivisa in differenti subnet per ospitare i seguenti componenti:

  • I due gruppi di nodi (node pools) di AKS:
    • AKS System Node pool: il pool di nodi di sistema che ospitano i pod necessari per l’esecuzione dei servizi core del cluster.
    • AKS User Node pool: il pool di nodi user che eseguono i workload applicativi e l’ingress controller.

Per ambienti applicativi multi-tenant o per workload con esigenze avanzate potrebbe essere necessario implementare meccanismi di isolamento dei node pools che richiedono la presenza di differenti subnet.

  • AKS Internal Load Balancer: il servizio di bilanciamento per instradare e distribuire il traffico in ingresso per le risorse Kubernetes. In questo caso viene utilizzato il componente Azure Load Balancer, che consente il bilanciamento del carico Layer-4 per tutti i protocolli TCP e UDP, garantendo alte prestazioni e bassissime latenze.
  • Azure Application Gateway: si tratta di un servizio gestito dalla piattaforma Azure, con funzionalità intrinseche di alta disponibilità e scalabilità. L’Application Gateway è un load balancer applicativo (OSI layer 7) per il traffico web, che consente di governare il traffico HTTP e HTTPS delle applicazioni (URL path, host based, round robin, session affinity, redirection). L’Application Gateway è in grado di gestire in modo centralizzato i certificati per la pubblicazione applicativa, tramite policy SSL ed effettuando SSL offload quando necessario. L’Application Gateway può avere assegnato un indirizzo IP Privato oppure un indirizzo IP Pubblico, se la ripubblicazione applicativa deve avvenire verso Internet. In particolare in quest’ultimo caso, è consigliato attivare la funzionalità di Web Application Firewall (WAF), che consente di ottenere una protezione applicativa, basandosi su regole OWASP core rule sets. Il WAF protegge l’applicativo da vulnerabilità e da attacchi comuni, come ad esempio attacchi X-Site Scripting e SQL Injection.

Grazie all’adozione degli Azure Private Link è possibile portare i servizi Azure in una Virtual Network e mapparli con un endpoint privato. In questo modo tutto il traffico viene istradato tramite l’endpoint privato, mantenendolo sulla rete globale di Microsoft. Il dato non transita mai su Internet, questo riduce l’esposizione a minacce e aiuta a rispettare gli standard di compliance.

Figura 4 – Panoramica di Azure Private Link

Negli ambienti AKS gli Azure Private Link vengono solitamente creati nelle subnet della rete virtuale di Spoke per Azure Container Registry ed Azure KeyVault.

Si riporta uno schema con i flussi di rete in ingresso ed in uscita per un ambiente AKS, che prevede anche la presenza di Azure Firewall per controllare il traffico in uscita.

Figura 5 – Esempio dei flussi di rete in una tipica architettura AKS

Traffico di Management

Per poter consentire la gestione dell’ambiente, come la creazione di nuove risorse oppure per svolgere le attività per scalare l’ambiente cluster, è opportuno prevedere un accesso alle API Kubernetes. Buona norma è applicare dei filtri di rete per autorizzare in modo puntuale questo accesso.

Cluster AKS privato

Nel caso si voglia implementare un ambiente AKS totalmente privato, dove non viene esposto nessun servizio in Internet, è possibile adottare un cluster AKS in modalità “private”.

Conclusioni

La sempre più frequente richiesta di architetture applicative basate su microservizi che utilizzano Azure Kubernetes Service (AKS) richiede di individuare e realizzare architetture di rete progettate per essere sicure, flessibili e con un elevato livello di integrazione. Il tutto deve avvenire tramite un approccio moderno in grado di sfruttare a pieno le potenzialità offerte in ambito networking da Azure.

Azure Networking: comparativa tra il nuovo Azure Firewall e le virtual appliance di terze parti

La messa in sicurezza delle architetture di rete è un aspetto di fondamentale importanza anche quando si adotta il cloud pubblico e diventa ormai obbligata l’adozione di una soluzione firewall per proteggere e segregare al meglio i flussi di rete. Recentemente è stata annunciata la disponibilità di Azure Firewall Premium, il next generation firewall di Microsoft con interessanti funzionalità che possono risultare utili in ambienti altamente sensibili alla sicurezza e che necessità di un elevato livello di regolamentazione. In questo articolo vengono riportate le caratteristiche di questa nuova soluzione e viene fatta una comparativa con le Network Virtual Appliances (NVAs) di vendor di terze, per valutare la scelta di una opportuna “Firewall Strategy”.

Nuove funzionalità in Azure Firewall Premium

Azure Firewall è la soluzione di firewall-as-a-service (FWaaS) presente nel cloud pubblico di Microsoft, che consente di mettere in sicurezza le risorse presenti nelle Virtual Network di Azure e di governare i relativi flussi di rete.

Figura 1 – Panoramica di Azure Firewall Premium

Azure Firewall Premium utilizza Firewall Policy, una risorsa globale utilizzata per gestire centralmente i firewall tramite Azure Firewall Manager. Tutte le nuove funzionalità sono configurabili solo tramite Firewall Policy.

Nei capitoli seguenti vengono riportate le nuove funzionalità introdotte in Azure Firewall Premium.

TLS inspection

La tecnologia di sicurezza standard che consente di stabilire un collegamento crittografato tra un client ed un server è il Transport Layer Security (TLS), precedentemente noto come Secure Sockets Layer (SSL). Questo standard garantisce che tutti i dati che transitano tra i client ed il server rimangano privati e crittografati. Azure Firewall Premium è in grado di intercettare ed ispezionare le connessioni TLS. Per farlo viene effettuata una de-crittografia completa delle comunicazioni di rete, vengono eseguiti i controlli di sicurezza necessari e viene crittografato nuovamente il traffico che deve essere inviato alla destinazione.

La soluzione TLS Inspection di Azure Firewall Premium risulta ideale per i seguenti casi d’uso:

  • Terminazione TLS in uscita.

Figura 2 – TLS Inspection di Azure Firewall per il traffico in uscita

  • Terminazione TLS tra virtual network di spoke (est-ovest).
  • Terminazione TLS in ingresso con Application Gateway. Nei flussi di comunicazione Azure Firewall può essere distribuito dietro ad un Application Gateway. Adottando questa configurazione, il traffico Web in ingresso passa sia attraverso il WAF dell’Application Gateway sia attraverso il firewall di Azure. Il WAF fornisce una protezione a livello di applicazione Web, mentre Azure Firewall funge da punto centrale di controllo e di registrazione per ispezionare il traffico tra l’Application Gateway e i server di back-end. L’Azure Firewall può infatti de-crittografare il traffico ricevuto dall’Application Gateway per un’ulteriore ispezione e crittografarlo nuovamente prima di inoltrarlo al Web server di destinazione. Per maggiori dettagli su codesto caso d’uso è possibile consultare questo documento Microsoft.

Figura 3 – Implementazione dell’Application Gateway prima dell’Azure Firewall

Per abilitare la TLS Inspection in Azure Firewall Premium è opportuno utilizzare un certificato presente in un Azure Key Vault. L’accesso di Azure Firewall verso il key vault per recuperare i certificati avviene utilizzando una managed identity. Per maggiori informazioni in merito all’utilizzo dei certificati, per questa funzionalità di Azure Firewall Premium, è possibile consultare la documentazione ufficiale Microsoft.

Questi casi d’uso consentono ai clienti di adottare un modello zero trust e di implementare una segmentazione della rete tramite crittografia end-to-end.

IDPS

Un Intrusion Detection and Prevention system (IDPS) di rete consente di monitorare le attività di rete per rilevare quelle dannose, registrare informazioni su queste attività, segnalarle e, facoltativamente, tentare di bloccarle. Azure Firewall Premium fornisce IDPS basato sulle firme ed è in grado di consentire il rilevamento degli attacchi cercando pattern specifici, come sequenze di byte nel traffico di rete oppure sequenze di istruzioni dannose note utilizzate dai malware. Le firme IDPS sono automaticamente gestite e continuamente aggiornate.

Questa capacità funziona per tutte le porte ed i protocolli, ma nonostante alcuni rilevamenti possono essere eseguiti anche con il traffico crittografato, l’abilitazione della TLS Inspection è importante per utilizzare al meglio l’IDPS.

Figura 4 – Modalità dell’IDPS

URL filtering

La funzionalità di URL filtering permette di filtrare l’accesso in uscita verso specifici URL, e non solo per determinati FQDN. Vengono infatti estese la capacità di filtro FQDN di Azure Firewall per considerare un intero URL. Ad esempio, www.microsoft.com/a/b anziché solo www.microsoft.com. Questa funzionalità è efficace anche per il traffico crittografato se la TLS Inspection è abilitata.

L’URL filtering può anche essere utilizzata insieme alla categorizzazione Web per estendere una determinata categoria aggiungendo più URL in modo esplicito oppure per consentire/negare l’accesso agli URL all’interno della intranet dell’organizzazione.

Figura 5 – URL filtering nelle application rules

Categorizzazione Web

La categorizzazione Web nei criteri di Azure Firewall permette di consentire oppure negare l’accesso degli utenti a Internet in base a specifiche categorie, come ad esempio, social network, motori di ricerca, giochi d’azzardo, etc.

Questa funzionalità è possibile usarla come tipologia di destinazione nelle application rules nelle SKU sia Standard sia Premium di Azure Firewall. La differenza principale è che lo SKU Premium permette di ottenere un livello maggiore di ottimizzazione, classificando il traffico in base all’URL completo, tramite la funzionalità di TLS Inspection, mentre lo SKU standard classifica il traffico solamente in base all’FQDN. Questa funzione permette di avere la visibilità ed il controllo nell’utilizzo del traffico Internet di un’organizzazione ed è ideale per controllare la navigazione Internet per i client Windows Virtual Desktop.

Figura 6 – Categorizzazione Web in una regola di accesso

Azure Firewall Premium vs Network Virtual Appliances (NVAs) di terze parti

Le Network Virtual Appliances (NVAs) fornite da vendor di terze parti e disponibili nel marketplace di Azure sono numerose e possono offrire funzionalità avanzate. Tipicamente la configurazione di queste soluzioni è più articolata e il costo è tendenzialmente più elevato rispetto alle soluzioni fornite dalla piattaforma Azure.

Il divario tra le funzionalità di Azure Firewall, grazie alle funzionalità Premium, e le NVAs di terze parti è ora molto ridotto.

Si riporta una comparativa ad alto livello tra Azure Firewall Premium e le NVAs:

Figura 7 – Comparativa funzionalità Azure Firewall Premium vs NVAs

Il set di funzionalità di Azure Firewall è pertanto adatto per la maggior parte dei clienti e fornisce alcuni vantaggi chiave essendo un servizio gestito nativo del cloud, come ad esempio:

  • Integrazione con i modelli DevOps e con altri artifacts Azure (es. tag, impostazioni di diagnostica).
  • L’alta disponibilità è integrata nel servizio e non sono richieste configurazioni specifiche o componenti aggiuntivi per renderla effettiva. Questo è sicuramente un elemento che lo distingue rispetto a soluzioni di terze parti che, per la configurazione delle Network Virtual Appliance (NVA) in HA, richiedono tipicamente la configurazione di load balancer aggiuntivi.
  • Azure Firewall consente di scalare facilmente per adeguarsi ad eventuali cambi dei flussi di rete.
  • Non è necessaria nessuna attività di manutenzione.
  • Notevole risparmio sul TCO per la maggior parte dei clienti. Infatti, per le NVAs è opportuno considerare:
    • Costi computazionali (almeno due macchine virtuali per l’HA)
    • Costi di licensing
    • Costi per gli standard load balancer (interni ed esterni)
    • Costi di manutenzione
    • Costi per il supporto

Risulta comunque opportuno specificare che per alcuni clienti le soluzioni di terze parti sono più adatte in quanto consentono di dare una continuità nell’esperienza d’uso rispetto alle soluzioni già attive nell’ambiente on-premises.

Conclusioni

Con il rilascio della SKU Premium Azure Firewall diventa un next generation firewall completamente integrato nella fabric di Azure, che mette a disposizione funzionalità molto interessanti, al punto da renderlo la scelta ideale per i clienti con esigenze avanzate di controllo e di sicurezza del proprio networking di Azure.

Come effettuare il monitor, diagnosticare problemi e ottenere informazioni dettagliate sul networking con gli strumenti di Azure

Le architetture di rete nel cloud pubblico hanno particolarità e introducono concetti che le differenziano in modo sostanziale rispetto a quelle tradizionali presenti nell’ambiente on-premises. Un aspetto però che le accomuna è sicuramente la necessità di doverle monitorare, verificando costantemente le prestazioni e lo stato di salute. Per fare tutto questo in modo efficace, contemplando le particolarità intrinseche del cloud pubblico ed architetture di rete ibride è opportuno dotarsi di strumenti efficaci. In questo articolo vengono riportare le caratteristiche del servizio di piattaforma Azure Network Watcher, che fornisce una suite di strumenti per monitorare, diagnosticare e visualizzare le metriche ed i log delle risorse di rete.

Network Watcher è stato progettato per effettuare il monitor e controllare l’integrità dell’infrastruttura di rete, anche in ambienti ibridi, in modo specifico per i componenti IaaS (Infrastructure-as-a-Service) attestati sulle virtual network di Azure. Network Watcher non mette a disposizione strumenti per monitorare l’infrastruttura PaaS (Platform-as-a-Service) oppure per effettuare l’analisi di componenti web.

Network Watcher è un servizio regionale, zone-resilient e totalmente gestito. L’abilitazione del componente avviene ora di default per ogni subscription Azure che contiene delle virtual network. Le risorse Network Watcher vengono posizionate di default nel resource group, nascosto e creato automaticamente, chiamato NetworkWatcherRG.

Gli strumenti inclusi in Azure Network Watcher possono essere suddivisi in tre categorie in base alle funzionalità offerte: Monitoring, Diagnostica e Logging

Strumenti di Monitoring

Topology view

In architetture di rete particolarmente complesse può risultare utile individuare quali risorse sono attestate su una specifica virtual network e come si relazionano tra loro. Grazie a questo strumento è possibile visualizzare direttamente nel portale di Azure un diagramma visivo dei componenti presenti in una specifica rete virtuale e le relazioni presenti tra le varie risorse.

Figura 1 – Esempio di una Topology view

Connection Monitor

Connection Monitor è stato recentemente rivisto e nella versione 2.0 permette di monitorare le connessione end-to-end sia in ambienti Azure che in presenza di architetture di rete ibride.

Tra i principali punti di forza di questa nuova soluzione troviamo:

  • Esperienza di monitor unificata ed intuitiva sia per ambienti totalmente dislocati in Azure che per ambienti ibridi.
  • Monitor della connettività, anche cross-region, e verifica delle latenze di rete verso gli endpoint.
  • Frequenze di probing elevate che permettono di ottenere una maggiore visibilità sulle performance di rete.
  • Avvisi più immediati per segnalare condizioni anomale in presenza di architetture di rete ibride.
  • Possibilità di fare dei check di connettività basati sui protocolli HTTP, TCP, e ICMP.
  • Supporto del salvataggio dei dati nelle metriche di Azure Monitor e nei workspace di Log Analytics.

Figura 2 – Panoramica dello strumento Connection Monitor

Per fare in modo che Connection Monitor sia in grado di riconoscere le VMs di Azure come origini per le attività di monitor, è necessario installare su di esse la Network Watcher Agent virtual machine extension.

Network Performance Monitor

Network Performance Monitor è ora parte integrante di Connection Monitor e pertanto incluso in Azure Network Watcher. La soluzione richiede la presenza dell’agent di Azure Monitor e, grazie all’utilizzo di transazioni sintetiche, fornisce la possibilità di monitorare i parametri di rete in architetture di rete ibride, per avere le informazioni relative alle performance, come la perdita di pacchetti e la latenza. Inoltre, questa soluzione consente di localizzare facilmente la sorgente di una problematica in uno specifico segmento di rete oppure identificando un determinato dispositivo. La soluzione, tenendo traccia dei pacchetti di retransmission e del tempo di roundtrip, è in grado di restituire un grafico di facile e immediata interpretazione. Inoltre, permette di verificare le performance tra l’ambiente on-premises ed Azure, anche in presenza di connettività ExpressRoute.

Strumenti di Diagnostica

IP Flow Verify

In determinate circostanze, può accadere che una macchina virtuale non è in grado di comunicare con altre risorse, a causa delle regole di sicurezza presenti. Questa funzionalità permette di specificare un indirizzo IPv4 di origine e di destinazione, una porta, un protocollo (TCP o UDP) e la direzione del traffico (in entrata o in uscita). IP Flow Verify verifica la comunicazione e informa se la connessione ha esito positivo oppure negativo. Se la connessione non riesce, viene indicata quale regola di sicurezza ha negato la comunicazione, in modo da poter risolvere la problematica.

Next Hop

Questo strumento aiuta a verificare le rotte del traffico di rete e permette di rilevare eventuali problemi di instradamento. La funzionalità Next Hop consente di specificare un indirizzo IPv4 di origine e di destinazione e di verificarne la relativa comunicazione.

Connection Troubleshoot

Questo strumento consente di controllare una tantum la connettività e la latenza tra una macchina virtuale e un’altra risorsa di rete, che può essere un’altra macchina virtuale, un FQDN, un URI oppure un indirizzo IPv4. Il test restituisce informazioni simili a quelle restituite quando si utilizza Connection Monitor, ma la verifica sulla connessione avviene in un determinato momento, anziché effettuare un monitor nel tempo come avviene per Connection Monitor.

Packet Capture

Grazie a questo strumento è possibile catturare in modo versatile il traffico di rete su una macchina virtuale di Azure, applicando eventuali opzioni di filtro avanzate e impostando limiti di tempo e di dimensione. L’acquisizione può essere archiviata in Azure Storage, sul disco della VM oppure in entrambe le posizioni. Il traffico di rete catturato è poi possibile analizzarlo con diversi strumenti standard di analisi, come ad esempio Wireshark.

VPN Troubleshoot

Questo strumento esegue diversi controlli diagnostici sui VPN gateway e sulle relative connessioni, utili per risolvere le problematiche.

Le funzionalità Packet Capture e Connection Troubleshoot richiedono la presenza sulle VMs dell’extension Network Watcher, così come riportato per Connection Monitor.

Strumenti di Logging

NSG Flow Logs

In Azure per poter consentire o negare la comunicazione di rete verso le risorse connesse alle Azure Virtual Networks (VNet) vengono utilizzati i Network Security Group (NSG), che contengono una lista di regole di accesso. I NSG vengono solitamente applicati alle subnet (scelta consigliata) oppure direttamente alle interfacce di rete connesse alle macchine virtuali. La piattaforma Azure utilizza i NSG flow logs per mantenere la visibilità del traffico di rete in ingresso e in uscita dai Network Security Group.

Traffic Analytics

Traffic Analytics si basa sull’analisi dei NSG flow logs e dopo una opportuna aggregazione dei dati, inserendo l’intelligence necessaria relativamente a security, topologia e mappa geografica, è in grado di fornire informazioni dettagliate sul traffico di rete del proprio ambiente cloud Azure.

Figura 3 – Data flow di Traffic Analytics

Utilizzando Traffic Analytics si possono effettuare le seguenti operazioni:

  • Visualizzare le attività di rete cross Azure subscriptions e identificare hotspots.
  • Intercettare potenziali minacce di security lato network, per poi poter adottare le giuste operazioni correttive. Questo viene reso possibile grazie alle informazioni riportate dalla soluzione: quali porte sono aperte, quali applicazioni tentano di accedere verso Internet e quali macchine virtuali si connettono a reti non autorizzate.
  • Comprendere i flussi di rete presenti tra le varie region Azure e Internet, al fine di ottimizzare il proprio deployment di rete in termini di performance e capacità.
  • Individuare configurazioni di rete non corrette che portano ad avere tentativi di comunicazione errati.

Figura 4 – Virtual Network in Traffic Analytics

Il costo di Network Watcher è dettagliato nella pagina ufficiale Microsoft e dipende dall’utilizzo che ne viene fatto dei vari strumenti inclusi nella soluzione.

Conclusioni

All’aumentare della complessità delle architetture di rete Azure ed in presenza in ambienti ibridi, è utile disporre di strumenti particolarmente efficaci e di facile utilizzo per poter effettuare il monitor. Azure mette a disposizione diversi strumenti integrati nella piattaforma che oltre al monitor permettono di diagnosticare problematiche di diversa natura ed ottenere una visibilità complessiva delle proprie risorse di rete in modo semplice e intuitivo.

Azure Application delivery: quale servizio di load balancing scegliere?

La transizione verso soluzioni cloud per erogare le applicazioni è una tendenza che procede a un ritmo molto elevato e garantire un accesso rapido, sicuro ed affidabile a tali applicazioni è un’attività sfidante che deve essere indirizzata adottando le giuste soluzioni. Microsoft Azure mette a disposizione una vasta gamma di servizi per garantire una erogazione ottimale delle applicazioni, ma nella valutazione di quale soluzione di load-balancing adottare ci sono diversi aspetti da prendere in considerazione. Questo articolo vuole fare chiarezza sugli elementi che è opportuno valutare per adottare la soluzione Azure più idonea in questo ambito.

L’esigenza di distribuire i carichi di lavoro su più risorse di elaborazione può essere data dalla necessità di ottimizzare l’uso delle risorse, massimizzare il throughput, ridurre al minimo i tempi di risposta ed evitare di sovraccaricare ogni singola risorsa. Inoltre, può essere rivolta anche a migliorare la disponibilità delle applicazioni condividendo un carico di lavoro tra risorse di elaborazione ridondanti.

Servizi di load balancing di Azure

Per erogare servizi di load-balancing di Azure troviamo i seguenti componenti.

Azure Load Balancer e cross-region Azure Load Balancer: si tratta di componenti che consentono il bilanciamento del carico Layer-4 per tutti i protocolli TCP e UDP, garantendo alte prestazioni e bassissime latenze. Azure Load Balancer è un componente zone-redundant, pertanto offre un’elevata disponibilità tra le Availability Zones.

Figura 1 – Panoramica di Azure Load Balancer e cross-region Azure Load Balancer

Azure Application Gateway: si tratta di un servizio gestito dalla piattaforma Azure, con funzionalità intrinseche di alta disponibilità e scalabilità. L’Application Gateway è un load balancer applicativo (OSI layer 7) per il traffico web, che consente di governare il traffico HTTP e HTTPS delle applicazioni (URL path, host based, round robin, session affinity, redirection). L’Application Gateway è in grado di gestire in modo centralizzato i certificati per la pubblicazione applicativa, tramite policy SSL ed effettuando SSL offload quando necessario. L’Application Gateway può avere assegnato un indirizzo IP Privato oppure un indirizzo IP Pubblico, se la ripubblicazione applicativa deve avvenire verso Internet. In particolare, in quest’ultimo caso, è consigliato attivare la funzionalità di Web Application Firewall (WAF), che consente di ottenere una protezione applicativa, basandosi su regole OWASP core rule sets. Il WAF protegge l’applicativo da vulnerabilità e da attacchi comuni, come ad esempio attacchi X-Site Scripting e SQL Injection.

Figura 2 – Panoramica di Azure Application Gateway

Front Door: è un application delivery network che fornisce bilanciamento del carico a livello globale e un servizio di site accelleration per le applicazioni web. Offre funzionalità Layer-7 per la pubblicazione applicativa come ad esempio SSL offload, path-based routing, fast failover, caching, al fine di migliorare le prestazioni e l’alta disponibilità delle applicazioni.

Figura 3 – Panoramica di Azure Front Door

Traffic Manager: è un servizio di bilanciamento del carico basato su DNS che consente di distribuire il traffico in modo ottimale ai servizi distribuiti in differenti region di Azure, fornendo al contempo alta disponibilità e responsività. Sono disponibili diversi metodi di instradamento per determinare verso quale endpoint dirigere il traffico. Basandosi su DNS, il failover può non essere immediato a causa delle sfide comuni relative al caching DNS e ai sistemi che non rispettano i TTL del DNS.

Figura 4 – Panoramica di Azure Traffic Manager (performance traffic-routing method)

Aspetti da valutare nella scelta dei servizi di load balancing di Azure

Ogni servizio ha le proprie caratteristiche e per scegliere quello più opportuno è bene fare una classificazione rispetto ai seguenti aspetti.

Servizi di load-balancing: globali vs regionali

  • Global load-balancing: vengono utilizzati per distribuire il traffico verso i backend distribuiti globalmente su più region, i quali possono essere dislocati in ambienti cloud oppure ibridi. Rientrano in questa categoria Azure Traffic Manager, Azure Front Door ed i cross-region Azure Load Balancer.
  • Regional load-balancing: consentono di distribuire il traffico verso le macchine virtuali attestate su una specifica virtual network oppure verso endpoint in una specifica region. Rientrano in questa categoria gli Azure Load Balancer e gli Azure Application Gateway.

Tipologia di traffico: HTTP(S) vs non-HTTP(S)

Un’altra importante discriminante nella scelta della soluzione di load-balancing da adottare è la tipologia di traffico che si deve gestire:

  • HTTP(S): è consigliata l’adozione di servizi di load-balancing Layer-7 che accettano solo traffico HTTP(S). Sono adatti per questa tipologia di traffico Azure Front Door ed Azure Application Gateway. Tipicamente vengono utilizzati per applicazioni web oppure per altri endpoint HTTP(S) e includono funzionalità come: SSL offload, web application firewall, path-based load balancing, e session affinity.
  • Non-HTTP(S): viene richiesto l’utilizzo di servizi di load-balancing che permettono di contemplare il traffico non-HTTP(S), come Azure Traffic Manager, cross-region Azure Load Balancer e Azure Load Balancer.

Nella valutazione del servizio Azure di load-balancing da adottare è opportuno far rientrare anche considerazioni riguardanti i seguenti aspetti:

Per facilitare la scelta della soluzione di load-balancing è possibile utilizzare come base di partenza il seguente diagramma di flusso, che indirizza la scelta su una serie di aspetti chiave:

Figura 5 – Flowchart per la scelta della soluzione Azure di load-balancing

NOTA: Questo flowchart non contempla i cross-region Azure Load Balancer in quanto al momento (11/2020) sono in preview.

Questo diagramma di flusso è un ottimo punto di inizio per le proprie valutazioni, ma siccome ogni applicazione ha requisiti unici è bene effettuare un’analisi specifica più di dettaglio.

Se l’applicazione è composta da più workload è opportuno valutare ciascuno di questi in modo separato, in quanto può essere necessario adottare una o più soluzioni di bilanciamento del carico.

I vari servizi di load load-balancing possono essere utilizzati in combinazione tra loro per garantire un accesso applicativo affidabile e sicuro ai servizi erogati in ambienti IaaS, PaaS oppure on-premises.

Figura 6 – Possibile esempio di come combinare i vari servizi di load-balancing di Azure

Conclusioni

Grazie ad un’ampia gamma di servizi globali e regionali Azure è in grado di garantire performance, sicurezza ed alta disponibilità nell’accesso agli applicativi. Per stabilire l’architettura più idonea alle proprie esigenze sono diversi gli elementi da valutare, ma la giusta combinazione delle soluzioni di Application Delivery di Azure permette di fornire un notevole valore alle organizzazioni IT, garantendo una distribuzione veloce, sicura ed affidabile delle applicazioni e dei dati all’utente.

Azure Networking: come monitorare ed analizzare i log di Azure Firewall

Nelle architetture di rete in Azure dove è presente Azure Firewall, la soluzione di firewall-as-a-service (FWaaS) che consente di mettere in sicurezza le risorse presenti nelle Virtual Network e di governare i relativi flussi di rete, diventa strategico adottare degli strumenti per monitorare in modo efficace i relativi log. In questo articolo viene esplorato come interpretare al meglio i log e come è possibile fare analisi approfondite di Azure Firewall, un componente che spesso detiene un ruolo fondamentale nelle architetture di rete in Azure.

Un aspetto importante da verificare è che in Azure Firewall siano correttamente configurate le impostazioni di diagnostica, per far confluire i dati di log e le metriche verso un workspace di Azure Monitor Log Analytics.

Figura 1 – Impostazioni di diagnostica di Azure Firewall

Per avere una panoramica complessiva dei diagnostic logs e delle metriche disponibili per Azure Firewall è possibile consultare la specifica documentazione di Microsoft.

Uno dei metodi più efficaci per visualizzare ed analizzare i log di Azure Firewall è utilizzare i Workbooks, che consentono di combinare testo, query di Log Analytics, metriche di Azure e parametri, costituendo così dei report interattivi e facilmente consultabili.

Per Azure Firewall è presente un workbook specifico fornito da Microsoft che permette di ottenere informazioni dettagliate sugli eventi, conoscere le application e le network rule attivate e visualizzare le statistiche sulle attività del firewall per URL, porte e indirizzi.

L’importazione di questo workbook può avvenire tramite ARM template oppure Gallery template, seguendo le istruzioni riportate in questo articolo.

Figura 2 – Importazione del workbook di Azure Firewall

Completato il processo di importazione è possibile consultare nella pagina di overview una panoramica dei diversi eventi e delle tipologie di log presenti (application, networks, threat intel, DNS proxy), con la possibilità di applicare dei filtri specifici relativi ai workspace, alla fascia oraria ed ai firewall.

Figura 3 – Azure Firewall Workbook overview

Nel workbook è presente una sezione specifica per le Application rule dove vengono mostrate le origini per indirizzo IP, l’utilizzo delle application rule, e gli FQDN negati e consentiti. Inoltre, è possibile applicare dei filtri di ricerca sui dati delle Application rule.

Figura 4 – Azure Firewall Workbook – Application rule log statistics

Inoltre, nella sezione Network Rule è possibile visualizzare le informazioni in base alle azioni compiute dalle regole (allow/deny), alle target port e alle azioni DNAT.

Figura 5 – Azure Firewall Workbook – Network rule log statistics

Nel caso Azure Firewall sia stato impostato per funzionare anche come DNS Proxy è possibile visualizzare nel tab “Azure Firewall – DNS Proxy” del Workbook anche informazioni riguardanti il traffico e le richieste DNS gestite.

Qualora si renda necessario effettuare degli approfondimenti per ottenere maggiori informazioni sulle comunicazioni di specifiche risorse è possibile utilizzare la sezione Investigation andando ad agire sui filtri a disposizione.

Figura 6 – Azure Firewall Workbook – Investigation

Per visualizzare ed analizzare gli activity log è possibile connettere i log di Azure Firewall ad Azure Sentinel, il servizio che amplia le capacità dei tradizionali prodotti SIEM (Security Information and Event Management), utilizzando le potenzialità del cloud e l’intelligenza artificiale. In questo modo, tramite workbook specifici disponibili in Azure Sentinel, è possibile ampliare le capacità di analisi e creare alert specifici per poter identificare e gestirerapidamente le minacce di security che interessano questo componente di infrastruttura. Per connettere i log di Azure Firewall ad Azure Sentinel è possibile seguire la procedura riportata in questo documento Microsoft.

Conclusioni

Azure Firewall è un servizio ampliamene utilizzato e spesso è il fulcro della propria architettura network in Azure, dove transitano e vengono controllate tutte le comunicazioni di rete. Diventa pertanto importante datarsi di uno strumento per analizzare le metriche e le informazioni raccolte, in grado di fornire anche un valido supporto nella risoluzione di eventuali problemi ed incident. Grazie all’adozione di questi Workbooks è possibile consultare agilmente i dati raccolti da Azure Firewall, utilizzando report visivamente accattivanti, con funzionalità avanzate che consentono di arricchire l’esperienza di analisi direttamente dal portale di Azure.

Azure Networking: nuove funzionalità da conoscere per progettare al meglio le architetture di rete

Le soluzioni cloud evolvono molto rapidamente e rimanere costantemente aggiornati è un elemento fondamentale per innovarsi e per saper rispondere efficacemente ai cambiamenti tecnologici. Con il cambio di passo imposto dalla digital transformation anche le infrastrutture di rete devono essere sempre più efficienti, flessibili ed in grado di erogare al meglio i servizi richiesti dal business aziendale. Per modernizzare la propria strategia di progettazione e di implementazione in ambito Azure Networking è perciò importante valutare come evolvono le varie tecnologie. In questo articolo vengono riportate le novità recentemente rilasciate da Microsoft e che possono interessare la progettazione del networking di Azure, con dei riferimenti a dei casi d’uso reali.

Azure Bastion e VNet peering

Azure Bastion è un servizio PaaS che offre un accesso RDP ed SSH sicuro e affidabile alle macchine virtuali, direttamente tramite il portale di Azure. Il provisioning del servizio Azure Bastion viene effettuato all’interno di una Virtual Network di Azure e consente l’accesso senza dover assegnare degli indirizzi IP pubblici direttamente ai sistemi.

La novità è che ora Azure Bastion può lavorare in sinergia con i Virtual Network (VNet) peering. Questo significa che è possibile attivare Azure Bastion su una VNet specifica e lo stesso servizio può essere utilizzato per connettersi anche alle macchine virtuali attestate sulle VNet in peering con questa.

Azure Bastion funziona sia in presenza di network peering che collegano VNet sulla stessa region di Azure, sia con VNet peering di tipologia global, che collegano VNet dislocate in region di Azure differenti. Dal punto di vista delle architetture di rete questa possibilità apre nuovi possibili scenari. Nel modello di rete tipico ed ampiamente utilizzato, definito hub-and-spoke, si ha una rete virtuale in Azure di hub che funge da punto di connettività verso la rete on-premises e le reti virtuali che eseguono il peering con l’Hub vengono definite spoke, utili per isolare i carichi di lavoro. Adottando questo modello è possibile attivare Azure Bastion sulla rete di hub. In questo modo sarà possibile raggiungere con un unico servizio Azure Bastion anche tutte le macchine virtuali distribuite nelle VNet di spoke.

Figura 1 – Azure Bastion in una architettura hub-and-spoke

Nel diagramma seguente viene riportato il deployment di Azure Bastion in una architettura di rete hub-and-spoke dove:

  • Il Bastion host viene attivato nella rete virtuale centralizzata di Hub.
  • Vengono consentite le comunicazioni, per le porte TCP 3389 e 22, provenienti dalla subnet di Azure Bastion presente nella virtual network di Hub, verso gli IP privati delle virtual network di Spoke.
  • Nessun IP pubblico viene richiesto per accedere alle macchine virtuali.

Grazie a questa configurazione sarà possibile semplificare l’architettura e ridurre i costi Azure, in quanto sarà necessario un solo servizio Azure Bastion per l’intera topologia di rete hub-and-spoke.

Inoltre, può essere effettuato il provisioning di Azure Bastion anche in topologie di rete full-mesh, ottenendo la medesima esperienza di accesso ai sistemi in modalità RDP / SSH per le VMs attestate su tutte le virtual network in peering.

Si riportano alcune osservazioni in merito:

  • Risulta possibile avere attivi contemporaneamente più Bastion hosts tra virtual network in peering. Questo può accadere in particolare nel periodo di transizione, quando si vogliono consolidare diversi Bastion hosts secondo la topologia hub-and-spoke sopra descritta. In presenza di più Bastion host, quando si effettuerà la connessione, sarà proposto di scegliere quale Bastion host utilizzare.
  • Attualmente Azure Bastion supporta gli scenari di virtual network in peering solo se queste risiedono in subscription appartenenti allo stesso tenant.

Azure Firewall: nuove impostazioni DNS

Azure Firewall è la soluzione di firewall-as-a-service (FWaaS) presente nel cloud pubblico di Microsoft, che consente di mettere in sicurezza le risorse presenti nelle Virtual Network di Azure e di governare i relativi flussi di rete. Le funzionalità di Azure Firewall sono state arricchite aggiungendo il supporto dei custom DNS e del DNS proxy.

Custom DNS

Per impostazione predefinita Azure Firewall utilizza i DNS di Azure per la risoluzione dei nomi. Ora è stata inclusa la possibilità di configurare Azure Firewall per utilizzare dei server DNS specifici.

Nelle impostazioni è possibile configurare un singolo server DNS oppure più server DNS:

Figura 2 – Impostazione dei custom DNS in Azure Firewall dal portale Azure

Azure Firewall può effettuare la risoluzione dei nomi anche utilizzando Azure Private DNS. In questo scenario è richiesto che la VNet all’interno della quale risiede Azure Firewall sia collegata all’Azure Private Zone.

DNS proxy

Azure Firewall può ora essere configurato per svolgere il ruolo di DNS proxy. Abilitando questa nuova funzionalità è possibile configurare come DNS delle virtual network l’indirizzo IP privato di Azure Firewall. In questo modo tutto il traffico DNS viene indirizzato verso Azure Firewall, il quale funge da intermediario tra i sistemi che effettuano le richieste DNS e i server DNS stessi, evitando in questo modo possibili incoerenze nelle risoluzioni dei nomi se vengono utilizzati dei DNS custom.

Quando il firewall di Azure agisce come DNS proxy, sono previste due tipologie di cache:

  • Positive cache: la risoluzione DNS va a buon fine. In questo caso Azure Firewall utilizza il TTL (time to live) del pacchetto o dell’oggetto.
  • Negative cache: la risoluzione DNS non va a buon fine. In questo caso le informazioni vengono memorizzate nella cache di Azure Firewall per un’ora.

Figura 3 – Configurazione di Azure Firewall come DNS proxy dal portale Azure

Questa funzionalità consente di valutare un nuovo scenario di utilizzo per Azure Firewall, molto utile quando si ha la necessità di gestire la risoluzione DNS in presenza dei Private Link, il meccanismo che permette di instaurare una connessione privata verso i servizi in Azure.

Ad ogni servizio PaaS di Azure che utilizza Azure Private Link viene assegnato un FQDN mappato e archiviato in una Azure Private DNS zone. Le richieste inviate verso le Azure DNS Private Zones vengono indirizzate all’IP di piattaforma 168.63.129.16, il quale è raggiungibile solo dall’interno dell’ambiente Azure. Per questa ragione, se la richiesta DNS ha origine dai sistemi on-premises (o comunque dall’esterno di Azure), è necessario attivare un DNS proxy all’interno di una rete virtuale di Azure connessa all’ambiente on-premise. Grazie a questa nuova funzionalità di DNS proxy di Azure Firewall è possibile gestire questa sfida di risoluzione dei nomi dei servi PaaS che utilizzano Private Link con i seguenti step:

  • La VNet all’interno della quale risiede Azure Firewall la si collega all’Azure Private Zone.
  • Azure Firewall lo si configura per utilizzare il DNS predefinito di Azure e si abilita la funzionalità di DNS Proxy.
  • Si configura il server DNS locale per inoltrare in modo condizionale le richieste ad Azure Firewall per il nome della zona richiesto.

Azure Firewall: utilizzo di FQDN filtering nelle network rule

Nelle Network Rule di Azure Firewall è ora possibile utilizzare dei fully qualified domain name (FQDN) basati sulla risoluzione DNS di Azure Firewall. Questa funzionalità permette di filtrare il traffico in uscita per qualsiasi protocollo TCP / UDP (NTP, SSH, RDP, etc.) e richiede che sia attiva la funzionalità di DNS proxy descritta nel paragrafo precedente. Azure Firewall, quando configurato come DNS proxy, archivia tutti gli indirizzi IP risolti dagli FQDN utilizzati nelle network rule. Per questa ragione come best practice è bene utilizzare gli FQDN nelle network rule.

Azure Firewall, sia per le application rule che per le network rule, converte l’FQDN in uno o più indirizzi IP in base al server DNS selezionato (Azure DNS oppure DNS personalizzato). Nel momento in cui avviene una nuova risoluzione DNS vengono aggiunti i nuovi indirizzi IP alle regole del firewall, mentre gli indirizzi IP che non vengono più restituiti dal server DNS hanno una scadenza di 15 minuti. Le Network Rule di Azure Firewall vengono aggiornate ogni 15 secondi utilizzando la risoluzione DNS. Se si ha la necessità di applicare dei filtri FQDN rimane comunque buona norma utilizzare sempre le application rule di Azure Firewall per i protocolli HTTP/S oppure MSSQL, mentre per tutti i restanti protocolli è possibile utilizzare sia le application rule che le network rule.

Nuove funzionalità per gli Azure VPN gateway

In seguito, si riportano le nuove funzionalità che è possibile adottare in presenza degli Azure VPN gateway:

  • Alta disponibilità dei server RADIUS nelle VPN point-to-site: questa funzionalità consente di effettuare una configurazione in alta disponibilità presso i clienti che utilizzano l’autenticazione RADIUS/AD per le VPN point-to-site.
  • Policy IPsec/IKE personalizzate con timeout DPD: l’impostazione del timeout IKE DPD (Dead Peer Detection) consente di regolare il valore di timeout della sessione IKE in base alla latenza di connessione e alle condizioni del traffico. Questa configurazione risulta utile per ridurre al minimo le disconnessioni del tunnel, migliorando l’affidabilità e l’esperienza di utilizzo.
  • Supporto APIPA per gli annunci BGP: questa funzione consente di stabilire sessioni Border Gateway Protocol (BGP), con i VPN gateway di Azure, usando indirizzi APIPA (169.254.x.x). Questa funzionalità è utile in particolare per i clienti con router VPN legacy, Amazon Web Service (AWS) VGW, Google Cloud Platform (GCP) VPN che utilizzano indirizzi APIPA (Automatic Private IP Addressing) per annunciare gli indirizzi BGP.
  • Supporto dei nomi FQDN per le VPN site-to-site: questa funzionalità consente di configurare le VPN site-to-site in presenza di apparati che non dispongono di indirizzi IP pubblici statici per connettersi ai VPN gateway di Azure. Risulta infatti possibile utilizzare il nome di dominio completo (FQDN) anziché gli indirizzi IP. I VPN gateway di Azure saranno in grado di effettuare la risoluzione del nome DNS, aggiornando automaticamente la destinazione per stabilire le connessioni IPsec/IKE della VPN.
  • Gestione delle sessioni e revoca degli utenti per le VPN point-to-site: viene data la possibilità di elencare e revocare le connessioni dei singoli utenti ai VPN gateway, direttamente dal portale di Azure ed in tempo reale.

Conclusioni

Diverse sono le novità rilasciate recentemente da Microsoft in ambito Azure networking ed è opportuno valutarle attentamente per effettuare una progettazione accurata. In questo modo sarà possibile realizzare architetture di rete efficaci, ottimizzando i costi ed in grado di sfruttare tutte le potenzialità offerte dalla piattaforma Azure.

Microsoft Always On VPN: l’accesso trasparente alla rete aziendale adatto in scenari di smart working

La tecnologia può svolgere un ruolo importante nel ridurre l’impatto di COVID-19 sulle persone e sulle realtà aziendali, aiutando il personale a rimanere produttivo quando non è in grado di essere fisicamente presso il proprio posto di lavoro. In questi giorni di emergenza le aziende sono state costrette ad adottare in tempi rapidi soluzioni efficaci per consentire ai propri dipendenti di lavorare da remoto senza sacrificare la collaborazione, la produttività e la sicurezza. Le soluzioni che è possibile adottare in questo ambito sono differenti, ciascuna con le proprie caratteristiche e peculiarità, in grado di rispondere a differenti esigenze. In questo articolo vengono riportate le principali caratteristiche della tecnologia Microsoft Always On VPN, per valutarne i vantaggi e quali sono i principali casi d’uso della soluzione.

Caratteristiche principali di Always On VPN

A partire da Windows Server 2016 e versioni successive Microsoft ha introdotto una nuova tecnologia di accesso remoto degli endpoint denominata Always On VPN che permette un accesso trasparente alla rete aziendale, rendendola particolarmente adatta in scenari di smart working.  Si tratta dell’evoluzione della tecnologia DirectAccess che, per quanto efficace, presentava delle limitazioni che ne rendevano difficile l’adozione.

Come dice il nome, la VPN è “sempre attiva”, infatti una connessione sicura alla rete aziendale viene stabilita automaticamente ogni volta che un client autorizzato ha connettività Internet, il tutto senza richiedere all’utente input oppure interazione, a meno che non sia abilitato un meccanismo di autenticazione a più fattori. Gli utenti remoti accedono ai dati e alle applicazioni aziendali allo stesso modo, proprio come se fossero sul posto di lavoro.

Le connessioni Always On VPN includono le seguenti tipologie di tunnel:

  • Device Tunnel: il dispositivo si collega ai server VPN prima che gli utenti accedano al dispositivo stesso.
  • User Tunnel: si attiva solo dopo che gli utenti hanno effettuato l’accesso al dispositivo.

Utilizzando Always On VPN è infatti possibile avere una connessione utente, del dispositivo, oppure una combinazione di entrambe. Sia il Device Tunnel che lo User Tunnel funzionano infatti in modo indipendente e possono utilizzare diversi metodi di autenticazione. Risulta pertanto possibile abilitare l’autenticazione del dispositivo per gestirlo remotamente tramite il Device Tunnel, ed abilitare l’autenticazione utente per la connettività alle risorse interne all’azienda attraverso lo User Tunnel. Lo User Tunnel supporta SSTP e IKEv2, mentre il Device Tunnel supporta solamente IKEv2.

Scenari supportati

La tecnologia Always On VPN è una soluzione solo per sistemi Windows 10. Tuttavia, a differenza di DirectAccess, i dispositivi client non devono necessariamente eseguire l’edizione Enterprise, ma tutte le versioni di Windows 10 supportano questa tecnologia, adottando la tipologia di tunnel definita User Tunnel. In questo scenario i dispositivi possono essere membri di un dominio Active Directory, ma ciò non è strettamente necessario. I client Always On VPN possono essere nondomain-joined (workgroup), pertanto anche di proprietà personale dell’utente. Per sfruttare determinate funzionalità avanzate, i client possono essere in join ad Azure Active Directory. Solamente per utilizzare il Device Tunnel è richiesto che i sistemi siano in join a un dominio e devono necessariamente avere Windows 10 Enterprise oppure Education. In questo scenario è consigliata la versione 1809 o successiva.

Requisiti di infrastruttura

Per poter implementare una architettura Always On VPN è necessaria la presenza dei seguenti componenti di infrastruttura, molti dei quali sono tipicamente già attivi nelle realtà aziendali:

  • Domain Controllers
  • DNS Servers
  • Network Policy Server (NPS)
  • Certificate Authority Server (CA)
  • Routing and Remote Access Server (RRAS)

Figura 1 – Panoramica della tecnologia VPN Always On

In questo contesto è opportuno specificare che Always On VPN è indipendente dall’infrastruttura e può essere attivata utilizzando il ruolo Windows Routing and Remote Access (RRAS) oppure adottando un qualsiasi dispositivo VPN di terze parti. Anche l’autenticazione può essere fornita dal ruolo Windows Network Policy Server (NPS) oppure da una qualsiasi piattaforma RADIUS di terze parti.

Per maggiori dettagli sui requisiti necessari è possibile fare riferimento alla documentazione ufficiale Microsoft.

Always On VPN in ambiente Azure?

In generale, è consigliabile far stabilire agli endpoint le connessioni VPN il più vicino possibile alle risorse a cui devono accedere. Per le realtà con ambienti ibridi, esistono diverse opzioni per posizionare l’architettura Always On VPN. Il deployment del ruolo Remote Access su una macchina virtuale in ambiente Azure non è supportato, tuttavia è possibile utilizzare gli Azure VPN Gateway con Windows 10 Always On, per stabilire tunnel sia di tipologia Device Tunnel che User Tunnel. A questo proposito è bene precisare che è opportuno fare le corrette valutazioni sulla tipologia e sulla SKU dell’Azure VPN Gateway da implementare.

Tipologie di deployment

Per Always On VPN sono previsti due scenari di deployment:

Il deployment di Always On VPN può prevedere opzionalmente, per i client Windows 10 in join al dominio, di configurare l’accesso condizionato per regolare le modalità in cui gli utenti VPN accedono alle risorse aziendali.

Figura 2 – Workflow per il deployment di Always On VPN per Windows 10 client domain-joined

Il client Always On VPN può infatti integrarsi con la piattaforma Azure Contitional Access per forzare l’autenticazione a più fattori (MFA), la conformità dei dispositivi oppure una combinazione di questi due aspetti. Se conforme ai criteri di Contitional Access, Azure Active Directory (Azure AD) emette un certificato di autenticazione IPsec di breve durata che può essere usato per autenticarsi sul gateway VPN. La conformità del dispositivo utilizza i criteri di conformità di Microsoft Endpoint Manager (Configuration Manager / Intune), che possono includere lo stato di attestazione dell’integrità del dispositivo, come parte del controllo di conformità per la connessione.

Figura 3 – Workflow per la connessione lato client

Per maggiori dettagli su questa metodologia di deployment è possibile fare riferimento a questa documentazione Microsoft.

Provisioning della soluzione sui client
Always On VPN è progettato per essere implementato e gestito utilizzando una piattaforma di gestione dei dispositivi mobile come ad esempio Microsoft Endpoint Manager, ma è possibile utilizzare anche soluzioni di Mobile Device Management (MDM) di terze parti. Per Always On VPN non è presente alcun supporto per la configurazione e la gestione tramite Group Policy di Active Directory, ma qualora non si disponga di una soluzione MDM è possibile procedere con un deploy della configurazione in modo manuale tramite PowerShell.

Integrazione con altre soluzioni Microsoft

Oltre a quanto riportato nei paragrafi precedenti, la tecnologia Always On VPN si può integrare con le seguenti tecnologie Microsoft:

  • Azure Multifactor Authentication (MFA): se combinata con i servizi RADIUS (Remote Authentication Dial-In User Service) e l’estensione NPS (Network Policy Server) per Azure MFA, l’autenticazione VPN può sfruttare meccanismi di autenticazione a più fattori.
  • Windows Information Protection (WIP): grazie a questa integrazione è consentita l’applicazione dei criteri di rete per determinare se il traffico è autorizzato a passare attraverso il tunnel VPN.
  • Windows Hello for Business: in Windows 10, questa tecnologia sostituisce le password, fornendo meccanismo di autenticazione a due fattori forte. Questa autenticazione consiste in una tipologia di credenziali utente legate a un dispositivo e utilizza un PIN (Personal Identification Number) biometrico o personale.

Conclusioni

Preparare la propria infrastruttura per consentire agli endpoint di accedere alla rete aziendale tramite la tecnologia Always On VPN non richiede nessun costo aggiuntivo per licenze software e gli investimenti necessari sia in termini di effort che di risorse sono minimi. Grazie a questa metodologia di connettività si riesce a garantire una esperienza utente ottimale anche in mobilità, fornendo un accesso trasparente e automatico alla rete aziendale pur mantenendo un elevato livello di sicurezza. Per gli aspetti sopra elencati la tecnologia Always On VPN non è adatta a tutti gli scenari d’uso, ma è sicuramente da tenere in considerazione in presenza di sistemi Windows 10 che devono accedere remotamente alle risorse aziendali.

[VIDEO] – Architecting and Implementing Azure Networking

Per implementare cloud ibridi in modo sicuro e allo stesso tempo funzionale è fondamentale una conoscenza approfondita dei vari aspetti legati al networking di Azure. Recentemente ho avuto il piacere di partecipare alla Cloud Conferenze Italia dove ho tenuto una sessione relativa al Networking di Azure. A questo proposito riporto il video della sessione dove vengono esplorati a 360° gli elementi chiave da tenere in considerazione per realizzare architetture di rete ibride, sfruttando al meglio i vari servizi offerti dalla piattaforma Azure, al fine di realizzare la miglior integrazione con l’ambiente on-premises, senza mai trascurare la sicurezza. Durante l’intervento sono stati approfonditi scenari avanzati di architetture di rete ibride, mostrando esempi reali, frutto di un’esperienza diretta sul campo.

Azure Networking: gestione di micro-perimetri con Azure Firewall Manager

Nel cloud pubblico di Microsoft è stato introdotto il nuovo servizio di management Azure Firewall Manager che consente di gestire in modo centralizzato le policy di security e le regole di routing. Grazie a questa soluzione è possibile governare al meglio i perimetri di sicurezza dei propri ambienti cloud ottenendo una protezione ottimale del proprio ecosistema aziendale. In questo articolo vengono riportate le caratteristiche principali del nuovo servizio evidenziando i vantaggi che si possono ottenere grazie al suo utilizzo.

Il modello di sicurezza, definito Zero trust dagli analisti di Forrester Research, e in contrasto con i modelli convenzionali basati sulla sicurezza perimetrale, ci indirizza nell’adozione di un approccio legato alla micro-segmentazione e alla definizione di perimetri granulari nella propria architettura di rete. Per agevolare questo approccio Microsoft ha rilasciato questo strumento che, mettendo a disposizione un unico pannello di controllo centralizzato, è in grado di semplificare la configurazione e la gestione delle network security policy, le quali spesso devono essere distribuite su più istanze di Azure Firewall.

Azure Firewall Manager al momento si integra con Azure Virtual WAN, il servizio che consente di implementare architetture di rete gestite secondo il modello hub and spoke. Azure Firewall ora può essere attivato nelle reti di Hub di Virtual WAN e nel momento in cui policy di security e di routing vengono associate da Azure Firewall Manager ad una rete di Hub questa viene definita come Secured Virtual Hub.

Figura 1 – Panoramica di Azure Firewall Manager

Adottando Azure Firewall Manager è possibile ottenere i seguenti benefici:

  • Configurazioni e deployment centralizzati: il deployment e la configurazione di più istanze di Azure Firewall, in reti di Hub di Virtual WAN, può essere fatta in modo centralizzato. Queste istanze di Azure Firewall possono risiedere in differenti region di Azure e su diverse subscription. Inoltre, è possibile organizzare una gerarchia di policy di Azure Firewall ottimizzate per DevOps, dove le Global firewall policy vengono gestite dall’IT centrale e le firewall policy locali vengono delegate ai DevOps per favorire una migliore agilità nei processi.
  • Routing automatizzato: viene fornita la possibilità di ridirigere facilmente e in modo centralizzato il traffico dalle reti di spoke verso il Secure Virtual Hub, il tutto senza dover manipolare le User Defined Routes delle reti di spoke.
  • Integrazione con partner Security as a Service (SECaaS) di terze parti: per arricchire ulteriormente le funzionalità di sicurezza è prevista l’integrazione con SECaaS partners, attualmente Zscaler e iBoss, ma presto sarà possibile anche con CheckPoint.

Figura 2 – Central security e route policy management

Nel dettaglio gli step per adottare la soluzione sono i seguenti:

  1. Creazione dell’architettura di rete hub and spoke, utilizzando il servizio Azure Virtual WAN e attivazione di una istanza Azure Firewall nella rete di Hub. Per fare ciò è possibile procedere tramite due distinte modalità:
    1. Creazione di una nuova Secured Virtual Hub tramite Azure Firewall Manager e aggiunta delle virtual network connections;
    2. Trasformazione di un Virtual WAN Hub esistente, attivando sulla rete di Hub il servizio Azure Firewall.

Figura 3 – Avvio del processo tramite Azure Firewall Manager

  1. Selezione dei security provider (opzionale). Questo può essere fatto sia durante il processo di creazione di un Secure Virtual Hub oppure durante la conversione di un Virtual WAN Hub in un Secure Virtual Hub.

Figura 4 – Scelta del Trusted Security Partner

  1. Creazione di una firewall policy e associazione con la rete di Hub. Questo è possibile solo per le Azure Firewall Policy, mentre per le policy delle soluzioni di Security as a Service (SECaaS) fornite dai partner, è necessario utilizzare i loro strumenti di gestione.
  1. Configurazione delle impostazioni di routing sul secured hub per attrarre il traffico delle reti di spoke e renderlo filtrato secondo le policy definite.

Al momento Azure Firewall Manager è supportato solamente per la gestione di architetture Hub and Spoke create tramite il servizio Azure Virtual WAN. Il supporto per poter gestire anche le istanze di Azure Firewall attivate nelle Virtual Network è atteso per la prima metà del prossimo anno.

Conclusioni

Azure Firewall Manager è uno strumento che risulta molto utile per gestire ambienti complessi composti da differenti architetture di rete che adottano il modello Hub and Spoke tramite Azure Virtual WAN. Questo servizio di management aggiuntivo nonostante sia agli albori, e destinato ad arricchirsi presto con nuove funzionalità, risulta di fondamentale importanza per gestire in modo più semplice ed efficace la propria architettura di rete di Azure. Al momento il servizio è in Public Preview, quindi non sono garantiti SLA (Service-Level Agreement) e non dovrebbe essere utilizzato in ambienti di produzione.