Nou werk ek vir 'n sagteware verskaffer maatskappy, in die besonder toegang beheer oplossings. En my ervaring "uit 'n vorige lewe" hou verband met die kliëntekant - 'n groot finansiële instelling. Op daardie stadium kon ons toegangsbeheergroep in die inligtingsekuriteitsafdeling nie spog met groot bevoegdhede in IdM nie. Ons het baie geleer in die proses, ons moes 'n klomp bulte vul om 'n werkende meganisme vir die bestuur van gebruikersregte in inligtingstelsels in die maatskappy te bou.
Deur my ervaring opgedoen in die kliënt te kombineer met verskafferskennis en -bevoegdhede, wil ek in wese 'n stap-vir-stap instruksie met jou deel: hoe om 'n rolgebaseerde toegangsbeheermodel in 'n groot maatskappy te skep, en wat dit sal gee in die einde. My instruksie bestaan uit twee dele: die eerste - ons berei voor om 'n model te bou, die tweede - ons bou dit eintlik. Voor jy deel een, voorbereidend.
NB Die bou van 'n rolmodel is ongelukkig nie 'n resultaat nie, maar 'n proses. Of eerder, selfs deel van die proses om 'n toegangsbeheer-ekosisteem in die maatskappy te skep. Skakel dus lankal in op die speletjie.
Eerstens, laat ons definieer - wat is rolgebaseerde toegangsbeheer? Gestel jy het 'n groot bank met tien of selfs honderdduisende werknemers (onderwerpe), wat elkeen dosyne toegangsregte tot honderde intra-bank inligtingstelsels (objekte) het. En vermenigvuldig nou die aantal voorwerpe met die aantal vakke - dit is hoeveel verbindings jy ten minste eers moet bou, en dan beheer. Is dit regtig moontlik om dit met die hand te doen? Natuurlik nie - rolle het verskyn om hierdie probleem op te los.
'n Rol is 'n stel toestemmings wat 'n gebruiker of groep gebruikers nodig het om sekere werktake uit te voer. Elke werknemer kan een of meer rolle hê, en elke rol kan een tot baie toestemmings bevat wat aan 'n gebruiker binne daardie rol toegelaat word. Rolle kan gekoppel word aan sekere posisies, departemente of funksionele take van werknemers.
Rolle word gewoonlik geskep uit individuele werknemermagtigings in elke inligtingstelsel. Dan word globale besigheidsrolle gevorm uit die rolle van elke stelsel. Byvoorbeeld, die besigheidsrol "leningsbestuurder" sal verskeie afsonderlike rolle insluit in inligtingstelsels wat in die bank se kliëntekantoor gebruik word. Byvoorbeeld, in soos die hoof outomatiese bankstelsel, kasregister, elektroniese dokumentbestuurstelsel, diensbestuurder en ander. Besigheidsrolle is as 'n reël gekoppel aan die organisasiestruktuur - met ander woorde, aan 'n stel maatskappydepartemente en posisies daarin. Dit is hoe die globale rolmatriks gevorm word (ek gee 'n voorbeeld in die tabel hieronder).
Dit is opmerklik dat dit eenvoudig onmoontlik is om 'n 100% rolmodel te bou, wat al die nodige regte verskaf aan werknemers van elke pos in 'n kommersiële struktuur. Ja, dit is nie nodig nie. Die rolmodel kan immers nie staties wees nie, want dit hang af van die voortdurend veranderende omgewing. En van 'n verandering in die maatskappy se besigheidsaktiwiteite, wat dienooreenkomstig die verandering in die organisatoriese struktuur en funksionaliteit beïnvloed. En van die gebrek aan volle voorsiening van hulpbronne, en van nie-nakoming van posbeskrywings, en van die begeerte na wins ten koste van sekuriteit, en van baie ander faktore. Daarom is dit nodig om ’n rolmodel te bou wat tot 80% van gebruikers se behoeftes vir die nodige basiese regte kan dek wanneer hulle in ’n pos aangestel word. En die oorblywende 20% sal hulle, indien nodig, later op aparte aansoeke kan ondervra.
Natuurlik kan jy vra: "Wat, daar is glad nie 100% rolmodelle nie?" Wel, hoekom, dit gebeur byvoorbeeld in nie-winsgewende strukture wat nie onderhewig is aan gereelde veranderinge nie - in een of ander navorsingsinstituut. Of in militêre-industriële komplekse organisasies met 'n hoë vlak van sekuriteit, waar sekuriteit eerste kom. Dit gebeur, en in 'n kommersiële struktuur, maar binne die raamwerk van 'n enkele eenheid, waarvan die werk 'n redelik statiese en voorspelbare proses is.
Die belangrikste voordeel van rolbestuur is die vereenvoudiging van die uitreiking van regte, omdat die aantal rolle aansienlik minder is as die aantal gebruikers van die inligtingstelsel. En dit geld vir enige bedryf.
Kom ons neem 'n kleinhandelmaatskappy: dit het duisende verkoopspersone in diens, maar hulle het dieselfde stel regte in die N-stelsel, en net een rol sal vir hulle geskep word. 'n Nuwe verkoper het na die maatskappy gekom - aan hom is outomaties die nodige rol in die stelsel toegeken, wat reeds al die nodige magte het. U kan ook met een klik die regte vir duisende verkopers gelyktydig verander, byvoorbeeld 'n nuwe opsie byvoeg om 'n verslag te genereer. Jy hoef nie 'n duisend bewerkings te doen, wat 'n nuwe reg aan elke rekening koppel nie - voeg net hierdie opsie by die rol, en dit sal gelyktydig vir alle verkopers verskyn.
Nog 'n voordeel van rolgebaseerde bestuur is die vermyding van onversoenbare toestemmings. Dit wil sê, 'n werknemer wat 'n sekere rol in die stelsel het, kan nie gelyktydig 'n ander rol hê nie, waarvan die regte nie gekombineer moet word met die regte in die eerste een nie. 'n Aanskoulike voorbeeld is die verbod op die kombinasie van die funksies van inset en beheer van 'n finansiële transaksie.
Enigiemand wat belangstel in hoe rolgebaseerde toegangsbeheer in die eerste plek tot stand gekom het, kan
duik in die geskiedenis
As ons na die geskiedenis draai, dan het die IT-gemeenskap vir die eerste keer in die 70's van die XX eeu aan toegangsbeheermetodes gedink. Alhoewel toepassings toe redelik eenvoudig was, maar, soos nou, wou almal regtig toegang daartoe gerieflik bestuur. Gee, verander en beheer gebruikersregte - net om dit makliker te maak om te verstaan watter toegang elkeen van hulle het. Maar in daardie tyd was daar geen gemeenskaplike standaarde nie, die eerste toegangsbeheerstelsels is ontwikkel, en elke maatskappy was op sy eie idees en reëls gebaseer.
Baie verskillende toegangsbeheermodelle is nou bekend, maar hulle het nie dadelik verskyn nie. Laat ons stilstaan by diegene wat 'n tasbare bydrae tot die ontwikkeling van hierdie rigting gemaak het.
Die eerste en waarskynlik die eenvoudigste model is Diskresionêre (Selektiewe) Toegangsbeheer (DAC - Diskresionêre toegangsbeheer). Hierdie model impliseer die deel van regte deur alle deelnemers aan die toegangsproses. Elke gebruiker kry toegang tot spesifieke voorwerpe of bewerkings. Trouens, hier stem die stel subjekte van regte ooreen met die stel objekte. Daar is gevind dat hierdie model te buigsaam en te moeilik is om te onderhou: toegangslyste word groot en moeilik om mettertyd te beheer.
Die tweede model is Verpligte toegangsbeheer (MAC). Volgens hierdie model kry elke gebruiker toegang tot die voorwerp in ooreenstemming met die uitgereikte toegang tot 'n bepaalde vlak van datavertroulikheid. Gevolglik moet voorwerpe volgens die vlak van vertroulikheid gekategoriseer word. Anders as die eerste buigsame model, het hierdie een, inteendeel, te streng en beperkend geblyk te wees. Die gebruik daarvan regverdig homself nie wanneer die maatskappy baie verskillende inligtingsbronne het nie: om toegang tot verskillende hulpbronne te beperk, sal jy baie kategorieë moet instel wat nie sal oorvleuel nie.
As gevolg van die ooglopende onvolmaakthede van hierdie twee metodes, het die IT-gemeenskap voortgegaan om modelle te ontwikkel wat meer buigsaam en terselfdertyd min of meer universeel is om verskillende tipes organisatoriese toegangsbeheerbeleide te ondersteun. En dit is toe dat dit verskyn het die derde model van rolgebaseerde toegangsbeheer! Hierdie benadering blyk die belowendste te wees, aangesien dit nie net magtiging van die gebruiker se identiteit vereis nie, maar ook sy werkfunksies in die stelsels.
Die eerste goed beskryfde rolmodelstruktuur is in 1992 deur Amerikaanse wetenskaplikes David Ferrailo en Richard Kuhn van die Amerikaanse Nasionale Instituut vir Standaarde en Tegnologie voorgestel. Toe het die term eers verskyn RBAC (Rolgebaseerde toegangsbeheer). Hierdie studies en beskrywings van die hoofkomponente, sowel as hul verwantskappe, het die basis gevorm van die INCITS 359-2012-standaard, wat tot vandag toe geldig is, goedgekeur deur die Internasionale Komitee vir Inligtingstegnologiestandaarde (INCITS).
Die standaard definieer 'n rol as "'n werkfunksie in die konteks van 'n organisasie met 'n mate van gepaardgaande semantiek rakende die gesag en verantwoordelikheid wat aan die gebruiker toegeken is wat aan die rol toegewys is". Die dokument vestig die basiese elemente van RBAC - gebruikers, sessies, rolle, toestemmings, bewerkings en voorwerpe, sowel as die verhoudings en verhoudings tussen hulle.
Die standaard verskaf die minimum nodige struktuur vir die bou van 'n rolmodel - kombineer regte in rolle en gee dan toegang aan gebruikers deur hierdie rolle. Die meganismes vir die samestelling van rolle uit objekte en bewerkings word uiteengesit, die hiërargie van rolle en die oorerwing van magte word beskryf. Inderdaad, in enige maatskappy is daar rolle wat elementêre magte kombineer wat nodig is vir alle werknemers van die maatskappy. Dit kan toegang tot e-pos, tot die EDMS, tot die korporatiewe portaal, ens. Hierdie toestemmings kan ingesluit word in een algemene rol genaamd "werknemer", en dit sal nie in elk van die hoërvlakrolle nodig wees om al die elementêre regte oor en oor te lys nie. Dit is genoeg om net die teken van oorerwing van die "werknemer"-rol aan te dui.
Later is die standaard aangevul met nuwe toegangskenmerke wat verband hou met die voortdurend veranderende omgewing. Bygevoeg die vermoë om statiese en dinamiese beperkings in te stel. Statiese impliseer die onmoontlikheid om rolle te kombineer (dieselfde insette en beheer van bedrywighede hierbo genoem). Dinamiese limiete kan gedefinieer word deur parameters soos tyd (werk/nie-werksure of dae), ligging (kantoor/huis) en dies meer te verander.
Afsonderlik moet daar oor gesê word Attribuut-gebaseerde toegangsbeheer (ABAC). Die benadering is gebaseer op die verlening van toegang deur middel van kenmerkdeelreëls. Hierdie model kan afsonderlik gebruik word, maar dit komplementeer dikwels die klassieke rolmodel aktief: jy kan eienskappe van gebruikers, hulpbronne en toestelle, sowel as tyd of ligging by 'n spesifieke rol voeg. Dit laat jou toe om minder rolle te gebruik, bykomende beperkings in te stel en toegang minimaal voldoende te maak, en dus sekuriteit te verhoog.
Byvoorbeeld, 'n rekenmeester kan toegang tot rekeninge toegelaat word as hy in 'n sekere streek werk. Dan sal die ligging van die spesialis met 'n sekere verwysingswaarde vergelyk word. Of jy kan slegs toegang tot rekeninge gee as die gebruiker aanmeld vanaf 'n toestel wat in die register van toegelates ingevoer is. 'n Goeie toevoeging tot die rolmodel, maar word selde op sy eie gebruik as gevolg van die behoefte om baie reëls en tabelle van toestemmings of beperkings te skep.
Ek sal 'n voorbeeld gee van die gebruik van ABAC uit my "vorige lewe". Ons bank het verskeie takke gehad. Werknemers van kliëntekantore in hierdie takke het presies dieselfde bedrywighede uitgevoer, maar moes slegs in die hoofstelsel met rekeninge in hul streek werk. Eerstens het ons afsonderlike rolle vir elke streek begin skep - en daar was so baie sulke rolle met herhalende funksionaliteit, maar met toegang tot verskillende rekeninge! Deur dan 'n liggingkenmerk vir 'n gebruiker te gebruik en dit te koppel aan 'n spesifieke reeks rekeninge om na te gaan, het ons die aantal rolle in die stelsel aansienlik verminder. As gevolg hiervan het rolle vir slegs een tak gebly, wat vir die ooreenstemmende posisies in alle ander territoriale afdelings van die bank herhaal is.
En kom ons praat nou oor die nodige voorbereidende stappe, waarsonder dit eenvoudig onmoontlik is om 'n werkende rolmodel te bou.
Stap 1. Skep 'n funksionele model
Dit is die moeite werd om te begin met die skepping van 'n funksionele model - 'n topvlak dokument wat die funksionaliteit van elke eenheid en elke posisie in detail beskryf. As 'n reël kom inligting uit verskeie dokumente in: posbeskrywings en regulasies vir individuele afdelings - afdelings, departemente, departemente. Die funksionele model moet met alle belanghebbende departemente (besigheid, interne beheer, sekuriteit) ooreengekom en deur die maatskappy se bestuur goedgekeur word. Waarvoor is hierdie dokument? Sodat die rolmodel daarna kan verwys. Jy gaan byvoorbeeld 'n rolmodel bou wat gebaseer is op die bestaande regte van werknemers - afgelaai van die stelsel en "verminder tot 'n gemene deler". Dan, wanneer daar met die besigheidseienaar van die stelsel ooreengekom word oor die ontvangde rolle, kan daar verwys word na 'n spesifieke item van die funksionele model, op grond waarvan hierdie of daardie reg by die rol ingesluit word.
Stap 2. Ons oudit IT-stelsels en stel 'n prioritiseringsplan op
In die tweede stadium moet 'n oudit van IT-stelsels uitgevoer word om te verstaan hoe toegang daartoe georganiseer word. My finansiële maatskappy het byvoorbeeld etlike honderde inligtingstelsels bedryf. In alle stelsels was daar 'n paar beginsels van rolbestuur, in die meeste - sommige rolle, maar meestal op papier of in die stelselgids - is hulle lankal verouderd, en toegang daartoe is op die werklike gebruikerversoeke versprei. Natuurlik is dit eenvoudig onmoontlik om 'n rolmodel in 'n paar honderd stelsels tegelyk te bou, jy moet iewers begin. Ons het 'n in-diepte ontleding van die toegangsbeheerproses gedoen om die vlak van volwassenheid te bepaal. In die proses van ontleding is kriteria vir die prioritisering van inligtingstelsels ontwikkel - kritiek, gereedheid, planne vir uitdiensstelling, ens. Met hulle hulp het ons 'n reeks gebou vir die ontwikkeling / opdatering van rolmodelle vir hierdie stelsels. En dan - ingesluit rolmodelle in die plan vir integrasie met die Identity Management-oplossing om toegangsbeheer te outomatiseer.
So, hoe om die kritiekheid van die stelsel te bepaal? Beantwoord jouself die volgende vrae:
- Is die stelsel gekoppel aan die operasionele prosesse waarvan die maatskappy se kernbesigheid afhanklik is?
- Sal die ontwrigting van die stelsel die integriteit van die maatskappy se bates beïnvloed?
- Wat is die maksimum toelaatbare stilstandtyd van die stelsel, waarna dit onmoontlik is om aktiwiteit na 'n onderbreking te herstel?
- Kan 'n skending van die integriteit van inligting in die stelsel lei tot onomkeerbare gevolge, beide finansieel en reputasie?
- Kritiek teenoor bedrog. Die teenwoordigheid van funksionaliteit, met onvoldoende beheer waarvan dit moontlik is om interne / eksterne bedrieglike aksies uit te voer;
- Wat is die wetlike vereistes, sowel as interne reëls en prosedures vir hierdie stelsels? Sal daar boetes van reguleerders wees vir nie-nakoming?
In ons finansiële maatskappy het ons 'n oudit soos hierdie gedoen. Bestuur het 'n Toegangsreg-oorsig-ouditprosedure ontwikkel om bestaande gebruikers en regte eerste te hanteer op daardie inligtingstelsels wat op die topprioriteitlys is. Die sekuriteitsafdeling is die eienaar van hierdie proses aangewys. Maar om 'n volledige prentjie van die toegangsregte in die maatskappy te kry, was dit nodig om IT- en besigheidsafdelings by die proses te betrek. En hier het dispute, misverstande en soms selfs sabotasie begin: niemand wil wegbreek van hul huidige pligte en betrokke raak by sommige, met die eerste oogopslag, onverstaanbare aktiwiteite nie.
NB Groot maatskappye met ontwikkelde IT-prosesse is waarskynlik vertroud met die IT-ouditprosedure - IT algemene beheermaatreëls (ITGC), wat jou toelaat om tekortkominge in IT-prosesse te identifiseer en beheer te vestig om prosesse te verbeter in ooreenstemming met beste praktyk (ITIL, COBIT, IT) Bestuur, ens.) So 'n oudit laat IT en besigheid toe om mekaar beter te verstaan en 'n gesamentlike ontwikkelingstrategie te ontwikkel, risiko's te ontleed, koste te optimaliseer en meer doeltreffende benaderings tot werk te ontwikkel.
Een van die areas van oudit is om die parameters van logiese en fisiese toegang tot inligtingstelsels te bepaal. Ons het die verkryde data as basis geneem vir verdere gebruik in die bou van 'n rolmodel. As gevolg van so 'n oudit het ons 'n register van IT-stelsels, waarin hul tegniese parameters bepaal is en beskrywings gegee is. Daarbenewens is vir elke stelsel 'n eienaar bepaal vanuit die besigheidsrigting in wie se belange dit bedryf is: dit was hy wat verantwoordelik was vir die besigheidsprosesse wat hierdie stelsel gedien het. 'n IT-diensbestuurder is ook aangestel, verantwoordelik vir die tegniese implementering van besigheidsbehoeftes in 'n spesifieke IS. Die mees kritieke stelsels vir die maatskappy en hul tegniese parameters, ingebruikneming en uitgebruikneming datums, ens.. Hierdie parameters het baie gehelp in die proses van voorbereiding vir die bou van 'n rolmodel.
Stap 3 Skep 'n metodologie
Die sleutel tot die sukses van enige besigheid is die regte metode. Daarom, om 'n rolmodel te bou en om 'n oudit uit te voer, moet ons 'n metodologie skep waarin ons die interaksie tussen departemente sal beskryf, verantwoordelikheid in maatskappyregulasies sal vasstel, ens.
Eerstens moet jy al die beskikbare dokumente ondersoek wat die prosedure vir toegang en regte bepaal. Op 'n goeie manier moet prosesse op verskeie vlakke gedokumenteer word:
- algemene korporatiewe vereistes;
- vereistes vir die gebiede van inligtingsekuriteit (hang af van die aktiwiteite van die organisasie);
- vereistes vir tegnologiese prosesse (instruksies, toegangsmatrikse, riglyne, konfigurasievereistes).
In ons finansiële maatskappy het ons baie verouderde dokumente gevind – ons moes dit in lyn bring met die nuwe prosesse wat ingestel word.
In opdrag van die bestuur is 'n werkgroep geskep wat verteenwoordigers van die gebiede van sekuriteit, IT, besigheid en interne beheer ingesluit het. Die bevel het die doelwitte om die groep te skep, die rigting van aktiwiteit, die bestaanstydperk en die verantwoordelikhede van elke kant uiteengesit. Daarbenewens het ons 'n ouditmetodologie en 'n prosedure ontwikkel om 'n rolmodel te bou: alle verantwoordelike verteenwoordigers van die gebiede het dit ooreengekom en deur die maatskappy se bestuur goedgekeur.
Dokumente wat die prosedure vir die uitvoering van werk beskryf, sperdatums, verantwoordelikhede, ens. - 'n waarborg dat op pad na die gekoesterde doelwit, wat aanvanklik nie vir almal duidelik is nie, niemand vrae sal hê "waarom doen ons dit, hoekom het ons dit nodig, ens. en daar sal geen geleentheid wees om "af te spring" of die proses te vertraag nie.
Stap 4. Regstelling van die parameters van die bestaande toegangsbeheermodel
Ons stel die sogenaamde "stelselpaspoort" op wat toegangsbeheer betref. Trouens, dit is 'n vraelys oor 'n spesifieke inligtingstelsel, waarin alle algoritmes vir die bestuur van toegang daartoe aangeteken word. Maatskappye wat reeds IdM-klasoplossings geïmplementeer het, is waarskynlik vertroud met so 'n vraelys, want dit is daarmee dat die studie van stelsels begin.
Sommige van die parameters oor die stelsel en eienaars het vanaf die IT-register in die vraelys ingevloei (sien stap 2, oudit), maar nuwes is bygevoeg:
- hoe rekeninge bestuur word (direk in die databasis of deur programkoppelvlakke);
- hoe gebruikers by die stelsel aanmeld (met 'n aparte rekening of 'n AD-rekening, LDAP, ens.);
- watter vlakke van toegang tot die stelsel gebruik word (toepassingsvlak, stelselvlak, gebruik van netwerklêerhulpbronne deur die stelsel);
- beskrywing en parameters van die bedieners waarop die stelsel loop;
- watter rekeningbestuurbedrywighede ondersteun word (blokkering, hernoeming, ens.);
- watter algoritmes of reëls gebruik word om die stelselgebruiker-identifiseerder te vorm;
- watter kenmerk gebruik kan word om 'n skakel met 'n rekord oor 'n werknemer in die personeelstelsel te vestig (volle naam, personeelnommer, ens.);
- alle moontlike rekeningeienskappe en reëls vir die invul daarvan;
- watter toegangsregte in die stelsel bestaan (rolle, groepe, atoomregte, ens., is daar geneste of hiërargiese regte);
- meganismes om toegangsregte te skei (volgens posisies, afdelings, funksionaliteit, ens.);
- of die stelsel reëls het vir skeiding van regte (SOD - Segregation of Duties), en hoe dit werk;
- hoe gebeure van afwesigheid, oordrag, ontslag, opdatering van werknemerdata, ens. in die stelsel verwerk word.
Die lys kan aanhou, met besonderhede oor die verskillende parameters en ander entiteite wat by die toegangsbeheerproses betrokke is.
Stap 5: Skep 'n besigheidsgerigte magtigingsbeskrywing
Nog 'n dokument wat ons nodig sal hê wanneer ons 'n rolmodel bou, is 'n gids tot al die moontlike magte (regte) wat in 'n inligtingstelsel aan gebruikers verleen kan word met 'n gedetailleerde beskrywing van die besigheidsfunksie wat daaragter staan. Dikwels word die magte in die stelsel geïnkripteer met sekere name, bestaande uit letters en syfers, en besigheidswerknemers kan nie agterkom wat agter hierdie karakters skuil nie. Dan gaan hulle na die IT-diens, en daar ... kan hulle ook nie die vraag beantwoord byvoorbeeld oor selde gebruikte regte nie. Dan moet jy meer toetse doen.
Dit is goed as daar reeds 'n besigheidsbeskrywing is of selfs al is daar 'n assosiasie van hierdie regte in groepe en rolle. Vir sommige toepassings is die beste praktyk om so 'n gids op die ontwikkelingstadium te skep. Maar dit gebeur nie gereeld nie, so ons gaan weer na die IT-afdeling om inligting oor alle moontlike regte in te samel en dit te beskryf. Ons gids sal uiteindelik die volgende bevat:
- die naam van die owerheid, insluitend die voorwerp waarop die toegangsreg van toepassing is;
- die aksie wat toegelaat word om met die voorwerp gedoen te word (bekyk, verander, ens., die moontlikheid van beperking, byvoorbeeld op 'n territoriale basis of op 'n groep kliënte);
- gesagskode (kode en naam van die stelselfunksie/versoek wat met behulp van die magtiging uitgevoer kan word);
- beskrywing van die owerheid ('n gedetailleerde beskrywing van die optrede in die IS wanneer die gesag toegepas word en die gevolge daarvan vir die proses;
- toestemmingstatus: "Aktief" (as die toestemming aan ten minste een gebruiker toegeken is) of "Nie aktief nie" (indien die toestemming nie gebruik word nie).
Stap 6 Ons laai data oor gebruikers en regte van die stelsels af en vergelyk dit met die personeelbron
Op die finale stadium van voorbereiding moet jy data vanaf inligtingstelsels oplaai oor alle gebruikers en die regte wat hulle tans het. Twee scenario's is hier moontlik. Eerstens het die sekuriteitsafdeling direkte toegang tot die stelsel en het die middele om die relevante verslae af te laai, wat skaars is, maar baie gerieflik. Tweedens: ons stuur 'n versoek aan IT om verslae in die vereiste formaat te ontvang. Praktyk toon dat dit nie moontlik is om met IT te onderhandel en die nodige data die eerste keer te kry nie. Dit is nodig om verskeie benaderings te maak totdat die inligting in die verlangde vorm en formaat ontvang word.
Watter data moet opgelaai word:
- Rekeningnaam
- Naam van die werknemer aan wie dit opgedra is
- Status (aktief of gedeaktiveer)
- Rekening skeppingsdatum
- Laaste gebruik datum
- Lys van beskikbare regte/groepe/rolle
Dus, ons het aflaaie van die stelsel ontvang met alle gebruikers en met al die regte wat aan hulle toegestaan word. En hulle sit dadelik alle geblokkeerde rekeninge opsy, aangesien werk aan die bou van 'n rolmodel slegs vir aktiewe gebruikers uitgevoer sal word.
Dan, as jou maatskappy nie geoutomatiseerde maniere het om toegang vir afgedankte werknemers te sluit nie (dit is nie ongewoon nie) of daar lapwerk-outomatisering is wat nie altyd reg werk nie, moet jy al die "dooie siele" identifiseer. Ons praat van die rekeninge van reeds afgedankte werknemers, wie se regte om een of ander rede nie geblokkeer is nie - dit moet geblokkeer word. Om dit te doen, vergelyk ons die opgelaaide data met die personeelbron. Personeelaflaai moet ook vooraf verkry word by die eenheid wat die personeelbasis lei.
Afsonderlik is dit nodig om rekeninge opsy te sit waarvan die eienaars nie in die personeelbasis gevind is nie, nie aan iemand toegewys is nie - dit wil sê eienaarloos. Vir hierdie lys het ons die datum van die laaste gebruik nodig: as dit redelik onlangs is, moet ons steeds na die eienaars soek. Dit kan rekeninge van eksterne kontrakteurs of diensrekeninge insluit wat aan niemand toegewys is nie, maar met enige prosesse geassosieer word. Om die eienaarskap van die rekening te verduidelik, kan jy briewe aan alle departemente stuur met 'n versoek om te reageer. Wanneer die eienaars gevind word, voer ons data oor hulle in die stelsel in: op hierdie manier word alle aktiewe rekeninge geïdentifiseer, en die res word geblokkeer.
Sodra ons oplaaie van onnodige rekords skoongemaak is en net aktiewe rekeninge oorbly, kan ons begin om 'n rolmodel vir 'n spesifieke inligtingstelsel te bou. Maar ek sal in die volgende artikel hieroor praat.
Skrywer: Lyudmila Sevastyanova, Solar inRights-promosiebestuurder
Bron: will.com