Archivi categoria: Azure Networking

Azure Networking: nuove funzionalità da conoscere per progettare al meglio le architetture di rete

Le soluzioni cloud evolvono molto rapidamente e rimanere costantemente aggiornati è un elemento fondamentale per innovarsi e per saper rispondere efficacemente ai cambiamenti tecnologici. Con il cambio di passo imposto dalla digital transformation anche le infrastrutture di rete devono essere sempre più efficienti, flessibili ed in grado di erogare al meglio i servizi richiesti dal business aziendale. Per modernizzare la propria strategia di progettazione e di implementazione in ambito Azure Networking è perciò importante valutare come evolvono le varie tecnologie. In questo articolo vengono riportate le novità recentemente rilasciate da Microsoft e che possono interessare la progettazione del networking di Azure, con dei riferimenti a dei casi d’uso reali.

Azure Bastion e VNet peering

Azure Bastion è un servizio PaaS che offre un accesso RDP ed SSH sicuro e affidabile alle macchine virtuali, direttamente tramite il portale di Azure. Il provisioning del servizio Azure Bastion viene effettuato all’interno di una Virtual Network di Azure e consente l’accesso senza dover assegnare degli indirizzi IP pubblici direttamente ai sistemi.

La novità è che ora Azure Bastion può lavorare in sinergia con i Virtual Network (VNet) peering. Questo significa che è possibile attivare Azure Bastion su una VNet specifica e lo stesso servizio può essere utilizzato per connettersi anche alle macchine virtuali attestate sulle VNet in peering con questa.

Azure Bastion funziona sia in presenza di network peering che collegano VNet sulla stessa region di Azure, sia con VNet peering di tipologia global, che collegano VNet dislocate in region di Azure differenti. Dal punto di vista delle architetture di rete questa possibilità apre nuovi possibili scenari. Nel modello di rete tipico ed ampiamente utilizzato, definito hub-and-spoke, si ha una rete virtuale in Azure di hub che funge da punto di connettività verso la rete on-premises e le reti virtuali che eseguono il peering con l’Hub vengono definite spoke, utili per isolare i carichi di lavoro. Adottando questo modello è possibile attivare Azure Bastion sulla rete di hub. In questo modo sarà possibile raggiungere con un unico servizio Azure Bastion anche tutte le macchine virtuali distribuite nelle VNet di spoke.

Figura 1 – Azure Bastion in una architettura hub-and-spoke

Nel diagramma seguente viene riportato il deployment di Azure Bastion in una architettura di rete hub-and-spoke dove:

  • Il Bastion host viene attivato nella rete virtuale centralizzata di Hub.
  • Vengono consentite le comunicazioni, per le porte TCP 3389 e 22, provenienti dalla subnet di Azure Bastion presente nella virtual network di Hub, verso gli IP privati delle virtual network di Spoke.
  • Nessun IP pubblico viene richiesto per accedere alle macchine virtuali.

Grazie a questa configurazione sarà possibile semplificare l’architettura e ridurre i costi Azure, in quanto sarà necessario un solo servizio Azure Bastion per l’intera topologia di rete hub-and-spoke.

Inoltre, può essere effettuato il provisioning di Azure Bastion anche in topologie di rete full-mesh, ottenendo la medesima esperienza di accesso ai sistemi in modalità RDP / SSH per le VMs attestate su tutte le virtual network in peering.

Si riportano alcune osservazioni in merito:

  • Risulta possibile avere attivi contemporaneamente più Bastion hosts tra virtual network in peering. Questo può accadere in particolare nel periodo di transizione, quando si vogliono consolidare diversi Bastion hosts secondo la topologia hub-and-spoke sopra descritta. In presenza di più Bastion host, quando si effettuerà la connessione, sarà proposto di scegliere quale Bastion host utilizzare.
  • Attualmente Azure Bastion supporta gli scenari di virtual network in peering solo se queste risiedono in subscription appartenenti allo stesso tenant.

Azure Firewall: nuove impostazioni DNS

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. Le funzionalità di Azure Firewall sono state arricchite aggiungendo il supporto dei custom DNS e del DNS proxy.

Custom DNS

Per impostazione predefinita Azure Firewall utilizza i DNS di Azure per la risoluzione dei nomi. Ora è stata inclusa la possibilità di configurare Azure Firewall per utilizzare dei server DNS specifici.

Nelle impostazioni è possibile configurare un singolo server DNS oppure più server DNS:

Figura 2 – Impostazione dei custom DNS in Azure Firewall dal portale Azure

Azure Firewall può effettuare la risoluzione dei nomi anche utilizzando Azure Private DNS. In questo scenario è richiesto che la VNet all’interno della quale risiede Azure Firewall sia collegata all’Azure Private Zone.

DNS proxy

Azure Firewall può ora essere configurato per svolgere il ruolo di DNS proxy. Abilitando questa nuova funzionalità è possibile configurare come DNS delle virtual network l’indirizzo IP privato di Azure Firewall. In questo modo tutto il traffico DNS viene indirizzato verso Azure Firewall, il quale funge da intermediario tra i sistemi che effettuano le richieste DNS e i server DNS stessi, evitando in questo modo possibili incoerenze nelle risoluzioni dei nomi se vengono utilizzati dei DNS custom.

Quando il firewall di Azure agisce come DNS proxy, sono previste due tipologie di cache:

  • Positive cache: la risoluzione DNS va a buon fine. In questo caso Azure Firewall utilizza il TTL (time to live) del pacchetto o dell’oggetto.
  • Negative cache: la risoluzione DNS non va a buon fine. In questo caso le informazioni vengono memorizzate nella cache di Azure Firewall per un’ora.

Figura 3 – Configurazione di Azure Firewall come DNS proxy dal portale Azure

Questa funzionalità consente di valutare un nuovo scenario di utilizzo per Azure Firewall, molto utile quando si ha la necessità di gestire la risoluzione DNS in presenza dei Private Link, il meccanismo che permette di instaurare una connessione privata verso i servizi in Azure.

Ad ogni servizio PaaS di Azure che utilizza Azure Private Link viene assegnato un FQDN mappato e archiviato in una Azure Private DNS zone. Le richieste inviate verso le Azure DNS Private Zones vengono indirizzate all’IP di piattaforma 168.63.129.16, il quale è raggiungibile solo dall’interno dell’ambiente Azure. Per questa ragione, se la richiesta DNS ha origine dai sistemi on-premises (o comunque dall’esterno di Azure), è necessario attivare un DNS proxy all’interno di una rete virtuale di Azure connessa all’ambiente on-premise. Grazie a questa nuova funzionalità di DNS proxy di Azure Firewall è possibile gestire questa sfida di risoluzione dei nomi dei servi PaaS che utilizzano Private Link con i seguenti step:

  • La VNet all’interno della quale risiede Azure Firewall la si collega all’Azure Private Zone.
  • Azure Firewall lo si configura per utilizzare il DNS predefinito di Azure e si abilita la funzionalità di DNS Proxy.
  • Si configura il server DNS locale per inoltrare in modo condizionale le richieste ad Azure Firewall per il nome della zona richiesto.

Azure Firewall: utilizzo di FQDN filtering nelle network rule

Nelle Network Rule di Azure Firewall è ora possibile utilizzare dei fully qualified domain name (FQDN) basati sulla risoluzione DNS di Azure Firewall. Questa funzionalità permette di filtrare il traffico in uscita per qualsiasi protocollo TCP / UDP (NTP, SSH, RDP, etc.) e richiede che sia attiva la funzionalità di DNS proxy descritta nel paragrafo precedente. Azure Firewall, quando configurato come DNS proxy, archivia tutti gli indirizzi IP risolti dagli FQDN utilizzati nelle network rule. Per questa ragione come best practice è bene utilizzare gli FQDN nelle network rule.

Azure Firewall, sia per le application rule che per le network rule, converte l’FQDN in uno o più indirizzi IP in base al server DNS selezionato (Azure DNS oppure DNS personalizzato). Nel momento in cui avviene una nuova risoluzione DNS vengono aggiunti i nuovi indirizzi IP alle regole del firewall, mentre gli indirizzi IP che non vengono più restituiti dal server DNS hanno una scadenza di 15 minuti. Le Network Rule di Azure Firewall vengono aggiornate ogni 15 secondi utilizzando la risoluzione DNS. Se si ha la necessità di applicare dei filtri FQDN rimane comunque buona norma utilizzare sempre le application rule di Azure Firewall per i protocolli HTTP/S oppure MSSQL, mentre per tutti i restanti protocolli è possibile utilizzare sia le application rule che le network rule.

Nuove funzionalità per gli Azure VPN gateway

In seguito, si riportano le nuove funzionalità che è possibile adottare in presenza degli Azure VPN gateway:

  • Alta disponibilità dei server RADIUS nelle VPN point-to-site: questa funzionalità consente di effettuare una configurazione in alta disponibilità presso i clienti che utilizzano l’autenticazione RADIUS/AD per le VPN point-to-site.
  • Policy IPsec/IKE personalizzate con timeout DPD: l’impostazione del timeout IKE DPD (Dead Peer Detection) consente di regolare il valore di timeout della sessione IKE in base alla latenza di connessione e alle condizioni del traffico. Questa configurazione risulta utile per ridurre al minimo le disconnessioni del tunnel, migliorando l’affidabilità e l’esperienza di utilizzo.
  • Supporto APIPA per gli annunci BGP: questa funzione consente di stabilire sessioni Border Gateway Protocol (BGP), con i VPN gateway di Azure, usando indirizzi APIPA (169.254.x.x). Questa funzionalità è utile in particolare per i clienti con router VPN legacy, Amazon Web Service (AWS) VGW, Google Cloud Platform (GCP) VPN che utilizzano indirizzi APIPA (Automatic Private IP Addressing) per annunciare gli indirizzi BGP.
  • Supporto dei nomi FQDN per le VPN site-to-site: questa funzionalità consente di configurare le VPN site-to-site in presenza di apparati che non dispongono di indirizzi IP pubblici statici per connettersi ai VPN gateway di Azure. Risulta infatti possibile utilizzare il nome di dominio completo (FQDN) anziché gli indirizzi IP. I VPN gateway di Azure saranno in grado di effettuare la risoluzione del nome DNS, aggiornando automaticamente la destinazione per stabilire le connessioni IPsec/IKE della VPN.
  • Gestione delle sessioni e revoca degli utenti per le VPN point-to-site: viene data la possibilità di elencare e revocare le connessioni dei singoli utenti ai VPN gateway, direttamente dal portale di Azure ed in tempo reale.

Conclusioni

Diverse sono le novità rilasciate recentemente da Microsoft in ambito Azure networking ed è opportuno valutarle attentamente per effettuare una progettazione accurata. In questo modo sarà possibile realizzare architetture di rete efficaci, ottimizzando i costi ed in grado di sfruttare tutte le potenzialità offerte dalla piattaforma Azure.

Please follow and like us:

Come configurare il servizio Azure Bastion per accedere in modo sicuro alle macchine virtuali

Azure Bastion è un servizio PaaS che offre un accesso RDP ed SSH sicuro e affidabile alle macchine virtuali, direttamente tramite il portale di Azure. Il provisioning del servizio Azure Bastion viene effettuato all’interno di una Virtual Network di Azure e supporta l’accesso a tutte le macchine virtuali su di essa attestate, senza dover assegnare degli indirizzi IP pubblici direttamente ai sistemi. In questo articolo viene riportato come attivare il servizio e quali accorgimenti è bene prendere in considerazione.

Il deployment di Azure Bastion è per virtual network e non per subscription oppure per singola virtual machine. Pertanto, completata la configurazione sarà possibile accedere direttamente dal portale Azure a tutte le macchine virtuali attestate sulla virtual network del Bastion host.

L’attivazione del servizio Azure Bastion richiede:

  • Una subnet almeno /27, la quale deve essere chiamata AzureBastionSubnet e sulla quale sarà attestato il Bastion host. Su questa subnet al momento non è supportata la configurazione di User Defined Routes.
  • Un indirizzo IP Pubblico statico che sarà assegnato alla risorsa Bastion. L’IP pubblico deve essere di SKU Standard e deve essere nella stessa region Azure sulla quale si intende attivare il servizio.

Sulla subnet AzureBastionSubnet è possibile applicare uno specifico Network Security Group (NSG). I NSG sono lo strumento principale per controllare il traffico di rete in Azure e consentono di filtrare le comunicazioni con apposite regole di deny e permit.

Per farlo è opportuno esaminare il traffico di rete necessario per Azure Bastion:

Figura 1 – Flussi di rete necessari per Azure Bastion

Il Network Security Group (NSG) sulla subnet AzureBastionSubnet dovrà contemplare le seguenti regole.

Inbound security rules

  • Traffico in ingresso da Internet: l’indirizzo IP Pubblico di Azure Bastion deve essere acceduto sulla porta TCP 443. Le porte 3389/22 *non* è necessario aprirle.
  • Traffico in ingresso dall’Azure Bastion control plane. Risulta necessario abilitare la porta 443 in entrata utilizzando il tag di servizio GatewayManager. Ciò consente al control plane, ovvero Gateway Manager, di poter comunicare con Azure Bastion.

