Vai al contenuto

Sicurezza delle reti tra 802.1X, AAA e Zero Trust: una guida tecnica integrata

La cornice: cosa intendiamo oggi per “sicurezza delle reti”

La sicurezza delle reti ha cambiato baricentro almeno tre volte negli ultimi vent’anni. Prima la difendevamo come un castello con il firewall perimetrale; poi, con la diffusione del wireless e del mobile, abbiamo capito che il perimetro era diventato poroso; oggi, in un mondo di cloud ibrido, BYOD e lavoro distribuito, il concetto stesso di “interno” ha perso significato. Le normative riflettono questo spostamento: la direttiva europea NIS2 (Direttiva 2022/2555), entrata in vigore il 18 ottobre 2024 e applicabile, secondo la Commissione europea, a oltre 160.000 entità essenziali e importanti — un’espansione decuplicata rispetto alle circa 15.000 coperte dalla NIS1 originale — in 18 settori, impone all’articolo 21 misure tecniche e organizzative che includono esplicitamente l’autenticazione multifattore, il controllo degli accessi, la cifratura e la segmentazione. Negli Stati Uniti, l’Executive Order 14028 “Improving the Nation’s Cybersecurity” firmato dal Presidente Joseph R. Biden il 12 maggio 2021 (Federal Register 86 FR 26633, documento 2021-10460) e il successivo OMB Memorandum M-22-09 “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles” firmato il 26 gennaio 2022 dalla Acting OMB Director Shalanda D. Young hanno fissato come obiettivo federale il raggiungimento di “specific cybersecurity standards and objectives by the end of Fiscal Year (FY) 2024 in order to reinforce the Government’s defenses against increasingly sophisticated and persistent threat campaigns”. In questo contesto, parlare di sicurezza delle reti significa parlare al tempo stesso di chi si collega (identità), di cosa si collega (postura del dispositivo) e di che cosa può fare una volta dentro (autorizzazione granulare e accounting).

IEEE 802.1X: l’autenticazione port-based, mattone fondamentale

Lo standard IEEE 802.1X, nella revisione vigente IEEE Std 802.1X-2020 ratificata nel febbraio 2020, definisce il Port-Based Network Access Control (PNAC) come il meccanismo che, nelle parole dell’IEEE 802.1 Security Task Group, “regulates access to the network, guarding against transmission and reception by unidentified or unauthorized parties, and consequent network disruption, theft of service, or data loss”. L’astrazione chiave è la separazione, su ogni porta dello switch o access point, tra un Uncontrolled Port — riservato al traffico di autenticazione e ai protocolli di gestione delle chiavi — e un Controlled Port che resta in stato “unauthorized” finché l’autenticazione non riesce. Solo allora il Controlled Port si apre al traffico dati e, opzionalmente, può attivare la cifratura di livello 2 con MACsec (IEEE 802.1AE), spesso ignorato in azienda ma sempre più rilevante nei datacenter e nelle reti OT.

Il modello operativo si articola in tre ruoli. Il supplicant è il software sul client (Windows Wired AutoConfig, wpa_supplicant su Linux, gli stack nativi di iOS, macOS e Android) che inizia il dialogo presentando le credenziali. L’authenticator è l’apparato di rete — switch, controller WLAN, access point — che funge da gatekeeper: non valuta le credenziali ma le inoltra come frame EAP incapsulati in EAPOL (EAP over LAN) verso un authentication server. Quest’ultimo, quasi sempre un RADIUS server (Cisco ISE, Aruba ClearPass, Microsoft NPS, FreeRADIUS, JumpCloud Cloud RADIUS, Portnox), prende la decisione e la notifica all’authenticator con un Access-Accept o Access-Reject, eventualmente accompagnato da attributi che spingono il client in una specifica VLAN, applicano una downloadable ACL o associano un Security Group Tag.

