Politiche e meccanismi sicuri per l utilizzo di dati sensibili in ambito Cloud

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Protocolli per reti mobili Politiche e meccanismi sicuri per l utilizzo di dati sensibili in ambito Cloud Anno Accademico 2013/14 Candidato: Castellano Pierpaolo matr. N

2 Alla mia famiglia

3 Indice Indice... III Introduzione... 5 Capitolo 1: Cloud Computing Cos è il Cloud? Modelli di servizio Software as a Service Platform as a Service Infrastructure as a Service Modelli di distribuzione Public Cloud Private Cloud Hybrid Cloud Community Cloud Il Cloud come tecnologia per l e-health Capitolo 2: Il Cloud per l e-health: rischi e benefici Benefici del Cloud in ambito e-health Problematiche di sicurezza Memorizzazione ed elaborazione dati Gestione dell infrastruttura dell e-health Usabilità ed esperienza dell utente Innovazioni nell applicazione del paradigma cloud all e-health Capitolo 3: Architetture e tecnologie per la sicurezza proposte in ambito e-health Cloud Concetto di domini privati in ambito e-health Trusted Virtual Domain (TVD) Realizzazione di Piattaforma Client sicura con TVD... 20

4 3.1.3 Protezione di storage esterni Modelli di sicurezza Separation Model Availability Model Migration Model Tunnel Model Cryptography Model Integrazione tra modelli Compatibilità tra servizi Cloud Modelli di sicurezza multi-livello Descrizione dell applicazione Modello di Bell-LaPadula Valide distribuzioni di applicazioni inter-cloud Trasferimento dati inter-cloud Utilizzo del modello di costo Capitolo 4: Una piattaforma Cloud per servizi e-health Progetto DACAR Design di SPOC (Single Point of Contact) Architettura interna Fase di autenticazione Fase di autorizzazione Scenari applicativi Autenticazione e autorizzazione SPOC di un utente interno per usufruire di servizi e- Health Autenticazione e autorizzazione SPOC di un utente esterno per usufruire di servizi e- Health Autorizzazione SPOC ad un servizio applicativo per accedere a dati medici Conclusioni Bibliografia... 46

5 Introduzione Progettare di usufruire delle più recenti tecnologie nel settore sanitario è un importante opzione utilizzata da molte organizzazioni affinché servizi di assistenza e costi operativi siano rispettivamente migliorati e ridotti. Inoltre i nuovi progressi tecnologici e della ricerca hanno facilitato la presenza di nuove diagnosi e di sempre più efficaci metodi di trattamento. La gestione di tali operazioni è diventata più complessa e molto costosa; inoltre vi è una forte concorrenza tra i settori sanitari, per cui ogni azienda fornisce un diverso tipo di servizio per soddisfare le richieste dei pazienti [1]. Si mira a voler trovare una soluzione tecnologica in modo tale da garantire una convergenza nei servizi, affinché diverse organizzazioni sanitarie possano collaborare utilizzando dati condivisi al fine di garantire una certa qualità di servizio. A causa dei costi in ascesa dei servizi sanitari, le organizzazioni tengono in considerazione l'adozione della tecnologia di informazione sanitaria (Health Information Technology, HIT). Questa consente alle organizzazioni sanitarie di semplificare molti dei loro processi informativi, per fornire servizi in modo più efficiente e conveniente, utilizzando sistemi interconnessi e fornendo soluzioni complete e integrate. A causa delle limitazioni proposte dai sistemi HIT, le ultime tendenze tecnologiche come il Cloud Computing introducono molte opportunità per l erogazione dei servizi di assistenza sanitaria oltre ad una qualità di servizio maggiore. In questa tesi si vuole offrire una panoramica sull "e-health Cloud" (Electronic Health Cloud), un termine usato per indicare soluzioni integrate in ambito HIT disponibili in rete Internet su un modello pay per use [1], mettendo in evidenza molti dei suoi componenti e proponendo la costruzione di un ambiente sicuro di e-health Cloud. Si presenterà poi una descrizione ad alto livello delle principali sfide per un e-health Cloud che potrebbero impedire la sua diffusione. È ovvio che l'utilizzo del Cloud in ambito di assistenza sanitaria elettronica erediterà alcune delle problematiche generali della tecnologia Cloud Computing, in aggiunta a quelle relative all applicazione di servizi sanitari specifici. Una delle sfide più ardue per l utilizzo del cloud per sistemi HIT è garantire la sicurezza e la privacy. Infatti, secondo la Commissione europea: "In tutti i paesi, la fiducia nei sistemi di sanità elettronica sia da parte dei cittadini e dei professionisti è stato identificato come la sfida fondamentale. La privacy è riconosciuta come l'aspetto più sensibile dei sistemi di e-health". Nei prossimi capitoli si vogliono introdurre i limiti e i rischi dei sistemi di e-health attuali, il concetto di Cloud Computing, definendo i suoi modelli di servizio e di distribuzione, i vantaggi nell utilizzo del Cloud Computing e le sue potenzialità, ma anche le sue limitazioni. Inoltre si vogliono evidenziare ed analizzare una serie di soluzioni in ambito e-health Cloud per garantire un buon livello della privacy stessa. 5

6 Capitolo 1: Cloud Computing L evoluzione tecnologica in ambito informatico viene quotidianamente messa a disposizione degli utenti per garantire il soddisfacimento delle sempre più crescenti richieste di informatizzazione e comunicazione, utilizzando soluzioni sempre più complesse ed integrate con la rete Internet. L espressione cloud computing fa riferimento alla sempre maggiore necessità da parte degli utenti di uno spazio di memoria proprio, ma anche condivisibile, attraverso l uso della rete Internet. Non esiste una ben precisa definizione di cloud, ma si può far riferimento all immagine con cui viene rappresentato: una nuvola. 1.1 Cos è il Cloud? Con l espressione Cloud Computing ci si riferisce ad un insieme di soluzioni che mirano a memorizzare, archiviare ed elaborare dati attraverso l uso di risorse hardware e software distribuite e virtualizzate in rete. Proprio questa è la novità fondamentale introdotta: tali risorse sono facilmente accessibili via rete e caratterizzate da una particolare agilità di fruizione. Ciò permette di fornire gradualmente aggiornamenti tecnologici adatti e distribuire nuovi servizi. Attraverso l uso del Cloud Computing si ridefinisce la modalità di gestione di sistemi informatici, agevolando la conduzione di sistemi informativi da parte delle aziende. Con questa soluzione, vi si affida a terze parti l incarico di gestire l infrastruttura informatica, diminuendo considerevolmente costi legati alla gestione dell hardware, del software e alla manutenzione. Aziende di piccole o medie dimensioni o semplici utenti ora possono richiedere a fornitori di servizi risorse necessarie alle loro attività, come ad esempio semplici spazi di archiviazione, siti web o infrastrutture complete. Il cloud offre quindi la possibilità di godere di risorse di elaborazione on-demand, con pagamento in base all effettivo utilizzo, secondo un modello pay-per-use. Uno dei vantaggi introdotti è, come già detto, la diminuzione dei costi relativi alla gestione dell infrastruttura e dell hardware; inoltre vi si offre un ingente spazio di archiviazione dati, accessibile off-site. In questo paragrafo si identificheranno cinque caratteristiche essenziali del modello Cloud, tre modelli di servizio e tre modelli di distribuzione. [2] 6

7 Il Cloud Computing permette quindi l accesso in modo continuativo e on-demand ad un insieme di risorse di calcolo configurabili e condivise, attraverso il minimo sforzo di gestione. Un agenzia dedicata alla definizione di standard, chiamata National Institute of Standards and Technology (NIST), ha proposto alcune proprietà del cloud computing che sono state universalmente accettate e riconosciute dalle industrie del settore [2]. Il cloud è fondamentalmente composto da cinque caratteristiche essenziali, quali: 1. Self-Service on-demand : un cliente può richiedere risorse di calcolo, come ad esempio storage, potenza computazionale e banda autonomamente senza l intervento dei gestori dell infrastruttura o dei fornitori di servizio. 2. Accessibilità globale : si deve garantire l accesso eterogeneo da diverse piattaforme (cellulari, tablet, laptop) alle risorse disponibili in rete. 3. Raggruppamento delle risorse : le risorse devono essere raggruppate in modo da poter essere disponibili per un insieme di utenti. 4. Elasticità immediata : le risorse possono scalare rapidamente e, in taluni casi, automaticamente. In questo modo si dà la sensazione all utente di avere una disponibilità illimitata. 5. Servizi misurabili: i sistemi Cloud ciclicamente ottimizzano l uso delle risorse attraverso una misura di ogni servizio in termini di consumo di risorse, così da potervi applicare modelli pay per use. Per cui, con la tecnologia cloud computing la distribuzione di sistemi IT e l archiviazione dei dati è cambiata da infrastrutture IT di proprietà dell utente e on-premise ad infrastrutture IT di proprietà di terze parti e off-premises. 1.2 Modelli di servizio I modelli di servizio fanno riferimento alle tipologie di servizi offerti dal Cloud Computing: sono possibili tre diversi modelli di servizio, quali: Software as a Service (SaaS) Platform as a Service (PaaS) Infrastructure as a Service (Iaas) 7