Figura 2 – NSG AzureBastionSubnet – Inbound security rules

Outbound security rules

  • Traffico in uscita verso le VMs target: Azure Bastion raggiungerà le VM di destinazione tramite indirizzo IP privato. I NSG devono consentire il traffico in uscita verso le altre sottoreti di destinazione per le porte 3389 e 22.
  • Traffico in uscita verso altri endpoint pubblici in Azure. Azure Bastion deve essere in grado di connettersi a vari endpoint pubblici all’interno di Azure (ad esempio, per archiviare i logs di diagnostica e i metering logs). Per questo motivo, Azure Bastion deve essere autorizzato ad uscire con la porta 443 verso il tag di servizio AzureCloud.

Figura 3 – NSG AzureBastionSubnet – Outbound security rules

Per la sottorete sulla quale viene è attestata la macchina che deve essere acceduta da Azure Bastion è necessario prevedere le seguenti regole.

Inbound security rules

  • Traffico in ingresso da Azure Bastion: Azure Bastion raggiungerà la VM di destinazione tramite IP privato sulle porte RDP / SSH (rispettivamente le porte 3389 e 22). Pertanto, come best practice, è possibile aggiungere come sorgente solo la sottorete di Azure Bastion in questa regola.

Figura 4 – NSG sulla subnet target

La creazione dell’Azure Bastion host può essere fatta direttamente dal portale Azure completando i seguenti passaggi:

Figura 5 – Aggiunta del servizio Azure Bastion

Figura 6 – Parametri richiesti in fase di creazione del servizio Azure Bastion

Completata la configurazione del servizio Azure Bastion è possibile utilizzarlo come riportato in seguito.

Figura 7 – Accesso a una VM dal portale Azure

Figura 8 – Inserimento delle credenziali per accedere a una VM dal portale Azure

Figura 9 – Accesso RDP alla VM direttamente dal browser

Per consentire l’accesso al servizio è necessario assegnare i seguenti ruoli:

  • Reader role sulle virtual machine alle quali si vuole consentire l’accesso
  • Reader role sulle NIC con indirizzo IP privato della virtual machine
  • Reader role sulla risorsa Azure Bastion

Azure Bastion è un servizio a pagamento, per ottenere i dettagli sui costi è possibile accedere alla pagina Azure Bastion pricing.

Conclusioni

Azure Bastion garantisce un accesso remoto semplice e sicuro ai sistemi presenti in ambiente Azure. Diverse sono le funzionalità che saranno prossimamente rilasciate per questo servizio e che lo renderanno ancora più completo e flessibile. Tra queste il supporto per Virtual Network in peering e per la multi-factor authentication.

Please follow and like us:

Azure Networking: come mettere in sicurezza i deployments di Window Virtual Desktop

Windows Virtual Desktop è un servizio completo di virtualizzazione dei desktop e delle applicazioni disponibile in Azure che, in un periodo come questo, dove il lavoro da casa è aumentato esponenzialmente, ha visto un’ampia adozione. Consentire ai propri dipendenti di lavorare da casa richiede alle organizzazioni di affrontare cambiamenti importanti della propria infrastruttura IT in termini di capacità, rete, sicurezza e governance. La soluzione Virtual Desktop Infrastructure (VDI) in Azure può aiutare le realtà aziendali ad affrontare in modo efficace queste evoluzioni, ma è necessario proteggere l’accesso a questi ambienti VDI in modo opportuno. In questo articolo viene descritto come è possibile strutturare il networking in Azure per proteggere in modo efficace i deployment di Windows Virtual Desktop.

Per poter adottare il giusto approccio è necessario valutare quali sono i componenti di Windows Virtual Desktop (WVD) e le loro iterazioni. Il servizio è distribuito secondo un modello di responsabilità condivisa e vede:

  • RD Clients che si collegano ai desktop e alle applicazioni erogati dal servizio WVD. L’ambiente può essere raggiunto da qualsiasi postazione con accesso Internet e la gestione dei client ricade nelle responsabilità del cliente.
  • Servizi Azure gestiti che hanno il compito di pilotare le connessioni tra i client RD e le macchine virtuali Windows in Azure. Si tratta dei ruoli server necessari per questo ambiente, quali Gateway, Web Access, Broker e Diagnostics, in modalità totalmente gestita da Microsoft.
  • Macchine virtuali in Azure attestate su una virtual network, la cui gestione è totalmente in carico al cliente.

Figura 1 – Shared Responsibility model di Windows Virtual Desktop

Per mettere in totale sicurezza l’ambiente Windows Virtual Desktop è necessario definire la topologia di rete più opportuna e i flussi di comunicazione necessari.

Topologia di rete Hub-Spoke per Windows Virtual Desktop

Nell’architettura di rete di tipologia Hub-Spoke, l’Hub è una rete virtuale in Azure che funge da punto di connettività verso la rete on-premises. Tale connettività può avvenire tramite VPN Site to site oppure tramite ExpressRoute. Gli Spoke sono le reti virtuali che eseguono il peering con l’Hub e possono essere usate per isolare i carichi di lavoro. Un buon approccio potrebbe quindi essere quello di strutturare il networking di Azure adottando fin da subito questa topologia di rete e posizionare le macchine virtuali Windows Virtual Desktop in una rete di Spoke. Questa architettura di rete è pensata anche per posizionare nella rete di Hub una network virtual appliance (NVA) per controllare i flussi di rete in modo centralizzato. Il controllo delle comunicazioni di rete può essere demandato a una network virtual appliance (NVA) di terze parti oppure ad 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.

Figura 2 – Hub-spoke network topology in Azure

Flussi di comunicazione necessari per Windows Virtual Desktop

Diversi sono i flussi di comunicazione che è necessario prevedere e che grazie alla topologia di rete Hub-Spoke è possibile governare facilmente e in modo centralizzato.

Figura 3 – Flussi di comunicazione per l’ambiente Windows Virtual Desktop nella topologia Hub-Spoke

Windows Virtual Desktop non richiede di dover aprire dei flussi di comunicazione in ingresso verso la virtual network su cui sono attestate le relative macchine virtuali.

