Gruppo vs ruolo (Qualche differenza reale?)

Qualcuno può dirmi qual è la vera differenza tra gruppo e ruolo? È da un po 'di tempo che cerco di capirlo e più informazioni leggo, più ho la sensazione che questo sia stato tirato fuori solo per confondere le persone e non c'è una vera differenza. Entrambi possono fare il lavoro dell'altro. Ho sempre utilizzato un gruppo per gestire gli utenti e i loro diritti di accesso.

Recentemente, mi sono imbattuto in un software di amministrazione, dove si trova un gruppo di utenti. Ad ogni utente può essere assegnato un modulo (l'intero sistema è suddiviso in poche parti chiamate moduli, ad es. Modulo Amministrazione, modulo Sondaggio, modulo Ordini, modulo Cliente). Inoltre, ogni modulo ha un elenco di funzionalità, che possono essere consentite o negate per ogni utente. Quindi diciamo che un utente John Smith può accedere al modulo Ordini e può modificare qualsiasi ordine, ma non ha dato il diritto di eliminarne nessuno.

Se ci fossero più utenti con la stessa competenza, userei un gruppo per gestirla. Aggregherei tali utenti nello stesso gruppo e assegnerei i diritti di accesso ai moduli e alle loro funzioni al gruppo. Tutti gli utenti nello stesso gruppo avrebbero gli stessi diritti di accesso.

Perché chiamarlo gruppo e non ruolo? Non lo so, lo sento solo in quel modo. Mi sembra che semplicemente non abbia molta importanza:] Ma vorrei comunque conoscere la vera differenza.

Qualche suggerimento sul perché questo dovrebbe essere chiamato piuttosto ruolo che gruppo o viceversa?

Google è tuo amico :)

Ad ogni modo, il divario tra ruolo e gruppo deriva dai concetti di sicurezza informatica (in opposizione alla semplice gestione delle risorse). Il Prof. Ravi Sandhu fornisce una copertura seminale della differenza semantica tra ruoli e gruppi.

http://profsandhu.com/workshop/role-group.pdf

Un gruppo è una raccolta di utenti con un determinato insieme di autorizzazioni assegnate al gruppo (e in modo transitorio, agli utenti). Un ruolo è una raccolta di autorizzazioni e un utente eredita effettivamente tali autorizzazioni quando agisce con quel ruolo.

In genere l'appartenenza al gruppo rimane per tutta la durata del tuo accesso. Un ruolo, invece, può essere attivato secondo condizioni specifiche. Se il tuo ruolo attuale è "personale medico" potresti essere in grado di vedere alcune delle cartelle cliniche di un dato paziente. Se, tuttavia, il tuo ruolo è anche "medico", potresti essere in grado di vedere ulteriori informazioni mediche oltre a ciò che può vedere una persona con solo un ruolo di "personale medico".

I ruoli possono essere attivati ​​in base all'ora del giorno e al luogo di accesso. I ruoli possono anche essere migliorati / associati agli attributi. Potresti operare come "medico", ma se non hai un attributo o una relazione di "medico primario" con me (un utente con ruolo di "paziente"), non puoi vedere la mia intera storia medica.

Potresti fare tutto questo con i gruppi, ma ancora una volta, i gruppi tendono a concentrarsi sull'identità, non sul ruolo o sull'attività. E il tipo di aspetti di sicurezza appena descritti tendono ad allinearsi meglio con il secondo che con il primo.

Per molti casi, per l'uso di classificare le cose insieme (e niente più), i gruppi ei ruoli funzionano allo stesso modo. I gruppi, tuttavia, sono basati sull'identità, mentre i ruoli hanno lo scopo di delimitare l'attività. Sfortunatamente, i sistemi operativi tendono a offuscare la distinzione, trattando i ruoli come gruppi.

Si vede una distinzione molto più chiara con i ruoli a livello di applicazione o di sistema - che trasportano semantica specifica dell'applicazione o del sistema (come nei ruoli Oracle ) - in contrapposizione ai "ruoli" implementati a livello di sistema operativo (che in genere sono sinonimi di gruppi).

Possono esserci limitazioni ai ruoli e ai modelli di controllo degli accessi basati sui ruoli (come con qualsiasi cosa ovviamente):

