Architettura

Pacchetti di policy e compromissione del dispositivo

Le vostre regole raggiungono ogni browser come un unico file firmato, un pacchetto di policy. Questa pagina spiega cosa contiene, come un browser decide di fidarsene, e cosa può e non può farne chi controlla un laptop o riesce a violare LayerT.

Descrive LayerT così come realizzato al 3 ottobre 2026. Tutto ciò che non è ancora realizzato è indicato come tale.

In parole semplici

Quando il vostro team IT pubblica regole nella console di amministrazione, LayerT raccoglie l’intero regolamento della vostra organizzazione in un unico file, chiamato pacchetto di policy, e lo firma. Ogni estensione LayerT ha integrata la chiave pubblica corrispondente, così un browser può distinguere un pacchetto autentico da uno falsificato o alterato. Rifiuta tutto ciò che non supera la verifica.

Perché è firmato. Il pacchetto viaggia su internet e risiede su laptop che nessuno sorveglia minuto per minuto. La firma fa sì che nessuno tra LayerT e il browser possa modificare una regola, aggiungere un’eccezione o disattivare l’applicazione delle regole. Né qualcuno può consegnare a un browser le regole di un’altra organizzazione, o una versione più vecchia delle vostre.

Perché scade. Ogni pacchetto è valido per 7 giorni, e LayerT lo firma di nuovo automaticamente ben prima di allora. La scadenza impedisce che un laptop viva per sempre con regole vecchie: un pacchetto che nessuno riesce ad aggiornare, prima o poi smette di essere considerato attuale.

Cosa succede offline. Un browser che non riesce a raggiungere LayerT continua a usare il suo ultimo pacchetto autentico. Nuove regole, nuove approvazioni, dispositivi revocati e arresto di emergenza non possono raggiungerlo finché non si riconnette. Se resta offline fino alla scadenza del pacchetto, non torna in silenzio a consentire tutto. Sui siti coperti dalle vostre regole di blocco, ferma le azioni coperte da quelle regole e chiede alla persona di riconnettersi.

Cosa non contiene mai. Password e codici monouso degli account condivisi non viaggiano mai in un pacchetto. Vengono inviati separatamente, per un login alla volta. Un pacchetto contiene invece indirizzi email di lavoro e le eccezioni concesse dai vostri approvatori, quindi trattatelo come dati aziendali.

Dove si ferma la firma. La firma protegge un pacchetto durante il tragitto verso il browser. Non lo protegge dopo che è stato salvato. Chi può scrivere nello storage dell’estensione nel profilo del browser, o ha diritti di amministratore sul laptop, può aggirare l’applicazione delle regole su quel laptop. La gestione dei dispositivi chiude questa lacuna, come spiega la sezione sulla presa di controllo del dispositivo e sulle violazioni.

Cosa contiene un pacchetto

Un pacchetto è un unico documento JSON per l’intera organizzazione. Ecco un esempio abbreviato con valori di fantasia:

{
  "bundleVersion": 57,
  "issuedAt": "2026-09-18T09:00:00.000Z",
  "expiresAt": "2026-09-25T09:00:00.000Z",
  "tenantId": "3f1c2a9e-7b44-4d2e-9a51-0c6e1d2b8f10",
  "tenantDisplayName": "Acme Corp",
  "killSwitch": false,
  "critical_update": false,
  "revoked_devices": ["b7e0c1d2-5a6f-4e3b-8c9d-1a2b3c4d5e6f"],
  "classifiers": [
    { "id": "corp_email", "type": "email_domain", "value": "acme-corp.example" }
  ],
  "rules": [
    {
      "id": "rule_postbox_work_only",
      "name": "Accesso a Postbox solo con un account di lavoro",
      "enabled": true,
      "event": "form_submit",
      "urlMatch": { "type": "glob", "patterns": ["https://*.postbox.example/*"] },
      "selectors": [{ "css": "input[name=login]" }],
      "valueMatch": { "op": "not", "operand": { "type": "matches_user_attribute", "field": "allowed_postbox_accounts" } },
      "action": {
        "type": "block_with_request_bypass",
        "message": "Qui usate il vostro account Acme Corp.",
        "bypass": { "mode": "request_bypass", "justificationRequired": true }
      },
      "audit": { "include": ["url", "value"], "redact": "partial" }
    }
  ],
  "exceptions": [
    {
      "id": "0b9c8d7e-1111-4222-8333-944455566677",
      "ruleId": "rule_postbox_work_only",
      "subject": { "userId": "jc_alice_chen" },
      "matchedValue": "[email protected]",
      "expiresAt": "2026-10-01T00:00:00.000Z",
      "grantedBy": "[email protected]",
      "grantedAt": "2026-09-17T08:12:00.000Z",
      "justification": "Caricamento mensile sul portale Vendor Reports"
    }
  ],
  "groups": {},
  "user_attributes": {
    "[email protected]": { "allowed_postbox_accounts": ["[email protected]"] },
    "[email protected]": { "allowed_postbox_accounts": ["[email protected]"] }
  },
  "signature": "ed25519:q8Vd…(64 bytes, base64)…",
  "signatureKeyId": "prod-v1"
}