Per consentire un corretto funzionamento del servizio è però necessario prevedere l’accesso dalle macchine WVD, attestate sulla virtual network di spoke, verso specifici Fully Qualified Domain Names (FQDNs). La lista completa degli indirizzi necessari per il funzionamento di Windows Virtual Desktop è possibile consultarla in questo documento Microsoft. Per semplificare questa configurazione, in Azure Firewall è disponibile l’apposito FQDN tag chiamato WindowsVirtualDesktop, che è possibile utilizzare in una application rule specifica. A questo proposito è bene specificare che questo tag non contempla l’accesso agli storage e service bus accounts necessari per gli host pool di Windows Virtual Desktop. Trattandosi di URL specifici per deployment è possibile andare a consentire il traffico https in modo puntuale verso gli URL specifici oppure si può utilizzare il wildcard per i seguenti FQDNs: *xt.blob.core.windows.net, *eh.servicebus.windows.net e *xt.table.core.windows.net. Questi FQDN tag sono presenti anche nelle Virtual Appliance di terze parti per facilitare la configurazione.

Le macchine Windows Virtual Desktop devono inoltre poter accedere ai server DNS, al servizio KMS per i processi di attivazione e ai server NTP per la sincronizzazione dell’orario.

In base alle esigenze aziendali può inoltre essere necessario abilitare l’accesso a Internet per gli utenti finali, applicando opzionalmente specifiche regole per la navigazione. Per filtrate il traffico Internet può essere utilizzato un secure web gateway posizionato on-premises oppure la network virtual appliance posizionata nella rete di Hub.

Infine, è opportuno prevedere l’abilitazione dei flussi di comunicazione necessari tra le macchine Windows Virtual Desktop, posizionate nella rete di Spoke, e le risorse che risiedono nell’ambiente on-premises.

Conclusioni

Uno dei primi aspetti da tenere in considerazione quando si decide di implementare soluzioni nel cloud è l’architettura di rete da adottare. Stabilire fin dall’inizio la topologia di rete più opportuna consente di avere una strategia vincente ed evita di trovarsi nella condizione di dover migrare in seguito i workloads, per adottare architetture di rete differenti, con tutte le complicazioni che ne conseguono. L’architettura di rete Hub-Spoke si presta bene anche per scenari di deploy di Windows Virtual Desktop, in quanto consente di ottenere un elevato livello di controllo sugli aspetti legati alla sicurezza di rete e di effettuare una segregazione del traffico di rete adottando Azure Firewall oppure Network Virtual Appliance di terze parti.

Please follow and like us:

Azure Networking: gestione degli indirizzi IP per il traffico in uscita da Azure

Quando si progettano architetture in Azure è spesso importante stabilire con precisione quali indirizzi IP pubblici vengono utilizzati per il traffico di rete in uscita. Un requisito comunemente richiesto è garantire che il traffico in uscita dalla rete virtuale di Azure avvenga con indirizzi IP pubblici stabiliti. Questo requisito tipicamente è dato dalla necessità di autorizzare in modo esplicito il traffico proveniente da Azure su altre risorse. In questo articolo viene descritto come in Azure è possibile governare questo aspetto, quali sono gli elementi da prendere in considerazione e quali novità sono state recentemente introdotte in questo ambito.

Per impostazione predefinita, il traffico in uscita da una rete virtuale di Azure utilizza degli indirizzi IP pubblici allocati in modo casuale e questi possono cambiare.

Assegnazione IP Pubblico alla singola macchina virtuale

Quando si ha la necessità di fissare l’indirizzo IP Pubblico per il traffico in uscita di una singola macchina virtuale, il metodo più semplice è assegnare a questa un indirizzo IP Pubblico. Tale indirizzo IP sarà utilizzato per il traffico in ingresso, se necessario, e per il traffico in uscita. Tramite i Network Security Groups (NSGs), lo strumento principale per controllare il traffico di rete in Azure, è possibile filtrare le comunicazioni con apposite regole di deny e permit.

Assegnazione IP Pubblico al Load Balancer

Anziché assegnare un indirizzo IP pubblico direttamente a una macchina virtuale, è possibile assegnarlo a un load balancer. In questo modo, qualsiasi macchina virtuale aggiunta al pool di back-end del load balancer utilizzerà l’IP pubblico ad esso assegnato per il traffico di rete in uscita.

Figura 1 – Load Balancer con IP Pubblico

Questo approccio è consigliato qualora ci sia davvero l’esigenza di adottare un Load Balancer per bilanciare il traffico di rete in ingresso tra più macchine virtuali. In questo modo è anche possibile limitare il numero di IP pubblici richiesti, configurando più macchine virtuali dietro allo stesso load balancer.

Utilizzo di Azure Firewall

In presenza di Azure Firewall, se il traffico di rete viene opportunamente fatto confluire a questo componente tramite delle rotte specifiche, si ha la certezza che uscirà verso Internet usando gli IP Pubblici assegnati all’istanza Azure Firewall. Ad Azure Firewall si possono associare fino a 250 indirizzi IP pubblici, ma è opportuno tenere in considerazione che attualmente l’indirizzo IP Pubblico sorgente di Azure Firewall utilizzato per le connessioni viene scelto in modo casuale tra gli IP assegnati. Questo aspetto è da valutare quando sono necessarie autorizzazioni specifiche per il traffico proveniente da Azure Firewall e se si deve gestire l’accesso a FTP Passivi (non supportati se Azure Firewall ha più indirizzi IP assegnati). Microsoft ha comunque in roadmap la possibilità di fare configurazioni SNAT specificando l’indirizzo IP Pubblico da utilizzare.

Figura 2 – Azure Firewall overview

Azure Firewall è un componente sempre più diffuso e la sua attivazione è consigliata per gestire e governare al meglio il traffico di rete. Tuttavia, in assenza di questo componente è possibile valutare metodi alternativi meno costosi se l’obiettivo unico è governare quali indirizzi IP vengono utilizzati nel traffico di rete in uscita.

Virtual Network NAT

Virtual Network NAT è un nuovo metodo che è stato recentemente introdotto per semplificare nelle reti virtuali la connettività Internet ed interessa esclusivamente il traffico di rete in uscita. Se configurato su una subnet, tutta il traffico in uscita utilizzerà gli indirizzi IP pubblici statici specificati. Il tutto è possibile senza l’adozione di indirizzi IP pubblici direttamente collegati alle macchine virtuali e di load balancer.

Figura 3 – Virtual Network NAT

Una subnet può quindi essere configurata specificando quale risorsa Gateway NAT utilizzare. Al termine della configurazione tutti i flussi di rete in uscita (UDP e TCP) provenienti da qualsiasi macchina virtuale attestata su quella subnet, utilizzeranno l’IP Pubblico (standard SKU), il Public IP Prefix oppure una combinazione di questi. La medesima risorsa Gateway NAT può essere utilizzata da più subnet, purché appartenenti alla stessa Virtual Network.

Virtual Network NAT è compatibile con le seguenti risorse, aventi SKU standard:

  • Load balancer
  • Public IP address
  • Public IP prefix

