Controlul accesului bazat pe roluri

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

În securitatea computerului , controlul accesului bazat pe roluri [1] [2] (în italiană: controlul accesului bazat pe roluri ; prescurtat RBAC) este un acces limitat la sistemele tehnice pentru utilizatorii autorizați. Este o alternativă mai recentă la controlul accesului obligatoriu (MAC) și controlul accesului discreționar (DAC).

Este un mecanism de acces definit pe baza conceptelor de rol și privilegiu. Componentele RBAC, cum ar fi permisiunile de rol, rolul utilizatorului și relațiile rol-rol, facilitează atribuirea rolurilor utilizatorilor. Un studiu dirijat de Institutul Național de Tehnologii Standard ( NIST ) a arătat că RBAC răspunde multor nevoi ale organizațiilor comerciale și guvernamentale. De fapt, RBAC poate fi utilizat pentru a facilita gestionarea securității în organizații cu sute de utilizatori și mii de permisiuni diferite. În timp ce RBAC este diferit de MAC și DAC, poate contribui la îmbunătățirea acestor politici fără a adăuga complicații. Popularitatea RBAC este evidențiată de faptul că multe produse și organizații îl utilizează direct sau indirect.

Proiecta

În cadrul unei organizații, sunt create roluri pentru diferite funcții ale postului. Permisiunile pentru efectuarea operațiunilor specifice sunt atribuite unor roluri specifice. Membrii grupului li se atribuie roluri speciale și, prin aceste atribuții, dobândesc permisiunea de a îndeplini funcții specifice. Deoarece permisiunile nu sunt atribuite direct utilizatorilor, ci sunt dobândite numai prin rolul (sau rolurile) atribuite acestora, gestionarea drepturilor individuale pentru un utilizator devine o simplă atribuire a rolurilor adecvate pentru utilizator. Acest lucru simplifică operațiunile obișnuite, cum ar fi adăugarea unui utilizator sau schimbarea departamentelor.

Trei reguli de bază sunt definite pentru modelul RBAC:

  1. Atribuirea rolului : un subiect poate executa o tranzacție numai dacă subiectul a selectat sau a fost atribuit unui rol.
  2. Autorizarea rolului : un rol activ pentru un subiect trebuie să fi fost autorizat pentru subiect. Împreună cu regula 1, această regulă asigură faptul că utilizatorii pot avea doar roluri pentru care au fost autorizați.
  3. Autorizarea tranzacției : un subiect poate executa o tranzacție numai dacă tranzacția este autorizată pentru rolul activ al subiectului. Împreună cu regulile 1 și 2, această regulă asigură faptul că utilizatorul poate efectua doar tranzacții pentru care a fost autorizat.

Pot fi aplicate și constrângeri suplimentare și rolurile pot fi combinate într-o ierarhie în care nivelurile superioare sunt compuse din permisiunile rolurilor nivelurilor inferioare.

Cu conceptele de constrângeri și ierarhie de roluri, se poate crea sau simula o abordare de control al accesului bazată pe rețele (LBAC). Prin urmare, RBAC poate fi considerat o extensie a LBAC.

Următoarele convenții sunt utile la definirea unui RBAC:

  • S = Subiect = o persoană sau un agent automat;
  • R = Rol = funcția sau titlul postului care definește un nivel de autoritate;
  • P = Permisiuni = aprobarea metodei de acces la resursă;
  • SE = Sesiune = o legătură care implică S, R și / sau P;
  • SA = Cesiune subiectului;
  • PA = Alocarea permisului;
  • RH = ierarhia de rol parțial ordonată (RH poate fi scris și ca: ≥ unde notația x ≥ y înseamnă că x moștenește permisiunile lui y).

În plus, sunt urmate următoarele reguli:

  • Un subiect poate avea mai multe roluri.
  • Un rol poate avea mai mulți subiecți.
  • Un rol poate avea mai multe permisiuni.
  • Un permis poate fi atribuit mai multor roluri.
  • O operațiune poate fi alocată mai multor permisiuni.
  • Un permis poate fi atribuit mai multor operațiuni.

O constrângere creează, de asemenea, o regulă restrictivă cu privire la moștenirea potențială a permisiunilor de la roluri antitetice și, prin urmare, poate fi utilizată pentru a realiza o segregare adecvată a atribuțiilor. De exemplu, o persoană care nu este autorizată să creeze un cont nu ar trebui să poată autoriza crearea unui cont.

Prin urmare, folosind notația set:

  • : este o relație de la mulți la mulți între permisiuni și roluri;
  • : este o relație între mulți și mulți dintre subiecți și roluri;
  • : este o relație mulți-la-mulți între roluri și alte roluri.

Rețineți că un subiect poate avea mai multe sesiuni simultane cu / în roluri diferite.

Relația RBAC cu alte modele

RBAC este o tehnologie flexibilă de control al accesului care vă permite să implementați sisteme DAC [3] sau MAC . [4] În schimb, DAC cu grupuri (cum ar fi sistemul implementat în sistemele de fișiere POSIX) poate emula RBAC. [5] MAC poate simula și RBAC dacă graficul de rol ia forma unui arbore și nu a unui set parțial ordonat . [6]

Înainte de dezvoltarea RBAC, modelul Bell-LaPadula (BLP) era sinonim cu MAC și permisiunile sistemului de fișiere erau echivalente cu DAC. Au fost considerate singurele modele cunoscute pentru controlul accesului: dacă un model nu a intrat într-un model BLP, atunci a fost considerat un DAC și invers. Mai multe cercetări de la sfârșitul anilor 1990 au arătat că RBAC nu se încadrează în nici una dintre categorii. [7] [8] Spre deosebire de controlul accesului bazat pe context (CBAC), RBAC nu se bazează pe mesaje contextuale (cum ar fi sursa conexiunii). RBAC a fost criticat ca implicând un număr mare de roluri [9] , o problemă în sistemele întreprinderilor mari, care necesită un control de acces mai fin decât ceea ce RBAC poate oferi prin roluri atribuite prin moștenirea operațiunilor și tipurilor de date. Similar cu CBAC, un sistem bazat pe controlul accesului bazat pe relații entitate (ERBAC, care nu trebuie confundat cu controlul accesului bazat pe rol extins, o versiune modificată a RBAC [1] care utilizează același acronim), este capabil să asigure instanțe de date având în vedere asocierea lor cu subiectul care rulează. [10]

RBAC este, de asemenea, diferit de listele de control al accesului (ACL), utilizate în sistemele tradiționale de control al accesului, în care sunt atribuite permisiuni pentru operațiuni specifice legate de obiecte de nivel înalt, mai degrabă decât date de nivel scăzut. De exemplu, o listă de control al accesului poate fi utilizată pentru a permite sau refuza accesul la scriere la un anumit fișier de sistem, dar nu poate determina cum poate fi schimbat acel fișier. Într-un sistem bazat pe RBAC, o operațiune poate fi definită la un nivel mult mai detaliat: de exemplu, poate exista operația de creare a unui cont de credit într-o aplicație bancară sau adăugarea unui test de nivel de zahăr în sânge în software-ul medical. Atribuirea permisiunii pentru a efectua o anumită operație este foarte importantă, deoarece fiecare operație are propriul său sens în cadrul aplicației. RBAC sa dovedit a fi deosebit de potrivit pentru cerințele de separare a sarcinilor (SoD), care asigură că două sau mai multe persoane trebuie să fie implicate în compensarea operațiunilor critice. Au fost identificate condițiile necesare și suficiente pentru SoD corect într-un sistem RBAC. Un principiu de bază al SoD este că nicio persoană nu ar trebui să poată provoca o încălcare a securității prin dublu privilegiu. Prin extensie, nicio persoană nu ar trebui să îndeplinească un rol care controlează și verifică funcționarea unui alt rol pe care îl deține, adică nu poate fi un supraveghetor al său. [11] [12]

Comparație cu controlul accesului discreționar (DAC)

În Controlul accesului discreționar (DAC), un utilizator poate permite sau nu accesul la ceea ce deține altor părți (identificate individual sau de grupul din care fac parte) la discreția sa. Controlul este discreționar în sensul că un subiect cu anumite permisiuni de acces poate transmite aceste permisiuni (chiar și indirect) oricărui alt subiect, fără intermedierea unui administrator de sistem.

În RBAC, pe de altă parte, administratorul de securitate este responsabil pentru aplicarea politicilor de securitate: deciziile privind controlul accesului sunt determinate de rolurile utilizatorilor individuali, care determină sarcinile, responsabilitățile și permisiunile, care nu pot fi transferate altora. subiecte la decizia utilizatorului individual. Această caracteristică este diferența cheie între DAC și RBAC. [1]

Comparație cu controlul accesului obligatoriu (MAC)

RBAC poate fi văzut ca o formă de control al accesului obligatoriu (MAC), deși nu se bazează pe cerințe de securitate pe mai multe niveluri. Mai mult, RBAC este mai orientat spre accesarea funcțiilor și informațiilor decât accesarea strictă a informațiilor. De fapt, politica MAC utilizată în armată se bazează pe respectarea unui singur tip de permis: „cine poate citi ce”. Pentru aceste sisteme, principala problemă este un flux neautorizat de informații de la niveluri superioare la inferioare. Deci, constrângerile de citire și scriere susțin această regulă. Dar într-un sistem RBAC, principala problemă este protejarea integrității informațiilor, adică se concentrează pe „cine poate face ce și ce”. [1]

Comparație cu listele de control al accesului (ACL)

O opțiune alternativă la modelul RBAC este modelul listei de control al accesului . Un „model minim RBAC” (abrevierea RBACm) poate fi comparat cu un mecanism ACL bazat pe grup (abrevierea ACLg), unde numai grupurile pot fi înregistrate în ACL. Barkley (1997) [13] a demonstrat că RBACm și ACLg sunt echivalente.

În cele mai recente implementări SQL, cum ar fi ACL-urile pentru cadrul CakePHP , ACL-urile gestionează ambele grupuri și moștenirea în ierarhia grupurilor. Astfel, anumite implementări „moderne ACL” pot fi comparate cu anumite implementări „moderne RBAC”, mai corect decât compararea RBAC cu implementările „vechiului sistem de fișiere”.

Pentru schimbul de date și pentru comparații la nivel înalt, informațiile ACL pot fi traduse în XACML .

Controlul accesului bazat pe atribute (ABAC)

Controlul accesului bazat pe atribute (acronim: ABAC) este o evoluție a RBAC, care ia în considerare atribute suplimentare pe lângă roluri și grupuri. În ABAC, puteți utiliza atribute pentru:

  • utilizatorul, cum ar fi cetățenia, autorizația;
  • resursa, cum ar fi clasificarea, departamentul, proprietarul;
  • actiunea;
  • contextul, cum ar fi ora, locația, adresa IP.

ABAC se bazează pe politici în sensul că folosește politici dinamice versus permisiuni statice pentru a defini ce este permis și ce nu.

Argumente pro şi contra

Utilizarea RBAC pentru a gestiona privilegiile utilizatorului (și permisiunile pe un computer) într-un singur sistem sau aplicație este larg acceptată ca fiind cea mai bună tehnică. Un raport din 2010 pregătit de NIST de Reasearch Triangle Institute a analizat valoarea economică a RBAC pentru întreprinderi și a estimat beneficiile pe angajat, cum ar fi reducerea timpilor de nefuncționare și administrarea mai eficientă a politicii de control al accesului. [14]

Într-o organizație cu infrastructuri și cerințe IT eterogene care acoperă zeci sau sute de sisteme și aplicații, utilizarea RBAC pentru a gestiona suficiente roluri și a atribui utilizatorilor roluri adecvate devine extrem de complexă fără crearea ierarhică de roluri și atribuirea permisiunilor. [15] Sistemele mai noi extind vechiul model RBAC al NIST [16] pentru a aborda limitările RBAC ale distribuțiilor întreprinderilor mari. Modelul NIST a fost adoptat ca standard de către INCITS ca ANSI / INCITS 359-2004. În plus, a fost postată o discuție cu privire la câteva opțiuni de proiectare pentru modelul NIST. [17]

