Il modello di autorizzazione
01L'identità non decide i diritti #sec_877062d8
Il fornitore di identità — Entra ID, Okta, Google, ADFS o un altro IdP — risponde a una domanda: chi si è appena autenticato e con quale livello di sicurezza? REVIEWIT risponde alle seguenti domande: cosa può fare questa persona, in quale ambito e fino a quando?
Questa separazione impedisce a un amministratore di directory cliente di assegnarsi un ruolo interno alla piattaforma. I gruppi o i ruoli inviati da un IdP non diventano automaticamente autorizzazioni REVIEWIT. Possono contribuire all'identificazione, ma la decisione di accesso rimane portata, amministrata, auditata e revocata in REVIEWIT.
L'identificatore pivot è stabile e indipendente dall'indirizzo di posta o dal nome visualizzato. Un cambiamento di IdP, nome o organizzazione non deve né ricreare i diritti né rendere illogico la cronologia.
02Tre ambiti chiusi #sec_5953283d
Il modello distingue tre livelli che non si confondono mai.
La piattaforma. Il ruolo di Operatore di Piattaforma è riservato all'editore. Permette di sfruttare il servizio, senza dare alcun diritto sui dati di un cliente al di là delle operazioni esplicitamente previste.
La sottoscrizione. L'Amministratore di Sottoscrizione governa una sottoscrizione identificata dal suo identificatore pubblico: parametri comuni, workspace, ruoli e capacità sottoscritte. Il suo potere non si estende alle altre sottoscrizioni.
Il workspace. I ruoli di Manager, Reader, Reporting Reader e Auditor si esercitano su un workspace preciso. Sono risolti dalla base nel momento in cui l'applicazione ne ha bisogno, in modo da riflettere una revoca o una scadenza senza trasportare tutti i diritti in una sessione lunga.
Questa tassonomia è chiusa per costruzione. Aggiungere un ruolo di piattaforma o di sottoscrizione non è una semplice operazione di configurazione: è una decisione di modello che deve definire il suo ambito, la sua amministrazione e il suo impatto di audit.
Nessun ruolo di amministrazione conferisce il diritto di prendere una decisione di revisione. Il ruolo di Review Manager e le assegnazioni di campagna rispondono a un modello di business distinto. Amministrare il contenitore non significa decidere al posto del revisore.
03Il contesto è risolto lato server #sec_f2e08188
Una richiesta client non può imporre la propria sottoscrizione o il proprio workspace. L'applicazione risolve il contesto autorizzato lato server, a partire dall'identità e dalle appartenenze attive. Un identificatore fornito in un URL o in un modulo rimane una destinazione richiesta, mai una prova di autorizzazione.
I diritti sono versionati. Quando un ruolo viene assegnato, sospeso, revocato o scaduto, una versione di autorizzazione evolve. Le sessioni e le applicazioni possono quindi rilevare che le loro informazioni non sono più attuali e rivalutare i diritti effettivi.
Ogni appartenenza possiede uno stato, una data di concessione, un autore, un motivo e una scadenza. Una sospensione temporanea si distingue da una revoca definitiva. Il modello rende quindi visibili sia il diritto corrente che il suo ciclo di vita.
La gestione dell'« ultimo amministratore » applica una protezione fail-closed: una sottoscrizione non può ritrovarsi senza responsabile attivo a causa di una cancellazione concorrente o di una scadenza mal preparata. La regola riguarda i diritti realmente effettivi, non solo il numero di righe presenti.
04Bootstrap, elevazione e accesso di emergenza #sec_b168e1cb
Il primo amministratore di una sottoscrizione deve essere stabilito da una procedura esplicita e tracciabile. Questo bootstrap non è un collegamento permanente: una volta installata la governance, gli amministratori si gestiscono secondo le stesse regole delle altre appartenenze.
Le operazioni sensibili possono richiedere un'elevazione TrustGate, cioè un'autenticazione recente o più forte. L'elevazione conferma l'identità dell'attore nel momento critico; non gli inventa alcun ruolo. L'autorizzazione viene valutata prima e dopo l'elevazione.
Il break-glass è una postura di funzionamento eccezionale, non un ruolo client nascosto. È limitato nel tempo, motivato, monitorato e auditato. Non serve mai a aggirare silenziosamente il modello di autorizzazione di una sottoscrizione.
05Una revoca che si propaga e si dimostra #sec_812968cd
Ogni assegnazione, sospensione, scadenza e revoca produce un atto nella traccia di audit con il suo attore, il suo motivo e il suo ambito. Una modifica dei diritti non è solo un cambiamento di configurazione: è un evento di sicurezza.
La propagazione combina diversi meccanismi: versione dei ruoli, lettura delle appartenenze effettive e risoluzione nella base dei diritti di workspace. L'obiettivo non è quello di fidarsi di un cookie fino alla sua scadenza, ma di ridurre la finestra durante la quale una sessione potrebbe continuare a portare un'informazione diventata falsa.
Il ravvicinamento periodico verifica infine la completezza: i diritti dichiarati, le sessioni emesse e i conti attivi devono raccontare la stessa situazione. Una divergenza diventa un incidente visibile piuttosto che un permesso implicito.
06In sintesi #sec_e0f5ace1
Il modello di autorizzazione REVIEWIT si basa su una regola facile da ricordare: l'IdP prova l'identità; REVIEWIT possiede i diritti. Tre ambiti chiusi, un contesto risolto lato server, ruoli versionati e una tracciabilità sistematica impediscono ai privilegi di viaggiare più lontano o più a lungo del previsto.