Questi componenti utilizzati insieme a Virtual Network NAT forniscono connettività Internet in entrata alle subnet. Virtual Network NAT gestisce invece tutta la connettività Internet in uscita dalla subnet. L’utilizzo congiunto di questi componenti è possibile in quanto sono consapevoli della direzione in cui è stato avviato il flusso e ne permettono la corretta gestione.

Figura 4 – Virtual Network NAT flow direction

Lo SLA garantito per questa funzionalità è del 99.9%, in quanto viene distribuita automaticamente dalla piattaforma su più fault domains per sostenere al meglio eventuali fault.

Virtual Network NAT è di default un servizio regionale ed è possibile isolarlo in una specifica zona (zonal deployment), quando si devono contemplare scenari che adottano diverse availability zones.

Figura 5 – Virtual Network NAT con availability zones

Per monitorare l’utilizzo di questo componente e per effettuare operazioni di troubleshooting è possibile consultare le metriche esposte in Azure Monitor:

  • Bytes
  • Packets
  • Dropped Packets
  • Total SNAT connections
  • SNAT connection state transitions per interval.

NSG flow logging non è al momento supportato per il Virtual Network NAT.

Il costo di questo componente è dato da due fattori:

  • Ore di esistenza della risorsa
  • Dati processati

Per maggiori dettagli sui costi è possibile consultare la pagina Microsoft relativa al pricing per questo componente.

Conclusioni

Per governare quali indirizzi IP vengono utilizzati dai sistemi in Azure per comunicare verso l’esterno ci sono diverse possibilità, ciascuna con le proprie caratteristiche. Nel caso si stia adottando la topologia di rete Hub-spoke con un Azure Firewall nella rete di Hub, il controllo è garantito by design. Un’ottima soluzione in assenza di Azure Firewall oppure di altre Network Virtual Appliance è l’adozione della metodologia Virtual Network NAT recentemente introdotta.

Please follow and like us:

Formazione: Cloud Community con la scuola per esplorare il mondo digitale

Siamo lieti di comunicarvi che la nostra community parteciperà ad un importante progetto di formazione dedicato alle classi quarta e quinta dell’Istituto Superiore Statale P. Gobetti di Scandiano (RE).

L’iniziativa di formazione durerà due mesi e coinvolgerà circa 50 ragazzi. Si tratta di un percorso di formazione appositamente pensato per avvicinare gli studenti ai grandi argomenti digital. In seguito si riportano i temi trattati durante questo progetto.

Automation con Powershell

Powershell è la shell multi-piattaforma Microsoft pensata per automatizzare e rendere ripetibili le operazioni amministrative sui sistemi IT. L’automazione consente di rendere certe e ripetibili le operazioni siano esse applicate a poche unità o migliaia di sistemi. In questo modulo introduttivo ci si limiterà alla gestione della piattaforma Windows e non si tratteranno temi legati alla piattaforma Linux.

Obiettivi

Rendere gli studenti in grado di:

  • Identificare le varie versioni di Powershell e l’ambito di utilizzo
  • Descrivere le funzionalità di powershell, ricercare ed eseguire i comandi base
  • Utilizzare la powershell pipeline
  • Lavorare con variabili, array e hash tables
  • Scrivere un semplice script powershell
  • Eseguire comandi e script powershell remotamente

Prerequisiti

  • Logica di programmazione per oggetti
  • Conoscenza dei meccanismi base ai autenticazione e autorizzazione in un dominio Active Directory

Docente

Cloud Networking in ambienti ibridi

L’IT aziendale non è più limitato o limitabile alle sole reti di proprietà tra sedi o stabilimenti, la cloud pubblica nelle sue varie declinazioni è ormai componente fondamentale di qualsiasi architettura IT. La possibilità di interconnettere sistemi e servizi è il primo mattone per la costruzione di un ambiente ibrido tra pubblico e privato (on-premises). In questo modulo gli studenti avranno modo di comprendere il networking su cloud pubblica e di realizzare un collegamento tra cloud pubblica e rete privata.

Obiettivi

Rendere gli studenti in grado di:

  • Identificare i maggiori cloud provider pubblici
  • Descrivere le varie tipologie di cloud computing
  •  Descrivere le differenze in termini di gestione dei costi tra sistemi di proprietà e cloud computing (se studiano anche economia ci può essere un rimando alla differenza tra capital expenses e operational expenses)
  • Descrivere cosa si intende per virtual networking e in particolare i concetti di virtual network di Microsoft Azure
  • Raccogliere le informazioni necessarie alla creazione di una virtual network su Microsoft Azure
  •  Creare una virtual network in subnet, definire regole di routing e network security group
  • Conoscere le diverse tipologie di connettività tra virtual network diverse e tra virtual network e reti private
  • Mettere in comunicazione una virtual network Azure con una rete locale privata
  • Cenni di sicurezza per le virtual network su cloud pubblica.

Prerequisiti

  • Conoscenza del protocollo tcp/ip e delle modalità di routing

Docente

Conclusioni

L’obiettivo principale di questa iniziativa community è quello di aiutare ed incentivare i giovani talenti a crescere e formarsi per le professioni legate al mondo digitale. Grazie a questo percorso di formazione si vuole darà l’opportunità ai giovani partecipanti di avvicinarsi al mondo del lavoro con una maggiore consapevolezza e una visione più ampia.

Please follow and like us:

Come attivare un servizio SFTP in Azure basato su Container

Un protocollo di comunicazione che viene comunemente utilizzato per il trasferimento di file tra differenti realtà aziendali è certamente SFTP (SSH File Transfer Protocol oppure Secure File Transfer Protocol). Ad oggi, in Azure non è disponibile un servizio di piattaforma totalmente gestito che consenta di erogare un accesso tramite il protocollo SFTP. L’attivazione di una macchina virtuale in Azure che ospiti il servizio SFTP comporta costi di attivazione e un effort di gestione non trascurabili. In questo articolo viene riportata una soluzione che è possibile adottare per erogare in ambiente Azure il servizio SFTP, basata su Azure Container Instances (ACI) ed Azure File Shares.

La soluzione proposta si basa sui seguenti componenti:

  • Azure Container Instances (ACI), che in Azure è il metodo più semplice e rapido per l’esecuzione di containers on-demand in un ambiente serverless gestito. Il tutto viene reso possibile senza dover attivare macchine virtuali specifiche e la manutenzione necessaria è pressoché trascurabile. La soluzione Azure Container Instances è idonea in scenari che richiedono containers isolati, senza la necessità di adottare un sistema di orchestrazione. Il servizio Azure Container Instances comporta dei costi minimi che dipendono dal numero di vCPU e di GBs di memoria utilizzati dal container group. Per maggiori dettagli sui costi è possibile consultare la relativa pagina ufficiale Microsoft.
  • Azure File, il servizio Azure gestito che permette di accedere a file shares nel cloud tramite il protocollo Server Message Block (SMB).

