Archivi categoria: Networking

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.

La protezione da attacchi DDoS in Azure

Un attacco informatico di tipologia denial-of-service distribuito (attacco DDoS – Distributed Denial of Service) è rivolto a far esaurire deliberatamente le risorse di un determinato sistema che eroga un servizio ai client, come ad esempio un sito web ospitato su dei web server, al punto da renderlo non più in grado di erogare il servizio a coloro che lo richiedono in modo legittimo. In questo articolo saranno riportate le caratteristiche della protezione che è possibile avere in Azure per questa tipologia di attacchi, in modo da proteggere al meglio le applicazioni presenti sul cloud e garantire la loro disponibilità a fronte di attacchi DDoS.

Gli attacchi DDoS sono sempre più diffusi e sofisticati, al punto da poter raggiungere dimensioni, in termini di larghezza di banda, sempre più importanti, che ne rendono difficoltosa la protezione e aumentano le possibilità di apportare un downtime ai servizi pubblicati, con un impatto diretto sul business aziendale.

Figura 1 – DDoS Attack Trends

Spesso questa tipologia di attacchi viene inoltre utilizzata dagli hackers per distrarre le aziende e mascherare altre tipologie di attacchi informatici (cyber Smokescreen).

Caratteristiche della soluzione

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

Figura 2 – Comparativa delle funzionalità dei tiers disponibili per la protezione DDoS

Figura 3 – Panoramica dell’Azure DDoS Protection Standard

L’Azure DDoS Protection di tipologia Standard è in grado di far fronte ai seguenti attacchi:

Volumetric attacks: l’obiettivo di questi attacchi è di inondare la rete con una quantità considerevole di traffico apparentemente legittimo (UDP floods, amplification floods, e altri spoofed-packet floods).
Protocol attacks: questi attacchi puntano a rendere inaccessibile una specifica destinazione, sfruttando un punto debole che viene individuato nel layer 3 e nel layer 4 dello stack (ad esempio SYN flood attacks e reflection attacks).
Resource (application) layer attacks: questi attacchi hanno come obiettivo i pacchetti delle Web application, al fine di interrompere la trasmissione di dati tra i sistemi. Gli attacchi di questo tipo includono: violazioni del protocollo HTTP, SQL injection, cross-site scripting e altri attacchi di livello 7. Per proteggersi da attacchi di questa tipologia non è sufficiente la protezione DDoS standard, ma è necessario utilizzarla in concomitanza con il modulo Web Application Firewall (WAF) disponibile nell’Azure Application Gateway, oppure con soluzione web application firewall di terze parti, disponibili nel marketplace di Azure.

Abilitazione della protezione DDoS Standard

La protezione DDoS Standard viene attivata a livello di virtual network ed è contemplata per tutte le risorse che risiedono al suo interno. L’attivazione dell’Azure DDoS Protection Standard richiede di creare un DDoS Protection Plan che raccoglie le virtual network con la protezione DDoS Standard attiva, cross subscription.

Figura 4 – Creazione di un DDoS Protection Plan

Il protection Plan viene creato in una determinata subscription, alla quale saranno associati i costi della soluzione.

Figura 5 – Abilitazione della protezione DDoS Standard su una Virtual Network esistente

Il tier Standard fornisce una telemetria in tempo reale che è consultabile tramite viste in Azure Monitor.

Figura 6 – Metriche DDoS disponibili in Azure Monitor

Qualsiasi metrica relativa alla protezione DDoS può essere utilizzata per generare degli alert. Utilizzando la metrica “Under DDoS attack” si può essere avvisati nel momento in cui viene rilevato un attacco DDoS e viene applicata una azione di mitigation.

La protezione DDoS Standard applica tre auto-tuned mitigation policies (TCP SYN, TCP & UDP) per ogni IP Pubblico associato a una risorsa protetta, che risiede quindi su una virtual network con il servizio DDoS standard attivo.

Figura 7 – Metriche di mitigation disponibili in Azure Monitor

Per effettuare la generazione di report, riguardanti le azioni svolte per mitigare gli attacchi DDoS, è necessario configurare le impostazioni di diagnostica.

Figura 8 – Diagnostics Settings in Azure Monitor

Figura 9 – Abilitazione diagnostica su IP Pubblico per collezionare i log DDoSMitigationReports

Nelle impostazioni di diagnostica c’è la possibilità di collezionare anche altri log relativi alle attività di mitigation e alle notifiche. Per maggiori informazioni a riguardo è possibile consultare la sezione Configure DDoS attack analytics della documentazione Microsoft. Le metriche per la protezione DDoS Standard vengono mantenute in Azure Moniotr per 30 giorni.

Figura 10 – Attack flow logs in Azure Log Analytics

Come testare l’efficacia della soluzione

Microsoft ha instaurato una partnership con BreakingPoint Cloud che, grazie a una interfaccia molto intuitiva, consente di generare del traffico, verso gli IP Pubblici di Azure, per simulare un attacco DDoS. In questo modo è possibile:

Validare l’effettiva efficacia della soluzione.
Simulare ed ottimizzare le risposte a fronte di incident relativi ad attacchi DDoS.
Documentare il livello di compliance per attacchi di questa tipologia.
Formare il network security team.

Costi della soluzione

Il tier Basic non prevede nessun costo, mentre l’abilitazione della protezione DDoS Standard prevede un prezzo mensile fisso (non trascurabile) e un addebito per i dati che vengono elaborati. Il prezzo mensile fisso include la protezione per 100 risorse, superate le quali è previsto un costo unitario aggiuntivo per ogni risorsa protetta. Per maggiori dettagli sui costi di Azure DDoS Protection Standard è possibile consultare la pagina ufficiale Microsoft.

Conclusioni

La protezione da attacchi DDoS in Azure ci consente di avere sempre attiva una protezione di base per far fronte ad attacchi di questo tipo. A seconda della criticità applicative si può valutare l’abilitazione della protezione Standard, che in concomitanza con una soluzione di web application firewall, consente di avere funzionalità complete per mitigare attacchi distribuiti di denial-of-service.

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.

Azure Networking: caratteristiche del Global VNet peering

Le Virtual Network in ambiente Azure sono per loro natura logicamente isolate, per consentire di connettere in modo sicuro differenti risorse Azure. Il Global VNet peering in ambito Azure fornisce la possibilità di mettere in comunicazione virtual network che risiedono su differenti region di Azure. In questo articolo verranno approfonditi i benefici e le attuali costrizioni imposte dal Global VNet peering. Sarà inoltre mostrata la procedura da seguire per l’attivazione di un Global VNet peering.

