Archivi categoria: Networking

Massimizza le prestazioni di Azure Stack HCI: scopri le migliori configurazioni per il networking

Le infrastrutture iperconvergenti (HCI) sono sempre più diffuse in quanto consentono di semplificare la gestione dell’ambiente IT, ridurre i costi e scalare facilmente in caso di necessità. Azure Stack HCI è la soluzione Microsoft che permette di realizzare una infrastruttura hyper-converged per l’esecuzione di workload in ambiente on-premises e che prevede una strategica connessione a vari servizi di Azure per modernizzare la propria infrastruttura IT. Configurare correttamente il networking di Azure Stack HCI è fondamentale per garantire la sicurezza, l’affidabilità e le prestazioni delle applicazioni. In questo articolo, vengono esplorati i fondamenti della configurazione del networking di Azure Stack HCI, approfondendo le opzioni di rete disponibili e le best practice per la progettazione e la configurazione del networking.

Sono differenti i modelli di rete che è possibile prendere come riferimento per progettare, distribuire e configurare Azure Stack HCI. Nei paragrafi seguenti vengono riportati gli aspetti principali da considerare per indirizzare le possibili scelte di implementazione a livello di rete.

Numero di nodi che compongono il cluster Azure Stack HCI

Un singolo cluster Azure Stack HCI può essere composto da un unico nodo e può scalare fino a 16 nodi.

Se il cluster è composto da un singolo server a livello fisico è consigliato prevedere i seguenti componenti di rete, riportati anche nell’immagine:

singolo switch TOR (L2 oppure L3) per il traffico in direzione nord-sud;
due\quattro porte di rete in team per gestire il traffico di management e computazionale collegate allo switch;

Inoltre, opzionalmente è possibile prevedere i seguenti componenti:

due NIC RDMA, utili se si prevede di aggiunge un secondo server al cluster per scalare la configurazione;
una scheda BMC per la gestione remota dell’ambiente.

Figura 1 – Architettura di rete per un cluster Azure Stack HCI composto da un singolo server

Se il cluster Azure Stack HCI è composto da due o più nodi è necessario approfondire i parametri seguenti.

Necessità di switch Top-Of-Rack (TOR) e relativo livello di ridondanza

Per i cluster Azure Stack HCI composti da due o più nodi, in ambiente di produzione, è fortemente consigliata la presenza di due switch TOR, in modo da poter tollerare interruzioni delle comunicazioni riguardanti il traffico nord-sud, in caso di guasto oppure di manutenzione del singolo switch fisico.

Se il cluster Azure Stack HCI è composto da due nodi si può fare in modo di non prevedere una connettività tramite switch per il traffico riguardante lo storage.

Configurazione a due nodi senza switch TOR per la comunicazione storage

In un cluster Azure Stack HCI composto da solo due nodi, per ridurre i costi degli switch, andando magari ad utilizzare switch già in possesso, è possibile collegare in modalità full-mesh le NIC RDMA dello storage.

In determinati scenari, che includono ad esempio branch office, oppure laboratori, si può adottare il seguente modello di rete che prevede un unico switch TOR. Applicando questo modello si ottiene una tolleranza agli errori a livello di cluster, ed è idonea se è possibile tollerare interruzioni della connettività in direzione nord-sud quando il singolo switch fisico si guasta oppure richiede manutenzione.

Figura 2 – Architettura di rete per un cluster Azure Stack HCI composto da due server, senza switch per lo storage e con un unico switch TOR

Sebbene i servizi SDN L3 siano pienamente supportati per questo schema, i servizi di routing come BGP dovranno essere configurati sul dispositivo firewall che si trovano sopra allo switch TOR, se questo non supporta i servizi L3.

Nel caso si voglia ottenere una maggiore tolleranza ai guasti per tutti i componenti di rete è possibile prevedere la seguente architettura, che prevede due switch TOR ridondati:

Figura 3 – Architettura di rete per un cluster Azure Stack HCI composto da due server, senza switch per lo storage e switch TOR ridondati

I servizi SDN L3 sono pienamente supportati da questo schema. I servizi di routing come BGP possono essere configurati direttamente sugli switch TOR se questi supportano i servizi L3. Le funzionalità legate alla sicurezza della rete non richiedono una configurazione aggiuntiva per il dispositivo firewall, poiché sono implementate a livello di virtual network adapter.

A livello fisico è consigliato prevedere i seguenti componenti di rete per ciascun server:

duequattro porte di rete in team, per gestire il traffico di management e computazionale, collegate alloagli switch TOR;
due NIC RDMA in una configurazione full-mesh per il traffico est-ovest per lo storage. Ogni nodo del cluster deve avere una connessione ridondata all’altro nodo del cluster;
come opzionale, una scheda BMC per la gestione remota dell’ambiente.

In entrambi i casi sono necessarie le seguenti connettività:

Reti	Management e computazionale	Storage	BMC
Velocità di rete	Almeno 1 GBps, 10 GBps recommendata	Almeno 10 GBps	Tbd
Tipologia di interfaccia	RJ45, SFP+ oppure SFP28	SFP+ oppure SFP28	RJ45
Porte e aggregazione	Duequattro porte in teaming	Due porte standalone	Una porta

