UNIVERSITÀ DEGLI STUDI DI SIENA. Sistema web e applicazione mobile per il trattamento di dati sanitari sensibili. Jacopo Vezzosi 10 Dicembre 2012

Transcript

1 UNIVERSITÀ DEGLI STUDI DI SIENA Facoltà di Ingegneria Corso di Laurea Magistrale in INGEGNERIA INFORMATICA Sistema web e applicazione mobile per il trattamento di dati sanitari sensibili Tesi di laurea di Jacopo Vezzosi 10 Dicembre 2012 Relatore: Prof.ssa Monica Bianchini Controrelatore: Prof. Alessandro Andreadis Correlatori: Prof. Marco Maggini Simone Nosi Anno Accademico 2011/2012

2 SOMMARIO SOMMARIO INTRODUZIONE I vantaggi della telemedicina e dell accesso online ai propri dati Lo scopo del progetto ANALISI DEI REQUISITI Il trattamento dei dati sanitari e la legislazione in merito Definizione dei requisiti Attori e casi d uso PROGETTAZIONE DEL SISTEMA Il server web Il database e la struttura dei dati L applicazione web (Healthcare Web) L applicazione mobile (Healthcare Mobile) Struttura dell app I dispositivi di misurazione TECNOLOGIE ADOTTATE Le applicazioni mobili e il sistema operativo Android Il server web Oracle Glassfish Le servlet Il database MySQL SICUREZZA Vulnerabilità del sistema e soluzioni Sicurezza dei dati nel dispositivo mobile Hacking del client Il problema del man-in-the-middle e l HTTPS Attacchi di tipo injection al server web... 52

3 Protezione dei dati sul database e hashing delle password FASI DI PROGETTAZIONE Fasi di sviluppo Strumenti di sviluppo CONCLUSIONI APPENDICE A Articoli rilevanti estratti dal Decreto Legislativo del 30 giugno 2003, n 196 (Codice in materia di protezione dei dati personali) APPENDICE B Allegato al Codice in materia di protezione dei dati personali (Disciplinare Tecnico in materia di misure minime di sicurezza) BIBLIOGRAFIA E SITOGRAFIA... 73

4 1. INTRODUZIONE Il recente sviluppo dei sistemi informatici ha permesso l invio rapido di dati attraverso Internet: inizialmente la comunicazione avveniva principalmente mediante computer fissi o portatili connessi alla rete tramite cavo Ethernet e, in seguito, tramite rete Wireless. Nell ultimo decennio, con la nascita dei telefoni mobili dotati della capacità di connettersi ad Internet tramite la rete telefonica, la comunicazione si è evoluta, rendendo possibile la trasmissione dei dati praticamente da qualsiasi luogo e in qualsivoglia situazione. L attuale tecnologia di telecomunicazione di terza generazione, meglio nota come 3G, permette di trasmettere dati ad alta velocità (le specifiche per questo tipo di tecnologia impongono una velocità di trasmissione dati di almeno 0.2Mbit/sec) e i cosiddetti cellulari intelligenti (gli smartphone) sempre più diffusi, permettono di eseguire vere e proprie applicazioni (le app). Il costo relativamente ridotto di questi dispositivi mobili ne ha poi comportato una diffusione capillare, tanto che ad oggi ormai quasi tutti nel mondo dispongono di un proprio smartphone o di un tablet. Risulta quindi evidente come queste tecnologie trovino numerosissime applicazioni nei campi più disparati quali, ad esempio, l home banking, il social networking, la domotica e la telemedicina. Ciò è stato ampiamente dimostrato dall enorme sviluppo di app, che permettono di svolgere numerosi compiti in maniera distribuita; molte di esse fungono infatti da thin client, fornendo alcune funzionalità di base in locale ed appoggiandosi a server remoti per le elaborazioni computazionalmente più pesanti e per la memorizzazione sicura dei dati (la cosiddetta nuvola informatica o cloud computing) tanto che ormai la connessione alla rete Internet è diventata quasi obbligatoria per poter utilizzare tali app nei propri smartphone I vantaggi della telemedicina e dell accesso online ai propri dati Uno dei campi di particolare interesse e che presenta numerose applicazioni possibili è quello della telemedicina. Quando una persona necessita di assistenza, perché ad esempio malata od anziana, è necessario che si rechi dal proprio medico personale o presso una struttura medica (una ASL, un ospedale od una clinica privata). Qualora però non sia in grado, ad esempio, di spostarsi, deve ricorrere all assistenza di familiari, Pag. 3

5 di un badante, o di personale addetto, che devono accompagnarlo o comunque recarsi a ritirare delle analisi o a consegnarle al medico curante (per esempio un paziente diabetico dovrà misurarsi regolarmente la glicemia e i risultati di queste misurazioni dovranno essere comunicate regolarmente). In altre situazioni può essere inoltre necessario ricordare al paziente impegni rilevanti per la sua salute, come ad esempio un appuntamento dal medico o l assunzione regolare di particolari farmaci a specifici dosaggi ed inoltre, nel caso in cui una persona, anche senza particolari problemi di salute, viva da sola, di disporre di un sistema che permetta di avvisare i familiari in maniera tempestiva in caso di pericolo (si pensi al noto Salvavita Beghelli). Dal punto di vista degli operatori sanitari, invece, sarebbe conveniente un sistema che permetta di archiviare, in maniera centralizzata, annotazioni riguardanti diagnosi e risultati delle analisi effettuate sui pazienti, in modo da potervi accedere rapidamente anche da strutture sanitarie diverse, specie in caso di necessità (ad esempio per un ricovero d urgenza). Un sistema per la memorizzazione delle analisi, comprese le misurazioni effettuate in maniera autonoma dal paziente direttamente da casa, e accessibile via Internet anche da quest ultimo, permetterebbe a costui di evitare lunghe code per poterle ritirare in forma cartacea, rendendo l intera procedura di monitoraggio delle condizioni fisiche estremamente comoda ed efficiente. Un applicazione del genere dovrebbe riassumere quindi al suo interno diverse funzionalità di assistenza domiciliare a distanza e fungerebbe da ponte tra colui che deve usufruire di assistenza medica e il soggetto incaricato di fornirla. In particolare, risulterebbe molto utile per essere utilizzata da Aziende Sanitarie Locali, da cliniche private e da aziende specializzate nella teleassistenza domiciliare, che potrebbero fornire al paziente un kit che comprenda sia gli strumenti che l applicazione, installabile nello smartphone o nel tablet personale del paziente. Un ulteriore impiego dell applicazione potrebbe infine essere costituito dalla creazione di access point informatici in località piccole o difficilmente raggiungibili, ad esempio comunità montane, attrezzati con un terminale e con la strumentazione necessaria alle analisi, nelle quali un paziente potrebbe recarsi periodicamente ed effettuare le misurazioni di routine senza che sia necessaria la presenza in loco del personale medico. Pag. 4

6 1.2. Lo scopo del progetto Per venire incontro a queste esigenze è stato realizzato un sistema che offre, da una parte, un insieme di strumenti utili al paziente ed al tutor che se ne dovrà prendere cura, costituiti da un app per dispositivi mobili e da un set di misuratori (di pressione, di glicemia, bilance, ecc.) dall altra, un sistema che permetta di interfacciare tra loro pazienti ed operatori sanitari, fornendo un mezzo per la memorizzazione e l accesso rapido ai dati sanitari dei pazienti stessi. Infine, occorrerà predisporre un sistema per l archiviazione sicura dei dati (un server dedicato appartenente alla ASL o all azienda privata). Le caratteristiche principali che il sistema dovrà possedere sono le seguenti: Rendere facilmente accessibili i dati richiesti, da più luoghi possibile ed in maniera veloce; Fornire garanzie agli utenti riguardo la sicurezza e la riservatezza dei dati personali; Essere affidabili, in particolare in situazioni di emergenza; Essere di facile utilizzo anche per persone che abbiano poca esperienza con le nuove tecnologie, ma nel contempo fornire la maggior quantità possibile di funzionalità integrate. Il sistema dovrà quindi prevedere, innanzitutto, un applicazione per dispositivi mobili, utilizzabile ovunque, che possa connettersi ad un sistema centrale per la memorizzazione dei dati, sfruttando la rete wireless o 3G. Tale sistema dovrà poi essere accessibile via browser web, sia dagli operatori sanitari che dai pazienti, per la gestione dei dati stessi, in modo che entrambe le categorie possano intervenire sui dati e visualizzarli. In particolare, ai medici interesserà visualizzare le note e le analisi effettuate sui pazienti per avere una panoramica del loro stato di salute. Viceversa, i pazienti potranno avere a disposizione sempre i dati personali con la possibilità di visualizzarli, rimuoverli se desiderano, di aggiungerli con o senza l ausilio della strumentazione (qualora non ne dispongano). Il sistema dovrà inoltre fornire adeguate garanzie agli utenti circa la sicurezza dei loro dati personali contro appropriazioni e modifiche da terzi non autorizzati e sulla riservatezza del loro trattamento da parte degli operatori sanitari, secondo la Pag. 5

7 normativa vigente sulla privacy, come descritto nel seguito. Questa sicurezza andrà garantita in tutte e tre le fasi del trattamento dei dati: nella fase di memorizzazione su dispositivo mobile, nella fase di trasmissione ed in quella di elaborazione e archiviazione nel server dedicato. Il sistema dovrà risultare affidabile in caso di necessità, effettuando in maniera autonoma tutte le operazioni necessarie all avviso di chi è responsabile nel caso in cui l utente si trovi in difficoltà e non in grado di chiedere aiuto; esso dovrà inoltre essere affidabile in caso di guasto, impedendo la perdita di dati sia quando questi risiedono sullo smartphone (permettendone la sincronizzazione con il server remoto) sia quando risiedono sul server stesso (prevedendo dei sistemi di backup). Infine, per quanto riguarda le interfacce utente, sia di un eventuale sito Web che della stessa applicazione mobile, esse dovranno essere intuitive, ovvero visualizzare solo le informazioni necessarie, ma prevedere anche opzioni aggiuntive, in una sezione separata, per modificare parametri più avanzati. Tali opzioni addizionali dovranno essere a disposizione del tutor, qualora il paziente non abbia esperienza nell utilizzo di software, e dovranno prevedere meccanismi che non permettano a quest ultimo di modificarle accidentalmente. Qualora invece il paziente sia in grado di operare in maniera autonoma, dovrà essere reso possibile l accesso a tali strumenti anche a quest ultimo. Pag. 6

8 2. ANALISI DEI REQUISITI 2.1. Il trattamento dei dati sanitari e la legislazione in merito Estremamente sensibile in Italia è il tema della riservatezza dei dati personali, tutelata dal Decreto Legislativo del 30 giugno 2003, n 196 (Codice in materia di protezione dei dati personali 1 ) che afferma che i dati di tipo sanitario, ovvero quelli che contengono qualsiasi tipologia di informazione riguardante la salute (e non solo) di una persona appartengono, assieme ai dati giudiziari, alla categoria dei cosiddetti dati sensibili, così come afferma l Articolo 4 del decreto. Il trattamento di tali dati è equiparato ad attività pericolosa e come tale impone a chi deve effettuarlo (e di conseguenza a chi progetta il sistema di elaborazione automatica di tali dati) di adottare particolari cautele; l Articolo 15 prevede infatti che vi sia una responsabilità civile, nel caso in cui si cagionino danni ad altre persone come effetto di tale trattamento. Inoltre, la legge impone di garantire alcuni diritti agli utenti del sistema di elaborazione, ovvero la possibilità di disporre sempre dei propri dati (quindi di sapere se sono memorizzati) nonché quello di rimuoverli, modificarli o comunque di poterne chiedere una rettifica, come stabilito dall Articolo 7. L utente del sistema ha anche diritto ad avere tutte le informazioni necessarie circa i metodi di trasmissione e trattamento dei dati e sugli incaricati ad effettuare dette operazioni (mediante un informativa sul trattamento dei dati personali). L utente deve infine dare il proprio consenso, che deve per legge essere prestato in forma scritta prestato dall utente prima di consentirgli di inviare o aggiungere i propri dati al sistema, come affermano gli Articoli 13 e 26. E fondamentale inoltre provvedere alla separazione tra dati sanitari e dati anagrafici, in modo tale che anche coloro che sono amministratori e responsabili della gestione del sistema (i tecnici incaricati della gestione degli account, ad esempio) non possano associare l identità del paziente, ovvero i suoi dati anagrafici, con i suoi dati sanitari, come definito dall Articolo 22 e provvedere alla loro protezione sia quando vengono trasmessi, sia quando vengono archiviati, con metodi di autenticazione, di cifratura e di backup. Il decreto fornisce in questo senso alcuni requisiti minimi di sicurezza per il Pag. 7

