Autorizzazione e permessi: best practice che impediscono l'accesso non autorizzato

La maggior parte delle persone confonde autenticazione con autorizzazione, e questa confusione è costosa. L'autenticazione dimostra chi sei, login, password, token, dati biometrici. Autorizzare è decidere cosa tu, già individuato, hai il diritto di fare. Si tratta di problemi diversi e il secondo è il luogo in cui si concentra la maggior parte delle fughe di notizie interne e delle frodi.

È comune vedere sistemi con accesso impeccabile e autorizzazione lassista. La porta d'ingresso ha una serratura biometrica, ma una volta dentro chiunque può aprire qualsiasi cassetto. L'aggressore non ha bisogno di violare la tua autenticazione se, dopo aver effettuato l'accesso con un account normale, può accedere a dati a cui non dovrebbe.

Questo testo riunisce i passaggi essenziali e le migliori pratiche di autorizzazione. L'obiettivo è pratico: garantire che ogni utente, sistema o servizio acceda esattamente a ciò di cui ha bisogno, né più né meno.

Il principio che sta alla base di tutto: il minimo privilegio

Se prendi solo un'idea da questo testo, prendi questa: dare a ogni utente l'accesso minimo necessario per svolgere il proprio lavoro, e niente di più. È il principio del privilegio minimo e risolve, in pratica, la maggior parte dei problemi di autorizzazione.

Forte è la tentazione opposta. È più facile dare ampio accesso “per non fermare nessuno” e affrontarne le conseguenze in un secondo momento. Ma ogni permesso aggiuntivo è una porta in più. Quando un account viene compromesso, il danno è proporzionale a ciò che potrebbe fare quell'account. Conti con troppo potere trasformano un piccolo incidente in una catastrofe.

Il privilegio minore non è la sfiducia nelle persone. Significa riconoscere che gli account sono compromessi, che si verificano errori e che il danno deve essere contenuto in fase di progettazione.

Passaggio 1: modella i ruoli prima di distribuire le autorizzazioni

La distribuzione dei permessi utente per utente non è scalabile e diventa un disastro in breve tempo. Una pratica matura è quella di organizzare l'accesso per ruoli, il modello noto come RBAC (controllo degli accessi basato sui ruoli).

Invece di dire "Giovanni può vedere i resoconti finanziari", definisci il ruolo di "analista finanziario" con una serie di autorizzazioni e assegna quel ruolo a Giovanni. Quando John se ne va e Mary si unisce, basta scambiare chi occupa il ruolo. Le autorizzazioni sono descritte in un unico posto, verificabile e coerente.

Per scenari più complessi, esiste il controllo basato sugli attributi (ABAC), in cui la decisione considera contesto, tempo, posizione, sensibilità dei dati. Ma inizia in modo semplice. Un RBAC ben fatto risolve la stragrande maggioranza dei casi e la complessità prematura in questo caso genera solo errori.

Passaggio 2: centralizzare la decisione di autorizzazione

Un errore architetturale comune è quello di sparpagliare le regole di autorizzazione in tutto il codice, un "se" qui, un controllo là. Nel corso del tempo, nessuno sa con certezza chi può fare cosa e le regole differiscono tra le parti del sistema.

Una buona pratica consiste nel considerare l'autorizzazione come una responsabilità centrale, con un punto chiaro in cui vengono prese le decisioni. Non importa se si tratta di una libreria, di un servizio o di un modulo, l'importante è che la domanda "può farlo questo utente?" ricevere risposte coerenti, in un luogo che può essere verificato e modificato.

Ciò semplifica anche la vita quando si tratta di dimostrare la conformità. Quando un revisore dei conti, o la stessa LGPD, nel caso dei dati personali, chiede chi ha accesso a cosa, è possibile rispondere cercando in un unico posto, non cercando nell’intero codice.

Passaggio 3: non fidarti mai di ciò che dice il cliente

Ecco uno dei difetti più pericolosi e comuni. Il frontend nasconde un pulsante che l'utente non dovrebbe vedere e il team considera il problema risolto. Non lo è. Nascondere il pulsante è esperienza, non sicurezza.

L'autorizzazione deve essere controllata nel backend, ad ogni richiesta, ogni volta. Un utente malintenzionato non utilizza la tua interfaccia, chiama direttamente l'API. Se l’unica barriera è visiva, non esiste barriera. La regola è semplice e non negoziabile: il cliente può suggerire, il server decide.

Lo stesso vale per gli identificatori. Se il sistema consente all'utente di accedere a una risorsa semplicemente modificando il numero nell'URL, senza verificare se quella risorsa gli appartiene, si ha una delle vulnerabilità più sfruttate esistenti, l'accesso improprio a un oggetto tramite riferimento diretto, catalogato da anni da OWASP. Controlla il possesso, non solo l'esistenza.

Passaggio 4: rendi l'accesso revocabile e verificabile

L’accesso concesso deve poter essere tolto, e velocemente. Quando qualcuno lascia l'organizzazione, cambia ruolo o il suo account viene compromesso, è necessario interrompere l'accesso immediatamente, non nello sprint successivo.

Ciò presuppone due cose. In primo luogo, sapere chi ha accesso a cosa, il che risale al punto di centralizzazione e modellazione dei ruoli. In secondo luogo, registrare chi ha avuto accesso a cosa e quando. La registrazione degli accessi non previene il problema, ma è ciò che consente di indagare, rispondere e apprendere dopo un incidente. Un sistema senza traccia di controllo è un sistema che non sa cosa gli è successo.

Riflessione critica: il silenzioso accumulo di privilegi

C’è un problema che cresce senza che nessuno se ne accorga: l’accumulo di permessi nel tempo. La persona cambia area, ottiene nuovi accessi e mantiene quelli vecchi. Anni dopo, accumula permessi da tre ruoli che ricopriva una volta. Nessuno l'ha recensito, perché recensire è un lavoro e non ti dà un trofeo.

Questo accumulo è una bomba a orologeria. Quando uno di questi account viene compromesso, l'accesso è sproporzionato. La difesa è scomoda ma necessaria: revisione periodica degli accessi. Guarda di tanto in tanto e chiedi "questa persona ne ha ancora bisogno?" Quasi sempre la risposta, per alcuni permessi, è no.

L’altra sfida è culturale. L'autorizzazione restrittiva genera attriti, e gli attriti generano reclami. L’utente vuole un accesso ampio, il manager vuole agilità e la sicurezza diventa il cattivo che ferma tutti. Sostenere il minimo privilegio richiede la convinzione della leadership e la consapevolezza che gli attriti di oggi sono più economici delle fughe di notizie di domani.

Ciò che resta

L'autorizzazione fatta bene è invisibile quando funziona e devastante quando fallisce. Non appare in una dimostrazione di prodotto, non impressiona in una riunione, eppure è una delle decisioni più consequenziali di qualsiasi sistema che si occupi di dati sensibili.

I passaggi sono chiari: privilegio minimo come principio, ruoli invece di autorizzazioni vaghe, processo decisionale centralizzato, verifica lato server e accesso revocabile e verificabile. Nessuno di loro è sofisticato. Tutti vengono spesso ignorati.

Se la tua organizzazione gestisce dati sensibili e non sei sicuro di chi possa accedere a cosa, ora è il momento giusto per esaminarli. Sul blog sono presenti altri testi su sicurezza, controllo accessi e compliance che approfondiscono l'argomento.