8 1.2.1 Software as a Service In questo senso i servizi offerti dal Cloud sono software, eseguiti sull infrastruttura Cloud, accessibili da diversi dispositivi attraverso un interfaccia client. Il consumatore non ha alcun controllo sull infrastruttura cloud sottostante, tra cui la rete, server, sistemi operativi e operazioni di storage Platform as a Service Con questa definizione, sono fornite dal cloud intere piattaforme create per l utente: vengono utilizzate per sviluppare, testare e distribuire un applicazione, gestire database ecc.. Come prima, l utente non gestisce l infrastruttura cloud sottostante, pur avendo però il controllo delle applicazioni distribuite e sulle loro impostazioni di configurazione. 8

9 1.2.3 Infrastructure as a Service In questo modello non si eroga più, come servizio, un software o una piattaforma, ma viene fornita l intera infrastruttura, quindi una o più macchine, fisiche e virtuali, in modo che l utente possa erogare autonomamente i propri servizi e le proprie applicazioni. 1.3 Modelli di distribuzione Sono disponibili diversi scenari applicativi in cui può operare un Cloud: i modelli di distribuzione indicano la provenienza dei servizi erogati e quindi in che locazione deve essere offerto un modello di Cloud Computing. Sono possibili quattro modelli di distribuzione: Public Cloud Private Cloud Hybrid Cloud Community Cloud Public Cloud Con questa definizione si indica la situazione in cui l intera infrastruttura Cloud è resa disponibile per un utilizzo pubblico. L intera infrastruttura, le applicazioni e la piattaforma sono di proprietà dei fornitori di servizio, che offrono questi servizi di cloud computing a diversi clienti. Questo porta il beneficio di una distribuzione molto più rapida e con maggiore scalabilità; tuttavia comporta un grave problema di sicurezza, in quanto l utente affida i propri dati a terze parti. 9

10 1.3.2 Private Cloud In questo caso l intera infrastruttura Cloud è fornita da un unica organizzazione o da un provider esterno. Essa può essere di proprietà o di gestione dell organizzazione, o da una terza parte; può essere erogato all azienda stessa (on-premise) oppure alle sue unità (off-premise). Il vantaggio che questa soluzione comporta consiste nella sicurezza: solo gli utenti appartenenti all organizzazione possono accedere al cloud privato Hybrid Cloud Il modello di cloud ibrido consiste nella composizione di due o più cloud distinti. Con questa soluzione si usufruisce dei vantaggi di entrambi i modelli precedenti: si utilizza la modalità privata per alcuni aspetti, ad esempio la conservazione dei dati, e quella pubblica per altri, come interfacce di accesso. In questo modo un azienda può eseguire un applicazione inizialmente su un cloud privato, per poi appoggiarsi su un cloud pubblico durante periodi di elevato utilizzo Community Cloud In questo modello i servizi offerti dal cloud computing sono ad uso esclusivo di una comunità di consumatori di servizio: nella maggior parte dei casi questi appartengono ad organizzazioni aventi norme legali, livelli di sicurezza ed obiettivi comuni. L infrastruttura, le applicazioni e la piattaforma sono gestite da un azienda del gruppo o da un provider esterno. 10

11 1.4 Il Cloud come tecnologia per l e-health Si intuisce che l utilizzo del Cloud Computing comporta una serie di vantaggi: infatti, attraverso la virtualizzazione delle risorse, il cloud offre diverse soluzioni IT come servizi on-demand per le diverse esigenze organizzative. Inoltre in questo modo le organizzazioni non hanno bisogno di mantenere infrastrutture hardware e software, permettendo così ai consumatori di aumentare le capacità di sistema senza dover investire in nuovi componenti dell infrastruttura. In questa tesi, si immagina un particolare use case in cui viene applicata la tecnologia Cloud Computing: si definisce e-health cloud quel particolare utilizzo della tecnologia cloud computing mirato a migliorare l assistenza sanitaria elettronica. Prima di andare a definire vantaggi e svantaggi di questa soluzione, andremo a giustificare perché si è adottata questa scelta [1]. Infatti, gli attuali sistemi di e-health avevano dei grossi limiti, tra i quali: Scambio dati limitato: soluzioni per l assistenza sanitaria elettronica sono utilizzate perlopiù in sistemi clinici di piccole o medie dimensioni, all interno di organizzazioni di dimensione maggiore. A causa di ciò, i dati del paziente sono in uno stato disperso all interno di sistemi separati, per cui è impegnativo riunire le informazioni e condividerle all interno dell organizzazione o attraverso diversi fornitori di servizi sanitari. Elevato costo di implementazione e manutenzione: organizzazioni sanitarie, specialmente se di piccole o medie dimensioni, sono enormemente influenzate da investimenti in hardware, software ed infrastrutture. Migrando a soluzioni cloud-based sono disponibili tecniche innovative per risolvere alcuni dei problemi posti e fornire soluzioni più efficienti e meno costose. Nel prossimo capitolo si mostreranno le novità ed i benefici introdotti dal cloud in ambito e-health, ma anche le problematiche che esso introduce. 11

12 Capitolo 2: Il Cloud per l e-health: rischi e benefici L applicazione dell Information Technology nell ambito dell assistenza sanitaria ha portato importanti novità in molti paesi. Vi sono continui sforzi di ricerca al fine di garantire interoperabilità tra servizi e diminuire i costi: ad esempio, in ambito di sistemi e-health si parla di record sanitari (EHR, Electronic Health Record), documenti elettronici su cui sono conservate tutte le informazioni sul paziente. Attraverso l e-health cloud si punta a supportare la cooperazione tra diversi settori sanitari attraverso l utilizzo di applicazioni interconnesse e integrando le loro capacità, creando reti di coordinamento: in questo modo si avrà uno scambio più efficiente di informazioni. Inoltre si tenterà di minimizzare i costi di servizio. In questo capitolo si andranno prima a mostrare due modelli di cloud in ambito e-health; in seguito si evidenzieranno i benefici dell uso della tecnologia cloud in ambito di assistenza sanitaria elettronica, ma anche i limiti e le problematiche che esso comporta. Il capitolo si conclude con cenni di contributi innovativi per la costruzione di un ambiente cloud nel settore e-health. In questa prima parte andremo a mostrare un modello di cloud che comprende le varie entità dell infrastruttura telematica per l assistenza sanitaria elettronica, quali: 1. Personal Health Record (PHR): database di dati medici gestiti dal paziente. 2. Electronic Health Record (EHR): database di dati medici gestiti da professionisti del settore. 3. Health care provider: organizzazione che fornisce servizi di assistenza sanitaria. 4. Health professional: persone che forniscono servizi di assistenza sanitaria. In figura è mostrato un semplice modello cloud in un primo caso, in cui i pazienti archiviano i loro dati, denominati PHR (Personal Health Record), su un server web. In questo modello [3], i pazienti hanno la visione e la gestione delle proprie informazioni su siti web online, avendo la possibilità di inserire date e periodi di malattia, appuntamenti con i medici, e qualsiasi altra 12

13 informazione relativa al proprio stato di salute. La novità introdotta dal cloud è che i PHR sono memorizzati proprio su un server nel cloud stesso. In questo modello è il fornitore del server PHR responsabile della protezione dei dati. Questo problema della sicurezza e della privacy dei dati nel cloud, è un problema che si tratterà ampiamente nei prossimi capitoli. Solitamente si affida al paziente la possibilità di poter assegnare diritti di accesso ai dati: il vantaggio di questa soluzione è che i PHR sono accessibili solo da determinati utenti. Tuttavia, questo modello dal punto di vista tecnico presenta un grande svantaggio per quanto riguarda la privacy dei pazienti: può essere possibile, in generale, per il server provider accedere ai dati memorizzati nei PHR. In contrasto con i PHR, gestiti dai pazienti, le cartelle elettroniche sanitarie, o meglio EHR, sono gestite solo da professionisti sanitari (health professionals). Per cui infrastrutture che coinvolgono EHR sono in genere più complesse del modello cloud mostrato precedentemente. In figura 1 è mostrato il modello avanzato, che coinvolge più parti, comprendendo anche alcune tecniche per il garantimento della privacy degli EHR. Questi ultimi sono mantenuti e gestiti da fornitori di assistenza sanitaria e, attraverso il server EHR nel cloud, condivisi con altri health professionals. Figura 1. Modello di cloud e-health avanzato. Tuttavia il cloud non è solo utilizzato per operazioni di memorizzazione ed elaborazione di EHR, ma anche per la fornitura di servizi aggiuntivi, quali fatturazione e contabilità con le assicurazioni sanitarie dei pazienti. Tenendo in considerazione questi servizi aggiuntivi, un aspetto importante da considerare è la privacy, poiché alle assicurazioni sanitarie o ai servizi di contabilità non deve poter essere concesso di accedere agli EHR. Ad esempio, in alcuni paesi, tra cui la Germania, si utilizzano smartcards per autorizzare health professionals e pazienti, fornire autenticità, crittografare dati prima che essi vengano memorizzati sulla nuvola, e autorizzare l accesso ai dati EHR. Tuttavia non si pensa a come i dati possono essere gestiti dalle piattaforme client. Nei prossimi paragrafi si illustreranno benefici e rischi dell utilizzo del cloud in ambito sanitario. 13