Notă

  1. ^ a b c d ( EN ) Ferraiolo, DF și Kuhn, DR, Role-Based Access Control ( PDF ), în a 15-a Conferință Națională de Securitate a Computerelor , octombrie 1992, pp. 554-563.
  2. ^ (EN) Sandhu, R. Coyne, EJ, Feinstein și HL Youman, CE, Modele de control al accesului bazate pe roluri (PDF), în IEEE Computer, vol. 29, nr. 2, IEEE Press, august 1996, pp. 38–47, DOI : 10.1109 / 2.485845 .
  3. ^ (EN) Ravi Sandhu și Qamar Munawer, Cum se face utilizarea rolurilor de control al accesului discreționare, în al treilea atelier ACM privind controlul accesului bazat pe roluri, octombrie 1998, pp. 47–54.
  4. ^ (EN) Sylvia Osborn, Ravi Sandhu și Qamar Munawer, Configurarea controlului accesului bazat pe roluri pentru aplicarea politicilor obligatorii și discreționare de control al accesului, în ACM Transactions on Information and System Security, 2000, pp. 85-106.
  5. ^ (EN) Achim D. Brucker și Burkhart Wolff, O abordare de verificare pentru securitatea sistemelor aplicate , în Jurnalul internațional privind instrumentele software pentru tehnologie (STTT), 2005, DOI : 10.1007 / s10009-004-0176-3 .
  6. ^ ( EN ) DR Kuhn, Controlul accesului bazat pe roluri pe sistemele MLS fără modificări ale nucleului ( PDF ), în al treilea atelier ACM privind controlul accesului bazat pe roluri , 1998, pp. 25–32.
  7. ^ Controlul accesului bazat pe roluri - Întrebări frecvente | CSRC , la csrc.nist.gov . Adus la 13 decembrie 2017 .
  8. ^ (RO) David Ferraiolo, Richard Kuhn, Controale de acces bazate pe roluri (PDF) pe csrc.nist.gov. Adus la 13 decembrie 2017 .
  9. ^ ( EN ) AA Elliott și GS Knight, Role Explosion: Reconnaising the Problem ( PDF ), în Proceedings of the 2010 International Conference on Software Engineering Research & Practice , 2010.
  10. ^ Kalle Korhonen, tapestry-security-jpa , la www.tynamo.org . Adus la 13 decembrie 2017 .
  11. ^ ( EN ) DR Kuhn, Excluderea reciprocă a rolurilor ca mijloc de implementare a separării datoriei în sistemele de control al accesului bazate pe roluri ( PDF ), în al 2-lea atelier ACM Controlul accesului bazat pe roluri , 1997, pp. 23-30.
  12. ^ (EN) Ninghui Li, Ziad Bizri și Mahesh V. Tripunitara. Tripunitara, Despre rolurile care se exclud reciproc și separarea datoriei, ( PDF ), în cea de-a 11-a conferință ACM privind securitatea computerelor și comunicațiilor , 2004, pp. 42-51.
  13. ^ J. Barkley (1997) „ Compararea modelelor simple de control al accesului bazate pe roluri și listele de control al accesului ”, În „Proceedings of the two ACM workshop on Role-based access control”, paginile 127-132.
  14. ^ (EN) AC O'Connor și RJ Loomis, Analiza economică a controlului accesului bazat pe roluri (PDF), Research Triangle Institute, martie 2002.
  15. ^ (EN) Hitachi ID Systems, Beyond Roles: A Practical Approach to Enterprise IAM , pe www.idsynch.com. Adus la 13 decembrie 2017 .
  16. ^ (EN) Sandhu, R., Ferraiolo, DF și Kuhn, DR, Modelul NIST pentru controlul accesului bazat pe roluri: către un standard unificat (PDF), al cincilea atelier ACM privind controlul accesului bazat pe roluri, iulie 2000, pp. 47–63.
  17. ^ (EN) Ferraiolo, DF, Kuhn, DR și Sandhu, R., RBAC Justificare standard: comentarii cu privire la o critică a standardului ANSI privind controlul accesului bazat pe roluri (PDF), în IEEE Security & Privacy, vol. 5, nr. 6, IEEE Press, noiembrie - decembrie 2007, pp. 51–53, DOI : 10.1109 / MSP.2007.173 (arhivat din original la 17 septembrie 2008) .

Elemente conexe

Lecturi suplimentare

  • David F. Ferraiolo; D. Richard Kuhn; Ramaswamy Chandramouli (2007). Controlul accesului bazat pe roluri (ediția a doua). Casa Artech.

linkuri externe