We bouwen een op rollen gebaseerd toegangscontrolemodel. Deel één, voorbereidend

Momenteel werk ik voor een softwareleverancier, met name toegangscontroleoplossingen. En mijn ervaring ‘uit een vorig leven’ houdt verband met de kant van de klant: een grote financiële organisatie. Onze toegangscontrolegroep op de afdeling informatiebeveiliging kon destijds niet bogen op grote competenties op het gebied van IdM. We hebben veel geleerd tijdens het proces, we hebben veel hobbels moeten overwinnen om een ​​werkend mechanisme op te bouwen voor het beheer van gebruikersrechten in informatiesystemen in het bedrijf.

Door mijn zuurverdiende klantervaring te combineren met de kennis en competenties van leveranciers, wil ik in wezen stapsgewijze instructies met u delen: hoe u een op rollen gebaseerd toegangscontrolemodel kunt creëren in een groot bedrijf, en wat dit als resultaat zal opleveren . Mijn instructies bestaan ​​uit twee delen: het eerste is het voorbereiden van het model, het tweede is het daadwerkelijk bouwen. Hier is het eerste deel, het voorbereidende deel.

NB Het bouwen van een rolmodel is helaas geen resultaat, maar een proces. Of beter gezegd, zelfs onderdeel van het proces van het creëren van een toegangscontrole-ecosysteem in het bedrijf. Maak je dus lang klaar voor het spel.

Laten we het eerst definiëren: wat is op rollen gebaseerd toegangscontrole? Stel je hebt een grote bank met tientallen of zelfs honderdduizenden medewerkers (entiteiten), die ieder tientallen toegangsrechten hebben tot honderden interne bankinformatiesystemen (objecten). Vermenigvuldig nu het aantal objecten met het aantal onderwerpen - dit is het minimale aantal verbindingen dat je eerst moet bouwen en vervolgens moet controleren. Is het echt mogelijk om dit handmatig te doen? Natuurlijk niet: er zijn rollen gecreëerd om dit probleem op te lossen.

Een rol is een set machtigingen die een gebruiker of groep gebruikers nodig heeft om bepaalde werktaken uit te voeren. Elke medewerker kan één of meer rollen hebben, en elke rol kan één tot vele machtigingen bevatten die aan de gebruiker binnen die rol zijn toegestaan. Rollen kunnen worden gekoppeld aan specifieke functies, afdelingen of functionele taken van medewerkers.

Rollen worden doorgaans aangemaakt op basis van individuele werknemersautorisaties in elk informatiesysteem. Vervolgens worden mondiale bedrijfsrollen gevormd op basis van de rollen van elk systeem. De bedrijfsrol 'kredietmanager' zal bijvoorbeeld verschillende afzonderlijke rollen omvatten in de informatiesystemen die worden gebruikt in het klantenkantoor van de bank. Bijvoorbeeld in het belangrijkste geautomatiseerde banksysteem, de geldmodule, het elektronische documentbeheersysteem, de servicemanager en andere. Bedrijfsrollen zijn in de regel gebonden aan de organisatiestructuur, met andere woorden, aan de reeks bedrijfsdivisies en posities daarin. Dit is hoe een globale rollenmatrix wordt gevormd (ik geef een voorbeeld in de onderstaande tabel).

Het is vermeldenswaard dat het simpelweg onmogelijk is om een ​​100% rolmodel op te bouwen, dat alle noodzakelijke rechten biedt aan werknemers van elke positie in een commerciële structuur. Ja, dit is niet nodig. Een rolmodel kan immers niet statisch zijn, omdat het afhankelijk is van een voortdurend veranderende omgeving. En van veranderingen in de bedrijfsactiviteiten van het bedrijf, die bijgevolg veranderingen in de organisatiestructuur en functionaliteit beïnvloeden. En door het gebrek aan volledige voorziening van middelen, en door het niet naleven van functiebeschrijvingen, en door het verlangen naar winst ten koste van de veiligheid, en door vele andere factoren. Daarom is het noodzakelijk om een ​​rolmodel op te bouwen dat tot 80% van de gebruikersbehoeften voor de noodzakelijke basisrechten kan dekken wanneer deze aan een functie worden toegewezen. En de overige 20% kunnen ze desnoods later op aparte aanvragen opvragen.

