L'autenticazione

01In una frase #sec_ae957ae4

REVIEWIT è la propria autorità di autenticazione: il cliente conserva il proprio fornitore di identità e il prodotto si riserva di decidere ciò che accetta come prova di identità e con quale livello di garanzia.

02Il problema #sec_a55cce9c

Uno strumento di ricertificazione afferma, campagna dopo campagna, che una determinata persona ha deciso una determinata cosa. Tutto il valore probatorio si basa quindi su una domanda preliminare:

Cosa garantisce che fosse proprio lei?

Tre difficoltà si accumulano e non sono della stessa natura.

Il cliente ha già il proprio fornitore di identità. Non lo cambierà per uno strumento e non è possibile chiedergli di creare password aggiuntive. Uno strumento deve appoggiarsi a un elenco aziendale, a un fornitore cloud, a volte a più a seconda delle entità, non sostituirlo.

Appoggiarsi a un unico fornitore limita il prodotto. Un software che sa autenticarsi solo contro un unico ecosistema è inutilizzabile per chi non ne fa parte e diventa ostaggio delle evoluzioni di quel fornitore.

Non tutte le autenticazioni si equivalgono. Aprire la fila di lavoro di un revisore e modificare i parametri di governance di un'entità non dovrebbero richiedere la stessa prova. Bisogna comunque sapere, al momento della decisione di accesso, come la persona si è autenticata, informazione che le applicazioni quasi mai possiedono.

03La scelta #sec_d821c25a

Il prodotto delega la verifica dell'identità, mai la decisione di ciò che accetta.

REVIEWIT introduce un'autorità di autenticazione interna. Le applicazioni non parlano più a un fornitore di identità: parlano a questa autorità, in un linguaggio standard. L'autorità, a sua volta, si occupa di verificare l'identità presso il fornitore del cliente, qualunque esso sia.

Il guadagno è doppio. Il cliente conserva il proprio elenco, le proprie regole, la propria politica di autenticazione. E il prodotto guadagna un luogo unico in cui ragionare su ciò che accetta, invece di lasciarlo a quattro applicazioni che lo farebbero ciascuna a modo suo.

Sei principi strutturano questa scelta. Sono loro che fanno la differenza tra « funziona » e « regge davanti a un audit ».

1. La prova fa fede, mai la richiesta

È il principio più importante e più controintuitivo.

Un'applicazione può chiedere al fornitore di identità un'autenticazione forte. Ma questa richiesta è solo una richiesta: a seconda del fornitore, della sua configurazione, dello stato della sessione o della politica in vigore, può essere parzialmente onorata, ignorata o silenziosamente aggirata.

REVIEWIT non si fida quindi mai di ciò che ha chiesto. Verifica ciò che ritorna e, se la prova attesa non è presente, l'accesso viene rifiutato. Richiedere è uno sforzo di buona volontà; verificare è la garanzia.

È ciò che separa una politica di sicurezza dichiarata da una politica di sicurezza effettiva.

2. Il livello di garanzia, non il meccanismo

Le applicazioni non ragionano mai su « la persona ha utilizzato tale dispositivo ». Ragionano su un livello di garanzia ordinato:

Una schermata richiede un livello minimo; il meccanismo che l'ha prodotto non lo guarda. Il vantaggio è duraturo: quando appare un nuovo mezzo di autenticazione, basta sapere a quale livello corrisponde, nessuna applicazione deve essere modificata.

Il prodotto conserva anche il momento dell'autenticazione, il che permette di richiedere un'autenticazione recente per un gesto sensibile, e non solo un'autenticazione valida. Questa informazione non viene mai ricostituita per approssimazione: se manca, la regola di freschezza fallisce piuttosto che lasciare passare.

3. Mai un abbinamento automatico tramite indirizzo e-mail

Quando si presenta un'identità sconosciuta, la tentazione è di collegarla a un conto esistente con lo stesso indirizzo. REVIEWIT non lo fa mai.

L'indirizzo e-mail non è una prova di identità: è dichiarativo, riassegnabile e falsificabile presso un fornitore mal configurato. Un abbinamento automatico su questo criterio è un vettore classico di presa di controllo del conto: basta far emettere un'identità con il giusto indirizzo per ereditare i diritti di qualcun altro.

Il collegamento tra un'identità esterna e un conto REVIEWIT è quindi stabilito su un tripletto stabile - il fornitore, l'emittente, l'identificatore del soggetto - e un collegamento tra più fornitori rientra in un flusso controllato ed esplicito, mai in una deduzione.

4. Il conto REVIEWIT è l'autorità di sessione

Un'autenticazione riuscita presso il fornitore del cliente non è sufficiente per aprire una sessione.

Il prodotto tiene il proprio registro dei conti e questo registro decide: a un conto disattivato da parte di REVIEWIT viene rifiutato l'accesso anche se il fornitore di identità lo ha appena autenticato con successo. I due cicli di vita sono separati: revocare un collegamento di identità non è disattivare un conto e viceversa.

Questa verifica viene riprodotta a ogni emissione di accesso, anche durante le riconnessioni silenziose consentite dalla sessione unica. È proprio il caso in cui si potrebbe credere che non ci sia « nulla da ricontrollare » e è il caso in cui una disattivazione rimarrebbe altrimenti senza effetto per ore.

