Il cloud della Pubblica Amministrazione è una nuvola digitale dai contorni sempre più definiti. Dopo la presentazione dei Piani di migrazione, lo scorso 28 febbraio, è infatti il momento, per le amministrazioni interessate, di passare all’azione per gestire al meglio il trasferimento in cloud di dati, servizi e applicativi. Una fase da condurre avendo cura dei riferimenti tecnici e normativi necessari per completare una migrazione di successo, con una serie di elementi chiave ai quali prestare particolare attenzione.
I riferimenti tecnici e normativi
Per una PA alle prese con la migrazione di dati e servizi in cloud è bene tenere anzitutto in considerazione il più ampio contesto fornito da:
- Codice dell’Amministrazione Digitale (CAD), che individua il digitale come la modalità principale per assicurare la disponibilità, la gestione, l’accesso, la trasmissione e la conservazione di dati, documenti e informazioni;
- articolo 33 septies del decreto legge n.179 del 2012, che ha fissato, con il Consolidamento e la razionalizzazione dei siti e delle infrastrutture digitali del Paese, l’obbligo di migrazione al cloud per le PA;
- aggiornamento del Piano Triennale al 2024, che ha mantenuto il principio cloud first tra i suoi elementi guida, stabilendo che in fase di definizione di un nuovo progetto e di nuovi servizi le PA adottino il cloud come “paradigma di riferimento”, ovvero come complesso di regole metodologiche, modelli e soluzioni tecniche a cui attingere;
- Strategia Cloud Italia, che fornisce alle PA l’indirizzo strategico e indica i passi amministrativi necessari all’implementazione di soluzioni cloud, con particolare riguardo agli aspetti legati a tutela di privacy, autonomia tecnologica, controllo sui dati e resilienza del sistema;
- Manuale di abilitazione al cloud, che da un punto di vista tecnico accompagna le PA nel percorso che parte dall’identificazione degli applicativi da migrare in cloud fino ad arrivare alla valutazione degli indicatori di risultato a migrazione avvenuta.
Oltre a questi riferimenti, e a quelli imprescindibili legati alla cybersecurity promossi dall’Agenzia per la cybersicurezza nazionale (ACN), una migrazione in cloud considerata di successo deve tenere sotto stretta osservazione anche alcuni accorgimenti tecnici generali, come la riduzione del rischio lock-in (non solo tecnologico), il miglioramento delle strategie di recovery e l’incremento della continuità di servizio, ovvero della resilienza dei sistemi. Questi tre obiettivi hanno un impatto determinante sulla buona riuscita di una migrazione, e possono essere gestiti tramite un approccio DevOps e Infrastructure as Code (IaC, dove l’infrastruttura è gestita automaticamente tramite ricette in forma di codice). Vediamoli più in dettaglio.
Riduzione del rischio lock-in
A un livello molto astratto il cloud può essere definito, con la debita attenzione, come “il computer di qualcun altro”. Per questo motivo, fra gli obiettivi del Piano Triennale troviamo chiaramente indicata la necessità di mitigare il rischio del lock-in, ovvero la difficoltà a svincolarsi da scelte effettuate in precedenza, incluse la scelta del fornitore con il relativo contratto. Non ci sono ricette miracolose per perseguire questo obiettivo, perché il rischio può manifestarsi a diversi livelli e occorre prestare attenzione a tutti gli aspetti organizzativi, tecnologici e operativi della migrazione, nonché a quelli di tipo economico.
A tale proposito, il Manuale di abilitazione al cloud contiene una sezione specifica per riconoscere possibili situazioni di lock-in, oltre a indicare buone pratiche tecnologiche, di metodo e contrattuali. Il caso più comune, per una PA, è quello inerente i fornitori, con i quali si instaurano spesso dei rapporti di lungo periodo. Avere un rapporto consolidato con un’azienda non è necessariamente un fatto negativo; tuttavia conviene essere consapevoli dei limiti che si possono incontrare nella gestione dei dati, nella manutenzione degli applicativi e nei vincoli contrattuali. I software qualificati da ACN offrono comunque tutte le funzionalità necessarie a mitigare i rischi di lock-in, ad esempio attraverso l’export di dati tramite API documentate, come evidenziato anche nel successivo paragrafo dedicato al Repurchase/replace.
Nel processo di migrazione si può inoltre scegliere di rimpiazzare soluzioni proprietarie, per esempio il database, con soluzioni open source, che sono disponibili anche come PaaS qualificato, ovvero in possesso dei requisiti di sicurezza stabiliti da ACN. Si possono scegliere soluzioni che integrano lo scambio di dati tramite API e formati standard, o favorire l’utilizzo di strumenti e framework di sviluppo openrispetto a soluzioni sviluppate internamente e di difficile manutenibilità per altri fornitori. Ulteriori azioni di mitigazione sono contenute nella sezione Come mitigare il lock-indel manuale di abilitazione al cloud al quale si rimanda per gli approfondimenti.
Recovery (dal backup)
La valutazione del rischio e la scelta delle modalità dell’erogazione di un servizio rimane sempre in capo all’amministrazione. Allo stesso modo l’ente delega l’esecuzione del servizio, ma non le responsabilità connesse. Il sistema di classificazione di dati e servizi elaborato da ACN è lo strumento principale per orientare le scelte dell’amministrazione. Per una migrazione di successo, le amministrazioni dovrebbero anzitutto effettuare un’analisi approfondita, comprensiva di una solida fase di test dei sistemi di backup e soprattutto di recoveryofferti dalle soluzioni adottate, o ancora da attivare in caso non siano presenti nativamente. Questo per evitare che si creino disservizi, anche prolungati nel tempo, a tutto svantaggio di cittadini e imprese. In generale, quindi, è sempre possibile, oltre che auspicabile, cautelarsi con apposite strategie di disaster recovery e di backupdei database e degli applicativi seguendo i suggerimenti del Manuale di abilitazione.
Per quanto riguarda il backup, è necessario pianificare dei test periodici di ripristino complessivo dei sistemi, oltre a definire la frequenza temporale, la quantità di dati da salvare e il loro periodo di conservazione. La strategia di disaster recovery va decisa in base ai tempi di ripristino desiderati, alla quantità di dati che un ente ritiene accettabile perdere e ai costi da sostenere. Per loro natura, gli ambienti cloud permettono un ripristino più rapido dei sistemi IT, grazie alla ridondanza e a servizi specifici di solito offerti dal provider. Sono aspetti che vanno considerati in fase di contrattualizzazione del fornitore, con l’obiettivo di assicurare la continuità di servizio e prevenire malfunzionamenti.
Continuità di servizio e resilienza agli attacchi ransomware
Particolare attenzione deve essere posta nell’avere sempre un backup recente disconnesso o in sola lettura, per tutelarsi dagli attacchi di tipo ransomware. Una delle ultime ondate di cyberattacchi, ad esempio, ha sfruttato una vulnerabilità nota di sistemi non aggiornati, quella dell’hypervisor, lo strato software che di norma è gestito dal cloud provider. In questo caso, per (ir)responsabilità del provider, anche avendo aggiornato applicativi, dipendenze e sistemi operativi, un’amministrazione può rimanere comunque colpita. E il costo della perdita dei dati o del pagamento del riscatto è di certo superiore alla messa in campo, in via preliminare, delle opportune contromisure.
In base al regolamento della qualificazione ACN, un fornitore di servizi qualificati deve testare il restore dei dati almeno una volta all’anno. Ciò non toglie la possibilità alla PA di negoziare test più frequenti e livelli di servizio superiori agli standard minimi. Le amministrazioni, inoltre, grazie all’utilizzo degli strumenti di automazione che permettono di testare il backup con frequenza arbitraria, di norma settimanale o giornaliera, possono verificare autonomamente e in maniera continuativa il restore dei dati in ambiente di test.
Come migliorare la migrazione in cloud grazie a un approccio DevOps
Gli esperti sulla sicurezza e sulla continuità di servizio lo dicono chiaramente: non ha senso chiedersi se avverrà un disservizio, perché avverrà sicuramente. Meglio quindi essere pronti. E le attuali buone pratiche raccomandano di automatizzare il più possibile il processo di bootstrap, gestione, ripristino e migrazione di un’infrastruttura. Un modo per poter agire tempestivamente in caso di eventi avversi o per essere pronti a cogliere nuove opportunità, che potrebbero presentarsi, come un nuovo requisito da soddisfare velocemente o come la migrazione verso un altro cloud provider che offre migliori condizioni.
La flessibilità in fase di deployment, ovvero la modalità in cui si installano e configurano i servizi, è un asset importante. E anche se non ci sono specifici finanziamenti e normative che impongono l’adozione di un modello di deploymentbasato sul ciclo DevOps e la pratica di Infrastructure as Code, è opportuno adottare questo approccio.
L’adozione del paradigma cloud, infatti, è un processo aperto: le amministrazioni devono partire dal presupposto che ogni componente del software può essere migliorato o sostituito. Il perfezionamento può avvenire su diversi fronti: dalle prestazioni del sistema alla modalità di deployment. Cambiare tutto in colpo solo può quindi esporre a rischi notevoli e, in linea di massima, vale il principio che più è grande un cambiamento, maggiore è il rischio che qualcosa non vada come previsto.
Per questo motivo è consigliabile l’adozione di strumenti e modalità di lavoro iterative a piccoli passi, sostituendo un componente alla volta e verificando che tutto funzioni dalle procedure di test. L’automazione nella gestione dei componenti è ormai internazionalmente riconosciuta come insieme di pratiche DevOps, di cui la creazione e prima configurazione dell’infrastruttura è una parte fondamentale, tale da meritare la definizione di Infastructure as Code (IaC).
L’approccio DevOps, si può applicare in tutti i casi di migrazione previsti. In generale i servizi cloud, che siano Iaas, PaaS o SaaS devono offrire delle API per la configurazione e la gestione. Le API sono il punto di contatto fra il cloud e gli strumenti DevOps. Più un servizio è supportato dagli strumenti DevOps, più opportunità di integrazione e gestione automatizzata ci saranno.
L’approccio DevOps, può essere attuato direttamente dall’amministrazione o richiesto al fornitore per qualsiasi tipo di servizio. Per esempio un servizio di norma erogato come SaaS come la posta elettronica può essere configurato tramite API, facilitando la gestione dei dati. L’aggiunta di un utente, la configurazione delle quote e dei redirect, le politiche di retention, l’export dei dati e il backup possono essere gestiti in maniera automatica.
Le due modalità di migrazione
Come stabilito dal Regolamento cloud, il 28 febbraio scorso è scaduto il termine per la presentazione dei Piani di migrazione da parte delle pubbliche amministrazioni sulla base del modello standard definito dal Dipartimento. Nel documento, così come nei fondi messi a disposizione dal Piano nazionale di ripresa e resilienza su PA digitale 2026, viene chiesto alle amministrazioni di scegliere fra due modalità di migrazione:
- il trasferimento in sicurezza dell’infrastruttura IT;
- l’aggiornamento di applicazioni sicure in Cloud.
Per ognuno dei servizi oggetto della migrazione è opportuno che le PA valutino con attenzione vantaggi e svantaggi, per individuare il modello di migrazione più adatto alle loro esigenze. Vediamoli più in dettaglio.
Trasferimento in sicurezza dell’infrastruttura
Definizione contenuta negli avvisi pubblicati su PA digitale 2026:
“L’opzione di trasferimento in sicurezza dell’infrastruttura IT consente di sfruttare la strategia di migrazione Lift&Shift (anche detta Rehost), cioè la migrazione al Cloud dell’infrastruttura già esistente, senza la necessità di reingegnerizzare le applicazioni. Tale modalità consiste nel migrare l’intero servizio, comprensivo di applicazioni e dati su un hosting cloud senza apportare modifiche agli applicativi, ovvero replicando il servizio esistente in un ambiente cloud.”
Il trasferimento in sicurezza dell’infrastruttura avviene quando l’applicazione viene spostata in cloud senza modifiche sostanziali. Di solito, in questo caso vengono riconfigurati gli indirizzi IP; tuttavia anche il semplice re-host può nella pratica articolarsi in diversi sottocasi.
Semplicità nella migrazione
In linea di massima il re-host prevede di modificare il meno possibile l’applicazione e il sistema operativo sul quale è installata. È tuttavia possibile passare da un sistema installato direttamente sull’hardware a una macchina virtuale, che può poi avere lo storage fornito come dischi (volumi) locali, o come dischi di rete. Poter disaccoppiare lo storage dalla macchina permette di avere un livello di flessibilità nella gestione che prima della migrazione non era possibile. Una flessibilità che, a sua volta, permette di accedere alle funzionalità basilari IaaS del cloud, come la scalabilità verticale (il poter far ripartire la macchina virtuale con più risorse: CPU, RAM, ma anche storage) o la gestione degli snapshot (le fotografie dei volumi usati come storage) e dei backup dei volumi, che possono essere anche inviati ad un sito remoto da attivare in caso di disaster recovery.
Difficoltà di mantenimento nel medio/lungo termine
Un servizio, per essere definito “cloud” deve prevedere la fatturazione a consumo. Di norma il prezzo di un hardware dedicato è superiore a quello di una macchina virtuale, ma, di contro, le prestazioni sono garantite, rispetto ad una soluzione virtuale che per sua natura prevede la condivisione delle risorse con altri utenti. Le macchine virtuali sono però offerte con taglie di risorse più granulari rispetto all’hardware fisico, rendendo possibile un dimensionamento senza sprechi che porta all’ottimizzazione dei costi.
Il problema principale di una migrazione Lift&Shift è che l’applicazione migrata non sfrutta i paradigmi più innovativi del cloud computing e che quindi, a medio/lungo termine diventerà sempre più onerosa perché non ottimizzata, complessa nella manutenzione in quanto poco automatizzata e automatizzabile, e più difficile da gestire all’interno di un piano per il disaster recovery. Il semplice trasferimento in cloud andrebbe considerato solo per servizi in dismissione, poco utilizzati e che consumano poche risorse, quando il valore aggiunto di un ammodernamento dell’applicazione non sarebbe ammortizzabile nel bilancio di un ente.
Con il re-host la possibilità di gestire le risorse in maniera elastica offre l’opportunità di migliorare notevolmente gli aspetti di backup e recovery oltre a quellidi resilienza.
Aggiornamento di applicazioni sicure in Cloud
Definizione contenuta negli avvisi pubblicati su PA digitale 2026:
“L’opzione di Aggiornamento di applicazioni sicure in Cloud offre la possibilità di migrare le applicazioni utilizzando una tra le strategie repurchase/replace e replatform. Per repurchase/replace si intende l’acquisto di una soluzione nativa in cloud, in genere erogata in modalità Software as a Service, mentre per replatforming si intende la riorganizzazione dell’architettura applicativa sostituendo intere componenti del servizio in favore di soluzioni Cloud native in modo da usufruire dei benefici dell’infrastruttura Cloud.”
Codice Amministrazione Digitale e Servizi Qualificati
In generale, l’adozione di nuove soluzioni informatiche presso la PA è soggetta alle prescrizioni del Codice dell’amministrazione digitale. In particolare, gli articoli 68 e 69 (rispettivamente “Analisi comparativa delle soluzioni” e “Riuso delle soluzioni e standard aperti”), impongono che gli enti effettuino un’analisi comparativa delle soluzioni acquisite, e prevede che queste vengano messe disposizione nel Catalogo curato da Developers Italia se sviluppate per una Pubblica Amministrazione. Per le soluzioni cloud, inoltre, la Strategia Cloud Italia disciplina un percorso di qualificazione dei servizi offerti dai fornitori con la collaborazione attiva dell’Agenzia per la Cybersicurezza Nazionale, che attualmente gestisce il Catalogo dei servizi cloud per la PA qualificati.
Repurchase/replace
I passaggi più delicati, nell’aggiornamento di un’applicazione tramite una strategia di repurchase/replace, sono legati alla migrazioni dei dati, all’integrazione con i sistemi esistenti e anche ad aspetti relativi alla formazione del personale. Nel valutare la scelta di quest’opzione, per l’amministrazione è opportuno soppesare con attenzione la facilità di importazione dei dati, l’usabilità delle interfacce e la compatibilità con i sistemi esistenti.
Allo stesso tempo conviene fin da subito valutare anche il costo di dismissione e migrazione ad altre soluzioni per mitigare il lock-in. In generale, è possibile (oltre che auspicabile) migliorare il livello di autonomia tecnologica ricorrendo a soluzioni open source o a soluzioni disponibili come servizi qualificati presso più fornitori. In ogni caso, la scelta di software qualificati da ACN garantisce alle Pubbliche Amministrazioni di avere a disposizione programmi che rispettano requisiti stringenti in materia di gestione, interoperabilità e portabilità: una gestione remota via API (utilizzabili anche con un approccio DevOps), avere API ben documentate e avere la possibilità di export dati in formati aperti diminuisce il lock-in.
Replatform e re-architect, verso il cloud native
Di norma con l’aggiornamento tramite replatform, parti dell’applicazione sono sostituite con del software IaaS, PaaS o SaaS: ad esempio il database interno può essere sostituito con un database as service, oppure lo storage su disco viene sostituito da un object storage. Dal punto di vista tecnico, il replatform è una modalità più complessa di trasferimento in cloud rispetto al rehost, in quanto è necessario intervenire su componenti di più basso livello del sistema. Si tratta però dell’opzione con le maggiori prospettive di miglioramento.
In caso di replatform è possibile inoltre incrementare il livello di autonomia tecnologica scegliendo componenti che sono disponibili su più cloud provider e sviluppando delle ricette di deploy che siano il più possibile agnostiche rispetto al cloud di destinazione.
I bandi del PNRR possono prevedere inoltre anche una terza modalità di migrazione con aggiornamento: la possibilità di un re-architect, ovvero del cambiamento di gran parte del software della soluzione, per esempio per dividerla in microservizi da gestire poi con sistemi di orchestrazione nativi del cloud. Da un certo punto di vista, il replatform si può anche vedere come il primo passo verso un re-architect: tempi e rischi, però, aumentano con l’entità dei cambiamenti necessari.
Il modello di sviluppo di applicazioni al quale tendere è quello cloud native, che mira a costruire ed eseguire applicazioni scalabili in cloud che tramite un robusto sistema di automazione possano essere modificate frequentemente per un miglioramento continuo.
In questo caso, saranno l’automazione e la gestione cloud native dell’applicazione, che miglioreranno in maniera naturale gli aspetti relativi al backup, restore e disaster recovery.
Per una nuova normalità
La migrazione al cloud non è qualcosa di magico che permette in un solo colpo di ammodernare l’infrastruttura e i servizi della PA: è piuttosto un processo che presenta rischi e opportunità. Se i finanziamenti del PNRR, insieme agli interventi di sistema promossi dagli Avvisi pubblicati sulla piattaforma PA digitale 2026, sono pensati per accompagnare la PA nel percorso di trasformazione digitale, ai singoli enti non deve mancare consapevolezza nella scelta di soluzioni lungimiranti. In futuro, infatti, il campo dell’Information Technology offrirà servizi sempre più fluidi e sviluppati secondo una metodologia agile, con il cambiamento costante che sarà la nuova normalità: tocca alle amministrazioni scegliere se governarlo oppure esserne governate.
