Thematopic: RBAC

[Turdie]

Thema topic: RBAC (Role Based Acces Control)

Introductie

Welkom in het thema topic RBAC (Role Based Acces Control).

Onlangs zijn we gestart met een aantal nieuwe items in het Beveiliging & Virussen forum. Een nieuw item zijn de thema topics waarin ruimte is voor discussie over een bepaald wisselend onderwerp.

Deze maand hebben we gekozen voor het thema "RBAC". Dit is een actueel onderwerp waar veel mensen een mening over hebben en waarover in het algemeen verschillende opvattingen bestaan.

Thema: RBAC (Role Based Acces Control)

RBAC is een permissie-model om gebruikers door middel van rollen permissies te geven op resources binnen een netwerk. Een gebruiker heeft dus niet overal meer permissies op verschillende plaatsen, maar krijgt een rol die hem standaard permissies geeft op resources binnen een netwerk.Het uitgangspunt bij RBAC is dat medewerkers die hetzelfde werk doen, dezelfde rechten en applicaties nodig hebben.

In dit thema topic hopen wij op een open discussie over dit interessante onderwerp.

Interessante bronnen en links

RBAC 2.0
Role-based access control
Role-Based Access Control for Multi-tier Applications Using Authorization Manager
RBAC: Role Based Access Control: wat moeten we er mee?
Presentatie: RBAC: General Concepts
[Implementation and Interoperability of Role Based Access Control

Mogelijke onderwerpen voor discussie

Mogelijke onderwerpen voor de discussie:

• Gebruik je binnen jouw organisatie RBAC?
• Is het makkelijk of moeilijk binnen jouw organisatie om te achterhalen welke rollen er zijn?
• Vind je RBAC nuttig of vind je het flauwekul?
• Is RBAC goed te documenteren?
• Denk je dat RBAC het beheer van permissies kan vereenvoudigen?

[ Voor 11% gewijzigd door Turdie op 18-07-2010 22:05 ]

[LuckY]

Persoonlijk vind ik dat RBAC voor en nadelen heeft, Immers het grote voordeel is dat je meer per afdeling de rechten bepaald en niet per persoon. Want dan ga je kijken waar moet en mag marketing bij mogen en waar niet? Echter vaak hebben mensen meerdere taken in de organisatie, zoals iemand van marketing ook applicatiebeheer van een stuk software kan doen, dan worden de rollen in een keer weer op de persoon gedaan.

Ik vraag me af hoe je dat doet in een veelzijdige organisatie waar meerdere mensen meerdere rollen hebben.

En persoonlijk ben ik van mening dat je RBAC moet gebruiken omdat het goed kan werken in de organisatie en niet omdat het een must is het is een extra feature wat mogelijke veiligheid met zich mee kan brengen maar net als elke andere security policy ook heel erg weerstand kan geven bij de collega's

[Orion84]

Wat is het probleem dan met mensen die meerdere rollen hebben? Het hele idee van RBAC is toch juist dat je een set users hebt, een set rollen en een set permissies en dat je naar hartelust rollen aan users kan toewijzen, en permissies aan rollen? Geen van die relaties is 1:1 hoor

Als iemand een marketingrol en een applicatiebeheerderrol heeft binnen het bedrijfsproces, dan maak je dus die twee rollen aan en wijs je die allebei toe aan de betreffende user. Of, als je maar één rol tegelijk actief wilt hebben, zorg je dat je de rol activeert die hoort bij de activiteit waar de user mee bezig is.

[Turdie]

Orion84 schreef op zondag 18 juli 2010 @ 16:32:
Wat is het probleem dan met mensen die meerdere rollen hebben? Het hele idee van RBAC is toch juist dat je een set users hebt, een set rollen en een set permissies en dat je naar hartelust rollen aan users kan toewijzen, en permissies aan rollen? Geen van die relaties is 1:1 hoor

Als iemand een marketingrol en een applicatiebeheerderrol heeft binnen het bedrijfsproces, dan maak je dus die twee rollen aan en wijs je die allebei toe aan de betreffende user. Of, als je maar één rol tegelijk actief wilt hebben, zorg je dat je de rol activeert die hoort bij de activiteit waar de user mee bezig is.

Je moet alleen zorgen dat mensen geen conflicterende rollen hebben, zoals bijvoorbeeld Betalingen boeken vs. Betalingen fiatteren.

[Orion84]

Uiteraard

Dat is een kwestie van goed beheer, of zorgen dat je een RBAC systeem hebt waar constraints kunnen worden gedefinieerd die beperkingen opleggen aan het toewijzen van rollen etc.

Ik heb trouwens geen praktijkkennis/-ervaring met RBAC, maar heb in m'n studie wel de nodige theorie er van gezien

[Turdie]

Orion84 schreef op zondag 18 juli 2010 @ 16:40:
Uiteraard

Dat is een kwestie van goed beheer, of zorgen dat je een RBAC systeem hebt waar constraints kunnen worden gedefinieerd die beperkingen opleggen aan het toewijzen van rollen etc.

Ik heb trouwens geen praktijkkennis/-ervaring met RBAC, maar heb in m'n studie wel de nodige theorie er van gezien

Ik heb wel praktijkervaring met RBAC, en het werkt best goed, wat wel lastig kan zijn om vooral bij mensen met beheerdersrechten te achterhalen welke rollen ze hebben, die hebben vaak erg veel rollen.

[Equator]

Orion84 schreef op zondag 18 juli 2010 @ 16:40:
Uiteraard

Dat is een kwestie van goed beheer, of zorgen dat je een RBAC systeem hebt waar constraints kunnen worden gedefinieerd die beperkingen opleggen aan het toewijzen van rollen etc.

Dergelijke systemen kom je helaas niet vaak tegen in de praktijk.. Maar dat zou wel erg mooi zijn.

Een groot nadeel van RBAC is dat het ingericht moet worden. Een rbac indeling maken in een CRM applicatie is nog wel te doen. Maar wat in financiele, beheer of securitymanagement systemen. Daar moet goed over nagedacht worden, en goed getest. Persoonlijk vind ik dat daar een grote rol is weggelegd voor de fabrikant van de applicatie, maar soms krijg je alleen de tools en zal je het volledig zelf in moeten richten.
Dan is het zeer van belang dat bepaalde conflicterende zaken niet binnen 1 rol vallen.

[alt-92]

Equator schreef op maandag 19 juli 2010 @ 07:30:
Een groot nadeel van RBAC is dat het ingericht moet worden. Een rbac indeling maken in een CRM applicatie is nog wel te doen. Maar wat in financiele, beheer of securitymanagement systemen. Daar moet goed over nagedacht worden, en goed getest. Persoonlijk vind ik dat daar een grote rol is weggelegd voor de fabrikant van de applicatie, maar soms krijg je alleen de tools en zal je het volledig zelf in moeten richten.
Dan is het zeer van belang dat bepaalde conflicterende zaken niet binnen 1 rol vallen.

Klopt, maar aan de andere kant: dat je enkel de tools krijgt hoeft ook geen nadeel te zijn. Misschien zijn de vereisten binnen je organisatie met betrekking tot functiescheidingen wel heel anders dan de standaard die je software leverancier hanteert
Dan ben je maar wat blij dat je daar zelf de aanpassingen in kan doen.

[YellowOnline]

Als ik de TS goed begrijp werken wij ook aldus. Op NTFS niveau heeft iedereen alle rechten: het volledige rechtenbeheer wordt gedaan via permissions. Users hebben één of meerdere rollen toegewezen op basis van dewelke ze al dan niet toegang hebben tot bepaalde network resources.

De complexiteit ligt, uiteraard, stukken lager dan rechtenbeheer op het niveau van gebruikers, maar in grote organisaties met veel opsplitsingen kan het nog steeds vrij moeilijk zijn: wij hebben toch gemakkelijk meer dan 250 verschillende rollen (met 25 000 gebruikers).

Documentatie is bij ons nog niet uitgevonden, dus daar kan ik niet over spreken

Als domain admin heb ik (zo nodig) trouwens tot alles toegang, dus de complexiteit dat beheerders véél rollen hebben gaat me voorbij.

[Turdie]

YellowOnline schreef op zaterdag 21 augustus 2010 @ 15:50:
Als ik de TS goed begrijp werken wij ook aldus. Op NTFS niveau heeft iedereen alle rechten: het volledige rechtenbeheer wordt gedaan via permissions. Users hebben één of meerdere rollen toegewezen op basis van dewelke ze al dan niet toegang hebben tot bepaalde network resources.

De complexiteit ligt, uiteraard, stukken lager dan rechtenbeheer op het niveau van gebruikers, maar in grote organisaties met veel opsplitsingen kan het nog steeds vrij moeilijk zijn: wij hebben toch gemakkelijk meer dan 250 verschillende rollen (met 25 000 gebruikers).

Documentatie is bij ons nog niet uitgevonden, dus daar kan ik niet over spreken

Als domain admin heb ik (zo nodig) trouwens tot alles toegang, dus de complexiteit dat beheerders véél rollen hebben gaat me voorbij.

Hoe kan je op NTFS niveau volledige rechten uitdelen als je met permissions werkt?Ik vermoed dat je op share niveau bedoelt?

[alt-92]

YellowOnline schreef op zaterdag 21 augustus 2010 @ 15:50:
Als domain admin heb ik (zo nodig) trouwens tot alles toegang, dus de complexiteit dat beheerders véél rollen hebben gaat me voorbij.

Dan zijn ze tijdens de invoering van RBAC bij jullie Risk Management toch echt wat vergeten
enne: 250 rollen op 25000 man is niet eens zo heel veel.

[ Voor 7% gewijzigd door alt-92 op 21-08-2010 16:10 ]

[YellowOnline]

shadowman12 schreef op zaterdag 21 augustus 2010 @ 16:06:
[...]


Hoe kan je op NTFS niveau volledige rechten uitdelen als je met permissions werkt?Ik vermoed dat je op share niveau bedoelt?

Uiteraard bedoel ik op share niveau

alt-92 schreef op zaterdag 21 augustus 2010 @ 16:09:
[...]

Dan zijn ze tijdens de invoering van RBAC bij jullie Risk Management toch echt wat vergeten

Wij zijn het grootste risico Maar zo gek is dat toch niet: aangezien wij de gebruikers in rollen steken zouden we ons in elk ander scenario sowieso in de gewenste groep kunnen steken. Quis custodiet ipsos custodes is een klassiek probleem.

Maar sowieso: het is niet dat er bij ons zo geweldig over nagedacht is. Of dat er risk management is tout court. We hebben dit systeem min of meer uit de grond gestampt omdat er hiervoor géén systeem was, maar 100en fileshare eilandjes waar niemand van wist wie ze beheerde.

[The Eagle]

Equator schreef op maandag 19 juli 2010 @ 07:30:
[...]

Dergelijke systemen kom je helaas niet vaak tegen in de praktijk.. Maar dat zou wel erg mooi zijn.

Een groot nadeel van RBAC is dat het ingericht moet worden. Een rbac indeling maken in een CRM applicatie is nog wel te doen. Maar wat in financiele, beheer of securitymanagement systemen. Daar moet goed over nagedacht worden, en goed getest. Persoonlijk vind ik dat daar een grote rol is weggelegd voor de fabrikant van de applicatie, maar soms krijg je alleen de tools en zal je het volledig zelf in moeten richten.
Dan is het zeer van belang dat bepaalde conflicterende zaken niet binnen 1 rol vallen.

Ik ben zelf ERP specialist (PeopleSoft) en daar kom je RBAC al sinds jaar en dag tegen. Was het eerst alleen op basis van user, rol en permissionlist, tegenwoordig kan op vrijwel ieder veld aparte security gezet worden. Dit naast de al bestaande zgn row-level security, waarbij op basis van bijvoorbeeld de business unit waar de user rechten toe heeft wordt bepaald of de user een bepaalde rij in de database al dan niet mag zien

De grote rol van de fabrikanten is er dus, maar zoals met eigenlijk alle applicaties is er vrijwel altijd sprake van een bedrijfsspecifieke situatie. En om nou de leverancier voor ieder bedrijf specifieke beveiliging te laten bouwen, dat gaat ook een beetje ver
Daarom levert men vanilla rollen en permissielijsten uit, die te kopieren en aan te passen zijn. Het gros van het werk is zo al gedaan, alleen het finetunen moet nog. En als dat niet voldoende kan zijn (bijvoorbeeld voor row-level security), dan kan er altijd nog een extra query/view op de securitytabellen gebouwd worden. Maar alles na de uitlevering is consultancy werk en dus extra.
Conflicterende situaties heb je er overigens zou uit: als een gebruiker dingen ziet die ie niet mag zien, moet je de row-level security voor diegene inperken

Verder eensch: over zoiets moet je goed nadenken. heb zelf een paar keer een dergelijke inrichting mogen doen en da's een shitload of work, zeker bij een bedrijf met veel medewerkers.

[Equator]

Ik heb ook niet gezegd dat geen enkele leverancier er over nadenkt

Verder eensch: over zoiets moet je goed nadenken. heb zelf een paar keer een dergelijke inrichting mogen doen en da's een shitload of work, zeker bij een bedrijf met veel medewerkers.

Kijk, en daar zit vaak de crux.. Niet alle bedrijven willen tijd en geld investeren om zoiets goed in te (laten) richten en te testen. Met alle gevolgen van dien.

[eghie]

Kon je de hoeveelheid administratief werk om dit allemaal te beheren niet afvangen voor een deel met het aanmaken van taakgerichte groepen en daarop rechten zetten?

[The Eagle]

Equator schreef op maandag 23 augustus 2010 @ 09:13:
Ik heb ook niet gezegd dat geen enkele leverancier er over nadenkt


[...]

Kijk, en daar zit vaak de crux.. Niet alle bedrijven willen tijd en geld investeren om zoiets goed in te (laten) richten en te testen. Met alle gevolgen van dien.

Waar hem nog een crux zit: een van de kritische succesfactoren (bullshitbingo ) is een organisatie die staat en waarvan de bedrijfsprocessen eenduidig zijn gedefinieerd. Alleen dan kun je een goede RBAC neerleggen. Als er teveel wisselingen zijn in wie wat doet op welke afdeling, of samenvoegingen van bedrijfsonderdelen oid, dan ga je structureel nat.

[Equator]

Moet je eens bij de overheid gaan werken

[YellowOnline]

Equator schreef op dinsdag 24 augustus 2010 @ 08:48:
Moet je eens bij de overheid gaan werken

* YellowOnline steekt hand op en verwijst naar zijn eerdere post

[The Eagle]

YellowOnline schreef op dinsdag 24 augustus 2010 @ 09:13:
[...]


* YellowOnline steekt hand op en verwijst naar zijn eerdere post

5 jaar semi-overheid en 1,5 jaar bij een ministerie gezeten. Dont ask