Architettura
Com’è costruito LayerT
Scritto per gli ingegneri e i revisori della sicurezza che devono decidere se LayerT è solido. Spiega cosa fa il prodotto, come lo fa e dove sono i limiti.
Descrive LayerT così come realizzato al 3 ottobre 2026. Tutto ciò che non è ancora realizzato è indicato come tale.
LayerT è composto da due parti. Un’estensione del browser gira all’interno del profilo Chrome che la vostra azienda già gestisce. Una console con API è il luogo in cui amministratori, approvatori e responsabili della compliance prendono le decisioni. Le due parti comunicano solo tramite HTTPS. Non c’è alcun proxy nel percorso di rete, nessun agente sul sistema operativo e nessun nuovo browser. L’unica eccezione è facoltativa e vale account per account: il routing tramite gateway fa passare i siti di un singolo account condiviso tramite un server che noleggiate voi.
Le cinque regole con cui costruiamo
Lo sviluppo di LayerT segue un insieme di regole scritte. Ogni specifica e ogni modifica vengono verificate rispetto a esse.
- Fail-closed (in caso di errore blocca). Se LayerT non riesce a dimostrare che la sua policy è aggiornata e autentica, blocca le azioni coperte da quella policy. Non le lascia mai passare in silenzio.
- Separare chi configura da chi concede eccezioni. L’IT scrive le regole. La compliance concede le eccezioni durature. Nessuno approva la propria richiesta.
- Firmare ciò di cui il browser si fida; mantenere leggibile la traccia di audit. La policy è firmata con Ed25519 e verificata nel browser. Il registro di audit è tenuto in parole semplici, così che un auditor possa leggerlo.
- Usare i protocolli veri. SCIM 2.0 per la vostra directory, OpenID Connect per il login, RFC 6238 per i codici dell’app di autenticazione, Web Crypto per le firme. I test sostituiscono le sorgenti dei dati, mai i protocolli.
- Una funzionalità è finita quando un browser vero lo dimostra. Ogni flusso ha scenari che pilotano un vero Chromium con la vera estensione caricata.
Cosa gira e dove
| Parte | Gira in | Cosa fa |
|---|---|---|
| Service worker | L’estensione, in Chrome | Registrazione del dispositivo, la chiave propria del browser e il suo token di breve durata, sincronizzazione della policy e verifica delle firme, invio a lotti degli eventi di audit, autorizzazioni agli account condivisi |
| Content script | Ogni pagina, nel mondo isolato di Chrome | Osservano solo i campi indicati dalle vostre regole, e i file consegnati ai punti indicati da una regola sui file; compilano i login degli account condivisi; disegnano i prompt di LayerT |
| Prompt nella pagina | Shadow root chiuse sulla pagina | La scheda di blocco, il menu dell’account, gli avvisi e il chip della sessione. La pagina non può leggerli né cliccarli |
| Console e API | Cloud di LayerT | Regole, account condivisi, Inbox, Sessioni, registro di audit, SCIM e login |
| Postgres | Cloud di LayerT | Versioni della policy, eventi di audit, dati della directory, segreti degli account condivisi come testo cifrato |
| Object storage | Cloud di LayerT | Registrazioni delle sessioni, cifrate sul dispositivo prima del caricamento |
| Job pianificati | Cloud di LayerT, un servizio worker separato | Fanno scadere richieste e sessioni, applicano la conservazione, firmano di nuovo la policy prima che scada, inviano notifiche, gestiscono i promemoria delle revisioni degli accessi |
I dettagli sono in Componenti e flussi di dati.
Cosa possono vedere i server di LayerT
Una revisione di sicurezza deve saperlo fin dall’inizio: LayerT non è zero-knowledge. Per far accedere qualcuno a un account condiviso, i server di LayerT decifrano la password di quell’account per una sessione approvata e limitata nel tempo e la inviano al browser registrato della persona. Per riprodurre una registrazione, i server la decifrano per chi è autorizzato a guardarla. Quando un Owner esporta l’intera organizzazione, i server decifrano le registrazioni conservate all’interno di quell’esportazione. Una password o una chiave di configurazione dell’app di autenticazione può anche essere mostrata una volta a una persona, ma solo dopo che altre due persone hanno approvato la richiesta. Ognuna di queste azioni viene verificata rispetto ai ruoli, associata a una persona e scritta nel registro di audit.
I server ricevono anche ciò che corrisponde alle 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, e questa impostazione viene applicata sul server, non nel browser. I dettagli sono in Gestione dei dati.
A che punto siamo
LayerT non è ancora stato lanciato e prevede il lancio nel quarto trimestre del 2026. È in funzione in un ambiente di test con dati fittizi. Non c’è alcun deploy in produzione. Tutto ciò che è descritto in queste pagine è realizzato e testato, salvo dove indicato da un’etichetta:
- Disattivato di default realizzato, ma l’azienda deve attivarlo (registrazione, filigrana, invio automatico, revisione a due autori)
- Accesso anticipato realizzato e testato; è stato in funzione solo nel nostro ambiente di test (routing tramite gateway, tramite gateway su server che noleggiate voi, attivato account per account)
- In arrivo non ancora realizzato, o non completato (Edge, Firefox e Opera)
- Proposto progettato, non realizzato
Due parti realizzate dipendono dalla produzione, non da altro lavoro. Le chiavi custodite in un servizio di gestione delle chiavi sono realizzate e in uso nell’ambiente di test; per la produzione, che userà il servizio di gestione delle chiavi di Google Cloud, non c’è alcun deploy. L’installazione forzata da un pacchetto dell’estensione firmato è realizzata e si attiva con il primo rilascio in produzione; non è mai stata eseguita su una macchina gestita.
Non ci sono ancora clienti né deploy in produzione, e LayerT non possiede certificazioni.