Capitolato per servizi cloud e hosting: sicurezza, SLA e continuità

Perché il capitolato deve integrare sicurezza, SLA e continuità

Un capitolato per servizi cloud e hosting non è una semplice lista di specifiche tecniche: è il documento con cui un'amministrazione o un'azienda mette per iscritto cosa pretende dal fornitore e cosa succede se tali aspettative restano disattese. Il Manuale di abilitazione al cloud ricorda che lo SLA, oltre a formalizzare le attese su tipo e qualità del servizio, stabilisce le misure da adottare quando gli standard pattuiti non sono rispettati; in pratica indica le metriche con cui misurare il servizio e le misure o sanzioni da applicare se i livelli concordati non vengono raggiunti.

Il contesto italiano introduce poi un ulteriore livello di indirizzo. La Strategia Cloud Italia, pubblicata a settembre 2021 dal Dipartimento per la trasformazione digitale e dall'Agenzia per la cybersicurezza nazionale nel percorso attuativo dell'art. 33-septies del decreto-legge n. 179 del 2012, affronta tre sfide principali: assicurare l'autonomia tecnologica del Paese, garantire il controllo sui dati e accrescere la resilienza dei servizi digitali. Il Piano triennale ICT richiama il principio cloud first: le amministrazioni devono valutare in via prioritaria l'adozione del paradigma cloud e motivare un eventuale esito negativo; tra le opportunità del percorso cita anche la mitigazione del rischio di lock-in verso i fornitori.

Per i servizi rivolti alle pubbliche amministrazioni esiste inoltre un quadro di qualificazione: i servizi qualificati da ACN devono rispettare requisiti e SLA stabiliti nel Regolamento Cloud, adottato con decreto direttoriale n. 21007/24 del 27 giugno 2024 e applicabile dal 1° agosto 2024. Anche se il capitolato non riguarda una PA, quel quadro resta un riferimento utile per individuare clausole e metriche che non dovrebbero mancare.

Livelli di qualificazione dei servizi cloud (ACN, Regolamento Cloud n. 21007/24)

1. Qualificazione Base — Servizi non critici, dati non sensibili. Requisiti minimi di sicurezza e SLA.

Perimetro del servizio e responsabilità tra cliente e fornitore

Il primo passo consiste nel definire il modello di fruizione del servizio — IaaS, PaaS, SaaS o hosting gestito — e quindi il confine tra quanto gestisce il fornitore e quanto resta a carico del cliente. Il Manuale di abilitazione al cloud sottolinea che gli aspetti da considerare nella stesura di uno SLA per servizi cloud possono essere adattati ai diversi modelli SaaS, PaaS e IaaS, che presentano confini di responsabilità differenti.

Al perimetro tecnico va affiancata una classificazione di dati e servizi. Nel settore pubblico, il 18 gennaio 2022 l'Agenzia per la cybersicurezza nazionale, con il Dipartimento per la trasformazione digitale, ha predisposto gli atti che definiscono le modalità di classificazione dei dati e dei servizi pubblici e i requisiti per le tipologie di qualificazione dei servizi cloud (determine n. 306 e n. 307), dopo il Regolamento per i servizi cloud pubblicato da AgID a dicembre 2021; la Strategia Cloud Italia prevede quattro tipologie di qualificazione. Anche nel privato conviene adottare una classificazione interna: dati personali, dati critici, servizi essenziali e servizi che tollerano interruzioni.

Dal perimetro discendono le responsabilità operative: chi applica gli aggiornamenti, chi gestisce identità e accessi, chi risponde agli incidenti, chi conserva e protegge i log, chi comunica con gli utenti finali. Metterle per iscritto, distinguendo obblighi del fornitore, obblighi del cliente e attività condivise, evita che in caso di incidente ciascuna parte scarichi la responsabilità sull'altra. Nello stesso documento vanno individuati dati e servizi critici con i livelli di servizio attesi: è su questi che si concentrano SLA, continuità e penali.

Sicurezza e protezione dei dati: requisiti e metriche contrattuali

Il Manuale di abilitazione al cloud elenca, tra le metriche di sicurezza da considerare nella definizione degli SLA: protezione del dato, livelli di crittografia, politiche di backup, permessi di accesso e consultazione del dato, conformità alle normative vigenti, modalità e tempi di comunicazione del provider in caso di data breach. Sono voci da tradurre in obblighi verificabili, non in dichiarazioni di principio.

Per ogni voce vanno definiti il requisito tecnico e la modalità di verifica: in quali casi i dati sono cifrati a riposo e in transito e con quali standard; chi genera, custodisce e gestisce le chiavi; quali profili di accesso esistono e con quale processo vengono autorizzati, riesaminati e revocati; come sono registrati gli accessi e per quanto tempo i log vengono conservati. Sul fronte delle notifiche occorre fissare canale, referente, tempi massimi di comunicazione e contenuto minimo dell'informativa in caso di incidente.

Nel settore pubblico il livello di sicurezza atteso dipende dalla classificazione del dato e del servizio: gli atti di qualificazione richiamano requisiti aggiuntivi di qualità, sicurezza, performance e scalabilità, differenziati per tipologia di qualificazione. Nel privato è buona pratica seguire lo stesso approccio proporzionato: requisiti più stringenti per i servizi critici, più leggeri per quelli non critici, ma sempre espressi in metriche misurabili e verificabili.

SLA misurabili: disponibilità, capacità, performance e supporto

La disponibilità va indicata in percentuale e, insieme, in tempo di indisponibilità ammesso. Il Manuale di abilitazione al cloud offre i riferimenti per la conversione: 99,9% di uptime equivale a 8,77 ore di downtime in un anno; 99,99% a 52,60 minuti in un anno; 99,999% a 5,26 minuti in un anno; 99,9999% a 31,5 secondi in un anno. Scegliere la percentuale vuol dire stabilire quanta indisponibilità è tollerabile per quel servizio.

Oltre all'uptime, il Manuale cita altre metriche da considerare: la capacità del servizio, cioè il carico o il numero massimo di utenti che possono accedere e le opzioni per ampliare questo numero; il monitoring delle performance, ossia le modalità con cui il fornitore monitorerà e riporterà le prestazioni del sistema; il supporto, distinto nelle due metriche fondamentali del tempo di risposta e del tempo di risoluzione. Il capitolato dovrebbe precisare anche le finestre di manutenzione programmata, i criteri di esclusione dal calcolo della disponibilità e il metodo di misurazione.

È utile distinguere tra SLA e KPI: lo SLA è l'accordo con il fornitore che definisce il servizio e il livello di prestazioni attesi, come misurare e approvare le prestazioni e cosa accade se i livelli non vengono soddisfatti; i KPI sono le misure usate per valutare il servizio. Un capitolato efficace contrattualizza pochi indicatori con conseguenze definite e ne monitora un insieme più ampio come KPI. Esistono inoltre forme diverse di accordo: a livello di cliente, a livello di servizio e multilivello.

Livelli di disponibilità SLA: tempi massimi di downtime annuo

Continuità operativa e resilienza: backup, ripristino e cambi infrastrutturali

La continuità va richiesta in modo esplicito, non considerata implicita. Le politiche di backup rientrano tra le metriche di sicurezza che il Manuale di abilitazione al cloud invita a definire. Nel capitolato occorre indicare frequenza dei backup, tipo di copia, periodo di conservazione, separazione delle copie, cifratura, verifiche periodiche di ripristino e tempi attesi di ripristino. Senza prove di ripristino documentate, l'esistenza dei backup resta un'affermazione non verificata.

Sul fronte della resilienza va chiesto come il servizio è progettato per resistere al guasto di un componente: ridondanza, distribuzione su più zone, capacità di failover, comportamento in condizioni di sovraccarico. Il tema dell'infrastruttura ad alta affidabilità è richiamato esplicitamente nel percorso italiano di adozione del cloud da parte delle amministrazioni, il cui obiettivo dichiarato è aumentare la resilienza dei servizi digitali.

Un ultimo blocco riguarda i cambi infrastrutturali. Il Manuale osserva che, per i provider cloud, i cambiamenti infrastrutturali sono molto più frequenti e vengono eseguiti in maniera trasparente, ma può essere utile chiedere al fornitore di essere informati in caso di aggiornamenti o cambiamenti rilevanti, così da pianificare e avvisare gli utenti di possibili downtime. Il capitolato dovrebbe precisare preavviso minimo, canale di comunicazione, contenuto dell'informativa, disciplina della manutenzione programmata e responsabilità della comunicazione verso gli utenti finali.

Monitoraggio, reportistica e verificabilità degli SLA

Il Manuale di abilitazione al cloud include tra le metriche da definire il monitoring delle performance, inteso come definizione delle modalità con cui il fornitore monitorerà e riporterà le prestazioni del sistema. Il capitolato deve quindi descrivere non solo gli obiettivi, ma anche il sistema con cui vengono misurati.

Gli elementi utili da negoziare sono: strumenti di monitoraggio e relativa copertura, frequenza di rilevazione, definizione univoca delle metriche e delle formule di calcolo, fonte dei dati, periodo di riferimento, report periodici con contenuti minimi, disponibilità di un cruscotto accessibile al cliente e canale di comunicazione in caso di anomalie.

Alla parte descrittiva va aggiunta la verificabilità: diritto del cliente di accedere ai dati di monitoraggio e alle evidenze, di richiedere report aggiuntivi, di effettuare verifiche o audit e di contestare i valori comunicati entro un termine definito. Altri elementi, come le procedure di escalation, rientrano tipicamente nella struttura di uno SLA per il cliente. Il principio è semplice: una metrica che il cliente non può verificare difficilmente è una metrica contrattuale.

Penali, rimedi e gestione degli inadempimenti

Il legame tra metriche e conseguenze è parte integrante dello SLA. Il Manuale di abilitazione al cloud è esplicito: lo SLA definisce anche misure o sanzioni da mettere in atto se i livelli concordati non sono soddisfatti. Ogni livello di servizio contrattualizzato dovrebbe quindi prevedere una conseguenza in caso di mancato raggiungimento.

Secondo la descrizione degli elementi tipici di uno SLA, le azioni da intraprendere quando i requisiti non sono soddisfatti possono includere, ad esempio, un supporto aggiuntivo o sconti sui prezzi; tra gli elementi comuni figurano anche le procedure di escalation e i termini per la cancellazione. Per ogni rimedio vanno definiti soglie di attivazione, criterio di calcolo, eventuali massimali, tempi di applicazione e modalità di contestazione.

Va disciplinato anche il processo: chi rileva l'inadempimento, entro quanto va contestato, chi risponde per il fornitore, entro quanto va proposto un piano di rientro, chi ne verifica l'efficacia. Indicare in anticipo referenti, livelli di escalation e tempi riduce il rischio che un problema tecnico diventi una disputa contrattuale.

Privacy, data breach e ruoli nel trattamento

In un servizio cloud il fornitore tratta dati per conto del cliente: il cliente determina finalità e modalità del trattamento, il fornitore opera in base alle istruzioni ricevute. Il Garante per la protezione dei dati personali ha affrontato il tema nel parere WP 196 sul cloud computing, richiamando le responsabilità del cliente di servizi cloud. Il capitolato deve riflettere questa distinzione e indicare per iscritto chi fa che cosa: ruolo del cliente, ruolo del fornitore, eventuali sub-fornitori coinvolti.

