RBAC, ABAC e PBAC: quali modelli di controllo degli accessi?

Tre modi di rispondere alla domanda "questo utente può fare questa azione su questa risorsa?":

• RBAC (Role-Based) – i permessi si assegnano a ruoli ("admin", "editor", "viewer"), e gli utenti ricevono ruoli. Semplice, comprensibile, il più diffuso. Il limite: esplode con la complessità (l'"editor ma solo del reparto X, solo in orario d'ufficio, solo dai dispositivi aziendali" genera una proliferazione di ruoli ingestibile – la role explosion)
• ABAC (Attribute-Based) – la decisione si calcola da attributi di utente, risorsa, azione e contesto ("permetti se reparto_utente == reparto_risorsa E orario è lavorativo E dispositivo è gestito"). Molto più espressivo e granulare, ma più complesso da progettare e verificare
• PBAC (Policy-Based) – generalizza: le decisioni sono policy dichiarative centralizzate, spesso come codice (Policy-as-Code con Open Policy Agent/Rego), disaccoppiate dall'applicazione

La direzione moderna è verso ABAC/PBAC e il Policy-as-Code: le regole di autorizzazione diventano codice versionato, testato e verificabile invece di logica sparsa nelle applicazioni – lo stesso spirito dell'Infrastructure as Code. Il consiglio pratico: parti da RBAC (copre benissimo la maggioranza dei casi ed è comprensibile a tutti), aggiungi attributi/policy dove la granularità serve davvero. E qualunque sia il modello, il fondamento resta il minimo privilegio: il miglior sistema di autorizzazione è quello che concede il meno possibile per default.