14 2.1 Benefici del Cloud in ambito e-health Si punta a migliorare l assistenza elettronica condividendo tutte le informazioni clinico-sanitarie su un documento elettronico (EHR-Electronic Health Record), da cui si possono trarre informazioni sul paziente. È possibile gestire dati sanitari senza la necessità di utilizzare complesse infrastrutture tecnologiche: l accesso alle informazioni da parte di tutte le parti coinvolte, dagli operatori sanitari al paziente stesso, avviene attraverso la rete Internet. Raccogliere i dati dei pazienti in un sistema cloud comporta numerosi vantaggi, alcuni dei quali sono [1]: Miglior cura del paziente: il cloud offre un unica cartella elettronica, contenente tutti i dati del paziente, condivisa da più organizzazioni sanitarie. Queste cartelle saranno accessibili da diverse parti, permettendo agli operatori sanitari di avere uno storico della situazione clinica del paziente, al fine di fornire loro i trattamenti più adeguati. Costi ridotti: è possibile pagare solo per l utilizzo attuale delle risorse, secondo un modello pay-per-use. Questa funzione è molto adatta per fornitori di assistenza sanitaria di piccole e medie dimensioni, in quanto possono utilizzare infrastrutture e servizi di information technology avanzati per sostenere le loro attività di assistenza sanitaria con un costo moderato. Inoltre non vi saranno costi relativi allo scambio e alla condivisione di dati. Facilitare studi clinici: il proprietario del cloud può collaborare con le diverse aziende sanitarie per la sperimentazione di nuovi farmaci. Risolvere il problema della scarsità di risorse: attraverso il cloud si superano i problemi di scarsità di risorse, in termini di infrastrutture IT e operatori sanitari. Infatti, la nuvola permette agli operatori sanitari di utilizzare i servizi sanitari a distanza. 2.2 Problematiche di sicurezza Come per ogni settore emergente della tecnologia informatica, il cloud computing dovrebbe essere affrontato con attenzione tenendo conto della sensibilità dei dati. Si deve assicurare che l ambiente informativo sia il più sicuro possibile, in conformità con tutte le politiche organizzative e che possa garantire un adeguato livello di privacy. Gli obiettivi di sicurezza di un organizzazione sono un fattore chiave per le decisioni di outsourcing (esternalizzazione) di servizi IT e, in particolare, per decisioni sulla transizione dei dati, di applicazioni, e di altre risorse ad un ambiente di cloud computing pubblico. Per cui si devono considerare la sicurezza e privacy dei dati durante tutto il ciclo di vita dei sistema, al fine di massimizzare l efficacia e ridurre i costi del cloud. Tenendo conto dello scenario d applicazione in cui si presenta l utilizzo del cloud, la centralizzazione di dati sanitari su di esso può comportare una serie di rischi, alcuni dei quali sono: Rischio di perdita dei dati: è questo un problema significante, che in parte è stato già tenuto in considerazione da alcuni sistemi di gestione di database quali Oracle, Cache e SQL, che hanno creato i concetti di backup a caldo e a freddo, fornendo soluzioni efficienti per minimizzare questo rischio. Indisponibilità del sistema: si deve garantire continuità di servizio, per evitare gravi danni, specialmente in situazioni d emergenza. 14

15 In generale, l elaborazione di dati sanitari dei pazienti comporta diversi problemi tecnici, che possono essere raggruppati in tre aree distinte: 1. Memorizzazione ed elaborazione dati 2. Gestione dell Infrastruttura dell e-health 3. Usabilità ed esperienza dell utente Memorizzazione ed elaborazione dati Bisogna garantire un certo livello di sicurezza e privacy durante le operazioni di memorizzazione ed elaborazione di dati medici su server PHR o EHR; per questo problema, si utilizzano meccanismi di controllo d accesso e cifratura dei dati. Inoltre, un altro problema da sottolineare è garantire che le piattaforme fornite agli utenti siano sicure, in modo tale che le elaborazioni eseguite sui dati non portino danni temporanei o permanenti. Ad esempio, i medici non hanno solitamente le competenze per gestire in modo professionale i propri sistemi, in modo tale da proteggerli contro eventuali minacce. I sistemi attuali non offrono meccanismi di sicurezza adeguati, come ad esempio complessi meccanismi di autorizzazione, autenticazione o interfacce protette: a causa di questi motivi sono maggiormente vulnerabili ad attacchi Gestione dell infrastruttura dell e-health L intera infrastruttura di un e-health cloud è sottoposta a rischi significativi circa la protezione dei dati medici: il semplice uso di smartcards e meccanismi di controllo di accesso non forniscono una sufficiente protezione. Per ovviare a questi problemi, si deve utilizzare un infrastruttura più complessa, che però aggiunge ulteriori problemi di sicurezza e privacy. Ad esempio, l utilizzo della crittografia richiede la gestione delle chiavi crittografiche: vi si chiede chi debba avere il controllo di queste. Ma come si possono gestire, ad esempio, smartcards o chiavi di crittografia perse? Nel caso in cui fornitori di card o di server EHR possiedano copie di backup delle chiavi, sono in grado di decifrare i dati ed accedere direttamente ai dati EHR. Inoltre, ci si deve accertare che le componenti hardware e software utilizzate dal server EHR, come lettori di smartcard, siano sicuri e testati correttamente. Inoltre dev essere possibile rilevare modifiche non autorizzate e dannose ai componenti, al fine di escluderli dall infrastruttura e-health Usabilità ed esperienza dell utente Infine, si va a valutare l utilizzo della piattaforma da parte di professionisti sanitari e pazienti. Ad esempio, l utilizzo di un PIN per la smartcard potrebbe essere deficitario per i pazienti più anziani. Ciò renderebbe l utilizzo del PIN totalmente inutile. Dopo aver elencato alcuni dei preziosi benefici offerti dalla tecnologia cloud in ambito di assistenza sanitaria, si sono mostrati i numerosi svantaggi e rischi di quest utilizzo. In particolare, alcune delle sfide affrontate dall e-health cloud sono le seguenti: Disponibilità: è necessario per gli operatori sanitari che i dati medici ed i servizi siano disponibili in modo continuo, senza alcun degrado delle loro prestazioni, e dovrebbero essere robusti rispetto ad eventuali interruzioni. 15

16 Gestione dei dati: la nuvola memorizzerà un ingente quantità di record medici, sui quali si deve garantire un accesso sicuro, efficiente, affidabile e scalabile, attraverso sofisticati meccanismi. Scalabilità: è importante, per garantire servizi cloud di successo, l opportunità di scalare, ossia di crescere, pur mantenendo prestazioni accettabili. Quest operazione è effettuata prevalentemente aumentando le capacità di risorse IT, ad esempio connessioni di rete, nodi di calcolo ed unità di storage; la scalabilità necessita inoltre che le risorse hardware utilizzate (che sono virtualizzate) siano ridimensionate automaticamente. Interoperabilità: dev essere possibile che diversi servizi per l e-health cloud possano cooperare per un fine comune, in questo scenario garantire un elevata qualità di servizio a pazienti che necessitano di cure mediche. Si deve fare in modo che server di diversi servizi cloud possano integrarsi tra loro. Sicurezza: poiché i dati sono memorizzati sui cloud, è molto importante che i servizi cloud adottino meccanismi di controllo di accesso e di autenticazione sufficientemente sicuri, oltre a meccanismi per garantire il trasferimento sicuro di dati. Oltre a questo requisito, è necessario fare in modo che il fornitore di servizio stesso non possa accedere né utilizzare i dati. Privacy: si deve garantire un adeguato livello di protezione dei dati, affinché non sia possibile che, ad esempio, fornitori di assistenza sanitaria possano accedervi. Per cui si mira a fornire soluzioni adeguate per garantire livelli di privacy accettabili prima di migrare alla tecnologia cloud. 2.3 Innovazioni nell applicazione del paradigma cloud all e-health Mentre problemi di sicurezza stanno impedendo alcune organizzazioni di adottare la tecnologia cloud, altre stanno considerano l uso di una combinazione del cloud ibrida : verrà utilizzato un cloud privato sicuro, accanto ad uno pubblico meno sicuro. In tal modo, applicazioni sensibili possono essere poi distribuite su un cloud privato, mentre quelle che non richiedono sicurezza possono essere distribuite esternamente, su un cloud pubblico. Tuttavia, anche questa tecnica comporta un problema specifico, quella del partizionamento di applicazioni inter-cloud: una soluzione a questo problema verrà proposta nel prossimo capitolo. A seguito delle problematiche introdotte nel paragrafo precedente, sono state suggerite diverse iniziative per contribuire alla costruzione di un ambiente di e-health cloud. Di seguito si presentano alcune innovazioni suggerite a tal fine: Soluzioni di storage cloud-based: sono stati proposti differenti metodi per la progettazione di sistemi di storage per l e-health cloud. Poiché i tradizionali sistemi di gestione ospedaliera (HMS, Hospital Management System) erano caratterizzati da alcune limitazioni (soprattutto in termini di storage e performance), un primo lavoro è stato proposto da Guo [4], che punta ad un Cloud-based intelligent hospital file management system (HFMS). Questa soluzione prevedeva la presenza di un Master Server e più blocchi di server. File di grandi dimensioni sono divisi in blocchi di dimensione fissata, ognuno dei quali è sostenuto da altri tre. Il Master Server gestisce il file system dei metadati, che include namespace, controllo d accesso e la mappatura file-blocco; il vantaggio di questa soluzione è l utilizzo di un insieme di server a basso costo. In aggiunta, Rolim [5] ha proposto una soluzione per 16

