U N I V E R S I TÀ D E G L I S T U D I D I F I R E N Z E Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Magistrale in Informatica

Transcript

1 U N I V E R S I TÀ D E G L I S T U D I D I F I R E N Z E Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Magistrale in Informatica Tesi di Laurea P R O G E T T O E R E A L I Z Z A Z I O N E D I U N L I N G U A G G I O F O R M A L E P E R I L C O N T R O L L O D E G L I A C C E S S I B A S AT O S U P O L I T I C H E andrea margheri Relatore: Prof. Rosario Pugliese Correlatore: Dott. Francesco Tiezzi Anno Accademico

2 Andrea Margheri: Progetto e realizzazione di un linguaggio formale per il controllo degli accessi basato su politiche, Corso di Laurea Magistrale in Informatica, Anno Accademico

3 Non trovare il difetto, trova il rimedio. Un sentito ringraziamento al Prof. Pugliese e al Dott. Francesco Tiezzi per avermi seguito e guidato nel mondo di XACML per tutti questi mesi di lavoro. Un sentito ringraziamento anche al Dott. Massimiliano Masi per il prezioso supporto durante il lavoro di tesi. Grazie alla mia famiglia per il supporto durante questi anni di studi e a tutti i colleghi del corso magistrale per due bellissimi anni assieme.

4

5 I N D I C E 1 introduzione 3 2 controllo degli accessi Modelli per il controllo degli accessi XACML Il processo di autorizzazione Il linguaggio delle politiche Standard collegati a XACML Caso di studio Il progetto epsos sintassi e semantica di xacml Sintassi di XACML Politiche e Insiemi di Politiche Regole Target Obbligazioni Richieste e Risposte Politiche del caso di studio Semantica di XACML Target Rule Policy e Policy Set Obligation e Advice Policy Enforcement Point Valutazione delle politiche del caso di studio Multiple Decision Profile un linguaggio formale per il controllo degli accessi Sintassi Traduzione delle politiche del caso di studio Semantica formale Target Obbligazioni Regole, Politiche e Insiemi di Politiche Policy Enforcement Point Valutazione formale delle richieste del caso di studio ambiente di valutazione e strumenti di sviluppo Ambiente di valutazione Test di conformità Strumenti di sviluppo

6 2 Indice Introduzione al framework Xtext Plugin per Eclipse Applicazione al caso di studio conclusioni Sviluppi futuri Lavori collegati a funzioni di match e linguaggio per le espressioni 91 b richieste d accesso per il caso di studio 95

7 1 I N T R O D U Z I O N E La diffusione di servizi web e di piattaforme di lavoro distribuite ha generato sistemi sempre più connessi e integrati tra loro. Per proteggere le informazioni sensibili, spesso gestite da questi sistemi, servono tra l altro strumenti adeguati per il controllo degli accessi. La grande attenzione riservata a queste tematiche, ha portato allo sviluppo di nuovi modelli e tecnologie per la gestione degli accessi. Un modello di controllo degli accessi è basato su regole d accesso che determinano, in base a varie tipologie di controlli, chi ha il permesso di fare certe azioni sulle risorse controllate. Nel corso degli anni sono stati proposti diversi modelli per far fronte alle problematiche emerse con lo sviluppo di nuove tecnologie, quali appunto i sistemi distribuiti su larga scala. L evoluzione dei modelli non ha apportato variazioni al tipo di accessi che si possono controllare, ma all espressività dei linguaggi per la definizione delle regole. I primi modelli di controllo erano basati su liste degli accessi, che associavano a ogni risorsa una lista con tutti gli utenti che potevano effettuare operazioni. L approccio era semplice, ma la quantità di dati da gestire era eccessiva, non permettendo al modello di scalare in sistemi di grandi dimensione. L introduzione del modello basato su ruoli, cioè l associazione di insiemi di risorse a soggetti raggruppati per ruolo, ha migliorato la scalabilità. La definizione dei ruoli ha però come difetto che le regole sono meno specifiche, quindi difficili da applicare per singole risorse. Maggiore flessibilità nella definizione delle regole di accesso è stata possibile con l introduzione del modello ad attributi, che definisce le regole sulla base di insiemi di caratteristiche di qualunque categoria, senza specializzarsi soltanto sui ruoli. Il modello ad attributi però non offre una buona scalabilità, dato che non c è una tecnica specifica di definizione e organizzazione delle regole. Questo ha portato al modello delle politiche, cioè a insiemi organizzati di regole su attributi. Attualmente, il modello basato su politiche è il più utilizzato. La necessità di integrazione e collaborazione tra sistemi ha portato alla richiesta di standard per la definizione del modello basato su politiche. Molti standard sono stati proposti e attualmente quello più utilizzato è extensible Access Control Markup Language (XACML), che fornisce un linguaggio per la 3

