Mettere in sicurezza VM e applicazioni è possibile grazie a diversi servizi attivabili sulle Virtual Network di Microsoft Azure: mostriamo le loro possibili combinazioni e integrazioni attraverso una serie di architetture e scenari.

I servizi che possiamo attivare su Azure sono sempre di più e molti di essi sono connessi a Virtual Network o anche esposti pubblicamente su Internet. Sono quindi in aumento le tipologie di workload che necessitano di protezione, e dobbiamo proteggere tutte le relative risorse da attacchi che diventano sempre più sofisticati.

Per rispondere a questa sfida, possiamo però contare su diversi strumenti che Microsoft Azure ci mette a disposizione per difenderci: essendo però questi piuttosto eterogenei, non sempre è immediato orientarsi nella scelta di quelli più adatti.

In questa guida mostriamo diversi scenari che possiamo incontrare nel mondo reale andando a pubblicare applicazioni in cloud e quali servizi Azure o loro combinazioni possiamo adottare di volta in volta per avere una protezione efficace e “mirata” sulle nostre esigenze.

Scenario 1: Nessuna Applicazione Web

Nello scenario che stiamo per descrivere ci basterà implementare solo Azure Firewall. Questo servizio offre tutte le funzionalità di un firewall di ultima generazione, quindi è in grado di effettuare packet filtering sia sugli indirizzi IP che sulle porte dei protocolli TCP/UDP, ma anche di operare a un livello più alto, cioè sugli attributi delle applicazioni HTTPS o SQL.

Descrivendo il flusso: il client che stabilisce una connessione chiamerà l’IP pubblico di Azure Firewall come IP di destinazione. Azure Firewall effettua quindi un Destination Network Address Translation (DNAT) “traducendo” l’IP di destinazione con quello privato del server che esegue l’applicazione e un Source NAT traducendo l’IP sorgente del client con il proprio IP privato. Quando l’applicazione risponde, il flusso viene ripetuto con la logica inversa.

Scenario 2: Solo Applicazioni Web

In questo scenario è sufficiente la sola presenza di Application Gateway, servizio che offre le funzionalità di un web load balancer e che a differenza di Azure Firewall funziona come un vero e proprio Reverse Application Proxy. I bilanciatori tradizionali operano al livello 4 della pila OSI, ovvero di Transport, effettuando il bilanciamento in base a indirizzo IP sorgente e porta. Application Gateway può invece smistare il traffico effettuando decisioni di livello più avanzato, per es. in base agli attributi della richiesta http, in quanto opera a livello OSI 7 (Application)

AG non effettua nessun NAT (Network Address Translation), ma inoltra al server di backend anche l’indirizzo IP originale del client, aggiungendolo nell’http header. Questo può essere utile nel caso di applicazioni web che necessitano di conoscere l’indirizzo sorgente del client per fornire contenuto specifico in base alla geolocalizzazione: per questo motivo in questo scenario abbiamo preferito Application Gateway ad Azure Firewall.

Scenario 3: Mix di Applicazioni Web e Applicazioni non-web

Finora abbiamo visto Azure Firewall e Application Gateway come servizi complementari, ma a seconda del contesto possono anche essere usati assieme per incrementarne l’efficacia.

In questo nuovo scenario la soluzione migliore è l’utilizzo di Application Gateway e Azure Firewall in parallelo: è il caso in cui ad esempio vogliamo pubblicare sia applicazioni web che non-web, dunque può essere utile sfruttare i vantaggi di entrambi i servizi. Quindi Azure Firewall si occuperà di ispezionare il traffico in ingresso per le applicazioni non web, mentre Application Gateway proteggerà quello diretto alle applicazioni web.

Per ottenere lo stesso livello di protezione su entrambi i tipi di applicazioni, sull’Application Gateway oltre alle feature già descritte prima potremmo abilitare un ulteriore servizio: WAF (Web Application Firewall). Si tratta di un device con funzionalità da firewall, specializzato per le applicazioni web: consente di proteggere in maniera centralizzata le applicazioni dai più diffusi tipi di attacchi e vulnerabilità.

Scenario 4: Applicazioni che necessitano di gestione dell’IP sorgente o destinazione

A seconda delle esigenze sulla gestione dell’IP sorgente, possiamo ipotizzare due nuove architetture dove anzichè collocare Application Gateway e Azure Firewall in parallelo, li mettiamo in serie.