Figura 1 – Esempio di connessione di VNet di Azure in region differenti

Nel momento in cui viene configurato il peering tra due virtual network che risiedono in region di Azure diverse, si espande il confine logico e le macchine virtuali attestate su queste VNet possono comunicare tra di loro con i propri indirizzi IP privati, senza dover utilizzare gateway e indirizzi IP pubblici. Inoltre, è possibile adottare il modello di rete hub-spoke, per condividere le risorse quali firewall oppure virtual appliance, mettendo in comunicazione anche virtual network in differenti region di Azure, attraverso il Global VNet peering.

Benefici del Global VNet peering

I principali benefici che si possono ottenere utilizzando il Global VNet peering per mettere in comunicazione le virtual network sono:

Il traffico tra le virtual network rimane all’interno della rete di backbone di Microsoft ed è pertanto totalmente privato.

Figura 2 – Rete di backbone di Microsoft

Si può usufruire di una connettività a bassa latenza e con un bandwidth elevato.
La configurazione è semplice e non richiede la presenza di gateway per istaurare tunnel VPN tra le differenti network.

Attuali costrizioni del Global VNet peering

Attualmente ci sono alcune costrizioni che è opportuno tenere in considerazione quando si effettua un Global VNet peering:

In presenza di un Global VNet peering non è possibile utilizzare i gateway remoti (opzione “use remote gateways”) oppure consentire il transito del gateway (opzione “allow gateway transit”) sulle virtual network. Queste opzioni sono attualmente utilizzabili solo quando si effettua un peering di virtual network che risiedono nella stessa region di Azure. Ne consegue quindi che i Global VNet peering non sono transitivi, quindi le VNet di downstream in una region non possono dialogare, utilizzando questa metodologia, con le VNet in un’altra region. Ad esempio, ipotizzando uno scenario dove tra la vNet1 e la vNet2 è presente un Global VNet peering e tra la vNet2 e la vNet3 è presente un altro Global VNet peering. In questo caso non ci sarà comunicazione tra la vNet1 e la vNet3. Se si ha la necessità, è possibile creare un ulteriore Global vNet peering per metterle in comunicazione.
Per una risorsa che risiede su una virtual network, non è consentito comunicare utilizzando l’indirizzo IP di un Azure internal load balancer che risiede sulla virtual network in peer. Questo tipo di comunicazione è consentita solo se il source IP e l’indirizzo IP del Load Balancer sono nella stessa VNet.
Il Global VNet peering si può creare in tutte le Azure public regions, ma non con VNet che risiedono negli Azure national clouds.
La creazione del Global VNet peering è consentita anche tra VNet che risiedono in subscription differenti, purché siano associate allo stesso tenant di Active Directory.
Le virtual network possono essere messe in peering solo se non è presente overlapping nei relativi address space. Inoltre, in seguito alla creazione del peering, se si ha la necessità di modificare gli address space è necessario a priori rimuovere il peering.

Configurazione del Global VNet peering

La configurazione del Global VNet peering è estremamente semplice. Nelle immagini seguenti vengono documentati gli step per mettere in comunicazione due virtual network create in region differenti, nel caso specifico West Europe e Australia Southeast.

Figura 3 – Aggiunta del peering dalle impostazioni della VNet

Figura 4 – Configurazione dei parametri del peering

Selezionando l’opzione “Allow virtual network access”, viene consentita la comunicazione tra le due virtual network. Tale impostazione consente che l’address space della VNet in peer sia aggiunto al tag Virtual_Network.

Figura 5 – Peering aggiunto, in stato Initiated

Le stesse operazioni, documentate nella figura 3 e nella figura 4, è necessario ripeterle anche sulla Virtual Network che risiede nell’altra region e con la quale si vuole configurare il Global VNet peering. La comunicazione sarà attivata nel momento in cui lo stato del peering sarà “Connected” su entrambe le VNet.

Figura 6 – Peering in stato Connected

Selezionando una macchina virtuale, attestata su una virtual network con configurato il global vNet Peering, si vedrà una rotta specifica per la VNet associata, come mostrato nella figura seguente:

Figura 7 – Effective route della VNet in Global Peering

Il Global VNet peering prevede dei costi per il traffico di rete in ingresso e in uscita che transitano dal peering e il costo varia a seconda delle zone contemplate. Per maggiori dettagli è possibile fare riferimento alla pagina ufficiale dei costi.

Conclusioni

Il Global VNet peering consente di avere un’ottima flessibilità nel gestire in modo semplice ed efficace come i vari workload possono connettersi tra di loro, consentendo di espandere i possibili scenari di implementazione in Azure, senza dover considerare i confini geografici come un limite. Importanti benefici possono essere ottenuti in particolare in architetture di replica del dato e di disaster recovery.

Azure Networking: introduzione al modello Hub-Spoke

Una topologia di rete sempre più adottata dai clienti che autilizzano Microsoft Azure è la topologia di rete definita Hub-Spoke. In questo articolo sono riportate le caratteristiche principali di questa architettura di rete, vengono esaminati i più comuni casi di utilizzo, e si evidenziano i principali vantaggi che si ottengono grazie a questa architettura.

La topologia Hub-Spoke

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

Questo uno schema di base dell’architettura:

Figura 1 – Architettura network Hub-Spoke di base

Questa architettura è pensata anche per posizionare nella rete di Hub una network virtual appliance (NVA) per controllare i flussi del traffico di rete in modo centralizzato.

Figura 2 – Possibile architettura della vNet di Hub in presenza di NVA

A questo proposito è opportuno evidenziare che Microsoft ha recentemente annunciato la disponibilità dell’Azure Firewall, un nuovo servizio gestito e totalmente integrato nel cloud pubblico di Microsoft, che consente di mettere in sicurezza le risorse presenti sulle Virtual Network di Azure. Al momento il servizio è in preview, ma presto sarà possibile valutare l’adozione dell’Azure Firewall per controllare in modo centralizzato, attraverso delle policy, i flussi di comunicazione di rete, il tutto in modo cross subscription e per differenti virtual network. Questo servizio, in presenza di architetture di rete di tipologia Hub-Spoke, si presta per essere posizionato nella rete di Hub, in modo da ottenere un controllo completo del traffico di rete.

Figura 3 – Posizionamento dell’Azure Firewall nella rete di Hub

Per maggiori dettagli sull’Azure Firewall è possibile consultare l’articolo Introduzione ad Azure Firewall.

Quando utilizzare la topolgia Hub-Spoke

L’architettura di rete Hub-Spoke è tipicamente utilizzata in scenari dove sono richieste queste caratteristiche in termini di connettività:

In presenza di workload deployati in ambienti differenti (sviluppo, test e produzione) i quali devono accedere ai servizi condivisi come ad esempio DNS, IDS, Active Directory Domain Services (AD DS). I servizi condivisi saranno posizionati nella virtual network di Hub, mentre i vari ambienti (sviluppo, test e produzione) saranno deployati nelle reti di Spoke per mantenere un elevato livello di isolamento.
Quando determinati workloads non devono comunicare con tutti gli altri workloads, ma solamente con i servizi condivisi.
In presenza di realtà che richiedono un elevato livello di controllo sugli aspetti legati alla sicurezza di rete e che necessitano di effettuare una segregazione del traffico di rete.

Figura 4 – Disegno dell’architettura Hub-Spoke con i relativi componenti

I vantaggi della topologia Hub-Spoke

I vantaggi di questa topologia di rete Azure possono essere così sintetizzati:

Risparmio sui costi, dati dal fatto che si possono centralizzare in un’unica posizione i servizi condivisi da più carichi di lavoro, come ad esempio i server DNS ed eventuali appliance virtuali. Si riducono inoltre i VPN Gateway necessari per fornire connettività verso l’ambiente on-premises, con un risparmi sui costi Azure.
Possibilità di separazione granulare dei compiti tra IT (SecOps, InfraOps) e workloads (DevOps).
Maggiore flessibilità in termine di gestione e sicurezza dell’ambiente Azure.

Riferimenti utili per approfondimenti

Si riportano i riferimenti alla documentazione tecnica Microsoft utili per indirizzare ulteriori approfondimenti su questa tematica:

Conclusioni

Uno dei primi aspetti da tenere in considerazione quando si decide di implementare soluzioni nel cloud è l’architettura di rete da adottare. Stabilire fin dall’inizio la topologia di rete più opportuna consente di avere una strategia vincente ed evita di trovarsi nella condizione di dover migrare in seguito dei workloads, per adottare architetture di rete differenti, con tutte le complicazioni che ne conseguono.

Ogni implementazione richiede una attenta analisi al fine di tenere in considerazione tutti gli aspetti e di effettuare le opportune valutazioni. Non è quindi possibile affermare che l’architettura di rete Hub-Spoke sia idonea per tutti gli scenari, ma introduce certamente diversi benefici che la rendono efficace per ottenere determinate caratteristiche ed avere un elevato livello di flessibilità.

Le novità introdotte in Virtual Machine Manager 1807

In seguito al primo annuncio della Semi-Annual Channel release di System Center, avvenuto nel mese di febbraio con la versione 1801, nel mese di giugno è stata rilasciata la nuova update release: System Center 1807. In questo articolo saranno approfondite le nuove funzionalità introdotte in System Center Virtual Machine Manager (SCVMM) dall’update release 1807.

Networking

Informazioni relative alla rete fisica

SCVMM 1807 ha introdotto un importante miglioramento in ambito network. Infatti, utilizzando il Link Layer Discovery Protocol (LLDP), SCVMM è in grado di fornire informazioni per quanto riguarda la connettività alla rete fisica degli host Hyper-V. Questi i dettagli che SCVMM 1807 è in grado di recuperare:

Chassis ID: Switch chassis ID
Port ID: Porta dello Switch alla quale la NIC è connessa
Port Description: Dettagli relative alla porta, come ad esempio il Type
System Name Manufacturer: Manufacturer e dettagli sulla versione Software
System Description
Available Capabilities: Funzionalità disponibili del sistema (come ad esempio switching, routing)
Enabled Capabilities: Funzionalità abilitate sul sistema (come ad esempio switching, routing)
VLAN ID: Virtual LAN identifier
Management Address: Indirizzo IP di management

La consultazione di queste informazioni può avvenire tramite Powershell oppure accedendo alla console di SCVMM: View > Host > Properties > Hardware Configuration > Network adapter.

Figura 1 – Informazioni fornite da SCVMM 1807 in merito alla connettività fisica degli host Hyper-V

Questi dettagli risultano molto utili per avere visibilità sulla rete fisica e per facilitare le operazioni di troubleshooting. Tali informazioni saranno rese disponibili per gli host Hyper-V che rispettano i seguenti requisiti:

Sistema operativo Windows Server 2016 o successivo.
Feature DataCenterBridging e DataCenterBridging-LLDP-Tools abilitate.

Conversione SET in Logical Switch

SCVMM 1807 consente di convertire un Virtual Switch di Hyper-V, creato nella modalità Switch Embedded Teaming (SET), in un logical switch, utilizzando direttamente la console di SCVMM. Nelle precedenti versioni di SCVMM tale operazione era fattibile solamente tramite comandi PowerShell. Questa conversione può risultare utile per generare un Logical Switch, utilizzabile come template su differenti host Hyper-V gestiti da SCVMM. Per maggiori informazioni sui Switch Embedded Teaming (SET) vi invito a consultare l’articolo Windows Server 2016: La nuova modalità di creazione dei Virtual Switch in Hyper-V

Supporto per host VMware ESXi v6.5

SCVMM 1807 ha introdotto il supporto di host VMware ESXi v6.5 all’interno della propria fabric. Per quella che è la mia esperienza, anche in ambienti costituiti da più hypervisors, difficilmente si utilizza SCVMM per la gestione di host VMware. Tale supporto è però importante in quanto introduce la possibilità di convertire VMs ospitate su host VMWare ESXi 6.5 in VMs di Hyper-v.

Storage

Supporto per la selezione del CSV da utilizzare durante l’aggiunta di un nuovo disco

SCVMM 1807 consente di specificare, durante l’aggiunta di un nuovo disco virtuale a una VM esistente, in quale cluster shared volumes (CSV) posizionarlo. Nelle precedenti release di VMM non veniva fornita questa possibilità e i nuovi dischi virtuali di default venivano posizionati sullo stesso CSV dove erano presenti i dischi già associati alla macchina virtuale. In alcune circostanze, come ad esempio in presenza di CSV con poco spazio libero a disposizione, questo comportamento poteva risultare non adeguato e poco flessibile.

Figura 2 – Aggiunta di un nuovo disco a una VM selezionando su quale CSV posizionarlo

