Il problema: la segmentazione legata a IP e VLAN non scala
Nelle reti tradizionali la segmentazione si realizza con VLAN, subnet e ACL basate su indirizzi IP. Il risultato è fragile: ogni policy va riscritta quando cambia l’indirizzamento, le ACL diventano lunghissime e la microsegmentazione all’interno della stessa subnet è di fatto impossibile. Cisco TrustSec rompe questo legame introducendo una segmentazione software-defined in cui la policy è espressa in termini di ruolo dell’endpoint, non di dove si trova nella topologia.
Il Security Group Tag (SGT)
Il cuore di TrustSec è il Security Group Tag (SGT), un valore a 16 bit che rappresenta il gruppo di sicurezza a cui appartiene un traffico (es. Employees, BYOD, IoT_Cameras, Quarantine). L’assegnazione del tag — la classificazione — avviene in Cisco ISE e può essere:
- Dinamica: al termine dell’autenticazione 802.1X, MAB o WebAuth, ISE restituisce l’SGT via RADIUS insieme al risultato dell’authorization.
- Statica: binding manuali IP-to-SGT, Subnet-to-SGT, VLAN-to-SGT o porta-to-SGT, tipici per server e dispositivi che non si autenticano.
Il punto chiave è che l’SGT viaggia con il traffico: una volta assegnato, identifica l’endpoint indipendentemente da IP e VLAN.
Propagazione: inline (nativo) vs SXP
Perché il device di enforcement possa applicare la policy, deve conoscere l’SGT sorgente e destinazione. Esistono due meccanismi:
| Metodo | Come funziona | Quando si usa |
|---|---|---|
| Inline tagging (nativo) | L’SGT è inserito in un campo Cisco Meta Data (CMD) dentro il frame Layer 2 | Dispositivi con ASIC TrustSec-capable su link diretti |
| SXP (SGT Exchange Protocol) | Peering TCP (porta 64999) che trasporta i binding IP-to-SGT dallo speaker al listener | Dove l’inline tagging non è supportato dall’hardware o attraversa domini non SGT-aware |
L’inline tagging è preferibile perché propaga il tag hop-by-hop nel dato stesso, ma richiede hardware che sappia scrivere/leggere il campo CMD. SXP è il fallback che consente di “trasportare fuori banda” le associazioni IP↔SGT verso un enforcement point (es. un firewall o uno switch a valle) quando il percorso non può portare il tag inline.
Enforcement con SGACL
L’applicazione della policy avviene tramite SGACL (Security Group ACL), tipicamente all’egress del dispositivo. La matrice di policy è definita centralmente in ISE come TrustSec Matrix: righe = SGT sorgente, colonne = SGT destinazione, celle = permit/deny/SGACL. Lo switch scarica dinamicamente da ISE solo le SGACL rilevanti (environment data + policy via RADIUS), evitando ACL statiche e massive. Su Cisco Firepower/FTD e ASA l’enforcement può basarsi sull’SGT nelle regole (SG-Firewall), estendendo la logica di gruppo al perimetro.
Una singola regola tipo Employees → Servers: permit / BYOD → Servers: deny vale per migliaia di host senza citare un solo indirizzo IP.
pxGrid: condivisione del contesto
pxGrid è il framework publish/subscribe che permette a ISE di condividere il contesto (identità, SGT, stato di postura, dispositivo) con l’ecosistema di sicurezza: Firepower, Stealthwatch/Secure Network Analytics, WSA, prodotti di terze parti. È il canale che consente, ad esempio, la Rapid Threat Containment: se un sistema rileva una minaccia, ISE può riassegnare l’host all’SGT Quarantine e la nuova policy si propaga a tutti i punti di enforcement, isolando l’endpoint senza toccarne l’indirizzamento.
Trappole tipiche d’esame
- Scenario: “voglio segmentare host nella stessa subnet/VLAN senza riprogettare l’indirizzamento” → risposta: TrustSec/SGT. TrustSec disaccoppia la policy dalla topologia IP: la segmentazione si basa sul ruolo (SGT), non su subnet o VLAN.
- Scenario: un dispositivo intermedio non supporta l’inline tagging nel frame → risposta: SXP. Quando l’hardware non sa scrivere il campo CMD, si usa SXP per propagare i binding IP-to-SGT verso l’enforcement point. Non è un’alternativa “migliore”, è il rimedio dove il tagging nativo manca.
- Scenario: “dove viene definita la policy e assegnato l’SGT?” → risposta: Cisco ISE. La classificazione dinamica e la TrustSec Matrix stanno in ISE; gli switch scaricano SGACL ed environment data via RADIUS. L’enforcement resta locale (egress), ma la policy è centralizzata.
- Scenario: “condividere identità/SGT/contesto tra ISE e altri prodotti (Firepower, Stealthwatch)” → risposta: pxGrid. Non SXP: SXP trasporta solo binding IP-to-SGT; pxGrid condivide contesto ricco tra piattaforme.
- Scenario: dove si applica la SGACL? → risposta: all’egress, sul device di destinazione, dopo che sorgente e destinazione SGT sono noti. Confondere ingress/egress è un classico distrattore.