Architettura
Policy firmata e applicazione
Le regole vengono scritte nella console, pubblicate come un’unica versione firmata, verificate da ogni browser e applicate nella pagina prima che un modulo venga inviato. Se un browser non riesce a dimostrare che la sua policy è aggiornata, va in fail-closed (in caso di errore blocca).
Descrive LayerT così come realizzato al 19 settembre 2026. Tutto ciò che non è ancora realizzato è indicato come tale.
Il ciclo di vita di una policy
- ConsoleBozzaL’IT scrive o modifica le regole come bozze. Nulla raggiunge ancora un browser.
- ConsolePubblicazioneLa pubblicazione applica tutte le bozze in sospeso come un’unica nuova versione. La revisione facoltativa a due autori impedisce di pubblicare le proprie bozze.
- Cloud di LayerTFirmaLa versione viene serializzata come JSON canonico e firmata con Ed25519.
- BrowserScaricamentoOgni 15 minuti, all’avvio e dopo la navigazione, con richieste condizionali.
- BrowserVerificaFirma, chiave, organizzazione, versione e scadenza vengono tutte verificate prima che venga usata anche una sola regola.
- La paginaApplicazioneLe regole agiscono sugli invii dei moduli e sulle operazioni di incolla prima che venga eseguito il codice del sito.
Che cos’è una regola
Una regola indica dove si applica, quali campi osserva, quale valore la fa scattare e cosa succede.
| Parte | Opzioni |
|---|---|
| Dove | Un pattern di sito: URL esatto, un glob come https://*.postbox.example/*, oppure un’espressione regolare |
| Quali campi | Selettori CSS per i campi di quella pagina. Gli amministratori possono costruirli indicando gli elementi della pagina con il selettore dell’estensione |
| Quale valore | Condizioni sul valore digitato: uguale a, corrisponde a un pattern, dominio email, presente in un elenco, e combinazioni con and/or/not. Le condizioni possono anche fare un confronto con l’identità della persona nella directory, come “solo il proprio indirizzo di lavoro” |
| Cosa succede | Monitora (solo registrazione nel log), blocca, blocca con richiesta (la persona può chiedere l’accesso), oppure forza il logout (cancella i cookie e lo storage del sito, poi mostra una pagina di logout avvenuto) |
Oggi LayerT valuta gli invii dei moduli (l’evento submit, i pulsanti di invio e il tasto Invio in un campo) e le operazioni di incolla nei campi osservati. Le regole integrate coprono i login personali a Google, Telegram Web e WhatsApp Web.
La firma
Ogni versione pubblicata viene serializzata in modo deterministico (chiavi ordinate, campi della firma esclusi) e firmata con Ed25519. La policy riporta un numero di versione, l’organizzazione a cui appartiene, quando è stata emessa e quando scade.
- Le versioni possono solo crescere. Ogni pubblicazione prende il numero successivo per la vostra organizzazione sotto un lock, così due amministratori non possono pubblicare la stessa versione.
- Il rollback pubblica le vecchie regole come una versione nuova e più alta. Le eccezioni approvate nel frattempo vengono mantenute, a meno che le regole ripristinate non le consentano più.
- In produzione, la chiave di firma è custodita in Google Cloud KMS e non può essere esportata: i server di LayerT chiedono a KMS ogni singola firma. Questo è realizzato e si attiva con il primo deploy in produzione di LayerT. Le build di sviluppo firmano con una chiave locale, di cui le build di produzione dell’estensione non si fidano.
La versione firmata che ricevono i vostri browser si chiama pacchetto di policy. Cosa contiene (comprese le allowlist e le eccezioni approvate di altre persone), dove viene archiviato sul laptop e cosa può farne chi controlla il laptop è spiegato in Pacchetti di policy e compromissione del dispositivo.
La verifica nel browser
L’estensione verifica ogni policy con l’implementazione Web Crypto del browser prima di usarla. Nell’ordine, rifiuta una policy se:
- la sua versione non è più recente di quella che ha già,
- appartiene a un’organizzazione diversa,
- è stata firmata con una chiave che l’estensione non conosce,
- la firma non risulta valida rispetto alla chiave pubblica integrata nell’estensione, oppure
- è scaduta, secondo l’orologio del laptop.
Una policy rifiutata viene scartata e il browser mantiene quella che aveva. Nell’estensione possono essere integrate più chiavi pubbliche contemporaneamente, così una chiave di firma può essere ruotata senza interruzioni.
Il comportamento fail-closed
Un browser che non riesce a ottenere una policy aggiornata e autentica non smette in silenzio di applicarla.
- La policy scade 7 giorni dopo l’emissione, e LayerT la firma di nuovo automaticamente 48 ore prima. Un browser vede una policy scaduta solo se non è riuscito a raggiungere LayerT per giorni.
- Su una pagina coperta da una regola blocca o forza il logout, una policy scaduta ferma ogni invio di moduli e ogni operazione di incolla nei campi della regola, con una scheda “Connectivity required” (connessione necessaria). La scheda spiega cosa è successo e offre solo l’opzione per tornare indietro.
- Le regole Monitora continuano a registrare nel log.
- Quando il browser si riconnette, la scheda scompare da sola entro circa 30 secondi, senza ricaricare la pagina.
L’arresto di emergenza
L’Owner può disattivare l’applicazione di tutte le regole per l’intera organizzazione. L’arresto è esso stesso una versione firmata della policy, quindi nessuno può inviarne uno falso a un browser. Viene registrato nel log, e Owner e IT Admin vengono avvisati. Serve solo a disattivare l’applicazione delle regole: non esiste un interruttore che invece blocchi tutto.
I browser lo recepiscono alla sincronizzazione successiva: entro 15 minuti, prima se la persona naviga. Un arresto è contrassegnato come urgente nella policy, ma oggi l’estensione non lo scarica prima delle altre modifiche. La revoca di un browser e il rollback arrivano nello stesso modo.
L’applicazione nella pagina
Il content script di LayerT intercetta gli invii e le operazioni di incolla prima che li veda il codice del sito. Quando una regola trova una corrispondenza, LayerT annulla l’evento, quindi la richiesta del sito non viene mai inviata. I test end-to-end verificano che non venga inviata.
I prompt di LayerT sono costruiti in modo che una pagina non possa interferire:
- Sono disegnati in shadow root chiuse, che gli script della pagina non possono raggiungere.
- I loro pulsanti rispondono solo a clic e pressioni di tasti reali, non a eventi creati da uno script.
- Non mostrano mai il nome interno della regola. Mostrano il messaggio scritto dall’amministratore.
- Non chiedono mai una password e non contengono mai un campo password. Un test verifica ogni prompt.
- Mentre un prompt è sulla pagina, l’icona di LayerT nella barra degli strumenti mostra un puntino ambra che la pagina non può falsificare.
Chiedere l’accesso
Una persona bloccata può chiedere l’accesso, se la regola lo consente.
- BrowserRichiestaLa persona spiega il motivo. La richiesta ha una scadenza, 30 minuti di default.
- Console o popupDecisioneUn approvatore sceglie: un singolo tentativo (cinque minuti), 15 minuti, 1, 8 o 24 ore, oppure permanente.
- Cloud di LayerTApplicazioneL’approvazione diventa un’eccezione in una policy firmata di nuovo, in un unico passaggio atomico.
- BrowserNuovo tentativoIl prompt si aggiorna da solo. Se la persona si è allontanata, una notifica desktop la avvisa.
- Nessuno può approvare la propria richiesta. Il server la rifiuta.
- Le eccezioni permanenti possono essere concesse solo dal Compliance Officer o dall’Owner, mai dall’IT.
- Una richiesta su cui nessuno decide scade automaticamente.
- Gli approvatori vengono informati delle richieste nell’Inbox della console, nell’estensione e via email, Slack o notifica del browser, secondo la scelta di ciascuno. Possono decidere nella console o direttamente da Slack, e una decisione presa da Slack viene registrata come tale.
Cosa viene registrato
Ogni blocco, ogni corrispondenza di una regola Monitora e ogni uso di un’eccezione crea un evento di audit con il sito, il campo, il valore corrispondente e la persona. I valori sono mantenuti leggibili di proposito, così un auditor può vedere che il login bloccato riguardava un indirizzo personale. Gli eventi di audit sono conservati per 365 giorni di default, e ogni organizzazione può modificare questo valore.