8 4 introduzione definizione delle politiche e i requisiti funzionali per una corretta valutazione delle stesse. L utilizzo di XML per la sintassi permette allo standard di essere applicato in svariati contesti, a discapito però di una facile specifica e manutenzione delle politiche. Inoltre, i requisiti funzionali, e più in generale il processo di valutazione degli accessi, sono descritti in linguaggio informale, prestandosi così a interpretazioni differenti su certi aspetti dei requisiti. Questo fatto è anche confermato dalla presenza di differenze in alcuni tool esistenti per la valutazione di politiche XACML. Sulla base delle suddette considerazioni è nata l idea del lavoro sviluppato in questa tesi: semplificare la scrittura delle politiche e definire una semantica formale per il processo di valutazione delle richieste d accesso rispetto alle politiche. Nel dettaglio, si propone un linguaggio fortemente basato su XACML, ma definito su una sintassi alternativa, che permette la definizione della semantica formale del processo di valutazione. L utilizzo della semantica formale elimina anche l ambiguità, introdotta dall utilizzo del linguaggio naturale, del documento di specifica dello standard XACML. Inoltre, la semantica offre anche la possibilità di definire controlli sulle politiche, per assicurarsi che l effetto globale definito dalle politiche sia effettivamente quello richiesto dai requisiti di sicurezza. La sola definizione del linguaggio non è però uno strumento utilizzabile in casi reali. Si è quindi deciso di definire un architettura Java che implementi il processo di valutazione e uno strumento di sviluppo per il supporto alla scrittura delle politiche. Il resto di questo documento è così organizzato. Nel Capitolo 2, dopo una breve introduzione ai modelli di controllo degli accessi, si descrive il modello delle politiche definito in XACML e il rispettivo processo autorizzativo. Per meglio descrivere le caratteristiche dello standard e del nostro linguaggio, si introduce, sempre nel Capitolo 2, un caso di studio medico ispirato a un progetto europeo per l integrazione di sistemi sanitari nazionali. Nel Capitolo 3 è presentato in dettaglio lo standard, sia negli aspetti sintattici che semantici. Nel Capitolo 4 si descrive il linguaggio alternativo e la semantica formale per il processo autorizzativo. L architettura di valutazione e gli altri strumenti di supporto sono invece illustrati nel Capitolo 5. Il documento si conclude poi con il Capitolo 6 dove sono riportati brevemente alcuni lavori collegati a XACML e i possibili sviluppi futuri del lavoro svolto.

9 2 C O N T R O L L O D E G L I A C C E S S I Il controllo degli accessi a risorse e servizi è un aspetto fondamentale in ogni architettura software, al fine di assicurare l integrità e la sicurezza dei dati. Standard e architetture specifiche sono stati sviluppati nel corso degli anni, rendendo quest area di ricerca sempre in continuo sviluppo. Per meglio comprendere il problema del controllo degli accessi descriviamo nella sezione seguente l evoluzione storica dei modelli di controllo e successivamente presentiamo in dettaglio il modello basato su politiche utilizzato dallo standard extensible Access Control Markup Language (XACML). A seguire, è introdotto il caso di studio che sarà utilizzato in tutto il resto della tesi per esemplificare gli argomenti trattati. 2.1 modelli per il controllo degli accessi Le informazioni gestite dai computer sono un bene di vitale importanza per ogni azienda, sia essa pubblica o privata. La perdita di informazioni riservate può comportare perdita di competitività sul mercato o in caso di dati confidenziali, come informazioni sanitarie, dar luogo a reati perseguibili anche penalmente. Lo sviluppo di sistemi informatici che collaborano tra loro pone all attenzione anche un ulteriore problema: come far collaborare sistemi di sicurezza. Il crescere della complessità dei sistemi, della quantità di dati da gestire e dei meccanismi di condivisione delle informazioni, ha portato i modelli di controllo degli accessi ad evolvere nel tempo. La letteratura in merito a questi modelli non fa riferimento a un unico e condiviso dizionario delle definizioni e degli acronimi. In molti articoli, le stesse sigle possono avere significati completamente diversi, ad esempio la sigla ABAC in [10] non rappresenta Attribute Based Access Control, significato comunemente diffuso, ma Authorization Based Access Control. Inoltre, vari documenti sono in contrasto tra loro sulla definizione del modello basato su politiche e le differenze rispetto alla versione basata su attributi. Per seguire un unica linea guida, la descrizione dei modelli riportata in questa sezione segue la panoramica offerta dal National Institute of Standards and Technology (NIST) in [15]. Si è scelto questo documento perché rilasciato da un agenzia adibita alla gestione e alla promozione di standard tecnologici per l industria americana, riconosciuta 5

10 6 controllo degli accessi a livello internazionale per il suo operato. Questa descrizione, inoltre, corrisponde al nostro punto di vista sull evoluzione dei modelli. Vediamo adesso le caratteristiche principali delle soluzioni proposte. I primi modelli di controllo degli accessi sono stati modelli discrezionali, Discretionary Access Control (DAC), dove l accesso alle risorse è basato unicamente sull identità del soggetto o del gruppo, e dei diritti che esso possiede sulla risorsa. Il capostipite di questi modelli è il metodo Access Control Lists (ACL) che consiste nella forma più elementare di controllo degli accessi: ogni risorsa controllata ha associata una lista di soggetti con le possibili azioni da eseguire su tale risorsa. Questo modello ha il vantaggio di definire un controllo molto fine sulle risorse e non richiede specifiche infrastrutture tecnologiche per essere realizzato. Per questo motivo fu tra i primi metodi ad essere supportato direttamente nei sistemi operativi. La dettagliata definizione delle regole di accesso è però causa di notevoli svantaggi, come l alto numero di controlli necessari quando si accede a molte risorse contemporaneamente e la grande quantità di dati da conservare. Queste caratteristiche non permettono quindi al metodo di scalare facilmente all aumentare delle risorse e degli utenti. Il passo successivo nello sviluppo è stato quello di definire il modello in base al ruolo che un utente ha nel sistema, e quindi definire l accesso alle risorse in base ai ruoli: il modello Role Based Access Control (RBAC). Questo modello sopperisce alla carenza principale di limitata scalabilità di ACL, visto che più persone possono avere lo stesso ruolo e di conseguenza accedere alle stesse risorse. I diritti di accesso sono definiti per il ruolo e permettono di creare una struttura gerarchica tra i ruoli, così da ereditare i diritti del predecessore e strutturare i permessi. Dal punto di vista delle implementazioni, un limitato modello RBAC è presente in tutti gli attuali sistemi operativi, pensiamo ad esempio al ruolo Administrator in Windows o a root nei sistemi Unix. A livello di reti aziendali, invece, si ha la necessità di infrastrutture apposite per la condivisione dei ruoli e dei relativi diritti, ma ormai sono molte le piattaforme che offrono questi servizi. La maggior scalabilità del modello, dovuta alla presenza dei ruoli, ha però aumentato la granularità dell approccio; per assegnare a persone specifiche poche risorse è sempre necessario definire un nuovo ruolo. Utilizzando la versione gerarchica è possibile definire vari sotto-ruoli, ma non permettono comunque una facile identificazione dei singoli utenti. Il controllo degli accessi non può basarsi soltanto su ruoli, visti i problemi di granularità, ma si deve affidare a più valori diversi: gli attributi. Gli attributi sono un insieme di caratteristiche associate al richiedente, all azione da eseguire e alla risorsa stessa. Questo modello prende il nome di Attribute Based Access Control (ABAC). La richiesta di accesso fornisce al gestore degli accessi, direttamente o indirettamente, una serie di attributi necessari per valutare l esito finale dell autorizzazione. Le regole possono essere definite per una qualsiasi combinazione di attributi, offrendo la possibilità di creare regole specifiche per