Natuurlijk kun je je afvragen: “Bestaat er niet zoiets als 100% rolmodellen?” Welnu, dit gebeurt bijvoorbeeld in non-profitstructuren die niet onderhevig zijn aan frequente veranderingen - in een onderzoeksinstituut. Of in militair-industriële complexe organisaties met een hoog beveiligingsniveau, waar veiligheid voorop staat. Het gebeurt in een commerciële structuur, maar binnen het raamwerk van een afzonderlijke divisie, waarvan het werk een tamelijk statisch en voorspelbaar proces is.

Het belangrijkste voordeel van rolgebaseerd beheer is de vereenvoudiging van de uitgifte van rechten, omdat het aantal rollen aanzienlijk kleiner is dan het aantal gebruikers van het informatiesysteem. En dit geldt voor elke branche.

Laten we een detailhandelsbedrijf nemen: het heeft duizenden verkopers in dienst, maar ze hebben dezelfde rechten in systeem N, en er wordt slechts één rol voor hen gecreëerd. Wanneer een nieuwe verkoper bij het bedrijf komt, krijgt hij automatisch de vereiste rol toegewezen in het systeem, dat al over alle benodigde bevoegdheden beschikt. Ook kunt u met één klik de rechten voor duizenden verkopers in één keer wijzigen, bijvoorbeeld een nieuwe optie toevoegen voor het genereren van een rapport. Het is niet nodig om duizend handelingen uit te voeren, waarbij u aan elk account een nieuw recht koppelt - voeg deze optie gewoon toe aan de rol en deze verschijnt voor alle verkopers tegelijkertijd.

Een ander voordeel van rolgebaseerd beheer is het elimineren van de uitgifte van onverenigbare autorisaties. Dat wil zeggen dat een werknemer die een bepaalde rol in het systeem vervult, niet tegelijkertijd een andere rol kan vervullen, waarvan de rechten niet mogen worden gecombineerd met de rechten in de eerste. Een sprekend voorbeeld is het verbod op het combineren van de functies van invoer en controle van een financiële transactie.

Iedereen die geïnteresseerd is in hoe rolgebaseerde toegangscontrole tot stand is gekomen, kan dat doen
duik in de geschiedenis
Als we naar de geschiedenis kijken, dacht de IT-gemeenschap voor het eerst na over toegangscontrolemethoden in de jaren zeventig van de twintigste eeuw. Hoewel applicaties toen, net als nu, vrij eenvoudig waren, wilde iedereen de toegang ertoe gemakkelijk kunnen beheren. Verleen, wijzig en beheer gebruikersrechten - gewoon om het gemakkelijker te maken om te begrijpen welke toegang elk van hen heeft. Maar in die tijd waren er geen gemeenschappelijke normen, de eerste toegangscontrolesystemen werden ontwikkeld en elk bedrijf was gebaseerd op zijn eigen ideeën en regels.

Er zijn inmiddels veel verschillende modellen voor toegangscontrole bekend, maar deze verschenen niet meteen. Laten we stilstaan ​​bij degenen die een belangrijke bijdrage hebben geleverd aan de ontwikkeling van dit gebied.

Het eerste en waarschijnlijk het eenvoudigste model is Discretionaire (selectieve) toegangscontrole (DAC – Discretionaire toegangscontrole). Dit model impliceert het delen van rechten door alle deelnemers aan het toegangsproces. Elke gebruiker heeft toegang tot specifieke objecten of bewerkingen. In wezen komt de verzameling rechtensubjecten hier overeen met de verzameling objecten. Dit model bleek te flexibel en te moeilijk te onderhouden: toegangslijsten worden uiteindelijk enorm groot en moeilijk te controleren.

Het tweede model is Verplichte toegangscontrole (MAC - Verplichte toegangscontrole). Volgens dit model krijgt elke gebruiker toegang tot een object in overeenstemming met de verleende toegang tot een bepaald niveau van gegevensvertrouwelijkheid. Dienovereenkomstig moeten objecten worden gecategoriseerd op basis van hun niveau van vertrouwelijkheid. In tegenstelling tot het eerste flexibele model bleek dit juist te streng en restrictief te zijn. Het gebruik ervan is niet gerechtvaardigd als het bedrijf over veel verschillende informatiebronnen beschikt: om de toegang tot verschillende bronnen te differentiëren, zul je veel categorieën moeten introduceren die elkaar niet overlappen.

Vanwege de voor de hand liggende onvolkomenheden van deze twee methoden is de IT-gemeenschap modellen blijven ontwikkelen die flexibeler zijn en tegelijkertijd min of meer universeel om verschillende soorten toegangscontrolebeleid voor organisaties te ondersteunen. En toen verscheen het het derde op rollen gebaseerde toegangscontrolemodel! Deze aanpak is de meest veelbelovende gebleken omdat deze niet alleen autorisatie van de identiteit van de gebruiker vereist, maar ook van zijn operationele functies in de systemen.

De eerste duidelijk beschreven rolmodelstructuur werd in 1992 voorgesteld door de Amerikaanse wetenschappers David Ferrailo en Richard Kuhn van het Amerikaanse National Institute of Standards and Technology. Toen verscheen de term voor het eerst RBAC (op rollen gebaseerde toegangscontrole). Deze onderzoeken en beschrijvingen van de belangrijkste componenten, evenals hun relaties, vormden de basis van de INCITS 359-2012-standaard, die nog steeds van kracht is en goedgekeurd door het International Committee on Information Technology Standards (INCITS).

De standaard definieert een rol als "een functie in de context van een organisatie met een aantal bijbehorende semantiek met betrekking tot de autoriteit en verantwoordelijkheid die is toegewezen aan de gebruiker die aan de rol is toegewezen." Het document legt de basiselementen van RBAC vast: gebruikers, sessies, rollen, machtigingen, bewerkingen en objecten, evenals de relaties en onderlinge verbindingen daartussen.

De standaard biedt de minimaal noodzakelijke structuur voor het bouwen van een rolmodel: het combineren van rechten in rollen en het vervolgens verlenen van toegang aan gebruikers via deze rollen. De mechanismen voor het samenstellen van rollen uit objecten en operaties worden geschetst, de hiërarchie van rollen en de overerving van bevoegdheden worden beschreven. In elk bedrijf zijn er immers rollen die basisbevoegdheden combineren die nodig zijn voor alle werknemers van het bedrijf. Dit kan toegang zijn tot e-mail, EDMS, een bedrijfsportaal, enz. Deze rechten kunnen worden opgenomen in één algemene rol genaamd “werknemer”, en het is niet nodig om alle basisrechten steeds opnieuw op te sommen in elk van de rollen op een hoger niveau. Het is voldoende om eenvoudigweg het overervingskenmerk van de rol van “werknemer” aan te geven.

Later werd de standaard aangevuld met nieuwe toegangsattributen die verband hielden met de voortdurend veranderende omgeving. De mogelijkheid om statische en dynamische beperkingen te introduceren is toegevoegd. Statische impliceren de onmogelijkheid om rollen te combineren (dezelfde input en controle over operaties als hierboven vermeld). Dynamische beperkingen kunnen worden bepaald door parameters te wijzigen, bijvoorbeeld tijd (werk-/niet-werkuren of dagen), locatie (kantoor/thuis), etc.

Het is de moeite waard om het apart te vermelden op attributen gebaseerde toegangscontrole (ABAC - op attributen gebaseerde toegangscontrole). De aanpak is gebaseerd op het verlenen van toegang met behulp van regels voor het delen van attributen. Dit model kan afzonderlijk worden gebruikt, maar vormt vaak een actieve aanvulling op het klassieke rolmodel: attributen van gebruikers, middelen en apparaten, maar ook tijd of locatie, kunnen aan een bepaalde rol worden toegevoegd. Hierdoor kun je minder rollen gebruiken, extra beperkingen invoeren en de toegang zo minimaal mogelijk maken en daarmee de veiligheid verbeteren.

Een accountant kan bijvoorbeeld toegang krijgen tot rekeningen als hij in een bepaalde regio werkt. Vervolgens wordt de locatie van de specialist vergeleken met een bepaalde referentiewaarde. Of u kunt alleen toegang tot accounts geven als de gebruiker inlogt vanaf een apparaat dat in de lijst met toegestane accounts staat. Een goede aanvulling op een rolmodel, maar zelden op zichzelf gebruikt vanwege de noodzaak om veel regels en tabellen met machtigingen of beperkingen te maken.

Laat me je een voorbeeld geven van het gebruik van ABAC uit mijn “vorige leven”. Onze bank had verschillende vestigingen. Medewerkers van klantkantoren in deze vestigingen voerden precies dezelfde handelingen uit, maar moesten in het hoofdsysteem alleen werken met rekeningen in hun regio. Eerst zijn we begonnen met het maken van afzonderlijke rollen voor elke regio - en er waren zoveel van dergelijke rollen met herhalende functionaliteit, maar met toegang tot verschillende accounts! Vervolgens hebben we, door een locatiekenmerk voor de gebruiker te gebruiken en dit te koppelen aan een specifieke reeks te beoordelen accounts, het aantal rollen in het systeem aanzienlijk verminderd. Als gevolg hiervan bleven de rollen voor slechts één filiaal over, die werden herhaald voor de overeenkomstige posities in alle andere territoriale afdelingen van de bank.

Laten we het nu hebben over de noodzakelijke voorbereidende stappen, zonder welke het simpelweg onmogelijk is om een ​​werkend rolmodel te bouwen.

Stap 1. Maak een functioneel model

U moet beginnen met het maken van een functioneel model: een document op het hoogste niveau dat de functionaliteit van elke afdeling en elke functie in detail beschrijft. In de regel komt informatie binnen uit verschillende documenten: functiebeschrijvingen en regelgeving voor individuele eenheden - afdelingen, divisies, afdelingen. Het functionele model moet worden overeengekomen met alle betrokken afdelingen (business, interne controle, beveiliging) en goedgekeurd door het management van het bedrijf. Waar is dit document voor? Zodat het rolmodel ernaar kan verwijzen. Je gaat bijvoorbeeld een rolmodel bouwen op basis van de bestaande rechten van medewerkers – uit het systeem gehaald en ‘gereduceerd tot een gemeenschappelijke noemer’. Wanneer u vervolgens met de bedrijfseigenaar van het systeem overeenstemming bereikt over de ontvangen rollen, kunt u verwijzen naar een specifiek punt in het functionele model, op basis waarvan dit of dat recht in de rol is opgenomen.

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

In de tweede fase moet u een audit van IT-systemen uitvoeren om te begrijpen hoe de toegang daartoe is georganiseerd. Mijn financiële bedrijf exploiteerde bijvoorbeeld honderden informatiesystemen. Alle systemen hadden enkele beginselen van op rollen gebaseerd beheer, de meeste hadden enkele rollen, maar meestal op papier of in de systeemdirectory - ze waren al lang verouderd en toegang daartoe werd verleend op basis van daadwerkelijke gebruikersverzoeken. Het is uiteraard simpelweg onmogelijk om een ​​rolmodel in meerdere honderden systemen tegelijk te bouwen; je moet ergens beginnen. We hebben een diepgaande analyse van het toegangscontroleproces uitgevoerd om het volwassenheidsniveau ervan te bepalen. Tijdens het analyseproces werden criteria ontwikkeld voor het prioriteren van informatiesystemen: kriticiteit, gereedheid, plannen voor ontmanteling, enz. Met hun hulp hebben we de ontwikkeling/update van rolmodellen voor deze systemen op een rij gezet. En vervolgens hebben we rolmodellen opgenomen in het plan voor integratie met de Identity Management-oplossing om de toegangscontrole te automatiseren.

Dus hoe bepaal je de kriticiteit van een systeem? Beantwoord jezelf de volgende vragen:

• Is het systeem aangesloten op de operationele processen waarvan de kernactiviteiten van het bedrijf afhankelijk zijn?
• Zal een systeemverstoring de integriteit van de bedrijfsmiddelen aantasten?
• Wat is de maximaal toegestane downtime van het systeem, waarbij het onmogelijk is om de activiteit na een onderbreking te herstellen?
• Kan een schending van de integriteit van informatie in het systeem leiden tot onomkeerbare gevolgen, zowel financieel als reputatiegericht?
• Kritiek op fraude. De aanwezigheid van functionaliteit kan, indien niet goed gecontroleerd, leiden tot interne/externe frauduleuze acties;
• Wat zijn de wettelijke vereisten en interne regels en procedures voor deze systemen? Komen er boetes van toezichthouders voor niet-naleving?

In ons financiële bedrijf hebben we een dergelijke audit uitgevoerd. Het management ontwikkelde de Access Rights Review-auditprocedure om eerst naar bestaande gebruikers en rechten te kijken in de informatiesystemen die op de hoogste prioriteitslijst stonden. De beveiligingsafdeling werd aangewezen als eigenaar van dit proces. Maar om een ​​compleet beeld te krijgen van de toegangsrechten in het bedrijf, was het noodzakelijk om IT- en businessafdelingen bij het proces te betrekken. En hier begonnen geschillen, misverstanden en soms zelfs sabotage: niemand wil zich losmaken van zijn huidige verantwoordelijkheden en betrokken raken bij op het eerste gezicht onbegrijpelijke activiteiten.

NB Grote bedrijven met ontwikkelde IT-processen zijn waarschijnlijk bekend met de IT-auditprocedure - IT general control (ITGC), waarmee u tekortkomingen in IT-processen kunt identificeren en controle kunt instellen om processen te verbeteren in overeenstemming met de beste praktijken (ITIL, COBIT, IT Governance etc.) Door een dergelijke audit kunnen IT en het bedrijfsleven elkaar beter begrijpen en een gezamenlijke ontwikkelingsstrategie ontwikkelen, risico's analyseren, de kosten optimaliseren en effectievere werkmethoden ontwikkelen.



Een van de gebieden van de audit is het bepalen van de parameters van logische en fysieke toegang tot informatiesystemen. We hebben de verkregen gegevens als basis genomen voor verder gebruik bij het bouwen van een rolmodel. Als resultaat van deze audit beschikten we over een register van IT-systemen, waarin de technische parameters ervan werden bepaald en beschrijvingen werden gegeven. Bovendien werd voor elk systeem een ​​eigenaar geïdentificeerd vanuit de bedrijfsdirectie in wiens belang het werd geëxploiteerd: hij was verantwoordelijk voor de bedrijfsprocessen die dit systeem diende. Er werd ook een IT-servicemanager aangesteld, verantwoordelijk voor de technische implementatie van de bedrijfsbehoeften voor een specifieke IS. Er werden de meest kritische systemen voor het bedrijf vastgelegd en hun technische parameters, de voorwaarden voor inbedrijfstelling en ontmanteling, enz. Deze parameters waren zeer nuttig bij de voorbereiding op het creëren van een rolmodel.

Stap 3 Creëer een methodologie

De sleutel tot het succes van elk bedrijf is de juiste methode. Daarom moeten we, zowel om een ​​rolmodel op te bouwen als om een ​​audit uit te voeren, een methodologie creëren waarin we de interactie tussen afdelingen beschrijven, de verantwoordelijkheid vastleggen in de regelgeving van het bedrijf, enz.
Eerst moet u alle beschikbare documenten onderzoeken die de procedure voor het verlenen van toegang en rechten vastleggen. Op een goede manier moeten processen op verschillende niveaus worden gedocumenteerd:

• algemene bedrijfsvereisten;
• vereisten voor informatiebeveiligingsgebieden (afhankelijk van de activiteitengebieden van de organisatie);
• vereisten voor technologische processen (instructies, toegangsmatrices, richtlijnen, configuratievereisten).

In ons financiële bedrijf troffen we veel verouderde documenten aan; we moesten ze in overeenstemming brengen met de nieuwe processen die werden geïmplementeerd.

In opdracht van het management werd een werkgroep opgericht, waarin vertegenwoordigers van de beveiliging, IT, business en interne controle zitting hadden. De order schetste de doelstellingen van het creëren van de groep, de richting van de activiteit, de bestaansperiode en de verantwoordelijken van elke kant. Daarnaast hebben we een auditmethodologie en een procedure ontwikkeld voor het construeren van een rolmodel: deze zijn overeengekomen door alle verantwoordelijke vertegenwoordigers van de gebieden en goedgekeurd door het management van het bedrijf.