Sopra a 802.1X gira EAP, definito da RFC 3748 (giugno 2004, autori B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz). EAP non è un metodo di autenticazione ma “an authentication framework which supports multiple authentication methods” che “typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP”. I metodi più rilevanti oggi sono EAP-TLS (RFC 5216), che richiede certificati su entrambi i lati e fornisce mutua autenticazione passwordless, considerato lo standard di fatto per il Wi-Fi enterprise sicuro; PEAP, che incapsula MS-CHAPv2 in un tunnel TLS server-side ed è ancora il più usato con Active Directory pur essendo vulnerabile ad attacchi di downgrade e dictionary; EAP-TTLS (RFC 5281), simile a PEAP ma più flessibile sui metodi interni; ed EAP-FAST di Cisco (RFC 4851), basato su Protected Access Credentials. In ambito mobile, EAP-AKA e EAP-SIM autenticano contro la SIM. L’evoluzione recente più significativa è il rilascio di Wi-Fi 7 con WPA3-Enterprise come baseline: WPA3-Enterprise 192-bit suite richiede di fatto EAP-TLS con curve ellittiche e SHA-384, segnando la fine pratica delle credenziali username/password sul Wi-Fi aziendale.

Casi d’uso reali: oltre al Wi-Fi corporate (dove 802.1X+EAP-TLS è ormai obbligatorio per qualsiasi azienda regolata), 802.1X presidia la rete cablata di campus universitari e ospedali, abilita il dynamic VLAN assignment in funzione del ruolo dell’utente, gestisce l’onboarding BYOD tramite portali con MAB (MAC Authentication Bypass) come fallback per stampanti, telefoni IP e dispositivi IoT non-supplicant-capable, e su scala mondiale sostiene la federazione eduroam che permette a uno studente di accedere alla Wi-Fi di qualsiasi università aderente con le credenziali del proprio ateneo grazie a un mesh di server RADIUS proxy.

AAA: Authentication, Authorization, Accounting come motore della decisione

Il framework AAA — Authentication, Authorization, Accounting — è la grammatica con cui un dispositivo di rete pone al server tre domande distinte: “chi sei?”, “cosa puoi fare?” e “cosa hai fatto?”. Tre protocolli implementano questa grammatica in modi diversi.

RADIUS (Remote Authentication Dial-In User Service), nato in Livingston Enterprises nel 1991 e standardizzato da RFC 2865 (authentication+authorization) e RFC 2866 (accounting) nel giugno 2000, è oggi la lingua franca dell’accesso utente: UDP, porte 1812 e 1813, modello stateless, attributi estensibili tramite Vendor-Specific Attributes. RADIUS combina autenticazione e autorizzazione in un singolo scambio Access-Request → Access-Accept/Reject/Challenge: il server restituisce contestualmente l’esito e gli attributi di policy. È il backend di scelta per 802.1X proprio perché il supplicant invia frame EAP che l’authenticator incapsula nativamente negli attributi RADIUS EAP-Message (RFC 3579). La sua debolezza storica — l’uso di MD5 per il Response Authenticator — è esplosa nel 2024 con Blast-RADIUS (CVE-2024-3596, CVSS 8.1), divulgata il 7 luglio 2024 da ricercatori dell’UC San Diego con Microsoft Research e Cloudflare. Per la pagina ufficiale dei ricercatori (blastradius.fail), “the attacker injects a malicious attribute into a request that causes a collision between the authentication information in the valid server response and the attacker’s desired forgery. This allows the attacker to turn a reject into an accept, and add arbitrary protocol attributes”. La mitigazione raccomandata è il Message-Authenticator obbligatorio su ogni pacchetto (HMAC-MD5 sull’intero pacchetto) e, in prospettiva, la migrazione a RadSec (RADIUS over TLS, RFC 6614) o DTLS (RFC 7360). Importante: i flussi EAP-based 802.1X, che usano già Message-Authenticator per design, non sono vulnerabili — la falla colpisce soprattutto MAB, login amministrativo con PAP/CHAP e VPN legacy.

TACACS+ (Terminal Access Controller Access-Control System Plus), formalizzato solo nel 2020 da RFC 8907, gira su TCP/49 e separa rigorosamente le tre fasi AAA in tre scambi distinti. Questa separazione è la sua arma vincente nella gestione amministrativa degli apparati di rete: con TACACS+ ogni singolo comando CLI che un network engineer digita su un router può essere autorizzato e auditato server-side (“command authorization” e “command accounting”), cosa che RADIUS non sa fare perché ferma l’autorizzazione al privilege level 0-15. Il rovescio della medaglia è che TACACS+ obfusca il body con un pad MD5 ma non lo cifra crittograficamente; per chiudere questo gap è stato pubblicato l’RFC 9887 che definisce TACACS+ over TLS 1.3 su TCP/300.