11 2.1 modelli per il controllo degli accessi 7 certe risorse o approcci più generali sullo stile del modello RBAC, considerando il ruolo come uno degli attributi. A differenza dei modelli precedenti, nei sistemi operativi attuali un servizio ABAC non è implementato, anche se per implementarlo non si ha la necessità di particolari infrastrutture tecnologiche di supporto. In sistemi di grandi dimensioni è comunque utile un servizio per stabilire definizioni comuni degli attributi (Authoritative Attribute Source, AAS), allo scopo di armonizzare lo sviluppo delle regole. La definizione di regole di sicurezza mediante attributi è un metodo più efficiente rispetto a RBAC, ma l organizzazione delle regole non scala in sistemi di grandi dimensioni, in quanto non vi è un metodo per gestirne la struttura. Il modello Policy Based Access Control (PBAC) si presenta come una standardizzazione e riorganizzazione del modello ABAC, per permettere una più semplice gestione delle regole. Il sistema di controllo è formato da politiche, cioè insiemi di regole su attributi, e valuta le richieste autorizzative combinando le decisioni delle politiche applicabili alla richiesta. Ogni politica calcola la sua decisione in base ad attributi forniti dalla richiesta o da altre entità esterne, che forniscono solitamente valori d ambiente. Rispetto al modello ABAC, le politiche possono essere identificate e utilizzate in più entità distinte all interno di un sistema, offrendo una maggior scalabilità del modello. Molte aziende e organizzazioni utilizzano sistemi per il controllo degli accessi basati sul modello PBAC. Quando questi sistemi interagiscono tra loro, anche i sistemi di controllo degli accessi devono comunicare tra loro, ma in assenza di standard su cui poter basare l implementazione di questi servizi non si avrà mai un comportamento interpretabile correttamente da entrambi i lati. Per standardizzare il processo di valutazione delle richieste e la definizione delle politiche di sicurezza, sono state fatte varie proposte negli scorsi anni. Tra queste specifiche quella che è diventa standard nell uso comune è XACML, realizzato e mantenuto dal consorzio Organization for the Advancement of Structured Information Standards (OASIS). Il modello PBAC potrebbe in futuro evolversi su vari fronti, ad esempio integrando nuove modalità di creazione e indicizzazione delle politiche. Attualmente non sono però disponibili varianti significative del modello, tranne quelle proposte per ambienti applicativi specifici, come sistemi militari e safetycritical. Queste proposte, che andremo brevemente a presentare, non sono però considerate nuovi modelli di controllo, ma soltanto applicazioni specifiche. Una di queste proposte è l applicazione del modello PBAC a sistemi critici. In questo ambito è necessario associare livelli di rischio a ogni processo di decisione e legare la valutazione delle richieste a parametri specifici di rischio. Il modello Risk Adaptive Access Control (RAdAC) è stato proposto per questo scopo, ma la vasta sfida tecnologica per il livello infrastrutturale necessario alla gestione del rischio, ha fatto sì che non si abbiano ancora applicazioni utilizzate da analizzare.

12 8 controllo degli accessi Un altro problema di PBAC è l assenza di un controllo autorizzativo tra i vari livelli di valutazione presenti. In applicazioni militari, per assicurare l integrità e la sicurezza delle informazioni, la valutazione delle politiche deve essere condizionata anche dall autenticazione ricevuta da chi esegue ogni operazione durante il processo. Questo approccio è trattato nel modello authorization Based Access Control (ZBAC), ma attualmente si hanno implementazioni soltanto in ambito militare. Questi ultimi modelli sono nati per ambienti applicativi ristretti e non presentano particolari innovazioni rispetto a PBAC, che invece è di largo utilizzo nei moderni sistemi di controllo degli accessi. Per comprendere quali siano le potenzialità e le caratteristiche del modello andiamo a presentare lo standard XACML, che ne è l esempio più significativo. 2.2 xacml Lo standard XACML definisce un linguaggio in sintassi XML per politiche di sicurezza e un processo di valutazione delle richieste autorizzative secondo il modello PBAC. La prima versione è stata pubblicata da OASIS nel 2003 e allo sviluppo hanno collaborato molte tra le più grandi aziende del settore IT. La versione attualmente stabile è la 2.0 [17] del 2005, ma dal 2010 è già disponibile una bozza della versione 3.0, che da giugno 2012 è stata aggiornata alla versione finale per la revisione pubblica [22]. Nello standard XACML la richiesta di accesso a una risorsa è formata da un insieme di attributi che descrivono il soggetto, l azione e la risorsa coinvolti. L esito del processo di autorizzazione è dato dalla combinazione delle regole applicabili a tale richiesta. Nella versione attuale, a differenza della precedente, il processo di autorizzazione della richiesta può dipendere non solo dalle regole applicate sugli attributi, ma anche dal risultato di azioni accessorie eseguite in fase di applicazione della decisione. Nel caso queste azioni non fossero eseguite con successo, si avrebbe la negazione dell accesso alle risorse; vedremo in dettaglio queste situazioni nelle prossime sezioni. Questa possibilità crea una maggior dinamicità delle politiche, in quanto l autorizzazione non dipende soltanto dalle regole definite, ma anche da azioni eseguite a tempo di valutazione. Con l eccezione del caso precedente, non sono presenti notevoli differenze tra le ultime due versioni, se non in costrutti sintattici diversi per migliorare l efficienza di specifica delle politiche; queste differenze sono presentate in dettaglio nel capitolo successivo. Nel prosieguo della tesi la versione di riferimento di XACML è la 3.0 [22]. A seguire è descritto il modello applicativo dello standard e la sua struttura interna.

