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 è solo un elenco di specifiche tecniche. Fissa ciò che un'amministrazione o un'azienda pretende dal fornitore e le conseguenze se le attese non vengono rispettate.

Il Manuale di abilitazione al cloud ricorda che lo SLA formalizza tipo e qualità del servizio attesi. Stabilisce anche cosa fare quando gli standard pattuiti non sono rispettati: metriche per misurare il servizio e misure o sanzioni se i livelli concordati non vengono raggiunti.

Il contesto italiano aggiunge un ulteriore livello di indirizzo. La Strategia Cloud Italia affronta tre sfide: assicurare l'autonomia tecnologica del Paese, garantire il controllo sui dati e accrescere la resilienza dei servizi digitali.

È 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.

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à cita anche la mitigazione del rischio di lock-in verso i fornitori.

Per i servizi destinati alle pubbliche amministrazioni esiste poi 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 essenziali.

Principali atti normativi italiani sul cloud e la sicurezza dei dati

Perimetro del servizio e responsabilità tra cliente e fornitore

Il primo passo è definire il modello di fruizione: IaaS, PaaS, SaaS o hosting gestito. Da qui discende il confine tra quanto gestisce il fornitore e quanto resta al cliente.

Il Manuale sottolinea che gli aspetti da considerare nello SLA per i servizi cloud possono adattarsi ai modelli SaaS, PaaS e IaaS. Questi modelli hanno 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 sulla classificazione dei dati e dei servizi pubblici.

Nel dettaglio, la determina n. 306 riguarda il modello per la predisposizione dell'elenco e della classificazione di dati e servizi; la determina n. 307 riguarda le ulteriori caratteristiche dei servizi cloud e i requisiti per la qualificazione. Gli atti fanno seguito alle disposizioni del Regolamento per i servizi cloud pubblicato dall'Agenzia per l'Italia Digitale (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.

Scriverle nero su bianco, distinguendo obblighi del fornitore, obblighi del cliente e attività condivise, evita che in caso di incidente ciascuno scarichi la colpa sull'altro. Nello stesso documento vanno individuati dati e servizi critici con i livelli di servizio attesi: su questi si concentrano SLA, continuità e penali.

Sicurezza e protezione dei dati: requisiti e metriche contrattuali

Il Manuale elenca alcuni indicatori di sicurezza utili per definire gli SLA. Sono protezione del dato, livelli di crittografia, politiche di backup, permessi di accesso e consultazione del dato, conformità alle normative vigenti.

Aggiunge le modalità e i tempi di comunicazione del provider quando si verifica una violazione dei dati. Vanno tradotte in obblighi verificabili, non in dichiarazioni di principio.

Per ogni voce vanno definiti requisito tecnico e modalità di verifica. Quando 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?

Sulle 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 adottare lo stesso approccio proporzionato. Requisiti più stringenti per i servizi critici, più leggeri per quelli non critici, ma sempre in metriche misurabili e verificabili.

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

La disponibilità va indicata in percentuale e anche in tempo di indisponibilità ammesso. Il Manuale fornisce i riferimenti di conversione.

99,9% di uptime equivale a 8,77 ore di downtime all'anno; 99,99% a 52,60 minuti all'anno.

99,999% a 5,26 minuti all'anno; 99,9999% a 31,5 secondi all'anno.

Scegliere la percentuale significa stabilire quanta indisponibilità è tollerabile per quel servizio.

Oltre all'uptime, il Manuale cita altre metriche. La capacità del servizio indica carico o numero massimo di utenti che possono accedere, con opzioni per ampliarlo.

Il monitoring delle performance riguarda come il fornitore monitorerà e riporterà le prestazioni del sistema. Il supporto si distingue nelle due metriche fondamentali del tempo di risposta e del tempo di risoluzione.

Il capitolato dovrebbe precisare anche finestre di manutenzione programmata, criteri di esclusione dal calcolo della disponibilità e metodo di misurazione.

È utile distinguere SLA e KPI. Lo SLA è l'accordo con il fornitore che definisce servizio e 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 anche forme diverse di accordo: a livello di cliente, a livello di servizio e multilivello.

Livelli di disponibilità SLA: tempi massimi di downtime all'anno

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

La continuità va richiesta esplicitamente, non data per implicita. Le politiche di backup rientrano fra gli indicatori di sicurezza che il Manuale invita a definire.

Il capitolato deve indicare frequenza dei backup, tipo di copia, periodo di conservazione e separazione delle copie. Deve precisare anche cifratura, verifiche periodiche di ripristino e tempi attesi di ripristino.

Senza prove di ripristino documentate, l'esistenza dei backup resta un'affermazione non verificata.

Sulla resilienza va chiesto come il servizio è progettato per resistere al guasto di un componente. Occorre indicare ridondanza, distribuzione su più zone, capacità di failover e 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 suo 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.

Può essere utile chiedere di essere informati in caso di aggiornamenti o cambiamenti rilevanti, per 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 include tra le metriche da definire il monitoring delle performance, cioè le 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: strumenti di monitoraggio e copertura, frequenza di rilevazione, definizione univoca di metriche e formule di calcolo, fonte dei dati.

Occorre precisare 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à. Il cliente deve poter accedere a dati ed evidenze di monitoraggio, richiedere report aggiuntivi, effettuare verifiche o audit e 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 è esplicito: lo SLA definisce anche misure o sanzioni da attuare 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, per esempio, supporto aggiuntivo o sconti sui prezzi.

Tra gli elementi comuni figurano anche procedure di escalation e 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 su 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 di accessi e log.

Occorre vietare di usare i dati per finalità proprie e disciplinare i sub-responsabili.

Il fornitore deve supportare il cliente nella gestione degli incidenti e nell'eventuale notifica all'autorità di controllo e agli interessati.

Alla cessazione del rapporto vanno previste cancellazione o restituzione dei dati.

Sulle violazioni dei dati servono tempi e modalità precisi. Il Manuale include fra gli indicatori di sicurezza le modalità e i tempi di comunicazione del provider quando si verifica un data breach.

Il capitolato dovrebbe stabilire il termine massimo entro cui il fornitore informa il cliente. Va indicato anche il referente a cui inviare la comunicazione.

Occorre definire 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 l'obbligo di restituire o rendere disponibili i dati alla cessazione, in formati aperti e documentati e con tempi definiti.

Va garantita assistenza al passaggio verso un altro fornitore o un'infrastruttura interna, oltre all'esportazione di configurazioni, log e metadati.

Occorre vietare di trattenere i dati oltre il termine concordato e prevedere la cancellazione delle copie residue. Il servizio deve restare continuo 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 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 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 violazione dei dati.

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.