Supporto per l’update di cluster Storage Spaces Direct (S2D)

In Virtual Machine Manager 2016 è presente il supporto per effettuare il deployment di cluster Storage Spaces Direct (S2D). Con SCVMM 1807 è stata introdotta anche la possibilità di fare patching e update dei nodi di cluster Storage Spaces Direct, orchestrando l’intero processo di update, che sfrutterà le baseline configurate in Windows Server Update Services (WSUS). Questa funzionalità consente di gestire in modo più efficace l’ambiente Storage Spaces Direct, punto cardine del Software Defined Storage di casa Microsoft, che porta al raggiungimento del Software Defined Data Center.

Statement di supporto

Supporto per SQL Server 2017

In SCVMM 1807 è stato introdotto il supporto per SQL Server 2017 per ospitare il relativo database. Questo consente di effettuare l’upgrade da SQL Server 2016 a SQL Server 2017.

Conclusioni

L’update release 1807 introduce in Virtual Machine Manager diverse novità che lo arricchiscono notevolmente in termini di funzionalità. Inoltre, questo aggiornamento risolve anche una serie di problematiche riportate nella documentazione ufficiale Microsoft. Si consiglia quindi di valutare un aggiornamento delle implementazioni di Virtual Machine Manager, per avere una maggiore stabilità e per poter usufruire delle nuove features introdotte. Si ricorda che le release appartenenti al Semi-Annual Channel hanno un periodo di supporto di 18 mesi.

Per provare System Center Virtual Machine Manager è necessario accedere all’Evaluation Center e dopo essersi registrati è possibile avviare il periodo di trial.

Introduzione ad Azure Firewall

Microsoft ha recentemente annunciato la disponibilità di un servizio da tempo atteso e richiesto da coloro che utilizzano sistemi in ambiente Azure, si tratta dell’Azure Firewall. L’Azure Firewall è un nuovo servizio gestito e totalmente integrato nel cloud pubblico di Microsoft, che consente di mettere in sicurezza le risorse presenti sulle Virtual Network di Azure. In questo articolo verranno esaminate le caratteristiche principali di questo nuovo servizio, attualmente in preview, e sarà riportata la procedura da seguire per la relativa attivazione e configurazione.

Figura 1 – Posizionamento dell’Azure Firewall nell’architettura di rete

L’Azure Firewall è un firewall 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. Questo servizio, in presenza di architetture di rete di tipologia hub-spoke, si presta per essere posizionato nella rete di Hub, in modo da ottenere un controllo completo del traffico.

Le funzionalità dell’Azure Firewall, attualmente disponibili in questa fase di public preview, sono le seguenti:

High availability (HA) Built-in: l’alta disponibilità è integrata nel servizio e non sono richieste configurazioni specifiche o componenti aggiuntivi per renderla effettiva. Questo è sicuramente un elemento che lo distingue rispetto a soluzioni di terze parti che, per la configurazione delle Network Virtual Appliance (NVA) in HA, richiedono tipicamente la configurazione di load balancer aggiuntivi.
Unrestricted cloud scalability: Azure Firewall consente di scalare facilmente per adeguarsi ad eventuali cambi dei flussi di rete.
FQDN filtering: si ha la possibilità di limitare il traffico in uscita HTTP/S verso una specifica lista di fully qualified domain names (FQDN), con la possibilità di utilizzare caratteri wild card nella creazione delle regole.
Network traffic filtering rules: si possono creare regole di allow oppure di deny per filtrare il traffico di rete sulla base dei seguenti elementi: indirizzo IP sorgente, indirizzo IP di destinazione, porte e protocolli.
Outbound SNAT support: all’Azure Firewall viene assegnato un indirizzo IP Pubblico statico, il quale sarà utilizzato dal traffico in uscita (Source Network Address Translation), generato dalle risorse della virtual nertwork di Azure, consentendone una facile identificazione dalle destinazioni internet remote.
Azure Monitor logging: tutti gli eventi dell’Azure Firewall possono essere integrati in Azure Monitor. Nelle impostazioni della diagnostica è consentito abilitare l’archiviazione dei log in uno storage account, effettuare lo stream verso un Event Hub, oppure impostare l’invio verso un workspace di OMS Log Analytics.

Azure Firewall si trova al momento in una preview pubblica gestita, il che significa che per implementarlo è necessario effettuare in modo esplicito l’abilitazione tramite il comando PowerShell Register-AzureRmProviderFeature.

Figura 02 – Comandi PowerShell per l’abilitazione della public preview dell’Azure Firewall

La registrazione della feature può richiedere fino a 30 minuti ed è possibile monitorare lo stato di registrazione con i seguenti comandi PowerShell:

Figura 03 – Comandi PowerShell per verificare lo stato di abilitazione dell’Azure Firewall

Al termine della registrazione è necessario eseguire il seguente comando PowerShell:

Figura 04 – Comando di registrazione del Network Provider

Per effettuare il deployment dell’Azure Firewall su una determinata Virtual Network è necessaria la presenza di una subnet denominata AzureFirewallSubnet, che deve essere configurata con una sunbnet mask almeno /25.

Figura 05 – Creazione della subnet AzureFirewallSubnet

Per effettuare il deployment dell’Azure Firewall dal portale Azure è necessario selezionare Create a resource, Networking e successivamente See all:

Figura 06 – Ricerca dell’Azure Firewall nelle risorse Azure

Filtrando per Firewall comparirà anche la nuova risorsa Azure Firewall:

Figura 07 – Selezione della risorsa Microsoft Firewall

Avviando il processo di creazione comparirà la seguente schermata che richiede l’inserimento dei parametri necessari per effettuare il deployment:

Figura 08 – Inserimento dei parametri necessari per il deployment del Firewall

Figura 09 – Review dei parametri selezionati e conferma di creazione

Per fare in modo di far confluire il traffico in uscita di una determinata subnet verso il firewall è necessario creare una route table contenente una rotta con le seguenti caratteristiche:

Figura 10 – Creazione della regola di inoltro del traffico verso il servizio Firewall

Nonostante Azure Firewall sia un managed service è necessario specificare Virtual appliance come next hop. L’indirizzo del next hop sarà l’IP privato dell’Azure Firewall.

La route table sarà da associare alla virtual network che si desidera controllare tramite Azure Firewall.

Figura 11 – Associazione della route table alla subnet

A questo punto, per i sistemi attestati sulla subnet che inoltra il traffico verso il Firewall, non sarà consentito il traffico in uscita, fintanto che non verrà esplicitamente abilitato:

Figura 12 – Tentativo di accesso al sito web bloccato dall’Azure Firewall

Azure Firewall mette a disposizione le seguenti tipologie di regole per controllare il traffico in uscita.

Figura 13 – Tipologie di regole disponibili

Application rules: consentono di configurare l’accesso a determinati fully qualified domain names (FQDNs) da una determinata subnet.

Figura 14 – Creazione Application rule per consentire l’accesso ad un sito web specifico

Network rules: permettono la configurazione di regole che contengono l’indirizzo sorgente, il protocollo, l’indirizzo e la porta di destinazione.

Figura 15 – Creazione Network rule per consentire il traffico sulla porta 53 (DNS) verso uno specifico DNS Server

Conclusioni

Poter disporre di un firewall completamente integrato nella fabric di Azure è sicuramente un vantaggio importante che consente di arricchire le funzionalità offerte in modo nativo da Azure. Al momento sono configurabili operazioni di base, ma il set di funzionalità è sicuramente destinato ad arricchirsi in tempi brevi. Si ricorda che al momento si tratta di un servizio in preview, e come tale non viene garantito nessun service level agreement e non è consigliato utilizzarlo in ambienti di produzione.

Azure Application Gateway: come monitorarlo con Log Analytics

L’Azure Application Gateway è un load balancer applicativo (OSI layer 7) per il traffico web, disponibile in ambiente Azure, che consente di gestire il traffico HTTP e HTTPS delle applicazioni. In questo articolo verrà approfondito come effettuare il monitor degli Azure Application Gateway utilizzando Log Anaytics.

Figura 1 – Schema di base dell’Azure Application Gateway

Utilizzando l’Azure Application Gateway è possibile usufruire delle seguenti funzionalità:

Routing basato su URL
Redirection
Multiple-site hosting
Session affinity
Secure Sockets Layer (SSL) termination
Web application firewall (WAF)
Supporto nativo per i protocolli WebSocket e HTTP/2

Per maggiori dettagli sugli Azure Application Gateway è possibile consultare la documentazione ufficiale Microsoft.

Configurazione Diagnostics logs dell’Application Gateway

L’Azure Application Gateway prevede l’invio dei log di diagnostica verso un workspace di Log Analytics. Questa funzionalità è molto utile per controllare le performance, per rilevare eventuali errori ed è fondamentale per operazioni di troubleshooting, in particolare in presenza del modulo WAF. Per abilitare la diagnostica dal portale Azure è possibile selezionare la risorsa Application Gateway specifica ed accedere alla sezione “Diagnostics logs”:

Figura 2 – Avvio della configurazione dei Diagnostics logs

Figura 3 – Configurazione dei Diagnostics logs

Dopo aver scelto il workspace di Log Analytics dove inviare i dati di diagnostica, nella sezione Log, è possibile selezionare quale tipologia di Log collezionare tra i seguenti:

Access log (ApplicationGatewayAccessLog)
Performance log (ApplicationGatewayPerformanceLog)
Firewall log (ApplicationGatewayFirewallLog): questi log vengono generati solo se il Web Application Firewall è configurato sull’Application Gateway.

Oltre a questi log sono inoltre collezionati di default gli Activity Log generati da Azure. Questi log vengono mantenuti per 90 giorni nello store dell’Azure event logs. Per maggiori dettagli è possibile consultare questo documento specifico.

Solution Azure Application Gateway analytics di Log Analytics

Microsoft mette a disposizione la solution Azure Application Gateway analytics che può essere aggiunta al workspace di Log Analytics seguendo questi semplici step:

Figura 4 – Avvio della procedura di aggiunta della solution al workspace OMS

Figura 5 – Selezione della solution Azure Application Gateway analytics

Figura 6 – Aggiunta della solution nel workspace selezionato

Dopo aver abilitato l’invio dei log di diagnostica verso il workspace di Log Analytics ed aver aggiunto sullo stesso la solution, selezionando il tile Azure Application Gateway analytics presente nella pagina di Overview, si potrà visualizzare una overview dei dati di log raccolti dall’Application Gateway:

Figura 7 – Schermata di overview della solution Azure Application Gateway analytics

Sarà inoltre possibile consultare i dettagli per le seguenti categorie.

Application Gateway Access logs:
- Client and server errors for Application Gateway access logs
- Requests per hour for each Application Gateway
- Failed requests per hour for each Application Gateway
- Errors by user agent for Application Gateways

Figura 8 – Schermata degli Application Gateway Access logs

Application Gateway performance:
- Host health for Application Gateway
- Maximum and 95th percentile for Application Gateway failed requests

Figura 9 – Schermata delle performance degli Application Gateway

Dashboard personalizzata di Log Analytics per il monitor dell’Application Gateway

Oltre a questa solution può essere conveniente utilizzare anche una apposita dashboard di Log Analytics, specifica per il monitoring dell’Application Gateway, reperibile a questo indirizzo. Il deploy della dashboard avviene tramite template ARM e richiede anche in questo caso l’abilitazione dei Diagnostics logs dell’Application Gateway, come descritto precedentemente. Le varie query di Log Analytics, utilizzate dalla dashboard, sono documentate in questo blog. Grazie a queste query la dashboard riporta diverse informazioni aggiuntive esposte dalla diagnostica dell’Application Gateway.

Figura 10 – Dashboard custom di Log Analytics per il monitor dell’Application Gateway

Query di Log Analytics per monitorare i Firewall Log

Utilizzando la solution Azure Application Gateway analytics di Log Analytics oppure la dashboard custom (riportata nel paragrafo precedente) non sono al momento contemplati i Firewall log, generati quando risulta attivo il Web Application Firewall (WAF) sull’Application Gateway. Il WAF si basa sulle regole di OWASP Core Rule Set 3.0 o 2.2.9 per intercettare gli attacchi, alle applicazioni Web, che sfruttano le più note vulnerabilità. Per citarne alcune, troviamo ad esempio gli attacchi SQL injection e gli attacchi cross site scripting.

In questo caso, qualora si decida di verificare i Firewall log, è necessario eseguire direttamente delle query di Log Analytics, come ad esempio:

Figura 11 – Query di LA per recuperare le richieste bloccate dal modulo WAF, negli ultimi 7 giorni, per uno specifico URI, suddivise per RuleId

Per consultare la lista delle regole del WAF, associando il RuleId alla relativa description, è possibile consultare questo documento.