Configurazione a due o più nodi utilizzando switch TOR anche per la comunicazione storage

Quando si prevede un cluster Azure Stack HCI composto da più di due nodi oppure se non si vuole precludere la possibilità di poter aggiungere facilmente ulteriori nodi al cluster, è necessario far confluire anche il traffico riguardante lo storage dagli switch TOR. In questi scenari si può prevedere una configurazione dove si mantengono delle schede di rete dedicate per il traffico storage (non-converged), come mostrato nella seguente immagine:

Figura 4 – Architettura di rete per un cluster Azure Stack HCI composto da due o più server, switch TOR ridondati utilizzati anche per il traffico storage e configurazione “non-converged”

A livello fisico è consigliato prevedere i seguenti componenti di rete per ciascun server:

due schede di rete in team per gestire il traffico di management e computazionale. Ogni NIC è collegata a uno switch TOR diverso;
due NIC RDMA in configurazione standalone. Ogni NIC è collegata a uno switch TOR diverso. La funzionalità multicanale SMB garantisce l’aggregazione dei percorsi e la tolleranza agli errori;
come opzionale, una scheda BMC per la gestione remota dell’ambiente.

Queste le connettività previste:

Reti	Management e computazionale	Storage	BMC
Velocità di rete	Almeno 1 GBps, 10 GBps recommendata	Almeno 10 GBps	Tbd
Tipologia di interfaccia	RJ45, SFP+ oppure SFP28	SFP+ oppure SFP28	RJ45
Porte e aggregazione	Due porte in teaming	Due porte standalone	Una porta

Un’altra possibilità da tenere in considerazione prevede una configurazione “fully-converged” delle schede di rete, come riportato nella seguente immagine:

Figura 5 – Architettura di rete per un cluster Azure Stack HCI composto da due o più server, switch TOR ridondati utilizzati anche per il traffico storage e configurazione “fully-converged”

Quest’ultima soluzione è preferibile quando:

i requisiti di larghezza di banda per il traffico nord-sud non richiedono schede dedicate;
le porte fisiche degli switch sono un numero ridotto;
si vogliono mantenere contenuti i costi della soluzione.

A livello fisico è consigliato prevedere i seguenti componenti di rete per ciascun server:

due schede di rete RDMA in team per il traffico di management, computazionale e storage. Ogni NIC è collegata a uno switch TOR diverso. La funzionalità multicanale SMB garantisce l’aggregazione dei percorsi e la tolleranza agli errori;
come opzionale, una scheda BMC per la gestione remota dell’ambiente.

Queste le connettività previste:

Reti	Management, computazionale e storage	BMC
Velocità di rete	Almeno 10 GBps	Tbd
Tipologia di interfaccia	SFP+ oppure SFP28	RJ45
Porte e aggregazione	Due porte in teaming	Una porta

I servizi SDN L3 sono pienamente supportati da entrambi i modelli sopra riportati. I servizi di routing come BGP possono essere configurati direttamente sugli switch TOR se questi supportano i servizi L3. Le funzionalità legate alla sicurezza della rete non richiedono una configurazione aggiuntiva per il dispositivo firewall, poiché sono implementate a livello di virtual network adapter.

Tipologia di traffico che deve passare dagli switch TOR

Per scegliere gli switch TOR più adatti è necessario valutare il traffico di rete che confluirà da tali apparati di rete, il quale può essere suddiviso in:

traffico di management;
traffico computazionale (generato dai workload ospitati dal cluster), il quale può essere suddiviso in due categorie:
- traffico standard;
- traffico SDN;
traffico storage.

Microsoft ha recentemente cambiato l’approccio a riguardo. Infatti, non è più richiesto che gli switch TOR rispettino ogni requisito di rete riguardante le varie funzionalità, indipendentemente dal tipo di traffico per il quale lo switch viene utilizzato. Questo consente di avere switch fisici supportati in base al tipo di traffico che trasportano e permette di poter scegliere tra un maggior numero di dispositivi di rete ad un costo più contenuto, ma sempre di qualità.

In questo documento sono elencati gli standard di settore obbligatori per i ruoli specifici degli switch di rete utilizzati nelle implementazioni di Azure Stack HCI. Questi standard contribuiscono a garantire comunicazioni affidabili tra i nodi dei cluster Azure Stack HCI. In questa sezione sono invece riportati i modelli degli switch supportati dai vari vendor, in base alla tipologia di traffico prevista.

Conclusioni

Configurare correttamente il networking di Azure Stack HCI è fondamentale per garantire che l’infrastruttura hyper-converged funzioni in modo corretto, garantendo sicurezza, affidabilità e prestazioni ottimali. In questo articolo sono stati riportati i concetti fondamentali riguardanti la configurazione del networking di Azure Stack HCI, analizzando le opzioni di rete disponibili. Il consiglio è di pianificare sempre attentamente gli aspetti legati al networking di Azure Stack HCI, scegliendo l’opzione di rete più appropriata per le esigenze del vostro business e seguendo le best practice di implementazione.

L’importanza di un approccio moderno al networking e di una network governance efficace nell’era del cloud