Campo per campo:

Campo	Cosa contiene
`tenantId`, `tenantDisplayName`	L’id della vostra organizzazione, che lega il pacchetto alla vostra organizzazione, e il nome che LayerT mostra nei suoi prompt
`bundleVersion`	Un numero che aumenta di uno a ogni nuovo pacchetto. Un browser accetta solo un numero più alto di quello che possiede
`issuedAt`, `expiresAt`	Quando il pacchetto è stato firmato, e quando smette di essere attuale: 7 giorni dopo
`rules`	Ogni regola: quando agisce (il suo trigger), dove si applica (pattern di sito), quali campi osserva (selettori CSS), quali valori la fanno scattare, cosa succede, il messaggio che le persone vedono e cosa registra il registro di audit
`classifiers`	Test sui valori, con un nome, che le regole possono condividere, come “un indirizzo del nostro dominio email”
`exceptions`	Ogni eccezione approvata e attiva: la regola, l’id della persona nella directory, il valore esatto approvato, quando scade, chi l’ha approvata e quando, e la motivazione fornita dalla persona
`groups`	Vuoto. Le appartenenze ai gruppi non viaggiano in un pacchetto: ogni browser chiede separatamente i gruppi della propria persona (vedete “I gruppi della persona, separatamente” più avanti)
`user_attributes`	Gli elenchi propri di ogni persona attiva, come gli account con cui è autorizzata ad accedere
`killSwitch`	L’arresto di emergenza. Quando è attivo, il browser non applica alcuna regola
`revoked_devices`	Gli id dei browser revocati da un amministratore
`critical_update`	Contrassegna una versione urgente: un arresto di emergenza, un rollback o una revoca. Oggi l’estensione non li scarica prima delle altre versioni (vedete “Arresto di emergenza e rollback” più avanti)
`gateways`	Solo se usate i gateway Accesso anticipato: nome, regione, nome host e porta di ogni gateway. Nessun indirizzo IP
`signature`, `signatureKeyId`	La firma Ed25519 su tutto quanto sopra, e quale chiave l’ha prodotta

Cosa non contiene mai

Password degli account condivisi, chiavi di configurazione dell’app di autenticazione o codici monouso. Quando qualcuno accede a un account condiviso, il browser scarica un’autorizzazione separata e monouso per quel singolo login e la conserva solo in memoria. Non fa mai parte di un pacchetto e non viene mai salvata su disco.
Procedure di login. I passaggi che LayerT segue per compilare il modulo di login di un fornitore viaggiano con quell’autorizzazione, e la loro firma viene verificata separatamente.
Token del dispositivo o chiavi. Il pacchetto indica la chiave che lo ha firmato. Non contiene mai una chiave, e la chiave che ogni browser crea per sé non lascia mai quel browser.
Chi fa parte di quale gruppo della directory. Un browser viene a conoscenza dei gruppi della propria persona, separatamente, e di nessun altro.
Ciò che le persone digitano mentre navigano. Le regole contengono pattern, e ciò che una regola ha intercettato va nel registro di audit, separatamente. Gli unici valori digitati che un pacchetto contiene sono i valori approvati nelle eccezioni attive.
Indirizzi IP dei gateway.

Contenuti interni e personali

Ogni browser riceve il pacchetto dell’intera organizzazione. Oggi ogni browser della vostra organizzazione riceve lo stesso pacchetto. Quindi ogni laptop con un browser approvato contiene gli elenchi dell’intera organizzazione (le allowlist di altre persone) e ogni eccezione attiva, compresi il valore approvato, chi l’ha approvata e la motivazione fornita. Non contiene più le appartenenze ai gruppi. Contiene anche le regole, quindi chiunque legga un pacchetto può vedere esattamente cosa viene osservato. La progettazione di LayerT prevede pacchetti limitati a una singola persona, ma questo non è realizzato. Finché non lo sarà, trattate un pacchetto come dati aziendali interni, e chiedete ad approvatori e richiedenti di non inserire nelle motivazioni nulla che non dovrebbe trovarsi su ogni laptop.

I gruppi della persona, separatamente

Una regola può applicarsi a un gruppo della directory. Per questo a un browser non servono le appartenenze dell’intera organizzazione, ma solo quelle della propria persona, quindi le appartenenze ai gruppi restano fuori dal pacchetto.

A ogni sincronizzazione della policy, ogni browser chiede anche a LayerT di quali gruppi fa parte la propria persona. LayerT legge la vostra directory così com’è in quel momento e risponde con i gruppi di quella persona e nient’altro. Un browser non viene mai a sapere chi altro fa parte di un gruppo.
La risposta è firmata con la chiave che firma la policy, in un formato proprio, ed è valida per 24 ore. Il browser la conserva solo se la firma risulta valida e la risposta è per questo browser e per questa organizzazione.
Una modifica nella vostra directory raggiunge un browser in esecuzione e connesso entro circa 15 minuti. Un browser offline conserva la sua ultima risposta fino a 24 ore, e una pagina aperta conserva ciò con cui è stata caricata finché non viene ricaricata o il suo indirizzo non cambia.
Un browser senza una risposta aggiornata va in fail-closed nelle pagine in cui una regola di blocco indica un gruppo (vedete “Scadenza e fail-closed” più avanti).

Il ciclo di vita di un pacchetto

Un pacchetto viene verificato una sola volta, all’arrivo. Dopodiché il browser si fida di ciò che ha salvato, ed è per questo che il laptop stesso deve essere gestito.

Pubblicazione

Ogni modifica che influisce su ciò che i browser applicano produce un nuovo pacchetto:

un Owner o un IT Admin pubblica le bozze in sospeso (eventualmente dopo la revisione di un secondo autore),
un approvatore concede un accesso, il che aggiunge un’eccezione,
qualcuno revoca un’eccezione, o attiva o disattiva una regola,
un Owner o un IT Admin revoca un browser, o lo ripristina,
l’Owner attiva o rilascia l’arresto di emergenza,
un Owner o un IT Admin esegue un rollback,
la vostra directory cambia (persone che entrano, escono o cambiano gruppo), rilevata da un job orario.

Ogni nuovo pacchetto prende il numero di versione successivo per la vostra organizzazione sotto un lock, così due modifiche simultanee non possono produrre la stessa versione. Il documento firmato viene archiviato con un’impronta del suo contenuto e un collegamento alla versione precedente.

Compilazione e firma

LayerT assembla il pacchetto, poi lo scrive in forma canonica: chiavi ordinate, campi della firma esclusi, così lo stesso contenuto produce sempre gli stessi byte. Quei byte vengono firmati con Ed25519.

La chiave privata di firma è custodita in un servizio di gestione delle chiavi, e non può essere esportata. I server di LayerT inviano i byte al servizio e ricevono in cambio una firma. La chiave è protetta via software: il servizio offre questo tipo di chiave (Ed25519) solo in software, quindi non è custodita in un modulo di sicurezza hardware. La configurazione di produzione si rifiuta di avviarsi con un file di chiave locale. Questo è realizzato e in uso nell’ambiente di test di LayerT. Per la produzione, che custodirà la chiave in Google Cloud KMS, non c’è alcun deploy. Le build di sviluppo firmano con una chiave locale, e una build di produzione dell’estensione si rifiuta di fidarsene.

La stessa chiave firma i pacchetti di ogni organizzazione. Firma anche altre due cose: l’identità a cui un browser viene legato al momento della registrazione, e le procedure di login. Firma anche la risposta che ogni browser riceve sui gruppi della propria persona. Ogni tipo è scritto nel proprio formato, così uno non può essere spacciato per un altro.

Nell’estensione possono essere integrate più chiavi pubbliche contemporaneamente. Per sostituire la chiave di firma, LayerT rilascia un’estensione che si fida sia della vecchia sia della nuova chiave, attende che venga distribuita, passa alla firma con la nuova chiave e rimuove la vecchia in un rilascio successivo.

Distribuzione

Il browser chiede l’ultimo pacchetto:

ogni 15 minuti,
all’avvio del browser e quando l’estensione viene installata o aggiornata,
quando la persona passa a una nuova pagina (al massimo ogni pochi secondi),
quando qualcuno preme Sync now nella pagina delle opzioni di LayerT,
e ogni 30 secondi mentre una pagina mostra la scheda “Connectivity required” (connessione necessaria).

La richiesta avviene tramite HTTPS con il token del dispositivo, che indica a quale organizzazione il browser appartiene. Un browser ancora in attesa dell’approvazione di un amministratore, o che è stato rifiutato, viene respinto e non riceve alcun pacchetto. La richiesta è condizionale: se nulla è cambiato, LayerT risponde “not modified” e non viene scaricato nulla. LayerT serve sempre e solo l’ultimo pacchetto della vostra organizzazione.

Verifica nel browser

Prima di usare un nuovo pacchetto, il browser esegue queste verifiche, in quest’ordine, con l’implementazione Web Crypto del browser:

Versione. Deve essere più alta della versione già archiviata. Questo impedisce di riproporre un pacchetto vecchio.
Organizzazione. Deve appartenere all’organizzazione a cui è legato questo browser. Il browser si lega alla propria organizzazione quando accetta il suo primo pacchetto autentico.
Chiave. Deve indicare una chiave di firma integrata nell’estensione.
Formato. La firma deve essere una firma Ed25519 ben formata.
Firma. La firma deve risultare valida sui byte canonici.
Scadenza. Non deve essere scaduto, secondo l’orologio del laptop.

Se una qualsiasi verifica fallisce, il nuovo pacchetto viene scartato e il browser mantiene quello che aveva. Viene salvato solo un pacchetto che supera tutte le verifiche.

Archiviazione sul dispositivo

Il pacchetto viene salvato nello storage delle estensioni di Chrome, all’interno del profilo del browser della persona, come JSON in chiaro. LayerT non lo cifra: a riposo, è protetto dalla cifratura del disco del laptop. Lo stesso storage contiene la registrazione del browser (il suo token del dispositivo di breve durata; non esiste una credenziale di rinnovo di lunga durata) ed eventuali eventi di audit non ancora inviati, che possono includere valori digitati dalle persone. Contiene anche la risposta firmata sui gruppi di quella persona. La chiave di firma propria del browser è conservata separatamente dal browser, in una forma che non può essere esportata.

Verificato all’arrivo, non a ogni lettura. Il browser verifica un pacchetto una sola volta, al suo arrivo. Dopodiché applica ciò che si trova nello storage, senza verificare di nuovo la firma. Per questo l’integrità del profilo del browser, e quindi del laptop, conta quanto la firma.

Applicazione

In ogni pagina, il content script di LayerT chiede all’estensione le regole che corrispondono all’indirizzo della pagina, poi agisce sugli invii dei moduli e sulle operazioni di incolla nei campi indicati da quelle regole, prima che li veda il codice del sito. Anche le regole per il testo digitato e per i file consegnati alla pagina agiscono lì. Un’eccezione si applica solo a una regola “blocca con richiesta”, e solo quando regola, persona e valore corrispondono esattamente e l’eccezione non è scaduta. Il comportamento delle regole nella pagina è descritto in Policy firmata e applicazione.

Scadenza e fail-closed

Un pacchetto dura 7 giorni. Un job orario firma di nuovo il pacchetto della vostra organizzazione, come una versione nuova e più alta con lo stesso contenuto, quando mancano 48 ore o meno alla scadenza. Il monitoraggio di LayerT segnala qualsiasi organizzazione il cui pacchetto più recente si trovi a meno di 24 ore dalla scadenza.

Se il pacchetto di un browser scade davvero, perché non è riuscito a raggiungere LayerT per giorni:

sulle pagine coperte da una regola blocca o forza il logout, ogni invio di moduli, e ogni operazione di incolla nei campi della regola, viene fermato con una scheda “Connectivity required” (connessione necessaria) che non offre alcun modo per aggirarla,
un file consegnato ai campi di una regola sui file, e il tasto Invio in un campo osservato da una regola sulla digitazione, vengono fermati allo stesso modo, senza leggere nulla,
le regole avvisa e monitora continuano a funzionare,
l’arresto di emergenza e l’elenco dei dispositivi revocati dell’ultimo pacchetto restano validi,
la scheda scompare da sola entro circa 30 secondi dall’arrivo di un nuovo pacchetto.

Un browser che non conosce i gruppi della propria persona si comporta allo stesso modo, anche con un pacchetto aggiornato. In una pagina in cui una regola di blocco indica un gruppo, l’azione viene fermata finché non arriva una risposta firmata.

Arresto di emergenza e rollback

L’arresto di emergenza serve quando una regola è sbagliata e deve essere disattivata ovunque, subito. Solo l’Owner può usarlo. Pubblica un nuovo pacchetto con l’applicazione delle regole disattivata: da quel momento ogni pagina passa, e la registrazione nel registro di audit continua. Owner e IT Admin vengono informati. Disattiva l’applicazione delle regole. Non esiste un interruttore che invece blocchi tutto. Un pacchetto che attiva o rilascia l’arresto dura 24 ore anziché 7 giorni, e il job orario continua a firmarlo di nuovo.

Un rollback pubblica le regole, i test sui valori e l’impostazione di arresto di emergenza di una versione precedente come una versione nuova e più alta. Mantiene le eccezioni attuali (eliminando quelle che le regole ripristinate non consentono più), gli elenchi e i dispositivi revocati. Un rollback a una versione precedente a un arresto di emergenza revoca l’arresto, e il registro di audit lo registra. Poiché i browser accettano solo versioni più alte, nessun browser torna mai indietro.

Urgente non significa più veloce, per ora. Arresti di emergenza, rollback e revoche sono contrassegnati come urgenti nel pacchetto, ma oggi l’estensione non tiene conto di questo contrassegno. Raggiungono un browser come qualsiasi altra nuova versione: pochi secondi dopo che la persona passa a una nuova pagina, oppure entro 15 minuti se il browser è inattivo.

Presa di controllo del dispositivo e violazioni

La firma e la scadenza proteggono un pacchetto sulla rete e nei confronti della pagina. Non sono state progettate per proteggerlo da chi controlla già il laptop, e nulla che giri all’interno di un browser può farlo. Ecco ogni caso: cosa può fare un attaccante, cosa non può fare e cosa chiude la lacuna.

Leggere, modificare e falsificare un pacchetto

Leggere il pacchetto dal discoRegge, con limiti

Possono: Chiunque possa leggere il profilo del browser della persona può leggere l’intero pacchetto in chiaro. Cioè la persona stessa, software eseguito con la sua identità, un amministratore, o chiunque abbia in mano il disco di un laptop senza cifratura del disco. Viene a conoscenza di ogni regola, delle allowlist di tutti e di ogni eccezione attiva con valore, approvatore e motivazione. Lo stesso storage contiene il token del dispositivo di breve durata del browser, l’elenco firmato dei gruppi di quella persona ed eventuali eventi di audit non ancora inviati, che possono includere i valori che hanno fatto scattare una regola.
Non possono: Ottenere password degli account condivisi, chiavi di configurazione o codici dell’app di autenticazione, o la chiave di firma. Nessuno di questi è lì. Non ci sono nemmeno le appartenenze ai gruppi: un browser contiene solo i gruppi della propria persona.
Cosa fare: Cifratura completa del disco (FileVault, BitLocker) imposta dal vostro MDM, e un blocco schermo a breve intervallo. Mantenete sobrie le motivazioni delle richieste di accesso. I pacchetti limitati a una singola persona non sono realizzati.

Modificare il pacchetto archiviatoNon difeso su quel laptop

Possono: Chi può scrivere nello storage dell’estensione del profilo può modificare il pacchetto archiviato: attivare l’arresto di emergenza, eliminare regole, aggiungere eccezioni, impedire che gli aggiornamenti autentici lo sostituiscano, o cambiare la persona a cui il browser ritiene di appartenere. Il browser non verifica di nuovo le firme su ciò che rilegge. Chi può scrivere lì è il software eseguito con l’identità della persona (per esempio mentre Chrome è chiuso), un amministratore, e chiunque usi gli strumenti per sviluppatori sull’estensione dove sono consentiti.
Non possono: Influire su qualsiasi altro laptop, modificare qualcosa sui server di LayerT o approvare qualcosa nella console. La modifica resta su quell’unico browser.
Cosa fare: Nessun diritto di amministratore locale per il personale. Bloccate tramite policy gli strumenti per sviluppatori per le estensioni e la modalità sviluppatore di Chrome. Usate una protezione degli endpoint e i controlli di conformità del vostro MDM. La verifica della firma del pacchetto archiviato a ogni lettura non è realizzata, e non fermerebbe un amministratore, che può sostituire l’estensione stessa.

Falsificare o alterare un pacchetto in transitoLayerT regge

Possono: Nulla di utile senza la chiave di firma.
Non possono: Far accettare a un browser un pacchetto creato o modificato da loro. Non supera la verifica della firma, e un pacchetto firmato con qualsiasi altra chiave viene rifiutato perché la chiave non è integrata nell’estensione.
Cosa fare: Nulla di più. È proprio a questo che serve la firma.

Riproporre un pacchetto vecchioRegge, con limiti

Possono: Solo in un caso limitato: se il pacchetto archiviato non c’è più (per esempio, il browser si è registrato di nuovo o qualcuno lo ha eliminato) e controllano la connessione, per esempio con un certificato di intercettazione installato da un amministratore, potrebbero consegnare un pacchetto autentico e non scaduto della vostra organizzazione risalente agli ultimi 7 giorni.
Non possono: Sostituire un pacchetto archiviato con uno più vecchio. La versione deve crescere. I server di LayerT servono sempre e solo l’ultimo pacchetto.
Cosa fare: Nessun diritto di amministratore locale, e controllo su quali certificati radice considerano attendibili i vostri laptop.

Inviare il pacchetto di un’altra organizzazioneLayerT regge

Non possono: Farlo accettare. L’id dell’organizzazione di ogni pacchetto è coperto dalla firma, e il browser rifiuta un pacchetto che non sia della propria. La stessa verifica blocca un pacchetto autentico di un altro cliente di LayerT.
Cosa fare: Nulla di più.

Usare un pacchetto scadutoRegge, con limiti

Possono: Mantenere attuale un pacchetto scaduto portando indietro l’orologio del laptop, perché la scadenza viene valutata in base all’orologio del laptop.
Non possono: Consegnare un pacchetto scaduto a un browser con l’orologio corretto. Viene rifiutato all’arrivo, e una volta scaduto quello archiviato, le regole di blocco vanno in fail-closed.
Cosa fare: I laptop gestiti non permettono al personale di cambiare l’orologio. Mantenete questa impostazione, e tenete attiva la sincronizzazione dell’ora.

La rete e la pagina web

Bloccare LayerT sulla reteRegge, con limiti

Possono: Mantenere il browser sul suo ultimo pacchetto autentico per un massimo di 7 giorni, il che ritarda nuove regole, nuove revoche e l’arresto di emergenza.
Non possono: Rendere il pacchetto più permissivo, o evitare il comportamento fail-closed. Alla scadenza, le regole di blocco fermano gli invii sulle pagine che coprono finché il browser non si riconnette.
Cosa fare: La vista della copertura nella console segnala i browser che non si fanno sentire da 3 giorni. Mostra la versione che LayerT ha inviato per ultima a ciascun browser, il che non prova che il browser l’abbia accettata, quindi considerate un browser silenzioso come un caso da verificare.

Una pagina web malevolaRegge, con limiti

Possono: Eseguire i propri script sulle proprie pagine, come può fare qualsiasi sito. L’applicazione delle regole all’interno di una pagina ha limiti propri, elencati nella pagina Limiti e lavori aperti.
Non possono: Leggere o modificare il pacchetto o lo storage dell’estensione, o inviare messaggi all’estensione: non ne accetta nessuno dai siti web. Il content script di LayerT gira in un mondo isolato che la pagina non può raggiungere, e i suoi prompt sono disegnati in shadow root chiuse.
Cosa fare: Nulla di più per il pacchetto in sé.

Persone e software sul laptop

Malware eseguito con l’identità della personaNon difeso su quel laptop

Possono: Tutto ciò che riguarda la lettura e la modifica del pacchetto. Può anche agire come quel browser nei confronti di LayerT finché è in esecuzione su quel laptop: copiare il token del dispositivo di breve durata, e usare lì la chiave propria del browser per rinnovarlo. La chiave è protetta dal software del browser, non dall’hardware. Quindi può scaricare il pacchetto della vostra organizzazione, inviare eventi di audit e ottenere autorizzazioni di login per le sessioni attive di account condivisi di quella persona su quel dispositivo.
Non possono: Ottenere autorizzazioni per altre persone o altri dispositivi, firmare un pacchetto o modificare qualcosa nella console. Una copia del solo token smette di funzionare entro pochi minuti.
Cosa fare: Protezione degli endpoint, controllo delle applicazioni e controlli di conformità del vostro MDM. Quando lo sospettate, revocate il browser nella console e sospendete la persona nel vostro identity provider.

Malware o una persona con diritti di amministratoreNon difeso su quel laptop

Possono: Tutto quanto sopra, più rimuovere le policy di Chrome, disinstallare o sostituire l’estensione, installare un certificato che consenta di leggere il traffico HTTPS e cambiare l’orologio. Un amministratore determinato su un laptop aggira LayerT su quel laptop. Nessun controllo eseguito all’interno di un browser può impedirlo.
Non possono: Raggiungere altri laptop o la chiave di firma di LayerT.
Cosa fare: Nessun diritto di amministratore locale per il personale, e un MDM con protezione dalle manomissioni. Questo è il controllo più importante di questa pagina.

Un laptop rubato, sbloccatoRegge, con limiti

Possono: Tutto ciò che la persona poteva fare: usare i suoi accessi entro le vostre regole, e leggere il pacchetto dal suo profilo senza diritti di amministratore.
Non possono: Fare più di quanto potesse la persona, a meno di avere anche diritti di amministratore o di poter caricare estensioni modificate.
Cosa fare: Revocate il browser nella console, sospendete la persona nel vostro identity provider (le sue eccezioni escono dal pacchetto successivo), e bloccate o cancellate il laptop tramite il vostro MDM. Un blocco schermo a breve intervallo rende raro questo caso.

Un laptop rubato, bloccato, con cifratura del discoLayerT regge

Non possono: Leggere o modificare qualsiasi cosa nel profilo del browser. Il token del dispositivo smette di funzionare entro pochi minuti, e per rinnovarlo serve la chiave del browser, che si trova sul disco cifrato. Non esiste una credenziale di rinnovo di lunga durata.
Cosa fare: Revocate comunque il browser. Senza cifratura del disco, chi ha in mano il disco può leggere tutto il contenuto del profilo, e la chiave del browser è protetta dal software, non dall’hardware, quindi revocate tempestivamente.

Rimuovere o disattivare l’estensioneRegge, con limiti

Possono: Su un browser in cui LayerT non è stato installato forzatamente, una persona può disattivarlo o rimuoverlo. Gli altri browser, e i profili Chrome in cui LayerT non è configurato, sono del tutto al di fuori di LayerT.
Non possono: Disattivare o rimuovere un’estensione installata forzatamente tramite le impostazioni di Chrome.
Cosa fare: Installate LayerT forzatamente con il vostro MDM. I modelli di policy di Chrome di LayerT lo installano forzatamente e ne fissano l’icona, e disattivano la modalità di navigazione in incognito, la modalità ospite e il password manager integrato di Chrome. Il pacchetto firmato dell’estensione per l’installazione forzata è realizzato e verrà distribuito con il primo rilascio in produzione di LayerT. Consigliamo inoltre di impostare le policy di Chrome sugli strumenti per sviluppatori e sulla modalità sviluppatore, così nessuno può caricare una copia modificata. La vista della copertura nella console mostra i browser in cui LayerT può essere disattivato, quelli diventati silenziosi e quelli da cui è stato rimosso.

Registrazione, revoca e LayerT stesso

Un token del dispositivo copiatoRegge, con limiti

Possono: Agire come quel browser nei confronti di LayerT finché il token non scade, entro pochi minuti: scaricare il pacchetto dell’organizzazione, inviare eventi di audit e ottenere autorizzazioni per le sessioni attive di quella persona su quel dispositivo.
Non possono: Continuare una volta scaduto il token. Per rinnovarlo serve una prova firmata dalla chiave che quel browser ha creato per sé, che non può essere esportata tramite il browser, e non esiste una credenziale di rinnovo di lunga durata da copiare. Una prova intercettata non può essere riutilizzata, e una risposta di login intercettata è inutile senza la chiave. Non possono nemmeno registrare un browser a nome di qualcun altro: l’identità a cui un browser è legato è firmata da LayerT e verificata al momento della registrazione.
Cosa fare: Revocate il browser. La chiave non è protetta dall’hardware e questa non è un’attestazione del dispositivo, quindi il software eseguito con l’identità della persona su quel laptop può comunque usare lì la chiave: vedete “Malware eseguito con l’identità della persona”. La cifratura del disco tiene il profilo al riparo in caso di furto del disco.

Un browser di cui non avete motivo di fidarviRegge, con limiti

Possono: Chiunque possa effettuare il login tramite il vostro identity provider come una delle vostre persone può configurare LayerT in un browser, su qualsiasi macchina. Quel browser resta poi in attesa, e il suo popup lo dice.
Non possono: Ottenere un pacchetto, i gruppi della persona o qualsiasi account condiviso prima che un Owner o un IT Admin approvi il browser in Dispositivi. Sono i server di LayerT a respingere un browser in attesa o rifiutato, non solo l’estensione. Ciò che il browser riferisce sul modo in cui è stato installato è una sua dichiarazione: viene mostrato all’approvatore e non decide nulla.
Cosa fare: Approvate solo i browser che riconoscete, e rifiutate gli altri. L’approvazione è la decisione di una persona, non la prova che un dispositivo sia di proprietà dell’azienda o gestito. Un Owner o un IT Admin può approvare il proprio browser, e il registro di audit indica chi ha approvato. La persona con il cui account è stato configurato il browser non viene avvisata via email.

Un browser revocatoRegge, con limiti

Possono: Continuare a funzionare come un normale browser. Quando lo revocate, LayerT pubblica un pacchetto che lo elenca. Alla sincronizzazione successiva, smette di applicare le regole e di inviare segnalazioni. Il suo token del dispositivo attuale funziona fino alla scadenza, entro pochi minuti. Poi il rinnovo viene rifiutato, la registrazione viene annullata e il browser non riprova da solo.
Non possono: Ricevere la policy, accedere agli account condivisi o inviare segnalazioni a LayerT una volta escluso.
Cosa fare: La revoca esclude un browser da LayerT. Non blocca il browser, e un browser revocato non applica nulla. Per fermare una persona, sospendetela anche nel vostro identity provider, e bloccate o cancellate il laptop tramite il vostro MDM.

Una violazione dei server di LayerTRegge, con limiti

Possono: Un attaccante che controlla i server applicativi di LayerT può chiedere al servizio di gestione delle chiavi di firmare, finché mantiene quell’accesso. Potrebbe pubblicare un pacchetto permissivo od ostile per qualsiasi organizzazione, e i browser lo accetterebbero. Chi dispone solo del database può leggere i pacchetti di ogni organizzazione, che lì non sono cifrati, e può smettere di servirli.
Non possono: Copiare la chiave di firma al di fuori del servizio di gestione delle chiavi. Con il solo database non può firmare nulla, e i browser rifiutano le versioni più vecchie, quindi trattenere i pacchetti porta al comportamento fail-closed, non a regole vecchie.
Cosa fare: Dal lato di LayerT: solo i servizi di LayerT possono usare la chiave, e il servizio di gestione delle chiavi registra ogni richiesta di firma. Rimuovere l’accesso dell’attaccante chiude la finestra. I pacchetti già accettati restano finché non vengono sostituiti o scadono, entro 7 giorni. La stessa chiave firma per ogni organizzazione, quindi questo caso le riguarda tutte.

Compromissione della chiave di firmaRegge, con limiti

Possono: La chiave non può essere esportata dal servizio di gestione delle chiavi, quindi questo significa usarla impropriamente tramite il servizio, come sopra. Se la chiave dovesse mai essere sostituita, chiunque potesse firmare con essa e consegnare un pacchetto potrebbe far accettare quel pacchetto a qualsiasi browser finché la sostituzione non lo raggiunge.
Non possono: Usare la chiave una volta che LayerT ha distribuito un rilascio dell’estensione che non la contiene più.
Cosa fare: La sostituzione della chiave richiede un nuovo rilascio dell’estensione senza la vecchia chiave. Di solito Chrome distribuisce un aggiornamento entro alcune ore, o al riavvio del browser.

Cosa dovrebbe configurare il vostro team IT

Il pacchetto è affidabile solo quanto il laptop su cui è archiviato. Questi sono controlli standard di gestione dei dispositivi, e LayerT fa affidamento su di essi:

Cifratura completa del disco, imposta dal vostro MDM, e un blocco schermo a breve intervallo.
Nessun diritto di amministratore locale per il personale.
Installazione forzata di LayerT tramite il vostro MDM, usando i modelli di policy di Chrome di LayerT.
Approvare tempestivamente i nuovi browser, e solo quelli che riconoscete. Ogni nuovo browser resta in attesa in Dispositivi finché un Owner o un IT Admin non lo approva.
Blocco degli strumenti per sviluppatori delle estensioni e della modalità sviluppatore tramite policy di Chrome.
Tenere altri browser e profili Chrome non gestiti fuori dai laptop di lavoro, oppure accettare che LayerT non li veda.
Mantenere l’orologio sincronizzato e fuori dal controllo del personale.
Protezione degli endpoint in grado di individuare software che manomette i profili del browser.
Una procedura per chi lascia l’azienda o perde il laptop che faccia tre cose insieme: revocare il browser in LayerT, sospendere la persona nel vostro identity provider e bloccare o cancellare il laptop.
Tenere d’occhio la vista della copertura per individuare i browser diventati silenziosi o in cui LayerT può essere disattivato.

I limiti, in un unico elenco

Un pacchetto viene verificato quando arriva, non ogni volta che viene letto. Chiunque possa scrivere nello storage dell’estensione del profilo del browser, o abbia diritti di amministratore, può aggirare l’applicazione delle regole su quel laptop.
Ogni browser contiene il pacchetto dell’intera organizzazione, comprese le allowlist di altre persone e ogni eccezione attiva con valore, approvatore e motivazione. I pacchetti limitati a una singola persona non sono realizzati.
Un browser contiene solo le appartenenze ai gruppi della propria persona, come risposta firmata valida per 24 ore. Un browser offline conserva quella risposta finché non scade, quindi una persona tolta da un gruppo può continuare a corrispondere a una regola di gruppo fino a 24 ore su quel browser.
La chiave di ogni browser è protetta dal software del browser, non dall’hardware. Non può essere esportata tramite il browser, ma il software eseguito con l’identità della persona può usarla su quel laptop. La rotazione programmata di quella chiave non è realizzata.
L’approvazione di un browser è la decisione di una persona. Non dimostra che il dispositivo sia di proprietà dell’azienda o gestito.
Il pacchetto è archiviato come JSON in chiaro. A riposo, lo protegge solo la cifratura del disco del laptop.
La scadenza viene valutata in base all’orologio del laptop.
I pacchetti urgenti (arresto di emergenza, rollback, revoca) arrivano al cambio di pagina successivo o entro 15 minuti, come tutti gli altri.
La revoca di un browser gli impedisce di applicare le regole e di inviare segnalazioni. Non lo blocca.
La console mostra la versione che LayerT ha inviato per ultima a un browser, non la prova che il browser l’abbia accettata.
Un’unica chiave di firma firma per ogni organizzazione. Sostituirla richiede un rilascio dell’estensione.
La chiave di firma è protetta via software nel servizio di gestione delle chiavi, non custodita in un modulo di sicurezza hardware. La firma tramite un servizio di gestione delle chiavi è realizzata e in uso nell’ambiente di test di LayerT. Non c’è alcun deploy in produzione.

Cosa questa pagina lascia fuori. Questa pagina descrive la progettazione e i suoi limiti. Non elenca i singoli difetti prima che vengano corretti. Se ne trovate uno, scrivete a security@layert.net.

Pagine correlate: Policy firmata e applicazione · Limiti e lavori aperti · Fail-closed per progettazione