Praegu töötan ma tarkvaratoote tootja juures, spetsialiseerudes juurdepääsu haldamise lahendustele. Minu varasem kogemus tuli tellija poolelt – suurest finantsasutusest. Toona ei saanud meie turbejuurdepääsu meeskond uhkeldada suure kompetentsiga IdM-i alal. Me õppisime palju protsessi käigus ja pidime palju vigu tegema, et ettevõttes välja töötada tõhus kasutajate õiguste haldamise mehhanism infotehnoloogilistes süsteemides.
Samas ühendades oma tellija poolelt saadud väärtusliku kogemuse tootja teadmiste ja oskustega, tahan jagada teiega praktilist, samm-sammult juhendit: kuidas luua suures ettevõttes rollipõhine juurdepääsu haldamise mudel ja mida see lõpuks toob. Minu juhend koosneb kahest osast: esimene – valmistume mudeli loomiseks, teine – loome ise mudeli. Teie ees on esimene, ettevalmistav osa.
N.B. Rollimudeli loomine on kahjuks mitte lõpptulemus, vaid protsess. Täpsemalt on see isegi osa protsessist, mille käigus teie ettevõttes luuakse ligipääsu haldamise ökosüsteem. Seega valmistuge pika mängu jaoks.
Alustame selgusest – mis siis on rollipõhine ligipääsu haldamine? Oletame, et teil on suur pank, kus töötab kümneid tuhandeid, isegi sadu tuhandeid töötajaid (subjekte), kellel on kümneid ligipääsuõigusi sadu sisepanganduse infosüsteemide (objektide) jaoks. Ja nüüd korrutage objektide arv subjektide arvuga – just nii palju seoseid peate alguses looma ja seejärel kontrollima. Kas on võimalik seda käsitsi teha? Loomulikult mitte – just selle ülesande lahendamiseks loodi rollid.
Roll on määratletud õiguste kogum, mis on vajalik kasutajale või kasutajate grupile teatud tööülesannete täitmiseks. Igal töötajal võib olla üks või mitu rolli, ning iga roll võib sisaldada ühte või mitmeid õigusi, mis on kasutajale antud selle rolli raames. Rollid võivad olla seotud kindlate ametikohtade, osakondade või töötajate funktsionaalsete ülesannetega.
Rollid luuakse tavaliselt töötaja eraldi volitustest igas teabe süsteemis. Seejärel moodustatakse igas süsteemis olemasolevatest rollidest globaalsed ärirollid. Näiteks äriroll 'krediidihaldur' hõlmab endas mitmeid eraldi rolle teabe süsteemides, mida kasutatakse panga kliendibüroos. Oletame, et sellistes süsteemides nagu põhiautomaatne pangandussüsteem, kassamoodul, elektroonilise dokumendihaldussüsteem, teenusehaldur ja teised. Ärivõrke seostatakse tavaliselt organisatsioonilis-struktuurse ülesehitusega – lihtsamalt öeldes, ettevõtte osakondade ja ametikohtade kogumiga. Nii moodustatakse globaalne rollide maatriks (näidatakse tabelis allpool).
Oluline on märkida, et 100% rollimudeli loomine, andes iga ametikoha töötajatele kõik vajalikud õigused kommertsstruktuuris, on lihtsalt võimatu. Ja see pole ka vajalik. Rollimudel ei saa olla staatiline, kuna see sõltub pidevalt muutuvas keskkonnas. Samuti sõltub see ettevõtte äritegevuse muutumisest, mis omakorda mõjutab organisatsiooni struktuuri ja funktsionaalsust. Ning sellest, et ressursse ei pruugita täielikult tagada, et tööülesandeid ei järgita, et püütakse kasumit teenida ohutuse arvelt ja paljusid muid tegureid. Seepärast tuleb luua rollimudel, mis suudab katta kuni 80% kasutajate vajadustest nende ametikohta määramisel vajalike põhioigustega. Ja ülejäänud 20% saavad nad vajadusel hiljem eraldi taotluste kaudu küsida.
Muidugi, võite küsida: „Kas 100% rollimudeleid üldse ei eksisteeri?“ Muidugi, selliseid kohtab näiteks mittetulundusühingutes, mis ei ole pidevatele muutustele alluvad, nagu näiteks teadus- ja arendusasutustes. Või ka kaitsetööstuse organisatsioonides, kus kõrge turvalisuse tase on prioriteet. On ka juhtumeid, kus see toimub ka kommertsstruktuurides, kuid ainult konkreetse osakonna raames, mille töö on piisavalt staatiline ja ettearvatav protsess.
Peamine eelis rollihalduses on õiguste väljastamise lihtsustamine, kuna rollide arvu on oluliselt vähem kui infotehnoloogia süsteemi kasutajate arvu. Ja see kehtib iga valdkonna kohta.
Võtame näiteks jaekaubanduse ettevõtte: seal töötab tuhandeid müüjaid, kuid süsteemis N on neil kõikidel samad õigused ja neile luuakse vaid üks roll. Kui ettevõttesse tuleb uus müüja, määratakse talle automaatselt vajalik roll, millel on juba olemas kõik vajalikud volitused. Samuti saab ühe kliki abil muuta õigusi tuhandete müüjate jaoks, näiteks lisada uus aruandlusvõimalus. Ei ole vaja teha tuhandeid toiminguid, sidudes uue õiguse iga kasutajakontoga – piisab, kui lisada see võimalus rolli, ja see ilmub kõigile müüjatele samal ajal.
Veel üks rullimise haldamise eelis on kokkusobimatute volituste väljastamise välistamine. See tähendab, et töötaja, kellel on süsteemis teatud roll, ei saa samal ajal omada teist rolli, mille õigused ei tohiks olla kooskõlas esimese õigustega. Hea näide on keeld ühendada rahavoogude sisestamise ja kontrollimise funktsioone.
Kõik, keda huvitab, kuidas rullimise õiguse haldamine üldiselt tekkis, võivad
sukelduda ajalukku
Ajaloo vaatamine näitab, et IT-kogukond mõtles juurdepääsuhalduse meetoditele esmakordselt juba XX sajandi 70. aastatel. Kuigi rakendused olid siis üsna lihtsad, soovis kõigile mugavalt juurdepääsu nendele hallata. Kasutajate õiguste andmine, muutmine ja kontrollimine oli vajalik, et lihtsustada arusaamist, millised on igaühe juurdepääsuvõimalused. Kuid sel ajal puudusid üldised standardid, töötati välja esimesed juurdepääsuhaldussüsteemid ning iga ettevõte juhindus oma isiklikest arusaamadest ja reeglitest.
Tänaseks on teada palju erinevaid juurdepääsuhalduse mudeleid, kuid need ei tekkisid kohe. Peatume nende mudelite peal, mis on märkimisväärselt panustanud selle valdkonna arengusse.
Esimene ja võib-olla kõige lihtsam mudel on Dikreetne (valikuline) juurdepääsuhaldus (DAC – Discretionary access control). See mudel tähendab, et juurdepääsu õiguste jagamine toimub kõigi osalejate vahel. Igal kasutajal on juurdepääs teatud objektidele või toimingutele. Sisuliselt vastab siin paljude õiguste subjektide hulk paljudele objektidele. See mudel on tunnustatud liiga paindlikuks ja liiga keeruliseks haldamiseks: juurdepääsu loendid muutuvad aja jooksul tohutuks ja neid on raske kontrollida.
Teine mudel on Mandaatne juurdepääsuhaldus (MAC – Mandatory access control). Selle mudeli kohaselt saab iga kasutaja juurdepääsu objektile vastavalt kehtestatud litsentsile teatud tasemele konfidentsiaalsusandmete osas. Vastavalt sellele peavad objektid olema kategoriseeritud vastavalt konfidentsiaalsuse tasemele. Erinevalt esimesest paindlikust mudelist osutus see aga liiga rangeks ja piiravaks. Selle rakendamine ei õigusta end, kui ettevõttes on mitmekesised teabeallikad: juurdepääsu piirmiseks erinevatele allikatele tuleb kehtestada lugematul hulgal kategooriaid, mis omavahel ei kohtu.
Kuna nende kahe meetodi ilmsetest puudustest jätkas IT kogukond mudelite loomist, mis oleksid paindlikumad ja enam-vähem universaalsed, et toetada erinevaid organisatsioonilise juurdepääsu kontrolli poliitikas. Just siis tekkis kolmas rollipõhine juurdepääsu haldamise mudel! See lähenemine osutus kõige tõhusamaks, kuna see nõuab mitte ainult kasutaja isiksuse autoriseerimist, vaid ka tema tööhõivet süsteemides.
Esimese selgelt kirjeldatud rollimudeli struktuuri pakkusid Ameerika teadlased David Ferraiolo ja Richard Kuhn USA Riiklikust Standardite ja Tehnoloogia Instituudist 1992. aastal. Siis ilmus esmakordselt mõisted RBAC (rollipõhine juurdepääsu haldamine). Need uuringud ja peamiste komponentide kirjeldused koos nende omavaheliste seostega olid INCITS 359-2012 kehtiva standardi aluseks, mille on heaks kiitnud Rahvusvaheline Infotehnoloogia Standardite Komitee (INCITS).
Standard määratleb rolli kui "ametikohta organisatsiooni kontekstis, millel on seotud semantika volituste ja vastutuse osas, mis on määratud kasutajale, kellele roll antakse". Dokumendis määratletakse RBAC põhielemendid – kasutajad, seansid, rollid, load, toimingud ja objektid, samuti nendevahelised suhted ja seosed.
Standardis on esitatud minimaalne vajalik struktuur rollimudeli loomiseks – õiguste koondamine rollidesse ja seejärel juurdepääsu andmine kasutajatele läbi nende rollide. Määratletud on mehhanismid rollide koostamiseks objektidest ja toimingutest, kirjeldatakse rollide hierarhiat ja volituste pärimist. Igas ettevõttes on rollid, mis ühendavad elementaarseid volitusi, mis on vajalikud kõikidele ettevõtte töötajatele. See võib olla juurdepääs e-posti, dokumentide haldamise süsteemi, ettevõtte portaalile jne. Need volitused võib koondada ühe üldise rolli alla nimega "töötaja", ja ei ole vaja iga kõrgeimal tasemel rollis iga kord loetleda kõiki elementaarseid õigusi. Piisab sellest, kui märkida rolli "töötaja" pärimise tunnus.
Hiljem täiendati standardit uute juurdepääsu atribuutidega, mis on seotud pidevalt muutuva keskkonnaga. Üks võimalus on staatiliste ja dünaamiliste piirangute rakendamine. Staatilised piirangud tähendab rollide kumulatsiooni vältimist (sama sissejuhatus ja operatsioonide kontroll, millest varem räägiti). Dünaamilised piirangud võivad sõltuda muutuvatest parameetritest, näiteks ajast (töö-/vabaaja või -päevad), asukohast (kontor/kodu) jne.
Erakordselt tasub rääkida atribuutide põhjal põhinevast juurdepääsu haldusest (ABAC — Attribute-based access control). Lähenemine põhineb juurdepääsu andmisel atribuutide jagamise reeglite kaudu. Seda mudelit saab kasutada iseseisvalt, kuid tihti täiendab see klassikalist rollimudelit: teatud rollile saab lisada kasutajate, ressursside ja seadmete atribuute, samuti aega või asukohta. See võimaldab vähendada rollide arvu, kehtestada täiendavaid piiranguid ja teha juurdepääsu minimaalseteks, seega tõsta turvalisust.
Näiteks võib raamatupidajale lubada juurdepääsu kontodele, kui ta töötab teatud piirkonnas. Sel juhul võrreldakse spetsialisti asukohta teatud standardväärtusega. Või võib juurdepääsu anda kontodele ainult siis, kui kasutaja logib sisse seadmel, mis on kantud lubatud seadmete registrisse. Hea täiendus rollimudelile, kuid seda kasutatakse iseseisvalt harva, kuna on vajalik luua palju reegleid ja lubade või piirangute tabeleid.
Toon näide ABAC rakendamisest oma "eelmises elus". Meie pangas oli mitu filiaali. Klientide kontorite töötajad nendes filiaalides tegid täiesti identsed toimingud, kuid nad pidid töötama põhissüsteemis ainult oma regiooni kontodega. Alguses hakkasime looma eraldi rolle igas piirkonnas – ja selliseid rolle, millel oli korduv funktsionaalsus, kuid juurdepääs erinevatele kontodele, sai väga palju! Siis, kasutades kasutaja asukoha atribuuti ja seostades selle konkreetse konto vahemikuga kontrollimiseks, vähendasime süsteemis oluliselt rollide arvu. Tulemuseks jäid alles rollid ainult ühe filiaali jaoks, mis duplitseeriti vastavatele ametikohtadele kõigis ülejäänud pangas asuvates territoriaalsetes üksustes.
Nüüd räägime vajalikest ettevalmistusmeetmetest, ilma milleta lihtsalt ei saa üles ehitada toimivat rollimudelit.
Samm 1. Loome funktsionaalse mudeli
Alustuseks tuleks luua funktsionaalne mudel – ülevaatlik dokument, kus on detailselt kirjas iga sektori ja iga ametikoha funktsioonid. Tüüpiliselt kogutakse teave sellest erinevatest dokumentidest: ametijuhenditest ja reeglitest, mis käsitlevad vastavaid osi – osakondi, juhtimisi, departemente. Funktsionaalne mudel peab olema kooskõlastatud kõigi sidusrühmadega (äri, sisekontroll, turvalisus) ja kinnitatud ettevõtte juhtkonna poolt. Miks on see dokument vajalik? Selleks, et rollimudel saaks sellele viidata. Näiteks, kui kavatsete koostada rollimudeli juba olemasolevate töötajate õiguste põhjal – mis on välja antud süsteemist ja „ühtlustatud“. Seejärel, kui lepitate kokku saadud rolle süsteemi äriomanikuga, saab viidata konkreetsele punktile funktsionaalses mudelis, mille alusel hõlmatakse rolli teatud õigus.
Samm 2. Auditeerime IT-süsteeme ja koostame prioriseerimise plaani
Teises etapis tuleb läbi viia IT-süsteemide auditeerimine, et mõista, kuidas nendele juurdepääs on korraldatud. Näiteks minu finantsettevõttes oli kasutuses mitu sada infotehnoloogiat. Kõikides süsteemides olid mingid rühmad, enamasti paberil või süsteemi soovitusel, mis olid juba ammu aegunud, ning juurdepääsu anti välja vastavalt kasutajate tegelikele taotlustele. Loomulikult on võimatu kohe välja töötada rollimudelit mitmesajale süsteemile – tuleb alustada kusagilt. Me viisime läbi süvaanalüüsi juurdepääsuhalduse protsessi kohta, et määrata selle küpsuse tase. Analüüsi käigus välja töötatud kriteeriumide alusel prioritiseeriti infotehnoloogiaid – kriitilisus, valmidus, plaanid väljaarvamiseks jne. Nende abil koostasime järjestuse rollimudelite arendamiseks/uuendamiseks nende süsteemide jaoks. Ja seejärel kaasasime rollimudelid identiteedihalduse lahendusega integreerimise plaani, et automatiseerida juurdepääsuhaldust.
Nii kuidas määrata süsteemi kriitilisust? Vastake endale järgmistele küsimustele:
- Kas süsteem on seotud operatsiooniprotsessidega, mille täitmine on ettevõtte põhitegevuseks?
- Kas süsteemi talitlushäire mõjutab ettevõtte varade terviklikkust?
- Milline on maksimaalne lubatud süsteemi seisaku aeg, mille saavutamisel ei ole võimalik tegevust taastada pärast katkestust?
- Kas süsteemi teabele kehtivate piirangute rikkumine võib põhjustada pöördumatuid tagajärgi, nii rahalisi kui ka mainekaotust?
- Pettuse kriitilisus. Funktsionaalsuse olemasolu, mille puhul kontrolle on ebapiisavalt, on võimalik korraldada sise- või välispettusi;
- Millised on seadusandluse nõuded ning sisereeglid ja -protseduurid nende süsteemide suhtes? Kas regulatiivsetelt organitelt on karistusi mittejärgimise eest?
Oma finantsfirma raames viisime auditi läbi järgmiselt. Juhtkond töötas välja Access Right Review auditi protseduuri, et selgitada välja olemasolevate kasutajate ja õiguste olukord kõigepealt tähtsaimates infotehnoloogiasüsteemides. Selle protsessi omanikuks määrati turbeosakond. Kuid täieliku ülevaate saamiseks ettevõtte õigustest oli vajalik kaasata protsessis IT- ja äriosakonnad. Siin algasid vaidlused, arusaamatused ja mõnikord isegi sabotaaž: keegi ei taha lahkuda oma praegustest kohustustest ja laskuda mingitesse esmapilgul segastesse tegevustesse.
N.B. Suured ettevõtted, kelle IT-protsessid on hästi välja arendatud, tunnevad kindlasti IT-auditi protseduuri - IT general controls (ITGC), mis võimaldab tuvastada puudusi IT-protsessides ja kehtestada kontrolli, et parandada protsesse vastavalt parimatele praktikatele (ITIL, COBIT, IT Governance jne). Selline audit aitab IT-l ja ääril üksteist paremini mõista ning arendada ühist arengustrateegiat, analüüsida riske, optimeerida kulusid ja välja töötada tõhusamad töömeetodid.
Auditi suund on määrata loogiliste ja füüsiliste juurdepääsuteave infosüsteemidele. Saadud andmeid oleme kasutanud rollimudeli loomisel. Selle auditi tulemusena koostasime IT-süsteemide registri, kus määrati nende tehnilised parameetrid ja antakse kirjeldused. Iga süsteemi jaoks määrati ka ärisuuna omanik, kelle huvides süsteem töötas: just tema vastutas selle järgi teenindatavate äriprotsesside eest. Samuti määrati IT-teenuse juht, kes vastutas konkreetse infosüsteemi tehniliste vajaduste täitmise eest. Dokumenteerisime ettevõtte jaoks kõige kriitilisemad süsteemid ja nende tehnilised parameetrid, kasutuselevõtu ja väljalaske tähtajad jne. Need parameetrid aitasid väga rollimudeli ettevalmistamise protsessis.
Samm 3 Loome metoodika
Iga ettevõtte edu saladus peitub õigesti valitud meetodis. Seetõttu peame, nii rollimudeli loomisel kui ka auditi läbiviimisel, välja töötama metoodika, kus kirjeldame osakondadevahelist koostööd, kinnitame vastutuse ettevõtte eeskirjades jne.
Esmalt tuleb uurida kõiki olemasolevaid dokumente, mis määratlevad juurdepääsu ja õiguste andmise korra. Protsessid peaksid olema dokumenteeritud mitmel tasandil:
- üldised ettevõtte nõuded;
- infoturbealased nõuded (sõltuvalt organisatsiooni tegevusvaldkondadest);
- tehnoloogiliste protsesside nõuded (juhised, ligipääsude matriibid, metoodilised juhised, konfiguratsiooninõuded).
Oma finantsettevõttes avastasime palju vananenud dokumente - need tuli sobitada sisse viidavate uute protsessidega.
Juhi juhtkonna korraldusel loodi töögrupp, kuhu kuulusid esindajad turvalisuse, IT, äri ja sise kontrolli valdkondadest. Käskkonnas määratleti rühma loomise eesmärgid, tegevussuunad, eksisteerimise tähtaeg ja vastutavad isikud iga osapoole kohta. Lisaks töötasime välja auditeerimise metoodika ja rollimudeli loomise korra: need leppisid kokku kõik vastutavad esindajad valdkondadest ning kinnitas ettevõtte juhtkond.
Dokumendid, mis kirjeldavad tööde teostamise korda, tähtaegu, vastutust jne – on garantii, et tee tõelise eesmärgini, mis alguses ei pruugi kõigile selge olla, ei tekita kellelegi küsimusi "miks me seda teeme, miks me seda vajame jne" ja ei anna võimalust "taganeda" või protsessi peatada.
Step 4. Fikseerime olemasoleva juurdepääsuhaldusmudeli parameetrid
Koostame nn niinimetatud „süsteemi passi“ juurdepääsu haldamise osas. Tegelikult on see konkreetse infotehnoloogia süsteemi küsitlus, kus on fikseeritud kõik juurdepääsu haldamise algoritmid. Ettevõtted, kes on juba rakendanud IdM klassi lahendusi, teavad kindlasti sarnast küsitlust, kuna sellelt algab süsteemide uurimine.
Osad süsteemi ja omanike parameetrid kanti küsitlusele IT-register, kuid lisandusid ka uued:
- kuidas hallatakse kasutajakontosid (otse andmebaasis või läbi programmiliideste);
- kuidas kasutajad siseneb süsteemi (kas eraldi kontoga või AD, LDAP või muude kontode kaudu);
- millised juurdepääsutasemed süsteemis kasutatakse (rakendustasand, süsteemitase, võrgu failide ressursside kasutamine);
- süsteemi töötamise kirjeldus ja parameetrid, serveritemillel süsteem põhineb;
- milliseid kasutajakontode haldamise operatsioone toetatakse (blokeerimine, ümbernimetamine jne);
- milliste algoritmide või reeglite alusel luuakse süsteemi kasutaja ID;
- millise atribuudiga saab seostada töötaja kaarti personalisüsteemis (nimi, töötaja number vms);
- kõik võimalikud kasutajakonto atribuudid ja nende täitmise reeglid;
- millised juurdepääsuõigused on süsteemis (rollid, grupid, atomaarne õigused jne, kas on olemas sisemised või hierarhilised õigused);
- juurdepääsu õiguste jagamise mehhanismid (vastavalt ametikohtadele, osakondadele, funktsioonidele jne);
- kas süsteemis on olemas õiguste piiramise reeglid (SOD – Segregation of Duties) ja kuidas need toimivad;
- kuidas süsteem käsitleb puudumist, üleviimist, koondamist, töötajate andmete uuendamist jm;
Seda nimekirja saab jätkata erinevate parameetrite ja muude objektide detailide lisamisega, mis on seotud juurdepääsu haldamise protsessiga.
Samm 5. Loome äri-orienteeritud volituste kirjelduse.
Veel üks dokument, mida vajame rollimudeli loomiseks, on juhend kõikidest võimalikest õigustest, mida saab kasutajatele anda infosüsteemis, koos detailse kirjeldusega äritegevusest, millega see seotud on. Tihti on süsteemis õigused kodeeritud teatud nimetustega, mis koosnevad tähtedest ja numbritest, ning ärikad ei oska nende sümbolite taga peituvat selgitada. Siis pöördutakse IT-osakonna poole, kuid seal… ei osata samuti näiteks harva kasutatavate õiguste osas vastata. Seega on vaja teha täiendavat testimist.
Hea, kui ärikirjeldus on juba olemas või isegi nende õiguste rühmitamine gruppidesse ja rollidesse. Mõnede rakenduste parim praktik on sarnase juhendi loomine juba arendusetapis. Kuid seda juhtub harva, seega läheme taas IT-osakonda, et koguda teavet kõikide võimalike õiguste kohta ja need kirja panna. Meie juhend sisaldab lõppkokkuvõttes järgmist:
- õiguse nimi, sealhulgas objekt, millele juurdepääsuõigus kehtib;
- tegevus, mida on lubatud teostada objekti suhtes (vaatamine, muutmine jt, piirangute võimalus, näiteks territoriaalse alusel või kliendigruppi põhjal);
- volituse kood (süsteemi funktsiooni/taotlemise kood ja nimi, mida saab volituse kasutamisel teostada);
- volituse kirjeldus (üldine kirjeldus toimingutest infosüsteemis volituse kasutamisel ja nende tagajärgedest protsessile;
- volituse seisund: „Aktiivne” (kui volitus on antud vähemalt ühele kasutajale) või „Mitte aktiivne” (kui volitust ei kasutata).
Samm 6 Ekspordime süsteemidest andmed kasutajate ja õiguste kohta ning seome need personaliallikaga.
Lõppfaasi ettevalmistamisel tuleb andmed kasutajate ja nende praeguste õiguste kohta teave, mis on saadud teabelahendustest. Siin on võimalikud kaks stsenaariumi. Esimene: julgeolekuteenistusel on juurdepääs süsteemile otse ja neil on vahendid vastavate aruannete eksportimiseks, mis on haruldane, kuid väga mugav. Teine: saadame IT-le taotluse vajalike aruannete saamiseks vajalikus vormingus. Praktika näitab: IT-ga kokkuleppimine ja vajalike andmete saamine esimesel katsel ei õnnestu. On vaja teha mitu lähenemist, enne kui teave saadakse soovitud kujul ja formaadis.
Milliseid andmeid tuleb eksportida:
- Kasutajakonto nimetus
- Töötaja rikkaliku nimega, kellele see on määratud
- Olek (aktiivne või blokeeritud)
- Kasutajakonto loomise kuupäev
- Viimase kasutamise kuupäev
- Saadavate õiguste/rühmade/rollide nimekiri
Nii, nüüd oleme saanud süsteemist eksporti kõigi kasutajate ja neile antud õigustega. Ja kohe panime kõik blokeeritud kontod kõrvale, kuna rollemudeli koostamise töö toimub ainult aktiivsete kasutajate osas.
Kui teie ettevõttes pole automatiseeritud tööriistu töötajate ligipääsu sulgemiseks (see on üsna tavaline) või on kasutusel killustatud automatiseerimine, mis ei toimi alati õigesti, tuleb tuvastada kõik "surmad hinged". Räägime siin juba lahkunud töötajate kontodest, mille õigusi mingil põhjusel ei ole peatatud – need tuleb blokeerida. Selleks võrreldakse eksportitud andmeid personaliallikaga. Personalihalduse eksport tuleb eelnevalt saada osakonnalt, kes haldab personaliandmeid.
Eraldi tuleb eraldada kontod, mille omanikud ei leitud personali andmebaasist, mis ei ole kellelegi seotud, – st hüljatud. Selle nimekirja jaoks on meile vajalik viimane kasutamise kuupäev: kui see on üsna värske, tuleb ikkagi omanikke otsida. Siia võivad kuuluda välistöötajate kontod või ametlikud kontod, mis ei ole kellegagi seotud, kuid on seotud mõne protsessiga. Konto kuuluvuse selgitamiseks võib saata kõigile osakondadele kirjad palvega reageerida. Kui omanikud leitakse, sisestame nende andmed süsteemi: sel moel on kõik aktiivsed kontod tuvastatud ja ülejäänud blokeerime.
Niipea kui meie eksport on puhastatud liigsetest kirjedest ja jäänud on vaid aktiivsed kontod, saab alustada rollimudeli koostamist konkreetse infosisüsteemi jaoks. Kuid sellest räägin juba järgmises artiklis.
Autor: Lyudmila Sevastyanova, Solar inRightsi turundusjuht
Allikas: habr.com
