Come navigare la strategia “Cloud Italia” e scegliere tra Cloud Pubblico, Privato o Ibrido per i dati sensibili?

La direttiva “Strategia Cloud Italia” ha imposto una svolta decisiva per la Pubblica Amministrazione e le grandi aziende italiane. Non si tratta più di decidere “se” migrare al cloud, ma “come” farlo in un contesto complesso, denso di vincoli normativi e opportunità irripetibili legate al Piano Nazionale di Ripresa e Resilienza (PNRR). Molti si concentrano sulla scelta apparentemente semplice tra cloud pubblico, privato o ibrido, valutando i pro e i contro in termini di costi e flessibilità. Si discute di scalabilità, agilità e riduzione dei costi di manutenzione dell’hardware on-premise. Questi sono, senza dubbio, aspetti rilevanti, ma rappresentano solo la superficie di una sfida molto più profonda.

Il vero nocciolo della questione è che la migrazione non è un mero trasloco tecnologico. È un esercizio di orchestrazione strategica ad altissima complessità. Se la chiave del successo non fosse la scelta del modello di cloud, ma la capacità di allineare ogni decisione tecnica—dalla localizzazione fisica del server all’efficienza energetica del codice—a un framework di rischio normativo, continuità operativa e sovranità digitale? Questo approccio trasforma la migrazione da un progetto IT a una manovra strategica di cui il CIO è il principale regista. La scelta del provider, la riscrittura di un’applicazione o la configurazione di un firewall diventano tasselli di un mosaico più grande: la garanzia della continuità dei servizi critici per il cittadino e la protezione del patrimonio informativo nazionale.

Questo articolo non si limiterà a descrivere le opzioni. Fornirà una bussola strategica per navigare le acque della trasformazione digitale italiana. Analizzeremo le implicazioni legali della localizzazione dei dati, confronteremo i percorsi di migrazione, smonteremo i falsi miti sulla responsabilità e forniremo quadri decisionali concreti per progettare sistemi resilienti, sicuri e sostenibili, in piena conformità con le direttive del Polo Strategico Nazionale (PSN) e dell’Agenzia per la Cybersicurezza Nazionale (ACN).

Per affrontare in modo strutturato queste complesse decisioni, abbiamo suddiviso l’analisi in otto aree critiche. Ogni sezione affronta una domanda fondamentale che un CIO deve porsi, fornendo risposte basate su dati, normative e casi d’uso specifici per il contesto italiano.

Server in Europa o USA? Perché la localizzazione del dato è critica per il GDPR e il Cloud Act

La domanda sulla localizzazione dei server non è un dettaglio tecnico, ma la pietra angolare di tutta la strategia di conformità. La scelta tra un data center a Milano o in Virginia ha implicazioni legali, economiche e di rischio normativo radicalmente diverse. Da un lato, il GDPR impone rigidi vincoli al trasferimento di dati personali fuori dall’Unione Europea. Dall’altro, il CLOUD Act statunitense permette alle autorità USA di richiedere dati a provider americani, indipendentemente da dove questi siano conservati. Questa tensione legale, culminata nella sentenza Schrems II, rende estremamente rischioso ospitare dati sensibili di cittadini italiani su infrastrutture soggette alla giurisdizione USA.

È in questo scenario che si inserisce la necessità di una sovranità calcolata. Il Polo Strategico Nazionale (PSN) è la risposta italiana a questa esigenza. Come evidenziato in un’analisi de Il Sole 24 Ore sul cloud sovrano europeo, il PSN, costituito da TIM, Leonardo, CDP Equity e Sogei, garantisce che i dati strategici della PA rimangano fisicamente e legalmente sul territorio nazionale, al riparo da ingerenze esterne. Questa scelta supporta un mercato che, secondo l’Osservatorio Cloud Transformation del Politecnico di Milano, è destinato a raggiungere gli 8,1 miliardi di euro nel 2025. Per un CIO della PA, optare per un provider qualificato AGID e operante all’interno del perimetro del PSN non è solo una scelta di conformità, ma un requisito fondamentale per la gestione del rischio.

Lift & Shift vs Refactoring: quando conviene riscrivere l’app invece di spostarla così com’è?