5. Identità e contesto non si confondono

L'autorità di autenticazione stabilisce chi sei. Non decide mai a cosa hai diritto, né a quale sottoscrizione o workspace appartieni.

Quando viene trasmesso un contesto, lo è come un indice firmato - utile per evitare all'utente di riseleczionare il proprio perimetro - e mai come una prova di appartenenza. L'applicazione ricontrolla sistematicamente i diritti come se questo indice non esistesse.

Confondere i due è l'errore che produce le elevazioni di privilegi più discrete: un token che afferma un perimetro finisce sempre per essere creduto.

6. I segreti non sono nel database

Il database contiene il riferimento a un segreto, mai il suo valore. I segreti vivono in un negozio dedicato, con un meccanismo di rotazione a doppia versione: il nuovo segreto diventa attivo mentre il vecchio rimane accettato per il tempo del passaggio, poi viene revocato.

Lo stesso ragionamento vale per le chiavi: quelle che firmano i token destinati agli umani sono distinte da quelle destinate alle macchine, con mittenti e destinatari espliciti. Un token emesso per un'applicazione non è mai accettabile là dove se ne aspetta un altro: i meccanismi sono condivisi, mai i segreti.

04Due autorità, deliberatamente separate #sec_dd4e68e8

Questi due mondi hanno minacce, cicli di vita ed esigenze diversi. Farli coesistere nella stessa autorità porterebbe prima o poi a un token progettato per l'uno ad essere accettato dall'altro. Vedere il [dossier API](REVIEWIT_Dossier_API_v1.0.md).

05Il fornitore di identità del cliente #sec_9c97a8ca

Ogni sottoscrizione dichiara il suo fornitore di identità. L'instradamento avviene sul dominio dell'indirizzo professionale: l'utente inserisce il suo indirizzo e viene inviato al fornitore che lo riguarda.

I fornitori conformi agli standard moderni sono supportati nativamente, il che copre la maggior parte del parco, compresi gli annuari aziendali auto-ospitati nelle loro versioni recenti. I protocolli più vecchi vengono trattati tramite adattatore, in un secondo momento.

Un punto di progettazione merita di essere segnalato: la connessione degli utenti e la raccolta dei dati sono due percorsi distinti. Le autorizzazioni di cui il prodotto ha bisogno per inventariare le risorse di un cliente non transitano mai attraverso il percorso di connessione. Un utente che si connette non concede nient'altro che la sua identità — e una modifica della configurazione di raccolta non può interrompere l'autenticazione.

06Gli accessi di emergenza #sec_5e779c5b

Il prodotto prevede conti di emergenza, per il caso in cui il fornitore di identità del cliente fosse indisponibile.

Due salvaguardie: questi conti sono esplicitamente designati, uno per uno — non esiste una regola del tipo « tutti gli amministratori possono connettersi in altro modo » — e il loro utilizzo è oggetto di una registrazione rafforzata nella [pista di audit](REVIEWIT_Dossier_PisteAudit_v1.0.md).

Un accesso di emergenza è un'eccezione assunta, non una porta nascosta permanente.

07Una scelta assunta: la sostituzione in bianco #sec_50dd8f34

Il vecchio dispositivo di autenticazione non viene migrato, viene sostituito. Nessun doppio percorso, nessun periodo in cui i due coesistono.

La ragione è di sicurezza, non di comfort. Mantenere due percorsi di autenticazione significa mantenere due superfici di attacco, due set di segreti e l'obbligo permanente di verificare che il più debole dei due non possa essere utilizzato per aggirare l'altro. Le vecchie registrazioni applicative vengono dismesse e i loro segreti revocati.

È lo stesso ragionamento della [pista di audit](REVIEWIT_Dossier_PisteAudit_v1.0.md): meglio una base corta e netta che una base lunga di cui non si può affermare nulla.

08Cosa il prodotto non fa #sec_c39b58a6

• Non gestisce le password. REVIEWIT non ne memorizza alcuna, non ne verifica alcuna e non ne fa scadere alcuna. Questo è il compito del fornitore di identità del cliente.
• Non implementa il proprio multifattore. Il rafforzamento dell'autenticazione si basa sui dispositivi del cliente. Ciò che il prodotto offre è la capacità di richiedere e verificare un livello dato — non di fornirlo.
• Non decide i diritti. L'autenticazione stabilisce l'identità; le autorizzazioni sono portate dal workspace e dalla sottoscrizione.
• Non si fida di una dichiarazione. Né l'indirizzo e-mail, né un contesto annunciato, né una richiesta di autenticazione forte valgono come prova.

09Da ricordare #sec_5948ea3f

L'autenticazione è la fondazione su cui tutto il resto poggia: senza di essa, « Marie ha certificato questo accesso il 14 marzo » è un'affermazione inverificabile.

REVIEWIT si basa sull'identità che il cliente già controlla, ma mantiene il controllo su ciò che accetta. Verifica le prove invece di fidarsi delle richieste, ragiona in livelli di assicurazione piuttosto che in meccanismi, rifiuta le comode coincidenze che portano alle prese di controllo e si riserva l'ultima parola sull'apertura di una sessione.

Questo permette di affermare non solo che una decisione è stata presa, ma da chi, e con quale grado di certezza.