Autenticazione, ruoli e permessi, a ogni livello.

Nessuno sbaglia il controllo di autorizzazione sull'endpoint principale di un'entità: è la prima cosa a cui si pensa e la prima che viene rivista.

Gli incidenti nascono altrove, e quasi sempre negli stessi posti: un'esportazione aggiunta in fretta, una funzione di ricerca globale scritta per il supporto interno e poi esposta, un report che aggrega dati saltando il filtro, un'interfaccia creata per un'integrazione e mai rivista con la stessa attenzione. Il codice funziona: fa quello che c'è scritto, e quello che c'è scritto è incompleto.

Quando i permessi sono dichiarati sul dominio invece che scritti nei percorsi, quei percorsi non hanno un modo per essere incompleti: attraversano lo stesso motore di autorizzazione delle schermate principali. Non è una garanzia contro ogni errore possibile — un permesso dichiarato male resta dichiarato male — ma sposta il rischio da "qualcuno ha dimenticato" a "qualcuno ha dichiarato la regola sbagliata", che è un errore molto più facile da trovare perché è scritto in un documento che si può leggere.

Chi può entrare. Autenticazione con token, politiche di blocco dopo tentativi falliti, gestione sicura delle credenziali, doppio fattore dove serve. È il livello che tutti implementano e quello che raramente è il punto debole.

Quali record può vedere. Le regole condizionali di appartenenza risolvono a runtime domande come "solo i propri", "solo quelli della propria organizzazione", "solo quelli in uno stato determinato". Questo è il livello che protegge dall'incidente più costoso, quello in cui un utente vede dati di qualcun altro.

Quali campi di quel record. La granularità sul singolo attributo, per ruolo e per operazione: un campo può essere visibile ma non modificabile, o invisibile del tutto a certi ruoli. È il livello che nei sistemi tradizionali si implementa schermata per schermata e che quindi diverge più facilmente.

La proprietà che conta è che tutti e tre valgano su ogni percorso: schermate, ricerche, esportazioni, interfacce esposte e piani compilati da un agente AI passano dallo stesso motore.

Un livello applicativo dichiarativo risolve la sicurezza dei dati e delle operazioni. Non risolve, e non deve pretendere di risolvere, tutto il resto.

• Sicurezza dell'infrastruttura: segmentazione di rete, protezione perimetrale, gestione degli accessi amministrativi e aggiornamenti del sistema operativo restano responsabilità di chi opera l'ambiente, con gli strumenti che già usa.
• Gestione dei segreti: le credenziali dei sistemi esterni vanno custodite con gli strumenti previsti dal vostro ambiente, non nei file di configurazione del dominio.
• Verifiche di sicurezza indipendenti: un test di penetrazione prima del passaggio in produzione è una buona pratica che nessuna proprietà architetturale sostituisce, ed è anche il modo più diretto per verificare le affermazioni di questa pagina.
• Adempimenti sulla protezione dei dati: la configurazione dichiarativa agevola registro dei trattamenti e valutazione d'impatto, ma gli adempimenti restano vostri in qualità di titolare.