Il Cloud pubblico potrebbe diventare presto realtà: la grande novità delle ultime settimane è rappresentata dalla pubblicazione del modello di “Piano dei Fabbisogni”, ossia del documento destinato a contenere, descrivere ed illustrare le necessità di ogni singola amministrazione.
Cloud pubblico, la strada verso il PSN e la sovranità nazionale: novità e prospettive
La PA pronta a sbarcare sulla nuvola
La macchina burocratica nazionale è davvero molto vicina a sbarcare sulla grande nuvola digitale, dopo un lungo e tortuoso percorso, nel quale non sono mancate (ed ancora non sono del tutto superate) resistenze e perplessità soprattutto negli enti territoriali, che temono un depauperamento delle comunità e delle imprese locali a vantaggio dei colossi di caratura nazionale.
A dicembre 2022, infatti, è stato collaudato il Polo Strategico Nazionale, che è divenuto operativo nelle sedi di Acilia e Pomezia nel Lazio, Rozzano e Santo Stefano Ticino in Lombardia, apprestandosi a diventare il quartier generale informatico della Pubblica Amministrazione Italiana.
Il processo di onboarding
Il processo di “onboarding” degli enti sul Cloud nazionale segue il percorso ormai consolidato e conosciuto già adottato da diversi anni per le Convenzioni CONSIP: una volta acquisiti i requisiti dell’amministrazione, il fornitore (ossia la cordata capitanata da TIM e composta anche da Leonardo, Cassa Depositi e Prestiti e SOGEI) dovrà presentare “progetto del piano dei fabbisogni” contenente la descrizione dei servizi, la relativa quantificazione economica coerente con il listino di gara ed “piano di migrazione di massima.”
La PA interessata, all’esito delle proprie verifiche, può richiedere eventuali modifiche e sottoscrivere, al termine del processo, il contratto esecutivo con il PSN.
Il meccanismo di adesione appare estremamente fluido e ben congegnato: se, infatti, le esigenze di un’Amministrazione dovessero trovare corrispondenza all’interno del listino approvato in sede di gara, sarà possibile “acquistare” direttamente i servizi compilando i quadri di dettaglio in cui si articola il capitolo 7 del Piano dei Fabbisogni; in caso contrario, l’ente potrà indicare un prospetto sintetico dei servizi da attivare insieme ad una ipotesi economica di riferimento.
Il Piano dei Fabbisogni
Il primo passaggio fondamentale per avviare il processo di migrazione verso il PSN è rappresentato dalla compilazione del “Piano dei Fabbisogni”, il cui template è pubblicato sul sito ufficiale (in verità al momento davvero “minimale”) della newco che si è aggiudicata la concessione pubblica per un periodo di 13 anni.
La grafica (spartana) del sito ufficiale del PSN
Il documento, invero, permette alle amministrazioni di esprimere le proprie esigenze in termini di trasferimento del parco applicativo esistente verso la grande nuvola pubblica ma anche di qualificare e dimensionare i servizi richiesti, a regime, al Polo Strategico Nazionale.
Si tratta, in realtà, di un file in formato docx composto da 7 capitoli che guidano, in maniera estremamente intuitiva, gli enti centrali e periferici nel processo di definizione del proprio contesto di riferimento.
La “copertina” del Piano dei Fabbisogni
Gli obiettivi di migrazione e la lista dei Servizi
Seguendo lo schema del Piano dei Fabbisogni, l’Amministrazione dovrà preliminarmente riportare una breve descrizione delle finalità dell’Amministrazione oggetto del processo di migrazione, indicando, in particolare, l’elenco dei servizi e delle modalità di migrazione, in ossequio a quanto previsto dalla Determina di adozione del “Modello di piano di migrazione”.
In particolare, per ogni servizio sarà necessario compilare una tabella analoga a quella di seguito riportata nella quale:
- La colonna “Servizio dell’amministrazione” deve essere coerente con l’elenco dei servizi dell’amministrazione classificati ai sensi dell’articolo 3 del “Regolamento recante i livelli minimi di sicurezza, capacità elaborativa, risparmio energetico e affidabilità delle infrastrutture digitali per la PA e le caratteristiche di qualità, sicurezza, performance e scalabilità, portabilità dei servizi cloud per la pubblica amministrazione, le modalità di migrazione, nonché le modalità di qualificazione dei servizi cloud per la pubblica amministrazione” , secondo il quale:
- Le amministrazioni predispongono e aggiornano un elenco dei loro dati e dei loro servizi digitali, comprensivo della descrizione delle relazioni:
- tra i dati e i servizi digitali dell’amministrazione;
- tra i dati e i servizi digitali dell’amministrazione e i dati e servizi di terzi.
- I dati e i servizi digitali soggetti agli obblighi di cui al D.L. 105/2019 e di cui al D.Lgs. 65/2018 non sono oggetto dell’elencazione di cui al comma 1.
- I dati e i servizi digitali delle amministrazioni di cui al comma 1 sono classificati, sulla base della loro caratterizzazione, nelle seguenti tre classi:
- strategici, se la loro compromissione può determinare un pregiudizio alla sicurezza nazionale;
- critici, se la loro compromissione può determinare un pregiudizio al mantenimento di funzioni rilevanti per la società, la salute, la sicurezza pubblica e il benessere economico e sociale del Paese;
- ordinari, qualora la loro compromissione non determini i pregiudizi di cui alle lettere a) e b).
- I dati e i servizi digitali soggetti agli obblighi di cui al D.L. 105/2019 sono classificati come strategici.
- I dati e i servizi digitali soggetti agli obblighi di cui al D.Lgs. 65/2018 sono classificati come: a. strategici, qualora siano a valenza nazionale; b. critici, se non a valenza nazionale”.
B. La colonna “Tipo di migrazione” deve riportare solo uno dei due valori ammissibili previsti dal già citato Regolamento approvato dall’AgID:
- “modalità A – trasferimento in sicurezza dell’infrastruttura IT”: trasferimento in sicurezza dell’infrastruttura IT”: migrazione verso il cloud effettuata secondo la strategia di migrazione Lift&Shift (anche detta Rehost), ovvero la migrazione dell’intero servizio dell’amministrazione, comprensivo di applicazioni e dati su un hosting cloud senza apportare modifiche agli applicativi, ovvero replicando il servizio esistente in un ambiente cloud;
- “modalità B – aggiornamento in sicurezza di applicazioni in cloud”: aggiornamento in sicurezza di applicazioni in cloud”: migrazione verso il cloud effettuata secondo le seguenti strategie:
- repurchase/replace: si intende la migrazione del servizio dell’amministrazione verso una soluzione nativa in cloud, in genere erogata in modalità Software as a Service;
- replatform: 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;
- re-architect: ha come obiettivo quello di ripensare significativamente l’architettura core di un applicativo in ottica cloud, attraverso un processo di redesign iterativo ed incrementale che miri ad adottare appieno i servizi cloud-native offerti dai cloud service provider per massimizzare i benefici che ne derivano.
| Servizio dell’amministrazione | Tipo di Migrazione |
|---|---|
| Servizio 1 | modalità A – trasferimento in sicurezza dell’infrastruttura IT |
| Servizio 2 | modalità B – aggiornamento in sicurezza di applicazioni in cloud |
Descrizione dei Servizi da migrare
Per ognuno dei Servizi da migrare, l’amministrazione, inoltre, dovrà fornire dettagli sui seguenti aspetti:
- tempistiche ipotizzate per la migrazione
- tipologia di migrazione prevista, con motivazioni, risultanze rispetto a gap analisys su cloud maturity, o altre informazioni ritenute utili
- eventuali dipendenze tra i servizi da migrare
- vincoli istituzionali sui tempi utili per eseguire le attività di migrazione (impatti su continuità e/o fermi dei servizi coinvolti);
- proposte di intervento per ottimizzare la migrazione aggiornando i servizi (nel caso di migrazione rientrante nella “modalità B – aggiornamento in sicurezza di applicazioni in cloud”)
Il Piano di migrazione
Il piano di migrazione, che fornisce un quadro sintetico del progetto di migrazione della PA, dovrà, invece, riportare le seguenti informazioni minime:
| Nome servizio | Classificazione dei Dati | Tipo di migrazione | Budget – Costi di migrazione | Budget – Canone annuale | Previsione tempi Migrazione |
|---|---|---|---|---|---|
| Servizio 1 | Strategico Critico, Ordinario | modalità A o modalità B | relativi a tutte le attività necessarie per effettuare la migrazione (e ottimizzazione) del servizio sul PSN (comprendendo ad esempio – nel caso di migrazione di tipologia B- anche servizi di rearchitect, replatform, ecc.) | costo annuale ipotizzato per il canone della necessaria infrastruttura cloud del PSN, comprendendo eventualmente anche i costi annuali per servizi opzionali complementari alla migrazione | tempi di massima stimati dall’Amministrazione per il progetto di migrazione (in linea a quanto eventualmente espresso al paragrafo successivo). |
Le tempistiche di migrazione
L’Amministrazione interessata all’onboarding sul PSN dovrà, inoltre, riportare alcune informazioni di dettaglio connesse alle tempistiche previste, prevedendo, ad esempio:
- una fase di Assessment strutturata con Analisi e Discovery delle informazioni di maggior dettaglio
- La migrazione di ambienti e servizi
- Il collaudo dei servizi
| Nome servizio | T1 Analisi & Discovery | T2 Setup | T3 Migrazione | T4 Collaudo |
|---|---|---|---|---|
| Servizio 1 | T0 + .. giorni/mesi | T1 + .. giorni | T2 + .. giorni | T3 + .. giorni |
| Servizio 2 | T0 + .. giorni | T1 + .. giorni | T2 + .. giorni | T3 + .. giorni |
La descrizione dei Fabbisogni ed il contesto di riferimento
Una delle sezioni certamente più importanti del Piano dei Fabbisogni è certamente quella riservata alla descrizione del contesto di riferimento che permette, invero, ad ogni amministrazione di illustrare la situazione di partenza in termini di architettura digitale, di procedure di sicurezza, di infrastruttura fisica ma anche di organizzazione generale dei propri sistemi informativi.
L’Amministrazione, in estrema sintesi, è chiamata a fornire al gestore del PSN un vero e proprio quadro di insieme della propria “identità digitale”, specificando il livello di maturità, complessità e stratificazione dell’organizzazione dei propri servizi IT.
In particolare, il Piano fornisce, quale supporto per lo sviluppo dei contenuti, una serie di spunti di riflessione e di domande tematiche estremamente interessati ed in grado di guidare gli addetti ai lavori nel complicato processo di esplicitazione della situazione “ex ante” e degli obiettivi da raggiungere nel medio e lungo termine.
A tal proposito, nella tabella che segue sono riportati alcune tra le voci più significative proposte alle amministrazioni che intendono avviare il processo di migrazione:
| AMBITO | VALORE (Esempi) |
|---|---|
| Numero di Data Center e dislocazione sul territorio nazionale | |
| Presenza del servizio di Business Continuity | Si/No |
| Presenza del servizio di Disaster Recovery | Si/No (prevista ripartenza dei servizi su sito di DR o solo replica del dato?) |
| Quantità e tipologia di sistemi server (divisione tra sistemi fisici e sistemi dedicati alla farm virtuale) | 400 (200 farm fisica, 200 farm virtuale) |
| Quantità e tipologia di Storage (SAN, NAS) (con TB presenti, occupati e disponibili) | N° xx storage modello xxxx. (con xxTB raw, occupati xxTB, liberi xxTB) |
| Apparti SAN (quantità e caratteristiche della fabric) | N° xx switch modello, firmware xxx |
| Rete (quantità e caratteristiche: Bilanciatori, piano di indirizzamento, eventuali problemi nel cambio di indirizzamento IP) | N° xx switch modello, firmware xxx |
| Sistemi di sicurezza (quantità e caratteristiche) (Identity & Access Management, Firewall, Sonde, Waf, Soc, etc.) | |
| Servizio di Active Directory | |
| Sistemi di virtualizzazione (VMware, Hyper-V, RedHat) | VMware |
| In caso di presenza di VMWARE specificare: N° di vCenter e versioni | 2 |
| In caso di presenza di VMWARE specificare: Presenza di prodotti NSX-T, vRNI, vROPS, HCX, etc. | NSX (SI), vRNI (SI), HCX (NO) |
| Sistemi fisici dedicati alla farm Vmware (Fornire RVTools) | |
| storage fisici dedicati alla farm Vmware (Fornire RVTools) | |
| Presenza di sistemi Iperconvergenti (vSAN, nutanix, DELL VxRAIL, tec.) | SI/NO (specificare prodotto) |
| Backup, prodotti utilizzati (fornire schema topologico se disponibile, N° master e N° media server)(N° master e N° media server) | Veritas Netbackup, Commnvault, Veem, etc. |
| Policy di Backup (TB sottoposti a backup e retention) | |
| Librerie e storage dedicati al backup | SI/NO (specificare prodotto) |
| Piattaforme middleware (quantità e caratteristiche), identificare applicazioni single istance | |
| Identificazione cluster di sistema operativo (Windows, RedHat, Solaris, etc.) | (Windows, RedHat, Solaris, etc.) |
| Database (quantità e caratteristiche) | SI/NO (specificare prodotto) |
| Sistemi di posta elettronica (PEL e PEC) | SI/NO (specificare prodotto) |
| Siti e portali (quantità e caratteristiche) | N° xxx |
| È presente una stima del capacity? (eventuale previsione di crescita) in caso affermativo fornire i dati | |
| Presenza di un CMDB accurato del cliente con elenco delle applicazioni | |
| Il Data Center sorgente è gestito internamente o da fornitori terze parti? | SI/NO |
| Le applicazioni vengono gestite internamente o da fornitori terze parti? | |
| Sono disponibili strumenti di monitoraggio delle applicazioni e della rete? | SI/NO (specificare prodotto) |
| Presenza e tipologia di appliance fisiche | SI/NO (specificare prodotto) |
| Prodotti Antivirus | SI/NO (specificare prodotto) |
| Sistema di gestione delle password | SI/NO (specificare prodotto) |
| Qual è il numero totale di workloads presi in considerazione per questo progetto? | 500 |
| Eventuali workload fisici da migrare (tipologia e quantità) (P2V) | 30 |
| Tipologie e versioni di sistema operativo (Windows, Linux, etc.) | Windows 2008,2012, RHEL 7.0 |
| Contesto applicativo – numero di applicativi |
I servizi (standard o personalizzati) richiesti al PSN
Una volta che è stato definito il quadro di riferimento e che siano stati correttamente esplicitati i requisiti ed i fabbisogni in termini qualitativi e quantitativi, l’Amministrazione, può richiedere ai gestori del PSN una soluzione personalizzata o può scegliere, direttamente all’interno del documento relativo al Piano dei Fabbisogni, i servizi più aderenti alle proprie esigenze tra quelli di seguito riportati:
Industry standard – Hosting: consiste nel rendere disponibile una infrastruttura fisica e dedicata nei Data Center del PSN. A differenza del servizio Housing si ha la possibilità di noleggiare i server di proprietà del provider. Le modalità di erogazione del servizio sono:
- Hosting su rack condivisi, nel caso di porzioni dedicate di rack condivisi con altre Amministrazioni;
- Hosting su rack dedicati, nel caso di rack esclusivi/segregati per la singola Amministrazione.
- Industry standard – Housing: prevede di ospitare l’infrastruttura fisica negli spazi dedicati nei Data Center del PSN.
- Industry standard – IaaS: è finalizzato a rendere disponibile delle risorse infrastrutturali virtualizzate ed è suddiviso in:
- IaaS Private: Infrastruttura virtualizzata e dedicata; Server fisici con a bordo il virtualizzatore Vmware su cui possono essere attivate solamente VM della Amministrazione (cluster dedicato);
- IaaS Shared: Porzione di infrastruttura virtualizzata all’interno di una piattaforma condivisa; Si acquista un pool di risorse virtuali (vCPU, vGB di RAM, vGB di Storage) e il PSN è responsabile della gestione completa dell’infrastruttura sottesa, comprensiva degli strumenti di automation e orchestration.
- Industry standard – PaaS: mette a disposizione una piattaforma in grado di erogare componenti di middleware secondo un modello a servizio (ad esempio Data Base) astraendo l’infrastruttura sottostante. Il PSN è responsabile dell’infrastruttura sottostante comprensiva degli strumenti di automation e orchestration e si compone dei seguenti sottoservizi:
- DBaaS: Consente di configurare e gestire database utilizzando un servizio senza preoccuparsi dell’infrastruttura sottostante
- IAM: È un servizio di Identity Management applicativo che consente di gestire in modo unificato e centralizzato l’autenticazione e l’autorizzazione per la messa in sicurezza delle applicazioni che migrano dentro il PSN
- Big Data: Il servizio consente la costruzione di Data Lake as a service, servizi di analisi dati batch, stream e real-time con scalabilità orizzontale
- Artificial Intelligence: Mette a disposizione un set di algoritmi pre-addestrati di Artificial Intelligence per utilizzarli in analisi del testo, audio/video o di anomalie ed una piattaforma per la realizzazione di modelli custom di machine/Deep Learning
- Industry standard – CaaS: rende disponibile un PaaS di erogazione di Container basato su Kubernetes che abilita la trasformazione dei workload alla logica cloud-native (microservizi).
- Hybrid Cloud on PSN site: permette di combinare servizi di Cloud pubblico e privato mediante un’infrastruttura CSP (Azure) integrata nel PSN. Più specificatamente viene messa a disposizione una infrastruttura fisica dedicata basata su un cluster di server modulare che potrà crescere/decrescere con la granularità del singolo server.
- Secure Public Cloud on Microsoft Azure: permette di ottenere l’accesso al Public Cloud con controllo e gestione della Digital Sovereignty e della sicurezza. È un servizio che si basa su Region pubbliche degli Hyperscaler (Microsoft Azure e Google Cloud GCP) a cui vengono aggiunti tutti gli elementi di sicurezza (chiavi esterne, backup, template, servizi professionali).
Sono possibili 2 tipologie di servizio:
- Secure Public Cloud on Microsoft Azure
- Secure Public Cloud on Google GCP
- Secure Public Cloud on Google GCP:
- Public Cloud PSN Managed: permette di accedere a servizi dei CSP (Oracle e Google Cloud) erogati da «Region» dedicata al PSN, con separazione logico/fisica e operata da personale PSN.
- Servizi di migrazione: Servizio di migrazione end-to-end chiavi in mano sia fisica (housing) che virtuale (dall’analisi degli applicativi al test sui nuovi ambienti e messa in produzione) dell’infrastruttura IT dell’Amministrazione verso l’infrastruttura PSN.
- Servizi professionali evolutivi:
- Servizio Re-Architect: volti alla riprogettazione dell’architettura delle applicazioni in ottica Cloud.
- Servizio Re-Platform: volti alla riprogettazione delle piattaforme che gestiscono le applicazioni dell’Amministrazione in modo da abilitarne la trasformazione verso il Cloud.
- Servizi professionali – Security Professional Services: Attività di Strategy & Compliance, assessment di sicurezza su infrastruttura e parco applicativo e supporto alle Operations per il mantenimento degli elevati standard di sicurezza.
- Servizi professionali – IT Infrastructure – Service Operations: Servizi specialistici on demand a supporto delle Operations per la gestione dell’infrastruttura e del parco applicativo cliente.
- Servizi professionali – Business and culture enablement: Servizi di formazione e consulenza per accompagnare il percorso di avanzamento tecnologico e sviluppo di una infrastruttura ad alta affidabilità.
Come anticipato in precedenza, nel caso in cui nessuno dei servizi “standard” proposti dal documento dovessero rispondere alle reali necessità di un determinato ente, il Piano dei Fabbisogni permette anche di formulare specifiche richieste che potrebbero, all’esito di una valutazione del Dipartimento per la Transizione Digitale della Presidenza del Consiglio dei Ministri, entrare nel catalogo ufficiale del Polo Strategico Nazionale.
Conclusioni
Il Polo Strategico Nazionale è finalmente pronto ad accogliere le prime amministrazioni pubbliche che intendono avviare il processo di migrazione dei propri sistemi informativi verso la grande nuvola pubblica. In particolare, la cordata capitanata da TIM ha messo a disposizione sul proprio sito istituzionale un documento di fondamentale importanza, ossia il “Piano dei Fabbisogni” che permette ad ogni ente centrale e periferico di descrivere la propria situazione di partenza ed esprimere le proprie esigenze in termini di servizi richiesti ai gestori del PSN.
Il processo di on-boarding, invero, appare ben strutturato e, nella maggiorparte dei casi, dovrebbe tradursi nella selezione di un sottoinsieme di funzionalità già previste dall’articolato listino già concordato in sede di gara.
Considerando, però, che le numerose diramazioni della macchina statale presentano situazioni estremamente eterogenee, difficilmente classificabili a priori, la procedura di migrazione prevede anche la possibilità di modellare le singole fasi in base alle reali esigenze di ogni organizzazione, con l’obiettivo di garantire un trasferimento quanto più possibile lineare, veloce e soprattutto in grado di assicurare la continuità dei servizi erogati a favore della collettività.