Il networking è uno dei pilastri nel mondo IT, perché sostiene le infrastrutture, consente lo scambio di tutti i dati necessari al business, sia all’interno sia all’esterno dell’azienda, e abilita la creazione e l’adozione di nuove soluzioni. Si può facilmente intuire come il networking sia un ambito delicato, complesso e in continua evoluzione. Tuttavia, ciò a cui si assiste in molte realtà aziendali è l’ostinazione ad un approccio tradizionale al networking che risulta oggi limitante e poco efficace. In questo articolo vengono elencate le principali sfide di un approccio tradizionale al networking nell’era moderna e vengono riportati alcuni spunti per adottare un approccio differente e per strutturare una network governance efficace.

Le sfide del networking tradizionale nell’era moderna

Entrando nel merito delle sfide principali che i clienti affrontano quotidianamente in ambito networking troviamo:

un aumento della complessità e dell’effort di gestione: la rapida proliferazione di ambienti cloud, dei dispositivi mobili e dell’IoT ha di fatto eroso quelli che sono i confini delle reti moderne, rendendole più difficili da gestire e più vulnerabili;
l’espansione della superficie di attacco: a questo proposito la domanda alla quale è opportuno saper rispondere è «in che modo è possibile garantire una protezione di rete efficace senza interferire con la crescita e le fluttuazioni dei workload in ambienti cloud e multi-cloud?»;
una visibilità ed una integrazione frammentata ed incoerente tra i datacenter locali e gli ambienti cloud: l’aggiunta di prodotti di rete monofunzionali isolati per far fronte a problemi di comunicazione incrementa la complessità, i costi ed il carico di lavoro del personale IT;
cambiamenti nella connettività delle sedi periferiche: la tendenza delle realtà aziendali, distribuite geograficamente, vede la sostituzione delle costose connessioni MPLS con connessioni Internet dirette più convenienti, ma che non sempre permettono di raggiungere gli stessi livelli di qualità e di prestazione.

Tutto questo si traduce in specifici punti di criticità che nel tempo ho riscontrato presso i nostri clienti:

Costi elevati e molta complessità
Molti vendor di soluzioni di rete con una scarsa integrazione
Troppi alert con risposte lente e manuali
Mancanza di personale IT interno opportunamente formato

L’adozione di un approccio moderno al Networking

Alla luce di queste considerazioni diventa indispensabile adottare un approccio moderno al networking in grado di affrontare al meglio tutte queste sfide, andando a ridurre le complessità e a migliorare l’efficienza. Individuare e realizzare architetture di rete progettate per la trasformazione digitale deve avvenire tramite:

Un networking basato sulla sicurezza che garantisce e velocizza l’esperienza di rete e dell’utente.
Una gestione dinamica e trasversale di qualsiasi ambiente per proteggere e controllare l’infrastruttura e le applicazioni on-premise, in ambienti ibridi e nei cloud pubblici.
Soluzioni integrate per connettere i componenti dell’intera infrastruttura di rete, aiutando le organizzazioni ad adattarsi a un ambiente mutevole e sempre più sfidante.
Un ecosistema monitorato e controllato per rilevare e rispondere a malfunzionamenti, alle minacce di sicurezza e per ottimizzare le operazioni, alleggerendo il carico di lavoro sul personale.

Come strutturare la governance del networking

Nell’ambito dell’IT governance merita sicuramente un capitolo dedicato la network governance che deve contemplare un insieme di processi attraverso i quali è possibile garantire ad un’organizzazione un utilizzo efficace ed efficiente delle risorse IT in ambito networking, al fine di poter raggiungere i propri obiettivi.

Anche la network governance deve comprende l’applicazione di:

controlli che aiutano l’azienda a mitigare i rischi e a creare «guardrail»
misurazioni per verificare la presenza di potenziali problemi

Le principali discipline che emergono in ambito Network Governance sono:

Baseline di compliance e di sicurezza
Gestione delle vulnerabilità
Gestione delle identità e controllo degli accessi
Accelerazione, controllo e coerenza nei processi di deployment e change delle soluzioni di rete
Ottimizzazione ed efficientamento delle reti wired e wireless

Un aspetto importante è che tutto ciò deve essere fatto per le risorse IT in ambito networking in qualsiasi ambiente, sia on-premise sia in realtà cloud e multi-cloud con un approccio strutturato, consolidato ed olistico.

Microsoft, anche in questo ambito, offre diversi strumenti e soluzioni che permettono di affrontare la sfida della network governance in ambiente Azure, ai quali è necessario affiancare esperienza per mettere in atto processi consolidati ed affidabili.

Conclusioni

Negli ultimi anni l’adozione di architetture ibride ha registrato un notevole interesse da parte di molte aziende, attratte dalle possibilità offerte e dai benefici. Per poter realizzare al meglio questi ambienti e promuovere l’innovazione è indispensabile adeguare anche l’approccio nell’utilizzo delle risorse di rete ed estendere i processi di governance dell’ambiente IT all’ambito networking.

Come rafforzare la protezione di rete grazie a Defender for Cloud

