L'autorizzazione definisce cosa può fare un utente autenticato. Mentre l'autenticazione conferma l'identità, l'autorizzazione controlla l'accesso alle risorse e alle azioni. Questa guida presenta modelli, implementazioni e best practice per creare solidi sistemi di autorizzazioni.
Autenticazione e autorizzazione
Autenticazione
Risposta: "Chi sei?" Verifica l'identità tramite credenziali.
Autorizzazione
Risposta: "Cosa puoi fare?". Determina le autorizzazioni dopo la conferma dell'identità.
Esempio pratico
L'utente accede (autenticazione). Il sistema verifica se è possibile accedere al pannello di amministrazione (autorizzazione).
Perché l'autorizzazione è importante
Senza un adeguato controllo degli accessi, qualsiasi utente autenticato può accedere a qualsiasi risorsa. I dati sensibili vengono esposti e le azioni distruttive diventano disponibili. L'autorizzazione protegge i dati e le operazioni critici.
Modelli di controllo degli accessi
ACL (elenco di controllo degli accessi)
Elenco che definisce chi può accedere a ciascuna risorsa. Semplice, ma non si adatta bene a sistemi complessi.
RBAC (controllo degli accessi basato sui ruoli)
Autorizzazioni assegnate ai ruoli, ruoli assegnati agli utenti. Struttura gerarchica. Modello più comune.
ABAC (controllo dell'accesso basato sugli attributi)
Decisioni basate su attributi: utente, risorsa, ambiente. Flessibile ma complesso.
ReBAC (controllo degli accessi basato sulle relazioni)
Basato sulle relazioni tra entità. "Puoi modificarlo se lo possiedi." Utilizzato da Zanzibar (Google).
RBAC nei dettagli
Componenti
- Utenti: persone o sistemi che accedono.
- Ruoli: Set di autorizzazioni (amministratore, editor, visualizzatore).
- Autorizzazioni: Azioni consentite (crea, leggi, aggiorna, elimina).
- Caratteristiche: Oggetti protetti (post, utenti, impostazioni).
Gerarchia dei ruoli
I ruoli possono ereditare da altri. L'amministratore eredita dall'editor, che a sua volta eredita dal visualizzatore. Riduce la duplicazione.
Esempio di struttura
| Scorri | Autorizzazioni | Ambito |
|---|---|---|
| Amministratore | crea, leggi, aggiorna, elimina | Tutte le risorse |
| Redattore | creare, leggere, aggiornare | Contenuto |
| Visualizzatore | leggere | Contenuti pubblici |
Implementazione RBAC
Banca dati
Tabelle per utenti, ruoli, autorizzazioni e relazioni (user_roles, role_permissions).
Middleware di verifica
Prima dell'azione, il middleware controlla se l'utente ha richiesto l'autorizzazione.
Decoratori/Guardie
Nei framework moderni, annotazioni che proteggono percorsi o metodi.
Memorizzazione dei permessi nella cache
Evitare di consultare la banca per ogni richiesta. Memorizza nella cache le autorizzazioni utente in Token o Redis.
ABAC: Flessibilità Avanzata
Quando usarlo
Quando RBAC non è abbastanza espressivo. Le regole dipendono dal contesto dinamico.
Esempi di politiche
- Puoi modificare se sei l'autore del documento.
- Puoi accedervi se appartieni allo stesso dipartimento.
- Puoi approvare se l'importo è inferiore al limite.
###XACML
Standard per esprimere le politiche ABAC. Basato su XML, utilizzato in ambienti aziendali.
Autorizzazioni a livello di risorsa
Sicurezza a livello di riga
Controllo tramite registro. L'utente vede solo i propri dati. PostgreSQL è supportato nativamente.
Sicurezza a livello di colonna
Controllo sul campo. Alcuni campi sono visibili solo a determinati ruoli.
Multi-locazione
Isolamento tra inquilini. Ogni organizzazione accede solo ai propri dati.
Autorizzazioni del sistema operativo
###iOS
L'accesso alla fotocamera, alla posizione e alle foto richiede l'autorizzazione esplicita da parte dell'utente. Info.plist definisce le descrizioni.
###Android
Autorizzazioni dichiarate nel Manifesto. Le autorizzazioni pericolose richiedono il consenso del runtime.
Buone pratiche
- Ordine al momento dell'utilizzo, non anticipato.
- Spiega perché ne hai bisogno.
- Corri con garbo se negato.
Token e rivendicazioni
Affermazioni JWT
Il token può contenere richieste di autorizzazione. Il server convalida senza consultare la banca.
Ambiti in OAuth
Definiscono a quali risorse può accedere il token. leggi:utenti, scrivi:post.
Cura
I token di grandi dimensioni influiscono sulle prestazioni. Bilancia i reclami in linea e la consultazione.
Autorizzazione nelle API
Verifica per endpoint
Ogni endpoint controlla l'autorizzazione specifica prima dell'esecuzione.
Server di risorse
Il server API convalida i token e autorizza in base ad ambiti e attestazioni.
Punto decisionale politico (PDP)
Servizio centralizzato che decide le autorizzazioni. Un esempio è Open Policy Agent (OPA).
Modelli di implementazione
Nega per impostazione predefinita
Negare l'accesso a meno che non sia esplicitamente consentito. A prova di errore.
Privilegio minimo
Concedere il minimo necessario. L'utente può solo ciò di cui ha bisogno.
Separazione dei compiti
Le attività critiche richiedono più persone. Nessuno fa tutto da solo.
Controllo e registrazione
Registrare le decisioni
Registro di chi ha tentato di accedere a cosa e se è stato consentito o negato.
Rilevamento anomalie
Modelli sospetti: molti rifiuti, accesso fuori orario, aumento dei privilegi.
Conformità
Le normative richiedono una pista di controllo. GDPR, SOX, HIPAA.
Errori comuni
Verifica solo sul frontend
Il backend dovrebbe sempre controllare. Il frontend è manipolabile.
Ruoli codificati
Rende difficile l’evoluzione. Utilizzare la configurazione flessibile.
Autorizzazioni eccessive
Per comodità, concedere più accessi del necessario. Principio del privilegio minimo.
Mancanza di test
Autorizzazioni scarsamente testate creano scappatoie. Testare gli scenari di accesso.
Strumenti e librerie
Cascina
Libreria di autorizzazione con supporto per più modelli (RBAC, ABAC, ACL).
Agente policy aperta (OPA)
Motore politico. Le decisioni di autorizzazione come codice.
Aut0 FGA
Autorizzazione a grana fine. Modello simile a Zanzibar di Google.
Ory Keto
Implementazione open source ispirata a Zanzibar.
Multi-tenancy e autorizzazione
Isolamento
Gli inquilini non accedono ai dati degli altri. Controllo di tutte le query.
Ruoli per inquilino
L'utente può avere ruoli diversi in diverse organizzazioni.
Super amministratore
Accesso multi-tenant per le operazioni della piattaforma. Utilizzare con estrema cautela.
Conclusione
Un'autorizzazione ben implementata protegge i dati e garantisce che gli utenti facciano solo ciò che sono tenuti a fare. Scegli il modello adatto (RBAC per la maggior parte), implementa con Nega per impostazione predefinita, esegui test approfonditi e controlla l'accesso. La sicurezza è un processo continuo, non una configurazione una tantum.
##Domande frequenti
1) Il RBAC è sufficiente nella maggior parte dei casi? Sì. RBAC funziona bene con la maggior parte delle applicazioni. ABAC è per scenari più complessi.
2) Dove archiviare i permessi? Database per la fonte della verità. Cache (attestazioni JWT, Redis) per le prestazioni.
3) Come gestire un'autorizzazione negata? Restituisce 403 Vietato con messaggio generico. Non rivelare i dettagli della polizza.
4) Ho bisogno di un servizio di autorizzazione separato? Per i sistemi di grandi dimensioni, potrebbe valerne la pena. Per le app più piccole è sufficiente la libreria integrata.
5) Come testare l'autorizzazione? Test automatizzati che controllano gli accessi consentiti e negati in base al ruolo/autorizzazione.
Leggi anche
- Autorizzazione e permessi - Fondamenti di buone pratiche
- Autorizzazione e permessi: buone pratiche che impediscono l'accesso non autorizzato
- Autenticazione dell'applicazione: Guida completa alla sicurezza e all'UX
- Introduzione a Deno: Guida pratica per lo sviluppo moderno
- Sicurezza cloud nativa: protezione delle infrastrutture Kubernetes
- Azioni del server in Next.js: mutazioni senza mantenere un'API solo per quello
