Archivi categoria: Azure Networking

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:

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

$BackupFileName = ".AzureFirewallBackup.json"

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

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

{

"apiVersion": "2019-04-01",

"type": "Microsoft.Network/azureFirewalls",

"name": "[variables('FirewallName')]",

"location": "[variables('RegionName')]",

"zones": [

"1",

"2",

"3"

],

"properties": {

"ipConfigurations": [

{

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

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

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à.

Azure Firewall: l’automazione per gestirne il backup

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. In questo articolo viene riportato un meccanismo ideato per fare il backup schedulato della configurazione di questo componente utilizzando il servizio Azure Automation.

Azure Firewall è una soluzione che sempre più spesso viene utilizzata nelle architetture Azure, per i vantaggi che offre rispetto alle soluzioni firewall di vendor di terze parti e grazie ad un costante arricchimento delle funzionalità offerte. Dal momento in cui viene adottato, questo servizio diventa il centro di governo del networking vostro ambiente Azure e conterrà diverse regole per gestire in modo completo il traffico di rete. Diventa pertanto fondamentale disporre di una strategia che consenta di ripristinare la configurazione del servizio in tempi rapidi. Il servizio al momento non dispone in modo integrato di una funzionalità per farne il backup completo in modo periodico. Per questa ragione ho realizzato un runbook in Azure Automation che effettua il backup dell’Azure Firewall su un blob storage account di Azure.

Si riporta la procedura per attivare l’esecuzione del backup periodico della configurazione tramite questa metodologia.

Prerequisiti

Qualora non si disponga di un Azure Automation Account è necessario procedere con la relativa creazione:

Figura 1 – Creazione Azure Automation Account

Risulta inoltre necessario disporre di un blob storage account sul quale saranno salvati i backup dell’Azure Firewall.

Figura 2 – Creazione blob storage account

Nelle impostazioni firewall dello storage account è necessario abilitare l’exception “Allow trusted Microsoft services to access this storage account”.

Sullo storage account è inoltre possibile valutare la creazione di policy che consentono di prevenire la cancellazione dei backup.

Configurazione moduli in Azure Automation

Azure Automation supporta la possibilità di utilizzare il modulo Azure Powershell Az nei runbooks. Il modulo AZ non è al momento importato automaticamente negli Automation Accounts. Per questa ragione è necessario procedure con la relativa configurazione come descritto da questo documento Microsoft, nello specifico seguendo la procedura in seguito riportata.

Figura 3 – Avvio procedura di aggiunta moduli

 

Figura 4 – Selezione dei moduli necessari e avvio del processo di import

Questi i moduli necessari per questa automation:

Figura 5 – Moduli necessari

Import e pubblicazione del runbook

Lo step successivo prevede la creazione del Runbook in Azure Automation:

Figura 6 – Creazione del Runbook

Il codice del runbook è possibile trovarlo in questa pagina GitHub. Una volta creato il runbook è opportuno procedere con la relativa pubblicazione.

Figura 7 – Pubblicazione del Runbook.

Schedulazione del runbook

Come ultimo step è opportuno schedulare l’esecuzione periodica del runbook.

Figura 8 – Creazione della schedulazione

 

Figura 9 – Aggiunta della schedulazione al runbook

 

Figura 10 – Configurazione dei parametri richiesti dal runbook

I backup in formato JSON della configurazione di Azure Firewall vengono salvati automaticamente nello storage account indicato e vengono mantenuti per il numero di giorni espresso nel parametro “RetentionDays”.

Figura 11 – Backup di Azure Firewall all’interno del container

Ripristino della configurazione

Nel caso sia necessario ripristinare la configurazione di Azure Firewall è sufficiente fare il deploy del file JSON nel resource group specifico, utilizzando il comando seguente:

New-AzResourceGroupDeployment -name “RestoreAzureFirewall” -ResourceGroupName “AFW-RGNamexxx” -TemplateFile “.xxx-afwxxxxx.json”

 

Conclusioni

Grazie all’adozione di questa automazione è possibile effettuare il backup dell’Azure Firewall su un blob storage account di Azure. Tutto ciò risulta particolarmente utile e strategico in caso di modifica errata delle regole oppure se avviene una cancellazione parziale o totale della configurazione di Azure Firewall, che può essere accidentale oppure svolta da persone non autorizzate.

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.

Panoramica del servizio DNS in Azure

Il cloud pubblico di Microsoft offre diversi servizi tra i quali Azure DNS, che consente di ospitare e gestire domini DNS (Domain Name System) pubblici e privati nell’ambiente Azure. In questo articolo vengono riportate le caratteristiche della soluzione, i possibili casi d’uso e vengono affrontati i vantaggi nell’adottare questa soluzione.

Risoluzione dei nomi pubblici

Il servizio Azure DNS può essere utilizzato per la risoluzione dei nomi dei domini pubblici. Azure non consente l’acquisto diretto di domini pubblici, ma supponendo di disporre di un dominio pubblico, è possibile utilizzare il servizio DNS di Azure per la risoluzione dei nomi relativi al proprio dominio.

Per farlo è necessario procedere con la creazione di una DNS Zone, questa la procedura per attivarla dal portale Azure:

Figura 1 – Creazione della DNS Zone

Nel processo di attivazione di una zona DNS viene richiesto di specificare anche la location del Resource Group, che determina dove vengono mantenuti i metadati associati alla zona DNS. Il servizio Azure DNS è infatti globale e non associato ad una specifica location di Azure.

Il processo di creazione è molto rapido e, al termine della creazione del servizio, si possono individuare i name server che è possibile utilizzare per la zona creata.

Figura 2 – Name Server per la DNS Zone creata

Dopo aver creato la DNS Zone in Azure è necessario delegare la risoluzione dei nomi per il dominio ai name server di Azure. Ogni Registar ha il proprio strumento per la gestione dei nomi, dove è possibile specificare i record NS, facendoli puntare ai quattro Name Server forniti dal servizio Azure DNS.

A questo punto è possibile aggiungere e gestire eventuali record DNS pubblici sulla propria zona DNS ospitata in ambiente Azure.

Figura 3 – Aggiunta di un record DNS

Risoluzione dei nomi privati

Nelle Virtual Network di Azure è disponibile di default il servizio DNS integrato nella piattaforma, che consente la risoluzione dei nomi dei sistemi su di esse attestate (Azure-provided). In alternativa è possibile specificare dei custom DNS Server. Il servizio Azure DNS estende queste possibilità abilitando nuovi scenari, grazie alla possibilità di utilizzare il servizio Azure DNS, non solo per gestire la risoluzione dei nomi per domini pubblici, ma al momento in preview, viene data la possibilità di attivare una zona DNS privata. Per le zone DNS private le Virtual Network che possono usufruire del servizio di risoluzione dei nomi, prendono il nome di resolution virtual networks. Mentre le registration virtual network sono quelle VNet per le quali è previsto il mantenimento degli hostname quando viene creata una VM, quando questa cambia il proprio indirizzo IP oppure quando viene rimossa.

La creazione di una zona DNS privata al momento è possibile farla con comandi PowerShell e non dal portale Azure.

Figura 4 – Comandi PowerShell per la creazione di una zona DNS privata

Utilizzando il comando PowerShell New-AzDnsZone è possibile specificare che si tratta di una zona privata tramite il parametro ZoneType valorizzato a Private. Se si desidera utilizzare la zona privata solo per la risoluzione dei nomi, senza far avvenire la creazione automatica dei record DNS, è possibile specificare il parametro ResolutionVirtualNetworkId, in caso contrario, se si vuole anche la registrazione automatica dei nomi è opportuno specificare il parametro RegistrationVirtualNetworkId. A questo proposito attualmente l’associazione iniziale come RegistrationResolution Virtual Network è possibile solo se la VNet non ha sistemi attestati su di essa.

Al termine dell’esecuzione dei comandi PowerShell sarà possibile vedere la zona privata anche dal portale Azure. Le zone private al momento si distinguono dalle altre in quanto non presentano l’elenco dei Name Server. Risulta comunque possibile registrare e gestire i record DNS, non solo tramite PowerShell o CLI, ma anche dal portale.

Figura 5 – Esempio di zona DNS privata presente nel portale Azure.

Scenari di utilizzo

La presenza delle Private Zone nel servizio Azure DNS consente di essere adottato in differenti scenari.

Risoluzione dei nomi per una singola Virtual Network

In questo scenario si ha un’unica Virtual Network che usufruisce del servizio Azure DNS privato per la risoluzione dei nomi interni. Tale risoluzione è totalmente privata e può essere usufruita da tutte le risorse attestate su quella specifica VNet.

Figura 6 – Azure Private DNS per una singola VNet

Risoluzione dei nomi tra Virtual Network differenti

Questo scenario è comunemente utilizzato quando più Virtual Network devono accedere allo stesso servizio Azure DNS privato. L’adozione di questo scenario è tipico in presenza di architetture Hub-Spoke, dove la rete di Hub può essere associata alla zona privata dell’Azure DNS in modalità Registration, mentre le varie reti di spoke possono essere associate come Resolution virtual network.

Figura 7 – Azure Private DNS per due VNet

Funzionalità di Split-Horizon

Si ricade in questo scenario quando per la stessa zona DNS si ha l’esigenza di ottenere risoluzione dei nomi differenti in base a dove si trova il client, in ambiente Azure oppure in Internet.

Figura 8 – Azure Private DNS in uno scenario di Split-Horizon

Costo della soluzione

Il costo dell’Azure DNS è dato da due elementi:

  • Numero di zone DNS ospitate in Azure (pubbliche o private).
  • Numero di query DNS ricevute.

Per ottenere i dettagli dei costi dell’Azure DNS è possibile consultare la pagina ufficiale.

Vantaggi

La possibilità di poter ospitare le zone DNS in Azure introduce una serie di vantaggi, tra i quali:

  • Il servizio DNS può essere erogato utilizzando gli strumenti nativi offerti dalla piattaforma Azure, senza dover utilizzare soluzioni DNS custom, risparmiando così sui tempi e sui costi.
  • Il servizio consente di utilizzare tutte le tipologie di record DNS più comuni: A, AAAA, CNAME, MX, PTR, SOA, SRV, e TXT.
  • Viene fornita la gestione automatica dei record DNS per le macchine virtuali presenti su specifiche Virtual Network di Azure.
  • La risoluzione privata dei nomi DNS può avvenire in modo condiviso anche tra Virtual Network differenti, a differenza di quanto offre il servizio di risoluzione dei nomi fornito di default sulle VNet. Questo consente di ampliare i possibili scenari di utilizzo e semplificare le architetture, grazie anche alle funzionalità di Split-horizon.
  • La soluzione può essere totalmente gestita tramite i tool Azure conosciuti (PowerShell, Azure Resource Manager templates, e REST API), riducendo così la curva di apprendimento per l’effettiva adozione.

Conclusioni

Il servizio Azure DNS consente di ospitare i propri domini DNS in Azure, fornendo la possibilità di gestirli con le stesse credenziali, le stesse politiche di billing e di supporto degli altri servizi Azure. L’introduzione del servizio Azure DNS Private Zones introduce un importante elemento che, quando sarà rilasciato ufficialmente, sarà da tenere in considerazione nel disegno delle proprie architetture Azure, al fine di semplificarle e renderle maggiormente efficienti. Azure DNS fornisce inoltre elevati livelli di affidabilità, scalabilità, sicurezza e disponibilità, in quanto basato sulla global network di Microsoft, difficilmente ottenibili con soluzioni di terze parti.

Azure Networking: panoramica dei servizi di protezione

Nell’era moderna del cloud computing, la tendenza è di spostare sempre più frequentemente i propri workload nel cloud pubblico e di utilizzare cloud ibridi. La sicurezza è spesso percepita come un elemento inibitore per l’utilizzo di ambienti cloud. Si può estendere il proprio datacenter nel cloud mantenendo un elevato livello di sicurezza della rete? Come garantire un accesso sicuro ai servizi presenti nel cloud e con quali strumenti? Una delle principali ragioni per utilizzare Azure, per le proprie applicazioni e i propri servizi, è proprio la possibilità di poter usufruire di un ampio set di funzionalità e di strumenti di sicurezza integrati nella platform. In questo articolo verrà fatta una panoramica dei servizi di protezione in ambito network nel mondo Azure, riportando le linee guida e gli accorgimenti utili per utilizzare al meglio le potenzialità presenti nella piattaforma, al fine di strutturare il network in Azure rispettando tutti i principi di sicurezza.

In ambito Azure Networking sono disponibili diversi servizi che consentono di abilitare la connettività verso ambienti distinti, secondo modalità differenti, di attivare la protezione della rete e di configurare il delivery delle applicazioni. Tutti questi servizi si integrano con i sistemi di monitor offerti dalla piattaforma Azure, andando a creare un ecosistema completo per l’erogazione dei servizi di rete.

Figura 1 – Azure Networking Services

Per poter configurare la protezione della rete in Azure troviamo i seguenti servizi, disponibili in modo nativo nella platform.

Network Security Group (NSG)

I Network Security Groups (NSGs) sono lo strumento principale per controllare il traffico di rete in Azure. Tramite delle regole di deny e permit è possibile filtrare le comunicazioni tra differenti workload attestati su una virtual network di Azure. Inoltre, è possibile applicare filtri sulle comunicazioni con sistemi che risiedono nell’ambiente on-premises, connesso alla VNet Azure, oppure per le comunicazioni da e verso Internet. I Network Security Groups (NSGs) possono essere applicati su una determinata subnet di una VNet Azure oppure direttamente sulle singole schede di rete delle macchine virtuali Azure. Il consiglio è di applicarli se possibile direttamente sulle subnet, per avere un controllo globale e più flessibile delle ACLs. I NSGs possono contenere regole con dei Service Tags, che consentono di raggruppare con dei nomi predefiniti delle categorie di indirizzi IP, incluse quelle assegnate a determinati servizi Azure (es. AzureMonitor, AppService, Storage, etc.).

Nelle regole dei Network Security Groups possono essere referenziati anche gli Application Security Groups (ASGs). Si tratta di gruppi che contengono schede di rete di macchine virtuali presenti su Azure. Gli ASGs consentono di raggruppare con nomi mnemonici più server, utili in particolare per workload dinamici. Gli Application Security Groups consentono inoltre di non dover più gestire nelle regole degli NSGs gli indirizzi IP delle macchine virtuali Azure, purché questi IP siano relativi a VMs attestate sulla stessa VNet.

Figura 2 – Esempio di regola di un NSG che contiene un Service Tag e un ASG

Figura 3 – Visualizzazione grafica della segregazione del traffico di rete tramite NSG

Service Endpoints

Tramite i Virtual Network (VNet) service endpoints è possibile aumentare il livello di sicurezza degli Azure Services, prevenendo accessi non autorizzati.  I vNet Service Endpoints consentono di isolare maggiormente i servizi Azure, permettendo l’accesso ad essi solamente da una o più subnet definite nelle proprie Virtual Network. Questa funzionalità garantisce inoltre che tutto il traffico generato dalle proprie vNet verso i servizi Azure rimanga sempre all’interno della rete di backbone di Azure. Per ottenere i servizi supportati ed avere maggiori dettagli a riguardo è possibile consultare la documentazione Microsoft.

Figura 4 – Schema di sintesi dei Sevice Endpoints

Azure Firewall

L’Azure Firewall è un firewall, totalmente integrato nel cloud pubblico di Microsoft, di tipologia stateful, grazie al quale è possibile controllare in modo centralizzato, attraverso delle policy, i flussi di comunicazione di rete, il tutto in modo cross subscription e per differenti virtual network. Azure Firewall consente anche di filtrare il traffico tra le virtual network di Azure e le reti on-premises, interagendo sia con connettività che avvengono tramite Azure VPN Gateway che con Express Route Gateway. Per maggiori dettagli a riguardo è possibile consultare l’articolo Introduzione ad Azure Firewall.

Figura 5 – Posizionamento di Azure Firewall

 

Web Application Firewall

La pubblicazione applicativa può essere fatta utilizzando l’Azure Application Gateway, 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 6 – Schema di overview dell’Application Gateway con WAF

DDoS protection

In Azure la protezione da attacchi DDoS è disponibile in due differenti tiers: Basic oppure Standard.

La protezione Basic è abilitata di default nella piattaforma Azure, la quale effettua costantemente il monitor del traffico e applica in tempo reale delle mitigazioni agli attacchi di rete più comuni. Questo tier fornisce lo stesso livello di protezione adottato e collaudato dai servizi online di Microsoft ed è attiva per gli indirizzi IP Pubblici di Azure (Pv4 e IPv6). Non è richiesta alcun tipo di configurazione per il tier Basic.

L’Azure DDoS Protection di tipologia Standard fornisce delle funzionalità di mitigation aggiuntive rispetto al tier Basic, che sono ottimizzate in modo specifico per le risorse dislocate nelle virtual network di Azure. Le policy di protezione sono auto-configurate e vengono ottimizzate effettuando un monitoraggio specifico del traffico di rete e applicando degli algoritmi di machine learning, che consentono di profilare nel modo più opportuno e flessibile il proprio applicativo studiando il traffico generato. Nel momento in cui vengono superate le soglie impostate nella policy di DDoS, viene in automatico avviato il processo di DDoS mitigation, il quale viene sospeso nel momento in cui si scende al di sotto delle soglie di traffico stabilite. Queste policy vengono applicate a tutti gli IP pubblici Azure (IPv4) associati alle risorse presenti nelle virtual network, come: macchine virtuali, Azure Load Balancer, Azure Application Gateway, Azure Firewall, VPN Gateway e istanze Azure Service Fabric.

Per maggiori dettagli a riguardo è possibile consultare l’articolo La protezione da attacchi DDoS in Azure.

Sinergie e raccomandazioni per l’utilizzo dei vari servizi di protezione

Al fine di ottenere una protezione di rete efficace ed indirizzarvi nell’utilizzo dei vari componenti si riportano le principali raccomandazioni che è consigliato tenere in considerazione:

  • I Network Security Groups (NSGs) e l’Azure Firewall sono tra di loro complementari e utilizzandoli in modo congiunto si ottiene un grado di difesa elevato. I NSGs è consigliato utilizzarli per filtrare il traffico tra le risorse che risiedono all’interno di una VNet, mentre l’Azure Firewall è utile per fornire una protezione di rete e applicativa tra differenti Virtual Network.
  • Per aumentare la sicurezza dei servizi Azure PaaS è consigliato utilizzare i Service endpoints, i quali possono essere utilizzati in concomitanza ad Azure Firewall per consolidare e centralizzare i log degli accessi. Per farlo è possibile abilitare i service endpoint dalla subnet dell’Azure Firewall, disabilitandoli dalle subnet presenti nelle VNet di Spoke.
  • Azure Firewall fornisce un livello di protezione di rete Layer 3 per tutte le porte ed i protocolli, inoltre garantisce un livello di protezione applicativa (Layer 7) per il traffico HTTP/S in uscita. Per questa ragione nel caso si voglia effettuare una pubblicazione applicativa protetta (HTTP/S in inbound) è opportuno utilizzare il Web Application Firewall presente nell’Application Gateway, affiancandolo quindi ad Azure Firewall.
  • Azure Firewall può essere affiancato anche da soluzioni WAF/DDoS di terze parti.

Tutti questi servizi di protezione, opportunamente configurati in una architettura di rete di tipologia Hub-Spoke consentono di effettuare una segregazione del traffico di rete, ottenendo un elevato livello di controllo e sicurezza.

Figura 7 – Servizi di sicurezza in una architettura Hub-Spoke

Conclusioni

Azure mette a disposizione una vasta gamma di servizi che consentono di ottenere elevati livelli di sicurezza, agendo su differenti fronti. Il modello di sicurezza che si decide adottare è possibile ridimensionarlo e adattarlo in modo flessibile, in base alla tipologia dei workload applicativi da proteggere. Una strategia vincente la si può ottenere applicando un mix-and-match dei differenti servizi di sicurezza di rete, per ottenere una protezione su più livelli.

Azure Virtual WAN: introduzione alla soluzione

Azure Virtual WAN è un nuovo servizio di rete che consente di ottimizzare ed automatizzare la connettività branch-to-branch attraverso Azure. Grazie a questo servizio è possibile connettere e configurare i dispositivi di rete presenti nei branch per consentire la comunicazione con Azure (branch-to-Azure). In questo articolo vengono esaminati i componenti coinvolti in Azure Virtual WAN e viene riportata la procedura da seguire per la relativa configurazione.

 

Figura 1 – Azure Virtual WAN overview

La configurazione di Azure Virtual WAN prevede la creazione delle seguenti risorse.

 

Virtual WAN

La risorsa Virtual WAN rappresenta uno strato virtuale della rete Azure e colleziona differenti componenti. Si tratta di una stratificazione che contiene i link a tutti i virtual hub che si desidera avere all’interno della Virtual WAN. Le risorse Virtual WAN sono tra loro isolate e non possono contenere hub comuni.

Figura 2 – Avvio del processo di creazione di Azure Virtual WAN

Figura 3 – Creazione Azure Virtual WAN

Durante la creazione della risorsa Virtual WAN viene richiesto di specificare una location. In realtà si tratta di una risorsa globale che non risiede in una region particolare, ma viene richiesto di specificarla solo per poterla gestire e localizzare più facilmente.

Abilitando l’opzione Network traffic allowed between branches associated with the same hub viene consentito il traffico tra i vari sites (VPN o ExpressRoute) associati allo stesso hub (branch-to-branch).

Figura 4 – Branch-to-branch connectivity option

 

Site

Il site rappresenta l’ambiente on-prem. Sarà necessario creare tanti site quante sono le location fisiche. Se ad esempio è presente un branch office a Milano, uno a New York e uno a Londra, sarà necessario ceare tre site separati, i quali contengono i rispettivi endpoint degli apparati di rete utilizzati per instaurare la comunicazione. Nel caso si utilizzino apparati di rete di partner Virtual WAN, vengono fornite delle soluzioni che in modo nativo esportano queste informazioni nell’ambiente Azure.

Figura 5 – Creazione di un site

Nelle impostazioni avanzate è possibile abilitare l’opzione BGP, che se attivata diventa valida per tutte le connessioni create per il site specifico. Tra i campi facoltativi è possibile specificare le informazioni sui device, che possono essere di aiuto al Team Azure per future eventuali ottimizzazioni o in caso di supporto.

 

Virtual Hub

Un Virtual Hub è una Microsoft-managed virtual network. L’hub è il componente core di rete in una determinata region e può esistere un solo hub per Azure region. L’hub contiene diversi service endpoint per consentire di instaurare la connettività con l’ambiente on-prem. La creazione di un Virtual Hub comporta la generazione di una nuova VNet e opzionalmente di un nuovo VPN Gateway. L’Hub Gateway non è un classico virtual network gateway che si utilizza per la connettività ExpressRoute e VPN ed è utilizzato per creare una connessione Site-to-Site tra l’ambiente on-prem e l’hub.

Figura 6 – Creazione di un Hub

Figura 7 – Associazione del site con un Hub

Gli Hub è opportuno che siano associati ai site che risiedono nella stessa region dove si trovano le VNet.

 

Hub virtual network connection

La risorsa Hub virtual network connection è utilizzata per connettere l’hub con la rete virtuale. Attualmente è possibile creare connessioni (peering) con virtual network che risiedono nella stessa region dell’hub.

Figura 8 – Connessione della VNet a un hub

 

Configurazione del dispositivo VPN on-prem

Per configurare il dispositivo VPN on-prem è possibile procedere manualmente, oppure nel caso si utilizzino soluzioni di partner Virtual WAN, la configurazione dei dispositivi VPN può avvenire automaticamente. In quest’ultimo caso il device controller ottiene il file di configurazione da Azure e applica la configurazione ai dispositivi, evitando di dover procedere con configurazioni manuali. Il tutto risulta molto comodo ed efficace, consentendo di risparmiare tempo. Tra i vari partner virtual WAN troviamo: Citrix, Riverbed, 128 Technology, Barracuda, Check Point, NetFoundry e Paloalto. Questa lista è destinata ad ampliarsi a breve con ulteriori partner.

Selezionando Download VPN configuration viene creato uno storage account nel resource group ‘microsoft-network-[location]’ dal quale è possibile scaricare la configurazione dell’apparato VPN on-prem. Tale storage account può essere rimosso dopo aver recuperato il file di configurazione.

Figura 9 – Download della configurazione VPN

Figura 10 – Download del file di configurazione presente sullo storage account

Al termine della configurazione dell’apparato on-prem il site sarà connesso, come mostrato nella figura seguente:

Figura 11 – Stato del site connesso

Viene inoltre fornita la possibilità di instaurare delle connessioni ExpressRoute con Virtual WAN, associando il circuit ExpressRoue all’hub. Si prevede inoltre la possibilità di avere connessioni Point-to-Site (P2S) verso il virtual Hub. Al momento queste funzionalità sono in preview.

Nella sezione Health vengono riportate delle informazioni utili per verificare lo stato di salute della connettività per ciascun Hub.

Figura 12 – Check Hub health

 

Conclusioni

Virtual WAN è il nuovo servizio Azure che consente di realizzare in modo centralizzato, semplice e veloce il collegamento di vari branch, tra di loro e con il cloud pubblico di Microsoft. Tale servizio consente di ottenere un’ottima esperienza di connettività, traendo vantaggio dalla rete globale di Microsoft, la quale può vantare di raggiungere diverse region in tutto il mondo, più di qualsiasi altro cloud provider pubblico.