Archivi categoria: Networking

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.

Azure Networking: il nuovo metodo per accedere in modo privato ai servizi in Azure

L’esigenza di poter accedere a dati e servizi in Azure in modo totalmente privato e sicuro, in particolare dal proprio ambiente on-premises, è sicuramente molto sentita e sempre più diffusa. Per questa ragione Microsoft ha annunciato la disponibilità di Azure Private Link, che permette di semplificare l’architettura di rete instaurando una connessione privata verso i servizi in Azure, senza alcuna necessità di esposizione verso internet. In questo articolo vengono riportate le caratteristiche di questa tipologia di connettività e come è possibile attivarla.

Grazie ad 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 1 – Panoramica di Azure Private Link

Il concetto che sta alla base di Azure Private Link è già in parte noto nell’ambito del networking di Azure e richiama i Virtual Network Service Endpoints. Prima dell’introduzione di Azure Private Link l’unico modo disponibile per aumentare il livello di sicurezza nell’accesso ai servizi Azure, come ad esempio Azure Storage e Azure SQL Database, era dato dai VNet Service Endpoints. La differenza però è sostanziale, in quanto utilizzando i VNet Service Endpoints il traffico rimane nella rete di backbone di Microsoft, consentendo l’accesso alle risorse PaaS solamente dalla propria VNet, ma l’endpoint PaaS viene comunque acceduto tramite l’IP pubblico del servizio. Ne consegue che il principio di funzionamento dei vNet Service Endpoints non si estende al mondo on-premises anche in presenza di connettività con Azure (VPN oppure ExpressRoute). Infatti, per consentire l’accesso da sistemi presenti on-premises è necessario continuare ad utilizzare le regole firewall del servizio per limitare la connettività solamente agli IP pubblici di propria appartenenza.

Grazie ad Azure Private Link è possibile invece accedere alle risorse PaaS tramite un indirizzo IP privato della propria VNet, il quale è potenzialmente accessibile anche da:

  • Sistemi on-premises tramite Azure ExpressRoute private peering eo Azure VPN gateway.
  • Sistemi attestati su VNet in peering.

Tutto il traffico risiede all’interno della rete Microsoft e non è necessario configurare l’accesso tramite gli IP Pubblici del servizio PaaS.

Figura 2 – Accesso da on-premises e peered networks

Azure Private Link semplifica notevolmente il modo in cui è possibile accedere ai servizi Azure (Azure PaaS, Microsoft partner e servizi privati) in quanto sono supportate configurazioni cross Azure Active Directory (Azure AD) tenants.

Figura 3 – Private Link cross Azure Active Directory (Azure AD) tenants

L’attivazione di Azure Private Link è semplice e richiede un numero limitato di configurazioni lato networking di Azure. La connettività avviene basandosi su un flusso di approvazione di chiamate e quando una risorsa PaaS viene mappata su un endpoint privato, non è richiesta la configurazione di route table e di Network Security Groups (NSG).

Dal Private link center è possibile creare nuovi servizi e gestire la configurazione oppure configurare servizi esistenti per usufruire dei Private Link.

Figura 4 – Avvio della configurazione da Private link center

Figura 5 – Creazione di un Azure Storage Account da rendere accessibile in modo privato

Figura 6 – Parametri classici per la creazione di uno storage account

Figura 7 – Configurazione del Private endpoint

Figura 8 – Private endpoint connection presente nello storage account creato

Giunti a questo punto lo storage account sarà accessibile in modo totalmente privato. Per testarne l’accesso è stata creata una macchina virtuale e verificata la connettività tramite “Connection troubleshoot”:

Figura 9 – Test eseguito da “Connection troubleshoot” che dimostra la connettività privata

Per collegare tra di loro più Azure Virtual Network vengono tipicamente utilizzati i VNet peering, i quali richiedono che negli address space delle VNet non ci siano delle sovrapposizioni. Qualora si verifichi questa condizione è possibile adottare gli Azure Private Link come metodo alternativo per connettere in modo privato applicazioni che risiedono in differenti VNet con una sovrapposizione degli address space.

