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 19 settembre 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 gli invii dei moduli 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.

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": "Example Trading Ltd",
  "killSwitch": false,
  "critical_update": false,
  "revoked_devices": ["b7e0c1d2-5a6f-4e3b-8c9d-1a2b3c4d5e6f"],
  "classifiers": [
    { "id": "corp_email", "type": "email_domain", "value": "example-trading.test" }
  ],
  "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 Example Trading.",
        "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": {
    "grp_finance": ["user:[email protected]", "user:[email protected]"]
  },
  "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:

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, credenziali di rinnovo o chiavi di firma. Il pacchetto indica la chiave che lo ha firmato. Non contiene mai una chiave.
• 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

Il ciclo di vita di un pacchetto

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.

In produzione, la chiave privata di firma risiede in Google Cloud KMS, configurata con protezione basata su hardware (HSM), e non può essere esportata. I server di LayerT inviano i byte a KMS e ricevono in cambio una firma. La configurazione di produzione si rifiuta di avviarsi con un file di chiave locale. Questo è realizzato e si attiva con il primo deploy in produzione di LayerT. Fino ad allora, le build di sviluppo e di test 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. 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. 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:

1. Versione. Deve essere più alta della versione già archiviata. Questo impedisce di riproporre un pacchetto vecchio.
2. Organizzazione. Deve appartenere all’organizzazione a cui è legato questo browser. Il browser si lega alla propria organizzazione quando accetta il suo primo pacchetto autentico.
3. Chiave. Deve indicare una chiave di firma integrata nell’estensione.
4. Formato. La firma deve essere una firma Ed25519 ben formata.
5. Firma. La firma deve risultare valida sui byte canonici.
6. 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 e la credenziale di rinnovo) ed eventuali eventi di audit non ancora inviati, che possono includere valori digitati dalle persone.

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. 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,
• 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.

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ù), i gruppi, 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.

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

La rete e la pagina web

Persone e software sul laptop

Registrazione, revoca e LayerT stesso

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.
• 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.
• 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 firma tramite Cloud KMS è realizzata e si attiva con il primo deploy in produzione di LayerT. Le attuali build di sviluppo firmano con una chiave locale.

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