Le clausole da prevedere riguardano: istruzioni documentate del cliente, riservatezza del personale autorizzato, misure di sicurezza adeguate, gestione degli accessi e dei log, divieto di usare i dati per finalità proprie, disciplina dei sub-responsabili, supporto al cliente nella gestione degli incidenti e nell'eventuale notifica all'autorità di controllo e agli interessati, cancellazione o restituzione dei dati alla cessazione del rapporto.

Sul data breach servono tempi e modalità precisi: il Manuale di abilitazione al cloud include tra le metriche di sicurezza le modalità e i tempi di comunicazione del provider in caso di data breach. Il capitolato dovrebbe stabilire il termine massimo entro cui il fornitore informa il cliente, il referente a cui inviare la comunicazione, le informazioni minime da trasmettere e l'obbligo di cooperare nelle attività di accertamento e mitigazione.

Uscita dal contratto, portabilità e riduzione del lock-in

Il Piano triennale ICT annovera tra le opportunità del percorso di adozione del cloud la mitigazione del rischio di lock-in verso i fornitori. La riduzione del lock-in, però, si costruisce in fase di redazione del capitolato, non al momento dell'uscita.

Le clausole da prevedere riguardano: obbligo di restituire o rendere disponibili i dati alla cessazione, in formati aperti e documentati e con tempi definiti; assistenza al passaggio verso un altro fornitore o verso un'infrastruttura interna; esportazione di configurazioni, log e metadati; divieto di trattenere i dati oltre il termine concordato; cancellazione delle copie residue; continuità del servizio durante la migrazione.

Vanno fissati anche gli aspetti economici: cosa è incluso nell'uscita e cosa è a pagamento, con quali tariffe e con quale preavviso il cliente può recedere. Tra gli elementi comuni di uno SLA figurano infatti anche i termini per la cancellazione: inserirli esplicitamente nel contratto riduce il rischio di restare vincolati a un fornitore per ragioni tecniche o di dati non esportabili.

Checklist operativa per redigere il capitolato

Perimetro e responsabilità • Modello di servizio dichiarato (IaaS, PaaS, SaaS, hosting) e confini del servizio. • Elenco dei dati e dei servizi critici con la relativa classificazione. • Matrice delle responsabilità: attività del fornitore, del cliente e condivise. • Referenti tecnici e contrattuali per ciascuna parte.

Sicurezza • Protezione del dato, livelli di crittografia, gestione delle chiavi. • Permessi di accesso e consultazione, registrazione dei log, riesame periodico dei profili. • Politiche di backup e conformità alle normative applicabili. • Modalità e tempi di comunicazione in caso di data breach.

SLA • Uptime in percentuale e in tempo di indisponibilità ammesso nell'anno. • Capacità del servizio e opzioni di espansione. • Performance e modalità di monitoraggio. • Tempo di risposta e tempo di risoluzione del supporto. • Finestre di manutenzione, criteri di esclusione e metodo di misurazione. • Distinzione esplicita tra indicatori contrattuali (SLA) e KPI di monitoraggio.

Continuità • Frequenza, conservazione, cifratura e separazione delle copie di backup. • Prove di ripristino documentate e tempi di ripristino attesi. • Ridondanza e capacità di failover. • Preavviso e comunicazione per aggiornamenti, cambi infrastrutturali rilevanti e downtime pianificati.

Monitoraggio, rimedi e privacy • Report periodici, cruscotto, diritto di verifica e audit, contestazione delle metriche. • Penali o sconti, supporto aggiuntivo, piani di rientro, procedure di escalation e relativi tempi. • Ruoli nel trattamento dei dati, istruzioni, sub-responsabili, gestione degli incidenti, cancellazione o restituzione dei dati.

Uscita dal contratto • Formati aperti e documentati per la restituzione dei dati. • Tempi di rilascio, assistenza al passaggio, costi dell'uscita e termini di cancellazione. • Verifica dei requisiti di qualificazione applicabili, per le amministrazioni, rispetto al Regolamento Cloud adottato da ACN con decreto direttoriale n. 21007/24 del 27 giugno 2024.