13 2.2 xacml Il processo di autorizzazione Un sistema di controllo degli accessi deve essere considerato come un componente indipendente di un sistema architetturale più ampio. La tipologia di componenti presenti nel sistema dipende dalla natura dell architettura realizzata, ma componenti per la comunicazione e autenticazione saranno sicuramente presenti, per fornire gli strumenti necessari alla costruzione di altre funzionalità. Se dal punto di vista della comunicazione molto è legato all infrastruttura di rete utilizzata, per l autenticazione si può utilizzare lo standard Security Assertion Markup Language (SAML) [16] di OASIS. Questo standard permette la gestione e il trasferimento di attributi d identità nelle comunicazioni tra i componenti, e quindi anche per le richieste autorizzative. Lo standard XACML si inserisce all interno di questo contesto applicativo, con il compito di valutare le richieste di autorizzazione; gli attributi di identificazione eventualmente presenti possono condizionare l esito del processo. Andiamo adesso nel dettaglio di quello che è il modello di sistema proposto nello standard. Il dominio applicativo di XACML non comprende esclusivamente il ruolo di valutazione della richiesta autorizzativa, ma coinvolge altri ruoli, come l applicazione della decisione presa, la gestione delle politiche e il dialogo con l esterno. Lo standard descrive un insieme di ruoli e le interazioni tra di essi, allo scopo di delineare la struttura del sistema di controllo, senza però forzare specifiche soluzioni implementative. Il dialogo con applicazioni esterne al sistema di controllo degli accessi e l applicazione delle decisioni calcolate per le richieste, sono associate al ruolo del Policy Enforcement Point (PEP). La realizzazione del processo di valutazione autorizzativa è associata al ruolo del Policy Decision Point (PDP), che è quello definito con maggior dettaglio nello standard. Infine, la gestione di informazioni esterne alle politiche, ma necessarie per la valutazione, è associata al Policy Information Point (PIP). Il flusso delle informazioni tra i ruoli è gestito, come vedremo più avanti, dal context handler. La definizione di ruoli e non di entità ben precise, permette di definire le funzionalità del sistema, lasciando la possibilità di integrarle, a seconda delle implementazioni, nei componenti opportuni. Ad esempio, si può avere un sistema definito per richieste non sviluppate in formato XACML, che devono quindi essere trasformate nella sintassi richiesta dal PDP. Questo compito può essere svolto dal PEP oppure dal context handler prima della chiamata del PDP. Il processo di autorizzazione si basa sui valori degli attributi presenti nelle richieste e può dipendere anche dal contesto di valutazione esterno alle richieste. Con contesto si intende l insieme delle informazioni collegate all ambiente di valutazione delle richieste; un tipico esempio è l attributo tempo che indica la data e l ora corrente. L attributo è l unità che contiene le informazioni nel

14 10 controllo degli accessi Figura 2.1: Data-Flow XACML contesto e nelle richieste ed è formato da una coppia nome-valore. Lo standard definisce una sintassi specifica per gli attributi, ma non è necessario utilizzarla nelle implementazioni. Il flusso delle informazioni tra i ruoli prima presentati descrive il processo di valutazione alla XACML raffigurato in Figura 2.1. Lo standard non definisce il comportamento e i requisiti di ogni ruolo presente in figura, ma soltanto di quei ruoli strettamente coinvolti nel processo di decisione. Il PDP, che calcola la decisione associata a ogni richiesta, è dettagliato in ogni comportamento e requisito funzionale, a differenza degli altri ruoli definiti soltanto per requisiti generali. La definizione del PDP si basa su una sintassi specifica degli elementi request (richiesta), response (risposta) e attribute (attributo) presenti in Figura 2.1. Per effettuare il processo di valutazione riceve le politiche dal Policy Administration Point (PAP). Di questo ruolo non è stabilito alcun requisito funzionale per la sua implementazione, ma solo la sintassi delle politiche. La gestione delle politiche nel PAP, cioè salvataggio, aggiornamento, modi-

