Come stabilire un perimetro di competenze tra fornitori e migliorare la collaborazione tra stakeholder

di Daniele Pizzolli, Team Cloud Italia del Dipartimento per la trasformazione digitale

Come gestire una migrazione in cloud quando l’hardware è fornito da un’azienda, il software da un’altra e i servizi vengono gestiti da un terzo operatore? Nell’esercizio delle proprie funzioni, le pubbliche amministrazioni si avvalgono spesso di una pluralità di fornitori ed è quindi necessario suddividere le responsabilità a un livello appropriato di competenze. Un’operazione che può essere condotta grazie a strumenti tecnici e modelli di gestione efficaci, utili a costruire, operare ed evolvere un’infrastruttura cloud a disposizione di multipli fornitori, senza entrare nel merito di questioni contrattuali e amministrative.

Per prima cosa, è bene sottolineare che la responsabilità ultima del buon funzionamento di un servizio, anche quando erogato tramite fornitori esterni e cloud provider, rimane sempre in capo all’amministrazione. Delegare compiti, infatti, non significa sottrarsi alle responsabilità: ad esempio, nel caso della migrazione di un servizio tramite lift and shift, quando lo spostamento in cloud avviene importando l’immagine dell’host di partenza o migrando il software su una virtual machine a partire da un modello messo a disposizione dal cloud provider, l’aggiornamento del sistema operativo dell’host rimane in carico all’amministrazione, anche se a livello gestionale può essere delegato a un fornitore terzo.

Nella pratica, gli scenari nei quali si trova a operare una Pubblica Amministrazione sono diversi, ciascuno con particolari profili di rischio e opportunità. È possibile, però, individuare delle situazioni ricorrenti, come la configurazione degli ambienti del cloud provider (che può offrire vari strumenti per isolare risorse e reti), la gestione degli accessi (che attribuisce agli utenti determinati diritti) e la condivisione di una strategia di disaster recovery (per indirizzare le soluzioni dei possibili incidenti al giusto livello). Vediamole più nel dettaglio.

Un ambiente ottimale dove collaborare in sicurezza

Documentazione

L’ostacolo maggiore alla collaborazione in ambienti dove è necessaria la condivisione di informazioni per portare a termine un compito specifico, come ad esempio la messa in produzione di un nuovo servizio, è che nessuno degli attori coinvolti nel progetto, che spesso lavorano per PA e aziende diverse, abbia la visibilità totale sul sistema.

La documentazione condivisa, quando esiste, è una mappa spesso imprecisa e in molti casi non aggiornata. Inoltre, migrare un servizio in cloud e documentarlo in centinaia di pagine, poi distribuite sotto-forma di manuale, spesso in un formato non editabile, è un freno al cambiamento.

L’obiettivo a cui tendere, invece, è gestire la documentazione come se fosse codice, o come fossero commenti al codice di un sistema di deployment basato sull’Infrastructure as Code (IaC). Le buone pratiche per gestire infrastrutture non mancano e sono riassunte nell’articolo come gestire una migrazione al cloud.

Collaborazione e osservabilità

Un tipico esempio di collaborazione si ha quando il responsabile della rete deve configurare un accesso esterno tramite un router o un firewall (con porte e appositi indirizzi IP) a un nuovo servizio interno, gestito da terzi. Se dovesse avvenire un errore nella comunicazione degli indirizzi o delle porte, chi gestisce il servizio non ha modo di sapere immediatamente cosa è sbagliato, ma vedrà solo che qualcosa non funziona. Allo stesso modo, chi configura la rete spesso non dispone di tutte le informazioni per testare il servizio o ritiene che non sia un suo problema.Per individuare dove si annida l’errore, occorre che ogni soggetto coinvolto controlli bene tutti i parametri, anche se è convinto di averlo già fatto, prima di dichiarare che il problema è legato all’operato di altri.

Per ovviare a questi inconvenienti, un suggerimento è quello di avere dei sistemi di reportistica e delle dashboard condivise, che aumentino l’osservabilità del sistema. Di solito ogni cloud provider mette a disposizione degli strumenti di analisi e monitoraggio, che di norma possono essere usati per la verifica dei servizi in produzione. In alternativa, o in setup più complessi, per esempio nel caso si utilizzino deployment multi-cloud, si possono usare strumenti di analisi multi-cloud o adattati appositamente. In questo modo, ogni fornitore potrà avere un accesso con delle viste personalizzate dove controllare lo stato dei sistemi dei quali è responsabile.