Figura 1 – Architettura Azure

Sarà quindi attivato un container docker basato su Linux per erogare il servizio SFTP tramite Azure Container Instance (ACI). Per poter avere un accesso persistente allo storage dal container verrà fatto il mount di una Azure Files Shares. I file trasferiti tramite il servizio SFTP saranno pertanto anche accessibili tramite protocollo SMB, gestendo le opportune autorizzazioni, anche fermando l’esecuzione del container creato.

Per effettuare il deploy di questa soluzione è possibile utilizzare come base di partenza i template referenziati in questo documento Microsoft. Si tratta di due template, dove il primo prevede anche la creazione di uno storage account, ma di tipologia V1.

Figura 2 – Deployment tramite template custom

Al fine di ottenere una corretta integrazione con ambienti Azure esistenti e per garantire un accesso filtrato al servizio SFTP è necessario effettuare il deploy di container instances all’interno di una virtual network di Azure. Per fare ciò è necessario attivare una funzionalità in preview, che come tale ha alcune limitazioni, tra le quali non supporta scenari di Virtual Network tra di loro in peering. In questo scenario, qualora sia richiesta la pubblicazione del servizio SFTP verso internet, questa dovrà necessariamente avvenire tramite Azure Firewall, in quanto non è supportata l’assegnazione diretta di IP Pubblici agli Azure Container configurati in Virtual Network. Al fine di migliorare le security posture del vostro ambiente Azure è inoltre consigliabile:

  • Adottare un approccio legato alla micro-segmentazione e alla definizione di perimetri granulari nell’architettura di rete in Azure. Per fare ciò, oltre all’adozione di Azure Firewall, è necessario prevedere l’utilizzo dei Network Security Groups (NSGs), lo strumento utilizzato per segregare il traffico di rete internamente alla Virtual Network di Azure. Tramite delle regole di deny e permit è possibile filtrate le comunicazioni tra le differenti subnet dove sono attestati i differenti workload applicativi.
  • Prevedere l’utilizzo dei Virtual Network (VNet) service endpoints per aumentare il livello di sicurezza dello Storage Account, 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 rendere completa questa soluzione è necessario prevedere anche una strategia di protezione dei dati che vengono posizionati sullo storage account tramite il servizio SFTP. Il backup dei contenuti trasferiti tramite servizio SFTP su Azure file shares potrà avvenire utilizzando Azure Backup. Anche in questo caso si tratta al momento di una funzionalità in preview, quindi si potrà avere una protezione con una frequenza giornaliera.

Ad oggi, in alternativa a questa soluzione è possibile adottare soluzioni di terze parti disponibili nel marketplace di Azure per erogare il servizio SFTP. Si tratta di soluzioni nettamente più costose che tipicamente richiedono un effort maggiore per il deployment e per la relativa gestione.

Conclusioni

In attesa che Microsoft rilasci un servizio SFTP totalmente gestito in Azure, questa soluzione proposta consente di erogare in modo semplice e veloce questo servizio, con costi ridotti e senza dover mantenere e gestire delle macchine virtuali. L’adozione di questa soluzione necessità l’integrazione con altri servizi della piattaforma Azure per realizzarla in modo efficace, senza tralasciare l’aspetto sicurezza. Al momento potrebbe essere necessario utilizzare servizi in preview, quindi non ufficialmente supportati in ambiente di produzione.

Please follow and like us:

[VIDEO] – Architecting and Implementing Azure Networking

Per implementare cloud ibridi in modo sicuro e allo stesso tempo funzionale è fondamentale una conoscenza approfondita dei vari aspetti legati al networking di Azure. Recentemente ho avuto il piacere di partecipare alla Cloud Conferenze Italia dove ho tenuto una sessione relativa al Networking di Azure. A questo proposito riporto il video della sessione dove vengono esplorati a 360° gli elementi chiave da tenere in considerazione per realizzare architetture di rete ibride, sfruttando al meglio i vari servizi offerti dalla piattaforma Azure, al fine di realizzare la miglior integrazione con l’ambiente on-premises, senza mai trascurare la sicurezza. Durante l’intervento sono stati approfonditi scenari avanzati di architetture di rete ibride, mostrando esempi reali, frutto di un’esperienza diretta sul campo.

Please follow and like us:

Azure Networking: gestione di micro-perimetri con Azure Firewall Manager

Nel cloud pubblico di Microsoft è stato introdotto il nuovo servizio di management Azure Firewall Manager che consente di gestire in modo centralizzato le policy di security e le regole di routing. Grazie a questa soluzione è possibile governare al meglio i perimetri di sicurezza dei propri ambienti cloud ottenendo una protezione ottimale del proprio ecosistema aziendale. In questo articolo vengono riportate le caratteristiche principali del nuovo servizio evidenziando i vantaggi che si possono ottenere grazie al suo utilizzo.

Il modello di sicurezza, definito Zero trust dagli analisti di Forrester Research, e in contrasto con i modelli convenzionali basati sulla sicurezza perimetrale, 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 Microsoft ha rilasciato questo 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.

Azure Firewall Manager al momento si integra con Azure Virtual WAN, il servizio che consente di implementare architetture di rete gestite secondo il modello hub and spoke. Azure Firewall ora può essere attivato nelle reti di Hub di Virtual WAN e nel momento in cui policy di security e di routing vengono associate da Azure Firewall Manager ad una rete di Hub questa viene definita come Secured Virtual Hub.

Figura 1 – Panoramica di Azure Firewall Manager

Adottando Azure Firewall Manager è possibile ottenere i seguenti benefici:

  • Configurazioni e deployment centralizzati: il deployment e la configurazione di più istanze di Azure Firewall, in reti di Hub di Virtual WAN, può essere fatta in modo centralizzato. Queste istanze di Azure Firewall possono risiedere in differenti region di Azure e su diverse subscription. Inoltre, è possibile organizzare una gerarchia di policy di Azure Firewall ottimizzate per DevOps, dove le Global firewall policy vengono gestite dall’IT centrale e le firewall policy locali vengono delegate ai DevOps per favorire una migliore agilità nei processi.
  • Routing automatizzato: viene fornita la possibilità di ridirigere facilmente e in modo centralizzato il traffico dalle reti di spoke verso il Secure Virtual Hub, il tutto senza dover manipolare le User Defined Routes delle reti di spoke.
  • Integrazione con partner Security as a Service (SECaaS) di terze parti: per arricchire ulteriormente le funzionalità di sicurezza è prevista l’integrazione con SECaaS partners, attualmente Zscaler e iBoss, ma presto sarà possibile anche con CheckPoint.

