Perché la cifratura in transito è un requisito, non un’opzione
In uno scenario di connettività ibrida il traffico attraversa domini che non controlli: circuiti di operatore, punti di interconnessione in colocation, backbone del cloud provider. Il requisito di encryption-in-transit nasce dalla necessità di garantire riservatezza e integrità dei dati mentre percorrono questi tratti, indipendentemente dal fatto che il percorso sia “privato”. Nel design ENCC devi saper mappare quale tecnologia di cifratura si applica a quale segmento del percorso, perché IPsec e MACsec operano a livelli diversi e risolvono problemi diversi.
IPsec vs MACsec: la scelta dipende dal percorso
| Criterio | IPsec | MACsec (802.1AE) |
|---|---|---|
| Livello OSI | Layer 3 | Layer 2 |
| Ambito di protezione | End-to-end / gateway-to-gateway, su reti routate | Hop-by-hop, link Ethernet point-to-point |
| Scenario tipico | VPN site-to-cloud, overlay SD-WAN, tunnel sopra Internet o sopra un link privato | Cross-connect in colocation, porta fisica verso il provider, tratta tra switch adiacenti |
| Key management | IKEv2 | MKA (MACsec Key Agreement, 802.1X) |
| Cifratura | ESP con AES-GCM | GCM-AES 128/256, a line-rate |
| Overhead | Incapsulamento e possibile frammentazione (MTU/MSS) | Minimo, in hardware sull’ASIC |
Regola pratica per l’esame: se il traffico deve restare protetto attraverso più hop routati o su un percorso non fidato, il design corretto è IPsec (tipicamente terminato su un cloud VPN gateway o su un router IOS-XE/CSR in cloud). Se devi cifrare una singola tratta Ethernet punto-punto — ad esempio il cross-connect verso l’interconnessione dedicata del provider — la risposta è MACsec, che opera a wire-speed ma protegge solo quel link, non l’intero percorso.
Su una interconnessione dedicata (private interconnect verso il cloud) hai due opzioni: MACsec sulla porta fisica se il provider lo supporta, oppure IPsec sopra il collegamento privato per ottenere protezione end-to-end tra il tuo edge e il gateway cloud. Le due non si escludono: MACsec protegge il salto fisico, IPsec protegge il flusso logico.
Controlli lato cloud: security group e NACL
La cifratura protegge i dati sul filo; i controlli di accesso decidono chi può parlare con chi. Nel cloud i due strumenti principali sono:
- Security group — firewall stateful associato all’interfaccia/istanza. Contiene solo regole di allow su un modello default-deny: il traffico di ritorno è consentito automaticamente. È lo strumento di microsegmentazione più fine.
- Network ACL (NACL) — filtro stateless a livello di subnet, con regole di allow e deny valutate in ordine. Essendo stateless, devi aprire esplicitamente il traffico di ritorno (porte effimere). Utile come guardrail di perimetro sulla subnet.
Buona pratica di design: usa le NACL come confine grossolano tra subnet/tier e i security group per il controllo puntuale servizio-per-servizio.
Segmentazione del traffico ibrido secondo il least privilege
Nel design ibrido applica il least privilege a ogni livello: consenti solo le porte, i protocolli e le coppie origine/destinazione realmente necessari. Segmenta i tier (front-end, applicativo, dati) in subnet distinte, referenzia i security group per ID di gruppo anziché per range IP ampi, e limita i flussi tra on-premises e cloud alle sole subnet e servizi previsti dall’architettura. La cifratura e la segmentazione sono complementari: IPsec/MACsec impediscono l’intercettazione, i security group/NACL impediscono i movimenti laterali non autorizzati.
Trappole tipiche d’esame
- Scenario: il traffico passa su un’interconnessione dedicata “privata” e si conclude che è già sicuro → Risposta giusta: un link privato garantisce isolamento del path, non riservatezza; serve cifratura esplicita (MACsec sul cross-connect o IPsec sopra il circuito). “Privato” ≠ “cifrato”.
- Scenario: si sceglie MACsec per proteggere un flusso che attraversa più hop L3 fino al cloud → Risposta giusta: MACsec è hop-by-hop L2; per protezione end-to-end su rete routata serve IPsec.
- Scenario: un security group aperto a
0.0.0.0/0su una porta amministrativa considerato accettabile perché “tanto c’è la VPN” → Risposta giusta: viola il least privilege; restringi origine e porte, referenziando il security group di origine. - Scenario: si aggiunge solo una regola di allow in ingresso su una NACL e il traffico continua a fallire → Risposta giusta: la NACL è stateless; va aperto anche il ritorno sulle porte effimere (comportamento diverso dal security group stateful).
- Scenario: un tunnel IPsec attivo ma con perdita di pacchetti su flussi TCP grandi → Risposta giusta: overhead di incapsulamento ESP; regola MTU/MSS clamping sul path per evitare frammentazione.