Conservazione accreditata Agid in cloud? Ma le norme vanno rifatte, ecco perché

Si è molto dibattuto, negli ultimi mesi, intorno alla necessità (o quantomeno opportunità) che un servizio di conservazione accreditato possa essere erogato in modalità “cloud” e, conseguentemente, se tale servizio debba poi essere qualificato ai sensi della Circolare AgID 3/2018. La discussione è complessa, vediamo nello specifico su quali elementi verte.

La mancanza di una definizione di cloud

Sembra assurdo ma nell’attuale normativa, primaria e secondaria, risulta assente una definizione di cosa sia “cloud”. Senza imbarcarci in complesse disquisizioni tecniche (dalle quali, mancando una definizione normativa, è impossibile cavarne qualcosa) manca ad oggi un parametro di riferimento per poter valutare correttamente se la propria soluzione sia effettivamente offerta in modalità “cloud” o meno.

L’unica definizione rintracciabile, in quanto in parte richiamata dalle Circolari AgID 2 e 3 del 2018, è quella data dal NIST: Il cloud computing è un modello per abilitare, tramite la rete, l’accesso diffuso, agevole e a richiesta, ad un insieme condiviso e configurabile di risorse di elaborazione (ad esempio reti, server, memoria, applicazioni e servizi) che possono essere acquisite e rilasciate rapidamente e con minimo sforzo di gestione o di interazione con il fornitore di servizi. Sempre secondo la definizione del NIST (comunque non chiaramente richiamata dalla nostra normativa) il “cloud” è composto da cinque caratteristiche essenziali, tre modalità di servizio e quattro modelli di distribuzione^[1].

Le tipologie e le modalità di realizzazione di soluzioni “cloud” sono effettivamente molteplici. E la mancanza, a livello normativo, di limiti e confini precisi tra cosa sia o non sia “cloud” sarà sicuramente un problema che torneremo ad affrontare, sempre più spesso, anche in un’aula di tribunale.

Servizi di conservazione sfruttando modelli Cloud (IaaS o PaaS)

La normativa primaria attualmente in vigore non prevede vincoli tecnologici per la realizzazione di servizi di conservazione. Vi è però da considerare quanto previsto dall’art. 9, comma 2, del DPCM 3 dicembre 2013^[2] in base al quale molti commentatori hanno ritenuto che la realizzazione di servizi di conservazione che utilizzassero infrastrutture o piattaforme “cloud” fossero difficilmente realizzabili. Accanto a tale prescrizione, vi è poi un requisito di qualità e sicurezza^[3] che devono rispettare tutti i conservatori che intendono ottenere (o hanno già ottenuto) l’accreditamento ad AgID come conservatori ai sensi dell’art. 29 del CAD, il n. 72: “le diverse componenti critiche e significative (“sensitive”) del sistema di conservazione sono isolate da altri ambienti, organizzativamente, fisicamente e logicamente”. Pur mancando, come detto, una definizione normativa di cosa sia “cloud” appare difficile (se non impossibile) che un servizio basato su modelli “cloud” possa garantire l’isolamento organizzativo, fisico e logico, delle proprie componenti critiche.

Che però, oggi, tali servizi non possano essere offerti sfruttando anche gli innegabili vantaggi dei modelli “cloud” sembra effettivamente anacronistico. La normativa regolamentare, così come i requisiti di qualità e sicurezza richiesti ai conservatori accreditati dovrebbero, quindi, essere aggiornati quanto prima per permettere di poter realizzare soluzioni di volta in volta (a seconda dell’evolversi del contesto tecnologico e non innamorandosi della tecnologia del momento) in grado di garantire la maggiore efficienza, efficacia ed economicità possibile.

Servizi di conservazione come servizi (SaaS)

L’art. 34 del D.Lgs. 82/2005 (come da ultimo modificato dal D.Lgs. 217/2017) prevede che “Le pubbliche amministrazioni possono procedere alla conservazione dei documenti informatici: a) all’interno della propria struttura organizzativa; b) affidandola, in modo totale o parziale, nel rispetto della disciplina vigente, ad altri soggetti, pubblici o privati accreditati come conservatori presso l’AgID”. A questo punto è doveroso, però, chiedersi se un servizio affidato ad un conservatore esterno possa poi essere usufruito in modalità SaaS. Se, infatti, è sicuramente possibile immaginare una PA che realizzi un proprio servizio di conservazione acquisendo uno specifico software in tale modalità, non si comprende come possa parlarsi di SaaS laddove la PA intende affidare la realizzazione del vero e proprio servizio ad un soggetto esterno. E chi conosce la complessità di un sistema di conservazione sa bene di cosa stiamo parlando.