Documenten die de procedure voor het uitvoeren van werkzaamheden, deadlines, verantwoordelijkheden, enz. beschrijven. - een garantie dat op weg naar het gekoesterde doel, dat in eerste instantie niet voor iedereen duidelijk is, niemand vragen zal hebben “waarom doen we dit, waarom hebben we het nodig, enz.” en er zal geen mogelijkheid zijn om er van af te springen of het proces te vertragen.

Stap 4. Corrigeer de parameters van het bestaande toegangscontrolemodel

We zijn bezig met het opstellen van een zogenaamd “systeempaspoort” op het gebied van toegangscontrole. In wezen is dit een vragenlijst over een specifiek informatiesysteem, dat alle algoritmen registreert om de toegang daartoe te controleren. Bedrijven die al oplossingen van IdM-klasse hebben geïmplementeerd, zijn waarschijnlijk bekend met een dergelijke vragenlijst, aangezien hier het onderzoek naar systemen begint.

Sommige parameters over het systeem en de eigenaren kwamen vanuit het IT-register in de vragenlijst terecht (zie stap 2, audit), maar er zijn ook nieuwe toegevoegd:

• hoe accounts worden beheerd (direct in de database of via software-interfaces);
• hoe gebruikers inloggen op het systeem (met een apart account of met een AD-account, LDAP, etc.);
• welke toegangsniveaus tot het systeem worden gebruikt (applicatieniveau, systeemniveau, systeemgebruik van netwerkbestandsbronnen);
• beschrijving en parameters van de servers waarop het systeem draait;
• welke accountbeheerbewerkingen worden ondersteund (blokkeren, hernoemen, enz.);
• welke algoritmen of regels worden gebruikt om de systeemgebruikersidentificatie te genereren;
• welk attribuut kan worden gebruikt om een ​​koppeling tot stand te brengen met het dossier van een medewerker in het personeelssysteem (volledige naam, personeelsnummer etc.);
• alle mogelijke accountkenmerken en regels voor het invullen ervan;
• welke toegangsrechten bestaan ​​er in het systeem (rollen, groepen, atomaire rechten, etc., zijn er geneste of hiërarchische rechten);
• mechanismen voor het verdelen van toegangsrechten (per positie, afdeling, functionaliteit, enz.);
• Beschikt het systeem over regels voor de scheiding van rechten (SOD – Segregation of Duties), en hoe werken deze?
• hoe gebeurtenissen van verzuim, overplaatsing, ontslag, bijwerken van personeelsgegevens etc. in het systeem worden verwerkt.

Deze lijst kan worden voortgezet, waarbij de verschillende parameters en andere objecten worden beschreven die betrokken zijn bij het toegangscontroleproces.

Stap 5. Maak een bedrijfsgerichte beschrijving van rechten

Een ander document dat we nodig zullen hebben bij het bouwen van een rolmodel is een naslagwerk over alle mogelijke bevoegdheden (rechten) die aan gebruikers in het informatiesysteem kunnen worden verleend, met een gedetailleerde beschrijving van de bedrijfsfunctie die erachter staat. Vaak zijn autoriteiten in het systeem gecodeerd met bepaalde namen die uit letters en cijfers bestaan, en kunnen medewerkers van het bedrijf niet achterhalen wat er achter deze symbolen schuilgaat. Dan gaan ze naar de IT-dienst, en daar... kunnen ze ook de vraag over bijvoorbeeld zelden gebruikte rechten niet beantwoorden. Dan moeten er aanvullende tests worden gedaan.

Het is goed als er al een bedrijfsbeschrijving is of zelfs als er een combinatie van deze rechten in groepen en rollen is. Voor sommige toepassingen is het het beste om een ​​dergelijke referentie al in de ontwikkelingsfase te creëren. Maar dit gebeurt niet vaak, dus gaan we opnieuw naar de IT-afdeling om informatie te verzamelen over alle mogelijke rechten en deze te beschrijven. Onze gids zal uiteindelijk het volgende bevatten:

