Richiedete una demo

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.

Blocchi di carta crema disposti a griglia su un foglio, uniti da sottili linee di carta verde acqua come in uno schema di sistema.

Descrive LayerT così come realizzato al 19 settembre 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.

Panoramica del sistema LayerTSu ogni laptop gestito, l’estensione LayerT in Chrome ha un service worker, dei content script e dei prompt nella pagina. Comunica con la console e l’API di LayerT tramite HTTPS: riceve la policy firmata e le autorizzazioni agli account condivisi, e invia eventi di audit, richieste e frammenti cifrati delle registrazioni. La console e l’API archiviano i dati in Postgres e le registrazioni cifrate in un object storage, mentre job pianificati gestiscono scadenze, conservazione, nuova firma e notifiche. Il vostro MDM installa l’estensione. Il vostro identity provider sincronizza persone e gruppi tramite SCIM e gestisce il login degli amministratori tramite OpenID Connect.Laptop gestito · ChromeCloud di LayerTEstensione LayerT: service workerVerifica la policy, custodisce le credenziali del dispositivo, comunica con l’APIContent scriptMondo isolato; osservanosolo ciò che le regole indicanoPrompt nella paginaShadow root chiuse;solo clic realiLa paginaModuli di login, siti dei fornitori. Codice non di LayerT.Console e APIRegole, account condivisi, Inbox, Sessioni, auditPostgresPolicy, audit, segretisigillati (testo cifrato)Object storageRegistrazioni, archiviatesolo come testo cifratoJob pianificatiScadenze, conservazione, nuova firma, notificheIl vostro MDMInstalla e fissa l’estensioneAmministratori e approvatoriUsano la console in un browserIl vostro identity provider (JumpCloud)Persone e gruppi tramite SCIM 2.0; login tramite OpenID Connectpolicy firmata, autorizzazioniaudit, richieste,registrazioni cifratelegge i campi indicati dalle regolePolicy di ChromeHTTPSSCIM · OIDC
Ogni freccia è HTTPS. Al di fuori di una sessione registrata, l’estensione non invia mai il contenuto delle pagine; invia eventi di audit sui campi indicati dalle vostre regole e l’esito dei login agli account condivisi. Le notifiche agli approvatori e il routing opzionale tramite gateway (accesso anticipato) non sono mostrati.

Le cinque regole con cui costruiamo

Lo sviluppo di LayerT segue una costituzione scritta. Ogni specifica e ogni modifica vengono verificate rispetto a essa.

  1. 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.
  2. Separare chi configura da chi concede eccezioni. L’IT scrive le regole. La compliance concede le eccezioni durature. Nessuno approva la propria richiesta.
  3. 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.
  4. 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.
  5. 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

ParteGira inCosa fa
Service workerL’estensione, in ChromeRegistrazione del dispositivo, credenziali del dispositivo, sincronizzazione della policy e verifica delle firme, invio a lotti degli eventi di audit, autorizzazioni agli account condivisi
Content scriptOgni pagina, nel mondo isolato di ChromeOsservano solo i campi indicati dalle vostre regole; compilano i login degli account condivisi; disegnano i prompt di LayerT
Prompt nella paginaShadow root chiuse sulla paginaLa scheda di blocco, il menu dell’account, gli avvisi e il chip della sessione. La pagina non può leggerli né cliccarli
Console e APICloud di LayerTRegole, account condivisi, Inbox, Sessioni, registro di audit, SCIM e login
PostgresCloud di LayerTVersioni della policy, eventi di audit, dati della directory, segreti degli account condivisi come testo cifrato
Object storageCloud di LayerTRegistrazioni delle sessioni, cifrate sul dispositivo prima del caricamento
Job pianificatiCloud di LayerT, un servizio worker separatoFanno 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.

Perché questa progettazione. LayerT fa da intermediario per l’accesso: decide chi può usare un account, quando e per quanto tempo, e lo chiude puntualmente. Un vault che solo l’utente finale potesse aprire non potrebbe far rispettare nulla di tutto questo. Abbiamo scelto la governance rispetto alla segretezza nei confronti dell’utente finale, e lo diciamo chiaramente. Leggete il whitepaper sull’intermediazione.

A che punto siamo

LayerT non è ancora stato lanciato. Tutto ciò che è descritto in queste pagine è realizzato e testato in fase di sviluppo, 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, ma non ancora approvato per la produzione (routing tramite gateway e gateway sui vostri server)
  • In arrivo non ancora realizzato, o non completato (Edge, Firefox e Opera; caselle di posta condivise e codici di accesso via email)
  • Proposto progettato, non realizzato

Due parti realizzate attendono il primo deploy in produzione, non altro lavoro: le chiavi custodite nel servizio di gestione delle chiavi di Google Cloud e l’installazione forzata da un pacchetto dell’estensione firmato. In fase di sviluppo al loro posto si usano chiavi locali, per questo le descriviamo come realizzate e attivate al lancio.

Non ci sono ancora clienti né deploy in produzione, e LayerT non possiede certificazioni.

Per approfondire

Policy firmata e applicazionePubblicazione, firma, distribuzione, verifica e comportamento fail-closed.Account condivisiArchiviazione sigillata, autorizzazioni, compilazione, TOTP, chiusura delle sessioni, accesso di emergenza.Sessioni e registrazioneChiusura remota di una sessione, registrazione con impostazioni predefinite rispettose della privacy, filigrana.Identità, tenancy e ruoliSCIM, login, credenziali del dispositivo, isolamento, permessi, audit.Gestione dei datiCosa archivia LayerT, dove, per quanto tempo, e cosa non lascia mai il dispositivo.Limiti e lavori apertiCosa LayerT non fa e cosa stiamo ancora realizzando.