In caso di affidamento di un servizio ad un conservatore esterno, infatti, il soggetto Produttore non acquista un software da utilizzare come se fosse un servizio ma acquista il risultato di tale servizio, ovvero la corretta conservazione effettuata secondo metodi e attraverso il ricorso a specifiche competenze in grado, esse e non un software, di garantire la corretta conservazione a norma dei documenti informatici.

Inoltre, anche riprendendo la definizione di “cloud” fornita dal NIST (National Institute of Standards and Technology), ci si ritrova spiazzati in quanto l’obiettivo di esternare un servizio di conservazione non è e non può essere quello di utilizzare da remoto le applicazioni del fornitore funzionanti su un’infrastruttura cloud… ma, bensì, di definire e gestire un sistema che adotti regole, procedure e tecnologie, in grado di garantire le caratteristiche di autenticità, integrità, affidabilità, leggibilità, reperibilità ai documenti in esso conservati.

Tanto è ribadito dai compiti che, sulla base dei profili professionali richiesti per l’accreditamento dei conservatori, sono posti in capo al Responsabile del servizio di conservazione (ruolo interno al conservatore): se, infatti, spetta a tale ruolo la definizione e l’attuazione delle politiche complessive del sistema di conservazione, nonché la corretta gestione nel lungo termine, allora davvero non si comprende come possa parlarsi di un’erogazione di tale servizio in modalità SaaS.

Conclusioni

Pur se l’attuale normativa non sembra permettere la realizzazione di soluzioni di conservazione in “cloud”, restiamo convinti che i tempi siano ormai maturi per poter superare tale posizione e permettere che i sistemi di conservazione (interni o esterni) vengano realizzati sfruttando, a determinate e chiare condizioni di sicurezza, modelli tecnologici basati su “cloud”.

Andranno, però, rivisti sia la normativa tecnica relativa ai servizi di conservazione accreditati (possibilmente con la definizione delle nuove Linee guida previste dall’attuale art. 71 del CAD) che i corrispondenti requisiti di qualità e sicurezza previsti da AgID per i conservatori accreditati, ai quali dovranno essere aggiunti quelli richiesti per la realizzazione di sistemi di conservazione che sfruttino risorse in “cloud”.

Diversamente da altri servizi esternalizzati dalle PA, infatti, per la conservazione esistono già precise regole di accreditamento che è inutile e potenzialmente dannoso duplicare. In tal modo, infatti, i requisiti che il conservatore deve soddisfare (e non solo quelli relativi alla tecnologia da questo adottata) potranno essere oggetto di una più attenta azione di valutazione, controllo e vigilanza (e non semplicemente “autocertificati”) tramite le procedure già esistenti.

In occasione della XII edizione del DIG.Eat, l’evento annuale di Anorc che si terrà il 30 maggio a Roma, avremo modo di affrontare le novità in tema di conservazione digitale e strategia Cloud, in compagnia di numerosi esperti nazionali ed esponenti istituzionali, tra cui lo stesso Luca Attias, Commissario Straordinario per l’attuazione dell’Agenda Digitale Italiana.

Note