Organizzare privilegi e accessi amministrativi al servizio

Il responsabile della PA che gestisce gli account presso uno o più fornitori di servizi cloud, dovrà creare e delegare gli accessi amministrativi dei vari fornitori a vari servizi, tenendo sempre presente che un’efficace organizzazione dei permessi è alla base di una corretta gestione dei servizi cloud. Ad esempio, un fornitore potrebbe aver bisogno di un insieme di macchine virtuali e di servizi Platform as a service (PaaS) per installare il proprio applicativo: in questo caso sarebbe opportuno garantire appositi accessi amministrativi all’interno di un progetto isolato, creato appositamente per l’esigenza del fornitore, fissando all’occorrenza anche dei limiti di spesa ben definiti.

Anche se con il fornitore esiste un rapporto di fiducia consolidato, non è consigliabile concedere più privilegi di quelli necessari. Concedere a tutti gli utenti i privilegi di amministratore è una scorciatoia che può risultare conveniente nelle fasi iniziali del progetto, ma ben presto ci si renderà conto che per fretta, distrazione o incompetenza potrebbe mettere a rischio il sistema stesso e le sue preziose informazioni. Una situazione che risulterà spiacevole per tutti e che potrebbe minare i futuri rapporti di collaborazione.

In generale, le deleghe alla gestione dei vari componenti di un servizio cloud devono essere ben definite, documentate e testate. A loro volta, le persone che sono delegate a eseguire un compito, come ad esempio il monitoraggio o il backup, il ripristino o le operazioni per il disaster recovery, devono avere chiari i loro limiti di azione e le figure con cui coordinarsi in caso di necessità.

Per esempio, a un fornitore che richiede una virtual machine, si possono dare i permessi per accendere e spegnere la macchina virtuale, per gestire gli accessi e anche il backup. Non dovrebbe però essere necessario concedere anche i permessi per creare e distruggere la virtual machine o per sovrascriverla con un restore nelle operazioni di manutenzione ordinaria. In casi eccezionali, come nell’aggiornamento a una versione successiva o durante test e procedure di recovery, si potrà concedere il permesso di creare e distruggere la macchina virtuale solo per il tempo strettamente necessario alle operazioni.

Parlare la stessa lingua

Ogni_ cloud provider_ usa delle terminologie leggermente diverse per la sua offerta di servizi e configurazioni, e spesso oggetti dallo stesso nome sono in realtà molto diversi. Questo è un grande ostacolo per chi deve gestire servizi su più provider. Termini generici come owner, admin, principal e manager possono infatti avere ruoli molto diversi a seconda del provider e anche del servizio fornito da una stessa azienda. Motivo per cui deve essere posta grande attenzione in fase di definizione dei ruoli e delle regole di accesso.

Per esempio, a seconda del provider il dominio fondamentale per l’organizzazione si può chiamare: “account”, “progetto” o “organizzazione”, le deleghe date a un utente per accedere a un servizio si possono chiamare “service account” o “service principal”, i limiti e le quote possono avere significati leggermente differenti, che vanno in ogni caso a impattare sulla gestione. Chiarezza e condivisione di terminologie e significati rafforzano la qualità delle interazioni fra fornitori e amministrazione, rendendo i processi legati ai servizi cloud più semplici ed efficaci.

Gestione dell’identità e degli accessi

Con Identity and access management (IAM) si indicano gli strumenti e le procedure per la gestione delle identità e degli accessi. In pratica** a ogni soggetto che entra in un sistema si associano un’identità e un insieme di credenziali, permettendogli di gestire determinate funzionalità messe a disposizione dal cloud provider**. Ogni cloud provider ha un suo particolare modo di implementare lo IAM, ma i concetti generali di fondo restano invariati. Di norma c’è un account radice che dispone di privilegi illimitati. Tale account è gestito dal responsabile tecnico della PA. Il responsabile può creare degli altri account e assegnarli con determinati diritti d’accesso ai suoi collaboratori oppure a fornitori esterni.

