A novembre 2020 AWS ha annunciato l'"AWS Network Firewall". Con il proliferare dei firewall è facile perdere l'orientamento: questo articolo nasce proprio per fare chiarezza.
Iniziamo con un confronto tra i firewall di AWS e altri sistemi di difesa di rete analoghi, illustrando i casi d'uso di ciascuno, gli attacchi da cui proteggono e le regole che utilizzano per rilevare le minacce.
Proseguiremo poi con un racconto che illustra gli scenari in cui potrebbe imbattersi man mano che la sua applicazione cresce e ne aumenta la rilevanza economica.
Quando usare ciascun servizio firewall di AWS
Partiamo dal basso, dall'infrastruttura di livello più basso, per poi salire: in linea generale, è così che dovrebbe costruire anche le sue difese.
Security Groups
I Security Groups proteggono le Elastic Network Interface, generalmente associate a istanze EC2, ma anche ad altri servizi come RDS o Lambda all'interno di una VPC. Possono proteggere, ad esempio, da connessioni SSH non autorizzate. Bloccano l'accesso in base a porte di origine e destinazione e a intervalli di indirizzi IP. Conviene definire i Security Groups, concedendo solo l'accesso strettamente necessario, ogni volta che crea nuove istanze.
Network ACLs
Le Network ACL proteggono le subnet, ad esempio impedendo connessioni non autorizzate verso un database da parte del server di backend. Come i Security Groups, bloccano l'accesso in base a porte di origine e destinazione e a intervalli di IP. Conviene definire le NACL quando suddivide i suoi sistemi in subnet per funzione, operazione che andrebbe fatta nel momento in cui definisce i tier. Con le NACL, i sottosistemi possono accedere agli altri in base al ruolo che ricoprono nell'architettura, a condizione che le subnet siano state definite di conseguenza.
Kubernetes Network Policies
Le Kubernetes Network Policies proteggono le applicazioni in Elastic Kubernetes Service. Come i Security Groups e le NACL, bloccano l'accesso in base a porte di origine e destinazione e a intervalli di IP. In più, possono sfruttare le label di Kubernetes, abilitando un controllo degli accessi funzionale a grana molto fine. Conviene definire queste Network Policies ogni volta che crea un set di servizi Kubernetes, salvo nei casi più semplici.
Network Firewalls
I Network Firewall proteggono tutte le reti di un'organizzazione, ad esempio dai bot Trojan che esfiltrano dati. Bloccano l'accesso sulla base di ruleset standard scaricabili. Come avviene per Security Groups e NACL, questi ruleset includono firme definite da porte di origine e destinazione e da intervalli di IP. In più, possono ricorrere alla deep packet inspection e bloccare quindi il traffico in base a domini, URL e protocolli (a patto che il TLS venga terminato prima del Network Firewall). Conviene aggiungere i Network Firewall quando servono policy coerenti di Intrusion Detection and Protection a livello di organizzazione.
AWS Shield Standard
AWS Shield Standard protegge web app e API dagli attacchi DDOS. Blocca l'accesso analizzando i pattern del traffico HTTP(S), inclusi la frequenza e l'origine delle invocazioni. Conviene attivare AWS Shield Standard su qualsiasi web app pubblica con valore per il business. (È gratuito ed è abilitato di default su alcune risorse.)
AWS Shield Advanced
AWS Shield Advanced offre le stesse funzionalità della versione Standard, ma con monitoraggio più approfondito, rimborso dei costi sostenuti durante gli attacchi e, soprattutto, un team operativo umano altamente qualificato. Vale la pena valutare AWS Shield Advanced per qualsiasi web app business-critical, soppesandone il costo rispetto alla versione Standard.
Web Application Firewall
Il Web Application Firewall (WAF) protegge le web app da Cross-Site Scripting, SQL Injection, Insecure Direct Object References e altre vulnerabilità presenti nella lista OWASP. Rileva e blocca l'accesso in base alle firme definite dai pattern presenti negli header o nel body di una richiesta HTTP(s). Vale la pena valutare il WAF come protezione mentre corregge vulnerabilità note dell'applicazione, oppure se utilizza applicazioni vulnerabili il cui codice non è sotto il suo controllo, o ancora se ritiene che il suo codice abbia vulnerabilità minime ma desidera una protezione aggiuntiva, per maggiore sicurezza.
Istanze con Security Groups, subnet con NACL, organizzazione multi-rete con Network Firewall. AWS Shield contro i DDOS e WAF a protezione dei punti di ingresso
Una storia di firewall
Per mostrare come si adottano i diversi firewall man mano che l'applicazione cresce, ecco un racconto fatto di casi d'uso.
Pat ha appena iniziato a sviluppare un'applicazione web per la sua startup. È un po' all'antica e decide di utilizzare una singola istanza EC2 per un semplice proof of concept. Configura un security group come firewall a livello di istanza, consentendo l'accesso solo sulle porte 80 e 443, in modo che le richieste HTTP/S possano raggiungerla, e sulla porta 22 per l'intervallo IP del suo ufficio, così da poterla amministrare via SSH. A questo punto ha protetto l'istanza dagli accessi su porte diverse dalla 80 o dalla 443 e ha bloccato qualsiasi accesso SSH da indirizzi IP non autorizzati.
Il suo proof of concept è già al sicuro, in questa fase iniziale, da molti tipi di attacchi, ma man mano che aggiungerà complessità alla rete e all'applicazione, e con l'aumentare della sua rilevanza economica, avrà bisogno di ulteriori difese.
Per andare oltre quel semplice proof of concept e arrivare a una solida applicazione n-tier, configura un database e separa i server di front-end e di back-end. Ogni tier ottiene una subnet dedicata. Configura le Network Access Control List (NACL) come firewall di ingresso a livello di subnet, consentendo alle richieste HTTP/S di accedere alla subnet di frontend, al frontend di accedere al backend, al backend di accedere al database e nient'altro.
La scalabilità ha i suoi limiti e, anche se l'applicazione continua a reggere sotto carico, un attacco DDOS farebbe lievitare i costi. Introduce quindi AWS Shield Standard, che è gratuito. Una protezione DDOS adeguata. Molto più avanti, quando l'applicazione sarà cresciuta enormemente e sarà diventata una fonte di ricavo importante, il costo di AWS Shield Advanced potrebbe valerne la pena. La versione Advanced offre, soprattutto, un team operativo qualificato di AWS — un promemoria, valido per la sicurezza in generale: la minaccia è rappresentata da persone in gamba che trovano nuovi modi per attaccarla, e quindi servono persone in gamba che trovino il modo giusto per difenderla in ogni momento.
Pat porta l'applicazione su Elastic Kubernetes Service per facilitarne l'orchestrazione e la gestione. Qui le Kubernetes Network Policy definiscono le restrizioni sui servizi Kubernetes che possono dialogare con altri servizi, abilitando un controllo degli accessi funzionale più granulare rispetto a quanto possibile con le subnet.
I penetration test dell'applicazione fanno emergere una serie di vulnerabilità presenti nella lista OWASP, tra cui Insecure Direct Object References, Cross Site Scripting e SQL Injection. Pat e il team di sviluppo aggiungono quindi AWS Web Application Firewall, dando al contempo priorità alle correzioni necessarie e a un impegno strutturale sulla sicurezza all'interno del team di sviluppo.
Infine arriva il grande giorno: Exit! La startup viene acquisita da una grande azienda. L'applicazione entra a far parte di un portfolio di applicazioni più ampio e la rete diventa parte di un'infrastruttura complessa, con più VPC e reti on-premises gestite da diverse unità organizzative. Per tenere tutto al sicuro, l'azienda ha definito policy di rete coerenti a livello di organizzazione. Viene aggiunto AWS Network Firewall per limitare gli accessi tramite ruleset di difesa standard definiti da porte, indirizzi IP, domini, URL e protocolli. In questo modo non ci si protegge solo dagli stessi attacchi coperti da Security Groups e Network ACL, ma si rilevano e si prevengono anche intrusioni da parte di bot Trojan o di hacker umani che eseguono codice in rete e corrompono o esfiltrano dati.
Le grandi organizzazioni richiedono un approccio centralizzato alla gestione di risorse e policy: un sistema è forte quanto il suo anello più debole. Viene introdotto AWS Firewall Manager per orchestrare Network Firewall, WAF e altri sistemi, garantendo una protezione coerente in tutta l'organizzazione.
Spero che il quadro sui numerosi firewall di AWS sia ora più chiaro. Se ha domande, può scriverle senza problemi nei commenti.
— —
Un ringraziamento al mio collega Dr. Artem Shchodro per i suoi preziosi commenti.