15 2.2 xacml 11 fica e recupero, dipendono dai vincoli applicativi e dalle tecnologie utilizzate. Una proposta di OASIS a tal riguardo è descritta nello standard amministrativo collegato [24]; questo standard è descritto con maggior dettaglio nelle sezioni successive. Durante la valutazione delle politiche il PDP può avere la necessità di ricevere informazioni aggiuntive su risorse. Perciò, usa il context handler per interrogare il PIP, che ricerca il valore degli attributi richiesti; anche in questo caso le modalità implementative possono essere molteplici. Il PAP e le entità collegate al context handler potrebbero essere oggetto di una definizione più completa in futuri standard OASIS, ad esempio, in [27] vi è una discussione su quali caratteristiche dovrebbe avere il futuro PAP. La ricezione delle richieste e l applicazione delle decisioni calcolate sono compiti del PEP. Questo ruolo non è definito completamente nello standard, ma sono descritte le linee guida generali da seguire. Il PEP per applicare la decisione ricevuta con l elemento response in Figura 2.1, ha il compito di eseguire e valutare tutte le azioni accessorie presenti e, in base all esito delle azioni, permettere l accesso alla risorsa o negarlo. Il PEP, in generale, è un livello di astrazione che implementa le azioni non eseguibili direttamente dal PDP e gestisce la comunicazione con l esterno. Se pensiamo ad esempio a un servizio web che implementa il modello di valutazione XACML, il PEP può essere lo stub che riceve le richieste, spacchetta i vari attributi organizzandoli in richieste per il PDP e, una volta ricevuta la decisione, la comunica al client. La definizione delle azioni eseguibili dal PEP non è formalizzata e nelle politiche sono definiti soltanto l identificatore dell azione e gli argomenti. Per l esecuzione corretta dell azione, si deve avere un accordo tra chi implementa il PEP e chi scrive le politiche, allo scopo di associare stesso significato agli identificatori. La comunicazione tra PDP, PEP, PIP e gli altri ruoli presenti in Figura 2.1, è resa possibile dal context handler. Questo ruolo non ha compiti specifici oltre ad organizzare le richieste e gestire la comunicazione di risposte e attributi. Nelle implementazioni dei tool che supportano XACML, questo ruolo è solitamente definito all interno del PDP o del PEP a seconda delle scelte. La descrizione precedente ha chiarito i compiti svolti dai vari ruoli, vediamo adesso come collaborano tra loro per decidere l esito di una richiesta, sulla base delle politiche d accesso definite nel PAP e disponibili per il PDP. Una situazione standard del flusso di informazioni generato dal processo di valutazione di un richiesta, è la seguente: La richiesta è inviata al PEP e inoltrata al context handler, che provvede a formattarla nella sintassi XACML e a inviarla al PDP. Se durante la valutazione il PDP necessita di attributi aggiuntivi, questi sono richiesti al context handler, che se non li ha ricevuti dal PEP, interroga il PIP. Quando tutti gli attributi sono stati ottenuti e la valutazione

16 12 controllo degli accessi della richiesta è terminata, il PDP completa la sua esecuzione e invia al context handler la risposta, comprensiva della decisione e di eventuali azioni accessorie. La risposta è ricevuta dal PEP, che esegue le eventuali azioni e garantisce l accesso alla risorsa oppure no, a seconda dell esito dei vari passaggi. Dalla descrizione precedente segue che il contesto di applicazione dello standard è il più vario possibile, non ci sono vincoli sul tipo di attributi o azioni eseguibili, ma soltanto sulla sintassi delle politiche e sui requisiti funzionali del PDP. Il recupero delle politiche dal PAP è una azione molto importante e le modalità scelte in fase di implementazione possono inficiare la performance. L approccio dei ruoli e la suddivisione dei compiti definita in precedenza, hanno permesso una vasta diffusione dell utilizzo di XACML, sia in ambito accademico che commerciale. Alcuni esempi di tool per la valutazione e il supporto allo sviluppo di politiche XACML sono mostrati in [1], mentre esempi di applicazioni industriali sono riportati in [3] Il linguaggio delle politiche Gli elementi valutabili di più basso livello del linguaggio sono le rule, raggruppate in policy che a loro volta possono essere contenute in insiemi chiamati policy set; nei policy set inoltre si possono anche raggruppare altri policy set. La valutazione delle rule determina l effetto, permit o deny, da cui inizia il processo di decisione. Dalla combinazione degli effetti delle rule e, risalendo l albero di valutazione, delle policy e dei policy set, è possibile ottenere la decisione finale del PDP. La composizione degli elementi del linguaggio si può raffigurare come in Figura 2.2, che andremo adesso a descrivere. Per quanto riguarda la notazione, per riferirsi agli elementi XML specifici di XACML è utilizzato il termine inglese in italico, mentre il termine italiano, riportato alla prima occorrenza del termine tra parentesi, è utilizzato in senso lato rispetto al modello PBAC. La rule (regola) rappresenta la componente elementare della policy (politica) ed è formata dal target 1, che ne definisce l applicabilità mediante espressioni su attributi, dalla condition (condizione), un espressione booleana che ne perfeziona l applicabilità, ed infine dall effect (effetto), permit o deny, che è il valore restituito dalla rule in caso di valutazione positiva delle altre componenti. L applicabilità di un elemento a una richiesta significa che tale elemento è utilizzato dal PDP per il calcolo della decisione autorizzativa. 1 Il termine italiano utilizzato è la stessa parola target, utilizzata in italico per riferirsi all elemento specifico XACML, con caratteri normali altrimenti.

17 2.2 xacml 13 Figura 2.2: Struttura del linguaggio XACML Le rule sono organizzate in policy, che sono composte da un target e dall identificatore dell algoritmo di combinazione dei risultati della valutazione delle rule contenute. L ultimo livello di aggregazione è il policy set (inisiemi di politiche), che è utilizzato per raccogliere le policy e i policy set stessi. Come per le policy, si ha la presenza di un target e di un algoritmo per il combinig dei risultati delle policy. In ogni rule, policy e policy set si ha anche la presenza di obligation e advice (entrambi i termini tradotti con obbligazione), che definiscono le azioni accessorie, già citate nelle sezioni precedenti, che deve eseguire il PEP. Per introdurre maggior dipendenza dal contesto della valutazione delle richieste, rispetto alla versione precedente di XACML le obligation sono state modificate con l introduzione di espressioni invece che valori letterali fissi, ed è stato introdotto l elemento advice per fornire informazioni aggiuntive non vincolanti per la decisione finale. Questi elementi permettono di ottenere mediante il PDP attributi dal contesto, che altrimenti non sarebbero ottenibili nel PEP e di eseguire azioni esterne al processo di valutazione del PDP, cioè nel PEP. L esito dell esecuzione di queste azioni influisce sull applicazione della decisione, infatti in caso di errori di esecuzione non è accordato l accesso alla risorsa. A questo fa eccezione l advice che in caso di errore non ha conseguenze sull ap-