9 sistema (Articolo 31 e Disciplinare Tecnico allegato al decreto 2 ) tali requisiti devono fungere da linee guida in fase di progettazione del sistema e possono costituire delle limitazioni sia alla sua facilità di progettazione che alla sua usabilità, ma risultano essere indispensabili per permetterne la commercializzazione Definizione dei requisiti Tenuto conto della legislazione esistente in materia di trattamento dei dati sensibili, si possono definire alcune linee guida sintetiche per la progettazione del sistema di elaborazione degli stessi: Privacy e autorizzazioni al trattamento Fare sì che i dati sanitari relativi al paziente e quelli identificativi siano memorizzati in posizioni separate in modo tale che non sia possibile, per chi accede al sistema con scopi tecnici, associare i dati relativi ad un certo soggetto a quest ultimo; I dati che vengono trasmessi non devono essere riconducibili al soggetto a cui si riferiscono (devono cioè essere trasmessi in forma anonima); Informare l utente delle finalità e delle modalità di trattamento dei dati e su quali saranno i soggetti che avranno accesso ad essi (fornirgli cioè l informativa); Dare la possibilità all utente di inviare i propri dati solo dopo aver prestato il consenso al loro trattamento, il quale dovrà essere fornito obbligatoriamente per iscritto; Fornire all utente la possibilità di scegliere se inviare al medico i risultati delle misurazioni, se conservarli solo localmente o se eliminarli; Fornire all utente la possibilità di visualizzare in maniera agevole i dati memorizzati sul server, di riconoscerne la presenza e di eliminarli in parte o completamente. Autenticazione informatica Definire con precisione l ambito di accesso ed intervento sui dati da parte delle diverse categorie di incaricati (es. medici o pazienti) prevedendo diversi profili di Pag. 8

10 autenticazione, in modo tale che ogni categoria abbia accesso solo ai dati necessari ad essa per le operazioni di trattamento; Garantire l accesso ai dati solo ai soggetti autorizzati tramite un sistema di autenticazione che sfrutta come credenziali un ID, ovvero un codice di identificazione del soggetto ed una parola chiave personale (la password). Il codice deve essere costituito da almeno otto cifre alfanumeriche e deve essere fornito dalla ASL in una busta sigillata dopo che l utente ha prestato il consenso; deve inoltre essere unico per ciascun soggetto e non essere in alcun modo riconducibile a questi. Tale sistema deve consentire l identificazione univoca del soggetto che modifica i dati, sia da dispositivo che via web; Includere un sistema che obblighi l utente a scegliere una password personale la cui lunghezza deve superare gli otto caratteri e che deve necessariamente contenere sia numeri che lettere; essa deve obbligatoriamente essere modificata al primo accesso e, successivamente, almeno ogni tre mesi. La password di primo accesso deve essere fornita assieme al codice identificativo, nella busta sigillata, oppure ad un indirizzo mail sicuro che deve essere fornito dall utente stesso; Prevedere un sistema per l invalidazione delle credenziali di autenticazione non utilizzate da almeno sei mesi, escluse quelle utilizzate esclusivamente per scopi di gestione tecnica. Altre misure di sicurezza Prevedere un sistema per la protezione dei dati trasmessi sul canale di comunicazione dal danneggiamento, dalla modifica intenzionale e dall intercettazione; Garantire la protezione dal danneggiamento e dalla perdita accidentale dei dati memorizzati sul server (mediante una copia di sicurezza, almeno settimanale) ed il ripristino, entro sette giorni, della disponibilità dei sistemi in cui questi sono conservati; Pag. 9

11 Proteggere i dati contenuti nel database, anche nel caso di accessi per scopi tecnici (cifrando ad esempio le password memorizzate); Prevedere un sistema di memorizzazione di tutte le operazioni compiute sui dati e di conservazione di quelli eliminati per uso giudiziario in caso di controversie legali; tale repository deve essere inaccessibile per ogni altra ragione e i dati in esso contenuti devono essere periodicamente copiati in supporti conservati in un luogo sicuro a cui possa accedere solo una persona fidata (ad esempio l amministratore del sistema che ne ha la responsabilità) e solo nella situazione suddetta Attori e casi d uso Le categorie di utenti associate al sistema sono tre: Pazienti e tutor: in questa categoria rientrano coloro che usufruiscono del servizio di assistenza e che possono accedere alle potenzialità del sistema non solo da web, ma anche attraverso l applicazione installata nei propri dispositivi mobili. Da quest ultima possono effettuare diverse operazioni in modalità off-line (impostare allarmi, effettuare misurazioni, ecc.) ma anche sincronizzare i dati presenti nel diario in modalità on-line, dopo aver effettuato l associazione del dispositivo mobile all ID utente. Da web possono invece visualizzare e modificare i propri dati anagrafici e quelli relativi alle misurazioni effettuate (che possono rimuovere selettivamente o aggiungere) nonché reimpostare la propria password qualora non se la ricordino o nel caso in cui il loro account sia scaduto o sia il loro primo accesso al sistema. I pazienti si devono registrare sul sistema obbligatoriamente tramite web, scegliendo una password personale dopo aver ricevuto dalla ASL il codice identificativo, prima di poter sincronizzare i dati nei propri dispositivi mobili; Medici ed operatori sanitari: in questa categoria rientrano sia i medici, che necessitano di informazioni generali circa lo stato di salute del paziente, sia tutti gli operatori sanitari che devono inserire dati a seguito di un analisi effettuata su un paziente. Hanno accesso completo al database dei pazienti tramite web (sul quale possono ricercare i soggetti di interesse tramite i loro dati anagrafici) possono visualizzare i dati clinici di questi ed aggiungere nuove note e misurazioni (ma non Pag. 10

12 possono modificare quelle esistenti) possono inoltre modificare i propri dati e reimpostare la propria password. I medici si devono registrare sul sistema utilizzando il proprio codice identificativo (previa notifica ai tecnici per la creazione del nuovo account) scegliendo quindi una password personale. Essi possono infine visualizzare le azioni compiute dai pazienti sui dati (come cancellazioni e modifiche) attraverso un sistema di tracciabilità delle operazioni compiute (un log); Tecnici e amministratori di sistema: possono modificare, aggiungendoli, rimuovendoli o cambiandone lo stato, gli account di pazienti e medici. Non sono autorizzati ad accedere o modificare in nessun modo i dati di questi ultimi. I tecnici accedono al sistema per mezzo di una password ed un username prefissati ed uguali per tutti i soggetti di questa categoria e sono direttamente responsabili della loro segretezza. Oltre a questi, assumono rilevanza altri tre attori, che sono parte integrante del sistema: Gli strumenti di misurazione: si intendono tutti quegli strumenti utili alle analisi che possono essere sincronizzati con l applicazione mobile per la ricezione e memorizzazione dei risultati delle misurazioni da parte di quest ultima; Il software di controllo: è il software che si occupa della gestione dei dati nel database svolgendo alcune funzioni essenziali in maniera automatizzata: Effettua settimanalmente un backup di tutti i dati contenuti nel database; Controlla con frequenza giornaliera gli account nel database per eliminare quelli più vecchi di tre mesi e scaduti; Controlla gli account di medici e pazienti per eliminare quelli che non sono stati utilizzati da più di sei mesi (eliminando tutti i dati ad essi collegati); Elimina, o salva su supporto, i dati dei pazienti quando i loro account vengono rimossi. Il software di controllo può essere un programma esterno al software stesso, che agisce in maniera attiva e periodicamente, oppure di tipo lazy, ovvero può intervenire Pag. 11

13 solo a seguito di un interazione degli utenti (per esempio, verificando la validità dell account quando l utente tenta di accedervi) nel nostro caso esso sarà progettato seguendo quest ultima filosofia. Il database: il sistema di memorizzazione persistente dei dati in maniera strutturata all interno di tabelle, nelle quali sono contenuti i dati relativi agli account di medici, pazienti e tecnici, nonché i dati anagrafici dei pazienti e le loro cartelle cliniche (costituite dai risultati delle analisi e dalle annotazioni). Fig. 1 - Diagramma dei casi d'uso Pag. 12

14 3. PROGETTAZIONE DEL SISTEMA Dopo una fase preliminare di raccolta ed analisi dei requisiti, si è passati alla progettazione del sistema durante la quale sono state definite tutte le componenti necessarie per il suo funzionamento ed, in particolare, il server web e il database, il sito web (Healthcare Web) e l applicazione mobile (Healthcare Alarm) pensata per dispositivi con sistema operativo Android (non è comunque esclusa la possibilità di uno sviluppo futuro su altre piattaforme, come ad esempio ios) Il server web Il server web è il componente principale del sistema ed è un applicativo che risiede, assieme al database, su una macchina server e funge da interfaccia tra questo e il client, che richiede l elaborazione di dati o pagine web. In particolare, esso fornisce tutti i dati necessari sia al sito web che all app Android. Il server web è costituito da una servlet, ovvero da un software lightweight scritto in Java, che risiede all interno di un application server, il quale funge a sua volta da contenitore di servlet (nel senso che può eseguire più software di questo tipo in ascolto simultaneo su diverse porte della macchina) nel nostro caso il server open source Oracle Glassfish. La servlet risponde alle richieste (di tipo POST o GET) che gli vengono trasmesse dalla rete attraverso il protocollo HTTPS (HyperText Transfer Protocol over Secure Socket Layer) e che possono provenire sia dalla pagina web (tramite istruzioni in linguaggio JSP integrate nell HTML) sia attraverso vere e proprie funzioni Java, incluse in una libreria ad-hoc presente all interno dell app per Android. In entrambi i client, a seguito di determinate azioni compiute dall utente, che prevedono o l autenticazione delle credenziali o l elaborazione dei dati nel database, vengono inviate delle richieste HTTPS POST (ad una determinata porta del server - la 8180, usata perlopiù in fase di test, o la 8181) contenenti un URL, un header (l intestazione, che indica il tipo di richiesta ed altri parametri) ed un body (il corpo del messaggio) all interno del quale sono presenti diversi attributi che compongono la richiesta. Nel nostro caso, uno di questi attributi è command, il quale ha come valore associato il tipo di azione richiesta dal client, mentre gli altri attributi sono quelli associati al tipo di comando, come ad Pag. 13

15 esempio type, che specifica se il login viene effettuato da un medico, da un paziente o da un tecnico. I comandi principali accettati dalla servlet, e definiti nella sua classe Commands, sono i seguenti: ACCESS: permette l accesso di un utente al sistema; i parametri che devono accompagnare questa richiesta sono obbligatoriamente type, id e password, dove type può assumere i valori patient, medic e technic. Quando la servlet ha verificato la corrispondenza dei dati inseriti con quelli presenti nel database, invia al browser del client la pagina web che permetterà all utente di visualizzare la propria cartella personale. ADD_MEASUREMENT: permette l aggiunta di una misurazione da parte di un operatore sanitario o di un paziente; la richiesta è accompagnata dagli attributi id, medic_id, type, date, value ovvero, rispettivamente, l id del paziente a cui è associata la misurazione o l annotazione, l id dell operatore incaricato di effettuarla (facoltativo) il tipo, la data e i valori associati all analisi. La servlet sfrutta questi dati per inserire la nuova misurazione nel database, qualora rilevi che non ne sia già presente una con lo stesso timestamp, ed invia al browser del client la pagina dei risultati aggiornata con i nuovi dati inseriti. DELETE_MEASUREMENT: permette la cancellazione della misurazione memorizzata nel database; possiede gli stessi parametri del comando ADD_MEASUREMENT, che permettono alla servlet di identificare in maniera univoca la misurazione e di eliminarla. PASSWORD_REQUEST: richiede l invio via di una password temporanea all utente; la richiesta contiene solo l attributo id, che la servlet sfrutta per reperire nel database l indirizzo riservato dell utente al quale mandare la password casuale e per cambiare con essa quella che era precedentemente associata a quell account. La servlet contiene al suo interno il codice necessario sia per l invio della dall account di posta SMTP predefinito sanita.centrosistemi@gmail.com, sia per la generazione casuale della nuova password temporanea. Pag. 14