In ambito networking Microsoft Azure mette a disposizione una serie di soluzioni, native della piattaforma, che consentono di ottenere un elevato grado di sicurezza se vengono adottate nel modo opportuno. Un importante valore aggiunto per raffinare e rafforzare la security posture della rete è dato da Microsoft Defender for Cloud, in quanto consente di contemplare, mediante funzionalità specifiche, anche determinati aspetti del networking. In questo articolo viene approfondito come Microsoft Defender for Cloud consente di verificare, raggiungere e mantenere una configurazione da best practice del networking di Azure.

Panoramica di Defender for Cloud

La soluzione Microsoft Defender for Cloud mette a disposizione una serie di funzionalità in grado di contemplare due importanti pilastri della sicurezza per le architetture moderne che adottano componenti cloud: Cloud Security Posture Management (CSPM) e Cloud workload protection (CWP).

Figura 1 – I pilastri della sicurezza contemplati da Microsoft Defender for Cloud

In ambito Cloud Security Posture Management (CSPM) Defender for Cloud è in grado di fornire le seguenti funzionalità:

Visibilità: per valutare l’attuale situazione relativa alla sicurezza.
Guida all’hardening: per poter migliorare la sicurezza in modo efficiente ed efficace.

Grazie ad un assessment continuo Defender for Cloud è in grado di scoprire continuamente nuove risorse che vengono distribuite e valuta se sono configurate in base alle best practice di sicurezza. In caso contrario, le risorse vengono contrassegnate e si ottiene un elenco prioritario di consigli relativi a ciò che è opportuno correggere per migliorare la loro protezione. Questo processo avviene nello specifico anche per le risorse di rete e le raccomandazioni sono incentrare sulle varie soluzioni in ambito networking come ad esempio: next generation firewall, Network Security Group e JIT VM access. Un elenco completo delle raccomandazioni e delle relative azioni correttive, consigliate da Defender for Cloud per la rete, è possibile consultarlo in questo documento.

Figura 2 – Esempi di raccomandazioni relative al networking

Per quanto concerne l’ambito Cloud Workload Protection (CWP), Defender for Cloud eroga avvisi di sicurezza basati su Microsoft Threat Intelligence. Inoltre, include una ampia gamma di protezioni avanzate ed intelligenti per i workload, fornite tramite piani di Microsoft Defender specifici per le differenti tipologie di risorse presenti nelle subscription ed in ambienti ibridi e multi-cloud.

Le funzionalità specifiche di Defender for Cloud in ambito networking

Per quanto riguarda il networking, Defender for Cloud oltre a fare un assessment continuo delle risorse e a generare eventuali raccomandazioni, include altre funzionalità specifiche:

Figura 3 – Le funzionalità di Microsoft Defender for Cloud in ambito networking

Adaptive network hardening

I Network Security Groups (NSG) sono lo strumento principale per controllare il traffico di rete in Azure, attraverso il quale, tramite delle regole di deny e permit, è possibile filtrate le comunicazioni tra differenti workload attestati sulle virtual network di Azure. Tuttavia, possono esserci delle situazioni in cui il traffico di rete effettivo che attraversa un NSG corrisponde solo ad un sottoinsieme delle regole che sono state definite all’interno del NSG stesso. In questi casi, per migliorare ulteriormente la security posture è possibile perfezionare le regole presenti nei NSG, in base ai modelli di traffico di rete effettivi. La funzionalità di adaptive network hardening di Defender for Cloud verifica proprio questo e genera delle raccomandazioni per rafforzare ulteriormente le regole presenti nei NSG. Per ottenere questo risultato viene utilizzato un algoritmo di machine learning che tiene conto del traffico di rete effettivo, della configurazione presente, dell’intelligence sulle minacce e di altri indicatori di compromissione.

Figura 4 – Raccomandazioni relative alla funzionalità di adaptive network hardening

Network Map

Per monitorare continuamente lo stato di sicurezza della rete, Defender for Cloud mette a disposizione una mappa interattiva che consente di visualizzare graficamente la topologia della rete, includendo consigli e raccomandazioni per fare hardening delle risorse di rete. Inoltre, usando la mappa è possibile controllare le connessioni tra le macchine virtuali e le subnet, fino a valutare se ogni nodo è configurato correttamente dal punto di vista della rete. Andando a controllare come sono collegati i nodi è possibile individuare e bloccare più facilmente le connessioni indesiderate che potrebbero potenzialmente rendere più facile per un utente malintenzionato attaccare la propria rete. Per maggiori informazioni su questa funzionalità è possibile consultare la documentazione ufficiale Microsoft.

Figura 5 – Mappa di rete generata da Defender for Cloud

Per poter usufruire di queste specifiche funzionalità è necessario licenziare il piano Defender for Servers Plan 2.

Conclusioni

Una strategia vincente in ambito Azure networking, in grado di supportare anche il modello Zero Trust, la si può ottenere applicando un mix-and-match dei differenti servizi di sicurezza di rete per avere una protezione su più livelli. Al tempo stesso risulta molto utile poter far affidamento alle funzionalità di Defender for Cloud, anche per contemplare gli aspetti legati al networking, che tramite un assessment continuo ed una visibilità approfondita permettono di ottenere ambienti configurati secondo le best practice anche nel corso del tempo.