17 automatizzare l elaborazione dei dati critici del paziente: viene utilizzata una rete di sensori connessi ai dispositivi medici in modo da collezionare dati e svilupparli poi nel cloud e- Health per la loro memorizzazione, elaborazione e distribuzione. Soluzioni di piattaforma: sono state proposte piattaforme cloud in grado di fornire una serie di servizi necessari per sviluppare e gestire diverse applicazioni di ambito sanitario sul cloud. Ad esempio, si è proposto il progetto Data Capture and Auto Identification Reference (DACAR), che ha come obiettivo quello di sviluppare, implementare e diffondere una nuova piattaforma sicura sul cloud per gestire ed archiviare dati nell ambito dell assistenza sanitaria. La descrizione di questa soluzione verrà trattata nei prossimi capitoli. Generalmente, piattaforme cloud possono essere più aperte all integrazione con altre applicazioni, mentre quelle specifiche per l ambito sanitario possono fornire ambienti personalizzati per l implementazione, integrazione ed il funzionamento di applicazioni e- Health. Modelli implementativi: si utilizza una rete virtuale privata (VPN, Virtual Private Network) accompagnata della rete pubblica come Internet per stabilire un cloud privato grazie al quale diversi ospedali possono condividere informazioni; un altro approccio di modellazione mira a gestire requisiti di diversi servizi basati su architetture service-oriented (SOA, Service Oriented Architecture). 17

18 Capitolo 3: Architetture e tecnologie per la sicurezza proposte in ambito e-health Cloud I problemi introdotti nel capitolo precedente mostrano che l applicazione del cloud in ambito di assistenza sanitaria propone una molteplicità di rischi, relativi maggiormente alla sicurezza e alla privacy. In questo capitolo vengono proposte diverse tecniche per garantire un infrastruttura e- Health sicura: si parlerà dapprima del concetto dei domini privati e della sua applicazione sulle piattaforme al fine di garantire un adeguato livello di sicurezza; in seguito saranno proposti diversi modelli di sicurezza per ovviare alle sempre più crescenti preoccupazioni degli utenti; infine verrà proposto un metodo per partizionare i flussi di lavoro delle applicazioni su diversi cloud. 3.1 Concetto di domini privati in ambito e-health Nel contesto dell e-health, si è mostrato che è necessario proteggere la privacy dei dati sensibili dei pazienti. Una prima soluzione propone di costruire domini privati per i dati sanitari in modo tale da garantire che diversi sistemi, come ad esempio PC client, possano eseguire le loro applicazioni in ambienti isolati: in questo modo i dati sono tenuti all interno del dominio privato e solo utenti autorizzati possono accedervi. Inoltre, la perdita di dati da un dominio è impedita dall architettura di sicurezza e dall infrastruttura. Pertanto con questa soluzione lo stesso sistema può essere utilizzato per diversi flussi di lavoro, operanti in ambienti strettamente separati tra loro. La seguente figura mostra l applicazione di domini privati al nostro modello cloud e-health. 18

19 Per ogni applicazione è stabilito nel cloud un dominio privato, applicato anche sulle piattaforme client del provider di assistenza sanitaria. Si deve anche fare in modo che la nuova infrastruttura possa essere integrata con i sistemi tradizionali: utilizzando domini privati, è possibile impiegare applicazioni esistenti in esecuzione su un sistema operativo legacy all interno di un dominio. Si propone in seguito uno scenario d applicazione che prevede l utilizzo di domini privati [3]. Un dottore vuole utilizzare un programma di contabilità per esibire le fatture di assicurazioni sanitarie ed uno per memorizzare ed elaborare i dati sensibili del paziente. Inoltre necessita l accesso alla rete e potrà essere capace di inviare e ricevere . È ovvio pensare che i vari flussi di lavoro debbano essere disgiunti tra loro: i dati medici non dovrebbero essere letti dall assicurazione sanitaria, l accesso ad Internet non dovrebbe portare problemi di sicurezza, che potrebbero condizionare i dati medici e l esecuzione del processo di contabilità. Si dovrebbe garantire che solamente il programma che gestisce la contabilità stessa possa connettersi alla rete sanitaria, e che il dottore possa inviare dati medici dalla cartella elettronica (EHR) del paziente utilizzando un normale client . Per soddisfare questi requisiti, possono essere utilizzati tre domini privati, ognuno con differenti caratteristiche. Un primo dominio privato, il dominio e-health, si occupa dell archiviazione ed elaborazione di dati medici, per cui il dottore esegue su questo dominio per accedere ai dati del paziente. Il secondo, il dominio di contabilità, è ristretto al software autorizzato all accesso alla rete contabile. Il terzo dominio contiene programmi come un client o un browser web; è l unico che ha accesso senza limitazioni ad Internet Trusted Virtual Domain (TVD) Lo scenario appena presentato richiede la totale separazione dei dati medici da altri servizi; inoltre si richiede l integrazione delle smartcards nel sistema. Una realizzazione del concetto di domini privati è basata sui Trusted Virtual Domains (TVD). Esso può essere visto come un raggruppamento di macchine virtuali che condividono una politica di sicurezza comune. Queste condividono la stessa infrastruttura fisica ed eseguono sistemi operativi con differenti servizi ed applicazioni. Ogni macchina virtuale esegue in un ambiente d esecuzione isolato, chiamato compartment, controllato da un kernel di sicurezza sottostante, che funge da Virtual Machine Monitor (VMM) [6]. L ambiente di lavoro dell utente è ora eseguito dalla macchina virtuale, ospitata da un kernel di sicurezza in esecuzione sulla piattaforma fisica insieme ad altri componenti architetturali: questi elementi servono a far rispettare la politica di sicurezza comune. Le principali caratteristiche di sicurezza dei TVD sono: Compartments isolati: i compartments di diversi TVD sono limitati tra loro grazie al kernel di sicurezza, permettendo l esecuzione di diversi domini privati sulla stessa piattaforma fisica. Relazioni di fiducia: il TVD definisce una politica che autorizza diverse piattaforme e macchine virtuali a far parte del dominio stesso. Applicazione trasparente della politica: il kernel di sicurezza applica regole indipendentemente dai compartments. Comunicazione sicura: macchine virtuali appartenenti allo stesso TVD sono connesse attraverso una rete virtuale che può estendersi su diverse piattaforme; ogni rete è strettamente isolata da altre di diversi TVD. Per garantire questi servizi, la maggior parte delle operazioni è svolta dal kernel di sicurezza: esso ha il compito primario di garantire lo stretto isolamento tra differenti domini. Quando i dati abbandonano un dominio, ad esempio durante il trasferimento su rete o durante la memorizzazione su disco, vengono cifrati con una chiave crittografica disponibile solo sul corrispondente TVD. In 19

20 questo modo, l utilizzo di domini virtuali certificati impedisce l accidentale divulgazione di informazioni e contrasta eventuali attacchi malware. La principale caratteristica di un infrastruttura TVD è la sua gestione automatica: essa infatti verifica l integrità delle piattaforme client quando entrano a far parte di un TVD, distribuendo chiavi e politiche d accesso. Il kernel di sicurezza viene quindi utilizzato anche sulla piattaforma client per gestire la cifratura dei dati e l applicazione di politiche d accesso: il tutto è trasparente all utente. Finché non vi sono violazioni delle politiche definite, questo metodo si differenzia da un sistema convenzionale solo per la presenza di un indicatore grafico che definisce uno specifico TVD. Per garantire una comunicazione sicura tra diverse piattaforme all interno dello stesso TVD, si utilizza una rete virtuale privata basata su IPSec Realizzazione di Piattaforma Client sicura con TVD Per ogni dominio, la struttura di un TVD prevede principalmente una piattaforma client ed un Master TVD, un server utile per la gestione dell infrastruttura. Sulla piattaforma client esegue un kernel di sicurezza, sul livello superiore dell hardware, fornendo macchine virtuali isolate per applicazioni e sistemi operativi convenzionali. Inoltre è presente un proxy TVD per ogni dominio virtuale, con il compito di gestire il dominio stesso sul client e di configurare il kernel di sicurezza in accordo alle politiche stabilite. È anche presente un interfaccia utente sicura (secure GUI) che permette agli utenti di identificare in modo chiaro il compartment con cui stanno interagendo. In aggiunta, sulla piattaforma client è presente anche un componente hardware certificato, utilizzabile per verificare l integrità del software nel client. Questo componente hardware è chiamato Trusted Platform Module (TPM), attualmente un chip integrato sulla motherboard di un PC. Questo componente fornisce un insieme di funzioni di sicurezza e di crittografia, come ad esempio l utilizzo di crittografia a chiave pubblica e firme digitali. Per domini virtuali certificati sono previste due importanti funzionalità: Avvio autenticato: all avvio del sistema, la piattaforma utilizza funzioni crittografiche per associare determinati valori ai componenti che sono caricati e in esecuzione; questi valori 20

21 vengono conservati in modo sicuro in registri speciali del TPM, chiamati Platform Configuration Registers (PCR) Archiviazione sicura: l utilizzo di chiavi crittografiche da parte del TPM può essere ristretto a determinati valori contenuti nei PCR. In questo modo l utilizzo dei dati è consentibile solo se viene avviato il sistema corretto. Quando un client vuole unirsi ad un TVD, dapprima il Master TVD verifica l integrità del kernel di sicurezza del client, basata sulle caratteristiche di sicurezza del TPM. In questa fase, è eseguito un protocollo di comunicazione tra kernel di sicurezza, componenti hardware certificati e il Master TVD per assicurare che solamente clients allineati alle politiche del TVD possano essere introdotti all interno del dominio. Dopo questa fase, è avviato il proxy TVD sul client, ed il Master TVD distribuisce la politica TVD e le chiavi crittografiche necessarie al proxy, che configura il kernel di sicurezza e controlla che le macchine virtuali possano entrare nel TVD. Prima di questa soluzione, i correnti sistemi per e-health erano spesso soggetti ad attacchi causati dalla mancata identificazione ed autenticazione tra i corrispondenti devices. Utilizzando il metodo dei domini privati e quindi del TVD, si utilizza una mutua autenticazione tra i devices basata sui moduli hardware di sicurezza attaccati ai dispositivi, come ad esempio il TPM. Inoltre, solo piattaforme client e componenti software autenticati con successo possono stabilire un canale di comunicazione sicuro con l infrastruttura e-health centrale, in termini di accesso ai dati del corrispondente dominio privato Protezione di storage esterni L utilizzo di dispositivi esterni di archiviazione nei TVD richiede un attenta progettazione dell architettura di sicurezza globale. Dispositivi mobili di storage sono regolarmente utilizzati per memorizzare copie di documenti, che possono essere elaborati da altri sistemi ed in altre locazioni. In particolare, dispositivi USB sono spesso utilizzati offline, cioè collegati ad una piattaforma non connessa alla rete. Il cloud storage può fornire una soluzione conveniente ed economica per archiviare backup di dati: mentre dispositivi di storage locali o file server forniscono un accesso rapido ai dati e sono disponibili indipendentemente dalla connessione Internet, regolari backup possono essere memorizzati utilizzando servizi cloud esterni, fornendo all utente una percezione di spazio di storage illimitato. Con questa soluzione, si paga solo l aumentare dello spazio di archiviazione; in modo simile, file servers che non sono parte di un TVD possono essere usati come storage esterni all interno di un TVD stesso. Dispositivi e servizi di storage devono essere considerati come passivi, non garantendo alcuna proprietà di sicurezza. In tal modo, l applicazione di politiche di sicurezza è basata interamente sul computer col quale è connesso lo storage. In questo ambito si assume che la politica è correttamente applicata finché l archiviazione è usata all interno dei confini TVD. Tuttavia, questa ipotesi non è usualmente soddisfatta, poiché di solito dispositivi esterni di storage vengono utilizzati al di fuori del proprio dominio, ad esempio connettendosi ad altri computer. Per cui si fa in modo che solo piattaforme appartenenti ad uno stesso TVD possano accedere ai dati memorizzati. Allo stesso modo, altri storage esterni, come storage forniti dal cloud computing, possono essere incorporati all interno di un TVD. Riguardo l architettura dello stesso TVD, il servizio di storage fornisce un contenitore per dati, proprio come un dispositivo di storage mobile. La distribuzione di storage esterni all interno di un TVD richiede diversi raffinamenti al modello, a causa dei seguenti problemi: Identificazione dei contenitori: storage esterni possono essere spostati tra più computer senza alcun controllo da parte dell infrastruttura TVD. Per cui ogni volta che uno storage esterno è connesso ad una piattaforma, il sistema dovrebbe essere capace di distinguere il dispositivo ed il dominio a cui il dispositivo appartiene. 21

22 Gestione dinamica dello storage: essi possono dinamicamente far parte o meno del dominio, a differenza degli hard disk, costruiti all interno del computer. Per cui si richiede l introduzione di un infrastruttura per la gestione dello storage in modo tale da gestire, ad esempio, la creazione e distribuzione di chiavi crittografiche. Per estendere il TVD al fine di gestire lo storage esterno, si aggiunge al kernel di sicurezza del client un gestore di dispositivi di storage che identifica l appropriato TVD per il dispositivo e recupera le chiavi assegnate dal Master TVD. 3.2 Modelli di sicurezza In questa sezione si forniscono cinque differenti modelli di sicurezza, proposti da Zhao, Rong, Jaaturn e Sandnes [7], per affrontare i problemi che affliggono l utilizzo del cloud. Ognuno di essi offre funzioni relative alla sicurezza per rispondere a requisiti e scenari diversi, a seconda delle applicazioni. I modelli si basano sulla separazione dei compiti tra più servizi cloud, fornendo ridondanza ed interazione tra cloud, isolando le diverse parti coinvolte per non generare collisione, e utilizzando operazioni crittografiche. Il tutto è finalizzato a garantire requisiti richiesti da applicazioni che utilizzano dati sensibili, tra cui riservatezza ed integrità dei dati, ma anche ad assicurare disponibilità dei servizi in modo continuativo, e fornire tecniche per la migrazione dei dati inter-cloud. I cinque modelli che progressivamente alleviano le preoccupazioni di sicurezza dell utente sono: 1. Separation Model 2. Availability Model 3. Migration Model 4. Tunnel Model 5. Cryptography Model Nel seguito, si descrivono scenari d utilizzo e dettagli di ogni modello; successivamente si mostrerà come i modelli possono integrarsi tra loro Separation Model Con l utilizzo del cloud computing, gli utenti potranno lasciare le loro applicazioni e dati su un sistema remoto che non è sotto la loro gestione: potrebbe accadere che un generico operatore di sistema possa potenzialmente abusare del proprio potere, modificando dati e rifiutando le richieste di servizio da parte degli utenti. Questa situazione potrebbe ridurre la fiducia posta dagli utenti nell uso della tecnologia cloud, in quando non si raggiungerebbe un livello di sicurezza e di fiducia adeguato per applicazioni critiche. Per implementare il modello di separazione dei compiti è necessaria la presenza di almeno due entità per ogni singola transazione: ogni entità è responsabile solo di una parte della transazione. Il principio base è quello di dividere i compiti tra entità in modo tale che nessuna di esse abbia un controllo eccessivo sui processi critici. In figura è mostrato un 22

23 possibile design del concetto di separazione di compiti nel cloud computing nel semplice caso in cui i dati necessitano di essere elaborati e memorizzati. L idea principale è quella di avere due servizi indipendenti responsabili dei due compiti; i dati sono presentati all utente ed elaborati dal Data Processing Service. Quando c è bisogno di archiviarli, essi sono consegnati al Cloud Storage Service dal Data Processing Service, rendendoli persistenti e pronti per un futuro recupero. Per implementare il Separation Model è necessario che siano coinvolti almeno due fornitori di servizi indipendenti; ogni servizio dovrebbe essere responsabile di uno solo dei processi critici coinvolti in una transazione Availability Model È sottinteso garantire ad utenti che utilizzano la tecnologia cloud computing disponibilità del servizio: nel caso in cui un provider vada fuori servizio inaspettatamente, questo potrebbe compromettere l uso dei servizi agli utenti; in figura è mostrato un modello di disponibilità. Come il modello precedente, un utente può elaborare i propri dati attraverso un servizio di elaborazione dati (Data Processing Service) e questi verranno mantenuti su un servizio di archiviazione (Cloud Storage Service). Per garantire la disponibilità del servizio, vi sono almeno due servizi di elaborazione dati indipendenti, Data Processing Service A e Data Processing Service B, rispettivamente, e due servizi di archiviazione dati indipendenti, Cloud Storage Service C e Cloud Storage Service D. Ciascuno dei servizi di elaborazione può aver accesso ai dati su ognuno dei servizi di archiviazione. 23

24 Quindi, per implementare l Availability Model, devono essere soddisfatti i seguenti requisiti: Esistenza di almeno due fornitori cloud computing indipendenti che forniscano Data Processing Services equivalenti, e due fornitori indipendenti che offrano Cloud Storage Services equivalenti. La replicazione di dati tra i due servizi di storage cloud dovrebbe essere bidirezionale e trasparente agli utenti. Dati di ogni servizio di storage cloud devono essere disponibili per tutti i servizi di elaborazione. L Availability Model impone ridondanza sia sulle elaborazioni dati che sui storage cloud. Grazie a ciò, non esiste alcun punto di fallimento per quanto riguarda l accesso ai dati: nel caso di terminazione improvvisa di un servizio di elaborazione o di archiviazione cloud, vi è sempre un servizio di backup presente per garantire la disponibilità e continuità di servizio Migration Model Nel caso in cui i dati siano costretti a rimanere su piattaforme cloud in cui sono mantenuti, gli utenti saranno costretti ad utilizzare questi fornitori cloud fin quando non rinunceranno ai propri dati: la situazione di dipendenza assoluta dai dati è inaccettabile, specialmente se essi sono critici. Pertanto, si potrà adottare la tecnologia cloud computing solo quando è assicurato il trasferimento dati intercloud: è quindi necessario definire un nuovo modello che garantisca questa capacità. Gli utenti elaborano i propri dati utilizzando il Data Processing Service, e questi sono mantenuti sul Cloud Storage Service A. E presente un servizio aggiuntivo, chiamato Cloud Data Migration Service, può interagire con il Cloud Storage Service A e con un altro servizio di storage cloud, chiamato Cloud Storage Service B, al fine di trasportare dati tra i due Storage Services. In questo modo gli utenti possono trasferire dati tra cloud attraverso il Cloud Data Migration Service. Per implementare il Migration Model, è necessario che: Sia presente un secondo Cloud Storage Service che permette di importare/esportare dati. Il Cloud Data Migration Service possa interagire con il servizio di archiviazione cloud che mantiene i dati, al fine di esportarli. I due Cloud Storage Services debbano essere forniti da due fornitori cloud indipendenti. 24

25 3.2.4 Tunnel Model Il Separation Model descritto precedentemente divide la fase di elaborazione da quella di memorizzazione dati al fine di prevenire errori, con l assunzione che i due fornitori di servizi (Processing e Storage Service) non collidano tra loro. Per assicurare quest ipotesi, è necessario che i fornitori di servizio siano isolati, eliminando qualsiasi comunicazione diretta tra loro: in questo modo, nessun fornitore sarà capace di identificare l altro. Il Tunnel Model introduce un tunnel service situato tra il Data Processing Service ed il Cloud Storage Service, che fornisce un interfaccia per i due servizi al fine di farli interagire tra loro, ad esempio per manipolare e recuperare dati. Utilizzando questo modello, il Data Processing Service elabora i dati basati sull interfaccia fornita dal Data Tunneling Service: in questo modo non conoscerà alcun dettaglio del servizio di archiviazione. D altronde, nemmeno il Cloud Storage Service sarà capace di associare i dati che mantiene ad uno specifico servizio di elaborazione. Vi sarà un perfetto isolamento tra i due servizi (elaborazione ed archiviazione), e quindi tra i due providers. In questo modo sarà estremamente difficile per il Data Processing Service collidere con il Cloud Storage Service Cryptography Model Sia il Separation Model che il Tunnel Model isolano il service provider responsabile dell archiviazione dati da quello responsabile della loro elaborazione. Ma in entrambi i modelli non si previene la divulgazione di dati o la loro modifica inautorizzata da parte del Cloud Storage Service: non può essere garantita la riservatezza e l integrità dei dati. Per garantire questi requisiti, fondamentali nell utilizzo di applicazioni critiche, si adotta un supporto crittografico. Il Cryptography Model estende il Tunnel Model con un servizio di crittografia applicato ai dati: in questo modo il Data Processing Service delega al Data Tunneling Service il compito di assicurare integrità e segretezza dei dati. Esso invoca il Cryptography Service per eseguire un operazione crittografica sui dati, prima di consegnarli al Cloud Storage Service. I dati conservati da quest ultimo sono cifrati, per cui vi si può accedere al plaintext solo da chi possiede la chiave di decifratura, oppure utilizzando firme digitali. 25

26 Riguardo l accesso ai dati, il Data Tunneling Service dapprima recupera dal Cloud Storage Service i dati crittografati: se sono cifrati, il Cryptographic Service effettuerà l operazione di decifratura; se sono associate a firme digitali sarà sempre compito del servizio crittografico verificarne la validità. Infine, i dati decifrati saranno mandati al Data Processing Service per l elaborazione. L operazione di crittografia è totalmente trasparente ai servizi di elaborazione ed archiviazione su cloud, per cui l accesso ai dati è negato se non vi si possiede la chiave crittografica Integrazione tra modelli I modelli proposti possono inter-relazionarsi: il Separation Model (SM) è la base per tutti gli altri modelli. Si separa la memorizzazione dati dalla sua elaborazione, richiedendo almeno due fornitori cloud computing indipendenti. L Availability Model (AM) introduce ridondanza al modello di separazione, sia per il servizio di elaborazione che di memorizzazione dati: in questo modo si può tollerare un fallimento nel Data Processing Service e nel Data Storage Service. Il Tunnel Model (TM) estende ulteriormente il modello di separazione utilizzando un servizio tunnel per imporre l isolamento tra il processing e lo storage: in tal modo si eliminano le comunicazioni dirette tra i due servizi. Il Cryptography Model (CM) migliora il Tunnel Model fornendo un supporto crittografico, come meccanismi di cifratura e decifratura dati, e la firma digitale. Questo permette un archiviazione dati sicura e trasparente ai servizi di processing e storage, cifrando i dati prima di memorizzarli e decifrandoli all accesso, prevenendo modifiche inautorizzate associando chiavi o firme digitali ai dati. 26

27 Ogni modello si incentra su diversi aspetti di requisiti di sicurezza, e possono essere combinati tra loro per soddisfare più vincoli. Ad esempio, il Migration Model (MM) può essere combinato con il Cryptographic Model, cosicché il modello combinato possa fornire trasferimento dati inter-cloud, riservatezza, integrità dei dati. Nella seguente tabella si mostrano i requisiti di sicurezza che ogni modello garantisce Compatibilità tra servizi Cloud I modelli di distribuzione dei compiti proposti assumono che i servizi cloud coinvolti sono compatibili tra loro: questo può essere garantito solo definendo interfacce di interazione standardizzate tra servizi. Per cui si andranno a definire: Data Access Interface (DAI): implementato nel Cloud Storage Service ed utilizzato dai Data Processing Services per accedere ai dati memorizzati nel cloud. Data Replication Interface (DRI): implementato nel Cloud Storage Service e usato dal Data Replication Service per sincronizzare i dati tra due Cloud Storage Services. Data Migration Interface (DMI): implementato nel Cloud Storage Service e usato dal Cloud Data Migration Service per trasportare dati tra Cloud Storage Services. Data Tunneling Interface (DTI): implementato nel Data Tunneling Service e usato dal Data Processing Service. Questa sezione introduce modelli di distribuzione dei servizi per risolvere alcuni problemi tipici dell utilizzo della tecnologia cloud: non bisogna però dimenticare che queste soluzioni sono a livello di architettura di distribuzione, per cui non includono protocolli e algoritmi specifici che possano fornire supporto per la riservatezza e integrità a livello crittografico. Per cui si mira a sviluppare design pattern ed interfacce per consentire ad applicazioni cloud-based di essere distribuite secondo i modelli sopra specificati. 27

28 3.3 Modelli di sicurezza multi-livello Il cloud computing è una tecnologia che permette di fornire servizi a basso costo, in modo scalabile, ma presenta il problema della sicurezza: molte organizzazioni stanno quindi valutando la possibilità di utilizzare una combinazione ibrida di cloud, usufruendo di cloud privati sicuri insieme a cloud pubblici. Applicazioni sensibili possono essere distribuite sui primi, mentre quelle senza problemi di sicurezza possono essere implementate esternamente, su cloud pubblici. Tuttavia questa soluzione presenta il problema di come partizionare le applicazioni attraverso i cloud, nel rispetto dei requisiti di sicurezza. Attualmente si utilizza una base ad-hoc, potenzialmente incline ad errori, per la semplicità con cui l intera applicazione è distribuita su un singolo cloud: in tal modo non si usufruisce dei possibili benefici garantiti dall utilizzo di diversi cloud all interno di una singola applicazione. In questa sezione si descrive un alternativa agli approcci ad-hoc: una soluzione che determina tutti i modi in cui le applicazioni strutturate come flussi di lavoro (workflow) possano essere distribuite su un insieme di cloud in modo che siano soddisfatti determinati vincoli di sicurezza. L approccio è basato su un modello di Sicurezza Multi-Livello che estende il metodo di Bell-LaPadula per l utilizzo del cloud computing: si introducono trasformazioni del workflow, operazione necessaria quando si trasferiscono dati tra cloud. In alcuni casi, i requisiti di sicurezza possono essere violati da trasformazioni: si parlerà di come queste possono essere eliminate. Una volta generato un insieme di opzioni valide di partizionamento di workflows inter-cloud, si utilizzerà un modello di costo per classificarle Descrizione dell applicazione Per evidenziare l importanza di questa soluzione, si consideri un applicazione medica in cui sono analizzati dati provenienti dalle frequenze cardiache di un insieme di pazienti. In Figura 1 è mostrato un flusso di lavoro adottato per analizzare dati provenienti da ciascun paziente. Figura 1. Esempio di workflow per l analisi di dati medici. Il flusso di lavoro è alimentato da un file contenente un intestazione che identifica il paziente, ed una serie di misurazioni della frequenza cardiaca ottenute in un periodo di tempo. Un primo servizio (qui chiamato Anonymize) elimina l intestazione, lasciando solo le misurazioni; il secondo (Analyze) quindi analizza le misure, producendo una sintesi. Analizzare le misure della frequenza cardiaca è un operazione computazionalmente costosa, oltre al fatto che molte organizzazioni non preferirebbero archiviare record medici su cloud pubblici per una questione di riservatezza e, in alcuni casi, per motivi legali. Pertanto si può pensare di distribuire l intero workflow su un cloud privato: questa soluzione può sovraccaricare le limitate risorse della nuvola privata, portando ad uno scarso rendimento. Si mira quindi a partizionare un applicazione, vista come un insieme di servizi e dati connessi in un workflow, su diversi cloud per poi determinare, attraverso opportune regole, un insieme valido di distribuzioni delle applicazioni inter-cloud: il tutto garantendo che i requisiti di sicurezza siano soddisfatti. [8] 28

29 3.3.2 Modello di Bell-LaPadula Questa sezione descrive l applicazione del modello di sicurezza di Bell-LaPadula ai flussi di lavoro e come questo può essere esteso alla distribuzione di workflows su diversi clouds. Un flusso di lavoro è modellato come un grafo orientato, in cui i nodi rappresentano servizi e dati. I primi consumano zero o più unità di dato e generano uno o più unità di dato. In un sistema informativo che utilizza questo metodo, è adottato un modello di controllo d accesso multi-livello, in cui i servizi sono modellati come soggetti (S) ed i dati come oggetti (O) [9]. Il modello di sicurezza qui descritto consiste di: Un insieme di azioni (A) che i soggetti (S) possono operare su oggetti (O). Nel caso di servizi che operano su dati in un workflow, le azioni sono limitate a lettura/scrittura: pertanto, l insieme di azioni è A: {r,w}. Un insieme L parzialmente ordinato di livelli di sicurezza. Una matrice di autorizzazioni M: S x O A. Il contenuto della matrice è determinato dalla progettazione del flusso di lavoro: se ad esempio il servizio legge il dato vi sarà un elemento nella matrice del tipo x r. Una matrice d accesso B: S x O A. E determinata dall esecuzione del flusso di lavoro: può essere uguale alla matrice di autorizzazioni e in alcuni casi sarà un suo sottoinsieme, in dipendenza del percorso effettuato quando il workflow viene eseguito. Una clearance map C: SL, che rappresenta il livello di sicurezza massimo a cui ogni servizio può operare. Una location map l: S+O L, che rappresenta il livello di sicurezza di ogni servizio e dato presente nel workflow. In un tipico scenario di sicurezza multi-livello, il sistema si muove attraverso un insieme di stati, ed il modello può avere diversi valori per autorizzazioni, accessi, clearance e location in ogni stato. In generale, il modello di Bell-LaPadula afferma che un sistema è in uno stato sicuro se le seguenti condizioni sono soddisfatte, soggetto u S e oggetto i O: 1. Autorizzazione: (1) 2. Clearance: l(u) c(u) (2) 3. No-read-up: r c(u) l(i) (3) 4. No-write-down: w l(u) l(i) (4) Per flussi di lavoro, queste quattro condizioni portano le seguenti implicazioni: 1. Tutte le azioni svolte da servizi devono essere conformi alle autorizzazioni concesse a tali servizi. 2. Un servizio può operare solo ad un livello di location inferiore o uguale al suo livello di clearance. 3. Un servizio non può leggere dati aventi livello di sicurezza maggiore al proprio livello di clearance. 4. Un servizio non può scrivere dati aventi livello di sicurezza inferiore al proprio livello di location. Ad esempio, si consideri un servizio che consuma il dato e produce il dato : 29

30 In questo caso le regole di no-read-up e no-write-down si traducono nelle seguenti diseguaglianze: c( ) l( ) (5) l( ) l( (6) Le relazioni tra livelli di sicurezza sono mostrati in Figura 2: le frecce rappresentano relazioni di maggioranza. Figura 2. Relazioni tra livelli di sicurezza. Mentre l assegnazione di un livello di sicurezza ad un dato nel flusso di lavoro è analogo ad assegnare un livello ad un oggetto (come un documento), l assegnazione di un livello di sicurezza ad un servizio può essere meno intuitivo, poiché un organizzazione può avere diversi livelli di confidenza in un insieme di servizi che desidera utilizzare. Possono avere molta fiducia in un servizio garantito da un fornitore fidato, per cui vi si assocerà un livello di sicurezza elevato; assegnerà un livello di sicurezza basso, ad esempio, a servizi scaricati da Internet o da provenienza ignota. È comunque consigliabile associare ai servizi un livello di location sufficientemente basso, in modo da non violare la regola di no-write-down (4). In questa parte del capitolo si mira a descrivere come il modello di Bell-LaPadula possa essere esteso per l utilizzo del cloud computing. Abbiamo già notato che sarebbe inefficiente collocare l intera esecuzione su un unico cloud: ma se ve ne sono diversi disponibili, sorge il problema di dove collocare dati e servizi, e quindi come partizionare l esecuzione di un particolare flusso di lavoro. Pertanto, il resto di questa sezione estende il modello di sicurezza introdotto precedentemente, al fine di consentire decisioni sistematiche sulla partizione di un workflow intercloud, sempre garantendo particolari requisiti di sicurezza. Per fare questo, la location map viene estesa ad includere cloud, denotati con P: location map l : S + O + P L Inoltre, viene aggiunto H per definire il mapping tra ciascun servizio/dato ed un cloud: H: S + O P Si è quindi aggiunta una regola che permette l allocazione di un qualsiasi blocco (servizio o dato) su un cloud in funzione di loro livelli di location: in particolare, il livello di location del blocco dev essere minore o uguale a quello del cloud su cui è distribuito. Per un blocco x su un cloud y ciò corrisponde a: l( ) l( ) (7) 30

31 Ritornando all esempio mostrato precedentemente: Se, in H, è sul cloud, su e sul cloud, allora devono essere soddisfatte le seguenti regole: l( ) l( ) (8) l( ) l( ) (9) l( ) l( ) (10) Ciò permette di estendere la regola di no-write-down, definita precedentemente per quest esempio in (6), in: l( ) l( ) l( ) (11) Le relazioni complete tra livelli di sicurezza per blocchi e cloud sono rappresentate in Figura 3. Figura 3. Relazioni tra livelli di sicurezza di cloud e blocchi Valide distribuzioni di applicazioni inter-cloud Utilizzando il modello e le regole appena descritte, è possibile elencare automaticamente tutte le opzioni valide di distribuzione del workflow su diversi cloud. A partire dai seguenti elementi: L insieme dei cloud P L insieme dei servizi S L insieme dei dati O La location map l Si possono definire, utilizzando la regola (7), le mappature valide di servizi e dati sui cloud: V: S + O P V = {b p b S + O, p P, l(b) l(p)} 31

32 Per illustrare questo, usiamo il flusso di lavoro in Figura 1, con due clouds. La sequenza di servizi e dati del workflow è mostrata in figura; ogni servizio ha un dato in ingresso ed uno in uscita: Considerando i valori di location e clearance ai blocchi e ai cloud della Tabella 1 Tabella 1. Valori di location e clearance. Di seguito si riportano le possibili collocazioni valide di ogni blocco sui due cloud. Tabella 2. Valide distribuzioni dei blocchi sui clouds. Per cui l insieme di tutte le possibili distribuzioni valide del flusso di lavoro tra cloud è dato da: W: (S + O P) {(S + O P)} = {w V, b S+O. p P.b p w, w = S+O } Dove V è il power set di V e w è la cardinalità di w. Per cui l insieme di distribuzioni valide può essere effettuato da un algoritmo, in modo automatico. Per l esempio preso in considerazione, è mostrato in Figura 4 la tabella di tutte le possibili distribuzioni valide del workflow in esecuzione (con la notazione si indica il dato j distribuito nel cloud a). 32

33 Figura 4. Valide distribuzioni di workflow inter-cloud Trasferimento dati inter-cloud Si adottano le seguenti assunzioni: 1. Un servizio può generare un dato come output direttamente su un altro cloud, senza che venga prima memorizzato nel suo cloud 2. Un servizio può consumare un dato come input direttamente da un altro cloud, senza che venga prima memorizzato sul suo cloud. Il problema del trasferimento dati inter-cloud può essere risolto in due fasi. In primo luogo, viene introdotto un nuovo tipo di servizio, denominato sxfer, che trasferisce dati tra cloud: questo prende un dato da un cloud e ne crea una copia (ereditando il livello di sicurezza del dato originale) 33

34 su un secondo. Per cui il flusso di lavoro è sottoposto a trasformazioni ogniqualvolta vi è un trasferimento dati inter-cloud. Sono disponibili quattro trasformazioni del grafo: Le trasformazioni (12) e (14) fanno riferimento a nodi distribuiti sullo stesso cloud, mentre le trasformazioni (13) e (15) introducono nodi sxfer per trasferire dati tra clouds. Sfortunatamente, questo spostamento comporta potenziali problemi di sicurezza. Quando ad esempio è applicata la trasformazione (13), vi è il bisogno di controllare che il cloub b abbia un livello di sicurezza sufficiente per memorizzare la copia di. Per assicurarsi che ciò sia vero, bisogna controllare che: l( ) l( (16) e similarmente, per la trasformazione 15 l( ) l( (17) Se una delle due regole qui in alto è violata, il flusso di lavoro non soddisfa i requisiti di sicurezza, per cui dev essere rimosso dall insieme W di mappature valide di dati/servizi su clouds. Gli effetti di tali trasformazioni indesiderate è di modificare il reticolo di sicurezza mostrato in Figura 2 in quello presente in Figura 5. Figura 5. Relazioni tra livelli di sicurezza dopo trasferimenti dati inter-cloud Applicando le trasformazioni presentate alle distribuzioni presenti in Figura 4, seguite dalle regole (16) e (17), vengono rimosse molte possibili opzioni di distribuzione; le rimanenti sono mostrate in Figura 6. 34

35 Figura 6. Le sei distribuzione valide su cloud Questo diagramma è stato generato automaticamente da un tool che implementa i metodi descritti finora. Una volta definite le diverse opzioni valide di distribuzioni del workflow inter-cloud, si utilizza un modello di costo per selezionare l opzione migliore tra quelle disponibili, sulla base alle capacità offerte dai fornitori cloud Utilizzo del modello di costo In questa sezione si illustra un metodo per minimizzare il costo delle distribuzioni, misurato utilizzando metriche a seconda delle capacità fornite dai cloud providers. Per un cloud (p) queste sono rappresentate da: Volume di dati trasferiti all interno del cloud: Volume di dati trasferiti al di fuori del cloud: Volume di dati memorizzati nell unità di tempo necessaria all archiviazione: Unità di tempo della cpu consumate per l esecuzione di un servizio: Parametri di costo che caratterizzano un dato (d) sono invece: Dimensione del dato: size(d) Longevità del dato: la durata di tempo da cui il dato è memorizzato, longevity(d) Infine, un parametro di costo per un servizio (s) è: Unità di tempo della cpu consumate nell esecuzione di un servizio: cpu(s) 35

36 A partire da questi parametri, il costo dell esecuzione di un workflow distribuito su più cloud può essere definito come: Dove k indica il numero di dati presenti nel flusso di lavoro; m il numero dei servizi; q rappresenta il numero di trasferimenti dati inter-cloud. Nel terzo termine dell equazione, ps rappresenta il cloud sorgente e pd il cloud destinazione del trasferimento dati. Le stime presenti nell espressione (specialmente relativi ai costi della cpu) possono essere misurate attraverso analisi prestazionali e statistiche per ogni esecuzione del flusso di lavoro. Ora evidenziamo un esempio dell utilizzo del modello. Consideriamo le valide distribuzioni di servizi/dati su cloud espresse in figura 6. In un primo esempio si considera il caso più semplice, in cui costi e rendimento di entrambi i cloud sono uguali (come mostrato in Tabella 3): la differenza di costo tra le distribuzioni dipende solo dal numero di comunicazioni inter-cloud. Tabella 3. Parametri di costo dei cloud: Esempio 1 Informazioni sui blocchi del flusso di lavoro sono mostrati nella Tabella 4. Tabella 4. Informazioni suoi blocchi del workflow. La dimensione di sarà nota al suo ingresso nel workflow, mentre i parametri relativi ai blocchi e sono solo stimati, attraverso i risultati delle esecuzioni precedenti. Per impostare il valore di longevità, si è assunto che i dati di input ( ed output ( ) sono memorizzati da un anno, mentre i dati intermedi ( vengono immediatamente scartati una volta consumati da un servizio. I risultati del modello di costo, considerando le sei distribuzioni valide mostrate in Figura 6, sono mostrate nella Tabella 5. 36

37 Tabella 5. Costi delle distribuzioni. Esempio 1. Si conferma che l opzione più economica è l opzione 6, in cui tutti i blocchi vengono distribuiti sullo stesso cloud: ciò è causato dall assenza di costi di trasferimento dati inter-cloud. Nel caso in cui, invece, i costi della cpu variano tra cloud, distribuire workflow tra diversi cloud può essere una soluzione utile. Prendiamo ora in considerazione, nel secondo esempio, cloud con diversi parametri di costo. Tabella 6. Parametri di costo dei cloud. Esempio 2 Qui il cloud privato,, fornisce una maggiore sicurezza, ma ha costi di cpu e dati più elevati. L effetto di utilizzare questi (diversi) parametri dei cloud al modello di costo è mostrato in Tabella 7. Tabella 7. Costi delle distribuzioni. Esempio 2 Il risultato mostrato è che l opzione migliore è quella che alloca quanto più lavoro possibile sul cloud pubblico, che ha minori costi di cpu. 37

38 Capitolo 4: Una piattaforma Cloud per servizi e-health L applicazione delle moderne infrastrutture di informazione in ambito medico e la fornitura di servizi di assistenza sanitaria sono notoriamente conosciuti come e-health. Attualmente molti paesi sono pronti ad adottare questo sempre più innovativo paradigma, al fine di migliorare la qualità del servizio e ridurre i costi di erogazione di assistenza sanitaria: infatti la tecnologia Cloud Computing è in grado di ridurre il costo delle spese operative per lo sviluppo e la fornitura delle applicazioni della sanità elettronica. Servizi diversi possono scambiare e condividere dati medici al fine di migliorare la qualità complessiva delle cure offerte ai pazienti. Si propone in seguito la descrizione del progetto DACAR (Data Capture and Auto Identification Reference), il cui obiettivo è quello di sviluppare, realizzare e validare una nuova, sicura, piattaforma di servizio e-health cloud-based che rinforza l integrità, sicurezza, riservatezza e la verificabilità dei dati medici sensibili in tutto il loro ciclo di vita. [10] 4.1 Progetto DACAR Nell Ottobre 2009 fu fondato dal Technology Strategy Board (TSB) il progetto DACAR, che mirava alla creazione di un infrastruttura sicura in the cloud per l archiviazione e gestione di dati sensibili in ambito medico. La soluzione proposta utilizza un cloud privato per l archiviazione dati ed un cloud ibrido per ospitare istanze di servizio [10]. Si è detto che, dal punto di vista della fornitura dei servizi, sistemi cloud possono essere di tre tipi: Infrastructure as a Service (Iaas), Software as a Service (SaaS) e Platform as a Service (PaaS). Il progetto DACAR si concentra sul livello PaaS, puntando a fornire agli sviluppatori una piattaforma che affronta i requisiti più comuni di applicazioni e-health [10]. 38

39 La piattaforma si basa su un componente primario, chiamato Single Point of Contact (SPoC), essenzialmente un autorità di sicurezza, che protegge la privacy dei pazienti nelle applicazioni e- Health attraverso servizi di autenticazione e autorizzazione, oltre a facilitare la comunicazione sicura tra client e servizi e-health. Nel corso della sezione verrà dapprima mostrato il design dello SPoC e la sua architettura interna, poi saranno descritte le fasi di autenticazione e autorizzazione. Infine si mostreranno tre scenari applicativi d utilizzo. 4.2 Design di SPOC (Single Point of Contact) Lo SPoC adotta un approccio basato su richiesta per le fasi di autenticazione e di autorizzazione, attraverso il rilascio di token di sicurezza di diverso tipo, autenticando utenti (interni o esterni al dominio dello SPoC) ed associando determinati attributi all utente. In questo senso, uno SPoC funge da Identity Provider e da Attribute Provider Architettura interna L architettura interna di uno SPoC, rappresentata in figura, è costituita dai seguenti moduli [11]: Domain Ontology: viene fornito allo SPoC un insieme di informazioni necessarie per soddisfare diverse tipologie di richieste, ad esempio di autenticazione e autorizzazione. I concetti più importanti nell ontologia di dominio sono: 1. Dominio: si riferisce ad un area amministrata da una singola organizzazione. Un applicazione e-health può coinvolgere diversi domini (ospedali, farmacie, compagnie assicurative) e tipicamente un dominio è rappresentato da uno SPoC. Diversi SPoC possono comunicare tra loro formando un Circle of Trust (CoT): ogni SPoC mantiene informazioni sui servizi offerti da altri SPoC ed una tabella per tradurre informazioni da altri Domain Ontologies al proprio. 39