L’ABAC (Attribute-Based Access Control, controllo degli accessi basato sugli attributi) è un modello di controllo degli accessi in cui le decisioni di accesso vengono prese valutando attributi del soggetto richiedente, dell’oggetto richiesto e del contesto ambientale, combinati secondo politiche booleane. È l’estensione naturale del RBAC per scenari che richiedono politiche contestuali e dinamiche che il RBAC non può esprimere.
Tipi di attributi
Attributi del soggetto (chi richiede): ruolo, dipartimento, livello di clearance, sede, tipo di contratto, certificazioni possedute, stato dell’autenticazione (MFA completato?), tipo di dispositivo.
Attributi dell’oggetto (cosa viene richiesto): classificazione del documento, dipartimento proprietario, tipo di dato, sensibilità, fase del ciclo di vita.
Attributi dell’ambiente (il contesto): ora del giorno, posizione geografica, tipo di rete (aziendale, VPN, pubblica), livello di rischio corrente, indice di minaccia.
Esempio di politica ABAC
Una politica impossibile da esprimere con il solo RBAC:
PERMIT accesso a documento se:
soggetto.dipartimento == documento.dipartimento_proprietario
AND soggetto.clearance >= documento.classificazione
AND ambiente.ora BETWEEN 08:00 AND 20:00
AND ambiente.rete IN ["rete-aziendale", "vpn-aziendale"]
AND soggetto.mfa_completato == true
AND soggetto.dispositivo.compliance == trueQuesta politica esprime: “accedi ai documenti del tuo dipartimento con il livello di clearance adeguato, ma solo durante l’orario allargato di lavoro, dalla rete aziendale o VPN, con MFA completato e dispositivo conforme alle policy.”
Standard XACML
XACML (eXtensible Access Control Markup Language, OASIS) è lo standard XML per definire politiche ABAC. L’architettura XACML separa:
- PAP (Policy Administration Point): dove le politiche vengono definite e gestite
- PDP (Policy Decision Point): valuta le politiche e decide PERMIT/DENY
- PEP (Policy Enforcement Point): intercetta le richieste e le invia al PDP
- PIP (Policy Information Point): recupera gli attributi necessari per la valutazione
Vantaggi e sfide
ABAC permette politiche molto più espressive e contestuali di RBAC — ideale per scenari Zero Trust dove ogni richiesta è valutata in base al contesto completo. È la base tecnica dei sistemi di Zero Trust moderni e degli Identity-Aware Proxy (IAP di Google, Zscaler).
La sfida principale è la complessità: le politiche ABAC sono più difficili da progettare, testare e verificare rispetto al RBAC. È difficile capire a priori se una combinazione di attributi produce il risultato atteso. Nella pratica, molti sistemi usano un approccio ibrido: RBAC come struttura base, ABAC per le condizioni contestuali aggiuntive.
Limiti operativi di ABAC
La flessibilità espressiva di ABAC ha un costo operativo:
Explosion combinatoria delle politiche: con decine di attributi e centinaia di valori possibili, il numero di combinazioni da testare cresce esponenzialmente. Le suite di test automatizzati per le policy ABAC sono nettamente più complesse di quelle RBAC.
Difficoltà di audit: a differenza del RBAC (dove “chi ha accesso a cosa” si ottiene listando i ruoli), in ABAC non è possibile rispondere direttamente a questa domanda senza simulare ogni combinazione di attributi. Gli strumenti di access review aziendale non supportano nativamente ABAC.
Latenza delle decision point: il PDP deve recuperare gli attributi dal PIP in tempo reale per ogni richiesta. In ambienti ad alto traffico (migliaia di request/s), la latenza del PDP può diventare un collo di bottiglia.
Nella pratica, molti sistemi enterprise adottano un approccio ibrido: RBAC come struttura base per le autorizzazioni coarse-grained, ABAC per le condizioni contestuali fine-grained che il solo RBAC non può esprimere.
Vedi anche: Autenticazione, Zero Trust, Controllo degli Accessi.