Università degli Studi di Bologna IIª Facoltà di Ingegneria - Cesena TECNICHE DI CONTROLLO D ACCESSO OUTLINE Introduzione alle tecniche di controllo d accesso Discretionary Access Control (DAC) Mandatory Access Control (MAC) Role Based Access Control (RBAC) Ing. Ambra Molesini DEIS 051.20.93541 ambra.molesini@unibo.it CONTROLLO D ACCESSO Processo attraverso il quale ad un soggetto viene esplicitamente accordata o negata la possibilità di accedere ad una risorsa Controllo d accesso per: Escludere accessi fraudolenti o scorretti Preservare integrità e riservatezza Lasciare inalterata la disponibilità della risorsa per chi è autorizzato Il PROCESSO Lo sviluppo del processo si svolge in tre passi: Definizione del modello del sistema da controllare evidenziando solo i fattori critici dal punto di vista dell accesso Definizione della politica di accesso stabilire le norme attraverso cui l accesso verrà regolato Implementazione della politica Utilizzo di opportuni meccanismi hardware e/o software SEPARAZIONE TRA POLITICHE E MECCANISMI Mantenere su piani logici separati politiche e meccanismi introduce una indipendenza tra i requisiti di protezione che devono essere applicati e i meccanismi che li applicano Benefici per il progettista: è possibile comparare politiche di accesso differenti indipendentemente dalla loro realizzazione facilitazioni nella gestione del sistema di controllo: possibilità di lavorare a diversi livelli di astrazione progettare meccanismi su cui implementare politiche diverse identificare una serie di proprietà minime, sia per le politiche che per i meccanismi, che ogni sistema di controllo dovrebbe soddisfare CARATTERISTICHE DEI MECCANISMI Resistente alla manomissione Non deve essere possibile sabotarlo senza che nessuno se ne accorga Principio di mediazione completa Ogni accesso alla risorsa deve essere verificato e autorizzato dal meccanismo Piccolo e autocontenuto agire rapidamente in caso di guasti e semplici fasi di testing Costo complessivo non deve superare quello del danno che potrebbe comportare l accesso non autorizzato
CARATTERISTICHE DELLE POLITICHE Principio del privilegio minimo: qualsiasi accesso deve avvenire con le minime autorizzazioni Consistenza risoluzione di situazioni di conflitto in cui per la stessa richiesta di accesso esistono più autorizzazioni contrastanti Completezza e correttezza Ogni richiesta di accesso abbia esattamente una risposta in un tempo finito Stabilire una regola di default nel caso non ci sia nessuna autorizzazione Politica: norme + direttive amministrative per la gestione della modifica delle norme IL PROBLEMA DELLA CONSISTENZA Tale problema non ha un unica soluzione, esistono più tecniche: Autorizzazione più specifica: si applica sempre la politica più specifica Autorizzazione positiva/negativa: in caso di conflitti viene sempre concesso/impedito l accesso Criteri posizionali spazio/temporali: si applica l autorizzazione che spazialmente viene prima (o dopo) tutte le altre nella lista di autorizzazioni, oppure quella che è stata concessa meno (o più) di recente delle altre Criteri basati sull identità di chi ha concesso le autorizzazioni: stabilire scala gerarchica agli amministratori. In caso di conflitto viene applicata l autorizzazione concessa dall amministratore più alto in gerarchia REGOLA DI DEFAULT Sistemi closed policy La situazione di default per il sistema è la mancanza di diritto d'accesso Lo schema di protezione identifica poi quale sono le situazioni in cui l'accesso è invece permesso. Questo significa che se l'accesso a una risorsa non è espressamente autorizzato, allora non è autorizzato affatto Questa regola è adatta in quei sistemi in cui le risorse sono moltissime e c'è il rischio di non riuscire a stabilire una politica adeguata per quelle utilizzate meno frequentemente delle altre Sistemi open policy tutto ciò che non è espressamente vietato, allora non è vietato affatto PARAMETRI PER LE DECISIONI DI ACCESSO Definire una politica e implementarla attraverso un meccanismo non si riduce nella semplice soddisfazione delle proprietà dette E necessario includere norme legislative e organizzative e valutare quali parametri utilizzare per applicare le decisioni di accesso: Identità del soggetto : è il parametro più diffuso con cui prendere le decisioni di autorizzazione, basato semplicemente sull'identità del soggetto che richiede l'accesso alla risorsa Ruolo del soggetto richiedente: all'interno di un'organizzazione ogni persona appartiene a uno o più gruppi, cioè ricopre uno o più ruoli, e i permessi di accesso alle varie risorse sono condivisi da tutte le persone che ricoprono lo stesso ruolo PARAMETRI PER LE DECISIONI DI ACCESSO Tipo di accesso: si intende l'operazione che si ha intenzione di compiere sulla risorsa. Il soggetto richiedente non deve solo specificare a quale risorsa vuole accedere, ma anche che tipo di uso intende farne Parametri spazialo e/o temporali: L'accesso a particolari risorse può essere limitato in base al luogo in cui si trova il soggetto al momento della richiesta, o al momento in cui avviene la richiesta. Storia degli accessi passati: si può tenere traccia di quanti accessi un utente ha già effettuato in passato e anche di come e quanto ha utilizzato le risorse per avere maggiore flessibilità nel controllo MODELLI PER LE POLITICHE DI ACCESSO Le ricerche condotte negli anni passati hanno portato a delineare due tipologie fondamentali di modelli per il controllo degli accessi: Modelli basati su controllo d accesso a discrezione (DAC Discretionary Access Control ) Modelli basati su un controllo d accesso obbligatorio (MAC Mandatory Access Control) Role Based Access Control (RBAC)
POLITICHE DAC Le politiche di tipo DAC sono basate essenzialmente sull identità del soggetto che richiede l accesso alla risorsa e sul tipo di accesso richiesto DAC POLITICHE DAC Discrezione : ogni soggetto che possiede autorizzazioni può passarle ad altri soggetti, nei limiti permessi dal sistema Il modello di base di queste politiche è quello della matrice di controllo d accesso È una struttura dinamica : soggetti ed oggetti possono essere creati dinamicamente un diritto può essere esercitato solo ad un certo istante purchè siano avvenute altre azioni in precedenza MATRICE DI CONTROLLO D ACCESSO S = {S 1, S 2,..., S m } : insieme dei soggetti interessati ad accedere alle risorse R = {R 1, R 2,..., R n } : insieme delle risorse del sistema O : operazioni che si possono compiere sulle risorse Per ogni possibile utente e risora si individua il sottoinsieme di operazioni O i,j Є O che l utente può compiere su quella risorsa Se la cella (i,j) è vuota l utente i ha sempre accesso negato alla risorsa j (modello closed policy) MATRICE DI CONTROLLO D ACCESSO ESEMPIO R 1 R 2... R n S 1 O 11 O 12... O 1n S 2 O 21 O 22... O 2n............... S m O m1 O m2... O mn
OPERAZIONI Tra le varie operazioni che possono essere specificate ve ne sono due valide per qualsiasi risorsa: Control: il soggetto può passare qualsiasi sottoinsieme delle proprie operazioni sulla risorsa ad altri soggetti, ma non l operazione control Control*: il soggetto può passare qualsiasi sottoinsieme delle proprie operazioni sulla risorsa ad altri soggetti, compresa l operazione control* (o soltanto control) Queste operazioni, al contrario delle altre, sono soggette a politiche amministrative che portano a specializzazioni del modello DAC di base Controllo gerarchico: SPECIALIZZAZIONI L amministratore del sistema divide inizialmente gli utenti in sottogruppi logici Le operazioni di control o control* vengono assegnate solo ad un referente per ogni gruppo Il referente diventa l amministratore del sottogruppo e a sua volta potrà se necessario (e se possiede l operazione control*) dividere il sottogruppo in ulteriori gruppi più piccoli e assegnare l operazione control* ai vari responsabili Si individua così un albero di controllo che in genere riflette la struttura gerarchica dell organizzazione in cui si opera Controllo per proprietario: SPECIALIZZAZIONI Le risorse spesso sono create dinamicamente e ad ognuna di esse è associato un proprietario (di solito colui che la crea) Al proprietario è data di default l operazione di control (controllo gerarchico a soli due livelli) Il proprietario può modificare da solo le proprie operazioni permesse, ovviamente per le sole risorse di cui è proprietario Esempio: file system di UNIX Controllo laissez-faire: SPECIALIZZAZIONI Ogni utente che possiede l operazione control* può passarla a ogni altro utente senza alcuna limitazione Il più semplice da implementare e il più difficile da gestire Controllo centralizzato: Solo l amministratore del sistema ha la possibilità di distribuire le operazioni control e control* Possibile supervisionare accuratamente le modifiche alla politica di accesso Carica di molto lavoro l amministratore ritardi e/o errori nell aggiornamento della politica SAFETY PROBLEM Data una matrice iniziale nota, esiste una sequenza di comandi che porta un utente a poter avere dei privilegi su una risorsa che normalmente non dovrebbe avere? Nel caso generico questo problema è indecidibile (può essere ricondotto al problema dell halt della macchina di Turing) Diventa decidibile quando al sistema non possono essere aggiunti dinamicamente soggetti e/o oggetti In questi casi infatti bisogna analizzare un numero finito di configurazioni della matrice d accesso IMPLEMENTAZIONE DELLA MATRICE Nella pratica non viene mai implementata perché è probabile che sia sparsa (molte celle vuote spreco di memoria) Sono stati individuati diversi metodi per risolvere il problema: Tabella di autorizzazione: vengono riportate in una tabella a 3 colonne {soggetto, risorsa, autorizzazione} le sole celle della matrice non vuote. Molto usata nei DBMS relazionali. Access Control List (ACL): la matrice è rappresentata per colonne. Ad ogni risorsa è associata una lista che contiene, per ogni soggetto, le autorizzazioni che questo ha sulla risorsa Capabilities: duale ad ACL, matrice rappresentata per righe
POLITICHE MAC Le politiche di tipo MAC realizzano il controllo sulla base di regole impostate da un autorità centrale. MAC Ad ogni soggetto e ad ogni risorsa viene assegnata una classe d accesso costituita da un livello di sicurezza: insieme totalmente ordinato che rispecchia i differenti gradi di sicurezza del sistema (es: {TopSecret Secret Confidential Unclassified } ) un insieme di categorie: una categoria è un insieme non ordinato che riflette le aree funzionali di un sistema (es: {Armi ordinarie, Armi nucleari} ) POLITICHE MAC RELAZIONE DI DOMINANZA E possibile definire una relazione di dominanza fra classi: date due classi d accesso c1 e c2 c1 domina c2 (c1 c2) se e solo se il livello di sicurezza di c1 è maggiore uguale a quello di c2 e le categorie di c1 includono tutte quelle di c2 c1 e c2 sono non confrontabili se c1 non domina c2, nè c2 domina c1 Le classi di accesso vanno così a formare un reticolo Per questo spesso le politiche MAC vengono dette LBAC (Lattice Based Access Control) o MLS (Multi Level Security) RETICOLO DI CLASSI D ACCESSO CARATTERISTICA DI SICUREZZA L uso delle classi d accesso assegnate a soggetti e risorse è diverso in base alla caratteristica di sicurezza che è più importante preservare: riservatezza o integrità Le politiche orientate alla riservatezza controllano il flusso diretto e indiretto di informazioni al fine di prevenirne il passaggio tra livelli con differenti requisiti di sicurezza Le politiche orientate all integrità controllano le modifiche alle risorse
POLITICHE ORIENTATE ALLA RISERVATEZZA Il livello di sicurezza della classe di accesso assegnata ad ogni risorsa rappresenta la criticità dell informazione contenuta dalla risorsa Il livello di sicurezza associato ad ogni utente rappresenta il suo grado di affidabilità nel non rivelare le informazioni ad utenti non autorizzati Le categorie definiscono le aree di competenza di utenti e risorse e sono usate per rendere più accurata la politica Due principi devono sempre essere verificati... NO-READ-UP PRINCIPI Un utente può accedere in lettura ad una risorsa se e solo se la classe d accesso dell utente domina la classe d accesso della risorsa NO-WRITE-DOWN Un utente può accedere in scrittura ad una risorsa se e solo se la classe d accesso dell utente è dominata dalla classe d accesso della risorsa Il rispetto dei due principi garantisce la segretezza delle informazioni ESEMPIO George (TOPSECRET, {Nuclear}); Doc A (CONFIDENTIAL, {Nuclear}); Doc B (TOPSECRET, {Nuclear}); Doc C (TOPSECRET, {Army, Nuclear}); George accede in lettura a Doc A ma non in scrittura La classe d accesso di George domina quella di di Doc A, ma non viceversa George accede sia in scrittura che in lettura a Doc B La classe d accesso di George domina quella di Doc A, e viceversa George accede in scrittura a Doc C ma non in lettura La classe di accesso di George è dominata da quella di Doc C POLITICHE ORIENTATE ALL INTEGRITA Nei modelli appena discussi non viene protetta in alcun modo l integrità delle informazioni Non viene impostato nessun controllo sulle scritture a patto che esse avvengano su risorse di classi di sicurezza maggiori di quella dell utente che le effettua Il modello iniziale viene così esteso enunciando due principi duali, orientati a preservare l integrità... PRINCIPI NO-READ-DOWN Un utente può accedere in lettura ad una risorsa se e solo se la classe d accesso dell utente è dominata dalla classe d accesso della risorsa NO-WRITE-UP Un utente può accedere in scrittura ad una risorsa se e solo se la classe d accesso dell utente domina la classe d accesso della risorsa I due modelli non sono in contrasto tra loro possono essere applicati contemporaneamente: ad ogni soggetto e risorsa viene assegnata una classe di accesso per la sicurezza e una per l integrità RBAC
POLITICHE RBAC POLITICHE RBAC Sistemi di tipo Role Based Access Control (RBAC) assegnano i privilegi non agli utenti, ma alla funzione che questi possono svolgere nel contesto di una certa organizzazione L unte acquista quindi privilegi assumendo uno o più ruoli RBAC RBAC è policy neutral, questo gli consente di supportare facilmente i tre ben conosciuti principi di sicurezza: Minimo privilegio (Least Privilege ) Separazione dei compiti (Separation of duties): l utilizzo di ruoli mutuamente esclusivi potrebbe essere necessario in certe situazioni critiche (evitare che il controllato sia anche il controllore ) Astrazione dei dati (Data abstraction): invece dei tipici permessi read, write, execute utilizzati nei sistemi operativi, possono essere stabiliti permessi astratti come per esempio crediti e debiti RUOLO In RBAC un ruolo è visto come un costrutto semantico attorno al quale vengono formulate le politiche di controllo d accesso Il concetto di ruolo ha diversi significati: rappresenta la competenza nel compiere una specifica attività (per esempio farmacista o fisico ) incorpora sia l autorità che la responsabilità (per esempio responsabile di progetto ) RBAC Un sistema RBAC correttamente amministrato fornisce una grande flessibilità agli amministratori di sistema con il minimo sforzo: I ruoli nell organizzazione sono praticamente fissi, o variano molto raramente Stabiliti inizialmente i permessi per ogni ruolo... Tutto quello che deve fare l amministratore è gestire l assegnazione degli utenti ai ruoli Questo si traduce in un grande vantaggio rispetto alle politiche DAC e MAC LO STANDARD Di recente RBAC è stato standardizzato come ANSI/INCITS 359-2004 In questo documento vengono proposti quattro modelli in modo incrementale
CORE RBAC In questo primo modello vengono definiti solo gli elementi essenziali senza i quali non è possibile implementare un controllo d accesso. CORE RBAC: DETTAGLI Utente: tipicamente è un umano ma potrebbe per esempio essere anche un agente software Ruolo: è una funzione lavorativa all interno di un sistema (organizzazione) che descrive le autorità e le responsabilità conferite al membro del ruolo Permesso: è l approvazione di un particolare modo di accesso ad uno o più oggetti (risorse) del sistema (organizzazione) Sessione: l utente stabilisce una sessione durante la quale può attivare un sottoinsieme dei ruoli che gli appartengono. Ogni sessione mappa un utente sui possibili ruoli che può attivare CORE RBAC: DETTAGLI Se per un dato utente esiste una relazione con un ruolo, non vuol dire che l'utente appartenga a quel ruolo sempre, ma solo che in generale gli è permesso di farne parte L utente assumerà quel ruolo solo attivando la corrispondente sessione (e lo abbandonerà disattivandola). Ad ogni sessione è associato un solo utente, ad un utente possono essere associate più sessioni anche contemporaneamente Un utente può creare una o più sessioni, all'interno di ognuna delle quali può attivare uno o più ruoli, scegliendo tra quelli che gli sono stati messi a disposizione I permessi disponibili all utente sono l unione dei permessi associati ai ruoli che sono attualmente attivi nella sessione CORE RBAC: DETTAGLI Non esiste il permesso di compiere un'operazione in generale, ma, per ogni risorsa, esiste un permesso per ogni singola operazione che è possibile eseguire su di essa. È evidente che la stessa operazione può essere associata a risorse diverse Implementare un modello Core RBAC vuol dire fornire un sistema con cui è possibile interagire mediante: Funzioni di amministrazione (creare e rimuovere utenti, ruoli, risorse permessi...) Funzioni di supporto (creare sessioni, aggiungere/rimuovere ruoli attivi) Funzioni di monitoraggio (controllare il sistema) RBAC GERARCHICO Una gerarchia è un modo naturale di strutturare i ruoli all'interno di una organizzazione che rispecchia l'effettiva responsabilità e autorità di ognuno RBAC GERARCHICO Per tenere conto di queste situazioni molto comuni è stato introdotto il modello RBAC Gerarchico che estende il Core RBAC introducendo una relazione gerarchica tra ruoli A questa gerarchia di ruoli corrisponde di solito una effettiva ereditarietà di permessi, ovvero, salendo nella gerarchia, i vari ruoli possiedono tutti i permessi dei ruoli sottoposti, oltre ai propri
RBAC GERARCHICO: DETTAGLI Il significato di tale relazione è: Dati due ruoli r1 ed r2, r1 eredita il ruolo r2 se ogni permesso del ruolo r2 è anche un permesso del ruolo r1 La relazione è di tipo molti-a-molti per cui Un ruolo può ereditare i permessi da più ruoli Un ruolo può essere ereditato da più ruoli Lo standard non specifica nulla sul tipo di gerarchia ammessa, qualsiasi ordine parziale imposto sull insieme dei ruoli è valido Vengono estese le funzioni viste in precedenza al fine di poter gestire le relazioni gerarchiche RBAC CON VINCOLI SSD In organizzazioni in cui gli utenti possono assumere ruoli diversi è possibile che sorgano problemi di conflitti di interessi Esempio: un utente può assumere sia il ruolo di controllore che di controllato su una certa transazione Spesso vengono quindi imposti a priori dei vinccoli di separazione dei compiti (SSD- Static Separation of Duty) RBAC CON VINCOLI SSD RBAC CON VINCOLI SSD In RBAC è possibile definire vincoli SSD sia sulla relazione utente-ruolo che sulla relazione gerarchica tra ruoli: è possibile escludere a priori dei ruoli sia tra quelli assegnabili direttamente ad un certo utente, sia tra quelli da cui può ereditare dei permessi Un vincolo SSD è espresso come un insieme di coppie (rs,n) rs: è un sottoinsieme di ruoli n: è un numero intero maggiore di 1 Una coppia di questo tipo specifica che nessun utente può essere assegnato (direttamente o tramite ereditarietà) a n o più ruoli nel sottoinsieme rs Ruoli Mutuamente esclusivi VINCOLI TIPICI Allo stesso utente deve essere assegnato al massimo un ruolo di quelli presenti in un insieme mutuamente esclusivo Questo supporta il principio della Separazione dei compiti Esiste anche il vincolo duale che riguarda i permessi Lo stesso permesso deve essere assegnato ad al massimo un ruolo di quelli presenti in un insieme mutuamente esclusivo Questo permette di limitare la distribuzione del potere Cardinalità VINCOLI TIPICI Riguarda il massimo numero di membri appartenenti ad un ruolo La cardinalità minima in genere non viene considerata poiché è molto difficile da controllare Ruoli Prerequisiti Ad un utente può essere assegnato il ruolo A se e gli è già stato assegnato il ruolo B Questo vincolo è basato sulla competenza e appropriatezza Dualmente per i permessi Il permesso P può essere assegnato ad un ruolo solo se questo ruolo è già in possesso del permesso Q
CONSIDERAZIONI I vincoli sull assegnazione degli utenti sono efficaci solo se viene mantenuta una certa disciplina nella gestione dell assegnazione degli user identifiers agli umani (o agenti software) Se allo stesso individuo vengono assegnati più identificatori i controlli sulla cardinalità e sulla separazione dei compiti falliscono È indispensabile vi sia sempre un legame uno-a-uno tra gli identificatori e gli umani Le stesse considerazioni valgono anche per i permessi RBAC CON VINCOLI DSD Spesso i vincoli imposti staticamente sono troppo restrittivi per il sistema... Non si vuole limitare a priori il numero di ruoli che i vari utenti possono assumere, ma solo quelli che posso essere attivati contemporaneamente Oppure, i vincoli imposti staticamente potrebbero non bastare ed occorre introdurne altri in fase di esecuzione Per questo è stata introdotta una versione di RBAC con vincoli dinamici di separazione dei compiti (DSD- Dynamic Separation of Duty) Questi coinvolgono ovviamente il concetto di sessione, unico elemento che lega l utente al ruolo che assume RBAC CON VINCOLI DSD RBAC CON VINCOLI DSD Questa versione di RBAC supporta pienamente il principio del minimo privilegio Attraverso vincoli dinamici è possibile impedire che un utente attivi contemporaneamente più ruoli (e quindi acquisisca più privilegi) di quelli che gli sono strettamente necessari al momento Come per SSD, un vincolo DSD è espresso come un insieme di coppie (rs,n)