Diameter (RFC 6733, ottobre 2012, che obsoletizza RFC 3588) era stato pensato dalla AAA Working Group dell’IETF come erede naturale di RADIUS: TCP/SCTP, peer-to-peer, congestion control, failover nativo. Nella telefonia mobile (HSS e PCRF di 4G, AAA di IMS) ha vinto; nell’enterprise no. La ragione è prosaica: RADIUS funziona, è dappertutto, e dopo trent’anni di codice di campo nessuno vuole sostituirlo se non costretto.

L’integrazione con 802.1X è il punto in cui AAA esce dal regno teorico ed entra nell’operatività quotidiana. Quando un laptop si collega a una porta switch, l’authenticator estrae il payload EAP dai frame EAPOL del supplicant, lo incapsula in un attributo EAP-Message di RADIUS e lo inoltra al server. Il server gestisce il dialogo EAP fino a chiusura (con EAP-TLS scambia certificati, con PEAP costruisce il tunnel e poi MS-CHAPv2 interno), e al termine emette Access-Accept con attributi come Tunnel-Private-Group-ID per il dynamic VLAN, Filter-Id per una ACL preconfigurata, Cisco AV-pair per dACL, o un cisco-av-pair che codifica un SGT per TrustSec. È in questo handshake che si decide non solo “se” un utente entra, ma “dove” entra e “con quali privilegi” — il primo gradino reale dell’enforcement Zero Trust.

Zero Trust: dalla provocazione di Kindervag al NIST SP 800-207

Il termine “Zero Trust” è stato coniato da John Kindervag, allora analista di Forrester Research, nel report del 14 settembre 2010 dal titolo “No More Chewy Centers: Introducing The Zero Trust Model Of Information Security” (Forrester Research, autori John Kindervag con Stephanie Balaouras e Lindsey Coit). La tesi era brutale nella sua semplicità — “There is a simple philosophy at the core of Zero Trust: Security professionals must stop trusting packets as if they were people. Instead, they must eliminate the idea of a trusted network (usually the internal network) and an untrusted network (external networks). In Zero Trust, all network traffic is untrusted” — e oggi è entrata nel vocabolario operativo di chiunque progetti reti. La spinta concreta venne da Google: dopo l’attacco Operation Aurora del 2009, Google riprogettò la propria sicurezza interna nel programma BeyondCorp, descritto nell’articolo “BeyondCorp: A New Approach to Enterprise Security” di Rory Ward e Betsy Beyer pubblicato su USENIX ;login: Vol. 39 No. 6, dicembre 2014, pp. 6–11. L’idea, nelle parole degli autori: “access depends solely on device and user credentials, regardless of a user’s network location — be it an enterprise location, a home network…” — spostare cioè l’enforcement dal perimetro al binomio identità+dispositivo, eliminando la VPN e proxando ogni applicazione interna attraverso un Identity-Aware Proxy.

La codifica autorevole arriva con NIST Special Publication 800-207 “Zero Trust Architecture” (autori Scott Rose, Oliver Borchert, Stu Mitchell, Sean Connelly), pubblicata in versione finale l’11 agosto 2020. Il documento definisce sette tenets — fra cui “tutte le risorse di dati e i servizi di calcolo sono considerati risorse”, “tutte le comunicazioni sono protette indipendentemente dalla posizione di rete”, “l’accesso alle risorse aziendali è concesso per singola sessione”, “l’autenticazione e l’autorizzazione sono dinamiche e strettamente applicate prima che l’accesso sia consentito” — e disegna l’architettura logica attorno a tre componenti: il Policy Engine, che applica un algoritmo di trust su input come identità, postura, contesto, threat intelligence; il Policy Administrator, che configura il canale tra subject e resource sulla base della decisione; e il Policy Enforcement Point, lo stradino sul percorso che apre o chiude la porta. NIST identifica tre approcci implementativi principali: Enhanced Identity Governance (decisioni primariamente identità-driven), Microsegmentation (segmentazione fine grain attraverso firewall NGFW o agent host-based), e Software Defined Perimeter (overlay di rete che nasconde le risorse alla discoverability pubblica).

Il 10 giugno 2025 NIST ha rilasciato la versione finale di NIST SP 1800-35 “Implementing a Zero Trust Architecture”, frutto del lavoro pluriennale del NCCoE iniziato nel 2018-2019 con 24 collaboratori di settore che hanno costruito 19 build di esempio mappate sui controlli di NIST CSF 1.1/2.0 e SP 800-53r5: è oggi il riferimento operativo più completo per chi deve passare dalla teoria all’implementazione. Le implementazioni coprono quattro approcci — Enhanced Identity Governance (EIG), Software-Defined Perimeter (SDP), Microsegmentation e Secure Access Service Edge (SASE) — descritti come “interoperable, open standards-based ZTA implementations”.

Il vocabolario operativo Zero Trust si articola in quattro pratiche concrete. Il “never trust, always verify” si traduce in autenticazione continua: non più un check al login ma valutazione di rischio ad ogni richiesta, con session token a breve validità e step-up MFA quando il rischio cambia. La microsegmentazione applica policy least-privilege a livello di workload — implementazioni mature sono Illumio (agent host-based), VMware NSX (anchored al hypervisor), Cisco Secure Workload (ex Tetration) per ambienti ibridi e cloud-native, e nuovi entrant identity-driven come Elisity e Zero Networks. L’identity-aware proxy (paradigma BeyondCorp, implementato commercialmente come Google Cloud IAP, Cloudflare Access, Zscaler Private Access, Cisco Duo Network Gateway) intermedia ogni richiesta HTTP/HTTPS verso un’applicazione interna autenticando l’utente al gateway prima ancora che il pacchetto raggiunga il backend. Lo ZTNA (Zero Trust Network Access), definito da Gartner come “products and services that create an identity- and context-based, logical-access boundary that encompasses an enterprise user and an internally hosted application or set of applications”, è la generalizzazione di questa logica e, secondo il report Gartner “Emerging Technologies: Adoption Growth Insights for Zero Trust Network Access” (Nat Smith, Mark Wah, Christian Canales, 8 aprile 2022), “by 2025, at least 70% of new remote access deployments will be served predominantly by ZTNA as opposed to VPN services, up from less than 10% at the end of 2021”.

Casi d’uso reali abbondano: settore finanziario per ridurre il blast radius di un account compromesso, sanità per isolare i dispositivi medici IoMT regolati da HIPAA e dalla guidance HHS 405(d), industria manifatturiera per segmentare la rete OT da quella IT, settore pubblico federale USA dove M-22-09 ha imposto deadline vincolanti. Il report Gartner “Emerging Tech: Universal ZTNA Drives Secure Access Consolidation” (Charanpal Bhogal, Andrew Lerner et al., 20 dicembre 2024) prevede che “universal zero-trust network access is expected to grow to widespread adoption, greater than 40%, by 2027” — l’idea cioè di applicare lo stesso policy framework a utenti on-prem e remoti senza distinzione.

L’interconnessione: 802.1X + AAA + Zero Trust come strategia unitaria

È qui che le tre tecnologie smettono di essere isole e diventano un’architettura. La metafora che uso con i miei team è quella della casa: 802.1X è la serratura della porta d’ingresso, l’AAA è il portinaio che decide chi può salire a quale piano e tiene il registro delle entrate, Zero Trust è il principio per cui ogni stanza ha una serratura propria, anche se sei già dentro l’edificio.

In termini concreti, l’integrazione si materializza in tre punti. Primo, la radice identitaria comune: il supplicant 802.1X autentica con EAP-TLS contro un certificato emesso dalla stessa PKI aziendale che firma i certificati device usati dal client ZTNA, mentre l’utente si autentica all’IdP (Entra ID, Okta, Google Workspace, Ping) che federa sia il login al portale captive di onboarding sia il flusso SAML/OIDC verso le applicazioni dietro l’identity-aware proxy. Secondo, la postura del dispositivo: il NAC moderno (Cisco ISE, Aruba ClearPass, Portnox, Forescout) verifica al momento dell’autenticazione 802.1X che il client abbia disk encryption attiva, antivirus aggiornato, patch di sistema entro N giorni, e propaga lo stesso attributo di “device health” al PEP applicativo via SCIM o syslog strutturato; se la postura degrada in sessione, il PEP può forzare la riautenticazione o spostare il client in una VLAN di remediation. Terzo, la coerenza tra macro- e microsegmentazione: gli attributi che il server RADIUS spinge sull’authenticator 802.1X (VLAN, SGT, dACL) sono gli stessi che il firewall di microsegmentazione usa per applicare le policy est-ovest e che il broker ZTNA usa per decidere l’accesso applicativo. CISA ha pubblicato a luglio 2025 la guidance “The Journey to Zero Trust Microsegmentation in Zero Trust” (Part One, TLP:CLEAR) che indica esplicitamente come “microsegmentation augments the organization’s ability to apply targeted risk- and threat-appropriate protections when it is used in conjunction with existing capabilities”, consacrando l’integrazione tra NAC 802.1X e microsegmentazione come passo fondante della maturity Zero Trust.

In altre parole: senza 802.1X+AAA, lo Zero Trust resta una astrazione applicativa che lascia scoperto il livello 2; senza Zero Trust, 802.1X+AAA controllano l’ingresso ma non l’orizzontale, e una volta che un endpoint compromesso è dentro la VLAN giusta può muoversi lateralmente. La somma è una difesa coerente dal cavo Ethernet alla query API.

Trend 2023–2026: cosa sta cambiando davvero

Cinque sviluppi stanno ridisegnando il panorama. Primo, la convergenza SASE/SSE: Gartner, nel Magic Quadrant for SASE Platforms del 20 maggio 2025 (analisti Charlie Winckless, Thomas Lintemuth, Dale Koeppen, Charanpal Bhogal) e nel Magic Quadrant for Security Service Edge dello stesso anno, posiziona ZTNA non più come prodotto stand-alone ma come componente di piattaforme convergenti (SD-WAN + SWG + CASB + ZTNA + FWaaS) offerte da Zscaler, Palo Alto Networks Prisma Access, Cisco+Splunk, Cloudflare, Netskope, Fortinet. Secondo, la post-vulnerability era di RADIUS: dopo Blast-RADIUS i vendor (Cisco, Juniper Mist, Meraki, FreeRADIUS, Radiator) hanno rilasciato patch che rendono Message-Authenticator obbligatorio e accelerato l’adozione di RadSec — questo è il singolo cambiamento tecnico più importante del 2024 in ambito AAA. Terzo, la pressione regolatoria: NIS2 in UE applicabile da ottobre 2024, l’EO 14028 e M-22-09 negli USA con la deadline di settembre 2024, il DORA per il finanziario, hanno trasformato Zero Trust da best practice a requisito di compliance documentabile. Quarto, l’identità workload-to-workload con SPIFFE/SPIRE come standard emergente per la mutual authentication tra microservizi, esplicitamente richiamato dal NIST SP 800-207A. Quinto, l’integrazione AI-driven nei policy engine: il principale gap operativo evidenziato dal SP 1800-35 è che le architetture testate si basano ancora su valutazioni periodiche e provisioning statico, mentre lo stato dell’arte richiede continuous, context-aware access decisions con segnali EDR/XDR, UEBA e threat intelligence aggregati in tempo reale — un ambito in cui i vendor stanno investendo pesantemente nel 2025-2026.

Recommendations

Una progressione pragmatica, ordinata per impatto e fattibilità, per un’organizzazione che abbia oggi una rete enterprise tradizionale.

Fase 1 (0–3 mesi, costo basso): mettere in sicurezza il piano AAA esistente. Configurare Message-Authenticator obbligatorio su tutti i NAS e RADIUS server per mitigare Blast-RADIUS, dismettere PAP/CHAP nei flussi non-EAP, segmentare il traffico RADIUS in una management VLAN dedicata, attivare logging accounting su SIEM. La soglia che farebbe scalare a fase 2: scoperta di MAB diffuso o di credenziali condivise tra apparati.