Nel primo caso andiamo a gestire quelle applicazioni che necessitano di conoscere l’IP sorgente del client, a prescindere che siano web based o no. Collocheremo quindi come primo servizio che il client contatterà l’Application Gateway con l’aggiunta di WAF, in modo che offra protezione per le web application e possa preservare anche l’IP originale del client, mentre Azure Firewall verrà messo a valle come secondo livello di ispezione e si occuperà di controllo centralizzato e raccolta log.

Nel secondo caso gestiamo quelle situazioni in cui non ci interessa preservare l’IP sorgente ma vogliamo che sia Azure Firewall, con i suoi filtri più avanzati, a bloccare il traffico malevolo prima che raggiunga Application Gateway. In tal caso invertiremo la configurazione mettendo Azure Firewall come primo punto di accesso e Application Gateway dopo di esso.

Scenario 5: Protezione a layer 3+4 con DDoS Protection Standard

Introduciamo ora un altro interessante servizio Azure per la security: il DDoS Protection Standard, creato appositamente per proteggere le risorse dagli attacchi di tipo “Distributed denial of service (DDoS)”. Le risorse Azure, quando sono esposte su internet, possono essere facilmente oggetto di questi attacchi che consistono nel saturare tutte le risorse dell’applicazione fino a renderla indisponibile. Attacchi di questo tipo sfruttano di solito vulnerabilità nei livelli 3 e 4 della pila OSI, e la protezione del servizio DDoS si concentra quindi su queste.

Mentre la rete globale di Azure è protetta di default attraverso la DDoS Protection livello Basic, offerta quindi gratuitamente, il servizio Standard offre una protezione aggiuntiva attraverso delle policies che possono essere adattate alle applicazioni specifiche del cliente, il tutto in maniera intelligente in quanto il servizio è in grado di analizzare il traffico tipico dell’applicazione in modo da profilarlo e potere così più facilmente riconoscere le attività anomale. In più offre una serie di report e alert sugli attacchi rilevati, e la possibilità di essere integrato con Azure Security Center per potenziare ulteriormente il monitoraggio.

Scenario 6: Protezione a layer 3+4+livello Application

Possiamo ipotizzare un’ulteriore combinazione di due servizi di Azure Security appena visti per ottenere un doppio livello di protezione: Azure DDos e WAF. Essendo quest’ultimo basato su Application Gateway come mostrato nei precedenti scenari, otterremmo quindi una protezione completa ai livelli 3, 4 e 7 della pila OSI aggregando le feature di questi servizi.

Come mostrato nello screenshot, questi 2 servizi potrebbero lavorare assieme proteggendo la rete centrale nell’ambito di una particolare architettura di rete denominata “hub and spoke”.

Descrivendo in breve questa topologia standard: distribuiamo delle risorse condivise in una virtual network centrale denominata “hub”, che potranno connettersi a specifiche applicazioni isolate in apposite virtual network grazie ai virtual network peering. In questa architettura quindi, Azure Firewall e Application Gateway insieme a DDoS Protection verranno attivati nella virtual network con ruolo hub, anche se i server di backend che pubblicheranno possono stare nelle reti spoke, ottenendo quindi un ulteriore livello di isolamento e quindi protezione.

Conclusioni

Abbiamo visto una serie di servizi che sono tra loro complementari e possono quindi essere usati da soli o integrati tra loro: gli scenari mostrati sono solo alcuni esempi possibili tra le varie combinazioni che possono essere ipotizzate sulla base delle peculiari esigenze del cliente.

Partendo dai primi due scenari più semplici e dal costo più ridotto in quanto adottiamo un solo tipo di servizio, arriviamo fino a quelli (5 e 6) con la presenza di servizi dal costo più elevato come la DDoS Protection Standard, di conseguenza più adatti per aziende con un volume più elevato di workload da proteggere.

Infine consideriamo che gli strumenti visti presentano potenziali integrazioni con ulteriori servizi. Un esempio può essere Azure Kubernetes, nel caso in cui vogliamo proteggere i workload contenuti negli AKS cluster, oppure Azure Front Door che è un servizio molto simile a Application Gateway ma che anziché essere collocato in una Virtual Network, è disponibile a livello globale e decentralizzato.

 

Fonti e approfondimenti:

Firewall and Application Gateway for virtual networks – Azure Example Scenarios | Microsoft Docs

Azure DDoS Protection Standard Overview | Microsoft Docs

 

Microsoft Azure è una piattaforma di Cloud Computing accessibile tramite un portale online che consente di accedere e gestire i servizi e le risorse cloud forniti da Microsoft

 

Azure Engineer

 

0 commenti

Lascia un Commento

Vuoi partecipare alla discussione?
Fornisci il tuo contributo!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *