Qualificazione AGID e sicurezza applicativa per le PPAA: un efficace ambito d’intervento per infrastrutture e servizi in-Cloud più robusti
Nell’ambito del Piano Triennale per l’Informatica nella Pubblica Amministrazione 2019-2021, con l’obiettivo di qualificare servizi e infrastrutture cloud secondo specifici parametri di sicurezza, affidabilità strutturale ed elevato QoS, stanno assumendo sempre maggior rilievo le procedure operative che devono portare Analisti e Sviluppatori software – così come i Service Providers – a elaborare prodotti e servizi nel rispetto dei principali standard definiti a livello internazionale, omogenei e universalmente riconosciuti. Le modalità di soddisfacimento di tali requisiti sono state definite nei dettagli da AGID all’interno di un percorso di qualificazione, rivolto a soggetti fornitori di software e servizi in ambito pubblico.
Lo scenario
Il modello Cloud per le PPPA prevede servizi e infrastrutture qualificate di tipo public, private e community parallelamente all’introduzione del principio cloud first, in base al quale le amministrazioni sono tenute a valutare l’adozione di servizi digitali disponibili in-cloud prima di qualsiasi altra soluzione tradizionale. Si tratta di un tassello fondamentale all’interno di un disegno più ampio declinato nel noto Piano Triennale per l’informatica nella PA 2019-2021, i cui obiettivi dichiarati sono quelli di favorire la transizione a modelli di gestione digitale più facilmente scalabili verso architetture che, in ambito privato, risultano invece già piuttosto diffuse.
Gli obiettivi del percorso di qualificazione
Il percorso si rivolge a servizi qualificati identificabili sia all’interno della categoria di CSP (Cloud Service Provider) e sia tra i fornitori di applicativi ascrivibili alla tipologia di Software as a service (Saas), in modo tale da garantire il rispetto di elevati canoni di affidabilità̀ e sicurezza, considerati necessari per i servizi digitali pubblici.
La qualificazione CSP prevede che il Fornitore qualifichi la propria infrastruttura Cloud e si suddivide in 3 tipologie, in funzione dello specifico scopo:
- CSP – Tipo A: Il fornitore vuole qualificare sia la sua Infrastruttura, sia servizi Infrastructure as a Service (IAAS) e/o Platform as a Service (PAAS) per poterli vendere. Questo tipo non prevede la vendita di servizi Software as a Service (SAAS) da parte del fornitore.
- CSP – Tipo B: Il fornitore vuole qualificare sia la sua infrastruttura, sia servizi SAAS per poterli vendere. Non si prevede la vendita di servizi IAAS e/o PAAS da parte del fornitore.
- CSP – Tipo C: Il fornitore vuole qualificare sia la sua Infrastruttura, sia servizi IAASe/o PAAS, sia servizi SAAS per poterli vendere.
Per il più ampio contesto di Saas, i macro obiettivi imposti da Agid al fine di ottenere la qualificazione consistono in vari punti, suddivisi in base alla natura tecnologico-semantica dei contesti:
- la sicurezza applicativa;
- la disponibilità di un adeguato supporto tecnico per il cliente;
- la trasparenza e la disponibilità di informazioni dettagliate e aggiornate sulle modalità di erogazione del servizio e di esportazione dei dati;
- la disponibilità di incident report, statistiche e strumenti di monitoraggio;
- un insieme minimo di livelli di servizio garantiti obbligatori;
- la protezione dei dati e la portabilità in tutte le fasi di avanzamento della fornitura;
- l’interoperabilità mediante opportune API;
- l’esportabilità dei propri dati in un formato interoperabile verso un’altra piattaforma, per ridurre il rischio di dipendenza esclusiva della PA dal fornitore (lock in).
Un esempio concreto di adeguamento tecnico fattivo
Con particolare riferimento agli aspetti del percorso di qualificazione AGID rivolti ai fornitori Software as-a-service (Saas) della PA, presupponendo quindi che l’ipotetico software considerato si avvalga di architetture CSP qualificate, consideriamo qui un esempio reale di tematiche da affrontare: qualora ci si trovasse nella situazione di dover reingegnerizzare un modulo applicativo, mantenendo determinati standard di compliance Agid stilati in precedenza, lo sviluppatore e il fornitore dovrebbero impostare una fase analitica idonea a considerare ogni elemento di rischio dell’attività intrapresa.
La porzione di software qui ipotizzata è parte integrante di un applicativo fornito in modalità Saas e posizionato – by design – su un’architettura cloud a VPS; lo schema di assessment complessivo lo ha etichettato a “rischio elevato” per quanto concerne aspetti di load balancing delle risorse e relativa disponibilità delle informazioni. In particolare, essa è dedicata a un accesso condiviso a un insieme di risorse persistenti collocate su uno schema relazionale a RDBMS fornito da service provider di terze parti.
Si evidenziano i seguenti 3 facts, scaturiti a seguito dall’analisi preliminare di contesto:
a) il modulo applicativo destinato alla gestione della persistenza è inserito all’interno di una logica complessiva multithreading, per cui esso debba servire una moltitudine di request/response parallele provenienti dall’esterno (servitizzazione via application server). Gli aspetti correlati all’isolamento informativo e alla sicurezza dedicata a ogni istanza sono fondamentali e derivano da una corretta implementazione (e test) del parallelismo applicativo secondo casi d’uso e di carico previsti già in fase di progettazione;
b) la struttura di persistenza a RDBMS di cui fruisce è collocata a sua volta su un’infrastruttura cloud-based, esterna alla rete fisica su cui è posizionato il modulo applicativo;
c) sussistono dei limiti prestazionali correlati alla banda massima messa a disposizione dal service provider che fornisce il servizio di RDBMS, per cui il modulo applicativo debba implementare logiche algoritmiche di load balancing che evitino di saturare il valore di banda disponibile con un margine dell’80% di occupazione.
I tre punti evidenziano reali vincoli tecnologici da analizzare, in quanto essi vanno a impattare sostanzialmente sulle scelte architetturali operate dagli analisti per il modulo software stesso, dettate dalla presenza di una infrastruttura cloud-based distribuita – nell’esempio di fattispecie – su due livelli differenti.
Lo stack tecnologico complessivo deve dunque tenere conto della sussistenza di fattori abilitanti alla capacità dei vari componenti funzionali di interagire e garantire risultati solidi dal punto di vista del flusso di dati e informazioni coinvolto. Gli standard di sicurezza raggiunti con la versione in produzione, devono essere mantenuti e, ove possibile, potenziati.
Riferendosi direttamente all’infrastruttura complessiva su cui sussiste il software Saas a cui appartiene il modulo DAO, è evidente che il version number dell’application server (es. Apache Tomcat) sia direttamente correlato al numero di revisione del RDBMS: tale key point – che in semantica Agid-compliant, all’interno di un doc di assessment complessivo, potremmo definire univocamente “ID01_revv” – va inquadrato all’interno di precise logiche prescritte dal percorso di qualificazione, tra cui si citano:
- dipendenza dall’hardware fisico (o virtuale, nel caso di VPS). In che misura la nuova revisione dell’application server implementata va a impattare su aspetti hardware della macchina su cui sussiste, in termini di risorse necessarie (es. occupazione heap)?
- Misure di sicurezza. L’architettura precedente, intesa come application server (soggetto a revisione) e RDBMS, è stata soggetta a un risk assessment relativo a minacce e vulnerabilità mappate in documentazione di dettaglio create ad hoc. Il cambio di revisione conferma la validata di tale analisi precedente o richiede la reingegnerizzazione delle fasi di test?
- Modificabilità del codice sorgente. Qualora la migrazione portasse a ratificare la necessità di intervenire su aspetti funzionali correlati al modulo oggetto dell’esempio (o ad altri correlati), qual è il livello di intervento possibile sul codice sorgente? Un’eventuale modificabilità nulla o parziale potrebbe costituire elemento bloccante alla revisione → Disponibilità di documentazione tecnica: disponibilità della documentazione tecnica che spiega il funzionamento interno dell’applicativo e delle sue componenti per intervenire in modo mirato e controllato.
- Livello di test necessario. Lo scenario ipotizzato considera la presenza di vari moduli funzionali, tra cui quello DAO va a interagire con un RDBMS posizionato in cloud. La modifica dell’environment su cui sussiste l’applicativo, ed è ciò che avviene nel caso di modifica di revisione di un application server, chiama procedure di component e assembly test che devono precedere successive fasi di product test. Poiché di fatto un cambio di revisione di un componente funzionale indispensabile può essere equiparata a una attività di micro-migrazione, in tale scenario è importante eseguire un test di completezza a più livelli, ove vengano identificate varie Unità di Migrazione (Unit of Migration o UoM), con un approccio top-down a partire dallo strato business (gli aspetti di view appaiono qui non coinvolti), funzionali a capire quali porzioni di codice rivelino un comportamento anomalo a seguito della modifica di environment.
È evidente, per concludere, che il percorso di qualificazione AgID dei servizi SaaS rappresenti il volano per lo sviluppo dell’intero comparto, anche grazie alla corretta implementazione tecnologica dei principi “by default” e “by design” previsti dalla nuova normativa a protezione dei dati personali (si veda in proposito il contributo Compliance al GDPR dei servizi cloud SaaS).
Articolo a cura di Igor Serraino
Igor Serraino è professionista IT.
Opera come analista infrastrutturale e di Open Innovation nel contesto di Impresa 4.0 fin dal 2017, in qualità di Technology Expert per una importante società di settore attiva in ambiti aziendali eterogenei e sfidanti.
Il suo portfolio professionale senior-level si consolida attraverso una decennale esperienza da analista e sviluppatore hard-skills in ambienti Java-based, con particolare riferimento alla coprogettazione e sviluppo di applicativi per la gestione finanziaria commercializzati nel mondo della Pubblica Amministrazione.
Ha all’attivo numerose attività di formazione aziendale, workshops e pubblicazioni nei contesti di Cyber Security (GDPR e ISO27001), Legal-Tech, BlockChain Architect.