1. Caratteristiche essenziali:
   • Self-service su richiesta. Un consumatore può acquisire unilateralmente e automaticamente le necessarie capacità di calcolo, come tempo macchina e memoria, senza richiedere interazione umana con i fornitori di servizi.
   • Ampio accesso in rete. Le capacità sono disponibili in rete e accessibili attraverso meccanismi standard che promuovono l’uso attraverso piattaforme eterogenee come client leggeri o pesanti (come ad esempio telefoni mobili, tablet, laptops e workstations).
   • Condivisione delle risorse. Le risorse di calcolo del fornitore sono messe in comune per servire molteplici consumatori utilizzando un modello condiviso (multi-tenant), con le diverse risorse fisiche e virtuali assegnate e riassegnate dinamicamente in base alla domanda. Dato il senso di indipendenza dalla locazione fisica, l’utente generalmente non ha controllo o conoscenza dell’esatta ubicazione delle risorse fornite, ma può essere in grado di specificare la posizione ad un livello superiore di astrazione (ad esempio, paese, stato o data center). Esempi di risorse includono memoria, elaborazione e larghezza di banda della rete.
   • Elasticità rapida. Le risorse possono essere acquisite e rilasciate elasticamente, in alcuni casi anche automaticamente, per scalare rapidamente verso l’esterno e l’interno in relazione alla domanda. Al consumatore, le risorse disponibili spesso appaiono illimitate e disponibili in qualsiasi quantità, in qualsiasi momento.
   • Servizio misurato. I sistemi cloud controllano automaticamente e ottimizzano l’uso delle risorse, facendo leva sulla capacità di misurazione ad un livello di astrazione appropriato per il tipo di servizio (ad esempio memoria, elaborazione, larghezza di banda e utenti attivi). L’utilizzo delle risorse può essere monitorato, controllato e segnalato, fornendo trasparenza sia per il fornitore che per l’utilizzatore del servizio.

   Modelli di servizio:

   • Software come Servizio (SaaS da Software as a Service). La facoltà fornita al consumatore è quella di utilizzare le applicazioni del fornitore funzionanti su un’infrastruttura cloud. Le applicazioni sono accessibili da diversi dispositivi attraverso un’interfaccia leggera (thin client), come ad esempio un’applicazione e-mail su browser, oppure da programmi dotati di apposita interfaccia. Il consumatore non gestisce o controlla l’infrastruttura cloud sottostante, compresi rete, server, sistemi operativi, memoria, e nemmeno le capacità delle singole applicazioni, con la possibile eccezione di limitate configurazioni a lui destinate (parametrizzazione).
   • Piattaforma come Servizio (PaaS da Platform as a Service). La facoltà fornita al consumatore è quella di distribuire sull’infrastruttura cloud applicazioni create in proprio oppure acquisite da terzi, utilizzando linguaggi di programmazione, librerie, servizi e strumenti supportati dal fornitore. Il consumatore non gestisce né controlla l’infrastruttura cloud sottostante, compresi rete, server, sistemi operativi, memoria, ma ha il controllo sulle applicazioni ed eventualmente sulle configurazioni dell’ambiente che le ospita.
   • Infrastruttura come Servizio (IaaS da Infrastructure as a Service). La facoltà fornita al consumatore è quella di acquisire elaborazione, memoria, rete e altre risorse fondamentali di calcolo, inclusi sistemi operativi e applicazioni. Il consumatore non gestisce né controlla l’infrastruttura cloud sottostante, ma controlla sistemi operativi, memoria, applicazioni ed eventualmente, in modo limitato, alcuni componenti di rete (esempio firewalls). Una infrastruttura cloud è l’insieme di hardware e software che abilita le cinque caratteristiche essenziali del cloud computing. L’infrastruttura cloud può essere vista come contenente sia uno strato fisico che uno di astrazione. Lo strato fisico consiste nelle risorse hardware necessarie a supportare i servizi cloud da erogare e tipicamente comprende server, dischi e componenti di rete. Lo strato di astrazione consiste nel software installato sullo strato fisico, che manifesta le caratteristiche essenziali del cloud. Concettualmente lo strato di astrazione sta sopra a quello fisico. Questa possibilità non preclude necessariamente l’uso di linguaggi di programmazione, librerie, servizi e strumenti compatibili da altre fonti.

   Modelli di Distribuzione:

   • Cloud privato. L’infrastruttura cloud è fornita per uso esclusivo da parte di una singola organizzazione comprendente molteplici consumatori (ad esempio filiali). Può essere posseduta, diretta e gestita dall’organizzazione stessa, da una società terza o da una combinazione delle due, e può esistere dentro o fuori le proprie sedi.
   • Cloud comunitario. L’infrastruttura cloud è fornita per uso esclusivo da parte di una comunità di consumatori di organizzazioni con interessi comuni (ad esempio missione, requisiti di sicurezza, vincoli di condotta e di conformità). Può essere posseduta, diretta e gestita da una o più delle organizzazioni della comunità, da una società terza o una combinazione delle due e può esistere dentro o fuori le proprie sedi.
   • Cloud pubblico. L’infrastruttura cloud è fornita per un uso aperto a qualsiasi consumatore. Può essere posseduta, diretta e gestita da un’azienda, da un’organizzazione accademica o governativa oppure da una combinazione delle precedenti. Esiste dentro le sedi del fornitore cloud.
   • Cloud ibrido. L’infrastruttura è una composizione di due o più infrastrutture cloud (privata, comunitaria o pubblica) che rimangono entità distinte, ma unite attraverso tecnologie standard o proprietarie, che abilitano la portabilità di dati e applicazioni (ad esempio per bilanciare il carico di lavoro tra cloud).

   ↑

2. Fatto salvo quanto previsto dal decreto legislativo 22 gennaio 2004, n. 42, in ordine alla tutela, da parte del Ministero dei beni e delle attività culturali e del turismo, sugli archivi e sui singoli documenti dello Stato, delle regioni, degli altri enti pubblici territoriali, nonché di ogni altro ente ed istituto pubblico, i sistemi di conservazione delle pubbliche amministrazioni e i sistemi di conservazione dei conservatori accreditati, ai fi ni della vigilanza da parte dell’Agenzia per l’Italia digitale su questi ultimi, prevedono la materiale conservazione dei dati e delle copie di sicurezza sul territorio nazionale e garantiscono un accesso ai dati presso la sede del produttore e misure di sicurezza conformi a quelle stabilite dal presente decreto ↑
3. https://www.agid.gov.it/sites/default/files/repository_files/documentazione/requisiti_di_qualita_e_sicurezza_v.1.1.pdf ↑