Azure Networking: i servizi di sicurezza per un approccio Zero Trust

Sono sempre più numerose le realtà aziendali che per sostenere il ritmo dettato dalla trasformazione digitale e per altre ragioni specifiche intraprendono un percorso di adozione di soluzioni cloud e di migrazione dei propri workload verso il cloud. Per garantire che le risorse presenti in ambiente cloud siano al sicuro è necessario adottare un nuovo modello di sicurezza che si adatti in modo più efficace alla complessità dell’ambiente moderno, contemplando ambienti ibridi e proteggendo applicazioni e dati indipendentemente da dove risiedono. In questo articolo vengono descritti alcuni dei principali servizi di sicurezza del networking di Azure che aiutano le organizzazioni a adottare il modello Zero Trust, un approccio alla sicurezza integrato e proattivo da applicare su differenti fronti.

Il framework Zero Trust elaborato da Microsoft si basa sui seguenti tre principi per proteggere le risorse:

Verify explicitly. Autenticare e autorizzare sempre, tenendo in considerazione diversi aspetti come: l’identità utente, la location, lo stato del dispositivo, il servizio oppure il workload, la classificazione dei dati e le anomalie.
Use least privileged access. Limitare l’accesso degli utenti mediante: accessi “just-in-time” (JIT) e “just-enough-access” (JEA), policy adattive basate sul rischio e protezione dei dati.
Assume breach. Ridurre al minimo l’esposizione e segmentare gli accessi andando a definire perimetri granulari. Utilizzare una crittografia end-to-end e fare analisi per: ottenere visibilità, rilevare minacce e migliorare le difese.

L’approccio Zero Trust presuppone una violazione e accetta la realtà che i malintenzionati possano essere ovunque. Per questa ragione tale modello consiglia di verificare tutti i tentativi di accesso, limitare l’accesso degli utenti (JIT e JEA) e rafforzare la protezione delle risorse. A tutte queste pratiche è però importante associare dei controlli sulle comunicazioni di rete, andando a segmentando la rete in zone più piccole per poi controllare quale traffico può fluire tra di esse. Un approccio dove i firewall di rete vengono implementati esclusivamente sulle reti perimetrali, filtrando il traffico tra zone attendibili e non attendibili diventa limitante per questo modello. Invece, è consigliato filtrare il traffico anche tra reti interne, host e applicazioni.

In Azure sono presenti diversi servizi di sicurezza relativi al networking, descritti nei paragrafi seguenti, che consentono di filtrare e controllare le comunicazioni di rete in modo granulare, supportando così il modello Zero Trust.

Network Security Group (NSG)

I Network Security Groups (NSG) 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 (NSG) possono essere applicati su una determinata subnet di una VNet Azure oppure direttamente sulle singole schede di rete delle macchine virtuali Azure. I NSG 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 (ASG). Si tratta di gruppi che contengono schede di rete di macchine virtuali presenti su Azure. Gli ASG consentono di raggruppare con nomi mnemonici più server, utili in particolare per workload dinamici. Gli Application Security Groups consentono quindi di non dover più gestire nelle regole degli NSG gli indirizzi IP delle macchine virtuali Azure, purché questi IP siano relativi a VMs attestate sulla stessa VNet.

Sebbene ci sia la possibilità di attivare soluzioni firewall a livello di sistema operativo guest, i NSG di Azure sono in grado di garantire la protezione anche se la macchina virtuale in Azure viene compromessa. Infatti, un utente malintenzionato che ottiene l’accesso alla macchina virtuale e ne eleva i privilegi potrebbe essere in grado di disabilitare il firewall sull’host. I NSG, essendo implementati al di fuori della macchina virtuale, forniscono forti garanzie contro gli attacchi al sistema di firewalling a bordo delle macchine virtuali.

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

Azure Firewall

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

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

Figura 2 – Panoramica delle funzionalità di Azure Firewall Premium

Le best practice dettate dal modello Zero Trust prevedono di crittografare sempre i dati in transito per ottenere una crittografia end-to-end. Tuttavia, dal punto di vista operativo, spesso si ha la necessità di avere una maggiore visibilità per applicare servizi di sicurezza aggiuntivi ai dati non crittografati. Con le funzionalità di Azure Firewall Premium tutto ciò è possibile. Infatti, la versione Premium permette di ottenere un livello di protezione ulteriore dalle minacce di sicurezza, mediante funzionalità come TLS Inspection e IDPS che garantiscono un maggior controllo del traffico di rete al fine di intercettare e bloccare la diffusione di malware e virus. Per ulteriori dettagli riguardanti le funzionalità di Azure Firewall Premium è possibile consultare questo articolo.

DDoS protection

Il modello Zero Trust si pone l’obiettivo di autenticare e autorizzare qualsiasi componente che risiede sulla rete. Nonostante ciò, qualsiasi sistema in grado di ricevere pacchetti di rete è vulnerabile agli attacchi DDoS, anche quelli che utilizzano un’architettura Zero Trust. Di conseguenza, è fondamentale che qualsiasi implementazione Zero Trust adotti anche una soluzione per la protezione dagli attacchi DDoS.

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