Il messaggio descrittivo della rule viene riportato anche all’interno dei risultati restituiti dalla query:

Figura 12 – Query di LA per recuperare le richieste bloccate dal modulo WAF, negli ultimi 7 giorni, per uno specifico URI e per specifica RuleId

Conclusioni

Secondo la mia esperienza, nelle architetture Azure che richiedono la pubblicazione sicura di servizi Web verso internet, è spesso utilizzato il servizio Azure Application Gateway con il modulo WAF attivo. Grazie alla possibilità di inviare i log di diagnostica di questo componente verso Log Analytics si ha la possibilità di avere un monitor completo, che risulta fondamentale per analizzare eventuali condizioni di errore e per valutare lo stato del componete in tutte le sue sfaccettature.

Microsoft Azure: panoramica delle soluzioni di monitoring per la rete

In Microsoft Azure sono disponibili diverse soluzioni che consentono di monitorare le risorse di rete, non solo per ambienti cloud, ma anche in presenza di architetture ibride. Si tratta di funzionalità cloud-based, orientate a controllare lo stato di salute della rete e la connettività verso le proprie applicazioni. Inoltre, sono in grado di fornire informazioni dettagliate sulle performance di rete. In questo articolo verrà effettuata una panoramica delle diverse soluzioni riportandone le caratteristiche principali, necessarie per orientarsi nell’utilizzo degli strumenti di monitor della rete più opportuni per le proprie esigenze.

Network Performance Monitor (NPM) è una suite che comprende le seguenti soluzioni:

Performance Monitor
ExpressRoute Monitor
Service Endpoint Monitor

Oltre agli strumenti inclusi in Network Performance Monitor (NPM) è possibile utilizzare Traffic Analytics e DNS Analytics.

Performance Monitor

L’approccio sempre più frequentemente utilizzato è quello di avere ambienti ibridi con un networking eterogeneo, che consente di mettere in comunicazione la propria infrastruttura on-premises con l’ambiente implementato nel cloud pubblico. In alcuni casi si potrebbe disporre anche di differenti cloud provider, che rendono ancor più complicata l’infrastruttura di rete. Questi scenari richiedono pertanto l’utilizzo di strumenti di monitor flessibili e che possano lavorare in modo trasversale on-premises, in cloud (IaaS), e in ambienti ibridi. Performance Monitor ha tutte queste caratteristiche e grazie all’utilizzo di transazioni sintetiche, fornisce la possibilità di monitorare, pressoché in tempo reale, i parametri di rete per avere le informazioni relative alle performance, come la perdita di pacchetti e la latenza. Inoltre, questa soluzione consente di localizzare facilmente la sorgente di una problematica in uno specifico segmento di rete o identificando un determinato dispositivo. La soluzione richiede la presenza dell’agente di OMS e tenendo traccia dei pacchetti di retransmission e del tempo di roundtrip, è in grado di restituire un grafico di facile e immediata interpretazione.

Figura 1 – Diagramma Hop-by-hop fornito da Performance Monitor

Dove installare gli agenti

L’installazione dell’agente di Operations Management Suite (OMS) è necessario farla su almeno un nodo connesso a ogni sottorete dalla quale si intende monitorare la connettività verso altre sottoreti. Nel caso si intenda monitorare uno specifico link di rete è necessario installare gli agenti su entrambe gli endpoint del link. Nei casi dove non si è a conoscenza della topologia esatta di rete, un possibile approccio è quello di installare gli agenti su tutti i server che detengono workload particolarmente critici e per i quali è necessario monitorare le performance di rete.

Costo della soluzione

Il costo della funzionalità Performance Monitor in NPM è calcolato sulla base della combinazione di questi due elementi:

Subnet link monitorati. Per ottenere i costi per il monitoring di un singolo subnet link per un mese, è possibile consultare la sezione Ping Mesh.
Volume di dati.

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

ExpressRoute Monitor

Utilizzando ExpressRoute Monitor è possibile effettuare il monitor della connettività end-to-end e verificare le performance tra l’ambiente on-premises ed Azure, in presenza di connettività ExpressRoute con connessioni Azure Private peering e Microsoft peering. Le funzionalità chiave di questa soluzione sono:

Auto-detection dei circuit ExpressRoute associati alla propria subscription Azure.
Detection della topologia di rete.
Capacity planning e analisi dell’utilizzo di banda.
Monitoring e alerting sia per il primary che per il secondary path dei circuit ExpressRoute.
Monitoring sulla connettività verso i servizi Azure come Office 365, Dynamics 365 che utilizzano ExpressRoute come connettività.
Rilevamento di eventuali degradi della connettività verso le varie virtual network.

Figura 2 – Topology view di una VM su Azure (sinistra) connessa a una VM on-prem (destra), tramite connessione ExpressRoute

Figura 3 – Trend sull’utilizzo della banda e sulla latenza riscontrata sul circuit ExpressRoute

Dove installare gli agenti

Per poter utilizzare ExpressRoute Monitor è necessario installare almeno un agente di Operations Management Suite su un sistema che risiede sulla virtual network di Azure e almeno un agente su una macchina attestata sulla sottorete nell’ambiente on-premises, connessa tramite private peering di ExpressRoute.

Costo della soluzione

Il costo della soluzione ExpressRoute Monitor è calcolato in base al volume dei dati generato durante le operazioni di monitoring. Per maggiori dettagli è possibile consultare la sezione dedicata nella pagina dei costi di NPM.

Service Endpoint Monitor

Utilizzando questa soluzione si ha la possibilità di monitorare e testare la raggiungibilità dei propri servizi e delle proprie applicazioni, pressoché in tempo reale, simulando gli accessi degli utenti. Si ha inoltre la possibilità di rilevare problemi nelle prestazioni lato network e di individuare il segmento di rete problematico.

Si riportano le funzionalità principali della soluzione:

Effettua il monitor end-to-end delle connessioni di rete verso le proprie applicazioni. Il monitor può essere fatto di qualsiasi endpoint “TCP-capable” (HTTP, HTTPS, TCP, e ICMP), come websites, applicazioni SaaS, applicazioni PaaS, e database SQL.
Correla la disponibilità delle applicazioni con le performance della network, per localizzare con precisione il punto di degrado sulla rete, partendo dalla richiesta dell’utente fino al raggiungimento dell’applicativo.
Testa la raggiungibilità delle applicazioni da differenti location geografiche.
Determina le latenze di rete e i pacchetti persi per raggiungere le proprie applicazioni.
Rileva hot spots sulla rete che possono causare problemi di performance.
Effettua il monitor della raggiungibilità di applicazioni Office 365, tramite test built-in specifici per Microsoft Office 365, Dynamics 365, Skype for Business e altri servizi Microsoft.