Figura 10 – Azure Private Link in presenza di overlapping address space

Le caratteristiche di Azure Private Link consentono di avere un accesso specifico solamente alle risorse mappate in modo esplicito. Nell’eventualità di un incident di security all’interno della propria VNet, questo meccanismo elimina la minaccia di estrazione di dati da altre risorse utilizzando lo stesso endpoint.

Figura 11 – Accesso mirato solo alle risorse mappate in modo esplicito

Gli Azure Private Link aprono inoltre nuovi scenari di esposizione dei servizi erogati in Azure da parte dei service provider. Per consentire l’accesso ai servizi erogati ai propri clienti tipicamente si procedeva secondo una di queste modalità:

  • Si rendevano accessibili direttamente tramite IP Pubblici.
  • Per renderli privati, si creavano dei VNet peering, ma con problemi di scalabilità e di potenziali conflitti IP.

Figura 12 – Come Azure Private Link cambia gli scenari “Service Consumer”-“Service Provider”.

La nuova possibilità che viene offerta in questi scenari, che richiedono un accesso totalmente privato al servizio erogato, è la seguente:

  • Service Provider: configura un Azure Standard Load Balancer, crea un Azure Private Link e consente l’accesso dal Service Consumer proveniente da una differente VNet, subscription, o tenant Azure Active Directory (AD).
  • Service consumer: creare un Private Endpoint nella VNet specifica e richiedere l’accesso al servizio.

Figura 13 – Azure Private Link workflow in scenari “Service Consumer”-“Service Provider”

Per maggiori dettagli a riguardo è possibile consultare la documentazione ufficiale Microsoft.

Conclusioni

Questo nuovo metodo consente di consumare privatamente soluzioni erogate in Azure all’interno della propria infrastruttura di rete. Si tratta di un importante cambiamento che sicuramente è opportuno tenere in considerazioni quando si progettano le architetture di rete in Azure, in particolare per gli scenari ibridi. Al momento il servizio è in preview, quindi non ancora utilizzabile per ambienti di produzione e disponibile per un set limitato di servizi Azure. Nei prossimi mesi però Microsoft ha annunciato che renderà disponibile questa funzionalità anche per altri servizi di Azure e dei partner, consentendo così di avere una esperienza di connettività privata, elemento chiave per avere una maggiore adozione e diffusione di questi servizi.

Azure Networking: le novità di Azure Firewall

Azure Firewall è la soluzione di firewall-as-a-service 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. Questo servizio è stato rilasciato ufficialmente da diversi mesi e, come spesso accade per i servizi cloud, si hanno delle rapide evoluzioni, volte a migliorare il servizio e ad aumentare il set di funzionalità. In questo articolo vengo riportate le principali novità che hanno recentemente interessato Azure Firewall.

Indirizzi IP Pubblici associati ad Azure Firewall

Mentre inizialmente era possibile associare ad Azure Firewall un solo indirizzo IP pubblico, ora si possono associare fino a 100 indirizzi IP pubblici. Questa possibilità apre nuovi scenari di configurazione e di funzionamento:

  • In configurazioni DNAT si ha la possibilità di utilizzare la stessa porta su indirizzi IP Pubblici differenti.
  • Per quanto riguarda connessioni SNAT in outbound saranno disponibili un numero maggiore di porte, riducendo la possibilità di terminare le porte a disposizione.

Attualmente l’indirizzo IP Pubblico sorgente di Azure Firewall utilizzato per le connessioni viene scelto in modo casuale. Questo aspetto è da tenere in considerazione quando sono necessarie autorizzazioni specifiche per il traffico proveniente da Azure Firewall. Microsoft ha comunque in roadmap la possibilità di fare configurazioni SNAT specificando l’indirizzo IP Pubblico da utilizzare. La procedura da seguire per effettuare il deployment di Azure Firewall con più indirizzi IP Pubblici, tramite comandi PowerShell, è possibile consultarla in questo documento.