Figura 2 – Central security e route policy management

Nel dettaglio gli step per adottare la soluzione sono i seguenti:

  1. Creazione dell’architettura di rete hub and spoke, utilizzando il servizio Azure Virtual WAN e attivazione di una istanza Azure Firewall nella rete di Hub. Per fare ciò è possibile procedere tramite due distinte modalità:
    1. Creazione di una nuova Secured Virtual Hub tramite Azure Firewall Manager e aggiunta delle virtual network connections;
    2. Trasformazione di un Virtual WAN Hub esistente, attivando sulla rete di Hub il servizio Azure Firewall.

Figura 3 – Avvio del processo tramite Azure Firewall Manager

  1. Selezione dei security provider (opzionale). Questo può essere fatto sia durante il processo di creazione di un Secure Virtual Hub oppure durante la conversione di un Virtual WAN Hub in un Secure Virtual Hub.

Figura 4 – Scelta del Trusted Security Partner

  1. Creazione di una firewall policy e associazione con la rete di Hub. Questo è possibile solo per le Azure Firewall Policy, mentre per le policy delle soluzioni di Security as a Service (SECaaS) fornite dai partner, è necessario utilizzare i loro strumenti di gestione.
  1. Configurazione delle impostazioni di routing sul secured hub per attrarre il traffico delle reti di spoke e renderlo filtrato secondo le policy definite.

Al momento Azure Firewall Manager è supportato solamente per la gestione di architetture Hub and Spoke create tramite il servizio Azure Virtual WAN. Il supporto per poter gestire anche le istanze di Azure Firewall attivate nelle Virtual Network è atteso per la prima metà del prossimo anno.

Conclusioni

Azure Firewall Manager è uno strumento che risulta molto utile per gestire ambienti complessi composti da differenti architetture di rete che adottano il modello Hub and Spoke tramite Azure Virtual WAN. Questo servizio di management aggiuntivo nonostante sia agli albori, e destinato ad arricchirsi presto con nuove funzionalità, risulta di fondamentale importanza per gestire in modo più semplice ed efficace la propria architettura di rete di Azure. Al momento il servizio è in Public Preview, quindi non sono garantiti SLA (Service-Level Agreement) e non dovrebbe essere utilizzato in ambienti di produzione.

Please follow and like us:

Azure Monitor: le novità riguardanti il monitor del networking di Azure

Azure Monitor è una soluzione cloud-based in grado di collezionare dati di telemetria di diversa natura, analizzarli ed intraprendere determinate azioni. Tra le varie funzionalità offre la possibilità di controllare lo stato di salute del networking, la connettività verso le proprie applicazioni ed è in grado di fornire informazioni dettagliate sulle performance di rete. Il tutto non solo per ambienti cloud, ma anche in presenza di architetture ibride. In questo articolo vengono riportate le importanti novità che sono state recentemente annunciate da Microsoft per rendere ancora più completa la soluzione.

Prima di approfondire le nuove funzionalità che sono state introdotte è bene specificare che Azure Monitor include differenti soluzioni specifiche per monitorare il networking di Azure, tra le quali Network Performance Monitor (NPM), la suite che comprende le seguenti funzionalità:

Oltre agli strumenti inclusi in Network Performance Monitor (NPM) è possibile utilizzare Traffic Analytics, che consente di avere una visibilità complessiva sulle attività di rete che vengono intraprese nell’ambiente cloud. Il funzionamento di questa soluzione si basa sul principio che in Azure, per poter consentire o negare la comunicazione di rete verso le risorse connesse alle Azure Virtual Networks (vNet), vengono utilizzati i Network Security Group (NSG), che contengono una lista di regole di accesso. I NSG vengono applicati alle interfacce di rete connesse alle macchine virtuali oppure direttamente alle subnet (scelta consigliata). La platform utilizza i NSG flow logs per mantenere la visibilità del traffico di rete in ingresso e in uscita dai Network Security Group. Traffic Analytics si basa sull’analisi dei NSG flow logs e dopo una opportuna aggregazione dei dati, inserendo l’intelligence necessaria relativamente a security, topologia e mappa geografica, è in grado di fornire informazioni dettagliate sul traffico di rete del proprio ambiente cloud Azure. La novità che interessa Traffic Analytics è data dal fatto che ora è possibile processare questi dati con una frequenza maggiore, ad intervalli temporali ogni 10 minuti, contro i 60 minuti possibili in precedenza.

Figura 1 – Frequenza di elaborazione di Traffic Analytics

Azure Monitor for Networks

Per avere una maggiore visibilità nelle attività di rete svolte nel cloud Microsoft ha rilasciato Azure Monitor for Networks che introduce un’utile visuale sullo stato di salute di tutte le risorse di rete presenti nel proprio ambiente, arricchita dalle relative metriche. Il tutto è disponibile senza la necessità di dover fare alcuna configurazione specifica.

Figura 2 – Overview di Azure Monitor for Networks

Nel riquadro superiore è possibile impostare dei parametri di ricerca per identificare rapidamente le risorse di interesse, mentre sulla destra è presente un pannello che mostra eventuali alert suddivisi per criticità.

Selezionando i singoli componenti si ottengono maggiori informazioni di dettaglio.

Figura 3 – Dettagli sullo stato delle connessioni VPN

In particolare, al momento solamente per gli Application Gateway, viene messa a disposizione una vista molto utile delle Dependency, che aiuta a individuare con precisione la configurazione dei componenti e a rintracciare con maggiore rapidità eventuali condizioni di errore. Tale rappresentazione riporta le relazioni tra i front-end IPs, i listeners, le rules e i backend pool degli Application Gateway. I colori facilitano l’individuazione di stati di health problematici sulle risorse.

La vista riporta inoltre i dettagli delle metriche principali riguardanti gli Application Gateway.

Figura 4 – Elenco degli Application Gateway

Figura 5 – Dependency view di un Application Gateway specifico

Il grafico consente inoltre di accedere facilmente alle configurazioni dei diversi componenti. Per individuare i problemi di connettività e avviare le operazioni di troubleshooting è infatti presente la possibilità, facendo tasto destro sulla singola macchina virtuale, di accedere direttamente a VM Insight e al Connection troubleshoot.

Figura 6 – Accesso alle risorse per fare il troubleshooting della macchina

Conclusioni

