Creare un’infrastruttura di rete sicura (non) è un gioco da ragazzi!
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. Questo articolo non entrerà nel dettaglio di ogni risorsa (ci vorrebbero ben più di pochi minuti per la sua lettura), quanto desidera dare una visione di insieme sull’approccio alla risoluzione delle varie problematiche su questi temi.
Presentazione dello scenario: Hub & Spoke
Scegliamo di concentrarci sul modello hub & spoke perchè è uno dei più utilizzati per la segmentazione delle reti su Azure, ed inoltre, i concetti chiave che andiamo ad esplorare sono poi applicabili anche ad altre tipologie.
In particolare ci aspettiamo che:
- Hub: gestisce la connettività e la sicurezza centralizzata.
- Spoke: ospita i workload e le risorse applicative.
Nel nostro schema però abbiamo identificato 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
A completare lo schema, riportiamo qualche esempio di workload misti (di tipo IaaS e PaaS) che ospiteranno le nostre applicazioni e che dobbiamo connettere col resto degli “elementi”
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
Partiamo dalle fondamenta: come mi oriento tra le diverse possibilità? In realtà, non ci sono più scuse perchè Microsoft ha ridisegnato i propri hub ed ora offre quattro aree chiave per la gestione della rete in maniera sicura, andando a fornire percorsi di formazione, alberi decisionali e completo controllo:
Qua di seguito i link agli hub:
Accesso “Esterno” ed “Interno”
Nel nostro processo decisionale, vorrei sottolineare l’importanza del partire dalla definizione delle diverse personas che operano intorno ad un’architettura di rete suddividendole in:
- Esterni: fornitori, partner, utenti finali (non guest)
- Interni: 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à? Come descritto nell’Hub sull’Hybrid Connectivity abbiamo un ampio ventaglio di possibilità:
- 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?
1) La sottorete su azure da cui viene assegnato un indirizzo IP privato ad ogni client che si connette in VPN P2S (nel disegno vpn clients subnet su azure) è 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 attraverso lo switch “assignment required” e la sezione “Users and Roles” (vedi figura):
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)
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?
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
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:
Attenzione:: NSG e UDR vengono bypassati per i Private Endpoints, quindi è fondamentale pianificare la gestione delle rotte e delle policy di sicurezza.
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)
Arrivati a questo punto, abbiamo consentito un accesso segmentato alla nostra architettura per le diverse personas; abbiamo protetto i nostri workload (sia PaaS che IaaS) a livello applicativo. Non rimane che verificare (secondo il principio dello zero trust) ogni transito east-ovest tra le reti. Anche in questo scenario, abbiamo un Hub che ci può fare da bussola tra le varie opportunità ed identifichiamo alcuni strumenti principali:
- Azure Firewall
- DDoS Protection
- Network Security Groups (NSG)
- Service Endpoint Policy
Nel nostro scenario andremo ad introdurre un firewal e tutte le Route Table ed i Network Security Group necessari per assicurare che il transito dei dati di rete attraversi il firewall su cui avremo attivato IDS ed IPS.
Ma anche in questo scenario dobbiamo porre attenzione ad alcuni limiti della piattaforma e a come posizionare i nostri endpoint per una governance più semplice.
Nella figura seguente, infatti, ci sono alcuni elementi di “disturbo”:
- Lo scale set: quando usiamo l’application Gateway per bilanciare uno scale set con “Orchestration Mode” flexible abbiamo il limite di doverlo porre nella stessa virtual network del bilanciatore
- le private DNS zones: quando decidiamo di creare i link con le vnet dobbiamo ricordarci che solo una Private DNS zone può essere autorevole per una vnet su un certo dominio
In sostanza l’utilizzo di un’unica sottorete per i private endpoints, laddove possibile, favorisce la configurazione delle Route Tables ed evita la necessità di andare ad intercettare la rotta di ogni singolo private endpoint (ricordiamoci che i private endpoints creano una rotta /32 che può essere “sovrascritta” solo da un’altra rotta /32).
Anche la presenza di un workload nella rete di “Hub” costringe le Route Table ad essere molto specifiche perchè il traffico “intra-subnet” è semple complesso da instradare rispetto al traffico intra-vnet.
Rimane infatti un grosso interrogativo: devo ispezionare anche il traffico che non transita tra una rete e l’altra, ma che viaggia tra una subnet e l’altra?. Provo a rispondere con una domanda: Perchè abbiamo messo due workload in due subnet della stessa rete virtuale? Per far si che comunicassero in maniera diretta.. Quindi, ha senso ispezionare il traffico tra due workload che devono comunicare tra di loro, introducendo latenza, tempi di processing e costi (firewall che scala, peering). Ognuno di voi potrà decidere in maniera autonoma e soprattutto caso per caso. Per il principio dello zero trust, dovremo verificare tutto, ma forse verificare i flussi nord-sud ed east-ovest è sufficiente .. (?)
Infine, ricordiamo di far transitare il traffico in outbound sul firewall, così da prevenire exfiltration e/o connettività verso url non previsti, favorendo le subnet “private by default” e quindi senza connettività pubblica implicita.
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?
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.
CHIUSA
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
Scrivi un commento