Role-based access control: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Finita la traduzione della pagina inglese e aggiunta di due paragrafi (confronto con DAC e confronto con MAC) |
template citazione; rinomina/fix nomi parametri; converto template cite xxx -> cita xxx; parametri non usati su it.wiki |
||
Riga 1:
{{F|sicurezza informatica|maggio 2012|Mancano del tutto le sezioni Note/Bibliografia/Collegamenti esterni}}
Nella [[sicurezza informatica]], il '''Role-based access control'''<ref name=":0">{{
Il Role-based Access Control è un meccanismo di accesso definito basandosi sui concetti di ruolo e privilegio. I componenti del RBAC, come i permessi dei ruoli, il ruolo utente e le relazioni ruolo-ruolo, fanno in modo di semplificare l'assegnamento dei ruoli agli utenti. Uno studio diretto dal [[National Institute of Standards and Technology|NIST]] (National Institute of Standard Technologies) ha dimostrato che il RBAC risponde a molte necessità di organizzazioni commerciali e governative. Infatti, il RBAC può essere usato per facilitare la gestione della sicurezza nelle organizzazioni composte da centinaia di utenti e migliaia di permessi diversi. Benché il RBAC sia diverso dal MAC e dal DAC, può contribuire a migliorare queste politiche senza aggiungere delle complicazioni. La popolarità del RBAC è evidenziata dal fatto che molti prodotti e organizzazioni lo usano direttamente o indirettamente.
Riga 41:
== Relazione del RBAC con altri modelli ==
Il RBAC è una tecnologia di controllo degli accessi flessibile che consente di implementare sistemi [[Discretionary Access Control|DAC]]<ref>{{
Prima dello sviluppo del RBAC, il [[modello Bell-LaPadula]] (BLP) era sinonimo di MAC e i [[Permessi (Unix)|permessi del file system]] erano equivalenti al DAC. Essi erano considerati gli unici modelli conosciuti per il controllo dell'accesso: se un modello non ricadeva in un modello BLP, allora era considerato un DAC, e viceversa. Diverse ricerche della fine degli anni Novanta hanno dimostrato che il RBAC non ricade in nessuna delle due categorie.<ref>[http://csrc.nist.gov/rbac/rbac-faq.html National Institute of Standards and Technology FAQ on RBAC models and standards]</ref><ref>[http://csrc.nist.gov/groups/SNS/rbac/documents/ferraiolo-kuhn-92.pdf David Ferraiolo and Richard Kuhn]</ref> A differenza del [[Context-Based Access Control]] (CBAC), il RBAC non si basa sui messaggi di contesto (come la fonte della connessione). Il RBAC è stato criticato in quanto comporta un grande numero di ruoli<ref>{{
Il RBAC è diverso anche dalle [[Lista di controllo degli accessi|liste di controllo degli accessi]] (ACL), usate nei sistemi tradizionali a controllo discrezionale degli accessi, in cui si assegnano permessi per specifiche operazioni legate ad oggetti di alto livello, più che a dati di basso livello. Per esempio, un lista di controllo degli accessi può essere usata per permettere o vietare l'accesso in scrittura ad un particolare file di sistema, ma non può stabilire come quel file può essere cambiato. In un sistema basato su RBAC, un'operazione può essere definita a livello molto più dettagliato: ad esempio, può esistere l'operazione di creazione di un account di credito in un'applicazione bancaria oppure l'aggiunta di un esame del livello degli zuccheri nel sangue in un software medico. L'assegnamento del permesso di svolgere una particolare operazione è molto importante, in quanto ogni operazione ha un proprio significato all'interno dell'applicazione. Il RBAC ha dimostrato di essere particolarmente adatto nei requisiti di separazione dei compiti (in inglese, SoD, Separation of Duties), che assicurano che debbano essere coinvolte due o più persone nell'autorizzazione di operazioni critiche. Sono state individuate le condizioni necessarie e sufficienti per la corretta SoD in un sistema RBAC. Un principio sottinteso della SoD è quello che nessun individuo dovrebbe essere in grado di provocare una violazione della sicurezza attraverso un privilegio duale. Per estensione, nessuna persona dovrebbe coprire un ruolo che controlla e verifica l'operato di un altro ruolo che sta ricoprendo, ovvero non può essere supervisore di sé stesso.<ref>{{
=== Confronto con il Discretonary Access Control (DAC) ===
Riga 71:
== Pregi e difetti ==
L'uso del RBAC per gestire i privilegi utente (e i permessi su un computer) all'interno di un singolo sistema o applicazione è largamente accettata come la tecnica migliore. Un report del 2010 preparato dal NIST dal Reasearch Triangle Institute ha analizzato il valore economico del RBAC per le imprese ed ha stimato i benefici per impiegato, come un ridotto tempo di inattività ed una più efficiente amministrazione della politica del controllo degli accessi.<ref name="autogenerated2002">{{
In un'organizzazione con infrastrutture informatiche eterogenee e requisiti che coprono decine o centinaia di sistemi ed applicazioni, usare il RBAC per gestire ruoli sufficienti ed assegnare gli utenti a ruoli adeguati diventa estremamente complesso senza la creazione gerarchica di ruoli ed assegnamento di permessi.<ref>[http://www.idsynch.com/docs/beyond-roles.html Beyond Roles: A Practical Approach to Enterprise User Provisioning]</ref> I sistemi più recenti estendono il vecchio modello RBAC del NIST<ref>{{
==Voci correlate==
|