Il potere della Minimum Viable Network

Comprendere il networking nel cloud è uno degli adattamenti più impegnativi per le organizzazioni che iniziano il proprio percorso verso il cloud. Osservando lo schema di indirizzamento e i componenti, sembra in qualche modo una rete IP. E, dalla maggior parte dei punti di vista, lo è — ma in molti altri ambiti non lo è. Una rete software-defined (SDN) – come quelle offerte nel cloud – non è soggetta agli stessi vincoli di una rete fisica, e questo può generare parecchia confusione nella fase iniziale.

Anziché cercare di capire in che cosa una SDN si differenzi dalla rete fisica, concentriamoci su ciò che la rete deve fare e, soprattutto, su ciò che non deve essere consentito. Forse ricorderà un concetto chiamato “default deny”, secondo il quale, a meno che una connessione non fosse esplicitamente autorizzata, veniva bloccata per impostazione predefinita. Poi è arrivato il web e non è più stato possibile limitare la porta 80 o la 443, dato che praticamente tutte le applicazioni utilizzavano quelle porte. Inoltre, il “default deny” non è mai andato davvero oltre il perimetro e le nostre reti interne tendevano a essere piatte e aperte, affidandosi a una DMZ per filtrare il traffico dannoso proveniente dall’esterno. Come hanno dimostrato violazioni su violazioni, questo modello è solo moderatamente efficace.

La SDN, però, ci consente di avvicinarci molto di più al default-deny, attraverso un concetto che chiamiamo “Minimum Viable Network”, che permette di costruire reti personalizzate con i soli elementi necessari a svolgere il lavoro, e nulla di più.

Una Minimum Viable Network dovrebbe determinare l’architettura applicativa e poi creare SOLO il networking necessario a supportare tale applicazione, applicando routing e security group a privilegio minimo e utilizzando anche componenti PaaS come i load balancer cloud. In questo modo la rete a commutazione di pacchetto diventa di fatto una rete a commutazione di circuito, in quanto i componenti applicativi possono comunicare SOLO con gli altri componenti autorizzati e nulla può intercettare il traffico intermedio (tranne, in alcuni casi, il provider cloud). La rete scarta tutto il resto del traffico. Ciò elimina la necessità di costrutti come la tradizionale DMZ o le zone di rete, poiché l’intera rete è di per sé a privilegio minimo e default deny.

Rendiamo il concetto più concreto con un esempio. È possibile creare uno stack applicativo tradizionale a 3 livelli con un Application Load Balancer esposto pubblicamente, supportato da un web server in una subnet privata che accetta SOLO traffico proveniente dal load balancer. I web server possono connettersi unicamente agli application server che accettano connessioni da essi. Analogamente, gli application server possono inviare traffico soltanto ai database che consentono tali connessioni. Ogni livello è in default deny e consente solo connessioni in ingresso dai load balancer e connessioni in uscita verso i database. In molti casi è possibile implementare tutto questo senza alcuna connettività Internet (in subnet private), a eccezione dei load balancer pubblici, che sono costrutti PaaS altamente sicuri gestiti dal provider cloud.

Invece di costruire la rete e collocarvi all’interno le applicazioni, si progettano le applicazioni e poi si adatta la rete alle esigenze dell’applicazione. Questo riduce drasticamente la superficie di attacco dello stack applicativo e, di conseguenza, il rischio.

Abbiamo applicato questi principi nella realizzazione del sito securosis.com, come si può vedere nel diagramma architetturale qui sotto. Se analizziamo quel progetto con l’occhio della sicurezza di rete, notiamo che:

• L’accesso è limitato dal WAF cloud, così solo il traffico pulito raggiunge la VPC.
• Gli application load balancer (ALB) sono le uniche risorse nelle subnet esposte pubblicamente e consentono solo traffico 80/443.
• Tutte le istanze si trovano in subnet private e accettano traffico solo dagli ALB.
• L’istanza “admin” accetta login, ma solo da una VPN ospitata in un ambiente diverso.
• Non sono rappresentate le subnet del database RDS, anch’esse esclusivamente private e che accettano traffico solo dalle istanze. Se sono necessari login diretti o accessi RDBMS per la manipolazione dei dati, le regole dei security group vengono modificate per consentire un accesso temporaneo.
• Le connessioni a S3 avvengono tramite un service endpoint, eliminando la necessità di un NAT Gateway per l’accesso a Internet.
• SSH è disabilitato sulle istanze non admin. Queste sono soggette ad autoscaling, sono immutabili e vengono modificate solo cambiando l’immagine di base.
• Non esistono security group auto-referenziali (security group che consentono l’accesso interno), così da prevenire attacchi orizzontali. In AWS i security group operano a livello di risorsa, non di subnet, il che è molto efficace per bloccare gli attacchi East/West.
• Questa architettura riduce drasticamente la superficie di attacco complessiva. La rete consente solo la connettività minima necessaria e contiene soltanto le subnet e le tabelle di routing minime indispensabili a consentire l’accesso. Abbiamo sostanzialmente adattato la rete all’applicazione. Di fatto, la rete è stata progettata solo dopo aver definito l’architettura dello stack applicativo.
• Questo è un esempio molto semplice, relativo a un piccolo sito, ma i principi possono essere applicati ad architetture molto più ampie, con un numero maggiore di livelli, load balancer interni, API Gateway e componenti PaaS.

Come si può notare, i costrutti di networking cloud offrono una flessibilità straordinaria. Finalmente è possibile costruire la rete di cui l’applicazione ha bisogno, anziché adattare l’applicazione alla rete esistente. Con questa flessibilità, però, arriva anche la possibilità di configurare le cose in modo errato ed esporre ampie porzioni della propria infrastruttura alla rete Internet pubblica. Per questo consigliamo sempre di monitorare la propria postura di sicurezza cloud e di applicare le best practice con una piattaforma di cloud security operations (come quella offerta da DisruptOps).