Identità, tenancy e ruoli

La vostra directory è la fonte di verità

LayerT gestisce un server SCIM 2.0. Il vostro identity provider vi invia persone e gruppi e li mantiene aggiornati.

• Utenti e gruppi: creazione, lettura, sostituzione, aggiornamento ed eliminazione, con gli endpoint di discovery standard.
• Il filtraggio supporta eq e and, cioè ciò che gli identity provider usano per il provisioning.
• Il token SCIM è emesso da LayerT. Viene mostrato una sola volta e archiviato solo come hash. Quando lo ruotate, il vecchio token continua a funzionare per 24 ore, così il provisioning non si interrompe.
• I ruoli derivano dai gruppi della directory che mappate nella console. Chi non ha alcuna mappatura riceve Read-only. Quando si applicano più mappature, prevale quella con più privilegi.

LayerT è realizzato per JumpCloud. Altri identity provider che supportano SCIM 2.0 e OpenID Connect, come Okta, Microsoft Entra ID e Google Workspace, potrebbero funzionare ma non sono ancora certificati.

Il login alla console

La console usa il flusso authorization code di OpenID Connect con il vostro identity provider:

• LayerT individua la vostra organizzazione dal dominio email, poi indirizza la persona al vostro identity provider con uno state e un nonce monouso.
• L’ID token restituito viene verificato rispetto alle chiavi pubblicate dal vostro provider: issuer, audience, scadenza e nonce.
• La persona deve già esistere in LayerT tramite SCIM. Nessuno viene creato al primo login, e le persone disattivate vengono rifiutate.
• La sessione della console risiede sul server e viene verificata a ogni richiesta, compreso il ruolo attuale della persona. La revoca ha effetto immediato, e una modifica al ruolo di qualcuno ne provoca il logout, così che il login successivo riporti il nuovo ruolo.

Le credenziali di ogni browser

Una persona configura un browser una volta: digita la propria email di lavoro ed effettua il login tramite il vostro identity provider. Non c’è alcun token da incollare, e il popup di LayerT propone Configurate questo browser in un browser che non è stato configurato. Le persone possono farlo da sole. Questo non sostituisce una distribuzione gestita: installare LayerT tramite policy del dispositivo resta il piano per i laptop gestiti.

Alla configurazione, il browser crea la propria chiave di firma. Invia a LayerT la metà pubblica e dimostra di possedere la metà privata. Da quel momento il browser custodisce due cose:

• Non esiste una credenziale di rinnovo di lunga durata. Una copia del solo token smette di funzionare entro pochi minuti, e per rinnovarlo serve la chiave.
• Una risposta di login intercettata è inutile senza la chiave, e una prova di rinnovo viene accettata una sola volta: una prova usata una seconda volta viene rifiutata.
• La revoca di un browser, o la disattivazione della sua persona, vi pone fine. Il rinnovo successivo viene rifiutato e la registrazione del browser viene annullata. Un browser che ha perso la propria chiave è un nuovo browser: viene configurato di nuovo e resta in attesa di approvazione come qualsiasi altro.

Ogni nuovo browser resta in attesa di approvazione

Un browser appena configurato non fa nulla finché un Owner o un IT Admin non lo approva in Dispositivi, sotto In attesa di approvazione. Fino ad allora non riceve regole, non invia eventi di audit e non può usare gli account condivisi, e il suo popup dice che è in attesa. I server di LayerT respingono le richieste di policy, audit e account condivisi di un browser in attesa, quindi questo non dipende dalla sola estensione. Un browser in attesa può comunque rinnovare il proprio token, ed è così che viene a sapere di essere stato approvato.

Questo vale comunque LayerT sia stato installato. Ciò che un browser riferisce sul modo in cui è stato installato è una dichiarazione del browser stesso: viene mostrato all’approvatore e non decide nulla.

• Quando ci sono due o più browser in attesa, un solo pulsante approva i browser elencati nella pagina e nessun altro.
• Per 7 giorni dopo un rifiuto, il browser può essere rimesso in coda. Questo non approva nulla: il browser resta di nuovo in attesa.
• Ogni Owner e ogni IT Admin viene avvisato al massimo una volta per ciascun browser in attesa, e l’Inbox elenca ogni browser in attesa.

Gli amministratori possono revocare un dispositivo dalla console. Il dispositivo perde le credenziali LayerT e l’accesso agli account condivisi, e tutte le sessioni attive di account condivisi su di esso terminano.