Azure Firewall Manager

Il modello di sicurezza Zero Trust ci indirizza nell’adozione di un approccio legato alla micro-segmentazione e alla definizione di perimetri granulari nella propria architettura di rete. Per agevolare questo approccio è possibile utilizzare Azure Firewall Manager, uno strumento che, mettendo a disposizione un unico pannello di controllo centralizzato, è in grado di semplificare la configurazione e la gestione delle network security policy, le quali spesso devono essere distribuite su più istanze di Azure Firewall. Oltre alla gestione delle policy di Azure Firewall, Azure Firewall Manager consente di associare alle reti virtuali un piano di protezione dagli attacchi DDoS.

Inoltre, Azure Firewall Manager consente di utilizzare offerte SECaaS (Security as a Service) di terze parti per proteggere l’accesso a Internet degli utenti.

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

Al fine di ottenere una protezione di rete efficace si riportano alcune raccomandazioni che è consigliato tenere in considerazione per l’utilizzo dei vari componenti di sicurezza relativi al networking di Azure:

I Network Security Groups (NSG) e l’Azure Firewall sono tra di loro complementari e utilizzandoli in modo congiunto si ottiene un grado di difesa elevato. I NSG è 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 Private Link, i quali possono essere utilizzati in concomitanza ad Azure Firewall per consolidare e centralizzare i log degli accessi.
Nel caso si voglia effettuare una pubblicazione applicativa protetta (HTTP/S in inbound) è opportuno utilizzare il Web Application Firewall presente nelle soluzioni di Application Delivery di Azure, affiancandolo quindi ad Azure Firewall. Web Application Firewall (WAF), consente di ottenere una protezione da vulnerabilità e da attacchi comuni, come ad esempio attacchi X-Site Scripting e SQL Injection.
Azure Firewall può essere affiancato anche da soluzioni WAF/DDoS di terze parti.
Oltre ad Azure Firewall è possibile valutare l’adozione di Network Virtual Appliances (NVAs) fornite da vendor di terze parti e disponibili nel marketplace di Azure.

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

Figura 3 – Esempio di una architettura Hub-Spoke con i vari servizi di sicurezza

Inoltre, prevedendo l’integrazione con i servizi di sicurezza di Azure, come Microsoft Defender for Cloud, Microsoft Sentinel ed Azure Log Analytics, è possibile ottimizzare ulteriormente la gestione delle security posture e la protezione dei workload.

Conclusioni

Il modello di sicurezza definito Zero trust dagli analisti di Forrester Research è ormai un imperativo per la protezione dei propri ambienti. Azure mette a disposizione una vasta gamma di servizi che consentono di ottenere elevati livelli di sicurezza, agendo su differenti fronti per sostenere questo modello. Per affrontare questo percorso di adozione del modello Zero Trust, una strategia vincente in ambito Azure networking la si può ottenere applicando un mix-and-match dei differenti servizi di sicurezza di rete per avere una protezione su più livelli.

Azure Networking: come estendere una rete locale ad Azure con una connettività privata

Nel momento in cui si decide di intraprendere una strategia basata su un cloud ibrido, che combina le risorse IT on-premises con le risorse ed i servizi del cloud pubblico, è opportuno valutare attentamente come connettere la propria rete locale con le reti virtuali presenti nel cloud pubblico. In Azure una possibilità è quella di utilizzare ExpressRoute, una connessione privata e dedicata che avviene tramite un provider di connettività di terze parti. In questo articolo vengono riportate le possibili architetture di rete con ExpressRoute, insieme ad una serie di accorgimenti da tenere in considerazione per un deployment di successo.

Molto spesso viene utilizzata una VPN Site-to-site per stabilire la connettività tra le risorse on-premise e le risorse in ambiente Azure attestate sulle Virtual Network. Questo tipo di connettività è ideale per i seguenti casi d’uso:

Ambienti di sviluppo, test, laboratori, ma anche workload di produzione dove le risorse dislocate in ambiente Azure non un utilizzano in modo intensivo e strategico la connettività verso l’ambiente on-premises e viceversa.
Quando si ha una tolleranza accettabile per quanto riguarda la larghezza di banda e la velocità nella connessione ibrida.

Ci sono alcuni casi d’uso però dove è opportuno configurare ExpressRoute, secondo le best practice Microsoft, per garantire una connettività bidirezionale tra la rete on-premise e le reti virtuali (vNet) di Azure del cliente. Infatti, ExpressRoute risulta adatto per i seguenti casi d’uso:

Se si devono soddisfare requisiti di alta velocità, connessione a bassa latenza e di disponibilità/resilienza elevata.
In presenza di carichi di lavoro mission-critical che fanno uso di una connettività ibrida.

Che cos’è ExpressRoute?

Grazie ad ExpressRoute è possibile attivare una connessione privata dedicata, fornita da un provider di connettività di terze parti, per estendere la rete locale in Azure. Le connessioni ExpressRoute non passano attraverso la rete Internet pubblica. In questo modo possono offrire un livello di sicurezza superiore, maggiore affidabilità, velocità più elevate e latenze coerenti rispetto alle connessioni Internet tradizionali.

