Creare un’infrastruttura di rete sicura (non) è un gioco da ragazzi!

Due uomini (architects) entrano, uno solo esce (cit.)… (quello che fa le scelte giuste).

ancora una volta il nostro architetto è un sopravvissuto dell’era post-apocalittica (post data breach) e si muove tra esseri umani (zombie) alla continua ricerca del loro destino (trovare un CISO) . Il peregrinare per le lande desolate (e immense) di Azure si fa sempre più pericoloso man mano che i loro workload vengono esposti ai selvaggi di internet. Ma abbiamo modo di fornirgli riparo cosìcchè possano dormire sogni (quasi) tranquilli? Vediamo come gettare le fondamenta per una nuova civiltà “sicura”

-incipit-

La sicurezza delle architetture cloud è una delle sfide principali per chi progetta e gestisce infrastrutture su Azure. In questo articolo vedremo come configurare in modo sicuro le risorse di rete di Azure, seguendo best practice e sfruttando le ultime novità della piattaforma.

Presentazione dello scenario: Hub & Spoke

Il nostro scenario è quello classico: architettura Hub & Spoke

Il modello hub & spoke è uno dei più utilizzati per la segmentazione delle reti su Azure.

• Hub: gestisce la connettività e la sicurezza centralizzata.
• Spoke: ospita i workload e le risorse applicative.
• Altri elementi importanti:
  • ogni segmento di rete va preso in considerazione per la sua specificità: Subnet clients, Subnet Servers, Subnet VPN clients
  • Utenti al di fuori della rete aziendale
  • Inbound ed Outbound da e verso internet
  • Altre reti da cloud Privati e/o pubblici

Obiettivo: Capire quali risorse possiamo usare nell’Hub per consentire a tutti gli utenti e tutte le reti di raggiungere i workload nello Spoke in maniera sicura.

Nuovi strumenti per orientarsi nella scelta: I Quattro Hub Fondamentali

Non ci sono scuse per iniziare ad esplorare il ventaglio di opportunità. Azure offre quattro aree chiave per la gestione della rete in maniera sicura, andando a fornire percorsi di formazione, alberi decisionali e completo controllo:

1. Network Foundation
2. Hybrid Connectivity
3. Load Balancing and Content Delivery
4. Network Security

Accesso “Esterno” ed “Interno”

Partiamo dal definire le diverse personas che operano intorno ad un’architettura di rete dividendole in:

• Esterno: fornitori, partner, utenti finali (non guest)
• Interno: utenti aziendali, IT, applicazioni interne

Obiettivo: La divisione è fondamentale perchè le due tipologie di personas hanno diverse esigenze e dovranno avere diversi permessi. Il nostro obiettivo è riconoscere sempre chi accede alla nostra infrastruttura e ricondurlo ad una delle personas “note”.

Possiamo ipotizzare di dare accesso alle personas mediante Bastion (sia in modalità privata che non). Questo in parte risolve il problema dell’accesso amministrativo.

Ma se parliamo invece dell’accesso alle risorse, quali sono le differenti possibilità. Ci diverse soluzioni per la connettività ibrida:

• ExpressRoute: connessione privata e ad alte prestazioni
• Virtual WAN: gestione centralizzata delle connessioni
• VPN Gateway: connessione sicura tramite Internet

Mentre le prime due sono piuttosto comuni in scenari enterprise, l’ultima è di certo la più comune in tutti gli scenari SMB. Il Virtual Network Gateway di tipo VPN è uno strumento semplice per consentire l’accesso sia con Site-to-Site che con Point-to-Site.

Ma che tipo di problematiche comporta l’utilizzo di questo strumento, ad esempio, per una Point-to-Site?

Quali sono i problemi di questa configurazione?

1) La sottorete su azure da cui viene assegnato un indirizzo IP privato ad ogni client che si connette in VPN P2S è unica per tutti. non riusciamo a distinguere le personas e quindi non riusciamo a fornirgli accessi differenti.

2) Il software Azure VPN Client è una Enterprise App che di default è abilitata per tutti. non riusciamo a segmentare gli accessi e stabilire chi può e non può accedere alla rete su azure.

Per questo motivo si consiglia di configurare opportunamente l’Enterprise Application per limitare l’accesso solo agli utenti che devono averlo (vedi figura):

Limitare l’accesso all’Azure VPN Client

Per quanto riguarda la segmentazione della sottorete dei client VPN ci viene in supporto una nuova funzionalità:

Novità: User Groups e IP Address Pool per VPN

Azure introduce la possibilità di assegnare pool di indirizzi IP e gruppi di utenti per le connessioni VPN Point-to-Site (P2S), migliorando la segmentazione e la sicurezza.

About user groups and IP address pools for P2S connections (preview)

Una funzionalità che aspettavamo da tempo già disponibile in V-WAN

Limitazioni:

• Disponibile solo via PowerShell
• Address Pool minimo /24
• Utenti esterni devono essere di tipo “Member”

attenzione: funzionalità in preview

Suggerimenti per la configurazione VPN

• Preferire SKU AZ per maggiore robustezza e resilienza
• Modalità Active-Active (cloud) per rapido failover
• Privilegiare Entra ID Auth rispetto ai certificati
• Definire gli utenti abilitati all’uso dell’Azure VPN Client
• Diversificare le App Registration per “Audience”
• Pianificare user groups e IP address pool per accesso selettivo

Sicurezza Applicativa (Layer 7)

Dopo aver definito l’accesso delle personas è il momento di pensare a come proteggere le nostre applicazioni dai flussi interni ed esterni.

Obiettivo: Non esporre direttamente i nostri workload o i nostri certificate (proxy); applicare delle politiche di Rate Limiting e Geo restriction; evitare attacchi / ridurre la superficie di attacco; evitare DoS ed ispezionare il traffico cifrato (TLS termination) per rilevare attacchi con firme note.

• Application Gateway
• Azure Front Door
• Load Balancer
• Traffic Manager

Nel nostro scenario dunque ipotizziamo di utilizzare l’Application Gateway e L’Azure Front Door (perchè usarli insieme? link)

Questi due oggetti ci consentono di far fronte alla maggior parte delle nostre necessità, ma cosa manca ancora?

Questi due strumenti sono sufficienti in questa configurazione?

1) Le due risorse non hanno un Web Application Firewall a proteggerci dagli attacchi degli attori malevoli e da Bot (che ad oggi costituiscono il 30% del traffico internet).

2) Le nostre risorse sono ancora raggiungibili direttamente, seppur abbiamo aggiunto il proxy/gateway/cdn

Ora la nostra configurazione è più robusta

Inoltre, possiamo utilizzare alcune nuove funzionalità sul Front Door Novità: reCAPTCHA e Javascript Challenge

Azure Front Door introduce nuove funzionalità di sicurezza come reCAPTCHA e Javascript Challenge per proteggere dagli attacchi automatizzati.

attenzione: funzionalità in preview

Suggerimenti per la sicurezza applicativa

• Pianifichiamo il deploy di un WAF per la sicurezza contro attacchi della top 10 OWASP e attiviamo la Bot Protection
• Prevedi fin da subito Geo-Restriction e Throttling
• In caso di workload di tipo web app, prediligi Azure Front Door
• Sfruttiamo reCAPTCHA e Javascript Challenge
• Usare Private Link per stabilire una connessione privata con i backend
• Rimuovere l’accesso pubblico lasciando solo quello da App Gateway/FrontDoor

Approfondimento PaaS

Le risorse PaaS (Azure SQL, App Service, Function Apps, Storage, Key Vault) possono essere integrate con la rete sia in ingresso che in uscita:

• Private Endpoints: connessione privata diretta Inbound
• VNET Integration: integrazione con la rete virtuale in Outbound

Breve descrizione delle funzionalità di rete dei servizi PaaS:

Tramite Private Link Service esponiamo una risorsa tramite un Private Ednpoint. Non ho più necessità di Endpoint Pubblico

La nostra applicazione viene raggiunta in Inbound attraverso il suo Endpoint Pubblico che consente l’accesso dalla rete privata. L’accesso è comunque ristretto.

La nostra applicazione viene raggiunta in Inbound attraverso un IP solo privato. Non ho più necessità di Endpoint Pubblico

Attenzione:: NSG e UDR vengono bypassati per i Private Endpoints, quindi è fondamentale pianificare la gestione delle rotte e delle policy di sicurezza.

I nostri private Endpoints per poter onorare NSG e UDR devono prevedere questi flag sulle subnet dove risiedono

Suggerimenti per le risorse di tipo PaaS

• Verificare se il workload PaaS supporta la connessione inbound/outbound privata
• Raccogliere i Private Endpoints in un’unica subnet per semplificare la gestione delle rotte
• Private Endpoint = Inbound! E l’outbound?

Sicurezza di Rete (Layer 3-4)

Strumenti principali:

• Azure Firewall
• DDoS Protection
• Network Security Groups (NSG)
• Service Endpoint Policy

Suggerimenti:

• Verificare le Network Policy in caso di workload di tipo PaaS ed utilizzo Private Endpoints
• Ricordare le priorità delle tipologie di regole (DNAT, Network, Application)
• Utilizzare le subnet sulle UDR
• Evitare “asymmetric path”
• Spegnere il Firewall fintanto che non sia pronto al deploy
• Stabilire una politica sul traffic “intra-vnet” (ha senso ispezionarlo?)
• Utilizzare Virtual Machine per rilevare le “Effective Routes”
• Privilegiare le “Private Subnet” (no default outbound)

Governo della Soluzione

ora siamo al sicuro?

Ricordiamoci che senza i log i nostri strumenti di sicurezza non possono essere sufficienti. Monitorare.. Monitorare ..Monitorare

Ed infine, per mantenere la sicurezza nel tempo, occorre:

• Applicare policy e audit automatici (Azure Policy)
• Pianificare interventi di allineamento
• Enforcing di best practice (es. subnet private, assenza di IP pubblici)
• Monitoraggio e alerting

Fonti Autorevoli

E’ doveroso citare alcuni tra i massimi esperti sui temi di rete che hanno già pubblicato numerosi articoli sui temi che abbiamo appena “sfiorato” in questo post.

• Cloudtrooper Blog
• Luke Murray Blog
• NicolD Blog
• dmauser GitHub
• Journey of the Geek

CHIUSA

Facciamo in modo che l’architettura.. non ci scappi di mano!

Configurare in modo sicuro le risorse di rete su Azure richiede attenzione, pianificazione e conoscenza delle funzionalità offerte dalla piattaforma. Seguendo le best practice e sfruttando le novità, è possibile costruire architetture resilienti e sicure.

a si biri