Il modello AAA: le tre “A” della gestione degli accessi

Quando un utente o un dispositivo tenta di accedere a una risorsa di rete, entrano in gioco tre funzioni distinte, riassunte dall’acronimo AAA (Authentication, Authorization, Accounting). Confonderle è uno degli errori più frequenti: sono tre fasi separate e sequenziali.

  • Authentication (autenticazione) — risponde alla domanda “chi sei?”. Verifica l’identità dichiarata (username + password, certificato, token, biometria).
  • Authorization (autorizzazione) — risponde a “cosa puoi fare?”. Una volta provata l’identità, definisce quali comandi, VLAN, ACL o privilegi vengono concessi.
  • Accounting (registrazione) — risponde a “cosa hai fatto?”. Traccia sessioni, comandi eseguiti, byte trasferiti e durata, generando log utili ad audit e forensics.

Un utente può quindi autenticarsi con successo ma non essere autorizzato ad alcuna operazione: sono due controlli indipendenti.

Autenticazione centralizzata: RADIUS e Cisco ISE

Configurare credenziali locali su ogni router, switch o firewall non è scalabile. La soluzione è centralizzare le tre “A” su un server dedicato tramite il protocollo RADIUS (o TACACS+, tipico Cisco per l’amministrazione dei device).

Cisco ISE (Identity Services Engine) è la piattaforma di riferimento: agisce da server AAA centralizzato, gestisce le policy di accesso, l’integrazione con directory esterne, il profiling dei dispositivi e il 802.1X per l’autenticazione delle porte (NAC, Network Access Control). Il dispositivo di rete (l’authenticator) inoltra le credenziali a ISE, che decide se concedere l’accesso e con quale profilo (VLAN dinamica, dACL, SGT).

Protocollo Uso tipico Note
RADIUS Accesso di rete utenti/endpoint (802.1X, VPN, Wi-Fi) Cifra solo la password; UDP
TACACS+ Amministrazione device (comandi CLI) Cifra l’intero payload; separa nettamente le tre A; TCP

MFA: cosa conta davvero come “secondo fattore”

L’autenticazione a più fattori (MFA, o 2FA con due fattori) rafforza la sicurezza combinando fattori appartenenti a categorie diverse e indipendenti:

  1. Qualcosa che sai (something you know) — password, PIN, risposta segreta.
  2. Qualcosa che hai (something you have) — token hardware, smartphone con app OTP/push, smart card.
  3. Qualcosa che sei (something you are) — biometrics: impronta digitale, riconoscimento facciale, iride, voce.

Il punto chiave: due elementi della stessa categoria NON costituiscono MFA. Password + PIN sono entrambi “qualcosa che sai”, quindi restano un singolo fattore. Un vero secondo fattore deve provenire da una categoria differente. Analogamente, l’invio di un codice via SMS aggiunge un fattore “qualcosa che hai” (il telefono), pur essendo considerato più debole di un token dedicato per via del rischio di SIM swapping.

Least privilege e password policy

Il principio del privilegio minimo (least privilege) impone di concedere a ogni utente o processo solo i permessi strettamente necessari al suo ruolo, nulla di più. Su un dispositivo IOS/IOS-XE si traduce in privilege levels (0–15) e nell’uso mirato dei comandi di autorizzazione, evitando di assegnare a tutti il livello 15 (accesso completo).

La password policy definisce i requisiti minimi di robustezza:

  • Lunghezza e complessità (mix di maiuscole, minuscole, numeri, simboli).
  • Scadenza e history per impedire il riuso delle vecchie password.
  • Account lockout dopo N tentativi falliti, per contrastare il brute force.
  • Hashing sicuro delle credenziali memorizzate: su IOS preferire secret (hash) rispetto a password (reversibile). Il comando storico service password-encryption usa il tipo 7, facilmente reversibile, quindi inadeguato a proteggere segreti sensibili.
username admin privilege 15 secret <strong-hash>
enable secret <strong-hash>

Trappole tipiche d’esame

  • Scenario: un utente inserisce credenziali corrette ma non riesce a eseguire alcun comando. → Risposta giusta: l’authentication è riuscita; il problema è nell’authorization. Non sono la stessa fase.
  • Scenario: un sistema chiede password + PIN e viene definito “MFA”. → Risposta giusta: NON è MFA: entrambi sono “qualcosa che sai”, quindi un solo fattore. Serve un fattore di categoria diversa (token o biometria).
  • Scenario: occorre sapere chi ha eseguito quali comandi per un’indagine. → Risposta giusta: è la funzione Accounting, non l’autenticazione o l’autorizzazione.
  • Scenario: centralizzare le credenziali di accesso di switch e router per evitare account locali. → Risposta giusta: implementare un server AAA (Cisco ISE con RADIUS/TACACS+), non aggiungere utenti locali su ogni device.
  • Scenario: a un tecnico junior serve accesso solo in lettura. → Risposta giusta: applicare il least privilege con privilege level ridotto, non concedere il livello 15.