Quando qualcuno lascia l’azienda

Quando la vostra directory disattiva una persona o la rimuove da LayerT:

1. Le sue sessioni della console terminano immediatamente.
2. Le sue richieste di account condivisi e le sessioni attive vengono revocate, e i suoi browser escono da quegli account entro circa un minuto.
3. Le sue richieste di accesso aperte vengono chiuse.
4. I suoi browser non possono rinnovare il proprio token, quindi la loro registrazione viene annullata entro pochi minuti.
5. Nessuno può più approvare nulla per quella persona.

LayerT non permette alla directory di disattivare l’ultimo Owner attivo. Lo mantiene attivo e spiega il motivo all’Owner, così un’organizzazione non può chiudersi fuori da sola.

Tenere separate le organizzazioni

• Ogni record appartenente a un’organizzazione riporta la sua organizzazione e viene filtrato in base a essa nell’applicazione, a ogni query.
• La policy di ogni organizzazione è firmata separatamente, e l’estensione rifiuta una policy destinata a qualsiasi organizzazione diversa dalla propria.
• Le registrazioni sono archiviate con un prefisso distinto per ogni organizzazione.
• I test verificano che le credenziali di un’organizzazione non possano leggere policy, eventi di audit, sessioni o registrazioni di un’altra.

Il personale di LayerT

Il personale di LayerT non può consultare i dati di un’organizzazione. Per vedere la diagnostica di un’organizzazione, un operatore di LayerT identificato per nome deve farne richiesta, con una motivazione, per un massimo di quattro ore. Solo l’Owner di quell’organizzazione può approvarla. Ogni visualizzazione viene registrata nel registro di audit dell’organizzazione stessa.

Ruoli

LayerT ha sei ruoli integrati. Sono progettati in modo che chi configura non sia chi concede le eccezioni.

✱ Non di default. Un Owner può dare a una persona specifica, come un IT Admin, il diritto di concedere eccezioni permanenti.

• Nessuno approva la propria richiesta. Il server lo rifiuta per le richieste di accesso, per l’uso degli account condivisi e per le richieste di password. Vedere una password archiviata richiede l’approvazione di altre due persone, e una di loro deve essere un Owner o un Compliance Officer.
• Owner e IT Admin possono chiedere di vedere la password di qualsiasi account. Chiunque altro può chiederlo solo per gli account che può usare o di cui è proprietario.
• La revisione facoltativa a due autori impedisce di pubblicare regole redatte da sé.
• Le modifiche ai ruoli vengono verificate da entrambe le parti, così un IT Admin non può retrocedere un Owner.
• Attualmente i Team Approver possono decidere sulle richieste di tutta l’organizzazione. La limitazione al proprio team non è realizzata Proposto.
• Le revisioni degli accessi chiedono ogni trimestre al proprietario di ciascun account condiviso di confermare chi ne ha ancora bisogno. Nessuno conferma il proprio accesso, e nessuno perde l’accesso finché il revisore non invia la revisione.

Il registro di audit

Ogni blocco, richiesta, decisione, login, sessione, visualizzazione di registrazione, approvazione di un browser e modifica delle impostazioni viene scritto in un unico registro, in parole semplici.

• Gli eventi sono associati alla persona in base alle sue credenziali, mai in base a ciò che la richiesta dichiara.
• I valori sono leggibili di default. Se un indirizzo personale è stato bloccato, il registro mostra l’indirizzo, così un auditor può verificare la decisione. Una regola può essere impostata per scartare i propri valori, o mascherarli in parte, al loro arrivo.
• Una regola sulla digitazione conserva il testo dell’intero campo, fino a 10.000 caratteri, non solo la parte che corrispondeva. Gestione dei dati spiega cosa registra ciascun tipo di regola.
• Conservato per 365 giorni di default. Ogni organizzazione può modificare questo valore.
• Approvatori e Auditor vedono l’intera organizzazione. Tutti gli altri vedono i propri eventi.
• Il registro può essere filtrato per data, persona, azione, esito, regola, account, sessione e dispositivo. Tutto ciò che è a schermo può essere esportato in CSV o JSON Lines. I valori digitati sono esclusi, a meno che chi esporta non spunti una casella, e l’esportazione viene scritta nel registro prima che il file inizi.