Non tutti gli account devono per forza avere dei privilegi di creazione, modifica o cancellazione di risorse, ma ci possono anche essere account che hanno accesso in sola lettura. Questo potrebbe essere il caso di un account di monitoraggio dei costi, che può essere delegato a una persona con mansioni amministrative. Allo stesso modo, un account in sola lettura potrebbe essere assegnato a un apposito software di monitoraggio o di controllo conformità, che può leggere lo stato delle risorse e generare report periodici o fornire dashboard in tempo reale.

Ma è nella gestione degli account che hanno privilegi di creare, modificare o distruggere risorse che bisogna prestare più attenzione.

Idealmente ogni persona che ha accesso al sistema dovrebbe avere un account personale. Le identità condivise non permettono di associare i log degli eventi ad una persona responsabile e contribuiscono a creare pratiche deleterie, come lo scambio di password su canali insicuri. È bene discutere con i fornitori la gestione dei “segreti”, come password, chiavi, certificati, token, e in particolare dei token che possono o devono essere usati per automatizzare la gestione. Una percentuale importante delle compromissioni dei sistemi dipende dai comportamenti di chi usa il sistema e anche in questo caso prevenire significa aumentare la sicurezza di dati, informazioni e servizi.

Isolamento a livello di risorse

Il responsabile tecnico della PA, o chi da lui delegato, deve tendere alla creazione di ambienti cloud il più possibile isolati. Ogni fornitore dovrebbe avere il suo progetto/organizzazione, o se il fornitore gestisce più servizi, per ogni servizio ci dovrebbe essere il progetto corrispondente. Come è facile intuire, più i progetti sono frammentati più ci saranno delle complicazioni nella gestione dovute al cambio di contesto.

La possibilità di automatizzare anche la parte di gestione degli accessi permette di isolare i sistemi al giusto livello, senza dover ripetere manualmente le stesse configurazioni più volte. Il vantaggio di questa configurazione consiste nel fatto che l’ambiente messo a disposizione al fornitore è standard e riproducibile: il fornitore parte da una configurazione conosciuta e documentata, sulla quale può installare o reinstallare la sua soluzione in maniera automatica o facilmente automatizzabile.

Isolamento a livello di rete

Di norma ogni servizio installato in un progetto dovrebbe essere completamente isolato a livello di rete ed esporre solo gli endpoint necessari verso l’esterno oppure verso altri servizi. In primo luogo l’isolamento può avvenire attraverso i firewall, ma sono possibili e auspicabili anche accessi mediati da certificati, token, sistemi di autenticazione distribuita.

All’interno di un'infrastruttura cloud, che possiamo chiamare anche virtual data center, ogni fornitore potrebbe gestire in autonomia le configurazioni della rete. Una corretta gestione prevede, di solito, che ci sia una segmentazione delle reti, per esempio che i database gestiti sulle virtual machine o come Database as a Service (DBaaS) non siano direttamente esposti sulle reti pubbliche e condivise.

Se più fornitori necessitano di un accesso a una risorsa condivisa, le amministrazioni dovrebbero valutare caso per caso le migliori soluzioni, che possono spaziare da un accesso tramite rete (virtuale) condivisa, una VPN, oppure via endpoint pubblici o, ancora, tramite certificati. L’isolamento a livello di rete permette di definire e ridefinire le regole di accesso in maniera dinamica, oltre che consentire il monitoraggio del traffico per identificare e prevenire tempestivamente attacchi al sistema.

Backup, Restore e Disaster Recovery

Uno degli aspetti più critici dei servizi messi in esercizio attraverso l’ausilio di più fornitori è la gestione degli incidenti e delle emergenze. Situazioni dove è fondamentale identificare subito il livello in cui mettere in atto le prime contromisure e gestire le comunicazioni in fase emergenziale.

Qualche anno fa un cloud provider, a seguito di un incendio all’interno di uno dei suoi data center ha concluso l’annuncio dell'incidente con: vi raccomandiamo di attivare il vostro piano di disaster recovery. Per quanto la formula possa sembrare inopportuna, questo è quello che a volte accade nella realtà. E anche se i software qualificati da ACN offrono tutte le funzionalità necessarie per eseguire i backup e restore, la responsabilità ultima del funzionamento di un servizio rimane sempre in capo all’amministrazione.** **Avere un piano di disaster recovery per dei servizi cloud vuol dire, infatti, per la PA, **eseguire dei monitoraggi costanti, avere dei backup e soprattutto disporre di procedure condivise e aggiornate fra i fornitori **per procedere al ripristino dei sistemi in modo tempestivo.

