- DAC = il proprietario del file decide i permessi - flessibile ma dipende dall'utente
- MAC = il sistema decide in base a etichette di classificazione - usato in ambienti ad alta sicurezza
- RBAC = permessi assegnati ai ruoli, utenti assegnati ai ruoli - il modello più usato in azienda
- Rule-based = regole condizionali (orario, IP, dispositivo) - usato nei firewall e nel controllo accessi contestuale
- ABAC = combina attributi utente + risorsa + contesto - il più granulare, il più complesso
Giovedì mattina. Silvia, amministrativa HR, apre la share aziendale per caricare un documento. Trova una cartella che non riconosce. La apre. Dentro ci sono i file di stipendio di tutti i 140 dipendenti dell'azienda - compresi quelli dei dirigenti.
"Potevo leggerli? Ho pensato fossero accessibili a tutti."
Non erano accessibili a tutti. Erano accessibili a chiunque perché qualcuno aveva configurato i permessi nel modo sbagliato.
Il problema è il modello, non solo la configurazione#
Il sysadmin aveva applicato permessi 644 sulla cartella condivisa - leggibile da tutti gli utenti autenticati. Era un residuo di una migrazione fatta in fretta. Nessuna intenzione malevola. Solo la scelta del modello sbagliato per il contesto sbagliato.
Ci sono cinque modelli principali di access control. Ognuno risponde a una domanda diversa su chi decide i permessi, e quando.
graph TD
Q["Chi decide i permessi?"]
Q -->|"il proprietario del file"| DAC["DAC
Discretionary Access Control"]
Q -->|"il sistema - label di classificazione"| MAC["MAC
Mandatory Access Control"]
Q -->|"il ruolo dell utente"| RBAC["RBAC
Role-Based Access Control"]
Q -->|"regole condizionali"| RuBAC["Rule-Based AC
orario IP dispositivo"]
Q -->|"combinazione di attributi"| ABAC["ABAC
Attribute-Based Access Control"]
DAC - Discretionary Access Control#
Il proprietario del file decide chi può accedervi. Su Linux è il modello nativo: chmod, chown, i bit rwx. Su Windows sono le NTFS permission impostate manualmente.
Pro: flessibile, facile da capire, nessuna configurazione centralizzata. Contro: la sicurezza dipende interamente dall'utente. Un proprietario sbadato - o un sysadmin in fretta - può aprire tutto a tutti senza rendersene conto. Non c'è nessun vincolo di sistema che impedisca la scelta sbagliata.
Il caso di Silvia è DAC mal configurato. La cartella stipendi era di proprietà del sistema HR, ma i permessi erano stati impostati 644 - leggibile da tutti. Il proprietario aveva il controllo, lo aveva usato male.
Quando usarlo: ambienti piccoli, file personali, contesti dove la flessibilità conta più della rigidità. Non per dati sensibili condivisi.
MAC - Mandatory Access Control#
Il sistema decide. Gli utenti non possono modificare i permessi - neanche il proprietario del file. Ogni risorsa ha un'etichetta di classificazione (Top Secret, Secret, Confidential, Unclassified). Ogni utente ha un clearance level. Il sistema confronta i due: si accede solo se il clearance è uguale o superiore alla classificazione.
graph LR
U1["Utente - clearance: Secret"] -->|"può leggere"| F1["File - label: Confidential"]
U1 -->|"può leggere"| F2["File - label: Secret"]
U1 -->|"NEGATO"| F3["File - label: Top Secret"]
U2["Utente - clearance: Confidential"] -->|"NEGATO"| F2
Regola fondamentale: un utente può leggere file con label uguale o inferiore al suo clearance. Non può leggere sopra. Non può abbassare la label di un file per condividerlo con qualcuno che non ha il clearance.
Pro: il sistema impone i vincoli - l'utente non può sbagliare anche volendo. Massima rigidità. Contro: inflexible, costoso da gestire, richiede infrastruttura dedicata.
Dove si usa: ambienti militari, governativi, intelligence. Su Linux si implementa con SELinux o AppArmor. Rarissimo in aziende normali - troppo rigido per il lavoro quotidiano.
RBAC - Role-Based Access Control#
I permessi non vengono assegnati agli utenti singoli, ma ai ruoli. Gli utenti vengono assegnati ai ruoli. Se Silvia ha il ruolo HR-staff, ottiene automaticamente tutti i permessi definiti per quel ruolo.
graph LR
U1["Silvia"] --> R1["Ruolo: HR-staff"]
U2["Marco"] --> R1
U3["Anna"] --> R2["Ruolo: HR-manager"]
R1 -->|"legge"| P1["Contratti"]
R1 -->|"legge"| P2["Presenze"]
R2 -->|"legge + modifica"| P1
R2 -->|"legge"| P3["Stipendi"]
R3["Ruolo: Finance"] -->|"legge + modifica"| P3
Pro: scalabile - aggiungi un dipendente al ruolo giusto e ha subito i permessi corretti. Revoca l'accesso rimuovendo dal ruolo, non modificando decine di ACL. Principio di least privilege facile da applicare per categoria.
Contro: non gestisce bene i casi edge - "Marco può accedere ai contratti solo quando lavora in sede" non è esprimibile con RBAC puro.
Quando usarlo: quasi sempre, in qualsiasi organizzazione strutturata. È il modello di default per Active Directory, AWS IAM, sistemi HR, ERP. Il caso di Silvia avrebbe richiesto RBAC corretto: ruolo HR-staff con accesso a contratti e presenze, ma non a stipendi (riservato a HR-manager e Finance).
Rule-Based Access Control#
Non va confuso con RBAC. Qui l'accesso è governato da regole condizionali - IF/THEN basate su attributi del contesto: orario, indirizzo IP, tipo di dispositivo, giorno della settimana.
| Regola | Condizione | Azione |
|---|---|---|
| Accesso VPN | IP esterno + orario lavorativo | Permetti |
| Accesso admin DB | Solo da IP del jump server | Permetti |
| Accesso file stipendi | Fuori dall'orario lavorativo | Nega |
| Download dati clienti | Da dispositivo non aziendale | Nega |
Dove si usa: firewall (ACL), sistemi di controllo accessi fisici (badge solo nelle ore lavorative), network access control (NAC). Spesso combinato con RBAC - il ruolo definisce cosa puoi fare, le regole definiscono quando e da dove puoi farlo.
ABAC - Attribute-Based Access Control#
Il più granulare. Valuta contemporaneamente tre categorie di attributi:
- Attributi dell'utente - ruolo, reparto, livello di clearance, posizione geografica
- Attributi della risorsa - tipo di documento, livello di classificazione, proprietario
- Attributi del contesto - orario, dispositivo usato, posizione di rete
Una policy ABAC può essere: "un utente con ruolo=manager e reparto=HR può leggere documenti con tipo=contratto e livello=confidenziale solo se orario=9-18 e dispositivo=aziendale."
Pro: espressività massima - si può modellare qualsiasi scenario. Nessun caso edge irrisolvibile. Contro: complessità alta, difficile da auditare ("perché Marco non riesce ad accedere a quel file?"), richiede un policy engine dedicato. Errori nelle policy sono difficili da diagnosticare.
Dove si usa: cloud (AWS IAM con condition keys, Azure ABAC), sistemi zero trust, ambienti enterprise con requisiti di compliance granulari.
Quale usare quando#
| Scenario | Modello consigliato | Perché |
|---|---|---|
| Startup 10 persone, Google Drive | DAC | Semplicità, nessun dato critico |
| Azienda 200 dipendenti, AD | RBAC | Scalabile, gestibile, least privilege per reparto |
| Accesso solo in orario lavorativo | Rule-based | Condizione temporale - RBAC non basta |
| Cloud con requisiti compliance | ABAC | Granularità su attributi risorsa + contesto |
| Ambiente militare/governativo | MAC | Vincoli imposti dal sistema, non dall'utente |
| Azienda reale con casi edge | RBAC + Rule-based | Il 90% dei casi si copre con la combinazione |
exit 0#
Silvia non aveva fatto niente di sbagliato. Aveva aperto una cartella che il sistema le aveva lasciato aprire.
Il problema non era la password, non era un attaccante, non era un exploit. Era una scelta architetturale: DAC applicato a dati che avrebbero richiesto RBAC. Il proprietario aveva i permessi per sbagliare, e li aveva usati.
I modelli di autorizzazione non sono dettagli di configurazione - sono la struttura che decide cosa può andare storto anche quando tutto funziona correttamente.
Concetti correlati: iam