http://www.lhotka.net/weblog/CommentView,guid,9efcafc7-68a2-4f8f-bc64-66174453adfd.aspx

Circa dieci anni fa ho assistito ad alcune ricerche sul controllo degli accessi basato sugli attributi e sulla relazione che forniscono una granularità molto migliore rispetto al controllo degli accessi basato sui ruoli. Sfortunatamente, non vedo molta attività in quel regno da anni.

La differenza più importante tra ruoli e gruppi è che i ruoli in genere implementano un meccanismo di controllo dell'accesso obbligatorio (MAC). Non puoi assegnare te stesso (o gli altri) ai ruoli. Un amministratore del ruolo o un ingegnere del ruolo lo fa.

Questo è superficialmente simile ai gruppi UNIX in cui un utente può / potrebbe essere in grado di assegnarsi a un gruppo (tramite sudo ovviamente.) Quando i gruppi vengono assegnati in base a un processo di ingegneria della sicurezza, la distinzione tuttavia si confonde un po '.

Un'altra caratteristica importante è che i veri modelli RBAC possono fornire il concetto di ruoli che si escludono a vicenda. Al contrario, i gruppi basati sull'identità sono additivi: l'identità di un principale è la somma (o congiunzione) dei gruppi.

Un'altra caratteristica di un vero modello di sicurezza basato su RBAC è che gli elementi creati per un particolare ruolo in genere non possono essere accessibili in modo transitorio da qualcuno che non agisce in quel ruolo.

D'altra parte, in un modello di controllo di accesso discrezionale (DAC) (il modello predefinito in Unix), non è possibile ottenere quel tipo di garanzia con i soli gruppi. A proposito, questa non è una limitazione dei gruppi o Unix, ma una limitazione dei modelli DAC basati sull'identità (e transitivamente, con gruppi basati sull'identità).

Spero che sia d'aiuto.

=======================

Aggiungendo un po 'di più dopo aver visto la risposta ben formulata di Simon. I ruoli ti aiutano a gestire le autorizzazioni. I gruppi ti aiutano a gestire oggetti e soggetti. Inoltre, si potrebbe pensare ai ruoli come a "contesti". Un ruolo "X" può descrivere un contesto di sicurezza che regola il modo in cui il soggetto Y accede (o non accede) all'oggetto Z.

Un'altra importante distinzione (o ideale) è che esiste un ingegnere di ruolo, una persona che ingegnerizza i ruoli, i contesti, che sono necessari e / o evidenti in un'applicazione, sistema o OS. Un ingegnere di ruolo in genere è (ma non deve essere) anche un amministratore di ruolo (o amministratore di sistema). Inoltre, il vero ruolo (nessun gioco di parole) di un ingegnere di ruolo è nel regno dell'ingegneria della sicurezza, non dell'amministrazione.

Questo è un nuovo gruppo formalizzato da RBAC (anche se viene utilizzato raramente), uno che tipicamente non è stato presente con sistemi capaci di gruppo.

Un gruppo è un mezzo per organizzare gli utenti, mentre un ruolo è solitamente un mezzo per organizzare i diritti.

Questo può essere utile in molti modi. Ad esempio, un insieme di autorizzazioni raggruppate in un ruolo potrebbe essere assegnato a un insieme di gruppi o un insieme di utenti indipendentemente dal loro gruppo.

Ad esempio, un CMS potrebbe avere alcune autorizzazioni come Leggi post, Crea post, Modifica post. Un ruolo di Editor potrebbe essere in grado di leggere e modificare, ma non creare (non so perché!). Un post potrebbe essere in grado di creare e leggere ecc. Un gruppo di manager potrebbe avere il ruolo di editore, mentre un utente in IT, che non è nel gruppo di manager, potrebbe anche avere il ruolo di editore, anche se il resto del suo gruppo no.

Quindi, anche se in un sistema semplice i gruppi e i ruoli sono spesso strettamente allineati, non è sempre così.

Sebbene vi sia una differenza semantica tra ruoli e gruppi (come descritto sopra da altre risposte), tecnicamente ruoli e gruppi sembrano essere gli stessi. Niente ti impedisce di assegnare Autorizzazioni direttamente a Utenti e Gruppi (questo può essere considerato come un controllo di accesso di fine tuning). Allo stesso modo, quando all'utente viene assegnato un ruolo, può essere considerato un membro del ruolo, nello stesso senso quando l'utente diventa membro di un gruppo.

Quindi possiamo ritrovarci senza una vera differenza tra ruoli e gruppi. Entrambi possono essere presi in considerazione per raggruppare utenti e / o autorizzazioni. Quindi la differenza è solo semantica: - se è usata semanticamente per raggruppare i Permessi, allora è un Ruolo; - se viene utilizzato semanticamente per raggruppare gli utenti, è quindi un gruppo. Tecnicamente, non c'è differenza.

Un "gruppo" è una raccolta di utenti. Un "ruolo" è una raccolta di autorizzazioni. Ciò significa che quando il gruppo alpha include il gruppo beta , alpha riceve tutti gli utenti da beta e beta riceve tutte le autorizzazioni da alpha. Al contrario, potresti dire che il ruolo beta include il ruolo alfa e si applicherebbero le stesse conclusioni.

Un esempio concreto rende le cose più chiare. Considera "assistenza clienti" e "assistenza clienti senior". Se si considerano queste raccolte come gruppi, è chiaro che gli utenti dell'assistenza clienti "includono" gli utenti senior dell'assistenza clienti. Tuttavia, se li consideri ruoli, è chiaro che le autorizzazioni dell'assistenza clienti senior "includono" le autorizzazioni dell'assistenza clienti.

In teoria, potresti semplicemente avere un tipo di raccolta. Tuttavia, sarebbe ambiguo se si dicesse che "la raccolta alpha include la raccolta beta" . In tal caso, non puoi dire se gli utenti in alpha sono in beta (come un ruolo) o gli utenti in beta sono in alpha (come un gruppo). Per rendere inequivocabile la terminologia come "include" ed elementi visivi come le visualizzazioni ad albero, la maggior parte dei sistemi rbac richiede di specificare se la raccolta in questione è un "gruppo" o un "ruolo" almeno per motivi di discussione.

Alcune analogie potrebbero aiutare. Inquadrato in termini di teoria degli insiemi , quando il gruppo alpha è un sottoinsieme del gruppo beta, i permessi alpha sono un superset di permessi beta. Rispetto alla genealogia , se i gruppi sono come un albero dei discendenti, i ruoli sono come un albero degli antenati.

NOTA: le seguenti divagazioni hanno senso solo se si cerca di imporre la sicurezza all'interno di un'organizzazione, vale a dire, si cerca di limitare l'accesso alle informazioni ...

I gruppi sono empirici: rispondono alla domanda "cosa". Sono l '"è" nel senso che riflettono la realtà esistente dell'accesso. Le persone IT amano i gruppi: sono molto letterali e facili da definire. Alla fine, tutto il controllo degli accessi alla fine spetta (come tutti abbiamo imparato alle scuole medie ...) a rispondere alla domanda "A quale gruppo appartieni?"

I ruoli, tuttavia, sono più normativi: guidano ciò che "dovrebbe essere". I bravi manager e le risorse umane amano i "ruoli" - non rispondono - si pongono la domanda "perché?" Sfortunatamente, i ruoli possono anche essere vaghi e quella "sfocatura" può far impazzire le persone (IT).

Per utilizzare l'esempio medico di cui sopra, se il ruolo di "medico di base" ha più diritti (ovvero l'accesso a più gruppi) rispetto al ruolo di "tecnico radiografico", è perché le persone (manager e risorse umane) hanno deciso il motivo per cui doveva accadere. In questo senso sono "la saggezza collettiva" di un'organizzazione.

Supponiamo che un medico abbia accesso (appartenenza a un gruppo con accesso) ai record finanziari dei pazienti. Questo è normalmente al di fuori del "ruolo" di un medico e dovrebbe essere discusso. Quindi, nessuno (non importa quanto qualificato) dovrebbe avere pieno accesso a tutti i gruppi - invita gli abusi al potere. Questo è il motivo per cui l '"ingegneria dei ruoli" è così importante: senza di essa, hai solo l'accesso al gruppo distribuito come tante caramelle. Le persone raccoglieranno (e talvolta orde) l'accesso di gruppo senza discutere sui pericoli di un potere eccessivo.

Per concludere, la saggezza di ruoli ben definiti aiuta a moderare i pericoli dell'accesso al gruppo in fuga. Chiunque in un'organizzazione può discutere per l'accesso a un particolare gruppo. Ma una volta fornito l'accesso, raramente viene rinunciato. L'ingegneria dei ruoli (insieme a best practice come descrizioni di gruppo ben definite e gestori di accesso ai gruppi autorizzati) può limitare i conflitti di interesse all'interno di un'organizzazione, decentralizzare il processo decisionale e contribuire a rendere più razionale la gestione della sicurezza.

Le risposte precedenti sono tutte meravigliose. Come è stato affermato, il concetto di Gruppo vs Ruolo è più concettuale che tecnico. Abbiamo assunto la posizione che i gruppi vengano utilizzati per contenere gli utenti (un utente può essere in più di un gruppo: ad esempio Joe è nel gruppo Managers così come nel gruppo IT [è un manager in IT]) e per assegnare ampi privilegi (cioè il nostro sistema di carte magnetiche consente a tutti gli utenti del gruppo IT di accedere alla sala server). I ruoli sono stati utilizzati per aggiungere ora privilegi a utenti specifici (ad esempio, le persone nel gruppo IT possono eseguire l'RDP ai server ma non possono assegnare utenti o modificare le autorizzazioni, le persone nel gruppo IT con il ruolo di amministratore possono assegnare utenti e modificare le autorizzazioni). I ruoli possono essere costituiti anche da altri ruoli (Joe ha il ruolo di amministratore per aggiungere utenti / privilegi e ha anche il ruolo DBA per apportare modifiche al database al DBMS sul server). Anche i ruoli possono essere molto specifici in quanto possiamo creare ruoli utente individuali (cioè JoesRole) che possono essere molto specifici per un utente. Quindi, per ricapitolare, utilizziamo i gruppi per gestire gli utenti e assegniamo ruoli e ruoli generali per gestire i privilegi. Anche questo è cumulativo. Al gruppo in cui si trova l'utente possono essere assegnati ruoli (o un elenco di ruoli disponibili) che forniranno privilegi molto generali (ad esempio, gli utenti del gruppo IT hanno il ruolo ServerRDP che consente loro di accedere ai server) in modo che venga assegnato all'utente. Quindi tutti i ruoli a cui appartiene l'utente verranno aggiunti nell'ordine in cui sono definiti con l'ultimo ruolo che ha l'ultima parola (i ruoli possono consentire, negare o non applicare i privilegi in modo che, quando ogni ruolo viene applicato, sovrascriverà le impostazioni precedenti per un privilegio o non cambiarlo). Una volta applicati tutti i ruoli a livello di gruppo e i ruoli a livello di utente,

Agli utenti vengono assegnati ruoli in base alla responsabilità che svolgono in qualsiasi sistema. Ad esempio, gli utenti nel ruolo Sales Manager possono eseguire determinate azioni come fornire uno sconto aggiuntivo per un prodotto.

I gruppi vengono utilizzati per "raggruppare" utenti o ruoli in un sistema per una facile gestione della sicurezza. Ad esempio, un gruppo denominato "Gruppo di leadership" può avere i suoi membri dai ruoli Manager, Direttori e architetti e anche singoli utenti che non rientrano in questi ruoli. Ora dovresti essere in grado di assegnare determinati privilegi a questo gruppo.

Lo scopo dei gruppi e dei ruoli varia nelle applicazioni, ma principalmente quello che ho capito è come segue, i gruppi (insieme di utenti) sono statici mentre i ruoli (insieme di autorizzazioni) sono dinamici con le politiche, ad esempio in base al tempo da (9 a 6) a gruppo o utente può avere questo ruolo ma non quello.

Puoi assegnare un ruolo al gruppo. È possibile assegnare l'utente al gruppo e assegnare un ruolo a un singolo utente in qualsiasi utente con ruolo. Senso. Jean Doe può essere nel gruppo del reparto vendite con il ruolo disattivato ReportWritter che consente di stampare i nostri rapporti da SharePoint, ma nel gruppo reparto vendite, altri potrebbero non avere il ruolo di ReportWritter. - In altre parole, i ruoli sono privilegi speciali all'interno dei gruppi assegnati. Spero che questo faccia delle scene.

Saluti!!!