Archivi categoria: Azure Networking

Panoramica del servizio DNS in Azure

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

Risoluzione dei nomi pubblici

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

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

Figura 1 – Creazione della DNS Zone

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

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

Figura 2 – Name Server per la DNS Zone creata

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

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

Figura 3 – Aggiunta di un record DNS

Risoluzione dei nomi privati

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

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

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

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

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

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

Scenari di utilizzo

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

Risoluzione dei nomi per una singola Virtual Network

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

Figura 6 – Azure Private DNS per una singola VNet

Risoluzione dei nomi tra Virtual Network differenti

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

Figura 7 – Azure Private DNS per due VNet

Funzionalità di Split-Horizon

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

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

Costo della soluzione

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

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

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

Vantaggi

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

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

Conclusioni

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

Azure Networking: panoramica dei servizi di protezione

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

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

Figura 1 – Azure Networking Services

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

Network Security Group (NSG)

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

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

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

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

Service Endpoints

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

Figura 4 – Schema di sintesi dei Sevice Endpoints

Azure Firewall

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

Figura 5 – Posizionamento di Azure Firewall

 

Web Application Firewall

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

Figura 6 – Schema di overview dell’Application Gateway con WAF

DDoS protection

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

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

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

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

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

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

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

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

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

Conclusioni

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

Azure Virtual WAN: introduzione alla soluzione

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

 

Figura 1 – Azure Virtual WAN overview

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

 

Virtual WAN

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

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

Figura 3 – Creazione Azure Virtual WAN

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

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

Figura 4 – Branch-to-branch connectivity option

 

Site

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

Figura 5 – Creazione di un site

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

 

Virtual Hub

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

Figura 6 – Creazione di un Hub

Figura 7 – Associazione del site con un Hub

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

 

Hub virtual network connection

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

Figura 8 – Connessione della VNet a un hub

 

Configurazione del dispositivo VPN on-prem

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

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

Figura 9 – Download della configurazione VPN

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

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

Figura 11 – Stato del site connesso

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

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

Figura 12 – Check Hub health

 

Conclusioni

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