🥇We bouwen een rolmodel voor toegangsbeheer. Deel een, voorbereidende fase

Momenteel werk ik bij een softwareleverancier, specifiek gericht op toegangsbeheersoplossingen. Mijn ervaring 'uit eerdere levens' is verbonden met de klantzijde - een grote financiële organisatie. Toen kon onze toegangscontrolegroep in de IT-beveiligingsafdeling niet vertellen over grote kunde in IdM. We hebben veel geleerd tijdens het proces en moesten de nodige obstakels overwinnen om in het bedrijf een functioneel mechanisme voor het beheer van gebruikersrechten in informatiesystemen op te zetten.

Door mijn opgedane ervaring aan de klantzijde te combineren met de kennis en vaardigheden van de leverancier, wil ik met jullie een soort stapsgewijze handleiding delen: hoe je in een groot bedrijf een rolmodel voor toegangsbeheer kunt opstellen en wat dit zal opleveren. Mijn handleiding is verdeeld in twee delen: het eerste deel - voorbereiden op het bouwen van het model, het tweede deel - het bouwen zelf. Voor u ligt het eerste deel, de voorbereidende fase.

N.B. Het opzetten van een rolmodel is helaas geen resultaat, maar een proces. Sterker nog, het is een onderdeel van het proces om in het bedrijf een ecosysteem voor toegangsbeheer te creëren. Bereid je dus voor op een lange adem.

Laten we eerst bepalen - wat is eigenlijk rolgebaseerd toegangsbeheer? Stel, je hebt een grote bank met tientallen of zelfs honderden duizenden medewerkers (subjekten), elk met tientallen toegangsrechten tot honderden interne informatiesystemen (objecten). Vermenigvuldig nu het aantal objecten met het aantal subjekten - dat zijn minstens zoveel verbindingen die je eerst moet opzetten en daarna moest controleren. Is het haalbaar om dit handmatig te doen? Natuurlijk niet - daarom zijn er rollen ontstaan.

Een rol is een set bevoegdheden die nodig zijn voor een gebruiker of een groep gebruikers om specifieke werkonderdelen uit te voeren. Elke medewerker kan één of meerdere rollen hebben, en elke rol kan van één tot veel bevoegdheden bevatten die aan de gebruiker zijn toegestaan binnen het kader van die rol. Rollen kunnen gekoppeld zijn aan specifieke functies, afdelingen of functionele taken van de medewerkers.

Rollen worden doorgaans samengesteld uit de individuele bevoegdheden van medewerkers in elk informatiesysteem. Vervolgens worden uit de rollen van elk systeem wereldwijde bedrijfsrollen gevormd. Bijvoorbeeld, de bedrijfsrol 'kredietmanager' omvat verschillende afzonderlijke rollen in informatiesystemen die worden gebruikt in het klantkantoor van de bank. Denk hierbij aan systemen zoals het hoofdautomatiseringssysteem van de bank, de kassamodule, het systeem voor elektronisch documentbeheer, de servicemanager en andere. Bedrijfsrollen worden meestal gekoppeld aan de organisatorische en functionele structuur – simpel gezegd, aan een set van afdelingen binnen het bedrijf en de functies daarin. Zo wordt de wereldwijde rollenmatrix gevormd (een voorbeeld geef ik in de tabel hieronder).

Het is belangrijk op te merken dat het onmogelijk is om een 100% rolmodel op te stellen, waarbij alle noodzakelijke rechten voor elke functie in een commerciële structuur zijn gewaarborgd. En het is ook niet nodig. Een rolmodel kan namelijk niet statisch zijn, omdat het afhankelijk is van de voortdurend veranderende omgeving. En van de veranderingen in de bedrijfsactiviteiten van het bedrijf, die op hun beurt invloed hebben op de wijziging van de organisatiestructuur en de functionaliteit. En van het gebrek aan volledige toewijzing van middelen, en van het niet naleven van functieomschrijvingen, en van de drang naar winst ten koste van veiligheid, en van vele andere factoren. Daarom moet er een rolmodel worden opgebouwd dat tot 80% van de behoeften van gebruikers aan de benodigde basisrechten kan dekken bij het aannemen van een functie. De overige 20% kunnen ze, indien nodig, later aanvragen per afzonderlijk verzoek.

Je kunt natuurlijk vragen: 'Is er dan überhaupt geen 100% rolmodel?' Maar waarom niet? Dit komt voor, bijvoorbeeld in non-profitstructuren die niet onderhevig zijn aan frequente veranderingen – zoals een onderzoeksinstituut. Of in organisaties in de defensiesector met een hoog beveiligingsniveau, waar veiligheid voorop staat. Het kan ook voorkomen in een commerciële structuur, maar dan binnen een specifiek onderdeel waarvan de werking relatief statisch en voorspelbaar is.

Het grootste voordeel van rolbeheer is de vereenvoudiging van het verlenen van rechten, omdat het aantal rollen aanzienlijk lager is dan het aantal gebruikers van het informatiesysteem. Dit geldt voor elke sector.

Laten we een retailbedrijf nemen: daar werken duizenden verkopers, maar ze hebben dezelfde rechten in het systeem N, en er wordt maar één rol voor hen aangemaakt. Wanneer er een nieuwe verkoper in het bedrijf komt, krijgt hij automatisch de benodigde rol in het systeem, waarin alle vereiste bevoegdheden al zijn opgenomen. Ook kan met één klik de rechten voor duizenden verkopers tegelijk worden gewijzigd, bijvoorbeeld door een nieuwe optie voor het genereren van rapporten toe te voegen. Het is niet nodig om duizend handelingen te verrichten door het nieuwe recht aan elke gebruikersaccount te koppelen – het is voldoende om deze optie aan de rol toe te voegen, en het zal tegelijk voor alle verkopers verschijnen.

Een ander voordeel van rolbeheer is de uitsluiting van de toekenning van onverenigbare bevoegdheden. Dat wil zeggen, een medewerker met een bepaalde rol in het systeem kan niet tegelijkertijd een andere rol hebben waarvan de rechten niet samengaan met de rechten in de eerste rol. Een duidelijk voorbeeld is het verbod op het combineren van de functies van invoer en controle van financiële transacties.

Iedereen die geïnteresseerd is in hoe rolbeheer voor toegang eigenlijk is ontstaan, kan
een kijkje nemen in de geschiedenis
Als we naar de geschiedenis kijken, dan heeft de IT-gemeenschap zich voor het eerst in de jaren '70 van de 20e eeuw Gedanken gemaakt over methoden voor toegangsbeheer. Hoewel de toepassingen toen vrij eenvoudig waren, wilden mensen net als nu handig toegang tot hen beheren. Rechten van gebruikers verstrekken, wijzigen en controleren – gewoon om gemakkelijker te begrijpen welke toegang elke gebruiker heeft. Maar op dat moment waren er geen algemene standaarden, de eerste systemen voor toegangsbeheer werden ontwikkeld, en elk bedrijf baseerde zich op zijn eigen opvattingen en regels.

Tegenwoordig zijn er al veel verschillende modellen voor toegangsbeheer bekend, maar die zijn niet allemaal tegelijk ontstaan. Laten we ons richten op de modellen die een merkbare bijdrage hebben geleverd aan de ontwikkeling van dit gebied.

Het eerste en waarschijnlijk eenvoudigste model is Discretionair (selectief) toegangsbeheer (DAC – Discretionary access control). Dit model houdt in dat de rechten door alle deelnemers in het toegangproces gezamenlijk worden gebruikt. Elke gebruiker krijgt toegang tot specifieke objecten of operaties. In wezen komt dit neer op een veelheid aan subjects van rechten die overeenkomen met een veelheid aan objecten. Dit model werd echter als te flexibel en te complex voor beheer beschouwd: toegangsrechtenlijsten worden na verloop van tijd enorm en moeilijk te beheersen.

Het tweede model is Verplichte toegangscontrole (MAC — Mandatory access control). In dit model krijgt elke gebruiker toegang tot een object op basis van een verleende toestemming voor een bepaald niveau van gegevensbeveiliging. Dienovereenkomstig moeten de objecten worden gecategoriseerd op basis van het niveau van vertrouwelijkheid. In tegenstelling tot het eerste flexibele model, bleek deze, daarentegen, te streng en beperkend te zijn. Het gebruik ervan rechtvaardigt zich niet wanneer er in een bedrijf veel diverse informatiebronnen zijn: om de toegang tot verschillende middelen te scheiden, moeten er talrijke categorieën worden ingevoerd, die niet zullen overlappen.

Gezien de duidelijke gebreken van deze twee methoden, bleef de IT-gemeenschap modellen ontwikkelen die flexibeler zijn en meer of minder universeel zijn voor het ondersteunen van verschillende soorten organisatorische toegangscontroles. En zo kwam de derde rolgebaseerde toegangscontrole! Deze aanpak bleek de meest veelbelovende te zijn, omdat deze niet alleen de autorisatie van de identiteit van de gebruiker vereist, maar ook zijn werkfuncties in systemen.

De eerste duidelijk beschreven structuur van het rolgebaseerde model werd in 1992 voorgesteld door de Amerikaanse wetenschappers David Ferraiolo en Richard Kuhn van het National Institute of Standards and Technology in de VS. Voor het eerst werd toen de term RBAC (Role-based access control) geïntroduceerd. Deze onderzoeken en de beschrijvingen van de belangrijkste componenten, evenals hun onderlinge relaties, vormden de basis voor de tot op de dag van vandaag geldende standaard INCITS 359-2012, goedgekeurd door het International Committee for Information Technology Standards (INCITS).

De standaard definieert een rol als "een positie binnen een organisatie met een bepaalde semantiek met betrekking tot de bevoegdheden en verantwoordelijkheden die aan de gebruiker zijn toegewezen die aan de rol is verbonden". Het document stelt de basiscomponenten van RBAC vast - gebruikers, sessies, rollen, bevoegdheden, operaties en objecten, evenals de relaties en verbindingen daartussen.

De standaard biedt een minimale structuur voor het opbouwen van een rolmodel - het combineren van rechten in rollen en vervolgens het uitgeven van toegang aan gebruikers via deze rollen. Er zijn mechanismen voor het samenstellen van rollen uit objecten en operaties gedefinieerd, evenals de hiërarchie van rollen en de erfelijkheid van bevoegdheden. In elk bedrijf zijn er rollen die elementaire bevoegdheden combineren die noodzakelijk zijn voor alle medewerkers. Dit kan toegang tot e-mail, een Document Management Systeem, een bedrijfsportaal, enzovoort zijn. Deze bevoegdheden kunnen worden samengevoegd in één algemene rol genaamd "medewerker", zodat het niet nodig is om in elke hogere rol opnieuw alle elementaire rechten op te sommen. Het volstaat om simpelweg de erfelijkheid van de rol "medewerker" aan te geven.

Later is de standaard aangevuld met nieuwe toegangseigenschappen die verband houden met het voortdurend veranderende milieu. Er is de mogelijkheid toegevoegd om statische en dynamische beperkingen in te voeren. Statische beperkingen houden in dat het niet mogelijk is om rollen te combineren (de eerder genoemde invoer en controle van operaties). Dynamische beperkingen kunnen worden bepaald door veranderende parameters, zoals tijd (werk- /niet-werkuren of -dagen), locatie (kantoor /huis), enzovoort.

Het is apart vermeldenswaard dat toegangscontrole op basis van attributen (ABAC - Attribute-based access control). De aanpak is gebaseerd op het verlenen van toegang via gedeelde attribuutregels. Dit model kan afzonderlijk worden gebruikt, maar wordt vaak actief aangevuld met de klassieke rolbenadering: aan een bepaalde rol kunnen attributen van gebruikers, middelen en apparaten, evenals tijd of locatie worden toegevoegd. Dit maakt het mogelijk om minder rollen te gebruiken, extra beperkingen in te voeren en de toegang minimaal voldoende te maken, waardoor de veiligheid wordt verhoogd.

Bijvoorbeeld, een boekhouder kan toegang tot rekeningen krijgen als hij in een bepaald gebied werkt. Dan wordt de locatie van de specialist vergeleken met een bepaalde referentiewaarde. Of men kan alleen toegang tot rekeningen geven als de gebruiker zich aanmeldt vanaf een geregistreerd apparaat. Een goede aanvulling op het rolmodel, maar wordt zelden zelfstandig gebruikt vanwege de noodzaak om veel regels en permissietabellen te creëren.

Laat me een voorbeeld geven van de toepassing van ABAC uit mijn 'vorige leven'. In onze bank waren er verschillende filialen. Medewerkers van de klantkantoren in deze filialen voerden absoluut dezelfde handelingen uit, maar moesten alleen met de rekeningen van hun regio in het hoofdsysteem werken. Aanvankelijk begonnen we afzonderlijke rollen voor elke regio te creëren - en er waren dus ontzettend veel van deze rollen met herhalende functionaliteit, maar met toegang tot verschillende rekeningen! Toen hebben we, door het locatieattribuut voor de gebruiker te gebruiken en dit te koppelen aan een specifiek bereik van rekeningen voor controle, het aantal rollen in het systeem aanzienlijk verminderd. Uiteindelijk bleven er alleen rollen voor één filiaal over, die werden gerepliceerd naar de bijbehorende posities in alle andere territoriale onderdelen van de bank.

Laten we nu praten over de noodzakelijke voorbereidende stappen, zonder welke het gewoon niet mogelijk is om een werkend rolmodel op te bouwen.

Stap 1. We creëren een functioneel model

Het is belangrijk om te beginnen met het opstellen van een functioneel model – een document op hoog niveau waarin de functionaliteiten van elke afdeling en elke functie gedetailleerd worden beschreven. Meestal komt de informatie hieruit voort uit verschillende documenten: functieomschrijvingen en regelgevingen met betrekking tot specifieke afdelingen – secties, afdelingen, directies. Het functionele model moet worden afgestemd met alle betrokken afdelingen (bedrijf, interne controle, beveiliging) en goedgekeurd door het management van het bedrijf. Waarom is dit document nodig? Zodat het rolmodel hierop kan verwijzen. Bijvoorbeeld, als u van plan bent een rolmodel te bouwen gebaseerd op al bestaande rechten van medewerkers – geëxporteerd uit het systeem en 'genormaliseerd'. Dan kan bij de goedkeuring van de verkregen rollen met de business owner van het systeem worden verwezen naar een specifiek punt in het functionele model, op basis waarvan een bepaald recht in een rol wordt opgenomen.

Stap 2. We auditeren IT-systemen en stellen een prioriteringsplan op

In de tweede fase moet een audit van de IT-systemen worden uitgevoerd om te begrijpen hoe de toegang hierin is georganiseerd. Bijvoorbeeld, in mijn financiële bedrijf werden er honderden informatiesystemen gebruikt. In alle systemen waren er enkele aanzetten tot rolbeheer, in de meeste systemen waren er bepaalde rollen, maar voornamelijk op papier of in de systeemgids – deze waren al lang verouderd, en de toegang werd verstrekt op basis van feitelijke verzoeken van gebruikers. Het was uiteraard onmogelijk om onmiddellijk een rolmodel op te bouwen in enkele honderden systemen; er moet ergens worden begonnen. We hebben een diepgaande analyse van het toegangsbeheerproces uitgevoerd om de volwassenheid ervan te bepalen. Tijdens de analyse hebben we criteria voor de prioritering van informatiesystemen ontwikkeld – kritikaliteit, gereedheid, plannen voor buitengebruikstelling, enzovoort. Met deze hulpmiddelen hebben we een volgorde opgesteld voor de ontwikkeling/actualisatie van rolmodellen voor deze systemen. Vervolgens hebben we de rolmodellen opgenomen in het integratieplan met de oplossing voor Identity Management, om het toegangsbeheer te automatiseren.

Hoe bepaalt u de kritikaliteit van een systeem? Beantwoord de volgende vragen:

Is het systeem verbonden met operationele processen waarvan de uitvoering van essentieel belang is voor de kernactiviteiten van het bedrijf?
Zal een storing in de werking van het systeem van invloed zijn op de integriteit van de activa van het bedrijf?
Wat is de maximaal toegestane uitvaltijd van het systeem, waarna het niet meer mogelijk is om de activiteiten te herstellen na een onderbreking?
Kan een schending van de informatie-integriteit in het systeem leiden tot onomkeerbare gevolgen, zowel financieel als reputatiegebonden?
Bruikbaarheid in verband met fraude. De aanwezigheid van functionaliteit waarbij onvoldoende controle mogelijk is dat interne/externe frauduleuze acties worden uitgevoerd;
Wat zijn de vereisten van de wetgeving en ook de interne regels en procedures voor deze systemen? Zullen er boetes van toezichthouders zijn voor niet-naleving?

In ons financiële bedrijf hebben we een audit op deze manier uitgevoerd. Het management heeft de procedure voor de Audit Access Right Review ontwikkeld om de bestaande gebruikers en rechten te begrijpen, aanvankelijk in die informatiesystemen die op de lijst van hoogste prioriteit stonden. De eigenaar van dit proces werd toegewezen aan de beveiligingsafdeling. Maar voor een compleet beeld van de toegangsrechten binnen het bedrijf moest de IT- en bedrijfsafdeling bij het proces worden betrokken. En hier begonnen de geschillen, misverstanden en soms zelfs sabotage: niemand wil zijn huidige verantwoordelijkheden loslaten en zich mengen in ogenschijnlijk onduidelijke activiteiten.

N.B. Grote bedrijven met ontwikkelde IT-processen zijn ongetwijfeld bekend met de IT-auditprocedure – IT general controls (ITGC), die tekortkomingen in IT-processen kan identificeren en de controle kan verbeteren zodat de processen kunnen worden geoptimaliseerd volgens best practices (ITIL, COBIT, IT Governance, enz.). Een dergelijke audit stelt IT en het bedrijfsleven in staat om elkaar beter te begrijpen en een gezamenlijke ontwikkelingsstrategie te formuleren, risico's te analyseren, kosten te optimaliseren en effectievere werkmethoden te ontwikkelen.

Een van de auditgebieden is het bepalen van de parameters voor logische en fysieke toegang tot informatiesystemen. De verkregen gegevens hebben we als basis genomen voor verder gebruik bij de opbouw van het rolmodel. Als resultaat van deze audit hebben we een register van IT-systemen opgesteld, waarin hun technische parameters zijn gedefinieerd en beschrijvingen zijn gegeven. Daarnaast is voor elk systeem een eigenaar van de businessafdeling aangewezen, die ervoor verantwoordelijk was: deze persoon was verantwoordelijk voor de bedrijfsprocessen die door dit systeem werden ondersteund. Ook is er een IT-servicemanager aangesteld die verantwoordelijk was voor de technische implementatie van de zakelijke behoeften in het specifieke informatiesysteem. De meest kritische systemen voor het bedrijf en hun technische parameters, de invoer- en uitvoerdata in gebruik, enzovoort, zijn vastgelegd. Deze parameters hebben enorm geholpen in het voorbereidingsproces voor de opbouw van het rolmodel.

Stap 3 We creëren een methodologie

De sleutel tot het succes van elke onderneming is de juiste gekozen methode. Daarom is het noodzakelijk om zowel voor de opbouw van het rolmodel als voor het uitvoeren van de audit een methodologie te creëren, waarin we de interactie tussen afdelingen beschrijven, verantwoordelijkheden vastleggen in de bedrijfsreglementen, enzovoort.
Allereerst moeten we alle beschikbare documenten onderzoeken die de procedure voor toegang en rechten vaststellen. Idealiter zouden de processen op meerdere niveaus gedocumenteerd moeten zijn:

algemene bedrijfsvereisten;
vereisten voor beveiligingsgebieden (afhankelijk van de bedrijfsactiviteiten);
vereisten voor technologische processen (instructies, toegangsmatrices, richtlijnen, configuratie-eisen).

In ons financiële bedrijf hebben we veel verouderde documenten ontdekt – deze moesten in overeenstemming worden gebracht met de nieuwe processen die we implementeerden.

Per bevel van het management is er een werkgroep opgericht, bestaande uit vertegenwoordigers van de afdelingen veiligheid, IT, bedrijfsvoering en interne controle. In het bevel zijn de doelstellingen van de groep, de richting van de activiteiten, de termijn van bestaan en de verantwoordelijken van elke partij vastgelegd. Daarnaast hebben we een methodiek voor het uitvoeren van audits ontwikkeld en een rolmodel opgesteld: deze zijn goedgekeurd door alle verantwoordelijke vertegenwoordigers van de afdelingen en het management van het bedrijf.

Documenten die de procedure voor het uitvoeren van werkzaamheden, termijnen, verantwoordelijkheden, enz. beschrijven – zijn de sleutel tot het feit dat niemand op de weg naar het gewenste doel, dat in het begin niet voor iedereen duidelijk is, vragen zal hebben als "waarom doen we dit, wat hebben we eraan, enz." en er zal geen mogelijkheid zijn om "af te haken" of het proces te vertragen.

Stap 4. We documenteren de parameters van het bestaande toegangsbeheermodel

We stellen een zogenaamde "systeempas" op met betrekking tot het toegangsbeheer. Eigenlijk is dit een vragenlijst voor een specifiek informatiesysteem, waarin alle algoritmen voor toegang tot het systeem zijn vastgelegd. Bedrijven die al oplossingen van de klasse IdM hebben geïmplementeerd, zijn waarschijnlijk bekend met een dergelijke vragenlijst, aangezien deze als startpunt dient voor de studie van systemen.

Een deel van de parameters over het systeem en de eigenaren is uit het IT-register in de vragenlijst overgenomen (zie stap 2, audit), maar er zijn ook nieuwe toegevoegd:

hoe het beheer van gebruikersaccounts plaatsvindt (rechtstreeks in de database of via programmeerinterfaces);
hoe gebruikers inloggen in het systeem (met behulp van een aparte account of met gebruikmaking van een AD-, LDAP-account of soortgelijke);
welke toegangslevels in het systeem worden gebruikt (applicatieniveau, systeemniveau, gebruik door het systeem van netwerkbestandsbronnen);
beschrijving en parameters servers, waarop het systeem werkt;
welke bewerkingen voor het beheer van gebruikersaccounts worden ondersteund (blokkeren, hernoemen, enz.);
op basis van welke algoritmen of regels de gebruikersidentificatie in het systeem wordt gevormd;
op basis van welk attribuut de verbinding met het personeelsrecord in het personeelsysteem kan worden gelegd (naam, personeelsnummer of iets dergelijks);
alle mogelijke attributen van het gebruikersaccount en de regels voor het invullen ervan;
welke toegangsrechten in het systeem bestaan (rollen, groepen, atomische rechten, enz., zijn er geneste of hiërarchische rechten);
mechanismen voor toegangstoewijzing (op basis van functie, afdeling, functionaliteit, enz.);
zijn er binnen het systeem regels voor scheiding van plichten (SOD – Segregation of Duties), en hoe functioneren die;
hoe worden gebeurtenissen van afwezigheid, overplaatsing, ontslag, gegevensupdate van medewerkers, enz. in het systeem verwerkt;

Dit lijstje kan verder worden uitgebreid met details over verschillende parameters en andere objecten die betrokken zijn bij het toegangsbeheer.

Stap 5. We creëren een businessgericht beschrijving van bevoegdheden

Een ander document dat we nodig zullen hebben bij het opbouwen van het rollenschema, is een handleiding voor alle mogelijke bevoegdheden (rechten) die aan gebruikers binnen het informatiesysteem kunnen worden verleend, met een gedetailleerde beschrijving van de bedrijfsfunctie die erachter zit. Vaak zijn bevoegdheden in het systeem gecodeerd met specifieke benamingen van letters en cijfers, waardoor medewerkers van het bedrijf niet kunnen begrijpen wat deze symbolen betekenen. Dan gaan ze naar de IT-afdeling en daar… kan men ook geen antwoord geven op vragen over bijvoorbeeld zelden gebruikte rechten. Soms is extra testwerk noodzakelijk.

Het is ideaal als een bedrijfsbeschrijving al bestaat of als er zelfs een verzameling van deze rechten in groepen en rollen is. Voor sommige applicaties is het beste praktijk om zo'n handleiding al tijdens de ontwikkelingsfase te maken. Maar dat gebeurt niet vaak, dus moeten we weer naar de IT-afdeling om informatie te verzamelen over alle mogelijke rechten en deze te beschrijven. Onze handleiding zal uiteindelijk het volgende bevatten:

de naam van de bevoegdheid, inclusief het object waarop het toegangrecht van toepassing is;
de actie die met het object mag worden uitgevoerd (zien, wijzigen, enz., met mogelijk beperkingen, bijvoorbeeld op basis van territorium of klantgroep);
de code van de bevoegdheid (code en naam van de functie/verzoek in het systeem die met de bevoegdheid kan worden uitgevoerd);
de beschrijving van de bevoegdheid (gedetailleerde beschrijving van de acties in het informatiesysteem bij toepassing van de bevoegdheid en de gevolgen voor het proces;
de status van de bevoegdheid: "Actief" (als de bevoegdheid aan ten minste één gebruiker is toegewezen) of "Inactief" (als de bevoegdheid niet wordt gebruikt).

Stap 6 Exporteer gegevens over gebruikers en rechten uit de systemen en koppel deze aan de HR-bron.

In de laatste fase van de voorbereiding moeten de gegevens uit de informatiesystemen over alle gebruikers en hun huidige rechten worden geëxporteerd. Er zijn hier twee scenario's mogelijk. Eerste: de beveiligingsafdeling heeft directe toegang tot het systeem en beschikt over de middelen om de betreffende rapporten te exporteren, wat niet vaak voorkomt, maar wel erg handig is. Tweede: we sturen een verzoek naar IT om de rapporten in het gewenste formaat te ontvangen. De praktijk leert: het lukt vaak niet om met IT overeenstemming te bereiken en de benodigde gegevens de eerste keer te verkrijgen. Er zijn meerdere pogingen nodig totdat de informatie in de juiste vorm en het juiste formaat is verkregen.

Welke gegevens moeten worden geëxporteerd:

De naam van het account
Naam van de medewerker aan wie het is toegewezen
Status (actief of geblokkeerd)
Datum van aanmaak van het account
Datum van laatste gebruik
Lijst van beschikbare rechten/groepen/rollen

Dus, we hebben exporten uit het systeem ontvangen met alle gebruikers en alle rechten die aan hen zijn verleend. En we hebben meteen alle geblokkeerde accounts opzij gelegd, aangezien het werk aan het opbouwen van het rolmodel alleen met actieve gebruikers zal plaatsvinden.

Vervolgens, als uw bedrijf geen geautomatiseerde middelen heeft om de toegang van ontslagen medewerkers te sluiten (dit komt vaak voor) of als er een gefragmenteerde automatisering is die niet altijd correct functioneert, moet u alle "dode zielen" identificeren. Dit betreft accounts van al ontslagen medewerkers wiens rechten om de een of andere reden niet zijn geblokkeerd – deze moeten worden geblokkeerd. Daartoe vergelijken we de geëxporteerde gegevens met de personeelsbron. De personeels-export moet ook vooraf worden verkregen van de afdeling die de personeelsdatabase beheert.

Het is nodig om de accounts apart te houden waarvan de eigenaren niet in de personeelsdatabase zijn gevonden, die aan niemand zijn toegewezen - dus zonder eigenaar. Voor deze lijst hebben we de datum van de laatste gebruik nodig: als deze vrij recent is, moeten we toch op zoek gaan naar de eigenaren. Dit kan accounts van externe contractanten omvatten of dienstaccounts die aan niemand zijn toegewezen, maar wel verbonden zijn met bepaalde processen. Om de eigendom van de accounts te achterhalen, kunnen we brieven rondsturen naar alle afdelingen met het verzoek om te reageren. Zodra de eigenaren zijn gevonden, voegen we hun gegevens in het systeem in: zo zijn alle actieve accounts geïdentificeerd en blokkeren we de rest.

Zodra onze exports zijn schoongemaakt van overbodige records en alleen actieve accounts zijn overgebleven, kunnen we beginnen met het opbouwen van een rolmodel voor het specifieke informatiesysteem. Maar hierover zal ik in het volgende artikel vertellen.

Auteur: Lyudmila Sevastyanova, Marketing Manager bij Solar inRights

Bron: habr.com