• naam van de autoriteit, inclusief het object waarvoor het toegangsrecht geldt;
• een handeling die met een object mag worden uitgevoerd (bekijken, wijzigen, etc., de mogelijkheid van beperking, bijvoorbeeld per territoriale basis of per groep klanten);
• autorisatiecode (code en naam van de systeemfunctie/aanvraag die met behulp van de autorisatie kan worden uitgevoerd);
• beschrijving van de autoriteit (gedetailleerde beschrijving van acties in de IS bij het toepassen van de autoriteit en de gevolgen daarvan voor het proces;
• toestemmingsstatus: “Actief” (als de toestemming aan ten minste één gebruiker is toegewezen) of “Niet actief” (als de toestemming niet wordt gebruikt).

Stap 6 Wij downloaden gegevens over gebruikers en rechten uit de systemen en vergelijken deze met de personeelsbron

In de laatste voorbereidingsfase moet u gegevens downloaden uit informatiesystemen over alle gebruikers en de rechten die zij momenteel hebben. Er zijn hier twee mogelijke scenario's. Ten eerste: de beveiligingsafdeling heeft directe toegang tot het systeem en beschikt over de middelen om relevante rapporten te downloaden, wat niet vaak gebeurt, maar wel erg handig is. Ten tweede: we sturen een verzoek naar IT om rapporten in het vereiste formaat te ontvangen. De ervaring leert dat het niet mogelijk is om met IT tot overeenstemming te komen en de benodigde gegevens in één keer te verkrijgen. Er moeten verschillende benaderingen worden gevolgd totdat de informatie in de gewenste vorm en formaat wordt ontvangen.

Welke gegevens moeten worden gedownload:

• Accountnaam
• Volledige naam van de medewerker aan wie het is toegewezen
• Status (actief of geblokkeerd)
• Aanmaakdatum van account
• Datum van laatste gebruik
• Lijst met beschikbare rechten/groepen/rollen

We ontvingen dus downloads van het systeem met alle gebruikers en alle rechten die aan hen waren verleend. En ze hebben onmiddellijk alle geblokkeerde accounts opzij gezet, omdat het werk aan het bouwen van een rolmodel alleen voor actieve gebruikers zal worden uitgevoerd.

Als uw bedrijf vervolgens niet over geautomatiseerde middelen beschikt om de toegang tot ontslagen werknemers te blokkeren (dit gebeurt vaak) of over een patchwork-automatisering beschikt die niet altijd correct werkt, moet u alle ‘dode zielen’ identificeren. We hebben het over de accounts van werknemers die al zijn ontslagen en wier rechten om de een of andere reden niet zijn geblokkeerd - ze moeten worden geblokkeerd. Om dit te doen, vergelijken we de geüploade gegevens met de personeelsbron. Ook het lossen van personeel moet vooraf worden aangevraagd bij de afdeling die de personeelsdatabase beheert.

Afzonderlijk is het noodzakelijk om accounts opzij te zetten waarvan de eigenaren niet in de personeelsdatabase zijn gevonden, die aan niemand zijn toegewezen - dat wil zeggen zonder eigenaar. Aan de hand van deze lijst hebben we de datum van het laatste gebruik nodig: als deze vrij recent is, zullen we nog op zoek moeten gaan naar de eigenaren. Dit kunnen accounts zijn van externe contractanten of serviceaccounts die aan niemand zijn toegewezen, maar wel aan processen zijn gekoppeld. Om erachter te komen van wie de rekeningen zijn, kunt u brieven sturen naar alle afdelingen met de vraag om te reageren. Wanneer de eigenaren worden gevonden, voeren we gegevens over hen in het systeem in: op deze manier worden alle actieve accounts geïdentificeerd en de rest wordt geblokkeerd.

Zodra onze uploads zijn ontdaan van onnodige gegevens en alleen actieve accounts overblijven, kunnen we beginnen met het bouwen van een rolmodel voor een specifiek informatiesysteem. Maar hierover zal ik je in het volgende artikel vertellen.

Auteur: Ljoedmila Sevastyanova, promotiemanager Solar inRights

Bron: www.habr.com