Autorização
Permissões
Segurança
RBAC
ABAC
Controle de Acesso

Autorizzazione e permessi nelle applicazioni: controllo dell'accesso sicuro

Autorizzazione e permessi nelle applicazioni: controllo dell'accesso sicuro

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

ScorriAutorizzazioniAmbito
Amministratorecrea, leggi, aggiorna, eliminaTutte le risorse
Redattorecreare, leggere, aggiornareContenuto
VisualizzatoreleggereContenuti 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