UNIVERSITÀ DEGLI STUDI DI BRESCIA FACOLTÀ DI INGEGNERIA CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA INFORMATICA DIPARTIMENTO DI ELETTRONICA PER L AUTOMAZIONE CONTROLLO D ACCESSO BASATO SU RUOLI (RBAC) IN UN APPLICATION SERVER J2EE (JAVA 2 ENTERPRISE EDITION): STUDIO ED IMPLEMENTAZIONE Studente: Giacomo Carlotti Matricola: 52916 Relatore: prof. Pietro Baroni Correlatori: ing. Andrea Mauro ing. Pietro Martinelli ANNO ACCADEMICO 2004/2005
A mia madre e a mio padre Pagina 2
Ringraziamenti Ringrazio sentitamente il prof. Pietro Baroni e l ing. Andrea Mauro per la stima e la fiducia che hanno dimostrato avere nei miei confronti. Un ringraziamento particolare va all ing. Pietro Martinelli per la sua disponibilità ed i suoi preziosi consigli. Pagina 3
INDICE INDICE... 4 CAPITOLO 1 INTRODUZIONE... 11 1.1 Il contesto della tesi: la sicurezza dell informazione... 12 1.2 Le proprietà della sicurezza dell informazione... 14 1.2.1 Autenticazione... 14 1.2.2 Controllo degli accessi / Autorizzazione... 14 1.2.3 Confidenzialità (privacy e segretezza)... 15 1.2.4 Integrità... 15 1.2.5 Responsabilità & Non ripudio... 16 1.2.6 Disponibilità... 17 1.3 Politiche, modelli e meccanismi... 18 1.4 Gli obiettivi della tesi... 20 1.5 Il piano di lavoro... 21 CAPITOLO 2 IL CONTROLLO D ACCESSO TRADIZIONALE... 23 2.1 Il controllo d accesso... 24 2.1.1 L ontologia di base... 24 2.2 I principi fondamentali... 25 2.2.1 Il minimo privilegio (Least privilege)... 26 2.2.2 La separazione dei compiti (Separation of duty)... 26 2.3 Breve storia del controllo d accesso tradizionale... 27 2.3.1 Matrice di controllo... 28 2.3.2 Reference monitor e security kernel... 29 2.3.3 Il modello di Bell-LaPadula... 31 Pagina 4
2.3.4 Modello d integrità di Biba... 32 2.3.5 TCSEC: il MAC e il DAC... 33 2.3.5.1 DAC (Discretionary Access Control)... 33 2.3.5.2 MAC (Mandatory Access Control)... 34 2.3.6 Modello di Clark e Wilson... 35 2.3.7 Politica del muro cinese e modello di Brewer e Nash... 36 CAPITOLO 3 IL MODELLO RBAC ORIGINALE... 39 3.1 Il primo modello RBAC... 40 3.1.1 Utenti, ruoli ed operazioni... 40 3.1.2 Gerarchie di ruoli... 41 3.1.3 Descrizione formale... 43 3.1.4 Il principio del minimo privilegio... 45 3.1.5 Separazione dei compiti... 45 3.2 Differenza tra ruoli e gruppi... 46 3.3 Confronto tra RBAC, MAC e DAC... 47 3.3.1 RBAC vs DAC... 47 3.3.2 RBAC vs MAC... 48 CAPITOLO 4 RBAC96 FRAMEWORK... 49 4.1 Il framework RBAC... 50 4.2 Panoramica dei modelli... 50 4.2.1 RBAC 0... 51 4.2.2 RBAC 1... 52 4.2.3 RBAC 2... 55 4.2.4 RBAC 3... 55 4.3 Descrizione formale... 56 4.3.1 RBAC 0... 56 4.3.2 RBAC 1... 57 Pagina 5
4.3.3 RBAC 2... 57 4.3.4 RBAC 3... 57 CAPITOLO 5 LO STANDARD RBAC PROPOSTO DAL NIST... 59 5.1 Presentazione dello standard... 60 5.2 Panoramica dei modelli... 60 5.2.1 Core RBAC... 61 5.2.2 Hierarchical RBAC... 62 5.2.3 Constrained RBAC... 64 5.2.3.1 Static Separation of Duty (SSD)... 64 5.2.3.2 Dynamic Separation of Duty (DSD)... 65 5.3 Modello concettuale... 66 5.3.1 Core RBAC... 67 5.3.2 Hierarchical RBAC... 69 5.3.3 Constrained RBAC... 71 5.4 Specifiche funzionali... 72 5.4.1 Core RBAC... 73 5.4.2 Hierarchical RBAC... 75 5.4.3 Static Separation of Duty (SSD)... 77 5.4.4 Dynamic Separation of Duty (DSD)... 78 5.5 I packages... 79 CAPITOLO 6 ANALISI CRITICA DEL MODELLO... 83 6.1 Attivazione e disattivazione dei ruoli... 84 6.2 Le gerarchie... 85 6.2.1 Gerarchia ed attivazione dei ruoli... 86 6.2.2 Gerarchia e disattivazione dei ruoli... 86 6.2.3 Gerarchia e separazione dei compiti... 88 6.2.4 Gerarchia e permessi... 90 Pagina 6
6.3 Separazione dei compiti e permessi... 92 6.4 I permessi in un sistema ad oggetti... 93 6.5 Aggiunta e rimozione di elementi del modello... 95 6.6 I vincoli... 96 6.6.1 GTRBAC (Generalized Temporal RBAC)... 96 6.6.2 La separazione dei compiti storica... 97 6.6.3 Tassonomia dei vincoli... 98 6.6.4 I vincoli in un sistema ad oggetti... 101 6.7 Il formato dei vincoli... 102 6.7.1 XACML 2.0 (extensible Access Control Markup Language)... 103 6.7.2 La mutua esclusione... 104 6.7.3 La Blacklist di Crampton... 105 CAPITOLO 7 ESTENSIONE DEL MODELLO: UNA PROPOSTA... 108 7.1 Premessa... 109 7.2 L architettura... 109 7.2.1 Parte statica... 111 7.2.2 Parte dinamica... 112 7.3 L attivazione dei permessi... 114 7.4 Le scelte di definizione del modello... 117 7.5 Il framework... 119 7.5.1 Le funzioni... 119 7.5.2 I packages... 121 CAPITOLO 8 LA TECNOLOGIA J2EE... 122 8.1 La piattaforma J2EE... 123 Pagina 7
8.2 L architettura J2EE... 124 8.3 L Application Programming Model... 127 8.3.1 Livello Client... 129 8.3.2 Livello Web... 129 8.3.3 Livello Business... 130 8.3.4 Livello EIS... 131 8.4 Le API J2EE... 132 8.4.1 JDBC (Java DataBase Connectivity)... 132 8.4.2 RMI (Remote Method Invocation)... 135 8.4.3 Java IDL (Interface Definition Language)... 136 8.4.4 JNDI (Java Naming and Directory Interface)... 137 8.4.5 JMS (Java Message Service)... 137 8.5 Servlet API: il package javax.servlet... 137 8.5.1 HttpServletResponse... 140 8.5.2 HttpServletRequest... 140 8.5.3 Sessioni utente... 140 8.5.3.1 HttpSession... 141 8.5.3.2 Durata di una sessione utente... 142 8.5.4 Filter... 142 8.5.5 Eventi di tipo HTTP session... 143 8.6 JSP (Java Server Pages)... 144 8.6.1 Compilazione di una pagina JSP... 144 8.7 Autorizzazione in J2EE... 145 8.7.1 Modello di autorizzazione di base... 145 8.7.2 JAAS (Java Authentication and Authorization Service)... 146 CAPITOLO 9 L IMPLEMENTAZIONE DEL MODELLO ESTESO... 148 9.1 Motivazioni... 149 Pagina 8
9.2 Architettura del sistema... 150 9.3 I package... 153 9.4 Descrizione dell implementazione... 156 9.4.1 Il web plug-in... 157 9.4.2 Il motore statico... 159 9.4.3 Il motore dinamico... 161 9.4.4 Il gestore e il monitor delle sessioni... 164 9.4.5 Note implementative... 165 9.5 Il database... 165 9.5.1 I vincoli supportati ed il loro formato... 166 9.6 I tool amministrativi... 167 9.6.1 AdminTool... 167 9.6.2 SessionMonitor... 169 9.7 I file di configurazione... 170 CAPITOLO 10 TEST E CONCLUSIONI... 172 10.1 Testing... 173 10.1.1 Motore statico: Casi d uso... 174 10.1.2 Motore Statico: Casi d uso... 177 10.1.3 Risultati... 177 10.2 Considerazioni finali... 178 10.3 L attualità del tema... 179 10.4 Sviluppi futuri... 181 INDICE DELLE FIGURE... 182 INDICE DELLE TABELLE... 184 Pagina 9
BIBLIOGRAFIA E RIFERIMENTI... 185 APPENDICE A JAVADOC... 195 APPENDICE B.1 DIAGRAMMI UML DEI PACKAGES... 196 APPENDICE B.2 DIAGRAMMI UML DELLE CLASSI... 197 Pagina 10
CAPITOLO 1 INTRODUZIONE Prima di entrare nel dettaglio delle attività svolte per il raggiungimento degli obiettivi della tesi viene fornita una breve descrizione del contesto in cui essa si pone, in modo da inquadrare correttamente dal punto di vista concettuale il lavoro effettuato. A questo scopo verranno elencati in modo ordinato ed organico gli obiettivi della presente trattazione ed infine verrà illustrato il piano di lavoro seguito durante lo svolgimento delle diverse attività necessarie alla realizzazione dell intero progetto. Pagina 11
1.1 Il contesto della tesi: la sicurezza dell informazione Non è certo necessario dimostrare che al giorno d oggi una parte sempre maggiore delle attività umane viene realizzata, controllata, o coadiuvata dall'utilizzo di sistemi informatici. Per questa ragione risulta particolarmente importante comprendere quanto siano sicuri questi sistemi. Il problema ovviamente diviene sempre più critico, mano a mano che il valore delle informazioni scambiate in forma digitale cresce. La sicurezza dell'informazione ha attraversato un lungo periodo di gestazione in cui veniva considerata un'arte più che una scienza, da apprendere tramite l'esperienza e non tramite lo studio. Solo pochi studi pionieristici stendevano le basi dei metodi formali che negli ultimi anni sono stati sviluppati. Questo, unito all'intrinseca difficoltà della materia, spiega il motivo per cui gran parte degli approcci al tema della sicurezza dell'informazione sono basati su esperienza e conoscenza euristica più che su tecniche raffinate. Il principale settore della sicurezza che vanta una lunga tradizione nell'uso dei metodi formali è il campo della crittografia, che non sorprendentemente è molto più avanzato e stabile degli altri. Se questo metodo pragmatico di procedere ha funzionato per anni, lo sviluppo esplosivo dei sistemi collegati in rete e di dispositivi con potenza e versatilità francamente inimmaginabili solo pochi anni fa ha reso necessario e urgente lo sviluppo di un'ingegneria della sicurezza informatica, dove il termine ingegneria va inteso nel suo senso tradizionale di scienza applicata, con definizione formale di concetti, metodi e tecniche conosciute, esplorate da una ampia letteratura scientifica, e globalmente diffuse. Per capire che cos'è la sicurezza informatica è necessario prima di tutto conoscere in modo chiaro la differenza ed il rapporto che esiste tra dati ed informazioni, ovvero i due elementi centrali attorno a cui la sicurezza informatica nasce ed acquista significato: i dati rappresentano le informazioni, mentre le informazioni sono la conoscenza contenuta nei dati. Le informazioni sono la base su cui viene Pagina 12
condotta l'attività economica, cioè sono politicamente, commercialmente e personalmente sensibili per lo sviluppo aziendale. Per questi motivi le informazioni sono un bene di grande valore per l'azienda e devono essere protette adeguatamente. La Sicurezza è tutto ciò che riguarda la protezione dei beni aziendali e quindi la sicurezza informatica (o dell'informazione) è il ramo della Sicurezza focalizzato sulla protezione di questo particolare tipo di bene. Questa definizione implica che l'azienda conosca con precisione tutti i propri beni ed il loro valore, ma l'esperienza insegna che nella complessità di una realtà aziendale in molti casi non è così. Questa osservazione generale è assolutamente vera anche per la sicurezza informatica, ecco perché l'analisi dei rischi è parte integrante e necessaria della strategia di sviluppo della sicurezza informatica e non. Per quanto le tecniche fino ad oggi elaborate possano offrire alti standard di sicurezza, queste non sono infallibili e soprattutto non possono uscire dai confini del sistema stesso. Per questo motivo il concetto di sicurezza dell informazione deve essere esteso ben oltre l informatica in senso ristretto, ovvero l hardware, il software e le reti di computer, andando a interessarsi dell intero processo di gestione dei dati e delle informazioni messo in atto da un organizzazione. Rientrano quindi a pieno titolo nell ingegneria della sicurezza anche considerazioni di sicurezza ambientale, gestione dell informazione non digitale, procedure nella gestione delle risorse umane, eccetera. In effetti, i filtri della sicurezza dell informazione operano come un interfaccia tra le persone ed i processi del sistema e devono gestire entrambe le variabili. Come si può immaginare, si tratta di un processo complesso, costoso ed esposto a sviste anche gravi. Alla luce dei concetti esaminati possiamo dunque definire la sicurezza informatica come il connubio di prevenzione e individuazione di azioni non autorizzate verso il sistema informatico. Gli obiettivi di prevenzione ed autorizzazione si concretizzano nelle Politiche di sicurezza e nei Meccanismi di sicurezza, ovvero un insieme di regole e procedure che sanciscono a tutti i livelli quali azioni sono permesse e quali proibite. Pagina 13
1.2 Le proprietà della sicurezza dell informazione Sia nella letteratura accademica che nella pratica gli obiettivi della sicurezza dell'informazione sono normalmente descritti in termini di autenticazione, controllo degli accessi (o autorizzazione), confidenzialità (privacy e segretezza), integrità, responsabilità, non ripudio e disponibilità. I paragrafi seguenti forniscono una panoramica di ognuna delle proprietà appena elencate. 1.2.1 Autenticazione L autenticazione è il processo che permette di determinare con certezza l identità di un utente del sistema. Ovviamente questo processo può essere più o meno sicuro e di conseguenza la probabilità di autenticare correttamente un utente può essere più o meno alta a seconda delle differenti implementazioni del sistema. Generalmente un soggetto che desidera autenticarsi deve provare di conoscere un certo dato oppure deve possedere un determinato oggetto. Il sistema deve essere in grado di riconoscere queste informazioni come valide ed utilizzarle per identificare in modo univoco l utente. Va infine sottolineato il fatto che, anche se fino ad ora si è sempre parlato di utente, non è detto che questo sia necessariamente una persona, come la parola lascia intendere. Infatti a seconda del contesto in cui ci si trova ad operare è possibile autenticare ad esempio un applicativo, un calcolatore, un nodo di rete, un pacchetto IP ed altre numerose e disparate tipologie di entità. 1.2.2 Controllo degli accessi / Autorizzazione Il controllo degli accessi è il processo che permette di definire e controllare i diritti e i privilegi di accesso alle risorse e ai servizi del sistema. Questo processo necessita ovviamente di una qualche forma di autenticazione per poter funzionare, in quanto assume che l identità dell utente sia già stata verificata a monte. Quello che è necessario fare nell ambito del controllo d accesso è Pagina 14
verificare se un soggetto ha o meno i permessi per accedere a certi dati del sistema e/o compiere determinate operazioni su di essi. Questo è proprio il tema centrale della presente trattazione, se ne parlerà quindi ampiamente nei capitoli successivi. 1.2.3 Confidenzialità (privacy e segretezza) La confidenzialità è la proprietà che permette di garantire che l accesso alle risorse e ai servizi del sistema sia permesso solo alle entità autorizzate. Questa definizione in realtà può essere mal interpretata e può far pensare che la confidenzialità ed il controllo d accesso siano in pratica la stessa cosa. In realtà, mentre lo scopo del processo di autorizzazione è quello di bloccare l'accesso a risorse e servizi del sistema da parte di utenti non autorizzati, in questo caso il fine principale è quello di non permettere agli utenti non autorizzati di venire a conoscenza dell'esistenza di queste informazioni sensibili. I termini "privacy" e "segretezza" sono a volte utilizzati per distinguere tra la protezione dei dati personali degli utenti (privacy) e la protezione dei dati appartenenti all'organizzazione (segretezza). La confidenzialità è un concetto molto ben definito e la ricerca nel campo della sicurezza informatica si è spesso concentrata su questo punto, tanto che alle volte i termini confidenzialità e sicurezza sono stati perfino utilizzati come sinonimi. 1.2.4 Integrità L integrità consiste nel di garantire che non vengano eseguite modifiche non autorizzate ai dati protetti contenuti nel sistema. In altri termini l integrità si può definire come la capacità di un sistema di rendere possibile la modifica di risorse e dati solo a persone autorizzate, e anche a queste solo in modo autorizzato onde garantire la consistenza di questi dati con le funzioni gestite dal sistema. Secondo Clark e Wilson [7] l'integrità c'e' quando: "nessun utente del sistema, anche se autorizzato, è in grado di modificare dati, altrimenti i beni (le informazioni) dell'azienda andrebbero persi o corrotti." Pagina 15
Un'altra prestigiosa definizione di integrità dei dati si può trovare nell'orange Book [1]: "Integrità è quando i dati informatici sono identici ai dati dei documenti originali da cui sono stati estratti, e non sono esposti ad accidentali o maliziose alterazioni o distruzioni". In questo caso l'integrità è sinonimo di robustezza verso l'esterno. I dati raccolti in un sistema informatico dovrebbero riflettere esattamente delle realtà esistenti al di fuori del sistema informatico. Tuttavia è impossibile garantire questa proprietà unicamente attraverso meccanismi interni al sistema informatico. Per aggiungere maggiore confusione, alcune aree della sicurezza informatica hanno adottato la loro propria nozione di integrità; per esempio la sicurezza della comunicazione la definisce come: la rilevazione e correzione delle modifiche, imputazioni, cancellazioni o riproduzioni dei dati trasmessi, comprendendo manipolazioni e casuali errori di trasmissione. Si può osservare come, partendo da questa posizione, la presenza (o assenza) di una struttura di autorizzazione non incida sulla natura del problema da risolvere, né sui rispettivi meccanismi di sicurezza. Come si può notare dalle definizioni appena riportate, è' abbastanza difficoltoso dare una caratterizzazione precisa di integrità. In generale il termine integrità vuol dire assicurarsi che tutto sia come deve essere. Restringendo il campo nei confini della sicurezza informatica, quello che si deve fare in pratica è prevenire "scritture" non autorizzate. L integrità risiede dunque nell "essere autorizzati a fare ciò che stiamo facendo" e nel "seguire le corrette procedure". Di fatto l'integrità è spesso un prerequisito per altre proprietà della Sicurezza. Per esempio un attaccante potrebbe cercare di aggirare i controlli per la confidenzialità modificando il sistema operativo o la tavola di controllo degli accessi referenziata dal sistema operativo. Quindi aver protetto l'integrità del sistema operativo o della tavola di controllo accessi permette ad esempio la confidenzialità. 1.2.5 Responsabilità & Non ripudio La responsabilità è la proprietà che permette di ricollegare ogni singola azione sull informazione contenuta nel sistema al soggetto che l ha compiuta. Pagina 16
È possibile trovare questo requisito, particolarmente importante nel mondo del commercio elettronico, in un documento storico come l'orange Book: "Responsabilità significa controllare le informazioni in modo selettivo e protetto, così che azioni che influenzano la sicurezza possano essere ricollegate al diretto responsabile". Per essere in grado di soddisfare questo requisito il sistema deve prima di tutto identificare ed autenticare l'utente, ma oltre a questo deve mantenere una "traccia di verifica" degli eventi rilevanti per la sicurezza. Infatti se si verificasse una violazione della sicurezza, le informazioni raccolte nella traccia di verifica devono permettere di identificare il colpevole ed i passi che quest ultimo ha compiuto per compromettere il sistema. A questo punto entra in gioco la proprietà del non ripudio, che assicura l impossibilità da parte di chi ha prodotto dei dati di negare della creazione di questi ultimi. Si può dunque affermare che la responsabilità implica il non ripudio, in quanto non è possibile identificare un utente come origine di un azione dannosa per la sicurezza del sistema, se non si può provare con certezza la sua colpevolezza. 1.2.6 Disponibilità Secondo la definizione del CTCPEC (Canadian Trusted Computer Product Evaluation Criteria) [91] la disponibilità è "la proprietà secondo cui le informazioni sono sempre accessibili senza eccessivi ritardi quando necessario". Le definizione ISO (International Organization for Standardization) [92] è quasi identica: è la proprietà delle informazioni di essere accessibili ed utilizzabili a richiesta di un ente autorizzato. Nel contesto della sicurezza si vuole dunque assicurare che la prevenzione nei confronti degli attaccanti non impedisca agli utenti legittimi di avere un accesso ragionevole ai loro sistemi. Questo per prevenire disturbi del servizio. Allargando in questo campo la definizione ISO, la prevenzione diventa finalizzata a rendere sempre disponibile l'accesso autorizzato alle risorse senza comportare dei ritardi nelle operazioni time-critical. Infatti sono abbastanza frequenti attacchi che paralizzano un server per sovraccarico di richieste di connessione "bloccando" la Pagina 17
disponibilità delle informazioni, con gravi conseguenza per le realtà in cui la disponibilità è l'aspetto principale della sicurezza informatica. Va infine sottolineato il fatto che la disponibilità è in qualche modo un obiettivo in conflitto con i precedenti, in quanto impone che il sistema non solo debba garantire l accesso soltanto agli utenti autorizzati, ma che allo stesso tempo non possa mai negare l'autorizzazione per un accesso corretto. Inoltre, l'accesso deve essere consentito tempestivamente, dove la definizione esatta di tempestivamente dipende dal dominio del problema. Esiste in letteratura il concetto di Maximum Waiting Time proprio introdotto a questo proposito. È necessario prestare dunque attenzione ai casi in cui una sicurezza troppo "stretta" rischia di generare di per sé stessa disturbi/ritardi del servizio. Spesso vengono utilizzati i termini exposure per indicare il fallimento nella condizione di confidenzialità, compromise per il fallimento nella relazione di integrità, e denial of service per la mancanza di disponibilità. 1.3 Politiche, modelli e meccanismi Come già anticipato il progetto relativo alla tesi si inserisce nell ambito del controllo d accesso. Quando si prende in considerazione un qualsiasi sistema di controllo d accesso, bisogna tenere presente tre aspetti differenti: 1. la politica di controllo d accesso 2. il modello di controllo d accesso 3. il meccanismo di controllo d accesso La politica (o policy ) non è altro che un insieme di requisiti, che specificano come dev essere gestito l accesso alle informazioni, ovvero chi e in quali circostanze può fare che cosa su di esse. Le politiche di controllo d accesso sono molto varie e cambiano anche in modo netto da un applicazione all altra. Inoltre sono dinamiche per natura, poiché cambiano nel tempo per riflettere l evoluzione dei diversi fattori economici, legali e sociali, che influenzano le organizzazioni alle quali si devono applicare. Ad ogni modo, poiché le politiche non possono essere determinate con esattezza in anticipo, i sistemi di controllo d accesso devono essere progettati per poter essere configurati e personalizzati, in modo da Pagina 18
essere abbastanza flessibili per potersi adattare ad una grande varietà di politiche di accesso. Per rendere operative le direttive di una politica è necessario definire dei meccanismi di controllo d accesso, che traducano in atto i requisiti specificati da queste ultime. Vi sono numerosi meccanismi di controllo d accesso, ognuno dei quali comporta dei vantaggi e degli svantaggi in termini di flessibilità e capacità di adattarsi certe tipologie di politiche. In generale un meccanismo richiede che vi siano degli attributi di controllo d accesso per utenti e risorse, come ad esempio degli identificatori, delle etichette o più in generale dei metadati. Questi elementi vengono utilizzati dalla logica di controllo per verificare se un utente ha o meno il diritto di compiere una certa operazione su un oggetto protetto del sistema. Ovviamente, affinché ciò avvenga, devono essere state specificate a priori delle regole che il meccanismo va a verificare ogni volta che è necessario. Le modalità con cui questo insieme di regole si può definire, modificare e controllare sono un fattore discriminante per valutare la flessibilità e l efficacia di un meccanismo di controllo d accesso. Per analizzare un sistema di controllo d accesso e per valutarne la caratteristiche è tuttavia preferibile ragionare su qualcosa di più astratto e concettuale di un meccanismo. A questo scopo viene definito un modello di controllo d accesso. Generalmente i modelli vengono descritti in modo da prevedere numerose scelte implementative, fornendo un framework concettuale sul quale ragionare per capire quali requisiti delle politiche di controllo d accesso essi possono supportare. I modelli sono di interesse sia per gli utenti finali, che per i produttori di software, in quanto facilitano la comunicazione fra questi ultimi essendo una sorta di linguaggio intermedio comprensibile da entrambi. Sono quindi un ponte tra il livello di astrazione delle politiche e quello dei meccanismi di controllo d accesso. Gli utenti vedono i modelli come un modo non ambiguo di definire i requisiti di controllo d accesso, mentre i produttori di software li utilizzano come specifiche di design ed implementazione. Pagina 19
1.4 Gli obiettivi della tesi Nei paragrafi precedenti si è cercato di fornire una panoramica delle diverse problematiche che comporta la gestione di un qualunque sistema informatico dal punto di vista della sicurezza. Quello che si voleva mettere in luce è la grande complessità della materia, che oltre ad abbracciare una vasta gamma di argomenti, non è ancora formalmente consolidata in molte sue aree. La continua evoluzione tecnologica e la proposta incalzante di modelli teorici sempre più articolati rendono il lavoro certamente più interessante, ma allo stesso tempo lo complicano notevolmente. I contributi maggiori per la sicurezza informatica si sono avuti finora dalla crittografia, una scienza che ha una storia alle spalle e che quindi ha avuto il tempo di consolidarsi negli anni, anche se non bisogna dimenticare che gli studi in materia sono ancora molto produttivi ed hanno ricevuto un grande impulso proprio negli ultimi tempi. Purtroppo la crittografia non viene in aiuto quando si parla di controllo d accesso, in quanto si applica solamente ad alcune delle proprietà descritte nei paragrafi precedenti, quali l autenticazione, l integrità, la confidenzialità e il non ripudio. Il problema dell autorizzazione è stato forse quello più trascurato, anche se ovviamente non sono mancati studi in questo campo. Tuttavia negli ultimi anni c è stata un inversione di tendenza e un attenzione sempre maggiore si è concentrata sul controllo d accesso. Il motivo principale è da ricercarsi nelle dimensioni sempre crescenti dei sistemi informatici soprattutto in ambito civile, commerciale ed industriale, che ha evidenziato come le tecniche finora implementate non fossero del tutto adeguate per la gestione di questi tipi di applicazioni. A questo si aggiunge l introduzione di normative volte alla tutela della riservatezza dei dati e della privacy degli utenti, che le aziende si trovano a dover rispettare in tempi molto brevi. Per tutti questi motivi la perdita di risorse, espressa in ore uomo, per la gestione e l amministrazione dei sistemi informatici si è fatta sempre maggiore e la necessità di studiare nuove tecniche per migliorare la situazione si è fatta più pressante rispetto al passato, essendo ora spinta anche da esigenze economiche. Pagina 20
Si arriva dunque all argomento centrale della tesi, ovvero al controllo d accesso basato su ruoli, l RBAC (Role Based Access Control). Questo modello è stato proposto per la prima volta agli inizi degli anni Novanta per venire incontro alle esigenze delle organizzazioni commerciali e governative. Nel decennio scorso però non ebbe un grande successo e gli studi sull argomento non vennero seguiti con l attenzione che meritavano. Soltanto negli ultimi anni l interesse su questa tecnologia è cresciuto notevolmente e numerosi ricercatori stanno dando il loro contributo per migliorarla sempre più e portarla ad uno stadio maturo e consolidato. Come si sarà certamente capito si è ancora lontani dalla definizione di uno standard RBAC general-purpose e la presente trattazione si pone come primo obiettivo quello di fornire un modello RBAC il più aggiornato possibile, elaborando una sintesi degli studi attualmente in corso sulla materia. In secondo luogo si vuole fornire un implementazione del modello affinché si possa utilizzare in un application server J2EE (Java 2 Enterprise Edition) il controllo d accesso basato su ruoli. Gli obiettivi del presente lavoro possono essere definiti in modo più dettagiato come segue: Studiare un modello di controllo d accesso basato su ruoli generalpurpose, che inglobi tutte le caratteristiche dei modelli più recentemente sviluppati; Proiettare il modello elaborato su un insieme di interfacce organizzate ordinatamente in diversi packages (in linguaggio Java); Fornire un implementazione in linguaggio Java del modello per un application server J2EE (Java 2 Enterprise Edition); Sviluppare una piccola applicazione di prova per testare il funzionamento del sistema. 1.5 Il piano di lavoro Il piano di lavoro da seguire per portare a termine il progetto illustrato nel paragrafo precedente prevede innanzitutto uno studio approfondito sia dei modelli di controllo d accesso tradizionali, sia di quelli relativi al tema centrale della tesi, Pagina 21
ovvero all RBAC. Si cercherà di porre l attenzione sull evoluzione temporale dei diversi modelli, mettendone in luce le novità, i pregi ed i difetti. Terminata questa fase si procederà ad un analisi critica del modello RBAC così com è stato elaborato nella sua ultima versione, illustrandone gli aspetti ancora critici e passando in rassegna gli ultimi sviluppi nei diversi settori di ricerca. Alla luce degli studi effettuati, sarà infine possibile proporre un proprio modello generalpurpose di controllo d accesso basato su ruoli. A questo punto si potrà passare all implementazione e al testing dello standard RBAC definito, in modo da poterne valutare l efficacia. La tabella seguente mostra nel dettaglio le diverse attività del piano di lavoro e fornisce un indicazione percentuale del carico di lavoro assegnato a ciascuna di esse. Attività Carico di lavoro (%) Studio ed analisi dei sistemi di controllo d accesso tradizionale 5 Studio ed analisi dei modelli di controllo d accesso basato su ruoli proposti in passato. 20 Analisi critica dello standard RBAC 20 Definizione a seguito degli studi effettuati di un proprio standard RBAC general-purpose 20 Studio delle tecnologie J2EE 10 Implementazione del modello adottato 20 Sviluppo di un applicazione di testing 5 TOTALE 100 Tabella 1-1. Piano di lavoro Pagina 22
CAPITOLO 2 IL CONTROLLO D ACCESSO TRADIZIONALE Questo capitolo ha lo scopo di introdurre al controllo d accesso. Innanzitutto viene definito un background terminologico di base, al fine di poter descrivere con proprietà di linguaggio un modello di controllo d accesso. In secondo luogo vengono illustrati i principi fondamentali, che stanno alla base di questa disciplina. Infine viene presentata un breve storia del controllo d accesso, in modo da poter apprezzare l evoluzione tecnologica che ha portato alla definizione del controllo d accesso basato su ruoli, ovvero l argomento centrale della presente trattazione. Pagina 23