Presentatie door KeesJan Kolbover Role Based Access Control (RBAC)

Attribute-based access control (ABAC)

En hoe je dit in een hybride sitatie kan toepassen.

Door gebruik te maken van een 2 laags rollen model

We doen dit door gebruik te maken van het “Identity Governance & Administration” IGA proces binnen alle IAM processenMet IGA tooling kan je bij een goede inrichting een hoger automatiseringsniveau behalen door het juiste gebruik van de combi RBAC vs ABAC

1

IGA heeft als doel om in control te komen over alle Identiteiten en bevoegdheden

Hiervoor zijn 3 vragen die belangrijk zijn om te stellen en als je alle vragen goed of postief kan beantwoorden dan ben je in control

• Wie heeft op dit moment bevoegdhedenWeet je als organisatie wie allemaal welke bevoegdheden heeft? Vaak is dat niet of met enorm veel inspanning te achterhalen en zeker niet waterdicht

• Zijn de bevoegdheden passendWeet je of alle uitgereikte bevoegdheden passend zijn voor de taken die een persoon voor z’n werk noodzakelijkerwijs (dagelijks) nodigheeft.Als iemand maar 1x of b.v. 12 x per jaar een rapport moet hebben uiteen applicatie dan moet je je afvragen of hij het hele jaar olledigetoegang nodig heft of dat het makkelijker is dat die person het rapport krijgt toegezonden / opvraagt bij een persoon die het dagelijksgebruikt,Ook bij doorstroom binnen de organisatie behouden mensen vaakrechten die ze niet meer nodig hebben voor hun nieuwe functie

2

• Kun je bewijzen dat je in controle bentKan je bewijzen dat je in controle bent. Zijn de bevoegdheden door de juiste mensen geaccordeerd, worden bevoegheden netjes weggehaald.Zijn er Rogue en Orphan accounts?

Wat is het grootse Risico op het gebied van bevoegdheden?De volgende Risico’s worden vaak genoemd

1. De uitgereikte bevoegdheden worden niet tijdig ingetrokken!Ja is een Risico maar misbruik is vaak beperkt.

2. Men heeft niet op tijd de juiste bevoegdheden! Hierdoor kunnen mensen na indienst komen of functie wijziging niet werken en dat kost geld of erger.De eind gebruiker ervaart dit als veel erger.

Eigenlijk is de grootste bedreiging iets geheel anders en vaak niet genoemd:Als iemands account is gehackt (bv door Fishing) dan wil je als organisatie weten welke toegang het account had tot data / applicaties / fysieke ruimtes.Wie moeten er allemaal op de hoogte gebracht worden en wie moeten er allemaal controleren of er misbruik is gemaakt van het account in de periode dat het gehackt was.

2

1. Doel applicaties beheren de autorisatie matrix binnen de doel applicatieVerantwoordelijk is de (Proces)Eigenaar van de applicatie / het proces.Voor grotere systemen zoals DOK adviseren we om dit te beleggen bij een autorisatie commissie.

2. Alle te gebruiken doelapplicatierollen zijn in OIM uitreikbaar als losse applicatie rol.- Dit kan via selfservice (standaard workflow)- De in OIM beschikbare Applicatie rol heeft een 1 op n relatie met de autorisaties binnen de applicatie- Een Applicatie rol heeft in principe alleen

3. Indien we voor een populatie users één of meer rollen automatisch willen uitreiken spreken we van een organisatie rol.- Een organisatie Rol wordt uitgereikt op basis van een Rule.- Een organisatie Rol is alleen gekoppeld aan één of meerdere eerder binnen OIM gedefinieerde applicatie Rol(len)- Een organisatie Rol is niet direct gekoppeld aan één of meerdere autorisaties in de matrix

3

Bevoegdheden zijn onder te verdelen in 2 categorieën.1e orde wat mag je zien.Vb

• in een EPD brieven, labuitslagen, rontgen beelden etc etc.

• In een ERP pakket (vb Oracle eBS, SAP) Crediteuren, debiteuren HRM administratie (lees of schrijfrechten)

2e Orde van wie mag je wat zien.

• Alleen patienten waarmee nje een behandelrelatie hebt

• Alleen personeelsdossiers van personen aan wie je leiding geeft etc

5

6

Er wordt veel ghebruik gemaakt van een flat RBAC model

Dit resulteert vaak in net zo veel rollen als medewerkers.Oorzaak is dat niet iedereen altijd hetzelfde doet en mensen vaak meerdere petten ophebben.Er worden niet 2 rollen uitgereikt aan 1 persoon maar wil max 1 rol per persoon

7

Flat RBAC is aantrekkelijk omdat men heel eenvoudig een nieuwe rol kan maken op basis van een oude rol.Je kopieerd de rol verwijderd eventueel een aantal bevoegdheden en voegd eventuele nieuwe extra bevoegdheden toe

8

9

Vaak wordt er gestart met een eenvoudige IGA inrichting

1. Er worden users geimpoprteerd uit 1 of meerdere autoritatievebronnen.

a) HRM als 1e bron we halen diverse extra attributen op die gebruikt worden voor het maken van Rules om rollen uit te reiken.Zoals functie, de afdeling waar iemand werkt maar ook de leidinggevende van een medewerker.

b) Ook wordt er data uit andere bronnen gehaald die nodig zijn voor of rules of om te grbruiken binnen het IGA proces of in de doelsystemen.Denk aan pasnummers voor fysieke toegang tot kluisjes of andere parkeer management systemen.Email adressen uit de AD om mailst te versturen binnen het IGA process maar ook soms noodzakelijk in de verschillende doelapplicaties

2. We hebben diverse doel systeemen aangesloten bv EBS / SAP als ERP pakket en HIX of Epic als EPD.Maar ook andere applicaties voor b.v. fysieke toegang, PMS, Skype, rooster software, CMS etcTevens is vak de AD gekoppeld om users aan te maken in de AD en

11

gebruikers te plaatsen in de verschillende noodzakelijke Usergroups.We halen uit al die systemen de rollen / autorisaties, usergroups op.

3. Tevens is er een semi automatische koppeling voor het laag hangende fruit.Deze koppeling verzend een email aan de beterffende beheerder van een applicatie om een gebruiker aan te maken en eventuele rechten in te stellen.

4. We kunnen gebruikers koppelen aan een applicatie rol via een gestandaariseerdeworkflowOp de volgende slide staat een voorbeeld van een workflow.

5. Ook is het mogelijk om op basis van Rules rollen automatisch te koppelen aan een rol.Hier creeren we als het ware ABAC op een ander niveau dan in de doel applicatie maar wel met een gelijkwaardig resultaat.

11

Hoe werkt de Workflow simpel uitgelegd.

1. Een gebruiker of een leidinggevende vraagt een Rol aan via selfservice (voor zichzelf of voor een ander.

2. De Leidinggevende dient te accorderen of de medewerker de Rol mag hebben.

• Indien de leidinggevende zelf de rol aanvraagt voor een van zijn rapporterenden dan wordt deze stap overgeslagen.

• Als een LG een rol voor zichzelf aanvraagt gaat de aanvraag naar zijn LG

3. Indien de leidinggevende niet akkoord gaat wordt de aanvrager geïnformeerd. En de workflow beeindigd

4. Indien de leidinggevende akkoord geeft wordt er gecontroleerd of er een proceseigenaar is (kan ook een groep mensen zijn) die accordmoeten geven.Een LG kan wel vinden dat je b.v. mutaties mag doen in de salaris administratie. Maar de PE van de SA heeft daar ook wat over te zeggen.PE zijn uitermate lastig te vinden

5. Als er geen proceseigenaar is gekoppeld aan de rol dan wordt deze direct uitgereikt

12

Op zich niet erg als de PE dat besluit. VB skype gebruik of toegang tot bepaalde lockers

6. Als er wel een proceseigenaar is dan moet deze ook een akkoord geven.indien geen akkoord dan wordt de aanvrager geinformeerd waarom niet

7. Als de proceseigenaar wel accoord dan wordt de rol uitgreiktEn indien noodzakelijk eerst een account angemaakt in het doel systeem

12

We onderscheiden in dit conceptuele model 2 lagen.

1. Laag met applicatiesHier hebben we alleen applicatie rollen. Er zijn in principe geen combinaties van verschillende rollenDeze rollen kunnen altijd via een workflow worden aangevraagd

2. Een laag met personenHier hebben we de organisatie rollen.Bij voorkeur worden deze rollen gevuld via Rules op basis van voor de user beschikbare attributen.BV alle artsen van een specialisme, alle mederwerkers van een bepaalde regio etc etc.Het is niet verstandig om deze rollen met de hand te vullen omdat het verleden heeft uitgewezen dat het heel verleidelijk is om een persoon aan een bealde andere rol te hangen om hem / haar zo eenvoudig toegandg te geven.Uitzondering zouden langdurige grote projecten kunnen zijn waarbij aan een grote groep project leden een grote verscheidenheid aan bevoegdheden moet worden uitgereikt.Zolang het doel de middelen heiligt heeft dit zin.Het heeft geen toegevoegde waarde om een rol te maken voor b.v. 1 persoon (CISO, directeur, Manager Finance etc)

13

13

Applicatie rollen mag iedereen aanvragen via de standaard workflow:NB eventueel afschermen is aan te raden mits de IGA tooling dit toe laat.Hierdoor wordt de catalogus overzichtelijker

1. Applicatie rol AB van applicatie A

2. Applicatie rol B van applicatie B

Deze rollen zijn aanvraagbaar voor iedereen

Op basis van attributen en rules kiunnen we organisatie rollen maken (2e laaag) = ABAC

1. VB alle managers

Als de proceseigenaar van applicatierol AB bepaald dat deze rol automatisch mag worden uitgereikt aan alle managers dan kunnen we een parent child relatie aanmaken tussen de organistaierol en de applicatienrolDit geld ook voor de PE van b.b applicatie B

NB.Rules onedrhouden op de 2e lag heft diverse voordelen

- Beheer is eenvoudiger als rules op de applicatie rol

- Beter inzicht in waarom (op basis van welke parent role) de rechten voor de applictie rol zijn verkregenApplicatie rollen zijn direct gekoppeld. Als ze zijn verkregen via een organisatie rol

14

dan is de rol als het ware iondirect uitgereikt

14

Herhaling van de voorgaande slides maar dan in een iets andere vorm

15

16

17

18

EzelsbruggetjeIAM staat voor

Ik Autoriseer Makkelijk (EN VEILIG)

19