Figura 1 – Schema logico di ExpressRoute

Le connessioni ExpressRoute abilitano l’accesso ai servizi seguenti:

Servizi di Microsoft Azure (scenario trattato in questo articolo).
Servizi di Microsoft 365. Microsoft 365 è stato progettato per essere accessibile in modo sicuro e affidabile tramite Internet. Per questo motivo è consigliabile utilizzare ExpressRoute con Microsoft 365 solo in determinati scenari, come descritto in questo articolo Microsoft.

Risulta possibile creare una connessione ExpressRoute tra la rete locale ed il cloud Microsoft tramite quattro differenti modalità:

Figura 2 – Modelli di connettività di ExpressRoute

I provider di connettività possono offrire uno o più modelli di connettività ed è possibile scegliere il modello più appropriato per le proprie esigenze di connettività.

Architetture di riferimento

La seguente architettura di riferimento mostra come è possibile connettere la rete locale alle reti virtuali in Azure, usando Azure ExpressRoute.

Figura 3 – Architettura di riferimento per estendere una rete locale con ExpressRoute

L’architettura sarà costituita dai seguenti componenti.

Rete aziendale locale (nello schema “On-premises network”). Si tratta della rete locale privata del Cliente.
Edge router locali. Si tratta dei router che collegano la rete locale al circuito gestito dal provider.
ExpressRoute Circuit. Si tratta di un circuit layer 2 oppure layer 3, fornito dal provider di connettività, che unisce la rete locale ad Azure tramite edge router. Il circuit utilizza l’infrastruttura hardware gestita dal provider di connettività.
Edge router Microsoft. Si tratta di router in una configurazione ad alta disponibilità attivo-attivo. Questi router consentono al provider di connettività di connettere i propri circuit direttamente al data center.
Virtual network gateway (ExpressRoute). Il gateway di rete virtuale ExpressRoute consente alla rete virtuale (VNet) di Azure di connettersi al circuito ExpressRoute usato per la connettività con la rete locale.
Reti virtuali di Azure (VNet). Rete virtuali che risiedono in una region di Azure.

Nell’architettura sopra descritta, ExpressRoute sarà utilizzato come canale di connettività principale per connettere la rete locale ad Azure.

Inoltre, è possibile prevedere l’utilizzo di una connessione VPN site-to-site come fonte di connettività di backup per migliorare la resilienza della connettività. In questo caso l’architettura di riferimento sarà la seguente:

Figura 4 – Architettura di riferimento per utilizzare sia ExpressRoute sia una connessione VPN site-to-site

In questo scenario sono previsti, in aggiunta ai componenti architetturali descritti in precedenza, i seguenti componenti:

Appliance VPN on-premises. Un dispositivo oppure un servizio che fornisce connettività esterna alla rete locale. L’appliance VPN può essere un dispositivo hardware oppure una soluzione software supportata per la connessione ad Azure.
Virtual network gateway (VPN). Il gateway di rete virtuale VPN consente alla rete virtuale di connettersi all’appliance VPN presente nella rete locale.
Connessione VPN. La connessione ha proprietà che specificano la tipologia di connessione (IPSec) e la chiave condivisa con l’appliance VPN locale per crittografare il traffico.

Come monitorare ExpressRoute

Per consentire di monitorare le risorse di rete in presenza di una connettività ExpressRoute si può adottare lo strumento di piattaforma Azure Monitor, attraverso il quale è possibile verificare la disponibilità, le prestazioni, l’utilizzo ed il funzionamento di tale connettività.

Si riporta a titolo di esempio una schermata della soluzione.

Figura 5 – Monitor dei circuit ExpressRoute tramite Azure Monitor

Mediante questa soluzione verrà fornito un mapping dettagliato della topologia di tutti i componenti di ExpressRoute (peering, connessioni, gateway) in relazione tra loro. Le informazioni dettagliate sulla rete per ExpressRoute includeranno una dashboard attraverso la quale è possibile consultare le metriche, la velocità effettiva, l’eventuale drop di pacchetti di rete e le metriche del gateway.

Si riporta a titolo di esempio una schermata della dashboard che mostra il Throughput totale del traffico in ingresso ed in uscita per il circuit ExpressRoute (espresso in bit/secondo). Inoltre, risulta possibile visualizzare il throughput per le singole connessioni.

Figura 6 – Metriche relative al Throughput delle connection ExpressRoute

Per maggiori dettagli è possibile fare riferimento alla documentazione ufficiale Microsoft su come effetturare il monitor di ExpressRoute.

Considerazioni sulla sicurezza

Microsoft nelle security baseline per ExpressRoute, riferite all’Azure Security Benchmark versione 1.0, il set di linee guida specifico per Azure creato da Microsoft, fornisce diverse indicazioni che è consigliato seguire. Tra le principali che è opportuno adottare troviamo:

Definizione e implementazione delle configurazioni di sicurezza standard per Azure ExpressRoute utilizzando le Azure Policy.
Utilizzo di tag per i componenti Azure ExpressRoute in modo da fornire metadati e un’organizzazione logica e strutturata delle risorse.
Applicazione di lock per evitare la cancellazione oppure la modifica accidentalenon voluta dei componenti Azure relativi alla configurazione ExpressRoute.
Utilizzo degli strumenti della piattaforma Azure per monitorare le configurazioni delle risorse di rete e rilevare le modifiche relative alle risorse di rete delle connessioni ExpressRoute. Creazione di Alert in Azure Monitor da generare quando vengono apportate modifiche alle risorse critiche.
Configurazione della raccolta centralizzata degli Activity Log per i componenti ExpressRoute.

Conclusioni

ExpressRoute offre una connessione veloce e affidabile ad Azure con larghezze di banda che possono raggiungere fino ai 100 Gbps. Si tratta quindi di un’opzione ideale per scenari specifici come la migrazione periodica dei dati, la replica a fini di business continuity, il disaster recovery, e l’attivazione di strategie di alta disponibilità. Grazie all’elevata velocità ed ai tempi di latenza ridotti di ExpressRoute, Azure sembrerà una naturale estensione dei propri data center. In questo modo è possibile trarre vantaggio dalla scalabilità e dall’innovazione del cloud pubblico senza compromessi in termini di prestazioni di rete.

Funzionalità da Next-Generation Firewall con Azure Firewall Premium

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

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

Le funzionalità di Azure Firewall Premium

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

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

Figura 1 – Panoramica di Azure Firewall Premium

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

TLS inspection

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

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

Terminazione TLS in uscita.

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

Terminazione TLS tra virtual network di spoke (est-ovest).

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

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

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

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

IDPS

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

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

Figura 4 – Modalità dell’IDPS

URL filtering

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

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

Figura 5 – URL filtering nelle application rules

Categorizzazione Web

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

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

Figura 6 – Categorizzazione Web in una regola di accesso

**Il passaggio dalla versione Standard alla versione *Premium***

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

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

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

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

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

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

Il costo di Azure Firewall Premium

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

Conclusioni

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

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

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

Che cos’è Azure Kubernetes Service (AKS)?

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

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

La topologia di rete

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

Figura 2 – Topologia di rete Hub and Spoke

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

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

Figura 3 – Topologia di rete Hub and Spoke per AKS

Hub Virtual Network

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

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

Azure Bastion, il servizio PaaS che offre un accesso RDP ed SSH sicuro e affidabile alle macchine virtuali, direttamente tramite il portale di Azure.

Spoke Virtual Network

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

I due gruppi di nodi (node pools) di AKS:

- AKS System Node pool: il pool di nodi di sistema che ospitano i pod necessari per l’esecuzione dei servizi core del cluster.
- AKS User Node pool: il pool di nodi user che eseguono i workload applicativi e l’ingress controller.

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

AKS Internal Load Balancer: il servizio di bilanciamento per instradare e distribuire il traffico in ingresso per le risorse Kubernetes. In questo caso viene utilizzato il componente Azure Load Balancer, che consente il bilanciamento del carico Layer-4 per tutti i protocolli TCP e UDP, garantendo alte prestazioni e bassissime latenze.

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

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

Figura 4 – Panoramica di Azure Private Link

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

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

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

Traffico di Management

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

Cluster AKS privato

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

Conclusioni

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

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

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

Nuove funzionalità in Azure Firewall Premium

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

Figura 1 – Panoramica di Azure Firewall Premium

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

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

TLS inspection

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

Terminazione TLS in uscita.

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

Terminazione TLS tra virtual network di spoke (est-ovest).

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

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

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

IDPS

Figura 4 – Modalità dell’IDPS

URL filtering

Figura 5 – URL filtering nelle application rules

Categorizzazione Web

Figura 6 – Categorizzazione Web in una regola di accesso

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

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

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

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

Figura 7 – Comparativa funzionalità Azure Firewall Premium vs NVAs

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

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

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

Conclusioni

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

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

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

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

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

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

Strumenti di Monitoring

Topology view

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

Figura 1 – Esempio di una Topology view

Connection Monitor

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

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

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

Figura 2 – Panoramica dello strumento Connection Monitor

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

Network Performance Monitor

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

Strumenti di Diagnostica

IP Flow Verify

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

Next Hop

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

Connection Troubleshoot

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

Packet Capture

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

VPN Troubleshoot

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

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

Strumenti di Logging

NSG Flow Logs

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

Traffic Analytics

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

Figura 3 – Data flow di Traffic Analytics

Utilizzando Traffic Analytics si possono effettuare le seguenti operazioni:

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

Figura 4 – Virtual Network in Traffic Analytics

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

Conclusioni

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

Azure Application delivery: quale servizio di load balancing scegliere?

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

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

Servizi di load balancing di Azure

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

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

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

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

Figura 2 – Panoramica di Azure Application Gateway

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

Figura 3 – Panoramica di Azure Front Door

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

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

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

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

Servizi di load-balancing: globali vs regionali

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

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

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

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

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

Disponibilità del servizio, la quale è possibile consultarla nella pagina degli SLA di Azure.
Costo della soluzione, non solo dato dal costo del servizio stesso, ma considerando anche i costi delle operations per la gestione della soluzione basata su quel servizio.
Funzionalità e limiti di ciascun servizio.

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

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

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

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

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

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

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

Conclusioni

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