La BSI in Germania è l’equivalente della nostra ACN in Italia. L’iniziativa tedesca rappresenta un punto interessante da replicare nel nostro Paese perchè il cloud sovrano certificato merita un framework nazionale, regolamentare e normativo. Un primo passo importante che dovremmo seguire subito.

Sommario

L’era dell’autonomia digitale europea e la via tracciata dalla Germania da seguire in Italia

La sovranità digitale rappresenta oggi la capacità fondamentale di istituzioni e individui di operare nello spazio virtuale in modo indipendente e sicuro. Essa costituisce un pilastro strategico imprescindibile per garantire l’autonomia politica di un intero sistema paese. Ma dobbiamo analizzare gli elementi cardine necessari per raggiungere tale obiettivo attraverso l’adozione di criteri oggettivi e verificabili per l’autonomia del cloud computing. Risulta essenziale integrare tali requisiti nel più ampio quadro normativo europeo promuovendo una trasparenza totale da parte dei fornitori di servizi digitali. In un contesto dominato dal modello di responsabilità condivisa, la sovranità del cliente viene spesso limitata dalle decisioni tecniche del fornitore; proprio per questo la trasparenza diventa il presupposto indispensabile per compiere decisioni basate su una rigorosa valutazione del rischio. La Germania ha assunto un ruolo guida in questo percorso delineando un’evoluzione storica che trasforma i principi teorici in standard operativi pronti per il mercato.

I criteri della sovranità del cloud in Germania

L’Ufficio federale per la sicurezza informatica tedesco denominato BSI (corrispettivo della nostra ACN) svolge una funzione determinante nel definire standard tecnici che superano la protezione informatica tradizionale per abbracciare l’autonomia operativa. Il percorso evolutivo è iniziato con il catalogo C5 ed è approdato al nuovo framework C3A; ovvero i Criteri per l’Autonomia del Cloud Computing. Questo nuovo schema approfondisce e declina in modo analitico gli obiettivi fissati dal Quadro Europeo per la Sovranità del Cloud. La collaborazione con attori industriali di rilievo come SAP e l’esperienza maturata nel progetto Delos hanno permesso di trasformare la teoria in requisiti tecnici per la pubblica amministrazione. Questi sforzi coordinati stanno preparando il terreno per la futura normativa comunitaria denominata Cloud and AI Development Act la cui presentazione è prevista per il 27 maggio 2026. Nel frattempo il BSI si è impegnato a pubblicare le linee guida dettagliate per gli audit entro la fine di giugno; fornendo così una tabella di marcia chiara per l’intero settore.

Il catalogo dei criteri C3A (Criteria enabling Cloud Computing Autonomy), presentato dall’Ufficio federale tedesco per la sicurezza informatica (BSI), definisce i requisiti necessari affinché un’offerta cloud possa essere considerata “sovrana”. Questi criteri si basano sull’EU Cloud Sovereignty Framework (EU CSF) e si articolano in sei domini principali:

1. Sovranità Strategica (SOV-1)

Giurisdizione e Sede: Il fornitore deve operare sotto la giurisdizione dell’UE o tedesca e avere la sede legale principale in queste regioni.
Controllo Effettivo: La società deve essere sotto il controllo effettivo di una o più corporazioni dell’UE (o tedesche), garantendo trasparenza sulle decisioni strategiche e finanziarie.
Cambi di Controllo: Qualsiasi variazione nella proprietà o nella governance che possa influenzare i controlli di sovranità deve essere comunicata ai clienti con 90 giorni di anticipo.

2. Sovranità Legale e Giurisdizionale (SOV-2)

Esposizione Extraterritoriale: Il fornitore deve valutare annualmente i rischi derivanti da leggi extra-UE (come il Cloud Act statunitense) che potrebbero impattare sulla riservatezza e integrità dei dati.
Diritti di Audit: Devono essere garantite procedure che permettano alle autorità nazionali di sicurezza informatica di verificare la conformità ai criteri C3A.
Stato di Difesa: In caso di stato di difesa, il fornitore deve consentire allo Stato di assumere il controllo delle capacità operative necessarie per far funzionare il cloud.

3. Sovranità dei Dati (SOV-3)

Residenza dei Dati: Il cliente deve poter scegliere opzioni di servizio in cui i dati (del cliente, derivati e dell’account) siano archiviati e trattati esclusivamente nell’UE o in Germania.
Gestione Esterna delle Chiavi: Il cloud deve permettere l’integrazione di sistemi esterni per la creazione e gestione delle chiavi di crittografia, assicurando che il fornitore non possa decifrare i dati autonomamente.
Identità e Crittografia: È richiesto il supporto per provider di identità esterni e per la crittografia lato client con chiavi gestite fuori dall’ambiente del fornitore.

4. Sovranità Operativa (SOV-4)

Personale: Il personale con accesso logico o fisico all’infrastruttura, così come il management, deve essere composto da cittadini dell’UE con residenza principale nell’UE o in Germania.
Capacità di Disconnessione (Disconnect): Il criterio fondamentale richiede che il cloud possa essere scollegato da tutte le connessioni di rete extra-UE senza compromettere disponibilità e sicurezza, rimanendo operativo per almeno 90 giorni.
Accesso Remoto e SOC: Gli accessi amministrativi devono avvenire solo attraverso percorsi situati nell’UE, e i Security Operations Center (SOC) devono avere sede nell’UE o in Germania.

5. Sovranità della Catena di Approvvigionamento (SOV-5)

Trasparenza dei Componenti: Il fornitore deve mantenere un inventario aggiornato della provenienza di tutti i componenti software, hardware e servizi esterni utilizzati.
Gestione delle Dipendenze: Devono essere implementati processi per identificare e mitigare i rischi legati a restrizioni all’esportazione o interruzioni della catena di fornitura, mantenendo flessibilità architettonica per eventuali sostituzioni.

6. Sovranità Tecnologica (SOV-6)

Codice Sorgente: Deve essere conservato un backup del codice sorgente nell’UE (aggiornato ogni 24 ore) con la relativa documentazione, per consentire al fornitore di operare e sviluppare il servizio indipendentemente da terze parti esterne.
Continuità del Servizio: Il fornitore deve disporre di piani di emergenza e di personale tecnico specializzato capace di applicare patch di sicurezza e modifiche al software in autonomia, anche in caso di interruzione dei rapporti con i fornitori originali.

Proteggere le infrastrutture digitali dalle interferenze esterne richiede necessariamente il loro ancoraggio alla giurisdizione europea attraverso requisiti legali stringenti. I fornitori devono possedere una sede legale all’interno dell’Unione Europea e deve essere garantito un controllo effettivo da parte di società europee sulle decisioni strategiche e finanziarie. La massima trasparenza sugli assetti societari funge da difesa contro eventuali acquisizioni ostili; a tal fine il framework impone ai fornitori l’obbligo di informare i clienti con almeno novanta giorni di anticipo rispetto a qualsiasi variazione della governance o della proprietà. Un elemento centrale riguarda l’analisi dell’esposizione extraterritoriale attraverso la quale il fornitore valuta annualmente i rischi derivanti da leggi straniere come il Cloud Act statunitense (ce ne siamo occupati spesso su RegTech news). Il concetto di sovranità in stato di difesa impone inoltre al fornitore di garantire allo Stato la capacità di assumere il controllo dei servizi e del personale in situazioni di emergenza nazionale. Il diritto di audit è garantito direttamente all’autorità di cybersicurezza del paese in cui si trova fisicamente il centro elaborazione dati; assicurando che la protezione legale sia supportata da un controllo ispettivo reale.

Confronto Italia, Germania, Francia: verso una sovranità europea

Italia vs Germania (e Francia): imperativo vs modulare:

Sistema italiano (ACN + PSN) è imperativo, centralizzato e prescrittivo. Ha una legge primaria forte (Strategia Cloud Italia + Regolamento ACN), obbliga la qualificazione per tutta la PA, classifica rigidamente i dati (strategici ? PSN) e garantisce un controllo nazionale fisico/giuridico. Questo lo rende più maturo e immediatamente applicabile oggi, soprattutto per la Pubblica Amministrazione.
Sistema tedesco (BSI C5:2026 + C3A del 27 aprile 2026) è più orientato all’indipendenza/autonomia del cliente (disconnect, controllo operativo, chiavi solo del cliente, personale UE, valutazione rischi extraterritoriali). È avanzato su trasparenza e modularità, ma resta volontario/non vincolante a livello nazionale (anche se C5 è spesso richiesto nei fatti). La Germania sta accelerando ora, ma manca ancora quella “legge primaria a monte” che renda tutto obbligatorio come da noi.
La Francia (SecNumCloud + ANSSI) è stata pioniera sui requisiti di sovranità (ownership, immunità Cloud Act, ecc.) e ha influenzato molto C3A e il dibattito UE.

Differenza chiave: l’Italia ha un sistema centralizzato (PSN come pilastro), mentre Germania/Francia spingono di più sull’indipendenza operativa del cliente. Noi abbiamo alcuni requisiti “forti” che loro stanno definendo meglio solo ora (es. certi aspetti di disconnect o audit autonomo).

Il vero collo di bottiglia: il livello UE, il problema sta a monte con EUCS.

EUCS (European Cybersecurity Certification Scheme for Cloud Services) è bloccato da anni proprio sul tema sovranità (requisiti di ownership, giurisdizione, HQ UE, ecc.).
Molti Stati (Francia, Italia, ecc.) vogliono livelli alti con sovranità inclusa; altri (e hyperscaler) spingono per un approccio puramente tecnico di cybersecurity, senza “discriminazioni”.
Risultato: ancora in draft, senza adozione definitiva. Questo rende difficile armonizzare.

CADA (Cloud and AI Development Act):
è il Cloud and AI development Act, atteso a fine maggio 2026 (probabilmente intorno al 27 maggio, dopo slittamenti da marzo/aprile). Sarà il tentativo della Commissione di definire cos’è davvero un “sovereign cloud” a livello UE, con obiettivi ambiziosi (triplicare la capacità data center, policy unica per PA, ecc.). Molto dipenderà da come tratterà sovranità vs mercato aperto.

Se ogni Stato continua a decidere il proprio “limite di sovranità” (come sta accadendo), la sovranità europea rischia di ridursi a un “punteggio” (come nel recente EU Cloud Sovereignty Framework con i suoi SEAL levels e Sovereignty Score). Questo è esattamente quello che è emerso nelle discussioni recenti: un framework utile per procurement, ma non vincolante e con rischio di “sovereignty-washing”.

In sintesi:

Per ora l’Italia ha un vantaggio temporale grazie al sistema imperativo già a regime.
Germania/Francia stanno colmando gap su indipendenza operativa.
Senza un CADA forte e un EUCS sbloccato, rischiamo un’Europa a “geometria variabile” sul cloud sovrano.

La sovranità dei dati si definisce come la facoltà di stabilire con precisione l’ubicazione e le modalità di trattamento di ogni informazione immessa o generata nel cloud. I nuovi requisiti impongono che i dati risiedano in Europa o specificamente in Germania con l’obbligo di integrare sistemi di External Key Management. Per le architetture IaaS e PaaS tale integrazione è considerata un requisito di base; mentre per le soluzioni SaaS il fornitore deve supportare meccanismi equivalenti che permettano la gestione delle chiavi esclusivamente fuori dall’ambiente del fornitore stesso. L’autenticazione tramite fornitori di identità esterni deve basarsi su standard aperti e non proprietari; supportando modelli senza stato che evitino la duplicazione degli account presso il provider cloud. La crittografia lato client e la trasparenza totale sui flussi di dati garantita da log dettagliati e monitoraggio in tempo reale tramite API open source completano il quadro dei controlli. Ogni sforzo di protezione dei dati risulterebbe tuttavia vano senza una solida sovranità operativa che regoli l’accesso del personale e la gestione delle infrastrutture.

Mantenere l’operatività dei servizi digitali anche in scenari di isolamento geopolitico rappresenta una sfida cruciale per la resilienza delle istituzioni. Per questa ragione vengono stabiliti criteri rigorosi per il personale operativo; il quale deve possedere la cittadinanza europea e risiedere nell’Unione per escludere influenze esterne. Un requisito strategico fondamentale è la capacità di disconnessione fisica dalle dorsali di rete extra europee. Mentre lo standard C3A richiede un’autonomia di novanta giorni; il progetto Delos dedicato alle informazioni classificate della difesa tedesca eleva tale requisito a ben sei mesi di operatività indipendente. I Security Operations Center devono trovarsi esclusivamente in territorio europeo e la gestione degli aggiornamenti software deve avvenire in aree di rete segregate e controllate. Gli esperti del BSI sottolineano come le attuali soluzioni dei grandi hyperscaler; quali Stackit o l’AWS European Sovereign Cloud; rappresentino il futuro modello operativo standard per le applicazioni critiche nel continente.

Le dipendenze occulte da fornitori terzi di hardware e software costituiscono una vulnerabilità critica che va gestita tramite una trasparenza assoluta della catena di fornitura. Il framework C3A introduce l’obbligo di mantenere un inventario dettagliato tramite la Software Bill of Materials identificando con chiarezza i paesi di origine di ogni componente. Il controllo sul codice sorgente non ammette deroghe; il fornitore deve mantenere un backup residente nell’Unione Europea aggiornato ogni ventiquattro ore e articolato in almeno cinque versioni distinte per garantire la ridondanza. Risulta inoltre indispensabile disporre di talenti ingegneristici locali capaci di intervenire direttamente sul software e gestire le patch di sicurezza in totale autonomia qualora il supporto esterno venisse interrotto. Questi requisiti tecnici non sono semplici opzioni ma costituiscono un vero manuale operativo per la costruzione di una sovranità reale e tangibile.

Il framework C3A non deve essere considerato un regolamento statico ma una guida dinamica per orientare le gare d’appalto e le attività di audit. Esistono differenze significative tra l’approccio tedesco e quello francese espresso dall’agenzia ANSSI tramite il catalogo Secnumcloud. Mentre la Francia ha storicamente privilegiato una sovranità più politica; la Germania attraverso Martin Bierwirth ha cercato una sintesi tecnica che integri l’esperienza francese in parametri operativi misurabili. In questo contesto le offerte cloud pubbliche standard di Microsoft Azure; AWS e Google restano chiaramente escluse dai parametri di sovranità definiti dal BSI poiché non soddisfano i requisiti di autonomia totale. La distinzione tra criteri di base e criteri aggiuntivi consente tuttavia di modulare il livello di protezione richiesto adattandolo al rischio specifico di ogni amministrazione. Questa flessibilità tecnica è il presupposto necessario per preparare un’azione coordinata che metta in sicurezza il sistema paese italiano nel panorama europeo.

Le azioni di sovranità digitale in Europa: uno sguardo coordinato

L’Italia deve affrontare con urgenza la necessità di allinearsi alle migliori pratiche europee per evitare l’esclusione dai futuri standard di mercato continentale. Le istituzioni nazionali sono chiamate a seguire l’esempio tedesco adottando criteri tecnici rigorosi e promuovendo una collaborazione stretta tra le agenzie governative e i fornitori di tecnologia. Definire in modo univoco i requisiti di un cloud sovrano porterebbe benefici economici tangibili e un incremento della sicurezza nazionale simile a quanto perseguito dal BSI. L’adozione di standard basati su metriche chiare proteggerebbe l’amministrazione pubblica e le aziende operanti in settori critici dalle vulnerabilità geopolitiche e dalle dipendenze tecnologiche rischiose. È necessaria una visione strategica nazionale che collochi l’autonomia digitale al centro dell’agenda politica e industriale, trasformando i requisiti tecnici in un vantaggio competitivo per l’intero ecosistema digitale italiano.