Gestione della politica locale di un dominio

Il meccanismo di controllo degli accessi realizzato dal Security Agent si basa sul modello RBAC (Role Based Access Control). Quando il Security Agent definisce la politica interna del proprio dominio non assegna i diritti di accesso ai singoli utenti, ma ai gruppi, che identifica con il nome assegnato loro dal Domain Administrator.

In questo modo tutti gli utenti, che appartengono allo stesso gruppo, hanno gli stessi diritti e se un utente cambia gruppo cambiano automaticamente i suoi diritti, poiché acquisisce quelli del gruppo di cui entra a far parte. Se il Security Agent modifica i diritti di un gruppo cambiano, di conseguenza, i diritti delle singole entità del gruppo.6

L’insieme di permessi associati ad un gruppo è dinamico poiché il Security Agent può introdurre per un gruppo nuovi permessi oppure ne può revocare alcuni già esistenti.

D’ora in poi faremo distinzione fra “ruolo” e “dominio”: infatti, anche se entrambi indicano un insieme di utenti raggruppati sotto un unico nome, nel caso di “ruolo” a questi utenti sono assegnati i medesimi diritti. In particolare, il nome del gruppo specificato in una autorizzazione indica un “ruolo” rispetto a chi la ha emessa e il nome del gruppo, presente in una delega, si riferisce ad un “dominio” rispetto allo issuer della delega stessa7.

La politica locale del Security Agent si basa su due tipi di regole: − regole assiomatiche

− regole derivate

6 _{Il Security Agent è libero di assegnare a gruppi diversi gli stessi diritti.}

7 _{L’issuer dell’autorizzazione o della delega può essere l’Owner, proprietario della risorsa,}

Fig 2.4 Richiesta di autorizzazione M!:Reg.assiomatica M2:ok M3:Rich.autorizz. per R M6:Autorizzazione M4:Rich. permessi M5:permessi group1 M7:Rich.autorizz .per R M8:Rich.permessi M9:permessi group2 M1. M2. M3. M4. M5. M6. M7. M8. M9. Policy-database del Security Agent di D Client B credential: B-group2 Security Agent del dominio D Client A credential: A-group1

Il Security Agent inserisce la nuova regola assiomatica: “Accesso a R consentito solo ai membri di group1, diritto di delega yes”

Messaggio di conferma: “E’ stata memorizzata la nuova regola”

ClientA richiede l’autorizzazione per l’accesso a R fornendo la credenziale che attesta l’appartenenza a group1

Il SecurityAgent richiede i permessi di ClientA in quanto membro di group1

Elenco dei permessi di ClientA = { accesso a R }

Il Security Agent fornisce a ClientA l’autorizzazione per l’accesso a R

ClientB richiede l’autorizzazione per l’accesso a R fornendo la credenziale che attesta l’appartenenza a group2

Il SecurityAgent richiede i permessi di ClientB in quanto membro di group2

Elenco dei permessi di ClientB = { }

Il Security Agent NEGA a ClientB l’autorizzazione per l’accesso ad R

Le prime sono stabilite direttamente dal Security Agent ed indicano per ciascun ruolo quali siano i diritti di accesso alla risorsa.

Per ognuna di queste regole il Security Agent specifica una ulteriore autorizzazione in cui indica se il ruolo è autorizzato o meno a trasferire i propri diritti. In questo modo i ruoli hanno la possibilità di modificare la politica locale del Security Agent tramite le regole derivate. Se un utente, che riveste uno di questi ruoli, decide di trasferire i propri diritti, inoltra la richiesta al Security Agent. Quest’ultimo controlla che l’utente in questione abbia i requisiti giusti per effettuare l’operazione e, in caso affermativo, aggiunge la nuova autorizzazione alle altre (regola derivata). Inoltre, nella richiesta l’utente specifica se le entità coinvolte nella nuova regola possono propagare ad altri i diritti che sono stati assegnati loro.

Le regole che costituiscono la politica sono dinamiche perché se ne possono aggiungere di nuove o eventualmente si possono rimuovere quelle già esistenti. Una regola può essere revocata per i seguenti motivi:

− gli utenti decidono di modificare la politica locale e nell’effettuare questa richiesta gli utenti devono dimostrare di rivestire il ruolo che l’ha generata in precedenza

− la regola, generata da un ruolo, deve essere cancellata se lo stesso ruolo non appartiene più al dominio

− il periodo di validità temporale associato alla regola è scaduto

Quando il Security Agent cancella una regola r, per mantenere consistente la sua politica locale, deve anche eliminare tutte le regole che derivano da r.

M!:Reg.assiomatica M2:ok

M3:Rich.delega per accesso a R

M8:ok M5:permessi group1 M9:Rich.autorizz .per R M10:Rich.permessi M11:permessi group2 M12:Autorizza_ zione M4:Rich. permessi

Client A Security Agent

del dominio D

Client B Policy-database del

Security Agent di D M6:Reg.derivata credential: B-group2 credential: A-group1

Fig. 2.5 Richiesta di delega (creazione di una regola derivata)

M1. M2. M3.

Il Secutiry Agent inserisce la nuova regola assiomatica: “Accesso a R consentito solo ai membri di group1, diritto di delega yes”

Messaggio di conferma: “E’stata memorizzata la nuova regola”

ClientA richiede di delegare ai membri di group2 il diritto di accesso a R fornendo la credenziale che attesta l’appartenenza a group1

M4. M5. M6.

Il Security Agent richiede i permessi che ClientA puo’ delegare in quanto membro di group1

Elenco di permessi trasferibili = {accesso a R}

Il Security Agent inserisce la nuova regola derivata = “Accesso a R consentito ai membri di group2, diritto di delega

no” M7. M8. M9.

Messaggio di conferma: “E’stata memorizzata la regola” Messaggio di conferma: “Sono stati trasferiti i diritti” ClientB richiede l’autorizzazione per l’accesso a R fornendo la credenziale che attesta l’appartenenza a group2

M10. M11. M12.

Il Security Agent richiede i permessi di ClientB in quanto membro di group2

Elenco permessi di ClientB = { accesso a R}

Tutto ciò è molto più di un semplice controllo degli accessi basato sui ruoli perché i diritti possono essere delegati e queste deleghe non sono casuali, ma assegnate da una entità autorizzata ad un’altra entità o ad un gruppo, seguendo le politiche di sicurezza.