16 PASSWORD_RESET: richiede il cambiamento della password ed è associato agli attributi id, password e password_to_compare (il cui significato sarà più chiaro quando parleremo del sito web e del suo sistema di autenticazione). La servlet verifica che l id esista nel database e, se verifica che la password nuova e quella di confronto corrispondono, aggiorna la password e la sua data di scadenza (con la data attuale più il tempo di validità prefissato, in genere tre mesi) nel database. BACK_TO_PATIENTS_LIST: viene inoltrato quando un medico desidera tornare dalla schermata dei dati di uno specifico paziente a quella che contiene la lista di tutti i pazienti; contiene l attributo id, che permette alla servlet di accertare che la richiesta provenga da un utente valido e di inviare al browser del client la pagina JSP che contiene la lista di tutti i pazienti. GO_TO_PATIENT: inverso rispetto al comando BACK_TO_PATIENTS_LIST, permette al medico di accedere alla scherma che contiene i dati clinici di un certo paziente a partire dalla lista dei pazienti; la richiesta contiene gli attributi id e medic_id, il primo dei quali viene utilizzato dalla servlet per identificare il paziente per cui sono state richieste informazioni, mentre il secondo per accertare che la richiesta provenga da un operatore sanitario autorizzato. I comandi sopra elencati vengono inviati dal browser web del client, mentre l utente visualizza il sito; i seguenti comandi sono invece quelli inviati dall app Android. Possono sembrare duplicati rispetto ai precedenti, ma il motivo per cui sono diversi è perché diversa è la risposta della servlet. Mentre nel caso precedente essa aveva il compito di inviare una pagina JSP elaborata da visualizzare sul browser del client, come risposta alla richiesta, in questo caso viene inviata una semplice risposta HTTP, che contiene al suo interno un response status code, ovvero un numero di tre cifre dove quella più significativa specifica una di cinque classi di risposta (da 1 a 5 rispettivamente: Informational, Success, Redirection, Client Error e Server Error) come definito dallo standard IETF RFC 2616 per l HTTP/ Sulla base del codice ricevuto dal server, l app Android potrà compiere diversi tipi di azioni. I comandi riconosciuti dalla app sono: Pag. 15

17 VALIDATE: inoltrato quando l utente associa il proprio dispositivo mobile al server, contiene come attributi id e password, che permettono alla servlet di autenticarlo; la servlet risponde con OK se l autenticazione è andata a buon fine, con Forbidden in caso di autenticazione non valida o account scaduto e con Internal Server Error in caso di errore di altro tipo. CHECK: verifica che l elemento, misurazione o annotazione, definito dagli attributi id, type, date e value (che hanno lo stesso significato di quelli di ADD_MEASUREMENT) corrisponda ad una misurazione già presente sul database; in caso affermativo risponde con OK altrimenti con Not Found, o con Internal Server Error in caso d errore. SYNC: include in se la funzione CHECK; dopo aver verificato che la misurazione o l annotazione definita dagli attributi type, date e value per l utente identificato da id non sia già presente nel database (in quel caso non l aggiunge nuovamente, ma ritorna semplicemente OK) la inserisce e, se l aggiunta riesce ritorna OK, altrimenti ritorna come codice Internal Server Error. Un ultima osservazione è che, se anche fosse possibile costruire un programma in grado di inviare comandi al server sulla porta in cui è in ascolto la servlet (cosa non eccessivamente difficile in quanto i comandi potrebbero essere ricavati in parte dalle stesse pagine HTML del sito) sarebbe comunque necessario inviare assieme ad essi l id dell utente, noto solo ad esso; in caso contrario tali comandi verrebbero rifiutati. Altre funzionalità fornite dalla servlet, sono: Il sistema di hashing mediante Secure Hash Algorithm (SHA) dei dati, in particolare delle password delle quali viene ottenuto il digest subito prima del confronto con il corrispondente digest nel database, in fase di autenticazione (tale funzionalità è fornita dalla libreria SHAHash del package it.healthcare.security); Il sistema di generazione casuale delle password, che permette di creare password temporanee aventi lunghezza fissata, nel nostro caso 10 caratteri di tipo alfanumerico (funzionalità fornita dalla libreria PasswordGenerator del package it.healthcare.security); Pag. 16

18 Il sistema di controllo dell input, che serve a contrastare attacchi di tipo injection (di cui parleremo in seguito) rifiutando tutti gli attributi in ingresso i cui valori contengano caratteri non validi, in genere caratteri speciali (funzionalità questa fornita dalla libreria InputController del package it.healthcare.security); L invio automatico di mail sfruttando l account di posta predefinito, il quale sfrutta il server di posta SMTP (Simple Mail Transfer Protocol) di Google all indirizzo smtp.gmail.com ed un account GMail dal quale vengono inviati i messaggi agli utenti, sanita.centrosistemi@gmail.com; questa funzione viene realizzata dalla libreria Mail del package it.healthcare.web; Un ultima caratteristica fondamentale della servlet è la modalità di connessione al database il quale, nel nostro caso, è residente sulla stessa macchina su cui si trova in esecuzione la servlet (ma potrebbe anche trovarsi in un altra) ed è pertanto raggiungibile all URL jdbc:mysql://localhost:3306/telemedicina, dove telemedicina indica appunto il nome del database. La connessione al database viene effettuata tramite la libreria DBConnection del package it.healthcare.web.database, che contiene tutte le funzioni necessarie ad eseguire operazioni su quest ultimo e che sfrutta come connettore JDBC (Java DataBase Connectivity) l API fornita da Oracle nel package JAR mysql-connector-java jar 3.2. Il database e la struttura dei dati Per la realizzazione del sistema è stato impiegato un database MySQL; tale database svolge la funzione di archiviazione dei dati e non può essere acceduto dall esterno, se non tramite autenticazione sulla macchina su cui si trova in esecuzione (che si suppone sia in luogo non accessibile a chi non è autorizzato). L unico metodo alternativo per accedervi da parte degli utenti è proprio quello di comunicare con l application server, il quale contiene la servlet che funge da intermediaria. Il database ha un ruolo passivo, nel senso che, ad eccezione dei backup, non modifica autonomamente i dati che contiene, bensì è la servlet ad intervenire su di esso in caso di modifica. Pag. 17

19 Nel database, che porta il nome di telemedicina, i dati vengono conservati in tabelle, per un totale di sei. Due di esse vengono utilizzate esclusivamente dai tecnici per la gestione degli account e sono: account_pazienti: la tabella che memorizza l ID di ciascun paziente, la data di ultimo accesso, il digest hash della password associata e la data di scadenza dell account; account_operatori: tabella analoga alla precedente, che contiene gli stessi attributi ma si riferisce agli account degli operatori sanitari. Nelle due tabelle di cui sopra non sono memorizzati dati anagrafici o clinici relativi agli utenti, ma solo agli account e solo esse possono essere accedute in maniera diretta dai tecnici per la gestione degli stessi (inoltre, le password non sono memorizzate in chiaro ma attraverso i relativi digest, per evitare che i tecnici possano effettuare login non autorizzati agli account delle altre due categorie). I dati personali degli utenti sono invece memorizzati nelle seguenti tabelle: dati_pazienti: memorizza i dati anagrafici associati all ID di ciascun paziente; tali dati sono costituiti dal nome, dal cognome, dal codice fiscale, dalla data di nascita, dalla nazionalità, dal luogo di residenza, dai numeri di telefono fisso e mobile, dall id del medico curante (che deve essere registrato nel sistema per poter aggiungere dati per quel paziente) e dalla mail personale per il recupero della password (obbligatoria); dati_clinici_pazienti: memorizza, per ciascuna misurazione effettuata o annotazione inserita, l ID del paziente associato, la data, l ora e il tipo di analisi (o nota) l ID del medico che ha effettuato la misurazione (se a farla non è stato il paziente) e i dati associati ad essa. I dati possono provenire dai dispositivi mobili dei pazienti oppure essere stati aggiunti manualmente da medici o pazienti direttamente via web; dati_operatori: contiene i dati anagrafici sintetici degli operatori sanitari, ovvero nome, cognome e titolo; conserva inoltre l indirizzo per il recupero della password (obbligatorio); Infine siccome, come avevamo detto nella fase di analisi dei requisiti, in caso di controversie legali è indispensabile poter disporre di dati che potrebbero essere stati Pag. 18

20 eliminati in maniera accidentale o con cattive intenzioni e di mantenere traccia delle operazioni effettuate da tutte le categorie, è necessario prevedere una tabella per memorizzarle: log_operazioni: memorizza l identificativo dell utente che ha effettuato un operazione e la tipologia di utente (tecnico, operatore sanitario o paziente) il tipo di operazione (aggiunta di un account, eliminazione o modifica di un dato, ecc.) e i dati affetti dalla modifica. La tabella in questione si suppone essere inaccessibile ed i dati in essa contenuti verranno periodicamente copiati su supporti rimovibili a cui abbia accesso solo l amministratore di sistema, il quale è comunque autorizzato ad accedervi solo in caso siano necessarie delle indagini giudiziarie sui di essi L applicazione web (Healthcare Web) Come abbiamo precedentemente affermato, le applicazioni che possono connettersi al server sono due: Healthcare Web (il sito accessibile via browser web) ed Healthcare Alarm (l app Android). Il sito è accessibile da tutte le categorie di utenti, ovvero medici, pazienti e tecnici, attraverso un normale browser web, collegandosi all indirizzo Internet: Non appena digitato l URL, il browser bloccherà il sito avvertendo che non è possibile accertare l autenticità del certificato (questo errore è dovuto al fatto che il certificato è self-signed, cioè firmato dal progettista del sistema e non da un autorità certificante nota) e verrà richiesto di aggiungere un eccezione. Una volta confermata, verrà visualizzata la schermata iniziale del sito. Pag. 19

21 Fig. 2 - Schermata iniziale Dalla schermata iniziale sarà possibile per l utente decidere se accedere all area pazienti o all area operatori sanitari; una volta cliccato sull immagine relativa all area a cui si desidera accedere, verrà visualizzata la schermata di login all account personale. Fig. 3 - Schermata di accesso Da tale schermata l utente può inserire l ID fornitogli dalla ASL e la propria password personale. L ID viene fornito all utente in una busta sigillata, è strettamente personale Pag. 20

22 ed è compito dell utente non perderlo e non divulgarlo. La password invece viene fornita dalla ASL tramite all account personale dell utente, dopo aver ritirato la busta con il codice personale. Al primo utilizzo, il sistema chiederà di reimpostare la password; questa procedura avviene automaticamente anche quando l account è scaduto o quando l utente ha, spontaneamente, chiesto di ricevere una nuova password personale via mail. La procedura permette di essere certi dell identità dell utente, perché nel caso in cui un soggetto non autorizzato fosse a conoscenza del codice identificativo, egli dovrebbe avere accesso anche all account di posta personale dell utente. La reimpostazione avviene digitando l ID personale, la nuova password e la conferma della nuova password inserita; una volta effettuata l operazione l account verrà rinnovato con la nuova password, valida per tre mesi. Fig. 4 - Schermata di reimpostazione della password Per richiedere l invio di una nuova password (e l automatico rinnovo dell account per altri tre mesi), l utente può anche premere sul link Reimposta posto sotto il form di login; in questo modo egli verrà automaticamente rimandato alla pagina web dove gli verrà richiesto il codice personale, dopodiché, una volta confermato l inserimento, riceverà al suo indirizzo privato di posta una password temporanea generata casualmente. Pag. 21

