Whitepaper di LayerT
Condividere l’accesso, non le password
La maggior parte delle aziende ha login usati da più persone: gli account social, il portale della banca, il servizio paghe, la console di amministrazione di uno strumento per cui nessuno ha configurato il single sign-on. Le loro password finiscono in un foglio di calcolo o in una chat. Chiunque abbia mai avuto bisogno dell’account le conosce. Quando qualcuno se ne va, qualcuno dovrebbe cambiarle tutte.
La risposta di LayerT è condividere l’accesso invece della password. Questo documento spiega come funziona, perché ogni passaggio è costruito in quel modo e dove si ferma l’approccio.
Il modello
In LayerT un account condiviso è composto da quattro parti.
- Un segreto sigillato. La password e, se il fornitore li usa, la chiave di configurazione dell’app di autenticazione ed eventuali campi di login segreti come un PIN, cifrati e archiviati da LayerT.
- Una policy. Chi può usarlo, se serve ogni volta un approvatore, se lo detiene una sola persona alla volta e quanto dura una sessione.
- Una procedura di login. Dove si trovano i campi di login sul sito del fornitore, rilevati automaticamente o registrati una volta dal proprietario dell’account. Non contiene mai un valore.
- Una traccia. Ogni richiesta, approvazione, login, proroga e logout, attribuiti a una persona.
Una persona non riceve mai l’account. Riceve una sessione: un permesso limitato nel tempo e registrato nel log di essere collegata, che LayerT esegue per lei.
Archiviazione sigillata
I segreti sono cifrati con la cifratura a busta (envelope encryption) AES-256-GCM. Ogni account condiviso ha la propria chiave dati casuale a 256 bit. Ogni segreto viene cifrato con essa, con un nonce casuale nuovo, e la chiave dati è a sua volta cifrata (“wrapped”) da una chiave di cifratura delle chiavi. Il database archivia solo testo cifrato, in una tabella dedicata, separata dalle impostazioni dell’account.
La modifica di una password cifra di nuovo i segreti dell’account con una chiave dati completamente nuova, e viene registrata nel log. L’eliminazione di un account ne elimina i segreti.
In produzione, la chiave di cifratura delle chiavi risiede nel servizio di gestione delle chiavi di Google Cloud, nell’UE, dove può essere usata ma non estratta, e ogni utilizzo viene registrato dal lato di Google. Questo è realizzato e si attiva con il primo deploy in produzione di LayerT. In fase di sviluppo al suo posto si usa una chiave locale.
Dalla richiesta alla sessione
- BrowserRichiesta o sceltaDall’icona di LayerT nel campo di login, oppure dal launcher della barra degli strumenti. Gli account con accesso in un clic saltano l’approvazione.
- Console o popupApprovazionePer la sensibilità media e alta. Nessuno approva la propria richiesta, e l’approvazione verifica di nuovo che il richiedente sia attivo e autorizzato.
- Cloud di LayerTApertura della sessioneLegata alla persona e al suo browser registrato, con un’ora di fine. Un solo titolare alla volta, se impostato.
- BrowserAccesso effettuatoLayerT compila il modulo del fornitore. Un chip indica che si tratta di una sessione LayerT e il tempo rimanente.
- BrowserFine della sessioneAlla scadenza, da parte di un amministratore o all’offboarding. LayerT fa uscire la persona dal sito.
Le richieste su cui nessuno decide scadono dopo 30 minuti. Se due approvatori decidono nello stesso momento, conta una sola decisione. Le sessioni durano un’ora di default e possono essere prorogate fino a otto ore in totale dall’approvazione.
L’autorizzazione
Il momento della verità è quando una password lascia l’archivio. LayerT decifra un segreto solo quando tutte queste condizioni sono vere:
- la sessione è attiva e non è scaduta,
- appartiene alla persona che la richiede e al browser che ha registrato,
- la persona è ancora attiva nella vostra directory e ancora autorizzata a usare l’account, e
- l’account non è stato disabilitato.
Solo allora il server decifra la password, in memoria, e la restituisce tramite HTTPS in un’autorizzazione per quella sessione. Ogni autorizzazione viene registrata nel log con la persona, l’account e il dispositivo. La password ed eventuali codici dell’app di autenticazione non compaiono mai nel log.
Compilare senza mostrare
L’autorizzazione va al service worker di LayerT, che la consegna alla pagina solo se la pagina è esattamente il sito dell’account: stesso schema, host e porta, tramite HTTPS, senza caratteri jolly. La verifica usa l’indirizzo che Chrome riporta per il frame richiedente, non ciò che la pagina dice di sé.
La compilazione avviene dal mondo isolato di Chrome, lo spazio separato in cui gli script delle estensioni girano accanto a una pagina. LayerT si rifiuta di compilare campi nascosti, trasparenti, fuori dallo schermo o di sola lettura, il che protegge dai campi esca. Una password viene inserita solo in un campo password.
Far accedere qualcuno non mostra mai la password: non compare nel launcher, nel menu, nelle notifiche o nel registro di audit. L’unico modo per vederla è una richiesta di password approvata da due persone (vedete Accesso di emergenza). Quando LayerT fa accedere qualcuno, non scrive la password nello storage del browser.
Per impedire che Chrome stesso proponga di salvare la password condivisa nel profilo di qualcuno, disattivate tramite policy il password manager integrato di Chrome. I modelli di deployment di LayerT includono questa impostazione.
Inviare il modulo, con cautela
Compilare non equivale a inviare. L’invio automatico è disattivato di default, e un proprietario può attivarlo solo dopo che l’account ha superato un login di prova. Anche in quel caso, LayerT invia il modulo solo quando:
- la persona ha scelto esplicitamente l’account,
- la pagina è esattamente il sito e il percorso previsti, nel frame principale,
- ogni campo compilato da LayerT è ancora visibile, e
- LayerT ha trovato il pulsante di invio senza doverlo indovinare.
Non invia mai il modulo al caricamento della pagina. Un CAPTCHA mette in pausa LayerT e passa la mano alla persona.
Codici dell’app di autenticazione
Molti account dei fornitori usano codici generati da un’app di autenticazione. LayerT conserva la chiave di configurazione sui propri server e genera lì i codici (RFC 6238). Solo il codice attuale a sei cifre viaggia verso il browser, quando serve, e viene compilato come una password. Se la compilazione non riesce, la persona che detiene la sessione può vedere il codice attuale nel popup di LayerT nella barra degli strumenti e copiarlo; le visualizzazioni vengono registrate nel log. Un codice trapelato scade in pochi secondi.
La chiave di configurazione stessa lascia il server solo tramite una richiesta di password, approvata da due persone e mostrata una sola volta.
Chiudere puntualmente
Un accesso che non finisce non è governance. LayerT chiude le sessioni in tre modi:
- Alla scadenza prevista. Un minuto prima della fine, la persona può prorogare o effettuare il logout. Alla fine, LayerT cancella i cookie del sito e lo storage del sito nella scheda.
- Da parte di un amministratore. Un Owner o un IT Admin può terminare una sessione attiva dalla console, indicando un motivo. Il server smette immediatamente di riconoscere la sessione, e il browser effettua il logout entro circa un minuto.
- All’offboarding. Quando la vostra directory disattiva qualcuno o lo rimuove da un gruppo, LayerT revoca ovunque le sue sessioni e le sue richieste.
Accesso di emergenza (break-glass)
A volte una persona ha davvero bisogno della password stessa, per esempio per comunicarla al team di supporto di un fornitore. LayerT lo rende volutamente difficile:
- Una richiesta di password può riguardare la password, la chiave di configurazione dell’app di autenticazione o un campo segreto. La persona fa la richiesta con una motivazione: Owner e IT Admin per qualsiasi account, chiunque altro solo per gli account che può usare o di cui è proprietario.
- Due persone approvano, nessuna delle quali è il richiedente, e una delle quali deve essere un Owner o un Compliance Officer. La richiesta può essere decisa solo nella console, mai da Slack o dal link di un’email.
- Il richiedente la vede una sola volta, entro un’ora dall’approvazione, dopo aver effettuato di nuovo il login se l’ultimo risale a più di 10 minuti prima. Una seconda visualizzazione viene rifiutata.
- Viene poi contrassegnata come vista. Owner, Compliance Officer e il proprietario dell’account vengono avvisati, e al proprietario viene chiesto di cambiarla presso il fornitore. Ogni passaggio viene registrato nel log; il valore mai.
- Per il disaster recovery, un’esportazione offline è cifrata e suddivisa tra due custodi, ciascuno con la propria passphrase. Nessuno dei due può aprirla da solo. La sua generazione viene registrata nel log.
Il confronto
| Foglio di calcolo condiviso | Condivisione tramite password manager | LayerT | |
|---|---|---|---|
| Le persone vedono la password | Sì | Di solito sì, e possono copiarla | No. LayerT la compila. Vederla richiede due approvazioni |
| Approvazione prima dell’uso | No | Raramente | Facoltativa, per account |
| Limite di tempo | No | No | Ogni sessione |
| Un solo titolare alla volta | No | No | Facoltativo |
| Chi l’ha usato, e quando | No | In parte | Ogni richiesta, approvazione e sessione |
| L’accesso termina all’offboarding | Solo se cambiate ogni password | Solo se rimuovete la condivisione e cambiate le password | Automaticamente, dalla vostra directory |
Limiti
- La persona autorizzata potrebbe leggere una password compilata con i DevTools, come descritto sopra.
- I moduli di login all’interno di un frame proveniente da un altro dei siti dell’account non hanno il menu nella pagina; scegliete l’account dal launcher della barra degli strumenti e LayerT compila il frame, senza invio automatico. I moduli disegnati su canvas non sono supportati.
- La rotazione automatica delle password non è realizzata.
- Vedere una password tramite una richiesta invia subito un avviso. Le esportazioni non inviano ancora avvisi Proposto; sono nel registro di audit.
Volete vederlo sui portali dei vostri fornitori? Richiedete una demo, e portate l’account condiviso più difficile che avete.