18 14 controllo degli accessi plicazione della richiesta, garantendo maggior elasticità nella definizione delle azioni accessorie. L implementazione del PEP può comunque essere specializzata secondo il contesto applicativo, richiedendo una gestione diversa di questi elementi. Per facilitare la lettura, nel prosieguo della tesi si utilizzerà il solo termine obligation per indicare anche l elemento advice, a meno di esplicite distinzioni. I quattro possibili valori di decisione generati dal processo di valutazione del PDP sono i seguenti: - permit: l accesso alla risorsa è permesso; - deny: l accesso alla risorsa è vietato; - indeterminate: il PDP ha riscontrato un errore durante la valutazione della richiesta; - not-applicable: il PDP non dispone di politiche applicabili alla richiesta. Una situazione di indeterminate può essere causata da errori sintattici, assenza di alcune risorse o anomalie nell esecuzione di alcune operazioni. In molti casi si tratta di banali errori dovuti alla definizione delle policy, da cui nell ultima versione dello standard, per dettagliare maggiormente la situazione che ha generato un risultato indeterminate, è stata introdotta la seguente sintassi estesa per il valore indeterminate: - indeterminate-p: è un indeterminate dovuto a una politica o una regola che però potrebbe essere valutata come permit ma non deny; - indeterminate-d: è un indeterminate dovuto a una politica o una regola che però potrebbe essere valutata come deny ma non permit; - indeterminate-dp: è un indeterminate dovuto a una politica o una regola che però potrebbe essere valutata sia come permit che deny. I valori estesi riportano quello che potrebbe essere il valore di decisione dell elemento, così da facilitare la verifica delle politiche. La semantica della valutazione delle richieste si basa in larga parte sugli algoritmi di combinazione, infatti essi stabiliscono quale elemento deve essere valutato, come gestire eventuali risultati indeterminate e come unire più valori di decisione diversi. Nello standard sono presenti alcuni algoritmi per modellare situazioni frequenti, ma si può gestire situazioni specifiche con algoritmi personalizzati. Nella sfera di influenza di XACML ci sono anche altri standard minori per gestire casistiche particolari, ne vedremo due nella sezione successiva.

19 2.2 xacml Standard collegati a XACML Con lo sviluppo della versione 3.0 di XACML è stato introdotto il supporto ad alcune funzionalità aggiuntive rispetto al solo processo di decisione. Si tratta di operazioni collegate al processo di decisione, di cui si può richiedere l utilizzo mediante alcuni attributi presenti nella sintassi di XACML. A titolo di esempio si considera la decisione combinata di più richieste [23] e la delegation [24], che permette la gestione della modifica e dell aggiornamento delle politiche nel PAP. La decisione combinata di più richieste consiste nel sottoporre al PDP un insieme di richieste, del quale si richiede un unico valore di decisione. La scelta di questa opzione è possibile mediante un attributo presente nella richiesta, senza dover modificare i ruoli prima presentati. Le operazioni stabilite in [23], che devono essere eseguite dal PDP e dal context handler, saranno illustrate in dettaglio nella Sezione 3.3. La delegation invece è un approccio per la gestione dei diritti sulle politiche, cioè per stabilire chi è autorizzato ad aggiornare le regole di accesso a una risorsa. Si può realizzare questo obiettivo associando a ogni politica un proprietario, mediante l attributo XML PolicyIssuer, a partire dal quale si calcola chi ha i diritti per svolgere certe azioni. La gestione dei diritti sulle risorse avviene per delega, cioè si definiscono delle politiche amministrative allo scopo di delegare a un soggetto i diritti di gestione di una risorsa. Una politica amministrativa è della stessa forma di una politica di controllo degli accessi, si attribuisce quindi la delega definendo anche controlli su altri attributi del contesto, oltre a quelli della risorsa. Un soggetto delegato può a sua volta delegare altri, dando origine a strutture gerarchiche tra politiche amministrative; la radice di questa struttura è una politica senza proprietario, che viene considerata come affidabile. Quando una richiesta di autorizzazione deve essere valutata, se si applica questo standard amministrativo, prima di valutare le politiche, si controlla se sono state definite da soggetti autorizzati a farlo. Sulla base delle politiche d accesso applicabili, si ricostruisce, utilizzando le politiche amministrative presenti, il grafo di riduzione delle deleghe, cioè si ricostruiscono le autorizzazioni associate a chi ha definito la politica d accesso. Nel dettaglio, si prende una coppia di politiche e si controlla se una politica delega, al proprietario dell altra, i diritti di gestione della risorsa indicata nella richiesta autorizzativa. Si completa il grafo valutando tutte le coppie di politiche, e si selezionano per la valutazione della richiesta soltanto le politiche d accesso affidabili, cioè quelle per le quali è possibile creare un cammino di politiche amministrative fino a una politica senza proprietario, perciò affidabile. Per implementare questo processo di controllo amministrativo, deve essere gestito il riconoscimento del proprietario di ogni politica e la definizione di

