L'identità autenticata non determina il permesso

Tipo

Concetto

L'autenticazione verifica l'identità dichiarata con le garanzie del meccanismo usato. L'autorizzazione risponde a una domanda diversa: questo soggetto può compiere questa azione su questa risorsa, nelle condizioni richieste? Un'identità autenticata non possiede automaticamente tutti i permessi dell'applicazione. [1] Il ruolo può contribuire alla decisione, ma non rappresenta da solo un perimetro che dipende anche dalla società o dal singolo ordine. Accedere alla funzione e poterla usare su un determinato oggetto sono controlli distinti. [2] Consideriamo un esempio ipotetico, non un incidente reale: un'operatrice entra con il Single Sign-On aziendale ed è responsabile del customer service. In questa azienda può disporre rimborsi fino a 500 euro soltanto sugli ordini della società italiana. Deve rimborsare 120 euro, ma l'ordine appartiene alla società francese: il login valido e l'importo contenuto non autorizzano l'operazione. Una nuova verifica dell'identità, da sola, non cambierebbe il perimetro. Supponiamo invece che l'ordine sia italiano, con 200 euro incassati e 150 già rimborsati. L'operatrice ha l'autorità necessaria, ma la richiesta supera i 50 euro residui. Nel nostro modello, il limite personale di 500 euro è una regola di autorizzazione; non restituire più dell'incassato è un vincolo del dominio. Entrambi devono essere rispettati: il secondo non scompare assegnando un ruolo più potente. Questa distinzione assegna responsabilità, non impone servizi separati. [4] La conseguenza architetturale è concreta: il modello informativo deve collegare operatrice, perimetro autorizzato e società dell'ordine. La review deve nominare chi mantiene questi fatti, chi valuta la regola e chi blocca il comando. Un gateway può applicare controlli generali, ma non si può presumere che conosca il contesto dell'ordine: le decisioni specifiche devono raggiungere un componente che possiede o recupera informazioni affidabili. Decisione della policy e applicazione del controllo sono responsabilità distinguibili anche dentro un monolite. [3] Nascondere il pulsante migliora l'interfaccia ma non sostituisce il controllo server su una richiesta diretta. [1] Nel caso proposto, un unico controllo sul ruolo costa poco ma non esprime il confine societario; aggiungere il confine richiede dati mantenuti e test. L'incremento minimo è rendere verificabile la regola nel percorso applicativo del rimborso, non introdurre subito una piattaforma di policy. Domanda da portare in review: dopo il login, quale componente sa che questa persona può rimborsare questo ordine, e quale componente lo impedisce quando non può? Fonti: [1] OWASP, Authorization Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html ; [2] OWASP, API1:2023 Broken Object Level Authorization — https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/ ; [3] OWASP, Microservices Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Microservices_Security_Cheat_Sheet.html ; [4] OWASP, Business Logic Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html