Figura 4 – Creazione di un Service Connectivity Monitor test

Figura 5 – Diagramma che mostra la topology di rete, generata da diversi nodi, per raggiungere un Service Endpoint

Dove installare gli agenti

Per utilizzare Service Endpoint Monitor è necessario installare l’agente di Operations Management Suite su ogni nodo da cui si vuole monitorare la connettività di rete verso uno specifico service endpoint.

Costo della soluzione

Il costo per l’utilizzo di Service Endpoint Monitor è basato su questi due elementi:

Numero delle connessioni, dove la connessione è intesa come test di raggiungibilità di un singolo endpoint, da un singolo agente, per l’intero mese. A questo proposito è possibile consultare la sezione Connection Monitoring nella pagina dei costi.
Volume di dati generato dall’attività di monitor. Il costo lo si ricava dalla pagina dei costi di Log Analytics, nella sezione Data Ingestion.

Traffic Analytics

Traffic Analytics è una soluzione totalmente cloud-based, che consente di avere una visibilità complessiva sulle attività di rete che vengono intraprese nell’ambiente cloud. In Azure per poter consentire o negare la comunicazione di rete verso le risorse connesse alle Azure Virtual Networks (vNet) vengono utilizzati i Network Security Group (NSG), che contengono una lista di regole di accesso. I NSG vengono applicati alle interfacce di rete connesse alle macchine virtuali oppure direttamente alle subnet. La platform utilizza i NSG flow logs per mantenere la visibilità del traffico di rete in ingresso e in uscita dai Network Security Group. Traffic Analytics si basa sull’analisi dei NSG flow logs e dopo una opportuna aggregazione dei dati, inserendo l’intelligence necessaria relativamente a security, topologia e mappa geografica, è in grado di fornire informazioni dettagliate sul traffico di rete del proprio ambiente cloud Azure.

Utilizzando Traffic Analytics si possono effettuare le seguenti operazioni:

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

Figura 6 – Traffic Analytics overview

Figura 7 – Map delle Region Azure attive sulla subscription

DNS Analytics

La soluzione DNS Analytics è in grado di collezionare, analizzare e correlare i log del servizio DNS e mette a disposizione degli amministratori le seguenti funzionalità:

Indentifica i client che tentano di risolvere domini ritenuti malevoli.
Rileva i record appartenenti a risorse obsolete.
Mette in evidenza nomi di dominio frequentemente interrogati.
Mostra il carico delle richieste ricevute dai server DNS.
Effettua il monitor delle registrazioni dinamiche sul DNS fallite.

Figura 8 – Overview della solution DNS Analytics

Dove installare gli agenti

La soluzione richiede la presenza dell’agente di OMS oppure di Operations Manager installato su ogni server DNS che si intende monitorare.

Conclusioni

All’aumentare della complessità delle architetture network in ambienti ibridi, aumenta di conseguenza la necessità di potersi avvalere di strumenti in grado di contemplare differenti topologie di rete. Azure mette a disposizione diversi strumenti cloud based e integrati nella fabric, come quelli descritti in questo articolo, che consentono di monitorare in modo completo ed efficace il networking di questi ambienti. Ricordo che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.

Tutto quello che bisogna sapere sui nuovi Load Balancer di Azure

Microsoft ha recentemente annunciato la disponibilità in Azure degli Standard Load Balancer. Si tratta di load balancer Layer-4, per i protocolli TCP e UDP che, rispetto ai Basic Load Balancer, introducono dei miglioramenti e consentono di avere un controllo più granulare di determinate funzionalità. In questo articolo verranno riportate le caratteristiche principali degli Standard Load Balancer di Azure, al fine di poter avere gli elementi necessari per scegliere la tipologia di bilanciatore più opportuna per le proprie esigenze.

Qualsiasi scenario dove è possibile utilizzare la SKU Basic degli Azure Load Balancer, può essere soddisfatto anche utilizzando la SKU Standard, ma le due tipologie di bilanciatori presentano importanti differenze in termini di scalabilità, funzionalità, livelli di servizio garantito e costo.

Scalabilità

I Load Balancer Standard hanno una maggiore scalabilità, rispetto ai Basic Load Balancer, per quanto riguarda il numero massimo delle istanze (IP Configuration) che possono essere configurate nei pool di backend. La SKU Basic consente di avere fino a 100 istanze, mentre utilizzando la SKU Standard il numero massimo di istanze è pari a 1000.

Funzionalità

Backend pool

Per quanto riguarda i Basic Load Balancer, nei pool di backend, possono risiedere in modo esclusivo:

Macchine virtuali che si trovano all’interno di un availability set.
Una singola VM standalone.
Virtual Machine Scale Set.

Figura 1 – Associazioni possibili nei backend pool dei Basic Load Balancer

Negli Standard Load Balancer invece è consentito inserire nei pool di backend qualsiasi macchina virtuale attestata su una determinata virtual network. Lo scope di integrazione in questo caso non è infatti l’availability set, come per i load balancer Basic, ma è la virtual network e tutti i relativi concetti ad essa associati. Un requisito da tenere in considerazione, per poter inserire nei backend pool degli Standard Load Balancer le macchine virtuali, è che queste non devono avere IP pubblici associati oppure devono avere IP Pubblici con SKU Standard.

Figura 2 – Associazione nei backend pool degli Standard Load Balancer

Availability Zones

Gli Standard Load Balancer contemplano scenari di integrazione con le Availability Zones, nelle region che comprendono questa funzionalità. Per maggiori dettagli a riguardo è possibile consultare questo specifico documento Microsoft, che riporta i concetti principali e le linee guida di implementazione.

Alta disponibilità delle porte

I load balancer con SKU Standard, di tipologia “Internal”, consentono di bilanciare i flussi TCP e UDP su tutte le porte simultaneamente. Per farlo, nella regola di load-balancing, c’è la possibilità di abilitare l’opzione “HA Ports”:

Figura 3 – Configurazione rule di bilaciamento con opzione “HA Ports” abilitata

