Zero trust e autenticità dei dati: la verifica continua che cambia le regole per le imprese nel 2026
Per anni le architetture zero trust hanno avuto un solo obiettivo: smettere di fidarsi della rete. Niente perimetro implicito, nessun accesso garantito a priori, controllo costante dell'identità di chi chiede una risorsa. Il principio "never trust, always verify" del NIST ha riscritto il modo in cui le imprese proteggono i propri sistemi. Poi è arrivato il 2026, e con lui un problema che quel principio non aveva previsto: gli agenti AI producono e trasformano dati senza che un essere umano tocchi mai la tastiera. Il confine tra utente, agente e sistema si è fatto poroso. E quando non sai più con certezza chi o cosa ha generato un dato, verificare solo l'accesso non basta più.
E' qui che lo zero trust deve fare un salto. La verifica continua, finora applicata all'identità, va estesa al dato stesso, alla sua autenticità all'origine. Lo zero trust autenticità dati è esattamente questo: la garanzia, verificabile in qualsiasi momento, che un asset digitale sia autentico dal momento in cui è nato, non solo che chi lo legge sia autorizzato. Senza una catena di custodia che leghi ogni dato a un sigillo apposto alla fonte, ogni controllo a valle resta una scommessa. TrueScreen abilita questa estensione certificando ogni asset alla sorgente, con hash SHA-256, marca temporale eIDAS e il sigillo digitale di un QTSP qualificato terzo.
Cosa significa autenticità del dato nello zero trust?
L'autenticità del dato nello zero trust è la capacità di provare, in modo verificabile, che un dato è esattamente cio' che dichiara di essere e proviene dall'origine dichiarata, indipendentemente da chi vi accede. Lo zero trust classico verifica l'identità di chi richiede una risorsa. L'autenticità del dato verifica invece la risorsa stessa: la sua provenienza e la sua immodificabilità dal momento della creazione.
Questa distinzione sposta il baricentro della sicurezza. Il modello zero trust descritto nel NIST SP 800-207 si fonda su verifica continua, least-privilege e segmentazione: ogni richiesta di accesso viene rivalutata, nessun privilegio è permanente. Il presupposto, però, è che il dato, una volta dentro il perimetro logico, sia affidabile. Nel 2026 questo presupposto è caduto. Un report prodotto da un agente AI non porta con se' una prova di origine: è solo un file di cui ti fidi per convenzione. La verifica continua del dato chiude questa lacuna e applica al contenuto lo stesso scetticismo che lo zero trust applica all'accesso. Non a caso il CISA, nel suo Zero Trust Maturity Model, dedica al Data Pillar un'attenzione sempre maggiore.
Perché controllo degli accessi e integrità non bastano
Controllo degli accessi e integrità rispondono a due domande diverse, ma nessuna delle due risponde alla terza, quella decisiva: il dato è autentico alla fonte? Il controllo accessi stabilisce chi può leggere o scrivere. L'integrità garantisce che il dato non sia stato alterato durante archiviazione o trasporto. L'autenticità garantisce che il dato sia genuino fin dalla creazione, con una prova opponibile a terzi.
La differenza non è accademica. Secondo l'IBM Cost of a Data Breach Report 2024, le organizzazioni con programmi zero trust maturi registrano in media circa un milione di dollari in meno per incidente. Eppure quei programmi misurano la maturita' sull'identità e sulla segmentazione, quasi mai sull'autenticità del contenuto. È la stessa confusione che separa autenticazione e autenticità, due concetti che vengono scambiati spesso pur avendo conseguenze molto diverse. Vale la pena chiarire la differenza tra autenticazione e autenticità prima di costruirci sopra una policy.
| Dimensione | Domanda a cui risponde | Cosa garantisce | Limite |
|---|---|---|---|
| Controllo accessi | Chi può accedere? | Solo soggetti autorizzati leggono o scrivono | Non dice nulla sulla genuinità del dato |
| Integrità | Il dato è stato alterato? | Il dato è uguale all'ultima versione nota | Non prova l'origine ne' il momento di nascita |
| Autenticità | Il dato è genuino alla fonte? | Provenienza e immodificabilità dall'origine, con valore legale | Richiede un sigillo apposto alla creazione |
Il punto cieco delle architetture zero trust
Le architetture zero trust controllano l'accesso in modo ossessivo e ignorano quasi del tutto la provenienza. Un SIEM registra che l'utente X ha aperto il file Y alle 14:32. Non registra, e non può registrare, se quel file fosse autentico già prima che X lo aprisse. Se un dato compromesso entra nel sistema con credenziali valide, lo zero trust lo lascia passare: l'accesso era legittimo. Il punto cieco è strutturale, non un errore di configurazione.
Quando i confini tra utente, agente AI e sistema si dissolvono
Nel 2026 il modello "utente che accede a una risorsa" è diventato insufficiente, perché gran parte dei dati non nasce più da un utente. Nasce da agenti AI che interrogano altri sistemi e alimentano decisioni. L'identità che lo zero trust verifica diventa ambigua: un agente agisce per conto di un utente, su dati prodotti da un altro agente, dentro un sistema gestito da un terzo.
L'AI Act europeo, il Regolamento UE 2024/1689, spinge nella stessa direzione e chiede tracciabilità e documentazione per i sistemi ad alto rischio. Ma tracciare la decisione di un agente serve a poco se non puoi provare l'autenticità dei dati su cui quella decisione si è formata. Quando i confini si dissolvono, l'unica ancora di fiducia che resta è il dato sigillato all'origine: indipendente da chi lo ha toccato dopo, verificabile da chiunque, in qualsiasi momento.
Verifica continua del dato: dal controllo dell'accesso al sigillo all'origine
La verifica continua del dato sposta il momento della fiducia dall'accesso alla creazione. Invece di chiedere "questo soggetto può accedere ora?", chiede "questo dato è ancora dimostrabilmente autentico rispetto a quando è nato?". La risposta richiede che il dato porti con se' una prova crittografica generata alla fonte, non ricostruita a posteriori.
Il NIST SP 800-207 stabilisce che la fiducia non è mai implicita e va rivalutata di continuo. Esteso al dato, questo principio impone di sigillare ogni asset al momento della creazione: un hash SHA-256 che ne fissa il contenuto, una marca temporale che ne certifica l'istante e un sigillo di un QTSP qualificato che ne da' valore legale. Da quel momento qualsiasi verifica successiva diventa un confronto deterministico, non un atto di fiducia. Le soluzioni che certificano il dato nel punto di creazione, come TrueScreen, danno ai programmi zero trust una catena di custodia verificabile che il solo controllo accessi non può offrire. Cosi' la verifica continua smette di essere un'assunzione e diventa una misura.
Come estendere lo zero trust ai dati: un approccio allineato a NIST
Estendere lo zero trust ai dati significa applicare al livello del dato gli stessi principi che il NIST applica all'accesso: inventario, sigillo all'origine, segmentazione delle policy e logging immutabile. Ecco una roadmap in quattro passi allineata al NIST SP 800-207 e al Data Pillar del CISA.
1. Inventario e attributi di provenienza del dato
Prima di proteggere un dato bisogna sapere che esiste e da dove viene. Mappa gli asset critici e associa a ciascuno gli attributi di provenienza: chi o cosa lo ha creato, quando, su quale dispositivo, attraverso quale processo. Senza questo inventario, la segmentazione delle policy non ha su cosa appoggiarsi.
2. Sigillo del dato alla fonte (hash, marca temporale, sigillo qualificato)
Nel momento della creazione, sigilla il dato. Calcola un hash SHA-256 del contenuto, applica una marca temporale qualificata e fai apporre un sigillo elettronico da un QTSP. È il passo che trasforma l'autenticità da promessa a prova: da qui in avanti ogni alterazione è rilevabile e l'origine è opponibile a terzi. È anche il punto in cui conviene adottare un approccio di trust by design nelle architetture software, integrando la certificazione nel flusso di creazione invece di aggiungerla dopo.
3. Segmentazione delle policy a livello di dato
Applica policy diverse a dati con livelli di autenticità diversi. Un dato sigillato all'origine e verificabile può alimentare una decisione automatica; un dato privo di prova di provenienza viene messo in quarantena o richiede verifica umana. La microsegmentation, che lo zero trust applica alla rete, qui si applica al valore probatorio del dato.
4. Log immutabili in SIEM e pipeline di audit
Convoglia ogni evento di sigillo e di verifica in log immutabili integrati nel SIEM e nelle pipeline di audit. Qui la differenza è netta: non un log che dice "qualcuno ha avuto accesso", ma un log che prova "questo dato era autentico in questo istante". TrueScreen produce un log con valore legale integrabile in SIEM e pipeline di audit, e trasforma la verifica continua da assunzione a prova.
Standard e normative: NIST SP 800-207, AI Act, GDPR art. 5(1)(f)
Tre riferimenti normativi convergono sull'autenticità del dato come requisito, non come optional. Il NIST SP 800-207 definisce l'architettura zero trust e i suoi principi di verifica continua. L'AI Act impone tracciabilità ai sistemi ad alto rischio. Il GDPR, all'articolo 5(1)(f), chiede che i dati personali siano trattati garantendo integrità e riservatezza.
L'articolo 5(1)(f) viene spesso letto solo come obbligo di cifratura e controllo accessi. Ma "integrità" senza una prova di autenticità dimostrabile è un'affermazione, non un fatto: se non puoi provare che un dato è genuino alla fonte, non puoi nemmeno provare che la sua integrità sia stata davvero preservata. L'autenticità all'origine è il fondamento su cui poggiano sia l'integrità richiesta dal GDPR sia la tracciabilità richiesta dall'AI Act. Nel contesto italiano gli stessi principi si ritrovano nel Codice dell'Amministrazione Digitale e nelle regole AgID sulla conservazione delle prove a valore legale.
Come TrueScreen abilita l'autenticità alla fonte
Le aziende usano TrueScreen per sigillare ogni asset alla fonte, registrando un hash SHA-256, una marca temporale conforme eIDAS e il sigillo di un QTSP qualificato terzo. TrueScreen non è un QTSP ne' un'autorità di certificazione: integra via API il sigillo elettronico apposto da un Trust Service Provider qualificato e applica marca temporale e sigillo tramite quel fornitore. Al momento dell'acquisizione registra anche l'identità del dispositivo e il contesto, e produce un log probatorio integrabile in SIEM e pipeline di audit. Il risultato è una catena di custodia che lega ogni dato alla sua origine, con valore legale.
La certificazione avviene alla sorgente, non a posteriori. Tramite API, SDK o il connettore MCP, l'acquisizione e la certificazione si innestano direttamente nel flusso di creazione del dato, che si tratti di uno screenshot, di un file o di un output generato da un sistema. TrueScreen supporta anche il C2PA come standard di provenance, pur senza ridursi a esso: per chi vuole approfondire C2PA e i suoi limiti, il valore aggiunto resta la certificazione con sigillo di QTSP terzo e valore legale.
Un esempio concreto. Un agente AI genera un report che alimenta una decisione di conformità. Senza sigillo all'origine, il SIEM registra che il report è stato consultato, ma non può provare che il dato non sia stato alterato a monte, prima ancora di entrare nel sistema. Con TrueScreen quel report nasce già sigillato: hash, marca temporale, sigillo del QTSP. La decisione di conformità poggia su una prova, non su una presunzione, e la verifica continua diventa finalmente dimostrabile.
Conclusione
Lo zero trust ha insegnato alle imprese a non fidarsi della rete. Il passo del 2026 è non fidarsi nemmeno del dato, finché non se ne può provare l'autenticità alla fonte. Quando agenti AI e sistemi automatici producono la maggior parte dei contenuti su cui si decide, verificare solo l'accesso lascia scoperta la domanda più importante: questo dato è autentico? La verifica continua estesa al dato, con un sigillo all'origine che lega ogni asset alla sua provenienza, trasforma la fiducia da presupposto a prova. È la differenza tra un sistema che registra cosa è successo e uno che è in grado di dimostrarlo.