20 16 controllo degli accessi identificatori specifici per gli attributi, allo scopo di distinguere le politiche amministrative da quelle d accesso. 2.3 caso di studio La collaborazione tra sistemi informatici è pratica comune per la condivisione di informazioni e per la creazione di nuovi servizi. Questa direzione di sviluppo è stata adottata anche per i sistemi sanitari delle nazioni europee, al fine di condividere le informazioni su pazienti, prescrizioni e malattie rilevate sul territorio. Gli strumenti che si vogliono creare permettono di incrementare la qualità del servizio per il paziente, sia nella nazione di residenza che all estero. Lo sviluppo di questi progetti, oltre alle questioni normative, coinvolge largamente le problematiche del controllo degli accessi e le soluzioni tecnologiche da adottare. Vista l importanza dell obiettivo e la connessione agli argomenti affrontati nella tesi, si utilizza il progetto europeo Smart Open Services for European Patients (epsos) [25] come caso di studio. Presentiamo quindi con maggior dettaglio le finalità del progetto e le scelte tecnologiche effettuate Il progetto epsos Il progetto di un servizio sanitario europeo integrato è nato a inizio anni duemila e nel corso del 2008, con la nascita di epsos, siamo passati dalla fase concettuale a quella di progettazione vera e propria. La finalità del progetto è quella di creare le basi, tecnologiche e giuridiche, per supportare l interoperabilità dei sistemi sanitari degli stati membri. Le soluzioni tecniche e organizzative proposte, dal 2011, sono in fase di test con un progetto pilota su larga scala. Lo sviluppo di epsos guiderà verso la completa digitalizzazione i servizi sanitari nazionali, favorendo così nuove tipologie di servizi offerti, ad esempio la telemedicina, cioè fornire supporto al paziente tramite strumenti informatici, e la digitalizzazione delle ricette mediche. I servizi che si potranno offrire con queste tecnologie incrementeranno la qualità del sistema sanitario usufruibile dai cittadini europei. Conseguire questi obiettivi comporta una sfida tecnologica e anche legislativa rilevante, viste le differenze giuridiche tra le nazioni nel trattamento dei dati personali. In questo ambito, gli organi legislativi europei si sono adoperati per armonizzare i sistemi normativi e definire le modalità di applicazione del progetto. Dal punto di vista tecnologico, invece, si ha l obbligo di assicurare stringenti requisiti di sicurezza nell accesso ai dati, dei tempi di risposta nell elaborazione delle richieste e nella gestione di grandi quantità di dati. Vediamo adesso nel dettaglio la definizione del sistema di sicurezza.

21 2.3 caso di studio 17 Figura 2.3: Schema logico della comunicazione in epsos Il sistema di sicurezza Il sistema di scambio di informazioni tra nazioni si basa sulla creazione di un Circle of Trust (cerchio della fiducia) tra gli stati, cioè una piattaforma mediante la quale avviene il dialogo tra i vari sistemi nazionali. Dentro questo dominio, ogni nazione è rappresentata da un National Contact Point (NCP), cioè un gateway che gestisce i messaggi in entrata e in uscita dal sistema nazionale. Ogni NCP assicura i requisiti richiesti per la comunicazione con gli altri NCP e, prima di diffondere informazioni all infrastruttura nazionale, valuta l autorizzazione di quei dati, nel rispetto dello norme nazionali. Per garantire la sicurezza del sistema, si separa il sistema di gestione nazionale da quello per la comunicazione esterna, definendo un livello intermedio di controllo sugli accessi. Tutti gli scambi di messaggi, inoltre, sono soggetti a un controllo di autenticazione, cioè ci si assicura dell identità di chi effettua la richiesta; da questi attributi di identità dipende anche il risultato della decisione autorizzativa. La definizione delle politiche di sicurezza nazionali compete alle singole nazioni, mentre il sistema di controllo degli accessi e la comunicazione tra gli NCP sono definiti secondo i requisiti funzionali epsos. Per l implementazione del controllo degli accessi, cioè per la definizione delle politiche e delle richieste, è stato scelto lo standard XACML. Lo standard si inserisce all interno dello schema logico di Figura 2.3, dove è rappresentato il ruolo del sistema di controllo degli accessi per la comunicazione tra due NCP nazionali. Ogni nazione implementa il proprio NCP suddividendo la parte di comunicazione con gli altri NCP dal sistema nazionale vero e proprio. Tra le due componenti si pone il sistema di controllo degli accessi, che valuta l autorizzazione dei messaggi in transito. Quando si vuole interrogare un sistema straniero, il sistema nazionale controlla l autenticazione del soggetto, utilizzando lo standard

22 18 controllo degli accessi Figura 2.4: Caso d uso per Patient Summary (PS) SAML, e se i controlli autorizzativi hanno esito positivo, il messaggio viene codificato secondo le specifiche epsos e inviato all altro NCP. Quest ultimo valuterà la richiesta in base alle proprie politiche e, se il paziente e il sistema danno il consenso alla diffusione dei dati, la risposta è inviata al mittente. Le politiche di sicurezza nazionali sono definite, secondo le specifiche epsos, sui dati medici dei pazienti, distinguendo quelli critici, cioè da trattare secondo appropriate direttive, da quelli non critici e dai dati amministrativi. I diritti di accesso ai dati, sono definiti in base al ruolo che il richiedente ricopre nel servizio sanitario nazionale; ad esempio un dottore può aver accesso ai dati medici di un paziente, a differenza del personale amministrativo. Di ogni paziente i sistemi nazionali gestiscono, tra le altre, le seguenti tipologie di informazioni: - Patient Summary (PS): la cartella clinica completa del paziente, contenente tutte le informazioni sui trattamenti effettuati; - eprescription (ep): la prescrizione di un medicinale per un paziente, con la specifica delle modalità e dei tempi di somministrazione. In base alle regole di diffusione delle informazioni, definite dal paziente e dal sistema nazionale, sono definite le politiche di sicurezza XACML. Nel progetto epsos sono definiti i comportamenti del sistema anche per altre tipologie di informazioni, ma in questa tesi approfondiamo la gestione della cartella clinica e della prescrizione elettronica, presentando un caso d uso specifico.