La migrazione verso il cloud offre gli strumenti per implementare la business continuity e i piani di disaster recovery. In generale ogni fornitore ha chiaro come gestire il proprio sistema, ma non deve per forza essere a conoscenza di come questo si inserisce nel quadro dei servizi complessivi gestiti dalle amministrazione.

Per questo l’amministrazione deve accertarsi che per i fornitori sia chiaro come gestire le situazioni di emergenza, coordinandosi sulle risorse, come persone e hardware disponibile, sulle responsabilità, che devono essere preventivamente individuate, sulle tecnologie e sugli strumenti, per fare in modo che i livelli di servizio (SLA, Service Level Agreement) e, nei casi più gravi, gli obiettivi di punto e tempo di ripristino (RPO e RTO, Recovery Point/Time Objective) siano rispettati.

Le procedure di test per garantire la continuità di servizio sono onerose, sia in termini di risorse consumate (dovranno essere attivate delle virtual machine, dello storage, dei servizi PaaS aggiuntivi), sia di tempo (le persone devono trasferire, accendere, riconfigurare i servizi dal backup, controllare che tutto funzioni). Un processo che potrebbe essere lungo e faticoso, specialmente se le procedure non sono automatizzate. L’obiettivo a cui tendere è rendere la procedura sempre più automatica e testabile, per aumentare la resilienza generale del sistema.

Per una matrice delle responsabilità

Dopo aver analizzato i principali scenari in cui una Pubblica Amministrazione si trova normalmente a operare, è possibile ricostuire una matrice di gestione delle responsabilità, partendo come spunto da una situazione semplificata, con una Pubblica Ammnistrazione (PA), un fornitore generico, come può essere una software house, e un cloud provider (CP), che offre servizi cloud. Con la terminologia del modello di piano di migrazione adottato ai sensi del regolamento Cloud di AgID, un modello ripreso anche dagli Avvisi per il finanziamento della migrazione pubblicati su PA digitale 2026, possiamo così individuare le seguenti attribuzioni:

Oggetto	Migrazione con trasferimento	Migrazione con aggiornamento
Mantenimento Sistema Operativo	PA	Compreso nel SaaS
Mantenimento Servizio Custom su CP	Fornitore	/
Mantenimento Servizio in PaaS/SaaS direttamente da CP	/	CP
Mantenimento Servizio in PaaS/SaaS da Fornitore su CP	/	Fornitore
Mantenimento Infrastruttura CP	CP	CP

Per esteso, ci si aspetta che la PA, in caso di migrazione con trasferimento continui a gestire l’aggiornamento dei sistemi operativi sui quali è installato il servizio personalizzato che sarà gestito dal fornitore. Al cloud provider rimane in carico la gestione dei servizi cloud. In caso di migrazione con aggiornamento, la manutenzione del sistema operativo è compresa nel servizio SaaS (di norma questo avviene dietro le quinte, senza interruzioni di servizio). Il mantenimento del servizio sarà a carico di chi lo fornisce (CP o Fornitore) e ovviamente il mantenimento dei servizi cloud rimane in carico al CP.

Pur nella consapevolezza di non essere esaustivi, siamo certi che tracciare un perimetro chiaro delle responsabilità di ogni singolo attore in campo contribuisca a rafforzare la qualità dei progetti di migrazione, senza contare che l’adozione di strumenti come dashboard di controllo, vocabolari condivisi, segmentazione degli accessi nonchè di piani per il disaster recovery renda la gestione di un’infrastruttura cloud più efficace e performante, a tutto vantaggio dei cittadini.

Per rimanere aggiornato sui prossimi approfondimenti resta in contatto con noi su Slack Developers canale #cloud, iscriviti alla nostra mailing list e continua a seguirci sugli account Twitter di Developers Italia e Designers Italia.

Questo blog è redatto da Developers Italia