23 Fig. 5 - Mail di recupero password Quando il paziente effettua il login al proprio account viene invece reindirizzato ad una pagina dalla quale può visualizzare i dati personali comunicati precedentemente alla ASL, nonché tutte le misurazioni e le annotazioni effettuate, oltre a poter inserire nuovi elementi o eliminarli. Il paziente è sempre in grado di eliminare tutti gli elementi, anche quelli inseriti dagli operatori sanitari (contrassegnati da un asterisco) ciò non significa però che tali dati vengano persi, in quanto, come abbiamo precedentemente detto, sul database rimarrà traccia sia dei dati eliminati che dell operazione di eliminazione con la relativa data. Fig. 6 - Schermata gestione dati personali del paziente Pag. 22

24 Se invece ad effettuare l accesso è un operatore sanitario, la schermata che gli verrà presentata conterrà la lista di tutti i pazienti registrati sul sistema, in quanto può essere necessario reperire informazioni su di essi anche da parte di medici diversi da quello curante, ad esempio qualora un paziente sia ricoverato d urgenza al pronto soccorso. I pazienti sono identificabili tramite nome, cognome e dati anagrafici (non il codice personale però) nonché con il nome del medico curante, se registrato anch egli sul sistema. Premendo sul pulsante relativo a ciascun paziente l operatore potrà accedere alla schermata che contiene le misurazioni relative al paziente scelto, dalla quale potrà quindi aggiungere e rimuovere elementi. L operatore sanitario non può tuttavia rimuovere i dati aggiunti dal paziente o da altri medici. Fig. 7 - Schermata generale pazienti Le schermate di inserimento dati come paziente e come operatore non sono molto differenti tra di loro, entrambe hanno in comune il fatto di possedere tre campi di testo per l aggiunta di una nuova misurazione. In tali campi, la data e l ora della misurazione vengono inserite in maniera automatica (e sono modificabili) mentre la tipologia deve essere scelta sulla base dei tipi di analisi disponibili e a seconda di quello scelto cambierà il tipo di valori inseribili nel terzo campo, quello nella colonna dei risultati. Alcuni dei tipi inseribili sono: FC / BPM: frequenza cardiaca/battiti per minuto; PMAX: pressione massima; Pag. 23

25 PMIN: pressione minima; ALTEZZA-CM: altezza in cm; PESO-KG: peso in kg; SPO2: percentuale di ossigeno nel sangue; NOTA: nota generica; Questi sono i tipi attualmente disponibili a scopo dimostrativo; il sistema può comunque essere esteso facilmente per accettare anche altri tipi di dati, come ad esempio immagini di ecografie o radiografie, misurazioni ottenute da analisi del sangue, scannerizzazioni di documenti sanitari, ecc. Fig. 8 - Campi di inserimento nuovo dato Nel caso in cui l utente decidesse di premere il pulsante back sul browser, si potrebbero verificare dei problemi, in quanto il browser tenterebbe di recuperare e visualizzare l ultima pagina salvata in locale nella sua cronologia. Per evitare che questo accada (e che vengano quindi visualizzate pagine che contengono dati non più aggiornati, oppure che un utente possa ritornare ad una pagina che richiede il login precedentemente visualizzata anche dopo aver effettuato il logout dall account) quando la servlet invia come risposta le pagine JSP informa il browser che tali pagine non sono conservabili in cache, né archiviabili (attraverso l aggiunta del tag META, che ha come valori NO-CACHE e NO-STORE). In tal modo, quando l utente preme il pulsante back viene visualizzato nel browser il messaggio che la pagina scelta è scaduta L applicazione mobile (Healthcare Mobile) L applicazione per dispositivi mobili Healthcare Mobile è stata sviluppata in collaborazione con la Zucchetti Centro Sistemi S.p.A., è stata progettata per essere Pag. 24

26 eseguita su tutti i device con sistema operativo Android e non è esclusa la possibilità di uno sviluppo futuro per dispositivi ios. L applicazione consente agli utenti (pazienti e tutor) di effettuare misurazioni dal proprio smartphone o tablet mediante sincronizzazione attraverso Bluetooth con un appropriato set di strumenti (misuratori di pressione, di glicemia, bilance, ecc.) oppure di aggiungere manualmente i valori delle misurazioni ottenuti da qualsiasi strumento. Il sistema è particolarmente conveniente per quelle persone che, a causa di determinate malattie, devono assumere farmaci e/o effettuare misurazioni regolari in maniera autonoma o con l assistenza di un tutor (ad esempio un familiare). Il sistema permette infatti un assistenza remota ed è facilmente utilizzabile anche da coloro che non hanno molta esperienza nell utilizzo dei dispositivi mobili (come ad esempio gli anziani) Struttura dell app Per una migliore facilità d impiego, l applicazione consta di una sezione paziente (schermata iniziale e diario) molto semplice ed intuitiva e di una sezione tutor, che mette a disposizione funzionalità più avanzate, non necessariamente accessibili al paziente, tra le quali la creazione di una password personale del tutor che permette di separare tra di loro le due sezioni. Nel caso in cui il paziente sia autonomo e perfettamente in grado di utilizzare l app, è sufficiente per il tutor non impostare la password. La Sezione Paziente è costituita da: Una Schermata Iniziale, alla quale si accede dopo aver visualizzato la schermata che riporta la versione, il nome del programma e l informativa al trattamento dei dati personali. La schermata permette di Fig. 9 - Schermata iniziale Fig Diario delle misurazioni Pag. 25

27 visualizzare il prossimo allarme programmato, la sua tipologia e, se impostati, i farmaci da assumere con la relativa posologia. Dalla schermata iniziale è possibile accedere alla Schermata Impostazioni (premendo il pulsante back e poi Impostazioni ) e al Diario delle Misurazioni (premendo il pulsante back e poi Diario ); Un Diario delle Misurazioni, che permette di visualizzare data, ora, tipologia e valori delle misurazioni effettuate, nonché di: o Eliminarle premendo sul pulsante con la X associato ad ognuna di esse; o Aggiungerle attraverso il pulsante Aggiungi dati e la schermata di aggiunta manuale degli stessi; o Sincronizzarle singolarmente, attraverso il pulsante con la freccia circolare associato a ciascuna di esse, il quale risulta essere verde se la sincronizzazione è stata eseguita, rosso altrimenti, disattivato qualora non sia possibile effettuarla (ad esempio quando non è stato inserito l ID utente); o Sincronizzare tutte le misurazioni insieme, attraverso il pulsante Sincronizza dati (anch esso disattivato in assenza dell ID utente). In questa schermata il software controlla ad intervalli regolari se le misurazioni sono o meno sincronizzate con il server, ma solo qualora la connessione ad Internet sia disponibile. Una Schermata di Aggiunta Manuale dei Dati che, come descritto dal nome, permette di aggiungere i dati senza l ausilio di strumenti: dopo aver specificato il tipo di misurazione che si desidera Fig Schermata di aggiunta manuale dati Fig Schermata impostazioni (parte sup.) Schermata impostazioni (parte sup.) Pag. 26

28 aggiungere è possibile inserire i valori relativi ad essa all interno di campi prefissati; La Sezione Tutor è invece costituita da: Una Schermata Impostazioni, suddivisa in due tab e dotata di un pulsante Conferma per confermare le modifiche effettuate in essi, costituita da: o Il Tab Impostazioni Generali che permette di modificare le impostazioni dell applicazione, come: - Il timeout dell allarme in minuti, ovvero il tempo dopo il quale, se non viene effettuata alcuna azione, l allarme scade ed invia mail ed SMS di avviso ai contatti specificati nella sezione Gestione Contatti; - L intervallo in minuti dopo il quale un allarme che è stato rimandato dall utente viene riproposto; - Il suono di notifica che viene eseguito quando l allarme si verifica (include l opzione silenzioso qualora l utente non desideri alcuna suoneria per l allarme); Fig Schermata impostazioni (parte inf.) - Il nome del tutor e quello del paziente, opzionali, che vengono visualizzati nelle mail e negli SMS di avviso, sono utili qualora un tutor, come un medico di base Fig Finestra nuovo account GMail, schermata contatti e finestra di aggiunta nuovo contatto Pag. 27

29 od il responsabile di un servizio di teleassistenza, debba ricevere informazioni relative a più pazienti, per consentirgli di identificarli; - Il pulsante Modifica Contatti, che permette di accedere alla sezione Gestione Contatti, dalla quale è possibile aggiungere, eliminare (mediante i pulsanti con la X) e visualizzare gli indirizzi mail ed i numeri di telefono, con associati i relativi nomi, ai quali saranno inviate rispettivamente mail ed SMS, nel caso in cui ad un allarme non venga risposto (da notare che gli avvisi mail non verranno inviati nel caso in cui non sia stato configurato un account di posta personale GMail); - Il pulsante Account GMail, che permette di accedere alla finestra di dialogo Gestione Account, dalla quale è possibile specificare il proprio indirizzo di posta GMail e la password ad esso associata. Tale indirizzo costituisce il mittente delle mail di avviso ed è indispensabile per permetterne l invio. Il motivo per cui viene utilizzato un indirizzo di posta Google per l invio delle mail è che, di default è necessario un account di questo tipo per accedere alle funzionalità di Android e si suppone quindi che l utente ne sia già in possesso; - Il pulsante ID Utente, che permette di accedere alla finestra di dialogo Gestione Credenziali Utente, dalla quale è possibile inserire l ID e la password personali dell utente, che sono quelli conservati nel database del server. Una volta premuto il pulsante Conferma, l app si collega al server web che effettua l autenticazione dell utente; solo se questa avviene con successo è consentita la sincronizzazione dei dati nel diario con il database; - Il pulsante Password Tutor che permette di specificare se il controllo della password, all accesso della Schermata Impostazioni, deve essere attivo. La password è necessaria solo se il tutor desidera che il paziente non possa modificare le impostazioni del Fig Finestra gestione credenziali utente Pag. 28

30 programma e gli allarmi programmati. o Il Tab Gestione Allarmi, che permette di visualizzare, modificare (premendo su di essi) cancellare (premendo sui pulsanti con la X) e aggiungere (premendo sul pulsante Aggiungi ) gli allarmi. La modifica e l aggiunta degli allarmi viene effettuata dalla schermata Nuovo/Modifica Allarme. La Schermata Nuovo/Modifica Allarme, che permette di impostare un nuovo allarme o di modificarne uno già esistente, è costituita da: o Il tipo di allarme, obbligatorio; è possibile scegliere tra farmaco, misurazione o altro; o La descrizione dell allarme, facoltativa, che verrà visualizzata nella schermata iniziale per il prossimo allarme programmato; Fig Tab gestione allarmi o La validità dell allarme, che può essere impostata come illimitata o definendo un periodo di validità specifico; l allarme sarà automaticamente rimosso al termine di tale periodo; o La ripetitività dell allarme, che può essere impostato come giornaliero o settimanale ; nel primo caso, esso verrà riproposto ogni giorno agli orari Fig Schermata nuovo/modifica allarme (con allarmi giornalieri e settimanali) e finestra aggiunta nuovo farmaco Pag. 29

31 specificati, nel secondo caso, verrà riproposto ogni settimana, nei giorni e agli orari specificati. Allarmi di tipo diverso, impostati agli stessi orari e agli stessi giorni, vengono automaticamente riprogrammati dopo cinque minuti; o La descrizione del farmaco, che può essere inserita attraverso i pulsanti con l icona a forma di matita, è disponibile solamente per gli allarmi di tipo farmaco o altro e permette di specificare il nome e la posologia dei farmaci da assumere a quello specifico orario o in quello specifico giorno; o Il pulsante Conferma che permette di confermare le modifiche fatte sull allarme, o la sua creazione. Oltre all app a cui è possibile accedere dal menu applicazioni del proprio dispositivo, Healthcare Mobile è costituita da un servizio sempre attivo in background (definito nella classe AlarmService) che tiene traccia degli allarmi programmati e avvisa l utente della loro occorrenza attraverso una finestra di dialogo; sfortunatamente, a causa di limitazioni intrinseche al sistema operativo Android, tali allarmi non funzionano a dispositivo spento, ma vengono automaticamente visualizzati al suo primo riavvio. Quando un allarme viene visualizzato, viene proposta all utente la scelta se rimandarlo (pulsante Non ancora ) o se confermarlo (pulsante Si ). Nel primo caso, la finestra di dialogo viene chiusa e l allarme riproposto dopo il tempo specificato. Nel secondo caso, se l allarme è relativo ad un farmaco o, ad esempio, ad una visita dal dottore, viene ritenuto concluso e nessuna ulteriore azione è necessaria (si suppone che il paziente abbia assunto il farmaco o sia andato dal medico) se invece è una misurazione si passa alla fase di ricezione dei dati, che prevede: La Schermata di Inizio Ricezione, dove è presente un Fig Finestra di allarme Fig Schermata di inizio ricezione Pag. 30

32 pulsante che permette di attivare il Bluetooth (se non è attivo verrà chiesta conferma all utente) e di accedere alla schermata di Ricezione Dati; La Schermata di Ricezione Dati, dove avviene la sincronizzazione tramite Bluetooth con il dispositivo associato alla tipologia di misurazione da effettuare; se il dispositivo viene rilevato, i dati della misurazione verranno visualizzati negli appositi campi. A questo punto è possibile ripetere la misurazione (con il pulsante Ripeti ) confermarla (con Conferma ) o annullarla. Nel caso in cui Fig Schermata di ricezione dati venga data conferma, i dati della misurazione saranno memorizzati in locale, nel diario dei risultati. Affinché la ricezione sia possibile è necessario che lo strumento stia trasmettendo e che sia stato effettuato il pairing Bluetooth tra strumento e dispositivo mobile; in caso contrario verrebbe visualizzato un messaggio di errore. Fig Struttura dell'applicazione mobile Pag. 31

33 I dispositivi di misurazione Come abbiamo visto in precedenza, l applicazione supporta la connessione Bluetooth con alcuni dispositivi di misurazione, in particolare strumenti diagnostici, come misuratori di pressione, bilance, misuratori di ossigenazione sanguigna, ecc.. In generale non ci sono limitazioni ai dispositivi collegabili con l app, premesso che vengano sviluppati i relativi driver e che questi strumenti dispongano di un antenna Bluetooth compatibile con il dispositivo mobile. Allo stato attuale, solo un certo insieme di strumenti è supportato, ma è prevista l estensione anche ad altri. L idea di fondo è quella di mettere insieme diversi gruppi di strumenti, ciascuno dei quali sia destinato a fungere da supporto a persone con una determinata patologia (ad esempio un insieme di strumenti, come i misuratori di glicemia, destinati ai diabetici, un altro destinato a persone sovrappeso, ecc.) in modo che il paziente possa scegliere quale kit acquistare, assieme all app, sulla base delle proprie necessità. Per la sperimentazione dell applicazione sono stati scelti alcuni dispositivi della TaiDoc Technology Corporation 4, che sono anche gli unici correntemente supportati; essi sono: Un ossimetro modello TD-8201; Un misuratore di pressione TD-3128; Un termometro TD-1261; Una bilancia TD Fig Misuratore di pressione TD-3128 Indispensabile affinché sia possibile l invio dei dati dal dispositivo di misurazione all applicazione è il pairing Bluetooth dei due: in quasi tutte le versioni di Android, esso può essere effettuato accedendo al menu Impostazioni / Rete e Wi-Fi del dispositivo mobile; nella scheda Bluetooth è possibile visualizzare tutti gli strumenti correntemente visibili (un dispositivo è visibile solo quando sta trasmettendo, nel caso dei dispositivi TaiDoc, quando lampeggia la luce blu). Per associare un dispositivo è necessario premere sul nome corrispondente e digitare nella finestra di dialogo il codice di pairing (nel caso dei dispositivi TaiDoc questo è sempre ). Per Pag. 32

34 quanto riguarda i dati trasmessi da tali dispositivi, sono quelli relativi all ultima misurazione effettuata, il cui timestamp è costituito dalla data e dall ora corrente dello smartphone nel momento della ricezione. Alcuni dispositivi, come il misuratore di pressione, permettono di richiamare ed inviare allo smartphone, tramite appositi pulsanti, i dati relativi all ultima misurazione salvata in memoria, ovvero l ultima effettuata. Fig Procedura di pairing dei dispositivi TaiDoc su Android "Ice Cream Sandwich" Pag. 33

35 4. TECNOLOGIE ADOTTATE Nel presente capitolo, si introducono le principali tecnologie adottate per lo sviluppo del sistema. Healthcare Mobile è un app Android e vedremo meglio quali sono le differenze tra le app (non solo quelle per Android ma anche quelle per ios) e le normali applicazioni per PC e MAC. Parleremo poi della application server Oracle Glassfish e di come esso funzioni da servlet container. Descriveremo la struttura delle servlet e ne spiegheremo i vantaggi (rispetto, ad esempio, agli script CGI) e le differenze, in relazione ad altre tecnologie della piattaforma Java Platform Enterprise Edition, o Java EE, come applet e pagine JSP. Analizzeremo infine il database mysql e l interfaccia per la sua gestione, la Oracle MySQL Workbench Le applicazioni mobili e il sistema operativo Android Un applicazione mobile (o più semplicemente un app) è un software applicativo destinato ad essere eseguito su dispositivi mobili, quali computer tablet e smartphone. Il termine app è diventato popolare negli ultimi anni tanto da essere dichiarata Parola dell anno dall American Dialect Society nel L imprenditore Michael J. Saylor 5 ha affermato che le app hanno permesso il passaggio dai vecchi modelli di smartphone a quelli, più recenti, orientati alle app stesse, i quali oltre ad implementare il multitasking, possono supportare applicazioni scritte in linguaggi di programmazione differenti e sono ormai più vicini ad essere considerati dei computer veri e propri, piuttosto che dei telefoni portatili. Le app sono generalmente rese disponibili dagli sviluppatori attraverso alcune piattaforme di distribuzione standard, le quali sono gestite tipicamente dal proprietario del sistema operativo mobile, come ad esempio l App Store (distribuzione delle app per ios) Google Play (per le app Android) Windows Phone Store (per le app di Windows Phone) e BlackBerry App World (per quelle per BlackBerry). Quelle distribuite dalle piattaforme sopracitate sono normalmente scaricabili direttamente sul dispositivo di installazione (il target device) tramite un cavo USB, oppure possono essere scaricate mediante l app associata alla piattaforma, che in genere è preinstallata sugli smartphone. Le app possono essere gratuite o a pagamento, a Pag. 34

36 discrezione dello sviluppatore e, in genere, per quelle a pagamento, una percentuale di circa il 20-30% è destinata al fornitore del servizio di distribuzione, mentre il restante 70-80% va a chi ha sviluppato e pubblicato il software. Le app di alcuni sistemi operativi open source (come ad esempio Android) possono essere distribuite anche attraverso altri canali (come ad esempio il sito web dello sviluppatore) pubblicando direttamente l archivio eseguibile corrispondente (l APK) ovvero l analogo dell eseguibile con estensione EXE dei software per Windows. L APK contiene al suo interno i file DEX (Dalvik EXecutables) ovvero i file compilati e contenenti il byte code, file di risorse, ecc. Le app furono inizialmente sviluppate per rispondere ad esigenze di produttività o di information retrieval, come ad esempio per la gestione di e di contatti, calendari ed informazioni sul meteo e sulla finanza. Tuttavia, l aumento della domanda e la sempre maggiore disponibilità di programmi per il loro sviluppo, realizzati ad-hoc dalle diverse case proprietarie dei sistemi operativi (i Software Development Kit, o SDK, ad esempio XCode di Apple) portò ad una rapida espansione in altre categorie, come ad esempio giochi, automazione, servizi basati sulla localizzazione GPS, mobile banking, acquisti online, ecc. La popolarità delle applicazioni ha continuato ad aumentare ed il loro utilizzo è diventato sempre più prevalente tra gli utenti di dispositivi mobili. Nel maggio del 2012, uno studio di comscore 6 ha rilevato che, durante il quadrimestre precedente, la percentuale di utenti che usavano app rispetto a quelli che navigavano sul web con i propri device era pari al 51,1% contro il 48,9%, mentre un altra indagine ha svelato che, nel settembre del 2012, vi erano più di applicazioni disponibili per il solo sistema Android e che il numero stimato di applicazioni scaricate dal solo Google Play si aggirava attorno ai 25 miliardi. Per quanto riguarda, in particolare, le app Android, Google mette a disposizione degli sviluppatori una piattaforma per la loro distribuzione su Google Play, detta Android Developer Console. Detta piattaforma fornisce allo sviluppatore molte funzionalità, fra cui la possibilità di pubblicare gli APK sviluppati sul market, inserendone l icona e degli Pag. 35

37 screenshots personali, specificando le lingue supportate e scegliendo a quali paesi o a quali carrier permetterne l utilizzo. Essa permette inoltre di aggiornare le applicazioni pubblicate, in maniera invisibile all utente, e di visualizzare le statistiche relative ad ogni app pubblicata: il numero di installazioni attive e di quelle totali, le versioni dei dispositivi su cui è installata e le lingue delle installazioni. Tutte queste informazioni, assieme alla possibilità di visualizzare tutte le eccezioni che si sono verificate nei dispositivi degli utenti durante l uso del software, permettono di risolvere efficacemente eventuali bug e di facilitare il miglioramento. La console, come abbiamo detto, permette la pubblicazione delle app sulla piattaforma Google Play, che può essere acceduta sia tramite browser web che attraverso la corrispondente app preinstallata su tutti i dispositivi che rispettano i requisiti di compatibilità fissati da Google. La piattaforma filtra automaticamente le applicazioni che sono compatibili con il dispositivo su cui l utente vuole installare l app selezionata. Fig La Developer Console di Google Play Il sistema operativo mobile Android è un sistema basato su Linux, sviluppato da Google insieme alla Open Handset Alliance, un consorzio di 84 marche aziendali produttrici di hardware e software, con lo scopo di rilasciare uno standard open-source per dispositivi mobili. Il sistema fu originariamente progettato dalla Android Inc. che inizialmente fu finanziata, e poi nel 2005 acquisita, da Google. Android fu presentato nel 2007, insieme con la fondazione del consorzio, ed opera sotto la licenza Apache. Incaricato del mantenimento e dello sviluppo del sistema è l AOSP (Android Open Source Project) guidato da Google. Per Android molte sono le app sviluppate da sviluppatori indipendenti che estendono le funzionalità dei dispositivi. Il primo Pag. 36

38 telefono portatile con sistema operativo Android fu rilasciato nell ottobre del 2008 e, alla fine del 2010, Android era diventata la principale piattaforma per smartphone. Nel terzo quadrimestre del 2012 vi erano 500 milioni di dispositivi e 1,3 milioni di attivazioni al giorno, con una fetta di mercato pari al 68% 7. Un grosso vantaggio di Android è la flessibilità; trattandosi di un software open-source, infatti, esso è estremamente personalizzabile dalle case produttrici di device e pertanto può essere utilizzato su molti altri dispositivi elettronici oltre agli smartphone ed ai computer tablet, compresi laptop, netbook, e- books reader e persino smart TV e lettori CD e DVD. Una delle ultime applicazioni di Android riguarda i display montati su occhiali per la realtà aumentata (il cosiddetto Project Glass di Google) Fig L HTC Evo 4G con Android Le app per Android sono scritte in una versione personalizzata di Java (nel senso che sfruttano come libreria una versione ridotta e modificata della libreria standard del Java, la libreria android appunto) ma vi sono anche estensioni per lo sviluppo in C o C++. L ambiente di sviluppo standard è rappresentato dall Android Software Development Kit (SDK), anche se ne esistono di ulteriori, come Google App Inventor, un ambiente visuale semplificato su web. Questo SDK comprende l Android Virtual Device (AVD) Manager, che consiste in un gestore di macchine virtuali che simulano dispositivi Android e possono essere utilizzate in fase di sviluppo, per effettuare test in mancanza di dispositivi reali. Un altra caratteristica fondamentale di Android è il multitasking 8, che è stato migliorato con il rilascio della versione 4.0, Ice Cream Sandwich. Quando gli utenti tengono premuto il pulsante home dei dispositivi (o il pulsante apposito per il multitasking per quelli che lo supportano) verrà visualizzato un task manager con una lista delle applicazioni in pausa in background, che gli utenti possono selezionare per riprenderne l esecuzione. Oltre alle applicazioni è permessa l esecuzione di diversi tipi di servizi in background, servizi che possono essere sviluppati come parte di altre app Pag. 37

39 (come AlarmService nel caso di Healthcare Mobile) o come applicazioni indipendenti che vengono automaticamente eseguite all avvio del dispositivo o in occasioni definite dal progettista. Vediamo adesso come viene gestita la sicurezza all interno del sistema operativo Android. Per prima cosa, tutte le app vengono eseguite in una sandbox, ovvero un area isolata del sistema operativo che non dà accesso al resto delle risorse del sistema, a meno che permessi specifici non vengano garantiti dall utente all atto dell installazione. Google Play mostra preventivamente all utente tutti i permessi richiesti dall applicazione per operare (ad esempio un gioco potrebbe avere bisogno di attivare autonomamente la vibrazione, ma non di leggere messaggi o accedere alla rubrica). Dopo aver letto i permessi richiesti, l utente può decidere se installare o meno l applicazione. I due sistemi, quello di sandboxing e quello dei permessi, riducono l impatto dei bug e delle vulnerabilità di sicurezza nelle applicazioni. Tuttavia, molto spesso, l inesperienza degli sviluppatori (che devono specificare i permessi richiesti dalle loro applicazioni all interno del file manifest contenuto nel progetto Android) e la documentazione limitata hanno portato molte applicazioni a richiedere permessi inutili, riducendo l efficacia del sistema di protezione che comunque non impedisce l esecuzione di codice non autorizzato all interno di funzioni che sfruttano i permessi accordati dall utente. Un altro difetto del sandboxing è che esso riduce l efficacia di tutte le app sviluppate per fungere da antivirus, in quanto esse non possono accedere alle risorse di sistema Il server web Oracle Glassfish Fig Schermata di installazione app su Android con la lista dei permessi richiesti Il server web Glassfish, sponsorizzato dalla Oracle Corporation, è un application server open-source, inizialmente creato dalla Sun Microsystems per la piattaforma Java EE. Pag. 38

40 Questo server è rilasciato sotto due licenze free software: la CDDL (Common Development and Distribution License) e la GPL (GNU General Public License). Glassfish è l implementazione di riferimento della piattaforma Java EE e come tale supporta gli Enterprise JavaBeans, le Java Server Pages (JSP) il Java Message Service (JMS) le servlet, ecc.. Questa sua caratteristica permette agli sviluppatori di creare applicazioni enterprise che siano portabili e scalabili, nonché integrabili con tecnologie di tipo legacy. Glassfish utilizza infatti un derivato del server web HTTP Apache Tomcat come contenitore di servlet che include a sua volta un componente chiamato Grizzly, che sfrutta l API Java New I/O (NIO) per permettere maggiori scalabilità e velocità. Glassfish è incluso anche nel tool di sviluppo Java NetBeans IDE, dal quale può essere configurato ed avviato, per testare e pubblicare le applicazioni realizzate. Esso mette a disposizione una console di amministrazione, accessibile normalmente dalla porta 4848, che permette di gestire il server Le servlet Una servlet è una classe del linguaggio di programmazione Java usata per estendere le funzionalità di un server. Benché le servlet siano generalmente in grado di rispondere ad ogni tipo di richieste, esse vengono comunemente utilizzate per estendere le applicazioni ospitate dai server web, tanto che esse possono essere pensate come delle Applet Java eseguite su server anziché su browser web. Le servlet sono la controparte Java delle tecnologie per contenuto web dinamico non-java, come ad esempio il PHP e l ASP.NET. Tecnicamente parlando, come già accennato, una servlet è una classe Java contenuta nella piattaforma Java EE, che si conforma alle API Java Servlet (del package javax.servlet) un protocollo attraverso il quale una classe Java può rispondere a delle richieste. In linea di principio, le servlet possono comunicare attraverso un qualsiasi tipo di protocollo client-server, ma sono molto spesso utilizzate con il protocollo HTTP. Pertanto, la parola servlet è spesso usata con il significato di HTTP servlet. Uno sviluppatore software potrebbe sfruttare una servlet per aggiungere contenuto dinamico ad un server web, utilizzando la piattaforma Java. Il contenuto generato è comunemente HTML, ma potrebbe anche trattarsi di un altro tipo di contenuto, come Pag. 39

41 ad esempio codice XML. Le servlet sono stateful, nel senso che possono mantenere lo stato all interno di variabili di sessione, attraverso diverse transazioni con il server, utilizzando ad esempio cookie HTTP o la riscrittura dell URL. Una servlet funziona ricevendo una richiesta e generando la relativa risposta. Per pubblicare ed eseguire una servlet, deve sempre essere utilizzato un web (o servlet) container. Un contenitore web è essenzialmente il componente del server web che interagisce con le servlet; esso è responsabile della gestione del ciclo di vita di queste ultime, mappando un URL ad una particolare servlet (generalmente essa è costituita, come altre applicazioni web, da un singolo file: un archivio WAR) ed assicurando che il richiedente dell URL abbia i diritti di accesso corretti. Sono proprio le API Java Servlet a definire le interazioni attese tra queste ed il contenitore web. All interno di tali API sono presenti oggetti che rappresentano sia le richieste che le risposte, oltre a quelli che rappresentano i parametri di configurazione della servlet e il suo ambiente di esecuzione. La differenza essenziale tra le servlet e le pagine JSP (Java Server Page) è che le servlet tipicamente includono, all interno del loro codice Java, codice HTML, che in genere fa parte della risposta della servlet; al contrario, le pagine JSP contengono codice Java all interno del loro codice HTML. Le servlet presentano diversi vantaggi rispetto alla tradizionale CGI (Common Gateway Interface): Quando viene fatta una richiesta HTTP, si crea un nuovo processo per ogni chiamata allo script CGI. Questa eccessiva creazione di processi comporta un notevole consumo delle risorse di sistema, specialmente quando lo script CGI esegue operazioni relativamente veloci. Pertanto, la creazione dei processi può arrivare a richiedere più tempo rispetto all esecuzione dello script stesso. Le servlet Java risolvono questo problema generando e gestendo un thread Java separato per ogni richiesta in arrivo, all interno dell unico processo del server web, omettendo pertanto la fork di processi separati operato dal daemon HTTP del server. Pag. 40

42 Richieste simultanee causano la copia ed il caricamento in memoria dello script CGI tante volte quante sono le richieste. Viceversa, con le servlet, vi sono tanti thread quante sono le richieste, ma vi sarà una sola copia della classe servlet creata in memoria e che ivi risiede; Lo script CGI non può, come le servlet all interno del loro contenitore, essere eseguito in un ambiente protetto (una sandbox). Le servlet sono simili alle applet (le quali vengono eseguite nella sandbox del browser web). Questa caratteristica delle servlet ne garantisce la sicurezza, rendendo possibile un uso restrittivo di quelle potenzialmente dannose. Le servlet sono differenti rispetto alle applet, ma possiedono molte caratteristiche in comune. In generale, si definisce applet una piccola applicazione che effettua un compito specifico all interno di un programma più grande, normalmente un plug-in. Le applet vengono impiegate, come le servlet, per fornire funzionalità interattive alle applicazioni web, funzioni che non potrebbero essere fornite dall HTML da solo. Le Applet Java (che chiameremo nel seguito semplicemente applet) vengono eseguite, come le servlet, all interno di una sandbox, ma anziché sul server, la sandbox è inclusa nel browser web del client. Essa fa sì che le applet non possano accedere alle informazioni salvate in locale sul computer client, rendendole così più sicure, ma limitandone nel contempo le funzionalità. Un altro vantaggio è la loro possibilità di essere eseguite sui browser delle principali piattaforme poiché, essendo scritte in bytecode Java, sono cross-platform, ovvero indipendenti dalla piattaforma su cui vengono eseguite. L uso delle applet non esclude l uso delle servlet, poiché un applet può facilmente comunicare dal browser del client con una servlet residente su un server. Le applet funzionano come interfacce utente: possono catturare l input da mouse ed avere controlli come bottoni o check box; in risposta all azione dell utente l applet può poi variare il proprio contenuto grafico. Tuttavia, esse hanno poco controllo sul contenuto della pagina web al di fuori dell area a loro dedicata e sono per questo meno utili per migliorare l apparenza del sito in generale. Il motivo per cui si è optato per l utilizzo di pagine JSP nel sito Healthcare Web, piuttosto che sfruttare un applet è dovuto al fatto che le pagine JSP sono più leggere Pag. 41

43 da eseguire nel browser rispetto alle applet, in quanto queste ultime richiedono l installazione preventiva della JVM (Java Virtual Machine) Il database MySQL Per fornire le funzionalità di archiviazione dei dati nel sistema sviluppato è stato scelto MySQL. MySQL è uno degli RDBMS (Relational DataBase Management System) più usati; esso viene eseguito come un server per fornire accesso multi-utente ad un certo numero di database. SQL sta per Structured Query Language, un linguaggio ampiamente sfruttato dai sistemi di gestione dei database per accedere ai dati in essi contenuti, nonché per modificarne la struttura (il database schema). MySQL è disponibile sotto i termini della licenza GPL, ma anche sotto una varietà di accordi proprietari e, benché inizialmente sponsorizzato dalla svedese MySQL AB, è adesso di proprietà della Oracle Corporation. Questo RDBMS è molto usato per le applicazioni web ed è un componente centrale dell insieme del software per applicazioni web open-source cosiddetto LAMP (Linux, Apache, MySQL, Perl/Phyton/PHP). MySQL è usato in molti prodotti di larga scala del World Wide Web, inclusi Wikipedia, Facebook, Google e molti altri. MySQL non è dotato di un interfaccia grafica (la cosiddetta GUI ovvero Graphical User Interface) per la sua amministrazione e per la gestione dei dati nei database, ma solo strumenti gestibili da linea di comando. Un alternativa quindi può essere quella di affidarsi a software desktop o applicazioni web esterni per creare e gestire i database MySQL, per costruirne la struttura, per effettuare il backup e la gestione dei dati e per ispezionarne lo stato. L insieme di strumenti ufficiale per MySQL è il MySQL Workbench 9, attivamente sviluppato dalla stessa Oracle e disponibile gratuitamente per l utilizzo. MySQL Workbench, disponibile nella versione gratuita ed open-source Community Edition o nella versione proprietaria Standard Edition, che migliora ed estende le funzionalità della prima con alcuni moduli aggiuntivi, mette a disposizione dell utente molte funzionalità: Pag. 42

44 Permette di disporre di un interfaccia grafica dalla quale connettersi con i database e gestire le loro istanze; Permette di costruire lo schema di ciascun database, ovvero le tabelle e le relazioni tra di esse, in maniera visuale, tramite drag-and-drop; Permette di ricavare diagrammi ER dei database e di stamparli; Permette di scrivere query SQL, mettendo però a disposizione anche delle funzioni predefinite, ad esempio per ottenere il contenuto di una tabella o per crearla; Permette di avviare o fermare diverse istanze di un database, nonché di configurare queste ultime e gli account per accedervi; Permette di effettuare dump dei database e di importarli; Fornisce un interfaccia per la consultazione dei file di log; Permette la migrazione dei database verso altri RDBMS, come Microsoft SQL Server o PostgreSQL. Dalla sua introduzione, MySQL Workbench è divenuto molto popolare nella comunità MySQL, tanto da imporsi come il secondo prodotto più scaricato dal sito di MySQL, con più di 250,000 download al mese. Prima che ciò accadesse fu votato come Tool per database dell anno nel 2009 su Developer.com 10. Proprio grazie a tutte queste sue funzionalità, questo strumento è estremamente conveniente per la gestione dei database ed è stato pertanto impiegato nel progetto per la creazione e la gestione del database telemedicina. Pag. 43

45 5. SICUREZZA Il termine sicurezza informatica indica la protezione dell informazione e dei sistemi informativi da accessi, utilizzi, modifiche, registrazioni o distruzioni non autorizzate. Lo scopo della sicurezza informatica è dunque quello di garantire cinque punti fondamentali: La confidenzialità: ovvero tutte le misure messe in atto per prevenire la diffusione di informazione verso individui o sistemi non autorizzati (ad esempio, durante una transazione online con carta di credito, ciò avviene se una terza parte non autorizzata riesce ad ottenere il numero della carta in un qualsiasi modo); L integrità: ovvero tutte le misure messe in atto a garantire che i dati non vengano modificati senza che tale modifica venga rilevata; l integrità viene violata quando un messaggio viene modificato attivamente mentre transita attraverso un canale di comunicazione, come ad esempio la rete Internet; La disponibilità: affinché un sistema informativo svolga la propria funzione, l informazione deve essere sempre disponibile quando viene richiesta; questo significa che i sistemi elettronici utilizzati per memorizzare ed elaborare l informazione, i sistemi di controllo utilizzati per proteggerla ed i canali di comunicazione, utilizzati per accedervi, devono funzionare in maniera corretta. Ciò implica che i sistemi in questione devono risultare disponibili in ogni momento, prevenendo eventuali disservizi causati da mancanza di energia elettrica, guasti hardware o upgrade di sistemi, oltre che essere dotati di misure atte a proteggerli da attacchi mirati a negare la disponibilità del servizio, detti denial-of-service (DoS) attacks; L autenticità: indica tutti i sistemi utilizzati per assicurare che le transazioni, le comunicazioni ed i messaggi, sia quelli elettronici che quelli fisici, siano genuini, verificando che entrambe la parti coinvolte siano effettivamente quelle che dichiarano di essere; Pag. 44

46 La non ripudiabilità: tutti i metodi utili ad impedire la ripudiabilità dei messaggi; si dice che una parte coinvolta in una comunicazione la ripudia quando nega di avervi preso parte, ovvero afferma di non aver ricevuto, od inviato, un certo messaggio transitato sul canale di comunicazione. I sistemi più importanti volti a garantire autenticità e non ripudiabilità sono la firma digitale e la cifratura a chiave pubblica. Oltre ai cinque punti sopra descritti, ne sono stati proposti altri, fino ad arrivare ai 33 principi proposti dal NIST 11 (National Institute of Standards and Technology, un agenzia del governo americano mirata alla definizione di standard tecnologici). La sicurezza informatica ha assunto sempre maggiore importanza con l avvento di Internet: in precedenza i computer costituivano sistemi isolati, o al più erano collegati tramite Intranet: l unica precauzione necessaria era dunque quella di proteggere l accesso ai terminali. Con Internet invece la situazione è diventata molto più complessa: si hanno reti di calcolatori molto estese geograficamente, le informazioni vengono trasmesse su lunghe distanze e l accesso alle reti locali è diventato possibile anche da computer remoti, rendendo quindi necessario sia proteggere le informazioni in transito sulla rete, mediante ad esempio tecniche di cifratura delle stesse, che ricorrere a misure di autenticazione più avanzate per l accesso a server e reti locali. Istituzioni governative, militari, finanziarie, gli ospedali e le imprese private conservano grandi quantità di informazioni confidenziali riguardo i loro impiegati, i loro clienti, i loro prodotti, le loro ricerche e le informazioni di tipo finanziario all interno di computer, che si occupano di archiviarle, di elaborarle e di trasmetterle attraverso la rete ad altri computer. Ovviamente se queste informazioni confidenziali, ad esempio il progetto di un nuovo prodotto da lanciare sul mercato, dovessero finire nelle mani di un concorrente dell azienda, una tale breccia nella sicurezza potrebbe comportare conseguenze molto negative. Pertanto risulta indispensabile, come requisito etico (ma anche legale, come abbiamo visto nel capitolo 2) proteggere i dati sensibili. Pag. 45

47 5.1. Vulnerabilità del sistema e soluzioni Il sistema progettato è dotato (o si presta all adozione) di alcune misure di sicurezza mirate a risolvere alcune vulnerabilità: Quando l utente inserisce dati personali all interno dell app per Android, tali dati vengono memorizzati sul dispositivo e possono essere visualizzati da chiunque riesca ad avere accesso ad esso; Un soggetto non autorizzato potrebbe inviare dati da un dispositivo già associato, spacciandosi per l utente legittimo, o da un client creato ad-hoc; Durante la trasmissione, i dati possono essere intercettati, o modificati, da un soggetto non autorizzato (il problema del man-in-the-middle ); Potrebbe essere sferrato un attacco contro il server web, sia tramite un browser web che attraverso un programma creato ad-hoc dall attaccante, con lo scopo di renderlo inaccessibile oppure per ricavare da esso i dati contenuti nel database; Persone autorizzate all accesso al database potrebbero visualizzare dati a loro preclusi e farne un uso improprio Sicurezza dei dati nel dispositivo mobile Il problema forse più immediatamente visibile è quello di proteggere il dispositivo mobile, su cui viene eseguita l app, da accessi non autorizzati. Facendo l esempio dei device Android, i dati vengono salvati in una sandbox la quale, come abbiamo detto, non è accessibile al di fuori dell app che ne è proprietaria. Purtroppo, ciò è vero per tutti quei device che hanno un sistema operativo originale, che in genere non permette di accedere alle cartelle dedicate alle app senza i permessi di superuser, o amministratore (non forniti all utente). L utente ha comunque la facoltà di cambiare il sistema operativo installato sul device e questa azione, molto diffusa, è spesso volta ad effettuare il rooting del dispositivo, ovvero ad ottenerne i diritti di super-utente, per poterne sfruttare al massimo tutte le potenzialità, esponendo però i dati ad un notevole rischio di sicurezza (causa la loro disponibilità a chiunque abbia accesso al dispositivo). Pag. 46

48 È pertanto responsabilità dell utente del dispositivo provvedere alla sicurezza dei dati, non esponendoli a tali rischi. La maniera generalmente più sicura per proteggere tutti i dati su dispositivo, indipendentemente dal rooting, è quella di impostare l inserimento di un PIN o di una password, ogni volta che si accende o si sblocca il dispositivo. Ciò ovviamente può solo essere consigliato all utente, ma non imposto. Da parte sua lo sviluppatore potrebbe prevedere qualche sistema di cifratura simmetrica dei dati, attraverso una chiave privata inserita come variabile nel codice dell app; tale metodo non è però sicuro rispetto alla decompilazione dell app con tecniche di reverse engineering, al fine di ricavarne la chiave. Come si vede quindi il problema della sicurezza sui dispositivi è affidato, come peraltro la conservazione della password personale, al giudizio dell utente del sistema Hacking del client Un altro problema importante è quello che si verifica quando una persona non autorizzata si finge un utente autorizzato del sistema. Se una persona riesce ad accedere ad un dispositivo mobile con app già associata al server (ovvero tale che un utente legittimo abbia già inserito il proprio ID e la propria password e che queste siano già state verificate dal server) può facilmente accedere ai dati salvati in locale, visualizzandoli direttamente dall app e senza dover accedere alle cartelle di sistema, nonché di inviarli al server (non sarebbe comunque possibile modificarli od eliminarli, poiché, per ovvie ragioni di sicurezza, non sono stati definiti comandi a tale scopo nel protocollo di comunicazione tra l applicazione mobile e la servlet). Per risolvere il problema della visualizzazione dei dati personali basterebbe modificare l app in modo da richiedere la password tutor anche per accedere al diario delle misurazioni, cosicché, chi non ne fosse in possesso, non potrebbe visualizzare queste ultime. Ovviamente questo costituirebbe un ostacolo nel caso in cui paziente e tutor fossero due persone diverse, in quanto il paziente non potrebbe più visualizzare il diario senza la password del tutor e ciò causerebbe un problema quando, ad esempio, egli volesse rimuovere una misurazione sbagliata. Per quanto riguarda invece il problema dell invio dei dati, basterebbe richiedere all utente la password (o l id) del proprio account sul server, ogniqualvolta egli volesse inviare una misurazione. I due Pag. 47

49 metodi, insieme, risolvono questa debolezza dell app, ma riducendone nel contempo l usabilità. Un ulteriore problema riguarda la creazione di un client fittizio per la comunicazione con il server: evidentemente esso non sarebbe realizzabile perché, anche se per un attaccante è facile accedere ai comandi del server e ai loro parametri avendo un account legittimo (basterebbe leggere il sorgente di una pagina JSP e vedere i valori degli attributi, e in particolare quello dell attributo command, associati alle richieste POST) è comunque sempre necessario associare a tali comandi il valore dell attributo id dell utente di cui si vogliono modificare, o accedere, i dati. Pertanto, se l ID dell utente non è noto, l attaccante non ha possibilità di sferrare un tale attacco e questo è un motivo in più perché l utente abbia cura della segretezza del proprio codice Il problema del man-in-the-middle e l HTTPS Un altro problema rilevante che può presentarsi nel sistema è quello della potenziale insicurezza dei dati trasmessi via web. I dati vengono trasmessi sulla rete sotto forma di pacchetti e l unico modo per proteggerli consiste nello sfruttare tecniche di crittografia degli stessi (sarebbe infatti improponibile utilizzare altri metodi di controllo dei flussi in transito sulla rete, vista la quantità di dati che viene scambiata oggigiorno). Ovviamente è necessario considerare che, benché i sistemi crittografici prevengano l appropriazione indebita dei dati e che altri sistemi, come il checksum dei pacchetti, ne impediscano la modifica, essi non eliminano la possibilità della loro distruzione, né della loro replicazione. Uno dei tipi più comuni di attacco nella trasmissione dei dati è il cosiddetto MITM (Man-In-The-Middle attack). Come dice il nome, è una forma di intercettazione nella quale l attaccante si trova in mezzo al canale di comunicazione, tra i due soggetti coinvolti in essa. Egli crea connessioni indipendenti con le vittime e rilascia messaggi tra di loro, facendo credere loro che stiano parlando in maniera diretta in una connessione privata, mentre di fatto la conversazione è controllata dall attaccante. Per portare a termine questo tipo di attacco, l attaccante deve essere in grado di intercettare tutti i messaggi che passano dal mittente al ricevente e di iniettarne dei Pag. 48

50 nuovi da lui creati nel canale di comunicazione. Questo attacco, che può sembrare difficile, è in realtà molto facile da mettere in atto in reti poco protette (come punti di accesso Wi-Fi non cifrati o con sistemi di protezione deboli, come il protocollo Wired Equivalent Privacy, o WEP) e ha successo solo quando l attaccante riesce ad impersonare entrambi gli endpoint della comunicazione, in maniera tale da convincerli reciprocamente. Alcuni protocolli crittografici includono qualche forma di autenticazione degli endpoint, per prevenire questo tipo di attacco; esempi sono il Secure Socket Layer (SSL) ed il Transport Layer Security (TLS). Nel progetto, tali protocolli sono stati utilizzati assieme al protocollo HTTP per consentire l autenticazione di client e server. L HTTPS 12 (HyperText Transfer Protocol over Secure Socket Layer) è un protocollo di comunicazione sicura su una rete di computer, ottenuto stratificando il protocollo HTTP al di sopra del protocollo SSL/TLS, per aggiungere funzionalità di sicurezza. L HTTPS fornisce la cifratura bidirezionale delle comunicazioni tra un client ed un server, per proteggere dall intercettazione, dalla modifica dei messaggi in transito e dalla creazione di messaggi falsi. Come abbiamo detto, l HTTPS consiste nell uso del normale protocollo HTTP su una connessione cifrata con SSL/TLS; questo significa che vengono cifrati l URL del server o della pagina web a cui il client intende accedere, i parametri delle query, gli header e i cookie (che spesso contengono informazioni relative all utente). Tuttavia, poiché l URL e i numeri di porta sono parte dei protocolli TCP/IP sottostanti, l HTTPS non protegge contro la loro diffusione. Questo significa, in pratica, che un attaccante può comunque inferire l indirizzo IP e il numero di porta del servizio web (in alcuni casi anche il nome di dominio), ma non il resto dell URL. L attaccante può inoltre ottenere l ammontare di dati trasferiti e la lunghezza della sessione di comunicazione. Ciò nonostante, egli non riesce ad accedere al contenuto della comunicazione, rendendo l HTTPS un protocollo molto sicuro da usare (tuttavia, e ne parleremo nei prossimi paragrafi, esso non protegge il sistema progettato da attacchi portati a termine da utenti che hanno account validi: per questi attacchi sono necessarie ulteriori misure di protezione). In particolare, esso protegge i dati anche durante il transito verso un access point Wi-Fi non protetto mediante cifratura ed è quindi in grado di evitare lo sniffing Pag. 49

51 (intercettazione dei pacchetti nell etere) da parte di terzi che si trovano all interno della stessa LAN. L HTTPS si differenzia dall HTTP anche per il fatto di utilizzare di default la porta 443, anziché la porta 80, per la comunicazione. Nel nostro caso, per consentire all HTTPS di proteggere tutti i dati destinati al server web è stato necessario fornire l accesso al sito Healthcare Web totalmente attraverso questo protocollo, evitando di avere contenuti, ovvero pagine web, scoperte. Infatti, ogni volta che al sito viene fatto accesso mediante HTTP, anziché con HTTPS, i dati sull utente e sulla sessione risultano esposti ed utilizzabili per attacchi. Inoltre, almeno una delle due parti della comunicazione deve essere autenticata (in genere il server, ma può esserlo anche il client) tramite certificati. Il certificato costituisce la parte sensibile del protocollo. In generale un certificato deve essere verificato dal browser web e creduto dall utente, il quale può leggere le informazioni relative al certificato che gli vengono fornite dal browser. Un certificato a chiave pubblica può essere sempre firmato da chi ha creato un sistema web in maniera autonoma, senza passare da un autorità certificante (come VeriSign). In quel caso il browser web avvisa l utente che il certificato non può essere verificato e la decisione se dare o meno credito alla connessione protetta passa del tutto nelle mani dell utente. In generale, un utente dovrebbe dare credito ad una connessione HTTPS solo se: L utente ha fiducia che il browser implementi correttamente l HTTPS con le autorità certificanti correttamente pre-installate (i certificati installati nel browser servono a quest ultimo per effettuare la verifica del certificato fornito da un sito); L utente crede che l autorità certificante sia affidabile, ovvero pubblichi siti legittimi; Il certificato identifica il sito in maniera corretta (ci si aspetta ad esempio che, visitando il sito il certificato del sito riporti nel campo azienda Microsoft Inc. o un nome simile e non un altra entità); Ritiene che le parti coinvolte nella comunicazione siano credibili o che il metodo di cifratura SSL/TLS sia sufficientemente sicuro contro le intrusioni. Pag. 50

52 Nel presente progetto, il protocollo TLS 13, che è stato impiegato perché più nuovo rispetto all SSL, è stato utilizzato per cifrare sia le risposte HTTP della servlet, che le richieste provenienti dalle pagine web del sito Healthcare Web e dall app Healthcare Mobile. Il protocollo utilizzato è sempre di tipo one-way, ovvero il server, fornisce un certificato a garanzia della propria autenticità, mentre il client si occupa solo di verificarla. Nel caso del client Healthcare Web, sarà il browser ad accertarsi di possedere il certificato tra le proprie autorità certificanti pre-installate; se così non è, visualizza il messaggio di avviso all utente, il quale può verificare che il certificato sia corretto semplicemente visionando i suoi campi. Per quanto riguarda il client Healthcare Mobile, quando l app si collega al server e riceve da lui il certificato durante la fase di handshaking iniziale (ovvero la fase di scambio dei certificati, di accordo tra le parti) verifica che il certificato ottenuto dal server sia contenuto all interno del proprio keystore (il suo portachiavi ) e, se lo trova, autorizza la connessione. Il keystore è un archivio di certificati, protetto da password, che si può presentare in diversi formati: quello supportato da Android è il formato BKS (Bouncy castle KeyStore) fornito nella collezione di API per la crittografia Bouncy Castle 14, mentre il server Glassfish utilizza il formato JKS (Java KeyStore). Il certificato nel keystore dell app viene importato dal server ed inserito all interno di esso in fase di sviluppo; a sua volta il keystore deve essere inserito nella cartella delle risorse di tipo grezzo (raw resources) dell app, ovvero res/raw, che è la cartella dove l app, una volta compilata ed eseguita, andrà a ricavare il certificato per confrontarlo con quello ricevuto dal server e per accertarne l autenticità. Pag. 51

53 Fig Schema di comunicazione client-server con protocollo SSL one-way Il protocollo one-way si differenzia da quello two-ways, nel quale sia il client che il server forniscono alla controparte un certificato, che quest ultima verifica. Chiaramente questo protocollo sarebbe più sicuro in quanto permetterebbe di riconoscere l autenticità anche del client, non solo del server, ma risulta inutile nel nostro caso in quanto al server web non interessa tanto sapere come o da dove (cioè da quale dispositivo) vengono inseriti i dati ma da chi vengono inseriti; per fornire la garanzia sull identità dell utente esiste però già l ID personale, che accompagna ogni richiesta al server. Per la sua sicurezza, l HTTPS è molto usato nel World Wide Web, specialmente per le transazioni di pagamento o comunque sensibili, anche se negli ultimi anni il suo utilizzo è aumentato anche per proteggere l autenticità delle pagine e per rendere sicuri gli account degli utenti e la loro identità durante la navigazione sul web. Ciò nonostante, secondo un indagine condotta da Qualys SSL Server Test (un sito all interno del quale chiunque può verificare la qualità dell implementazione dell HTTPS per un server web specificato) solo il 13,6% dei siti Internet più popolari disponevano, ad ottobre 2012, di un implementazione sicura del protocolli Attacchi di tipo injection al server web Un altra tipologia di attacchi a cui è necessario prestare attenzione, poiché oggigiorno molto diffusi e poiché facilmente attuabili anche da coloro che non dispongono di un Pag. 52

54 account legittimo per accedere al server, è quella dei cosiddetti attacchi di tipo injection. Nel caso del nostro sistema essi potrebbero essere effettuati a partire dal sito Healthcare Web se non si predispongono adeguate misure di protezione. Si definisce iniezione di codice (o code injection) lo sfruttamento, da parte di un potenziale attaccante, di un bug del server causato dall elaborazione di dati non validi. L attacco viene attuato introducendo ( iniettando ) in un programma, ma anche su un sito web, del codice tale da poterne cambiare il corso di esecuzione. I risultati del code injection sono disastrosi, poiché possono portare alla distruzione dei dati sul database, o comunque alla loro modifica, e al crash del server. Esistono diverse tipologie di iniezione di codice, a seconda del linguaggio con cui è scritto il codice stesso. Esempi sono l SQL e l HTML injection. Un attacco del genere viene effettuato sfruttando i campi di testo utilizzati per inserire un input sul sito, che sono presenti in gran numero praticamente in tutti i siti web (basti pensare alle schermate di login, ma anche al campo per ricercare del testo su un motore di ricerca). Sorprendentemente, possono essere anche utenti normali ad effettuare inavvertitamente un tale tipo di attacco, ogniqualvolta inseriscono nei campi di testo dei caratteri che a loro sembrano innocui, ma che possono attivare dei bug non appena l input viene elaborato dal software su un server in genere perché tali simboli sono parte della sintassi del linguaggio con cui è scritto il server web. Poiché tali bug sono difficilmente rilevabili dal progettista, in quanto si possono verificare nelle situazioni più imprevedibili, non è consigliabile cercare di prevedere tutte le condizioni sotto le quali essi si verificano; risulterebbe una strategia migliore, invece, quella di effettuare un filtraggio di tutto l input che arriva al server web dall utente e di scartare quello non valido. Nel caso specifico, il sito Healthcare Web risulta particolarmente sensibile all SQL injection, perché il server web sfrutta comandi SQL per l inserimento dei dati nel database MySQL. Prendiamo come esempio la seguente query: SELECT * FROM dati_clinici_pazienti WHERE _id= ABCD123456' Pag. 53

55 dove ABCD è, in questo caso, l ID che viene inserito dal paziente nel momento del login. Questa funzione è utilizzata dalla servlet per ricavare tutti i dati clinici relativi al paziente con ID personale ABCD dal database e i risultati della query vengono presentati all utente nella schermata successiva. Supponiamo adesso che l utente voglia accedere a tutti i dati sul database, compresi quelli di altri pazienti. Se anziché scrivere ABCD nel campo dedicato all id nella schermata di login, egli inserisse il codice ' OR '1'='1, che risulterebbe essere valido, la query diventerebbe: SELECT * FROM dati_clinici_pazienti WHERE _id= ' OR '1'='1 ' che equivarrebbe a selezionare i dati di tutti i pazienti che hanno id uguale a (nessuno) oppure a tutti quelli per cui vale 1 = 1 (siccome lo statement è sempre vero, tutti i pazienti). A questo punto all attaccante verrebbero visualizzati i dati di tutti i pazienti. Si noti che il primo apice serve solamente a terminare la query presente nel codice della servlet ed una volta chiuso lo statement, l attaccante è libero di aggiungere tutto il codice SQL che desidera, potendo quindi effettuare moltissime azioni potenzialmente dannose. Come si nota, non è necessaria una profonda conoscenza del linguaggio di programmazione usato per scrivere il codice della servlet per effettuare un simile attacco, anche perché i database SQL sono molto usati oggigiorno. Una breccia nella sicurezza del genere non è chiaramente tollerabile in sistemi che devono gestire dati sensibili. Il problema, per quanto rilevante, può essere facilmente risolto predisponendo un controllo sull input, all interno del codice della servlet; nel nostro caso questa funzione è svolta dalla classe InputController, ed in particolare dal metodo check, che viene richiamato subito prima di elaborare l input, con il codice: if(!inputcontroller.check(this, request.getparametermap())) { displaymessage(request, response, "I CARATTERI: " + InputController.NOT_ALLOWED_CHARS + " NON SONO AMMESSI NEI CAMPI DI INPUT!", "index.html"); return; } Nel codice di cui sopra viene ottenuta la mappa di tutti i parametri della richiesta, qualunque essa sia, ovvero dei campi di input allegati ad essa. I caratteri di tali campi Pag. 54

56 vengono confrontati uno ad uno con tutti i caratteri della stringa InputController.NOT_ALLOWED_CHARS, ovvero la lista dei caratteri non ammessi. Se anche uno solo dei campi contiene un carattere non ammesso, in genere apici, parentesi, virgolette, punti e virgola, ecc., il comando viene rifiutato e viene visualizzato un messaggio di errore. Fig Errore generato dall'inserimento di caratteri non validi (in qualsiasi campo di testo) Protezione dei dati sul database e hashing delle password Un altro problema rilevante è quello della prevenzione degli accessi non autorizzati al database: tali accessi possono essere effettuati attraverso il server web che gestisce la comunicazione con il database sia da persone non autorizzate che da persone autorizzate, le quali però accedono a dati che sarebbero a loro preclusi. Analizziamo i metodi impiegati per risolvere il primo problema, ovvero quello di un accesso non autorizzato al database. Operatori e pazienti hanno a disposizione tre elementi per la loro autenticazione: un ID personale, una password ed un account e- mail. La sicurezza deriva proprio dal fatto che, per accedere, sono sempre necessari almeno due di questi elementi: se anche un utente non autorizzato avesse scoperto una password, necessiterebbe comunque dell id relativo per accedere al sistema e se invece possedesse un id, avrebbe bisogno di accedere all account di posta dell utente per cambiare la sua password (dovrebbe quindi possedere anche la password dell account di posta). Ovviamente questo non garantisce la sicurezza assoluta, perché Pag. 55