23 2.3 caso di studio 19 Il caso d uso di PS è descritto con il sequence diagram in Figura 2.4 e mette in risalto, rispetto alla Figura 2.3, l utilizzo dei ruoli di XACML. In questo caso d uso si ha che un dottore chiede la cartella clinica di un paziente, tramite lo NCP della nazione B, al NCP della nazione A di origine del paziente. La richiesta contiene gli attributi di identificazione del dottore e l identificativo del paziente. Una volta controllata l autenticità della richiesta, si provvede a recuperare le informazioni necessarie, delle quali se ne valuta la possibilità di diffusione in base alle politiche di sicurezza definite. Per calcolare tale decisione si interroga l unità PEP della nazione A, la quale applicando la decisione del PDP, restituisce la decisione finale al NCP di A, che la comunica al NCP di B. La risposta finale al dottore è vincolata dalla valutazione delle regole della nazione B, infatti si può avere alcune restrizioni normative che devono essere applicate. Questo caso d uso rappresenta la situazione reale in cui un paziente originario della nazione A si trova nella nazione B e necessita di cure. Il dottore che effettua la visita può richiedere la cartella del paziente alla nazione A. I dati clinici e le eventuali prescrizioni del paziente ricevuti, offrono maggiori informazioni al dottore per effettuare il consulto richiesto. Per quanto riguarda la richiesta di prescrizioni elettroniche, la sequenza delle operazioni è simile alla precedente, e non se ne presenta il caso d uso. In questa caso la richiesta può anche essere fatta da un soggetto che ricopre il ruolo di farmacista. Il caso d uso delle prescrizioni rappresenta la situazione in cui ad un paziente sono stati prescritti dei farmaci nella propria nazione e devono essere ritirati durante una permanenza all estero. Per rilasciare il farmaco, il farmacista si collega alla piattaforma epsos e controlla la presenza della prescrizione. Quando consegna al paziente i farmaci, la dispensazione è comunicata alla nazione di origine. Il caso di studio presentato in questa sezione è così dettagliato nei capitoli successivi. Nel Capitolo 3 sono presentate le politiche di sicurezza e la loro valutazione mediante il tool HERAS AF [26]. Nel Capitolo 4 la definizione delle politiche secondo la sintassi del nostro linguaggio ed infine nel Capitolo 5 la valutazione delle richieste con la libreria Java che abbiamo sviluppato.

24

25 3 S I N TA S S I E S E M A N T I C A D I X A C M L Il modello di controllo degli accessi alla base dello standard XACML, trattato nel capitolo precedente, ha delimitato l ambito entro cui stiamo operando e le funzionalità offerte dal sistema. In questo capitolo ci occupiamo di definire la sintassi del linguaggio delle politiche e la semantica informale del processo di valutazione delle richieste autorizzative. La sintassi è definita in XML e si suddivide tra la parte di definizione di rule, policy e policy set, elementi contenuti nel PAP, e quella di request e response. Il processo di valutazione delle richieste è definito specificando i requisiti funzionali del PDP necessari per la valutazione dei target, delle condizioni, ecc, e per l applicazione degli algoritmi di combinazione. Descriviamo prima gli elementi dello standard e le loro caratteristiche principali, e a seguire il processo per valutare le richieste. 3.1 sintassi di xacml Gli elementi valutabili della sintassi di XACML sono le rule, le policy, i policy set e i loro sotto-elementi come i target e le obligation. Gli elementi request e response sono definiti per il dialogo con il PDP Politiche e Insiemi di Politiche Le politiche e gli insiemi di politiche presenti nel PDP, recuperati dal PAP, sono gli elementi da cui inizia il processo di valutazione delle richieste. Infatti, il PDP può essere visto come un policy set con target vuoto che racchiude le altre politiche considerate nella valutazione. Questi elementi sono definiti rispettivamente con i costrutti XML <Policy> e <Policyset>. La loro struttura è la stessa, con la sola differenza che le policy contengono rule mentre i policy set sono formati da policy o altri policy set. Gli elementi sintattici necessari a identificare una policy sono - un identificatore della policy, utilizzato come riferimento per includere in altri policy set la policy in questione; 21

26 22 sintassi e semantica di xacml - un target, per definire l applicabilità della policy alle richieste; - un algoritmo per la combinazione delle rule presenti nella policy; - una sequenza, anche vuota, di rule; - eventuali obligation. L identificatore e l algoritmo sono definiti come attributi dell elemento XML mentre gli altri sono degli elementi figli di policy. L algoritmo di combinazione determina il flusso del processo di valutazione delle richieste e quale sia la decisione finale della politica. Tra i sotto-elementi di policy, oltre a quelli sopra elencati, ve ne sono anche altri per la scelta di parametri opzionali di valutazione. Ad esempio si ha il <PolicyIssuer>, necessario per l implementazione della delegation descritta in [24], o la definizione di parametri per l invocazione di algoritmi di combinazione personalizzati. Non andiamo nel dettaglio di queste specifiche in quanto non necessarie ai fini della tesi. Gli attributi dell elemento policy set sono simili a quelli elencati sopra per policy, con la differenza che gli algoritmi di combinazione sono definiti su politiche e non su regole. Alcuni esempi di politiche e insiemi di politiche sono riportati nella Sezione Regole L elemento di base per formare le politiche XACML è la rule. Gli elementi che la compongono sono l effetto, il target, la condizione e le obbligazioni. L effetto è la decisione restituita alla politica che contiene la regola, quando la regola è valutata con successo. L effetto può essere permit o deny. Per definire a quali richieste si applica la regola, oltre al target, vi è anche l elemento condition, che consiste in una funzione booleana su attributi o funzioni di attributi. In particolare, la condizione è un espressione dove è possibile definire controlli su attributi della richiesta o del contesto, per specializzare il controllo dell applicabilità. Le tipologie di espressioni che si possono definire sono raccolte sotto l elemento <Expression>. Tra le altre, si ha la specifica di funzioni con l elemento <Apply>, il recupero dei valori degli attributi con <AttributeSelector> o <AttributeDesignator>, e l utilizzo di riferimenti a funzioni, che erano state definite con l elemento <Variable> all esterno di rule. Esempi di rule sono riportati nella Sezione