Figura 1 – Assegnazione di più IP pubblici ad Azure Firewall dal portale Azure

Availability Zones

Al fine di aumentare i livelli di disponibilità di Azure Firewall è possibile, durante la fase di creazione,  prevedere l’utilizzo delle Availability Zones. Selezionando due o più Availability Zones si potrà ottenere una percentuale di uptime del 99.99 percento. Tutti i dettagli relativi ai Service Level Agreement (SLA) di Azure Firewall sono contenuti in questo documento. L’adozione di questa metodologia di deployment non prevede costi aggiuntivi, ma è necessario contemplare un incremento dei costi dati dal data transfer in inbound e in outbound dalle Availability Zones, reperibili in questo documento. Rispetto al costo dell’Azure Firewall questi non impattano in modo particolarmente significativo. Personalmente ritengo che se si adotta una architettura del networking di Azure dove Azure Firewall è il componente core per la messa in sicurezza dell’ambiente, diventa molto utile utilizzare le Availability Zones per garantire un elevato livello di disponibilità delle applicazioni mission-critical protette da questo servizio.

Figura 2 – Configurazione Availability Zones in fase di creazione di Azure Firewall

In presenza di Azure Firewall creati senza l’utilizzo delle Availability Zones, non si ha la possibilità di effettuare una conversione all’utilizzo delle stesse. L’unica modalità attualmente disponibile prevede la creazione di un nuovo Azure Firewall migrando le configurazioni esistenti. I backup in formato JSON della configurazione di Azure Firewall possono essere fatti utilizzando i seguenti comandi PowerShell:

[cc lang=”powershell”]

$AzureFirewallId = (Get-AzFirewall -Name “AzureFirewallName” -ResourceGroupName “Network-RG”).id

$BackupFileName = “.AzureFirewallBackup.json”

Export-AzResourceGroup -ResourceGroupName “Network-RG” -Resource $AzureFirewallId -SkipAllParameterization -Path $BackupFileName

[/cc]

Avendo a disposizione il file JSON è necessario modificarlo per contemplare le Availability Zones:

[cc lang=”powershell”]

{

“apiVersion”: “2019-04-01”,

“type”: “Microsoft.Network/azureFirewalls”,

“name”: “[variables(‘FirewallName’)]”,

“location”: “[variables(‘RegionName’)]”,

“zones”: [

“1”,

“2”,

“3”

],

“properties”: {

“ipConfigurations”: [

{

[/cc]

Al termine della modifica è possibile effettuare il deployment del nuovo Azure Firewall, utilizzando il file JSON opportunamente modificato, tramite il seguente comando:

[cc lang=”powershell”]

New-AzResourceGroupDeployment -name “RestoreFirewallAvZones” -ResourceGroupName “Network-RG” -TemplateFile “.AzureFirewallBackup.json”

[/cc]

Gestione centralizzata con soluzioni di terze parti

Azure Firewall espone pubblicamente delle REST APIs che possono essere utilizzate da vendor di terze parti per fornire delle soluzioni che permettono una gestione centralizzata degli Azure Firewall, dei Network Security Groups (NSGs), e delle virtual appliance di rete (NVAs). Al momento questi sono i vendor che offrono soluzioni di questo tipo: Barracuda con Cloud Security Guardian, AlgoSec con CloudFlow e Tufin con Orca.

Just-in-time (JIT) VM access per Azure Firewall

Quando un utente richiede di accedere a una VM con una policy Just-in-time (JIT), il Security Center prima verifica se l’utente dispone effettivamente dei permessi Role-Based Access Control (RBAC) necessari per effettuare la richiesta di accesso. In caso affermativo la richiesta viene approvata, e il Security Center è in grado di configurare automaticamente non solo i NSG, ma anche le regole necessarie lato Azure Firewall per consentire il traffico in ingresso.

Application rules con FQDN di SQL

Nelle application rule di Azure Firewall è stata introdotta la possibilità di specificare degli FQDN di SQL. In questo modo è possibile governare l’accesso dalle virtual network verso specifiche istanze SQL server. Tramite gli FQDN SQL è possibile filtrare il traffico:

  • Da Virtual Network verso un Azure SQL Database oppure un Azure SQL Data Warehouse.
  • Dall’ambiente on-premises verso Azure SQL Managed Instances oppure SQL IaaS in esecuzione sulle Virtual Network.
  • Da spoke-to-spoke verso Azure SQL Managed Instances oppure SQL IaaS in esecuzione sulle Virtual Network.

Figura 3 – Creazione Application Rule con FQDN SQL

FQDN Tag per Azure HDInsight (HDI)

I cluster Azure HDInsight presenti sulle proprie Virtual Network hanno diverse dipendenze da altri servizi Azure (esempio Azure Storage), con i quali è necessario prevedere un traffico di rete in uscita per funzionare in modo corretto. Grazie all’introduzione degli FQDN tags per HDInsight è possibile configurare Azure Firewall per restringere l’accesso in outbound per i cluster HDI. Per maggiori dettagli a riguardo è possibile consultare la documentazione ufficiale Microsoft.

Automazione per gestire il backup

Disporre di una strategia che consenta di ripristinare la configurazione del servizio in tempi rapidi è fondamentale in quanto questo servizio è il centro di governo del networking vostro ambiente Azure e contiene diverse regole per gestire in modo completo il traffico di rete. Il servizio al momento non dispone in modo integrato di una funzionalità per farne il backup completo in modo periodico. In questo articolo viene riportato un meccanismo ideato per fare il backup schedulato della configurazione di questo componente utilizzando il servizio Azure Automation.

Conclusioni

Azure Firewall è una soluzione che sempre più spesso viene utilizzata nelle architetture di rete di Azure, per i vantaggi che offre rispetto alle soluzioni firewall di vendor di terze parti e grazie ad un costante arricchimento delle funzionalità offerte. Tutte queste novità introdotte rendono Azure Firewall una soluzione più completa, totalmente integrata nella piattaforma, che consente di mettere in sicurezza le risorse presenti sulle Virtual Network di Azure con una elevata flessibilità.

Come accedere remotamente alle macchine virtuali in ambiente Azure

Poter accedere tramite RDP (Remote Desktop Protocol) oppure via SSH (Secure SHel) alle macchine virtuali presenti in Azure è un’esigenza fondamentale per gli amministratori di sistema. L’esposizione diretta di questi protocolli su Intenet è sicuramente una pratica da evitare in quanto comporta un elevato rischio di security. In questo articolo vengono riportate le differenti metodologie che è possibile adottare per accedere remotamente ai sistemi presenti su Azure e le caratteristiche di ciascuna di essa.

Anche recentemente Microsoft ha rilasciato un aggiornamento di sicurezza considerato critico e indirizzato alla risoluzione della vulnerabilità CVE-2019-0708 individuata sul servizio Remote Desktop per diversi sistemi operativi. Tale vulnerabilità permette l’esecuzione di codice tramite protocollo RDP consentendo così di prendere il controllo completo del sistema remoto. Questa vulnerabilità viene portata a titolo di esempio per evidenziare quanto sia effettivamente rischioso pubblicare in Internet questi protocolli di accesso. Per questa ragione è opportuno valutare l’adozione di una delle soluzioni in seguito riportate per avere una maggiore sicurezza.

Figura 1 – RDP/SSH attack

Accesso VPN

Per disporre di un semplice accesso amministrativo verso la Virtual Network di Azure è possibile attivare un VPN di tipologia Point-to-Site (P2S). Tramite le VPN P2S è possibile instaurare la connettività da una singola postazione verso l’ambiente Azure, in modo semplice e sicuro. Stabilita la connessione VPN si avrà la possibilità di accedere remotamente ai sistemi presenti in Azure. Per maggiori informazioni sulle VPN P2S vi invito a leggere l’articolo Azure Networking: l’accesso VPN Point-to-Site e le novità introdotte. Adottando questa metodologia è opportuno tenere in considerazioni il numero massimo di connessioni possibili per singolo Azure VPN Gateway.

Figura 2 – Protocolli disponibili per le VPN P2S

Just-in-Time VM Access

Si tratta di una funzionalità disponibile in Azure Security Center Standard Tier, che consente di applicare le configurazioni necessarie ai Network Security Group (NSG) e recentemente anche ad Azure Firewall per consentire un accesso amministrativo ai sistemi, opportunamente filtrato per IP sorgente e per un determinato periodo di tempo. Just-in-Time VM Access consente di effettuare le configurazioni necessarie per accedere remotamente ai sistemi in modo rapido, mirato e solo per un periodo temporale ben specifico. Senza l’utilizzo di questa funzionalità sarebbe necessario creare manualmente apposite regole all’interno dei NSG oppure in Azure Firewall (NAT Rule), ricordandosi di rimuoverle quando non più necessarie.

Figura 3 – Richiesta di accesso tramite Just-in-Time VM Access

Jumpbox

Uno scenario che viene in alcune situazioni utilizzato è la presenza di una macchina virtuale (Jumpbox) accessibile remotamente e dislocata in una subnet opportunamente isolata, che viene utilizzata per accedere a diversi altri sistemi in comunicazione con quella subnet. In una architettura di rete che rispecchia la topologia hub-spoke, tipicamente questo sistema viene posizionato nella rete di Hub, ma è comunque consigliato applicare dei filtri per fare in modo che tale sistema sia raggiungibile solo da determinati indirizzi IP pubblici, senza esporlo direttamente in Internet. In questo scenario è opportuno tenere in considerazione che si avranno a disposizione al massimo due connessioni remote contemporaneamente per singola Jumpbox.

Figura 4 – Posizionamento della Jumpbox in una architettura hub-spoke

Azure Bastion

Si tratta di un servizio PaaS, recentemente annunciato in preview da Microsoft, 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 supporta l’accesso a tutte le macchine virtuali su di essa attestate, senza dover esporre degli indirizzi IP pubblici.

Figura 5 – Architettura di Azure Bastion

Per maggiori dettagli a riguardo vi invito a leggere l’articolo Azure Bastion: un nuovo modello di sicurezza di Silvio Di Benedetto.

Azure Bastion è un servizio a pagamento, per ottenere i dettagli sui costi è possibile accedere alla pagina Azure Bastion pricing.

Al momento è opportuno tenere in considerazione che Azure Bastion e Just-in-Time VM Access non possono essere utilizzati per accedere agli stessi sistemi.

SSL Gateway

Una soluzione molta valida in termini di sicurezza potrebbe essere quella di implementare in ambiente Azure una architettura Remote Desktop Services, che prevede l’utilizzo del ruolo Remote Desktop Gateway, appositamente pensato per essere direttamente esposto verso Internet (porta TCP 443). Grazie a questo componente è possibile incapsulare il traffico RDP in un tunnel HTTP over TLS/SSL. Il Remote Desktop Gateway supporta inoltre la Multi-Factor Authentication che consente di aumentare ulteriormente il livello di sicurezza per l’accesso remoto alle risorse. Una soluzione analoga è disponibile anche in ambiente Citrix. In questo ambito sarà necessario considerare, oltre ai costi legati ai componenti Azure, anche i costi di licenza.

Figura 6 – Possibile architettura Remote Desktop Services in ambiente Azure

Conclusioni

Diverse sono le possibilità per garantire un accesso remoto sicuro ai sistemi presenti in ambiente Azure. Il nuovo servizio Azure Bastion è un metodo sicuro e semplice, ma che necessita di essere ampliato con ulteriori funzionalità, tra le più importanti c’è sicuramente il supporto per Virtual Network in peering e per la multi-factor authentication. Tali funzionalità con molta probabilità saranno già disponibili nel momento dell’effettivo rilascio. In attesa di poter utilizzare Azure Bastion in ambiente di produzione è possibile adottare gli altri metodi riportati, evitando così di dover esporre i sistemi in modo non protetto verso internet.

Azure Networking: tutto ciò che è opportuno sapere sul nuovo Application Gateway

L’Application Gateway è l’offerta di Application Delivery Controller as-a-service presente in Azure che consente ai clienti di effettuare la ripubblicazione applicativa, con funzionalità integrate di bilanciamento del carico layer-7, sicurezza e Web Application Firewall (WAF). Microsoft ha recentemente annunciato la disponibilità di una versione totalmente rivisitata dell’Azure Application Gateway e del relativo modulo Web Application Firewall (WAF). In questo articolo vengono riportati i miglioramenti e le funzionalità aggiuntive che sono presenti nelle nuove SKUs, chiamate rispettivamente Standard_v2 e WAF_v2.

Miglioramenti e nuove funzionalità

Si riportano gli ambiti dove la nuova versione dell’Azure Application Gateway ha apportato migliorie e funzionalità aggiuntive.

Figura 1 – Schema con le nuove funzionalità della SKU V2

Scalabilità

La nuova versione dell’Azure Application Gateway consente di effettuare in modo automatico uno scale-up oppure uno scale-down del numero delle istanze da utilizzare, in base al traffico rilevato verso gli applicativi ripubblicati. In questo modo il dimensionamento dell’Application Gateway sarà sempre idoneo per sostenere il traffico necessario e non sarà più opportuno dimensionare questo componente alla massima capacità per sostenere i momenti con picchi di traffico. Ne consegue che grazie a questa funzionalità è possibile ottenere un risparmio significativo sui costi in scenari dove sono presenti workload che non hanno un afflusso omogeneo, ma soggetto a variazioni.

Zone redundancy

Nella nuova SKU è possibile prevedere il deployment dell’application Gateway in diverse zone di disponibilità (availability zone) in modo da non essere soggetti a disservizi in caso di problematiche legate alla singola zona di Azure. Questa metodologia di deployment permette di aumentare la resilienza delle applicazioni pubblicate.

Assegnazione IP Pubblico Statico

Il Virtual IP Address assegnato all’Application Gateway potrà essere statico, garantendo così una assegnazione dell’indirizzo IP costante per tutto il ciclo di vita del componente. Tale funzionalità risulta particolarmente utile per gestire regole su sistemi firewall esterni ad Azure e per scenari di pubblicazione di Azure Web App.

Header Rewrite

La funzionalità di Header Rewrite consente di gestire più facilmente le pubblicazioni degli applicativi in quanto è consentito aggiungere, rimuovere o modificare gli header delle richieste e delle risposte HTTP, direttamente dall’Application Gateway e senza la necessità di modificare il codice dell’applicativo.

Performance

L’adozione della nuova SKU dell’Application Gateway consente di avere un notevole miglioramento nelle performance sia durante le attività di provisioning che durante le attività di aggiornamento della configurazione. Inoltre, si evidenzia un miglioramento delle performance, fino a 5 volte superiore rispetto alla precedente SKU, in scenari di SSL offloading.

La raccomandazione

Per tutte le nuove implementazioni si consiglia di valutare l’adozione della nuova SKU dell’Azure Application Gateway, mentre per chi sta effettuando pubblicazioni applicative tramite Application Gateway V1, si consiglia di migrare alla SKU V2 in tempi brevi, per le seguenti ragioni:

  • Nuove funzionalità e miglioramenti: migrando alla nuova SKU è possibile beneficiare dei miglioramenti e delle nuove funzionalità sopra menzionate.
  • Costo: vista la nuova politica di pricing adottata per la SKU V2, basata sui consumi e non più sul dimensionamento e sul numero di istanze, questa potrebbe risultare complessivamente più conveniente rispetto alla SKU V1. Per maggiori informazioni sui costi della nuova versione dell’Azure Application Gateway è possibile consultare la relativa pagina dei costi.
  • Supporto della piattaforma: a breve Microsoft disabiliterà la possibilità di creare nuovi Application Gateway V1. Inoltre, in futuro Microsoft rilascerà ulteriori nuove funzionalità, ma la maggior parte di queste saranno rilasciate esclusivamente per la SKU V2.

Come avviene la migrazione alla SKU V2

Attualmente la piattaforma Azure non fornisce una procedura automatica di migrazione dalla SKU V1 alla SKU V2, ma è necessario procedere con una migrazione in side-by-side. Per procedere con questa attività è necessaria una opportuna attività di analisi preliminare per verificare la presenza di tutti i requisiti necessari. La migrazione della configurazione esistente può avvenire tramite appositi script di supporto, ma potrebbero comunque essere richieste attività manuali. Conclusa la configurazione di tutte le impostazioni verso il nuovo Azure Application Gateway V2 è necessario ridirigere il flusso di traffico proveniente dai client verso il nuovo servizio di Application Delivery.

Conclusioni

L’introduzione delle nuove funzionalità descritte rende l’offerta di Application Delivery Controller as-a-service disponibile nella piattaforma Azure ancora più completa e funzionale, al punto da essere altamente competitiva con soluzioni di altri vendor, da tempo consolidate sul mercato. Per rimanere costantemente aggiornati con la rapida evoluzione del cloud è consigliato effettuare quanto prima il passaggio alla nuova versione dell’Application Gateway per poter usufruire dei vantaggi sopra citati.

Azure Networking: l’accesso VPN Point-to-Site e le novità introdotte

Tra le differenti possibilità per stabilire una connettività ibrida con il cloud Azure esistono le VPN di tipologia Point-to-Site (P2S). Tramite le VPN P2S è possibile attivare la connettività da una singola postazione verso l’ambiente Azure, in modo semplice e sicuro. Si tratta di una soluzione utile per consentire la comunicazione da postazioni remote verso le Virtual Network di Azure, prevalentemente utilizzata per fini di test e sviluppo. Può essere anche attivata in alternativa alle VPN Site-to-Site se si deve garantire la connettività verso Azure per un numero molto limitato di sistemi. In questo articolo vengono approfondite le caratteristiche di questa connettività e vengono riportate le ultime novità a riguardo.

Per stabilire connettività ibride con Azure si possono utilizzare differenti metodologie, ciascuna delle quali ha caratteristiche differenti e può risultare idonea per specifici scenari, garantendo livelli differenti di performance e affidabilità.

Figura 1 – Opzioni per attivare connettività ibride con Azure

Le VPN Point-to-Site forniscono sicuramente un set più ristretto di funzionalità rispetto alle altre opzioni di connettività ibrida e sono idonee in casi specifici, dove solo un numero limitato di postazioni devono collegarsi all’ambiente Azure. La connessione P2S viene stabilita avviandola direttamente dal sistema remoto e nella soluzione non sono previsti sistemi nativi per attivarla in modo automatico.

Figura 2 – Confronto tra le opzioni di connettività ibrida

Protocolli utilizzati dalla VPN P2S

Le VPN Point-to-site possono essere configurate per utilizzare i seguenti protocolli:

  • OpenVPN®: è un protocollo recentemente aggiunto in ambito Azure, ma già ampiamente utilizzato da differenti soluzioni, che arricchisce questa tipologia di connettività. Si tratta di un protocollo VPN basato su SSL/TLS, che per le sue caratteristiche consente di attraversare con maggiore facilità i firewall. Inoltre, è garantita la compatibilità con differenti piattaforme: Android, iOS (versione 11.0 e superiori), Windows, Linux e dispositivi Mac (OSX versione 10.13 e successive).
  • Secure Socket Tunneling Protocol (SSTP): si tratta di un protocollo VPN proprietario Microsoft basato su SSL e quindi anch’esso può facilmente attraversare sistemi firewall, ma ha la limitazione che può essere utilizzato esclusivamente da sistemi Windows. In particolare, Azure supporta tutte le versioni di Windows che contemplano il protocollo SSTP (Windows 7 e successivi).
  • IKEv2: si tratta di una soluzione VPN IPsec che può essere utilizzata da differenti piattaforme client, ma per poter funzionare richiede che sul firewall vengano consentite comunicazioni specifiche. IKEv2 è supportato su Windows 10 e Windows Server 2016, ma per poterlo utilizzare è necessario installare update specifici e impostare determinate chiavi di registry. Le precedenti versioni del SO non sono supportate e possono utilizzare solamente il protocollo SSTP oppure OpenVPN®.

Figura 3 – Protocolli OpenVPN® e IKEv2 a confronto

Le VPN Point-to-Site richiedono la presenza di un VPN Gateway attivo sulla virtual network di Azure e a seconda della SKU variano il numero massimo delle connessioni possibili. Occorre inoltre tener in considerazione che i VPN Gateway di tipologia Basic non supportano i protocolli IKEv2 e OpenVPN.

Figura 4 – Gateway SKU a confronte per le VPN P2S

La coesistenza tra le VPN P2S e le VPN S2S per la stessa virtual network è possibile solamente in presenza di VPN gateway di tipologia RouteBased.

Autenticazioni client supportate

L’accesso VPN Point-to-Site prevede la possibilità di utilizzare le seguenti metodologie di autenticazione:

  • Autenticazione nativa di Azure tramite certificati. Con questa modalità l’autenticazione avviene tramite un certificato client presente sul dispositivo che deve connettersi. I certificati client vengono generati da un certificato trusted root e devono essere installati su ogni sistema che deve connettersi. Il certificato root può essere emesso tramite una soluzione Enterprise, oppure è possibile generare un certificato self-signed. Il processo di validazione del certificato client viene svolto dal VPN Gateway durante il tentativo di stabilire la connessione della VPN P2S. Il certificato root deve essere quindi caricato nell’ambiente Azure ed è necessario per il processo di validazione.
  • Autenticazione tramite Active Directory (AD) Domain Server. Grazie a questa tipologia di autenticazione gli utenti possono autenticarsi utilizzando le credenziali di dominio. Questa metodologia richiede la presenza di un server RADIUS integrato con AD. Tale sistema RADIUS può essere implementato on-premises oppure nella VNet di Azure. Utilizzando questo meccanismo, durante il processo di autenticazione, l’Azure VPN Gateway comunica con il sistema RADIUS, pertanto è indispensabile prevedere questo flusso di comunicazione. Qualora il server RADIUS sia dislocato on-premises, deve quindi essere prevista anche una connettività tramite VPN S2S con i sistemi on-premises. Il server RADIUS può utilizzare i certificati rilasciati da una Certification Authority interna in alternativa ai certificati rilasciati da Azure, con il vantaggio che non è necessario gestire in Azure l’upload dei certificati root e la revoca dei certificati. Un altro aspetto importante è che il server RADIUS può integrarsi con meccanismi di autenticazione di terze parti, aprendo così la possibilità di utilizzare anche sistemi di autenticazione a più fattori per l’accesso VPN P2S. Al momento il protocollo OpenVPN® non è supportato con l’autenticazione RADIUS.

Conclusioni

Le VPN Point-to-Site (P2S) possono essere molto utili per fornire connettività verso le Virtual Network di Azure in scenari ben specifici. Grazie all’introduzione del supporto al protocollo OpenVPN® è possibile attivarle più facilmente e da differenti dispositivi (Windows, Mac e Linux), senza tralasciare gli aspetti legati alla sicurezza.