La nuova soluzione Network Insights presente in Azure Monitor permette di avere una visione complessiva delle proprie risorse di rete in modo semplice e intuitivo. La soluzione risulta particolarmente utile in presenza di ambienti complessi e la console di Dependency view è un valido supporto anche per documentare le implementazioni degli Application Gateway. Si tratta al momento di una funzionalità in preview e come tale sarà sicuramente arricchita nel breve periodo con ulteriori novità, consentendo così di avere un monitor sempre più completo e intuitivo della propria architettura di rete in Azure.

Please follow and like us:

Azure Networking: il nuovo metodo per accedere in modo privato ai servizi in Azure

L’esigenza di poter accedere a dati e servizi in Azure in modo totalmente privato e sicuro, in particolare dal proprio ambiente on-premises, è sicuramente molto sentita e sempre più diffusa. Per questa ragione Microsoft ha annunciato la disponibilità di Azure Private Link, che permette di semplificare l’architettura di rete instaurando una connessione privata verso i servizi in Azure, senza alcuna necessità di esposizione verso internet. In questo articolo vengono riportate le caratteristiche di questa tipologia di connettività e come è possibile attivarla.

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

Figura 1 – Panoramica di Azure Private Link

Il concetto che sta alla base di Azure Private Link è già in parte noto nell’ambito del networking di Azure e richiama i Virtual Network Service Endpoints. Prima dell’introduzione di Azure Private Link l’unico modo disponibile per aumentare il livello di sicurezza nell’accesso ai servizi Azure, come ad esempio Azure Storage e Azure SQL Database, era dato dai VNet Service Endpoints. La differenza però è sostanziale, in quanto utilizzando i VNet Service Endpoints il traffico rimane nella rete di backbone di Microsoft, consentendo l’accesso alle risorse PaaS solamente dalla propria VNet, ma l’endpoint PaaS viene comunque acceduto tramite l’IP pubblico del servizio. Ne consegue che il principio di funzionamento dei vNet Service Endpoints non si estende al mondo on-premises anche in presenza di connettività con Azure (VPN oppure ExpressRoute). Infatti, per consentire l’accesso da sistemi presenti on-premises è necessario continuare ad utilizzare le regole firewall del servizio per limitare la connettività solamente agli IP pubblici di propria appartenenza.

Grazie ad Azure Private Link è possibile invece accedere alle risorse PaaS tramite un indirizzo IP privato della propria VNet, il quale è potenzialmente accessibile anche da:

  • Sistemi on-premises tramite Azure ExpressRoute private peering eo Azure VPN gateway.
  • Sistemi attestati su VNet in peering.

Tutto il traffico risiede all’interno della rete Microsoft e non è necessario configurare l’accesso tramite gli IP Pubblici del servizio PaaS.

Figura 2 – Accesso da on-premises e peered networks

Azure Private Link semplifica notevolmente il modo in cui è possibile accedere ai servizi Azure (Azure PaaS, Microsoft partner e servizi privati) in quanto sono supportate configurazioni cross Azure Active Directory (Azure AD) tenants.

Figura 3 – Private Link cross Azure Active Directory (Azure AD) tenants

L’attivazione di Azure Private Link è semplice e richiede un numero limitato di configurazioni lato networking di Azure. La connettività avviene basandosi su un flusso di approvazione di chiamate e quando una risorsa PaaS viene mappata su un endpoint privato, non è richiesta la configurazione di route table e di Network Security Groups (NSG).

Dal Private link center è possibile creare nuovi servizi e gestire la configurazione oppure configurare servizi esistenti per usufruire dei Private Link.

Figura 4 – Avvio della configurazione da Private link center

Figura 5 – Creazione di un Azure Storage Account da rendere accessibile in modo privato

Figura 6 – Parametri classici per la creazione di uno storage account

Figura 7 – Configurazione del Private endpoint

Figura 8 – Private endpoint connection presente nello storage account creato

Giunti a questo punto lo storage account sarà accessibile in modo totalmente privato. Per testarne l’accesso è stata creata una macchina virtuale e verificata la connettività tramite “Connection troubleshoot”:

Figura 9 – Test eseguito da “Connection troubleshoot” che dimostra la connettività privata

Per collegare tra di loro più Azure Virtual Network vengono tipicamente utilizzati i VNet peering, i quali richiedono che negli address space delle VNet non ci siano delle sovrapposizioni. Qualora si verifichi questa condizione è possibile adottare gli Azure Private Link come metodo alternativo per connettere in modo privato applicazioni che risiedono in differenti VNet con una sovrapposizione degli address space.

Figura 10 – Azure Private Link in presenza di overlapping address space

Le caratteristiche di Azure Private Link consentono di avere un accesso specifico solamente alle risorse mappate in modo esplicito. Nell’eventualità di un incident di security all’interno della propria VNet, questo meccanismo elimina la minaccia di estrazione di dati da altre risorse utilizzando lo stesso endpoint.

Figura 11 – Accesso mirato solo alle risorse mappate in modo esplicito

Gli Azure Private Link aprono inoltre nuovi scenari di esposizione dei servizi erogati in Azure da parte dei service provider. Per consentire l’accesso ai servizi erogati ai propri clienti tipicamente si procedeva secondo una di queste modalità:

  • Si rendevano accessibili direttamente tramite IP Pubblici.
  • Per renderli privati, si creavano dei VNet peering, ma con problemi di scalabilità e di potenziali conflitti IP.

Figura 12 – Come Azure Private Link cambia gli scenari “Service Consumer”-“Service Provider”.

La nuova possibilità che viene offerta in questi scenari, che richiedono un accesso totalmente privato al servizio erogato, è la seguente:

  • Service Provider: configura un Azure Standard Load Balancer, crea un Azure Private Link e consente l’accesso dal Service Consumer proveniente da una differente VNet, subscription, o tenant Azure Active Directory (AD).
  • Service consumer: creare un Private Endpoint nella VNet specifica e richiedere l’accesso al servizio.

Figura 13 – Azure Private Link workflow in scenari “Service Consumer”-“Service Provider”

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

Conclusioni

Questo nuovo metodo consente di consumare privatamente soluzioni erogate in Azure all’interno della propria infrastruttura di rete. Si tratta di un importante cambiamento che sicuramente è opportuno tenere in considerazioni quando si progettano le architetture di rete in Azure, in particolare per gli scenari ibridi. Al momento il servizio è in preview, quindi non ancora utilizzabile per ambienti di produzione e disponibile per un set limitato di servizi Azure. Nei prossimi mesi però Microsoft ha annunciato che renderà disponibile questa funzionalità anche per altri servizi di Azure e dei partner, consentendo così di avere una esperienza di connettività privata, elemento chiave per avere una maggiore adozione e diffusione di questi servizi.

Please follow and like us: