Cisco TrustSec disaccoppia la politica di sicurezza dalla topologia di rete. Invece di scrivere ACL basate su indirizzi IP e subnet — fragili e difficili da mantenere quando la rete cresce — TrustSec classifica il traffico in gruppi logici identificati da un Security Group Tag (SGT) e applica l’enforcement in base al gruppo, non all’indirizzo. Cisco ISE è il cuore del modello: agisce da policy server centrale, definisce chi appartiene a quale gruppo, pubblica la matrice di autorizzazione e distribuisce i dati di policy ai NAD (Network Access Devices: switch, router, WLC, firewall).
Le tre fasi di TrustSec
TrustSec si articola in tre momenti distinti che è fondamentale tenere separati.
1. Classificazione — assegnazione dell’SGT
L’SGT viene assegnato in fase di autorizzazione. Quando un endpoint si autentica via 802.1X, MAB o Web Auth, ISE valuta le authorization policy e restituisce al NAD un SGT insieme (o al posto) degli altri risultati come dVLAN o dACL. Da quel momento tutto il traffico originato da quell’endpoint è associato a quel tag.
L’assegnazione può essere:
- Dinamica: risultato dell’authorization policy in ISE (il caso più comune).
- Statica: mappata manualmente sul NAD a IP, subnet, VLAN o interfaccia (utile per server e risorse non autenticate).
L’SGT è un valore a 16 bit (0–65535). Esempi tipici: Employees (4), Contractors, BYOD, Production_Servers, Quarantine.
2. Propagazione — portare il tag attraverso la rete
Il tag deve viaggiare dalla sorgente al punto di enforcement. Esistono due meccanismi.
Inline tagging (native tagging): l’SGT viene inserito direttamente nell’header Ethernet, in un campo Cisco Meta Data (CMD) aggiunto al frame Layer 2. Richiede hardware ASIC che supporti TrustSec hop-by-hop. È il metodo più efficiente ma funziona solo tra device TrustSec-capable.
SXP (SGT Exchange Protocol): dove l’inline tagging non è supportato (link non-TrustSec, apparati vecchi, path L3), SXP trasporta i binding IP-to-SGT via TCP (porta 64999) tra uno speaker e un listener. SXP non tagga i pacchetti: comunica soltanto la tabella “questo IP appartiene a questo SGT”, così il device di enforcement può ricostruire la classificazione a valle. ISE stesso può fungere da SXP speaker/listener e da aggregatore dei binding.
3. Enforcement — la matrice SGACL
L’enforcement è group-to-group e si esprime tramite una SGACL (Security Group ACL). La policy vive in una matrice dove le righe sono l’SGT sorgente e le colonne l’SGT di destinazione; ogni cella contiene la SGACL (permit/deny per protocollo/porta) applicata a quel flusso.
| Source \ Dest | Employees | Prod_Servers | Quarantine |
|---|---|---|---|
| Employees | Permit IP | Permit_HTTPS | Deny IP |
| Contractors | Deny IP | Deny IP | Deny IP |
| Quarantine | Deny IP | Deny IP | Deny IP |
ISE è il repository centrale della matrice: la si disegna una volta in Work Centers → TrustSec e ISE la distribuisce ai NAD. L’enforcement avviene tipicamente al punto di egress (l’ultimo switch prima della destinazione conosce l’SGT di destinazione), applicando la SGACL sul traffico che esce verso quel gruppo.
Il ruolo di ISE come policy server
Oltre alla matrice, ISE distribuisce ai NAD i cosiddetti environment data e policy data, scaricati dal device dopo l’autenticazione del NAD stesso (via PAC, Protected Access Credential, generata durante l’aggiunta del device a TrustSec). Questi dati includono l’elenco degli SGT esistenti, il proprio Device SGT e le SGACL applicabili. Il NAD interroga ISE via RADIUS per ottenere l’SGACL relativa a una coppia sorgente-destinazione quando ne ha bisogno.
Trappole tipiche d’esame
- SGT vs SGACL: uno scenario chiede “cosa classifica il traffico?” → SGT (assegnato in autorizzazione). “Cosa applica il permit/deny group-to-group?” → SGACL nella matrice. Confonderli è l’errore più comune: l’SGT è l’etichetta, la SGACL è la regola.
- Device non-TrustSec nel path: se un tratto non supporta inline tagging e il tag “si perde”, la risposta corretta è configurare SXP per propagare i binding IP-SGT, non “abilitare l’inline tagging” su hardware che non lo supporta.
- Dove avviene l’enforcement: la SGACL si applica di norma all’egress, perché è lì che si conosce l’SGT di destinazione. Rispondere “all’ingress” è spesso il distrattore.
- Chi ospita la policy: la matrice SGACL è definita e distribuita da ISE (policy server centrale), non configurata manualmente e indipendentemente su ogni switch.
- SXP non tagga i pacchetti: SXP trasporta solo la tabella IP-to-SGT via TCP/64999; se lo scenario parla di “inserire il tag nel frame”, quello è inline tagging (CMD field), non SXP.