Una volta definito il “dove”, la domanda successiva è il “come”. La migrazione di un’applicazione non è un processo monolitico. Le due strategie estreme sono il “Lift & Shift” e il “Refactoring”. Il Lift & Shift consiste nel trasferire un’applicazione “così com’è” da un server on-premise a un’infrastruttura IaaS (Infrastructure as a Service). È l’approccio più rapido ed economico nel breve termine, ma spesso si traduce nel trasferire inefficienze e debito tecnico nel cloud, limitando i benefici a un mero risparmio sui costi hardware. L’applicazione non sfrutterà le capacità native del cloud come l’auto-scaling o le architetture serverless, e l’integrazione con servizi moderni come pagoPA o SPID potrebbe risultare complessa.

Al contrario, il Refactoring (o Re-architecting) implica la riscrittura parziale o totale dell’applicazione per renderla “cloud-native”. Questo percorso è più lungo e costoso inizialmente, richiedendo competenze di sviluppo avanzate. Tuttavia, è l’unica via per massimizzare i vantaggi del cloud: maggiore resilienza, scalabilità granulare, costi operativi inferiori nel lungo periodo e performance ottimizzate. Per la PA, un refactoring ben eseguito rende l’applicazione intrinsecamente più sicura e performante, posizionandola come candidata prioritaria per l’accesso ai fondi del PNRR, che premiano la modernizzazione e l’efficienza. Esiste anche una via di mezzo, il “Replatforming”, che prevede piccole modifiche per adattare l’app a un ambiente PaaS (Platform as a Service), ottenendo un buon compromesso tra costi e benefici.

La scelta dipende da una valutazione strategica. Per un’applicazione legacy vicina alla dismissione, il Lift & Shift può essere sufficiente. Per un servizio critico per il cittadino, con un ciclo di vita lungo, il Refactoring è un investimento strategico irrinunciabile. La matrice seguente offre un quadro decisionale specifico per il contesto italiano.

Come evitare di diventare ostaggio di un unico provider Cloud e mantenere una via d’uscita?

La scelta di un provider cloud è un impegno a lungo termine che, se non gestito con lungimiranza, può trasformarsi in una trappola: il vendor lock-in. Diventare dipendenti da un unico fornitore significa perdere potere contrattuale, subire aumenti di prezzo ingiustificati e, soprattutto, trovarsi impossibilitati a migrare verso soluzioni migliori o più economiche a causa di tecnologie proprietarie, API non standard e costi di uscita proibitivi. Per un’entità pubblica, questo rappresenta un rischio strategico inaccettabile, in quanto compromette la flessibilità e l’autonomia decisionale nel lungo periodo.

La strategia per mitigare questo rischio è l’adozione di un approccio multi-cloud o hybrid-cloud fin dalla fase di progettazione. Ciò non significa necessariamente distribuire la stessa applicazione su più cloud (una pratica complessa e costosa), ma piuttosto utilizzare il provider migliore per ogni specifico carico di lavoro e, soprattutto, basare la propria architettura su tecnologie open-source e standard de-facto. L’uso di container (come Docker) e orchestratori (come Kubernetes) è la tattica più efficace: un’applicazione containerizzata è intrinsecamente portabile e può essere eseguita con modifiche minime su AWS, Azure, Google Cloud o su un’infrastruttura privata. Questo approccio è coerente con le tendenze del mercato italiano, dove, sebbene il cloud pubblico e ibrido costituiscano il 72%, il segmento privato sta crescendo del 23% (dati Osservatorio del Politecnico di Milano 2025) proprio per esigenze di maggiore controllo e flessibilità. Privilegiare API standard e servizi basati su open-source (es. PostgreSQL invece di database proprietari) crea una “via d’uscita” strategica, mantenendo il controllo sul proprio destino digitale.

L’errore di pensare che il Cloud Provider sia responsabile di tutto: il modello di responsabilità condivisa spiegato

Uno degli equivoci più pericolosi nella migrazione al cloud è credere che, una volta trasferiti i dati, la responsabilità della sicurezza ricada interamente sul provider. Questa convinzione è errata e può portare a conseguenze disastrose. Tutti i principali provider operano secondo un modello di responsabilità condivisa (Shared Responsibility Model). In sintesi, il provider è responsabile della “sicurezza *del* cloud” (l’infrastruttura fisica, la rete, l’hypervisor), mentre il cliente è responsabile della “sicurezza *nel* cloud” (i dati, le applicazioni, le identità, le configurazioni di rete e dei firewall).

Per un CIO, questo significa che la migrazione al cloud non riduce, ma trasforma la natura delle responsabilità di sicurezza. È imperativo investire nella formazione del team IT, implementare strumenti di Cloud Security Posture Management (CSPM) per monitorare costantemente le configurazioni e definire policy di Identity and Access Management (IAM) granulari. La matrice di responsabilità varia a seconda del modello di servizio scelto (IaaS, PaaS, SaaS), come chiarito dalle linee guida ufficiali.

La tabella seguente, basata sulla documentazione ufficiale della Strategia Cloud Italia, delinea chiaramente la ripartizione dei compiti.

Quando il Cloud va giù: come progettare la resilienza su più Region per non fermare i servizi critici

Anche l’infrastruttura cloud più robusta può subire interruzioni. Un guasto a livello di data center, un errore di configurazione su larga scala o un disastro naturale possono rendere irraggiungibili i servizi ospitati in una singola regione geografica. Per i servizi critici della PA, come i sistemi di pagamento, le anagrafi o i portali sanitari, un’interruzione prolungata è inaccettabile. La soluzione non è sperare che non accada, ma progettare una resilienza proattiva attraverso un’architettura multi-region.

Questo approccio prevede la distribuzione dell’infrastruttura e dei dati su almeno due data center geograficamente distanti (es. Milano e Francoforte, o all’interno delle diverse region del PSN). In caso di fallimento della regione primaria, il traffico viene reindirizzato automaticamente (failover) alla regione secondaria, garantendo la continuità del servizio. Questo richiede una pianificazione attenta, definendo due parametri chiave: l’RTO (Recovery Time Objective), ovvero il tempo massimo di disservizio tollerabile, e l’RPO (Recovery Point Objective), la quantità massima di dati che si è disposti a perdere. Per i servizi essenziali, entrambi i valori dovrebbero tendere a zero.

La Strategia Cloud Italia e il design del Polo Strategico Nazionale nascono con questo principio nel cuore. Come specificato dal Dipartimento per la trasformazione digitale, l’infrastruttura del PSN è basata su 4 data center distribuiti in 2 regioni italiane, offrendo ridondanza geografica nativa. Progettare fin dall’inizio un’architettura multi-region non è un lusso, ma un requisito fondamentale per rispettare la Direttiva NIS (Network and Information Security) per gli Operatori di Servizi Essenziali e garantire la fiducia dei cittadini. Le procedure di failover devono essere testate regolarmente per assicurarsi che funzionino quando servono davvero.

BitLocker o cifratura DB: quale livello di encryption è necessario per proteggere i dati su disco?

La crittografia non è un interruttore “on/off”, ma un approccio stratificato, noto come defense-in-depth. Affidarsi a un solo livello di protezione è una strategia fragile. La domanda non è “se” cifrare, ma “quanti e quali strati di crittografia” sono necessari in base alla sensibilità del dato. Le linee guida dell’ACN per la classificazione dei dati della PA (ordinari, critici, strategici) offrono una bussola precisa. Per i dati ordinari, la crittografia a riposo (at-rest) offerta di default dal provider, come BitLocker per i dischi virtuali, può essere sufficiente a proteggere da un accesso fisico non autorizzato al disco.

Tuttavia, per i dati “critici” e “strategici”, come quelli sanitari, giudiziari o fiscali, questo livello è del tutto inadeguato. Le linee guida del Garante Privacy e dell’ACN sono chiare. Come sottolinea l’Agenzia per la Cybersicurezza Nazionale nelle sue linee guida:

Per dati ‘Critici’ come quelli sanitari, le linee guida del Garante Privacy richiedono un approccio ‘defense-in-depth’: crittografia a livello di disco più crittografia a livello di database (TDE)

– Agenzia per la Cybersicurezza Nazionale, Linee guida per la classificazione e protezione dei dati nel Cloud della PA

Questo approccio multi-livello è cruciale. La TDE (Transparent Data Encryption) cifra i file del database, proteggendo i dati anche se un utente malintenzionato ottenesse accesso al sistema operativo. Per i dati più sensibili in assoluto, si può aggiungere un terzo strato: la crittografia a livello applicativo, dove la chiave di cifratura è gestita esclusivamente dal cliente in un ambiente sicuro (HYOK – Hold Your Own Key), rendendo il dato illeggibile persino per gli amministratori del provider cloud. Una ASL del Centro Italia, ad esempio, ha implementato con successo questo sistema a tre livelli per proteggere i dati dei pazienti, ottenendo la piena certificazione ACN.

