Mappare soggetto, azione, risorsa e punto di controllo

Tipo

Pratica

Usa questa pratica quando una review si chiude con «c'è il Single Sign-On» o «la pagina è riservata ai manager», senza chiarire chi possa agire sui singoli dati. Il risultato è una scheda per un'operazione concreta, non un inventario dei ruoli. La scheda proposta da Architecture Coffee applica al design i controlli per richiesta e per oggetto descritti da OWASP. [1][2] Compila questi campi: soggetto, azione, risorsa, condizioni di autorizzazione, fatti necessari con le rispettive fonti autorevoli, componente che decide e punto server che applica l'esito. Indica separatamente le invarianti del dominio e il comportamento quando mancano informazioni. Ecco una compilazione ipotetica, non una prescrizione universale. Soggetto: operatrice riconosciuta dalla sessione validata, responsabile del customer service per la società italiana. Azione: disporre un rimborso di 120 euro; leggere l'ordine non concede automaticamente questo permesso. Risorsa: lo specifico ordine, con la società di appartenenza verificata dal sistema. Condizioni: permesso di rimborso presente, ordine nel perimetro societario autorizzato e importo entro il limite personale di 500 euro. Fatti: la gestione degli accessi applicativi mantiene permessi, perimetri e limite personale; il modulo ordini mantiene la società dell'ordine. Decisione: una policy del modulo rimborsi combina quei fatti e valuta il permesso sul comando. Punto di controllo: il gestore server del comando applica la decisione prima di avviare il rimborso; ogni ingresso che esegue il comando deve attraversare il controllo. Invariante: il modulo rimborsi garantisce che il totale restituito non superi l'incassato. Informazioni mancanti: se il perimetro necessario non è verificabile, il rimborso non parte; l'incertezza produce un errore controllato, non un permesso. Questa divisione non richiede microservizi: decisione e controllo possono stare nella stessa applicazione. In un sistema distribuito rende visibili anche le dipendenze della valutazione; un controllo generale al gateway non sostituisce automaticamente quello specifico. [3] Società, identità e permessi non diventano affidabili soltanto perché il browser li trasmette: il server deve verificarli usando fonti attendibili. Il residuo rimborsabile va protetto anche dalla concorrenza fra richieste, non soltanto controllato prima della scrittura. [4] Trasforma la scheda in evidenze. Il test positivo usa un ordine italiano con almeno 120 euro residui e un'operatrice autorizzata. Nei test negativi cambia una condizione alla volta: stesso ruolo ma società sbagliata; ordine corretto ma permesso assente; importo oltre il limite personale; importo entro quel limite ma oltre il residuo. Nell'ultimo caso il diniego riguarda il dominio, non l'identità. Aggiungi una richiesta diretta all'API senza passare dal pulsante e una prova con la fonte dei permessi indisponibile. Per ogni diniego verifica che nessun rimborso sia avviato. Questi test non sostituiscono una valutazione di sicurezza più ampia. [1] La scheda costa allineamento tra chi definisce la regola, chi possiede i dati e chi implementa il comando, ma rende identificabili i vuoti. È completa quando un altro team sa quale fatto cambia la decisione, quale componente lo fornisce e quale test prova il blocco. Parti da una sola operazione sensibile; revoca, delega e workflow differiti richiedono approfondimenti separati. 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