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

Le persone effettuano il login una volta dall’estensione tramite il vostro identity provider. Questo dà al browser le proprie credenziali:

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 le credenziali, quindi la loro registrazione viene annullata entro un’ora.
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 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.
• 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.