Latenza iniziale: perché la tua funzione serverless ci mette 2 secondi a partire e come risolverlo?

Le architetture serverless, come AWS Lambda o Azure Functions, promettono un’efficienza di costi imbattibile, pagando solo per l’effettivo tempo di esecuzione. Tuttavia, nascondono un’insidia che può compromettere l’esperienza utente dei servizi critici: il cold start. Quando una funzione non viene invocata per un certo periodo, il provider la “congela” per liberare risorse. Alla successiva chiamata, il sistema impiega del tempo per inizializzare l’ambiente di esecuzione, caricare il codice e stabilire le connessioni. Questo ritardo, che può variare da poche centinaia di millisecondi a diversi secondi, è inaccettabile per servizi interattivi come un’autenticazione SPID o un gateway di pagamento.

La risoluzione di questo problema richiede un’attenta ponderazione tra costi e performance. La prima linea di difesa è ottimizzare il codice: ridurre le dimensioni del pacchetto di deploy, minimizzare le dipendenze e inizializzare le connessioni al di fuori del gestore della funzione. Tuttavia, per carichi di lavoro sensibili alla latenza, queste ottimizzazioni non bastano. È necessario implementare strategie di “warming”, ovvero mantenere un certo numero di istanze della funzione costantemente “calde” e pronte a rispondere. Tutti i principali provider offrono soluzioni a questo scopo (es. AWS Lambda Provisioned Concurrency, Azure Functions Premium Plan, Google Cloud Run min instances), che però introducono un costo fisso. Inoltre, la scelta della region ha un impatto enorme: test di performance su infrastrutture cloud per la PA italiana hanno mostrato una riduzione della latenza del 45% utilizzando la region di Milano rispetto a Francoforte. La tabella seguente offre un benchmark dei costi per le principali soluzioni di warming, tarato su carichi di lavoro tipici della PA italiana.

Come scrivere codice efficiente che consuma meno CPU e batteria riducendo le emissioni di CO2?

In un’era definita dalla transizione ecologica, l’efficienza del software cessa di essere una mera questione di performance per diventare un requisito di sostenibilità e conformità. Un codice inefficiente non solo rallenta le applicazioni e consuma più rapidamente la batteria dei dispositivi degli utenti, ma richiede anche più cicli di CPU sui server, traducendosi in un maggiore consumo energetico e, di conseguenza, in maggiori emissioni di CO2. Questo concetto, noto come Green Coding o Sustainable Software Engineering, sta diventando un pilastro della responsabilità digitale.

Per la PA italiana, questa non è più una considerazione etica, ma un vincolo operativo. I Criteri Ambientali Minimi (CAM) per gli appalti pubblici e le linee guida del PNRR spingono per l’adozione di pratiche sostenibili in ogni ambito, incluso quello digitale. Un’efficienza vincolata diventa quindi un obiettivo strategico. Come afferma il Dipartimento per la Trasformazione Digitale, “L’efficienza energetica del software può diventare un KPI misurabile per rendicontare i progetti della PA e delle aziende che accedono ai fondi PNRR”. Questo significa che la scelta di algoritmi efficienti, l’ottimizzazione delle query sul database, l’uso di linguaggi di programmazione a basso consumo energetico (come Rust o C++) e la progettazione di architetture che minimizzano il traffico di rete non sono più solo buone pratiche, ma requisiti misurabili da inserire nei capitolati tecnici.

Scegliere un provider cloud che a sua volta dimostri un impegno concreto per la sostenibilità, con data center alimentati da fonti rinnovabili e alti livelli di efficienza energetica (misurata dal PUE, Power Usage Effectiveness), chiude il cerchio di una strategia digitale veramente responsabile. Scrivere codice efficiente oggi significa ridurre i costi operativi domani e contribuire attivamente agli obiettivi di sostenibilità del Paese.

Valutare la soluzione cloud più adatta richiede un’analisi che va ben oltre la tecnologia, toccando aspetti legali, finanziari e strategici. Per avviare un percorso di migrazione consapevole e allineato alle direttive nazionali, il primo passo è ottenere una valutazione personalizzata delle proprie infrastrutture e dei propri obiettivi.