Architettura
Componenti e flussi di dati
Ogni parte in movimento, dove gira, e ogni connessione tra le parti, con il protocollo e la credenziale usati da ciascun lato.
Descrive LayerT così come realizzato al 3 ottobre 2026. Tutto ciò che non è ancora realizzato è indicato come tale.
Nel browser
Il lato browser di LayerT è un’estensione Manifest V3. Il vostro MDM la installa e ne fissa l’icona nella barra degli strumenti usando i file di policy enterprise di Chrome per macOS e Windows (esistono anche i file per Linux). La stessa policy disattiva la modalità di navigazione in incognito, la modalità ospite e il password manager integrato di Chrome, e su Windows aggiunge LayerT alle altre estensioni installate forzatamente invece di sostituirle. Una persona può anche configurare LayerT da sola in un browser, con il proprio account di lavoro.
Ogni nuovo browser resta poi in attesa che un Owner o un IT Admin lo approvi, comunque LayerT sia stato installato. Finché non viene approvato non riceve regole e non può usare gli account condivisi.
| Parte | Che cos’è | Note |
|---|---|---|
| Service worker | Il processo in background dell’estensione | Custodisce la chiave di firma propria del browser e il suo token di breve durata, scarica e verifica la policy firmata, invia a lotti gli eventi di audit, gestisce le autorizzazioni agli account condivisi, esegue i timer di scadenza delle sessioni |
| Content script | Script che Chrome esegue nel mondo isolato di ogni pagina | Separati dal JavaScript della pagina. Leggono valori solo dai campi indicati dalle vostre regole, controllano i file consegnati ai punti indicati da una regola sui file e compilano i login degli account condivisi |
| Prompt nella pagina | La scheda di blocco, gli avvisi, il menu dell’account e il chip della sessione | Disegnati in shadow root chiuse, così gli script della pagina non possono leggerli né modificarne lo stile. I pulsanti rispondono solo a clic e pressioni di tasti reali. Usano i font di sistema, così LayerT non carica mai web font nelle pagine di altre aziende |
| Frame del menu dell’account | Una pagina dell’estensione mostrata in un frame all’interno del prompt | L’elenco degli account condivisi vive nell’origine dell’estensione, non nella pagina |
| Popup della barra degli strumenti | Il launcher, le approvazioni e l’aggiunta rapida | Una pagina dell’estensione; mai parte di un sito web |
Il segnale di fiducia che una pagina non può falsificare. Mentre un prompt di LayerT è presente in una scheda, LayerT accende un puntino ambra sulla propria icona nella barra degli strumenti. Un sito web può copiare l’aspetto di un prompt, ma non può disegnare nella barra degli strumenti del browser. Inoltre i prompt di LayerT non chiedono mai una password, e un test verifica che nessun prompt contenga un campo password.
Nel cloud di LayerT
| Parte | Che cos’è | Note |
|---|---|---|
| Console e API | Un’applicazione web | La console di amministrazione, l’API dell’estensione, il server SCIM 2.0 e il client OpenID Connect |
| Worker | Un servizio separato senza indirizzo pubblico | Esegue i job pianificati e invia le notifiche |
| Console operatore | Un sito separato per il personale di LayerT | Crea e gestisce le organizzazioni. Il personale può vedere all’interno di un’organizzazione solo con l’approvazione di quell’organizzazione (vedete Identità, tenancy e ruoli) |
| Postgres | Il sistema di riferimento | Versioni firmate della policy, eventi di audit, dati della directory, richieste e sessioni. I segreti degli account condivisi sono archiviati come testo cifrato in una tabella dedicata |
| Object storage | Google Cloud Storage | Solo registrazioni delle sessioni, cifrate sul dispositivo prima del caricamento. Il bucket non contiene mai testo in chiaro |
| Servizio di gestione delle chiavi | Un servizio cloud di gestione delle chiavi | Firma ogni versione della policy con Ed25519 e cifra (wrap) la chiave che sigilla ogni segreto di account condiviso e ogni registrazione. Le chiavi possono essere usate tramite il servizio ma mai copiate al di fuori di esso. La chiave di firma della policy è protetta via software: il servizio offre quel tipo di chiave solo in software, non in un modulo di sicurezza hardware. Realizzato, e in uso nell’ambiente di test di LayerT. Per la produzione, che userà Google Cloud KMS, non c’è alcun deploy |
| Job pianificati | Job ricorrenti sul worker | Chiudono richieste e sessioni scadute, applicano la conservazione, firmano di nuovo la policy prima che scada, ricostruiscono la policy dopo le modifiche alla directory, inviano notifiche e promemoria, controllano lo stato dei gateway |
Hosting. LayerT non è ancora in produzione. Oggi è in funzione in un ambiente di test che contiene solo dati fittizi. In produzione girerà su Google Cloud nell’UE, nella regione di Milano (
europe-west8), con le chiavi e i backup del database conservati nella multi-regione UE di Google. Cloudflare gestirà il DNS e invierà le email di notifica. I fornitori sono elencati in Gestione dei dati. Altre opzioni di residenza dei dati non sono ancora disponibili.Al di fuori di LayerT
| Parte | Di proprietà di | Come LayerT la usa |
|---|---|---|
| Il vostro identity provider | Voi | Invia persone e gruppi a LayerT tramite SCIM 2.0 e gestisce il login di amministratori e persone tramite OpenID Connect. Realizzato per JumpCloud |
| Il vostro MDM | Voi | Distribuisce la policy di Chrome che installa LayerT, ne fissa l’icona e gli indica a quale organizzazione appartiene |
| I vostri gateway Accesso anticipato | Voi | Piccoli server che noleggiate voi. Un account condiviso con il routing attivato fa passare i propri siti tramite uno di essi, così il fornitore vede un solo indirizzo. LayerT controlla ogni gateway dall’esterno e gli dice quali connessioni ammettere. LayerT non gestisce gateway propri |
| I siti che usano le vostre persone | Fornitori | LayerT legge e compila i moduli su questi siti. Non modifica mai i server o il traffico di un fornitore |
Flussi di dati
Ogni flusso qui sotto passa tramite HTTPS.
| Flusso | Direzione | Cosa si sposta | Autenticato da |
|---|---|---|---|
| Sincronizzazione della directory | Identity provider → API | Persone, gruppi, stato attivo (SCIM 2.0) | Un token SCIM emesso da LayerT, archiviato solo come hash |
| Login alla console | Browser ↔ API ↔ identity provider | Flusso authorization code di OpenID Connect | ID token firmato, verificato rispetto alle chiavi pubblicate dal provider |
| Uso della console | Browser → API | Decisioni, regole, impostazioni | Una sessione lato server, verificata di nuovo a ogni richiesta |
| Registrazione del dispositivo | Estensione → API → identity provider | La persona effettua il login una volta. Il browser invia la metà pubblica di una chiave che ha creato, dimostra di possedere la metà privata e riceve un token del dispositivo di breve durata. Poi resta in attesa dell’approvazione di un amministratore | Il login dell’identity provider, e una firma della chiave del browser |
| Rinnovo del token | Estensione → API | Un nuovo token del dispositivo di breve durata | Una prova firmata dalla chiave del browser, verificata rispetto alla chiave pubblica che LayerT ha archiviato alla registrazione del dispositivo |
| Sincronizzazione della policy | API → estensione | La policy firmata della vostra organizzazione | Token del dispositivo; la policy stessa viene verificata con Ed25519 nel browser |
| I gruppi della persona | API → estensione | I gruppi della directory della persona di questo browser, e di nessun altro, come risposta firmata valida per 24 ore | Token del dispositivo; la risposta viene verificata con Ed25519 nel browser |
| Audit | Estensione → API | Eventi relativi a blocchi, corrispondenze, approvazioni e sessioni, con il valore che ha fatto scattare una regola | Token del dispositivo, che deve corrispondere al dispositivo dell’evento |
| Proseguire con un motivo | Estensione → API | Il motivo della persona per proseguire oltre un blocco, con la regola, la pagina e il valore. L’azione va avanti solo dopo che il server lo ha archiviato | Token del dispositivo; la persona viene ricavata dal token, mai dalla pagina |
| Richieste e autorizzazioni | Estensione ↔ API | Richieste di accesso, decisioni, autorizzazioni agli account condivisi | Token del dispositivo, legato alla persona e al browser registrato |
| Registrazione della sessione | Estensione → API → object storage | Frammenti cifrati delle registrazioni | Token del dispositivo; i frammenti sono già cifrati |
| Sessione del gateway Accesso anticipato | API → estensione | Per un account con il routing attivato: quale gateway usare, una credenziale valida solo per questa sessione e l’indirizzo che il fornitore vedrà. Non vi viaggia alcuna password | Token del dispositivo, legato alla sessione attiva della persona |
| Ammissione al gateway Accesso anticipato | Gateway → API | Il gateway chiede se ammettere ogni nuova connessione | La chiave propria del gateway. LayerT gli risponde solo sulle sessioni della sua organizzazione |
| Job pianificati | Cloud Scheduler → worker | Solo l’attivazione | Un identity token firmato da Google per il service account dello scheduler |
| Esiti dei login | Estensione → API | Se il login a un account condiviso è riuscito, a quale passaggio si è fermato e l’indirizzo della pagina senza la sua query. Mai valori, etichette o testo della pagina | Token del dispositivo |
| Informazioni sul dispositivo | Estensione → API | Versione dell’estensione, il modo in cui il browser dichiara di essere stato installato, browser, sistema operativo e versione della policy | Token del dispositivo |
| Controllo della versione | Estensione → API | Qual è la versione più recente di LayerT. La risposta è la stessa per ogni organizzazione | Nessuna. La richiesta non porta credenziali né alcuna informazione sulla persona |
| Notifiche | Worker → approvatori | Richieste in attesa di qualcuno, risposte e avvisi, via email, Slack e l’estensione. Nessun segreto e nessun valore completo | Email tramite SMTPS; l’API di Slack con la connessione Slack della vostra organizzazione; il token del dispositivo dell’estensione |
| Decisioni da Slack | Slack → API | L’Approva o il Rifiuta di un approvatore su una richiesta | La firma della richiesta di Slack, dopodiché i diritti dell’approvatore vengono verificati di nuovo al momento del clic |
Cosa invia l’estensione, e cosa no
LayerT legge solo i campi indicati dalle vostre regole. Quando una regola trova una corrispondenza, LayerT registra ciò che corrispondeva e, per una regola sulla digitazione, il testo del campo, così che un auditor possa verificare la decisione. Una regola può mascherare o nascondere i propri valori.
- Invia eventi di audit quando una regola trova una corrispondenza: la regola, l’indirizzo della pagina, il campo e il valore che ha fatto scattare la regola. Per una regola sui moduli il valore è il testo del campo, e per una regola sull’incolla il testo incollato. È così che un auditor può vedere che un indirizzo personale è stato fermato.
- Per una regola sulla digitazione, il valore è l’intero testo del campo com’era quando la regola ha trovato la corrispondenza, non solo la parte che corrispondeva, fino a 10.000 caratteri.
- Per una regola sui file, invia il nome, il tipo e la dimensione del file, il modo in cui il file è stato consegnato alla pagina e se LayerT ha potuto leggerlo. Il testo di un file viene letto nel browser per decidere e non viene mai inviato.
- Il browser invia sempre il valore intero. L’impostazione con cui una regola maschera o nasconde i propri valori viene applicata sui server di LayerT, prima che qualsiasi cosa venga archiviata. I valori non vengono oscurati nel browser.
- Una password o un codice compilati da LayerT non vengono mai letti da alcuna regola, quindi non c’è nulla da inviare. Una regola sulla digitazione non legge mai, in nessun caso, una casella della password o una casella del codice monouso. Una regola sui moduli o sull’incolla legge i campi che indica, e tra questi può esserci una casella della password in cui una persona ha digitato da sé.
- Invia richieste di accesso con la motivazione della persona, e frammenti cifrati delle registrazioni quando la registrazione è attiva per un account condiviso.
- Invia il motivo che una persona indica per proseguire oltre un blocco, dove una regola lo consente.
- Segnala se ogni login a un account condiviso è riuscito, e informazioni di base sul browser, così che l’IT possa vedere quali laptop sono protetti. Queste segnalazioni non contengono valori digitati né testo della pagina.
- Gli eventi in attesa di invio restano nello storage dell’estensione finché non vengono consegnati, e possono contenere i valori che hanno fatto scattare una regola.
- Non invia pagine. Al di fuori di una sessione registrata di un account condiviso, l’unico contenuto della pagina che invia è il testo di un campo in cui una regola ha trovato una corrispondenza, e non invia nulla di ciò che viene digitato in campi non indicati dalle vostre regole. Non invia mai la cronologia di navigazione, un elenco delle pagine visitate o i valori dei cookie. In una sessione registrata, ciò che le persone digitano è mascherato nel punto in cui lo digitano, nei campi dei moduli e negli editor di testo formattato, e la registrazione mostra comunque ciò che la pagina mostra a sua volta: i dettagli sono in Sessioni e registrazione.