Gruppi di Sicurezza vs. ACL di Rete: Scegliere il Firewall AWS VPC
Naviga le complessità della sicurezza AWS VPC padroneggiando le differenze tra Gruppi di Sicurezza (SG) e ACL di Rete (NACL). Questa guida esperta spiega l'ambito, la statefulness e la valutazione delle regole di entrambi i controlli. Scopri perché gli SG sono ideali per una protezione granulare e stateful delle istanze, mentre i NACL sono essenziali per una segmentazione stateless di sottoreti e politiche di rifiuto esplicito. Implementa una strategia firewall robusta e multilivello per la tua infrastruttura cloud.
Gruppi di Sicurezza vs. ACL di Rete: Scegliere il Firewall AWS VPC
Quando si progetta un ambiente Virtual Private Cloud (VPC) sicuro in Amazon Web Services (AWS), gli amministratori si affidano a più livelli di controllo per gestire il traffico di rete. I due componenti fondamentali per filtrare il traffico a livello di rete sono i Gruppi di Sicurezza (SG) e le Liste di Controllo degli Accessi di Rete (NACL).
Sembrano simili nella console, ma falliscono in modi molto diversi. I gruppi di sicurezza sono solitamente il luogo in cui descrivi l'intento dell'applicazione. Le ACL di rete sono il luogo in cui imponi ampi confini di sottorete o rifiuti di emergenza.
Il Ruolo dei Firewall in AWS VPC
AWS fornisce sicurezza di rete a due livelli principali all'interno di un VPC:
- Livello Istanza (Gruppi di Sicurezza): Agisce come un firewall per specifiche istanze EC2 o risorse (come database RDS o Elastic Load Balancer). Controlla il traffico da e verso l'interfaccia di rete.
- Livello Sottorete (ACL di Rete): Agisce come un firewall stateless per intere sottoreti, controllando il flusso di traffico in entrata o in uscita dal confine della sottorete.
Approfondimento sui Gruppi di Sicurezza (SG)
I Gruppi di Sicurezza funzionano come il firewall primario e granulare per le singole risorse. Sono stateful e filtrano per protocollo, porta e origine o destinazione.
Caratteristiche Chiave dei Gruppi di Sicurezza
| Caratteristica | Descrizione | Implicazioni per l'Uso |
|---|---|---|
| Ambito | Si applica direttamente all'Interfaccia di Rete Elastica (ENI) di un'istanza. | Controlla il flusso di traffico verso e dall' istanza stessa. |
| Statefulness | Stateful. Se una richiesta in entrata è esplicitamente consentita, il corrispondente traffico di ritorno (risposta in uscita) è automaticamente consentito, indipendentemente dalle regole in uscita. | Semplifica la configurazione; è necessario definire solo la direzione del traffico iniziatore. |
| Tipo di Regola | Solo Consenti. Le regole di rifiuto esplicito non sono possibili. Il traffico che non corrisponde a una regola ALLOW esplicita è implicitamente negato. |
Si concentra sulla definizione di ciò che è permesso. |
| Valutazione | Tutte le regole vengono valutate prima di prendere una decisione. Non sono numerate e nessun DENY implicito viene elaborato fino a quando tutte le regole ALLOW falliscono. |
L'ordine non ha importanza; tutte le regole sono trattate allo stesso modo. |
Esempio di Configurazione di un Gruppo di Sicurezza
Per consentire l'accesso SSH (porta 22) a un'istanza EC2, è necessaria solo una regola in entrata. La regola in uscita per la risposta SSH è gestita automaticamente dalla natura stateful del SG.
| Tipo | Protocollo | Intervallo Porte | Origine | Descrizione |
|---|---|---|---|---|
| In entrata | TCP | 22 | 0.0.0.0/0 (o IP amministrativo specifico) | Consenti accesso SSH |
| In uscita | Tutti | Tutte | 0.0.0.0/0 | (Predefinito: Consente tutto il traffico, ma può essere limitato se necessario) |
# Rappresentazione concettuale di un flusso stateful
Utente (IP Origine) --> [Regola SG In entrata: ALLOW 22] --> Istanza EC2
Istanza EC2 (Risposta) --> [Tracciamento Stato Implicito] --> Utente (Risposta ricevuta)
Suggerimento per le Buone Pratiche: Definisci sempre le regole del Gruppo di Sicurezza utilizzando il principio del minimo privilegio. Quando possibile, restringi gli intervalli di IP di origine invece di consentire 0.0.0.0/0.
Approfondimento sulle ACL di Rete (NACL)
Le ACL di Rete forniscono un secondo livello di difesa, agendo come un filtro stateless al confine della sottorete. Sono potenti per la segmentazione della rete e le politiche di rifiuto ampie.
Caratteristiche Chiave delle ACL di Rete
| Caratteristica | Descrizione | Implicazioni per l'Uso |
|---|---|---|
| Ambito | Si applica a un'intera sottorete VPC. Una sottorete può essere associata a una sola NACL alla volta. | Controlla tutto il traffico in entrata o in uscita dalla sottorete, influenzando tutte le istanze al suo interno. |
| Statefulness | Stateless. Sia le richieste in entrata che le corrispondenti risposte in uscita devono essere esplicitamente consentite. | Richiede una configurazione attenta per il traffico di ritorno (porte effimere). |
| Tipo di Regola | Consenti e Nega. Puoi definire esplicitamente regole per permettere o bloccare il traffico. | Eccellente per bloccare IP dannosi noti o negare protocolli specifici a livello di rete. |
| Valutazione | Le regole sono numerate (da 1 a 32766) e valutate in sequenza, a partire dal numero più basso. La prima regola corrispondente viene applicata immediatamente. | L'ordinamento delle regole è critico. La regola di rifiuto implicita (l'ultima regola elaborata) nega tutto ciò che non è stato esplicitamente consentito. |
Gestione del Traffico Stateless (Porte Effimere)
Poiché le NACL sono stateless, devi considerare le porte effimere utilizzate dai client che si connettono ai tuoi server. Quando un client avvia una connessione, utilizza una porta di destinazione (es., 80 per HTTP) e una porta di origine con numero alto (intervallo porte effimere, tipicamente 1024-65535).
Per consentire il traffico web (HTTP) in una sottorete, hai bisogno di due regole:
- Regola in Entrata: Consente il traffico sulla porta di destinazione (es., 80).
- Regola in Uscita: Consente il traffico di ritorno al client utilizzando le porte di origine effimere.
| Regola # | Tipo | Protocollo | Intervallo Porte | Origine/Destinazione | Azione Regola |
|---|---|---|---|---|---|
| 100 | In entrata | TCP | 80 | 0.0.0.0/0 | ALLOW (Traffico web in entrata) |
| 110 | In uscita | TCP | 1024-65535 | 0.0.0.0/0 | ALLOW (Risposta web in uscita - Porte effimere) |
| * | Rifiuto Implicito | Tutti | Tutte | Tutti | DENY (Elaborato per ultimo) |
Attenzione: Se perdi la corrispondente regola in uscita per le porte effimere in una NACL, il traffico raggiungerà l'istanza (a causa della regola in entrata) ma la risposta verrà scartata al confine della sottorete, portando a timeout di connessione.
Riepilogo Comparativo: SG vs. NACL
La tabella seguente riassume le differenze cruciali tra i due tipi di firewall:
| Caratteristica | Gruppo di Sicurezza (SG) | ACL di Rete (NACL) |
|---|---|---|
| Ambito di Applicabilità | Livello Istanza/ENI | Livello Sottorete |
| Stato | Stateful | Stateless |
| Tipi di Regola | Solo Consenti | Consenti e Nega |
| Valutazione Regole | Tutte le regole valutate, nessun ordine specifico. | Regole valutate in sequenza per numero (la più bassa prima); la prima corrispondenza vince. |
| Comportamento Predefinito | Nega tutto in entrata, consente tutto in uscita (a meno che non sia limitato). | NACL predefinita consente tutto in entrata/uscita. NACL personalizzate negano tutto in entrata/uscita. |
| Effetto sul Traffico | Applica le regole solo se il traffico è destinato a o proviene da una risorsa associata. | Filtra il traffico che attraversa il confine della sottorete, influenzando tutte le risorse nella sottorete. |
Scegliere il Firewall Giusto: Scenari e Buone Pratiche
La sicurezza VPC di successo si basa sull'uso combinato di SG e NACL in un approccio a strati (Difesa in Profondità).
Quando Dare Priorità ai Gruppi di Sicurezza
I Gruppi di Sicurezza dovrebbero essere lo strumento principale per filtrare l'accesso alla rete grazie alla loro natura stateful e alla capacità di fare riferimento ad altri SG, semplificando la configurazione dell'applicazione.
- Controllo Applicativo Granulare: Usa gli SG per definire esattamente quali porte e protocolli sono richiesti per un'applicazione specifica (es., consentire solo il traffico sulla porta 3306 dal SG del server web al SG del database).
- Comunicazione Interna: Gestisci la sicurezza per il traffico tra istanze all'interno della stessa sottorete o tra sottoreti (es., assicurando che un load balancer possa comunicare con i suoi gruppi target).
- Facilità di Gestione: Poiché sono stateful, gli SG richiedono meno regole e sono meno soggetti a errori rispetto alla gestione delle porte effimere con le NACL.
Quando Implementare le ACL di Rete
Le NACL sono più adatte per impostare ampi confini di rete e politiche di segmentazione.
- Politiche di Rifiuto Ampie: Usa regole
DENYesplicite (Regola #100) per bloccare specifici indirizzi IP o intervalli IP dannosi attraverso un'intera sottorete prima che il traffico raggiunga le istanze. - Segmentazione delle Sottoreti: Impone confini rigorosi tra i livelli della tua architettura (es., assicurando che la NACL della sottorete del database neghi esplicitamente tutto il traffico in entrata da internet, indipendentemente da come potrebbe essere configurato un SG).
- Requisiti di Conformità: Alcuni standard di conformità possono richiedere il filtraggio a livello di sottorete, rendendo le NACL essenziali.
- Filtraggio di Protocolli Stateless: Le NACL sono necessarie se è necessario filtrare protocolli stateless che gli SG non possono gestire efficacemente da soli (anche se questo è raro per il traffico TCP/UDP standard).
Errori che Causano Interruzioni
L'interruzione NACL più comune è dimenticare il traffico di ritorno. Qualcuno consente TCP 443 in entrata in una sottorete pubblica e lascia le regole in uscita troppo restrittive. Il load balancer o l'istanza riceve il SYN, ma la risposta viene scartata sulla via del ritorno. Dal lato client sembra un timeout, e dal lato istanza il servizio può sembrare perfettamente sano.
Un altro errore è usare le NACL per le politiche per applicazione. Se una sottorete contiene istanze web, worker e admin, una NACL si applica a tutte. Una regola aggiunta per un carico di lavoro può esporre o rompere inaspettatamente un altro carico di lavoro nella stessa sottorete. Se hai bisogno di un comportamento di rete diverso, usa gruppi di sicurezza diversi e considera sottoreti separate solo quando c'è un confine reale da imporre.
Anche la numerazione delle regole merita attenzione. Lascia spazi come 100, 110, 120 invece di 1, 2, 3 in modo da poter inserire regole di emergenza in seguito. Ricorda che la prima corrispondenza vince. Un rifiuto alla regola 90 batterà un consenso alla regola 100, anche se il consenso sembra più specifico a chi legge rapidamente la console.
Per i gruppi di sicurezza, l'errore comune sono gli intervalli di origine ampi. 0.0.0.0/0 sulla 443 per un load balancer pubblico può essere normale. La stessa origine su SSH, RDP, Redis, PostgreSQL o un'API admin interna è solitamente un problema. Preferisci i riferimenti ai gruppi di sicurezza all'interno del VPC e CIDR ristretti per l'accesso degli operatori.
Quando erediti un VPC esistente, esporta le regole e raggruppale per intento: punti di ingresso pubblici, traffico app-to-app, datastore, amministrazione e rifiuti di emergenza. Le regole senza un proprietario o una ragione chiari sono dove di solito risiede l'esposizione obsoleta.
L'Approccio della Difesa in Profondità
In un VPC tipico e ben progettato, i flussi di traffico devono passare attraverso sia una NACL che un Gruppo di Sicurezza. Se uno dei due controlli di sicurezza nega il traffico, il pacchetto viene scartato.
- Flusso in Entrata: Il traffico entra nella sottorete -> NACL controlla le regole -> Il traffico raggiunge l'ENI dell'istanza -> Gruppo di Sicurezza controlla le regole -> Il traffico raggiunge l'applicazione.
- Flusso in Uscita: L'applicazione genera la risposta -> Gruppo di Sicurezza (Controllo stateful superato) -> Il traffico lascia l'ENI dell'istanza -> NACL controlla le regole -> Il traffico lascia la sottorete.
Sfruttando la NACL per la segmentazione grossolana e le regole di rifiuto, e il SG per permessi precisi, stateful e a livello di applicazione, massimizzi l'efficacia della sicurezza mantenendo la semplicità di configurazione.
Un Modello di Progettazione Pratico
Per la maggior parte dei VPC applicativi, inizia con i gruppi di sicurezza. Dai al load balancer un gruppo di sicurezza rivolto al pubblico, dai alle istanze applicative un gruppo di sicurezza che accetta solo traffico dal gruppo di sicurezza del load balancer, e dai al database un gruppo di sicurezza che accetta solo traffico dal gruppo di sicurezza dell'applicazione sulla porta del database. Quel modello segue il grafico delle dipendenze dell'app e sopravvive ai cambiamenti di IP.
Usa le NACL con più parsimonia. Un buon caso d'uso per le NACL è un rifiuto a livello di sottorete per un CIDR noto come dannoso, un confine rigido attorno a una sottorete di database o una regola di conformità che deve applicarsi prima che il traffico raggiunga qualsiasi ENI nella sottorete. Le NACL diventano problematiche quando i team cercano di rispecchiare ogni regola applicativa lì. Le regole delle porte di ritorno stateless sono facili da sbagliare e un singolo rifiuto con numero basso può rompere un'intera sottorete.
Quando una connessione va in timeout, controlla entrambi i livelli nel percorso del pacchetto. Per il traffico internet in entrata verso un'istanza EC2 in una sottorete pubblica, la richiesta deve superare la regola NACL in entrata, la tabella di instradamento e la regola del gruppo di sicurezza in entrata. La risposta deve superare il tracciamento stateful del gruppo di sicurezza e la regola NACL in uscita. Se gli SG sembrano corretti ma i client si bloccano ancora, la regola della porta effimera NACL è spesso il pezzo mancante.
Il modello mentale più pulito è questo: i gruppi di sicurezza dicono quali risorse possono parlare a quali altre risorse; le NACL dicono cosa la sottorete non permetterà mai. Mantieni questi compiti separati e il design rimane più facile da controllare.