:: ESP - Lezione del 4 florile 216 (23 aprile 2008) ::
Torna alla pagina di ESP
Chinese Wall
Voglio prevenire i flussi di informazione che causano conflitti di interesse. Per focalizzare il problema, immaginiamo uno scenario con:
- oggetti
- company dataset = insieme di oggetti che riguardano una certa organizzazione o compagnia
- classi di conflitto = un gruppo di dataset
Il chinese wall fornisce regole, anche se non ben formalizzate, per controllare gli accessi, considerando che all'interno di una classe di conflitto le diverse organizzazioni sono in competizioni.
Questo vuol dire che se un utente legge un oggetto di una compagnia, il sistema non deve permettergli di accedere ad altre compagnie. Ci pensa il sistem automaticamente a bloccare i successivi accessi.
L'idea di per sé è carina, però c'è il problema che se tutti gli utenti leggono da una parte, nessuno può più andare dall'altra!
A parte questo problema, la separazione dinamica dei privilegi introdotta dal chinese wall ha degli aspetti positivi. Essa può essere statica o '''dinamica.
La separazione statica viene assegnata a priori agli utenti, e si fa in modo che gli utenti non abbiano troppi privilegi.
Quella dinamica invece è calcolata automaticamente dal sistema: se un utente sceglie di compiere certe azioni, automaticamente altre gli saranno negate.
L'esempio che ci ha fatto Maria Antonietta è quello di una transazione che richiede 4 operazioni. Se si forzano gli utenti a poter eseguire al massimo 2 di queste operazioni, ecco che per compiere l'intera operazione servono almeno 2 utenti, per maggiore sicurezza. Così facendo si evita di addensare nelle mani di un solo utente tutti i poteri.
Politiche basate sui ruoli
Le politiche basate sui ruoli cambiano il punto di vista che abbiamo adottato finora.
Fino a questo momento abbiamo detto: un utente vuole fare qualcosa, quindi a quell'utente assegno dei privilegi, con tutti i vari problemi che abbiamo visto.
Ora invece la prospettiva si ribalta: invece di pensare all'utente, si pensa alle applicazioni o task che gli utenti devono compiere. In base all'applicazione che un'utente deve compiere, esso deve assumere un certo ruolo.
Il ruolo è quindi un insieme di azioni e responsabilità legate ad una particolare attività relativa.
Questo sistema dei ruoli è stato inventato la prima volta in NPD, Named Protection Domain, un affare sviluppato per SQL.
Un ruolo è così definito:
Ruolo = {oggetto, azione}
Come si vede, non c'è il soggetto, perché non serve. Sarà l'utente che impersona quel ruolo a diventare abilitato a compiere quell'azione su quell'oggetto.
L'utente è autorizzato ad attivare ruoli.
Il ruolo è autorizzato ad accedere ad oggetti.
Quando un utente attiva un ruolo, si prende i privilegi del ruolo.
Da notare che i gruppi sono un concetto distinto rispetto al ruolo. Un utente è sempre membro di un gruppo, mentre un ruolo può essere assunto temporaneamente, per poi dismetterlo se si vuole assumerne un altro.
Generalmente i ruoli vengono messi in gerarchie di specializzazione, in cui un ruolo può anche avere più di un genitore. Ci sono due modi per propagare le autorizzazioni per la gerarchia:
- i privilegi in alto sono trasmessi in basso a tutti i sottoruoli
- un utente può attivare tutti i privilegi dei ruoli di cui è sottoruolo
Ecco i vantaggi dei ruoli:
- si semplifica la gestione dei privilegi, perché non devo darli a tutti gli utenti, ma ai ruoli
- la gerarchia dei ruoli mi aiuta nel distinguere chi (inteso come ruolo) può fare cosa
- posso assegnare restrizioni ai ruoli stessi
- principio di least privilege = assegno ad un ruolo il minimo indispensabile per eseguire il suo compito, limitando gli abusi
- principio di separazione dei privilegi, che è quello che abbiamo visto sopra: se divido le operazioni in diversi task, allora serviranno diversi ruoli.
Un problema riguarda invece la propagazione. Qualsiasi strategia io usi, il sistema dei ruoli non distingue tra chi impersona un ruolo. Questo vuol dire che qualsiasi persona attivi un ruolo, avrà i permessi di quel ruolo, e non c'è modo di dire quale utente ha attivato quel ruolo.
ANSI RBAC
RBAC = Role Based Access Control. È la standardizzazione ANSI delle politiche basate sui ruoli.
RBAC contiene tutti gli elementi visti finora, con il concetto di sessione: un utente entra in una sessione attivando un ruolo; per assumerne altri deve uscire dalla sessione.
Supporta un legame molti-a-molti tra utenti e ruoli, e tra privilegi e ruoli.
Le gerarchie sono opzionali. Possono essere generali o limitate:
- gerarchia generale = la "forma" della gerarchia non è necessariamente un albero
- gerarchia limitata = la forma è un albero, anche inverso
Gerarchie o no, c'è comunque sempre disponibile la separazione dei privilegi che abbiamo visto prima. Può essere assegnata ai nodi della gerarchia, oppure stabilita in base agli utenti.
Ci sono anche i role set: un utente ha un numero massimo di ruoli che può attivare all'interno di un dato role set, cioè un insieme di ruoli. Per esempio, se ho (roleset, 3) vuol dire che l'utente può assumere al max 2 su 3 ruoli. In questo modo applico la separazione dei privilegi.
Se voglio invece la separazione dinamica, i vincoli sui roleset possono applicarsi anche attraverso più sessioni.
Torna alla pagina di ESP