Il bilanciamento avviene per flusso, il quale è determinato dai seguenti elementi: source IP address, source port, destination IP address, destination port, e protocollo. Questa funzionalità risulta particolarmente utile in scenari dove vengono utilizzate delle Network Virtual Appliances (NVAs) che richiedono scalabilità. Questa nuova funzionalità consente di migliorare le attività richieste relative ad implementazioni in HA delle NVAs.

Figura 4 – Architettura di rete che prevede l’utilizzo del LB con opzione “HA Ports” abilitata

Un altro possibile utilizzo di questa funzionalità è quando si ha la necessità di bilanciare un elevato numero di porte.

Per maggiori dettagli in merito all’opzione “HA Ports” è possibile consultare la documentazione ufficiale.

Diagnostica

I Load Balancer Standard introducono le seguenti funzionalità in termini di capacità diagnostica:

Multi-dimensional metrics: si possono recuperare differenti metriche che consentono di consultare, in tempo reale, lo stato di utilizzo dei load balancer, sia pubblici che interni. Queste informazioni risultano particolarmente utili anche per operazioni di troubleshooting.

Figura 5 – Metriche dei Load Balancer dal portale Azure

Resource Health: in Azure Monitor si ha la possibilità di consultare lo stato di salute dei Load Balancer Standard (al momento disponibile solo per i Load Balancer Standard di tipologia Public).

Figura 6 – Resource health del Load Balancer in Azure Monitor

Si può inoltre consultare lo storico dello stato di health:

Figura 7 – Health history del Load Balancer

Tutti i dettagli relativi alla diagnostica, dei Load Balancer Standard, possono essere consultati nella documentazione ufficiale.

Sicurezza

I Load Balancer con SKU standard sono configurati di default in modo sicuro in quanto, per consentire il funzionamento, è necessario avere un Network Security Group (NSG) dove il flusso di traffico viene consentito in modo esplicito. Come riportato in precedenza, i Load Balancer Standard sono completamente integrati nella virtual network, la quale è caratterizzata dal fatto che è privata e di conseguenza chiusa. I Load Balancer Standard e gli IP Pubblici Standard vengono utilizzati per consentire l’accesso alle virtual network dall’esterno e ora di default è necessario configurare un Network Security Group (chiuso di default) per consentire il traffico voluto. Nel caso non sia presente un NSG, attestato sulla subnet oppure sulla NIC della macchina virtuale, non sarà consentito il relativo accesso da parte del flusso di rete proveniente dal Load Balancer Standard.

I Load Balancer Basic sono invece di default aperti e la configurazione di un Network Security Group è opzionale.

Connessioni in Outbound

I Load Balancer in Azure supportano scenari di connettività sia in inbound che in outbound. I Load Balancer Standard, rispetto ai Load Balancer Basic, si comportano in modo differente per quanto riguarda le connessioni in outbound.

Per effettuare il mapping degli indirizzamenti IP interni e privati della propria virtual network verso gli indirizzi IP pubblici dei Load Balancer viene utilizzata la tecnica Source Network Address Translation (SNAT). I Load Balancer Standard introducono un nuovo algoritmo per avere politiche di SNAT più robuste, scalabili e precise, che consentono di avere una maggiore flessibilità e di disporre di nuove funzionalità.

Utilizzando i Load Balancer Standard è opportuno considerare i seguenti aspetti per quanto riguarda gli scenari di outbound:

Devono essere creati in modo esplicito per consentire alle macchine virtuali la connettività in uscita e sono definiti sulla base delle regole di bilanciamento in ingresso.
Le regole di bilanciamento definiscono come avvengono le politiche di SNAT.
In presenza di più frontend, vengono utilizzati tutti i frontend e per ognuno di questi si moltiplicano le porte SNAT preallocate disponibili.
Si ha la possibilità di scegliere e controllare se uno specifico frontend non lo si vuole utilizzare per le connessioni in uscita.

Nei Basic Load Balancer, in presenza di più frontend IP Pubblici, viene scelto un singolo frontend per essere utilizzato nei flussi in uscita. Questa selezione non può essere configurata e avviene in modo casuale.

Per designare un indirizzo IP specifico è possibile seguire la procedura descritta in questa sezione della documentazione Microsoft.

Operazioni di Management

I Load Balancer di tipologia Standard consentono l’abilitazione delle operazioni di management in modo più rapido, tanto da portare i tempi di esecuzione di queste operazioni al di sotto dei 30 secondi (contro i 60-90 secondi necessari per i Load Balancer con SKU Basic). I tempi di modifica dei pool di backend sono dipendenti anche dalla dimensione degli stessi.

Altre differenze

Al momento per i Public Load Balancer di tipologia Standard non è possibile prevedere l’utilizzo di un indirizzo IPv6 pubblico:

Figura 8 – IPv6 pubblico per i Public Load Balancer

Service-Level Agreement (SLA)

Un importante aspetto da tenere in considerazione, nella scelta della SKU più opportuna per le diverse architetture, è il livello di servizio che si deve garantire (SLA). Utilizzando i Load Balancer Standard viene garantito che un Load Balancer Endpoint, che serve due o più istanze di macchine virtuali in stato di salute, sarà disponibile temporalmente con uno SLA del 99.99%.

I Load Balancer Basic non garantisco questo SLA.

Per maggiori dettagli a riguardo è possibile consultare l’articolo specifico SLA for Load Balancer.

Costo

Mentre per i Load Balancer Basic non sono previsti dei costi, per i Load Balancer Standard sono previsti dei costi di utilizzo in base ai seguenti elementi:

Numero delle regole di load balancing configurate.
Quantità dei dati processati in ingresso e in uscita.

Non sono invece previsti costi specifici per le regole di NAT.

Nella pagina dei costi dei Load Balancer possono essere consultati i dettagli e le cifre.

Migrazione tra SKUs

Per i Load Balancer non è previsto il passaggio dalla SKU Basic alla SKU Standard e viceversa. Ma è necessario prevedere una migrazione in side by side, tenendo in considerazione le differenze funzionali precedentemente descritte.

Conclusioni

L’introduzione dei Load Balancer Standard in Azure consente di disporre di nuove funzionalità e garantiscono una maggiore scalabilità. Queste caratteristiche potrebbero consentire di non dover utilizzare, in scenari specifici, soluzioni di bilanciamento offerte da vendor di terze parti. Rispetto ai Load Balancer tradizionali (SKU Basic) cambiano diversi principi di funzionamento e hanno caratteristiche distinte in termini di costi e SLA, che è bene valutare attentamente per poter scegliere la tipologia di Load Balancer più opportuna, sulla base dell’architettura che si deve realizzare.