Le chiavi di casa della tua infrastruttura digitale: segreti, token, compliance ed etica

Questo articolo è pensato per chi guida IT, sicurezza e compliance in azienda — CISO, DPO, CTO — ma anche per amministratori e responsabili legali che devono capire cosa chiedere ai propri fornitori tecnologici prima di firmare un contratto o affrontare un audit.


Daresti le chiavi di casa a uno sconosciuto?

Immaginiamo di affidare a ogni fornitore, manutentore o visitatore una copia permanente delle chiavi di casa. Finché tutti si comportano correttamente può sembrare comodo; il problema nasce quando una chiave viene dimenticata, copiata o intercettata.

Nelle architetture applicative accade qualcosa di molto simile: password tecniche, certificati, chiavi API e altri segreti statici sono le chiavi di casa della rete digitale. Consentono a un servizio di riconoscersi presso un altro servizio, interrogare un database, invocare un'API o accedere a dati e funzionalità critiche.

Il punto debole è la loro natura statica. Se un segreto viaggia in chiaro, viene registrato in un log, finisce in un repository o viene sottratto a una macchina compromessa, un attaccante può usarlo finché non interviene una rotazione manuale. In uno scenario di man-in-the-middle, chi si pone in ascolto sul canale di comunicazione può intercettare credenziali che restano valide nel tempo. La bonifica richiede allora indagini, sostituzione coordinata delle chiavi, aggiornamenti di configurazione e verifiche su tutti i sistemi coinvolti: un'attività costosa, lenta e soggetta a errori.

Un esempio concreto. Un'azienda mantiene per due anni una chiave API "hardcoded" in un repository privato, usata da un microservizio per dialogare con il database clienti. La chiave non è mai stata ruotata. Un giorno il repository viene esposto per errore di configurazione, anche solo per poche ore. Da quel momento, indipendentemente dal fatto che qualcuno l'abbia effettivamente sfruttata, l'azienda si trova già in una posizione di potenziale inadempimento: non perché l'attacco sia avvenuto, ma perché l'architettura ha reso quell'attacco possibile.

Non si tratta soltanto di buona pratica tecnica. L'articolo 24 del D.Lgs. 138/2024, che attua la NIS 2, richiede misure tecniche adeguate allo stato dell'arte, incluse politiche di crittografia e controllo degli accessi. L'articolo 32 GDPR chiede misure idonee a garantire, tra l'altro, cifratura e resilienza dei sistemi di trattamento. Non serve attendere una violazione conclamata per rilevare un'inadeguatezza; può essere sufficiente che una violazione sia stata resa concretamente possibile da un'architettura prevedibilmente debole.

Il ticket dell'autobus: il token JWT

Un primo salto di qualità consiste nel sostituire la chiave consegnata senza scadenza con un biglietto temporaneo. Il JSON Web Token, o JWT, funziona proprio così: è un ticket digitale firmato. Un'applicazione mittente genera un token usando la propria chiave privata; il destinatario ne verifica l'autenticità con la corrispondente chiave pubblica. Nel token possono essere indicati identità del chiamante, destinatario, autorizzazioni e data di scadenza. Il segreto non deve quindi accompagnare ogni richiesta tra i servizi.

Il vantaggio è immediato. La finestra di esposizione si riduce perché il ticket ha una durata limitata e, in molte implementazioni, resta confinato nell'applicazione che lo emette. La rotazione delle chiavi può essere gestita sul solo mittente, invece di distribuire una nuova credenziale permanente a tutti i soggetti che ne dipendono. È un modello più ordinato, più verificabile e più vicino ai principi di privacy by design dell'articolo 25 GDPR e di sicurezza del trattamento dell'articolo 32.

Non è però una bacchetta magica. Anche le chiavi asimmetriche permanenti hanno un ciclo di vita: vanno inventariate, custodite, ruotate, revocate e monitorate. La Determinazione ACN n. 164179/2025 richiama l'esigenza di un inventario degli asset; in questo perimetro, chiavi, certificati e componenti che li gestiscono devono essere visibili, classificati e associati a un responsabile. Senza evidenze documentali, anche una soluzione tecnicamente valida può diventare difficile da dimostrare in audit o in caso di incidente.

Il notaio digitale: Workload Identity Federation

Lo stato dell'arte evolve. Invece di far firmare i ticket direttamente a ogni applicazione con una chiave duratura, entra in gioco un terzo imparziale: un identity provider. La Workload Identity Federation consente al provider di attestare l'identità di un carico di lavoro e di forgiare token JWT validi soltanto per la coppia mittente-destinatario identificata. Il token non viene memorizzato in modo persistente e, di norma, vive cinque o dieci minuti.

La metafora è quella del notaio: non consegna una chiave universale, ma certifica per un tempo breve che una specifica persona può accedere a una specifica porta. Se un attaccante penetra nella rete, trova molto meno materiale riutilizzabile da sottrarre. Anche intercettando un token in transito, disporrebbe di una finestra temporale strettissima e di autorizzazioni circoscritte a una sola applicazione destinataria. La segmentazione dell'accesso diventa parte intrinseca della credenziale, non una speranza affidata alla configurazione.

Standard aperti e maturi come OAuth 2.0 e OpenID Connect permettono di realizzare questo schema di federazione delle identità — i dettagli tecnici di implementazione meritano un approfondimento a parte, ma ciò che conta qui è l'effetto giuridico: in chiave NIS 2, il modello sostiene l'autenticazione continua, il principio del minimo privilegio e la gestione delle identità digitali richiesti dall'articolo 24 del D.Lgs. 138/2024. In chiave GDPR, fornisce una risposta concreta alle misure da valutare nella DPIA ai sensi dell'articolo 35. Per i sistemi di IA, la valutazione dei rischi prevista dall'articolo 9 dell'AI Act non può ignorare il canale applicativo attraverso cui circolano dati, modelli e istruzioni.

L'articolo 15 dell'AI Act richiede che i sistemi ad alto rischio siano resilienti ai tentativi di alterarne l'uso o di sfruttare vulnerabilità dell'infrastruttura, inclusi attacchi alla riservatezza e, a seconda del contesto, data poisoning o adversarial examples. Ridurre le credenziali permanenti non elimina tutti questi rischi, ma diminuisce una delle vie più comuni con cui un attore ostile può raggiungere dati, pipeline e servizi sensibili.

GDPR, NIS 2 e AI Act: la cornice normativa

GDPR, NIS 2 e AI Act convergono su un punto: la sicurezza non è un controllo aggiunto alla fine del progetto, ma una proprietà da progettare, mantenere e dimostrare.

GDPR (Regolamento UE 2016/679). L'articolo 25 impone la privacy by design: le misure tecniche di protezione devono essere integrate fin dalla fase di progettazione del sistema, tenendo conto dello stato dell'arte. L'articolo 32 richiede misure tecniche ed organizzative adeguate ad esempio cifratura, resilienza e test periodici dell'efficacia delle misure adottate. La CNIL ha chiarito che non è il verificarsi di una violazione ad integrare un inadempimento, bensì il fatto che questa si sia resa possibile per l'inidoneità delle misure adottate allo stato dell'arte (Délibération SAN-2026-001, 8 gennaio 2026 - orientamento dell'autorità francese, coerente con la prassi del Garante italiano). In chiave processuale, la Corte di Giustizia UE ha ulteriormente chiarito che il verificarsi di un data breach non prova automaticamente l'inadeguatezza delle misure, ma l'onere di dimostrare la loro concreta adeguatezza al rischio grava interamente sul titolare del trattamento (C-340/21, 14 dicembre 2023). Se i dati personali transitano attraverso applicativi che comunicano con segreti statici in chiaro, l’organizzazione risulta esposta a una valutazione di inadempimento. In caso di data breach derivante da secret leakage, in funzione della probabilità che la violazione presenti un rischio per i diritti e le libertà degli interessati, scatta l'obbligo di notifica al Garante entro 72 ore (art. 33 GDPR).

NIS 2 (D.Lgs. 4 settembre 2024, n. 138). Il decreto di recepimento della Direttiva NIS 2 impone ai soggetti essenziali e importanti di adottare misure tecniche, operative e organizzative adeguate allo stato dell'arte (art. 24). Tra queste: politiche di crittografia e cifratura, gestione delle identità digitali e del controllo degli accessi, autenticazione a più fattori o continua. L'Agenzia per la Cybersicurezza Nazionale (ACN), con Determinazione n. 164179 del 14 aprile 2025, ha dettagliato queste misure operative in un framework strutturato.

AI Act (Regolamento UE 2024/1689). Se l'infrastruttura applicativa alimenta o incorpora sistemi di intelligenza artificiale classificati ad alto rischio, entra in gioco anche l'AI Act. L'articolo 15 impone che tali sistemi siano progettati per essere resilienti ad attacchi informatici — inclusi data poisoning, model poisoning e adversarial examples — che possono essere resi possibili proprio dalla compromissione delle credenziali di autenticazione tra componenti applicativi. L'articolo 9 richiede un sistema di gestione dei rischi iterativo e continuo. L'articolo 26, paragrafo 9, crea un collegamento esplicito con il GDPR: il deployer deve usare le informazioni del fornitore AI per condurre la valutazione d'impatto sulla protezione dei dati ai sensi dell'art. 35 GDPR — rendendo DPIA e valutazione dei rischi AI un processo integrato.

La dimensione etica: sicurezza come responsabilità verso le persone

La sicurezza dell'infrastruttura digitale non è soltanto una questione tecnica e giuridica: è una questione etica.

Ogni applicazione che comunica in rete — con o senza il nostro intervento consapevole — porta con sé informazioni sulle persone: i clienti, i dipendenti, i cittadini che hanno affidato i propri dati all'organizzazione. Quando un segreto statico viene intercettato, non viene violata soltanto un'infrastruttura IT: vengono violati i diritti fondamentali delle persone fisiche che quell'infrastruttura serve.

Il legislatore europeo ha compreso questa dimensione. I principi sui quali si fonda una Trustworthy AI — elaborati già nelle Ethics Guidelines for Trustworthy AI del 2019 e ora cristallizzati nell'AI Act — sono la supervisione umana, il rispetto dei diritti fondamentali dell'individuo, la robustezza e la sicurezza degli algoritmi, il rispetto della privacy, la trasparenza intesa come tracciabilità dei sistemi, la non discriminazione, la tutela del benessere sociale e ambientale, e la responsabilità. Questi principi devono essere compatibili con i diritti garantiti dalla Carta dei diritti fondamentali dell'Unione europea, tra cui il diritto alla libertà e alla sicurezza (art. 6) e il diritto al rispetto della vita privata (art. 7) e art. 8 (protezione dei dati di carattere personale).

La Legge 23 settembre 2025, n. 132 — la legge italiana sull'intelligenza artificiale — ha recepito questa visione in termini ancora più netti. Il suo art. 3, comma 6, dispone che «al fine di garantire il rispetto dei diritti e dei principi» fondamentali «deve essere assicurata, quale precondizione essenziale, la cybersicurezza lungo tutto il ciclo di vita dei sistemi e dei modelli di intelligenza artificiale, secondo un approccio proporzionale e basato sul rischio». La sicurezza informatica non è dunque un accessorio del sistema: è la precondizione senza la quale nessun diritto può essere garantito.

Trasparenza e supervisione umana

Un sistema sicuro non è soltanto un sistema difficile da attaccare. È un sistema comprensibile, trasparente e sorvegliabile dall'essere umano. L'art. 14 dell'AI Act impone che i sistemi di IA ad alto rischio siano progettati e sviluppati in modo tale da poter essere efficacemente supervisionati da persone fisiche durante il periodo in cui sono in uso. La sorveglianza umana deve poter individuare e affrontare anomalie, disfunzioni e prestazioni inattese, e ignorare, annullare o ribaltare l'output del sistema quando necessario.

Questa prescrizione ha una valenza etica profonda: significa che nessun sistema automatizzato può essere lasciato operare in modo autonomo e imperscrutabile sulle vite delle persone. La distorsione dell'automazione — la tendenza a fare eccessivo affidamento sulle decisioni delle macchine — è un rischio esplicitamente riconosciuto dall'art. 14 dell'AI Act, e combatterla richiede scelte architetturali consapevoli, non solo policy organizzative.

Formazione e alfabetizzazione digitale

La sicurezza non può essere delegata soltanto alla tecnologia. Richiede persone formate e consapevoli. L'art. 4 dell'AI Act impone ai fornitori e ai deployer di sistemi di IA di adottare misure volte a sostenere lo sviluppo dell'alfabetizzazione in materia di IA del loro personale, nonché di qualsiasi altra persona che si occupa del funzionamento e dell'utilizzo dei sistemi di IA. Non si tratta di un obbligo formale: è il riconoscimento che una tecnologia potente e sicura nelle mani di chi non la comprende rimane una tecnologia pericolosa.

Chi risponde quando qualcosa va storto?

Sul piano della responsabilità, il quadro normativo europeo ha effettuato una scelta precisa: la responsabilità non ricade sugli algoritmi, ma sulle persone e sulle organizzazioni che li progettano, distribuiscono e utilizzano. Il titolare del trattamento risponde non soltanto quando subisce un attacco, ma quando — indipendentemente dall'attacco — non ha adottato le misure che lo stato dell'arte richiedeva. La Corte di Giustizia dell'Unione europea ha chiarito (causa C-340/21) che «il verificarsi di un data breach non prova automaticamente l'inadeguatezza delle misure; tuttavia l’onere della prova dell’adeguatezza grava interamente sul titolare, che deve dimostrare in concreto la proporzionalità delle misure ai rischi del trattamento».

Questo principio ha una conseguenza etica diretta: l'inerzia è già una scelta. Scegliere di non aggiornare l'architettura di autenticazione, di non adottare token effimeri, di non implementare la Workload Identity Federation non è una scelta neutrale: è una scelta che espone le persone a un rischio evitabile. Il diritto ha tradotto questa responsabilità in sanzioni. Ma prima ancora che il diritto la sanzionasse, l'etica la condannava.

L'art. 3 della L. 132/2025 parla esplicitamente di sviluppo dell'IA «nel rispetto dell'autonomia e del potere decisionale dell'uomo, della prevenzione del danno, della conoscibilità, della trasparenza, della spiegabilità». Questi non sono soltanto principi normativi: sono impegni verso le persone.

Il quadro sanzionatorio: la compliance non è optional

L'adozione di architetture di autenticazione allo stato dell'arte non è più una scelta opzionale. È un requisito di conformità documentabile — e la sua assenza comporta conseguenze severe:

Le sanzioni massime

GDPR Artt. 25 e 32, Reg. (UE) 2016/679 fino a €10 milioni o 2% del fatturato globale;

NIS 2 Art. 24, D.Lgs. 138/2024 fino a €10 milioni o 2% del fatturato per i soggetti essenziali e fino a €7 milioni o 1,4% per i soggetti importanti;

AI Act Artt. 9, 15, 26, Reg. (UE) 2024/1689 fino a €15 milioni o 3% del fatturato globale.

L'adozione di misure allo stato dell'arte è altresì un fattore attenuante esplicito nel calcolo della sanzione GDPR (art. 83, comma 2, lett. d): dimostrare di aver implementato la Workload Identity Federation, di aver condotto una DPIA e di aver documentato il sistema di gestione dei rischi AI riduce concretamente l'esposizione sanzionatoria.

La posta in gioco non è solo tecnica

Proteggere le comunicazioni tra applicativi con identità federate e token effimeri non è soltanto una scelta di eccellenza ingegneristica. È la risposta giuridicamente più robusta — e, prima ancora, eticamente dovuta — a un quadro normativo che chiede prevenzione, proporzionalità, resilienza e prova delle misure adottate. La serratura giusta non consegna una chiave valida per tutto e per sempre: concede un accesso limitato, verificabile e revocabile alla porta giusta, per il tempo necessario.

La domanda, per chi guida IT, sicurezza e compliance, non è più se adottare queste soluzioni. È quando farlo, su quali flussi prioritari e come documentarlo nel registro delle attività di trattamento, nella DPIA e nella valutazione del rischio cyber e AI. Partire dai segreti statici più esposti, mappare le dipendenze e definire un percorso verso la Workload Identity Federation permette di trasformare un requisito normativo — e un dovere etico — in una riduzione concreta del rischio.

La buona notizia è che la soluzione tecnologicamente più robusta — token effimeri, non persistenti, legati all'identità del workload attraverso un terzo imparziale — è anche quella che meglio risponde ai requisiti di GDPR, NIS 2 e AI Act, e ai principi etici che li ispirano. Non si tratta di scegliere tra sicurezza, compliance ed etica: si tratta di riconoscere che, oggi, le tre cose coincidono.

Domande frequenti

Un JWT basta per essere "compliant"? No. Il JWT riduce l'esposizione perché il ticket ha durata limitata, ma la chiave asimmetrica che lo firma resta comunque un asset da inventariare, ruotare e monitorare. È un passo avanti rispetto al segreto statico permanente, non un punto di arrivo.

La Workload Identity Federation è obbligatoria per legge? Nessuna norma la nomina esplicitamente. Ma GDPR, NIS 2 e AI Act richiedono misure "adeguate allo stato dell'arte": se la WIF rappresenta oggi lo stato dell'arte per la gestione delle identità dei workload, la sua assenza — in assenza di misure equivalenti — può essere valutata come inadeguatezza delle misure di sicurezza adottate.

Cosa succede se subiamo un attacco pur avendo adottato queste misure? L'adozione di misure allo stato dell'arte non elimina il rischio, ma sposta la valutazione giuridica: la Corte di Giustizia UE ha chiarito che il verificarsi di un data breach non prova automaticamente l'inadeguatezza delle misure; tuttavia l’onere della prova dell’adeguatezza grava interamente sul titolare, che deve dimostrare in concreto la proporzionalità delle misure ai rischi del trattamento. Le misure adottate diventano inoltre un fattore attenuante esplicito nel calcolo di eventuali sanzioni GDPR.

Le chiavi di casa della tua infrastruttura digitale: tienile al sicuro.

📩 Vuoi verificare lo stato della tua organizzazione? Scrivimi per ricevere il kit di domande per l'audit interno su segreti, token e identità dei workload.