Fase 2 (3–9 mesi, costo medio): standardizzare 802.1X con EAP-TLS su tutta la rete wired e wireless aziendale. Implica costruire o esternalizzare una PKI (Microsoft AD CS, SecureW2, AWS Private CA), distribuire certificati device tramite MDM (Intune, Jamf, Workspace ONE), pianificare la migrazione da PEAP-MSCHAPv2 a EAP-TLS in finestre controllate, consolidare il server AAA su una piattaforma NAC che integri postura del dispositivo (Cisco ISE, Aruba ClearPass, Portnox Cloud, Forescout). La soglia di passaggio a fase 3: pressione di compliance NIS2/DORA o un incidente che evidenzi lateral movement.

Fase 3 (9–24 mesi, costo alto): introdurre Zero Trust applicativo. Pilotare ZTNA per accesso remoto sostituendo gradualmente la VPN su un sottoinsieme di applicazioni critiche, integrare l’identity-aware proxy con l’IdP aziendale e con i segnali di postura raccolti dal NAC, avviare un progetto di microsegmentazione partendo dai workload più sensibili (dati clienti, asset di pagamento, sistemi OT). Mappare ogni controllo sul NIST SP 1800-35 e su CSF 2.0 per costruire la documentazione di compliance NIS2 art. 21. Il KPI principale da monitorare è la riduzione del “blast radius” misurabile: ridurre del 50% in 12 mesi il numero medio di sistemi raggiungibili da un endpoint compromesso è un obiettivo realistico e auditabile.

Trasversalmente, su tutte le fasi: investire in formazione del team di rete sulla mentalità Zero Trust (è prima un cambio culturale e poi un acquisto di tecnologia), non firmare contratti SASE/SSE senza una proof-of-concept di almeno 60 giorni, evitare lock-in scegliendo prodotti che parlano standard (RadSec, SCIM, OIDC, OPA) anziché protocolli proprietari.

Caveats

Tre avvertimenti onesti. Primo, “Zero Trust” è anche un termine di marketing: molti prodotti etichettati come tali sono in realtà restyling di IAM, NGFW o VPN — il framework NIST 800-207 va usato come griglia di valutazione per separare la sostanza dall’etichetta. Secondo, le previsioni Gartner citate (70% sostituzione VPN entro il 2025 dal report dell’8 aprile 2022, oltre 40% universal ZTNA entro il 2027 dal report del 20 dicembre 2024) sono proiezioni di analisti, non dati storici certificati, e vanno trattate come segnali di tendenza non come fatti. Terzo, EAP-TLS e una PKI ben gestita restano il gold standard ma hanno un costo operativo reale (revoca, rotazione, gestione del ciclo di vita dei certificati device): organizzazioni piccole o con device IoT/OT poco supplicant-friendly devono pianificare con cura il fallback (MAB con profiling robusto, certificati pre-shared con scope ristretto) per evitare di trasformare l’irrigidimento di sicurezza in un blocco operativo. Infine, le date di pubblicazione e i numeri di standard citati riflettono lo stato al maggio 2026; lavori in corso come la revisione di IEEE 802.1X-2020 (progetto P802.1X-Rev) e ulteriori RFC su RadSec/TACACS+ potrebbero modificare alcuni dettagli nei prossimi 12-24 mesi.

Bibliografia

Standard IETF e IEEE

Documenti NIST

Documenti governativi e regolatori

Pubblicazioni accademiche e di settore

Report di analisti

  • Gartner, Emerging Technologies: Adoption Growth Insights for Zero Trust Network Access, Nat Smith, Mark Wah, Christian Canales, 8 aprile 2022.
  • Gartner, Emerging Tech: Universal ZTNA Drives Secure Access Consolidation, Charanpal Bhogal, Andrew Lerner et al., 20 dicembre 2024.
  • Gartner, Magic Quadrant for SASE Platforms, Charlie Winckless, Thomas Lintemuth, Dale Koeppen, Charanpal Bhogal, 20 maggio 2025.
  • Gartner, Market Guide for Zero Trust Network Access, 2024. https://www.gartner.com/en/documents/4632099

Vendor whitepaper di riferimento

Tag:

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *