Architettura
Gestione dei dati
Cosa conserva LayerT, dove lo conserva, per quanto tempo e cosa non raccoglie mai. Scritto perché il vostro team privacy possa compilare i propri registri senza bisogno di una call.
Descrive LayerT così come realizzato al 3 ottobre 2026. Tutto ciò che non è ancora realizzato è indicato come tale.
Cosa archivia LayerT
| Dati | Dove | Protetti da | Conservati per |
|---|---|---|---|
| Persone della vostra directory: nome, email, qualifica, responsabile, stato attivo | Postgres | Controlli di accesso; la fonte è la vostra directory | Finché sono nella vostra directory; le persone disattivate vengono conservate per la traccia di audit |
| Gruppi e appartenenze | Postgres | Controlli di accesso | Secondo quanto indica la vostra directory |
| Dispositivi: ogni browser configurato con LayerT, a chi appartiene, la metà pubblica della sua chiave, se è in attesa, approvato o rifiutato, quando è stato deciso, e ultimo accesso | Postgres | Controlli di accesso. La metà privata della chiave non lascia mai il browser | I dispositivi revocati vengono rimossi dopo 90 giorni di inattività |
| Eventi di audit: la regola, l’indirizzo della pagina, il campo e il valore corrispondente. Per una regola sui moduli il valore è il testo del campo, e per una regola sull’incolla il testo incollato | Postgres | Controlli di accesso; leggibili di default. Ogni regola sceglie cosa viene conservato dei propri valori: come sono stati digitati, parzialmente mascherati, oppure nulla. L’impostazione viene applicata sul server all’arrivo dell’evento | 365 giorni di default, configurabile |
| Testo digitato che ha fatto scattare una regola sulla digitazione: l’intero campo com’era quando la regola ha trovato la corrispondenza, fino a 10.000 caratteri | Postgres, come valore dell’evento di audit | Come qualsiasi valore corrispondente | Insieme al registro di audit |
| File che hanno fatto scattare una regola sui file: il nome, il tipo e la dimensione del file, il modo in cui è stato consegnato alla pagina e se LayerT ha potuto leggerlo. Mai il testo del file | Postgres, insieme all’evento di audit | Come qualsiasi valore corrispondente | Insieme al registro di audit |
| I motivi che le persone indicano per proseguire oltre un blocco, con le loro parole | Postgres, insieme all’evento di audit | Controlli di accesso. Se la persona ha digitato il valore bloccato nel proprio motivo e la regola nasconde o maschera i valori, il valore viene nascosto o mascherato anche lì | Insieme al registro di audit |
| Richieste di accesso: il valore, il sito, la motivazione della persona | Postgres | Controlli di accesso | 180 giorni dopo la chiusura, a meno che un’eccezione attiva dipenda da esse |
| Password degli account condivisi, chiavi di configurazione dell’app di autenticazione e campi di login segreti | Postgres | Cifratura a busta (envelope encryption) AES-256-GCM, una chiave dati per account | Finché l’account non viene eliminato o il segreto sostituito |
| Campi di login visibili (come un ID account) e note dell’account, con la cronologia delle modifiche di ogni nota | Postgres | Controlli di accesso | Finché l’account non viene eliminato |
| Sessioni degli account condivisi | Postgres | Controlli di accesso | 180 giorni dopo la fine |
| Gateway che aggiungete: nome, regione, nome host, gli indirizzi che LayerT ha misurato per esso e il suo stato | Postgres | Controlli di accesso | Conservati dopo la rimozione di un gateway, per la traccia di audit |
| Sessioni con routing: tramite quale gateway è uscita una sessione, e l’indirizzo che il fornitore ha visto | Postgres | Controlli di accesso. La credenziale del gateway della sessione è archiviata solo come hash | Insieme alla sessione |
| Registrazioni delle sessioni | Object storage | AES-256-GCM, una chiave nuova per ogni registrazione, cifrata sul dispositivo | 90 giorni di default, configurabile da 7 a 365 |
| Indice delle registrazioni: quale sessione, quali pagine, tempi | Postgres | Controlli di accesso | Eliminato insieme alla registrazione |
| Versioni firmate della policy | Postgres | Firma Ed25519 | Le ultime 20, più tutte quelle degli ultimi 30 giorni |
| Esiti dei login: se il login a un account condiviso è riuscito, e a quale passaggio si è fermato. Nessun valore né testo della pagina | Postgres | Controlli di accesso | 90 giorni |
| Informazioni sul dispositivo: versione dell’estensione, il modo in cui il browser dichiara di essere stato installato, browser, sistema operativo | Postgres | Controlli di accesso | Insieme al dispositivo |
| Notifiche e relativi record di consegna | Postgres | Controlli di accesso; non contengono mai un segreto né un valore completo | 30 giorni |
| Revisioni degli accessi: chi ha confermato che una persona ha ancora bisogno di un certo account, e il report | Postgres | Controlli di accesso; ogni report e CSV riporta un checksum SHA-256 | 7 anni |
| Caselle condivise che collegate: i dati di connessione e di accesso, e la conferma dell’Owner che si tratta di un indirizzo aziendale | Postgres | I dati di accesso usano la stessa cifratura a busta delle password degli account condivisi | Finché la casella non viene rimossa |
| Copie della posta di una casella condivisa collegata | Object storage; mittente, oggetto e data in Postgres | AES-256-GCM, una chiave dati per casella. Anche i codici e i link che LayerT estrae sono cifrati | 30 giorni di default, al massimo 365. Eliminate 7 giorni dopo lo scollegamento della casella |
| Chi ha letto quale email in una casella condivisa, e a chi è stato mostrato quale codice | Postgres | Controlli di accesso | Insieme al registro di audit |
Cosa registrano le vostre regole
LayerT legge solo i campi indicati dalle 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.
- Leggibile di default. Il valore che ha fatto scattare una regola sui moduli o sull’incolla viene inviato ai server di LayerT e conservato in forma leggibile, così un auditor può vedere cosa è stato fermato.
- Una regola sulla digitazione conserva l’intero campo, non solo la parte che corrispondeva, fino a 10.000 caratteri.
- Una regola sui file conserva il nome, il tipo e la dimensione del file, il modo in cui è stato consegnato alla pagina e se LayerT lo ha letto. Non conserva mai il testo del file.
- Nessuna regola legge una password o un codice compilati da LayerT. Qualunque sia il trigger, una regola salta una password, un codice monouso o un campo di login segreto compilati da LayerT, quindi la password di un account condiviso non può finire in ciò che una regola registra.
- Il nome utente che LayerT compila viene comunque valutato. Durante il login a un account condiviso, una regola sui login che copre la pagina vede comunque il nome utente compilato da LayerT. Lascia passare il login e lo registra come eccezione, con il nome utente.
- Una regola sulla digitazione non legge mai una casella della password, né una casella del codice monouso, in nessun caso, né un campo compilato da LayerT.
- Una regola sui moduli o sull’incolla legge i campi che indica, e tra questi può esserci una casella della password in cui una persona ha digitato da sé. Un valore del genere viene registrato in forma leggibile a meno che la regola non sia impostata per mascherare o nascondere i propri valori.
- L’impostazione viene applicata sul server. Il browser invia sempre il valore. La scelta di ogni regola (come digitato, parzialmente mascherato, oppure nulla) viene applicata sui server di LayerT prima che qualsiasi cosa venga archiviata. I valori non vengono oscurati nel browser.
- Gli indirizzi delle pagine vengono registrati solo insieme a un evento: quando una regola trova una corrispondenza, quando qualcuno chiede un’eccezione e, senza la query, quando viene segnalato se il login a un account condiviso è riuscito o no. Non viene conservato né inviato alcun elenco delle pagine visitate.
- Gli eventi in attesa di invio restano nel browser. Lo storage dell’estensione può contenere eventi non ancora inviati, compresi i valori che hanno fatto scattare una regola, finché non vengono consegnati.
Cosa non lascia mai il laptop
- Qualsiasi cosa digitata in un campo non indicato da alcuna regola, al di fuori di una sessione registrata. Cosa contiene una registrazione è spiegato in Sessioni e registrazione.
- Il testo contenuto in un file. Una regola sul testo dei file lo legge nel browser per decidere. Non viene mai inviato né archiviato.
- La metà privata della chiave che ogni browser crea per sé.
- La cronologia di navigazione delle vostre persone, le pagine non coperte da alcuna regola e i valori dei cookie. LayerT non li raccoglie.
- La chiave grezza della registrazione, dopo che è stata consegnata una sola volta per essere cifrata (wrap).
- Ciò che le persone digitano nei campi dei moduli e negli editor di testo formattato durante una sessione registrata: è mascherato nel punto in cui lo digitano, prima che qualsiasi cosa venga cifrata. Una registrazione mostra comunque ciò che la pagina mostra a sua volta dopo che è stato digitato, e gli indirizzi delle pagine e delle richieste.
Cosa riceve l’estensione
Ogni browser approvato nella vostra organizzazione riceve la policy firmata della vostra organizzazione. Quella policy include le regole, e le eccezioni approvate e le impostazioni per persona di cui le regole hanno bisogno, come i numeri di telefono aziendali o gli account personali approvati. Trattate la policy come un documento interno alla vostra organizzazione.
Le appartenenze ai gruppi non sono nella policy. Ogni browser riceve anche, separatamente, una risposta firmata che indica i gruppi della directory della propria persona, valida per 24 ore. Non riceve mai quelli di qualcun altro.
Per un account condiviso che esce tramite un gateway, il browser della persona in quella sessione riceve anche quale gateway usare, una credenziale valida solo per quella sessione e l’indirizzo che il fornitore vedrà.
Le password degli account condivisi, i campi di login segreti e i codici dell’app di autenticazione vengono inviati solo al browser registrato di una persona con una sessione attiva, solo quando servono per effettuare il login, e non vengono mai archiviati nel browser da LayerT.
C’è un solo altro modo in cui un segreto lascia i server di LayerT: una richiesta di password. Qualcuno chiede, con una motivazione, di vedere una password, una chiave di configurazione dell’app di autenticazione o un campo segreto. Altre due persone devono approvare, e una di loro deve essere un Owner o un Compliance Officer. La persona che ha fatto la richiesta lo vede poi una sola volta, nella console, dopo aver effettuato di nuovo il login negli ultimi 10 minuti. Il valore viene contrassegnato come visto, e al proprietario dell’account viene chiesto di cambiarlo.
Eliminazione
- Persone: disattivare qualcuno nella vostra directory ne termina subito l’accesso. I suoi record restano per la traccia di audit fino alla fine del periodo di conservazione.
- La vostra organizzazione: quando un’organizzazione chiude, LayerT ne conserva i dati per un periodo di tolleranza di 30 giorni, poi elimina tutto in un unico passaggio, comprese le registrazioni archiviate, e registra una ricevuta dell’eliminazione.
- Registrazioni e record datati: eliminati automaticamente da job giornalieri di conservazione, e ogni eliminazione di una registrazione viene registrata nel log.
- Copie delle caselle condivise: eliminate quando superano il periodo di conservazione della casella, e 7 giorni dopo lo scollegamento di una casella.
Portare con sé i propri dati
Un Owner può esportare l’intera organizzazione in un unico file zip, comprese tutte le registrazioni conservate, decifrate in modo da poter essere guardate al di fuori di LayerT. Un manifest elenca un checksum SHA-256 per ogni file. L’esportazione non include mai password, chiavi di configurazione dell’app di autenticazione o campi segreti, e la sua creazione viene scritta nel registro di audit.
Il registro di audit stesso può essere esportato in CSV o JSON Lines da Owner, IT Admin, Compliance Officer e Auditor. I valori digitati sono esclusi, a meno che la persona non spunti una casella per includerli.
Sub-responsabili e ubicazione
LayerT girerà su due fornitori di infrastruttura. Ciascuno tratta i vostri dati solo su istruzione di LayerT, nell’ambito di un accordo sul trattamento dei dati.
| Fornitore | Entità contraente | Uso previsto |
|---|---|---|
| Google Cloud | Google Cloud EMEA Limited (Irlanda) | La console, l’API e il worker, il database, l’archiviazione delle registrazioni, i log e il servizio di gestione delle chiavi. Regione: Milano (europe-west8). Chiavi e backup del database: multi-regione UE di Google |
| Cloudflare | Cloudflare, Inc. (Stati Uniti) | DNS per layert.net e invio delle email di notifica |
Se la vostra organizzazione collega Slack, le notifiche agli approvatori passano attraverso il vostro workspace Slack, nell’ambito del vostro accordo con Slack. Anche il vostro identity provider e il vostro MDM sono vostri, quindi non sono sub-responsabili di LayerT.
Se state compilando un registro dei trattamenti
- Finalità: controllare a quali account le persone accedono sui dispositivi di lavoro, applicare le vostre regole a moduli, operazioni di incolla, testo digitato e file consegnati a una pagina, fare da intermediario per l’accesso agli account condivisi e mantenere una traccia di audit di tutte e tre le cose.
- Interessati: i vostri dipendenti e collaboratori esterni i cui browser sono configurati con LayerT.
- Categorie particolari: LayerT non si propone di trattarle. Ciò che una regola registra contiene ciò che corrispondeva alla regola, quindi il suo contenuto dipende dalle regole che scrivete, e una regola sulla digitazione conserva l’intero campo. Una registrazione può catturare qualsiasi cosa mostri la pagina di un fornitore, ed è per questo che la registrazione richiede prima l’attestazione dell’Owner.
- Base giuridica: spetta a voi determinarla. LayerT chiede all’Owner di registrarla prima che qualsiasi registrazione possa avvenire.