Ehitage rollimudeli juurdepääsu haldamiseks. Osa üks, ettevalmistav

Praegu töötan tarkvaravaldkonna tootja juures, täpsemalt ligipääsu haldamise lahenduste valdkonnas. Minu varasem kogemus on seotud tellija poolega – suure finantsorganisatsiooniga. Toona ei saanud meie infokaitse osakonna ligipääsu kontrolli grupp kiidelda suurte oskustega IdM-is. Me õppisime paljusid asju protsessi käigus ning pidime sisse võtma palju kõva pähe, et ettevõttes luua tõhus kasutajaõiguste haldamise mehhanism teabesüsteemides.

Liites oma tellija poolt saadud kogemuse tootja teadmiste ja oskustega, soovin jagada teiega praktilist samm-sammult juhendit: kuidas luua suures ettevõttes rollipõhine ligipääsu haldamise mudel ja mida see tulemusena toob. Minu juhend koosneb kahest osast: esimeses valmistame ette mudeli ehitamiseks, teises osas ehitame seda mõistetavalt. Teie ees on esimene osa, ettevalmistav.

Märkus. Rollipõhise mudeli loomine on kahjuks mitte tulemus, vaid protsess. Täpsemalt on see osa ettevõtte ligipääsu haldamise ökosüsteemi loomise protsessist. Nii et valmistuge pikaajaliseks mänguks.

Esiteks, määratleme – mis on rollipõhine ligipääsu haldamine? Oletame, et teil on suur pank, kus töötavad kümned või isegi sadade tuhandete töötajate (subjektide) seas, kellel on kümneid ligipääsuõigusi sadu sise-pankade teabesüsteemides (objektid). Nüüd korruta objektide arv subjektide arvuga – just nii palju sidemeid peate esmalt looma ja seejärel kontrollima. Kas on seda võimalik käsitsi teha? Loomulikult mitte – selle ülesande lahendamiseks loodi rollid.

Roll on õ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, kusjuures igal rollil võib olla üks või mitu õigust, mis on antud kasutajale selle rolli piires. Rollid võivad olla seotud teatud ametikohtade, osakondade või töötajate funktsionaalsete ülesannetega.

Rollid luuakse tavaliselt töötaja individuaalsetest õigustest igas infosisystemis. Seejärel koostatakse igas süsteemis olevatest rollidest globaalne ärirulli. Näiteks ärirull "krediidihaldur" sisaldab mitmeid individuaalseid rolle infosisystemites, mida kasutab panga kliendibüroo. Ütleme, et näiteks sellistes süsteemides nagu peamine automatiseeritud pangandussüsteem, kassamoodul, elektroonilise dokumendihalduse süsteem, teenusehaldur ja muud. Ärivõimalused on tavaliselt seotud organisatsiooni struktuuri – lihtsamalt öeldes, ettevõtte osakondade ja ametikohtade komplekti. Nii luuakse globaalne rollide maatriks (näidet toob välja tabel allpool).

Tuleb märkida, et 100% rollimudeli loomine, tagades kõigile kommertstruktuuri ametikohtade töötajatele kõik vajalikke õigusi, on lihtsalt võimatu. Ja see pole ka vajalik. Lõppude lõpuks ei saa rollimudel olla staatiline, sest see sõltub pidevalt muutuvast keskkonnast. Ja ettevõtte äritegevuse muutumisest, mis vastavalt mõjutab organisatsioonistruktuuri ja funktsioone. Ja sellest, et ressursse pole täielikult, ja ametijuhendite mittetäitmisest, ja soovist teenida kasumit ohutuse arvelt ning paljusid teisi tegureid. Seetõttu on vajalik luua rollimudel, mis suudab katta kuni 80% kasutajate vajadustest vajalike põhiteenuste saamiseks ametikoha nimel. Ülejäänud 20% saavad nad vajadusel hiljem eraldi taotlustega küsida.

Muidugi võite küsida: "Kas on siis tõesti olemas 100% rollimudeleid?" Miks mitte, sellised esinevad näiteks mittetulundusühingutes, mis ei puutu sageli muutumisse, – näiteks mõnes teadus- ja arendustegevuses. Või kõrgendatud usaldusväärsusega kaitsetööstuses, kus ohutus on esikohal. On ka juhuseid, kus see esineb ka kommertsinstitutsioonides, kuid kindlas osakonnas, mille töö on piisavalt staatiline ja prognoositav protsess.

Rollihalduse peamine eelis on õiguste määramise lihtsustamine, sest rollide arv on oluliselt väiksem kui infosisestuse kasutajate arv. See kehtib iga tööstusharu kohta.

Võtame kaupluse, kus töötab tuhandeid müüjaid, kuid neil on süsteemis N samad õigused ja neile luuakse vaid üks roll. Kui ettevõttesse tuleb uus müüja, määratakse talle automaatselt vajalik roll süsteemis, kus on juba kõik vajalikud volitused. Ühe klõpsuga saab ka tuhandete müüjate õigusi korraga muuta, näiteks lisada uus valik aruande genereerimiseks. Ei ole vaja teha tuhandet operatsiooni, sidudes uue õiguse iga konto külge – piisab, kui lisada see valik rolli, ja see ilmub kõigile müüjatele korraga.

Veel üks rullide haldamise eelis on kokkusobimatute õiguste väljastamise vältimine. See tähendab, et töötaja, kes omab süsteemis teatud rolli, ei saa samal ajal omada teist rolli, mille õigused ei tohi olla kooskõlas esimese omadega. Selge näide – keelatud on andmete sisestamise ja finantstehingute kontrollimise funktsioonide ühitamine.

Kõik, keda huvitab, kuidas rullide haldus õigupoolest tekkis, võivad
sukelduda ajaloo ekskursiooni
Kui vaadata ajalukku, siis esmakordselt mõtles IT-kogukond juurdepääsu haldamise meetodite üle juba 1970. aastatel. Kuigi rakendused olid siis üsna lihtsad, soovisid kõik mugavalt juurdepääsu nende haldamiseks. Kasutajate õiguste andmine, muutmine ja kontrollimine – parandades arusaamist, milline juurdepääs on igaühel. Kuid sel ajal ei olnud ühtegi üldist standardit, arendati esimesi juurdepääsu haldamise süsteeme ning iga ettevõte põhines omaenda arusaamadel ja reeglitel.

Praeguseks on teada palju erinevaid juurdepääsu haldamise mudeleid, kuid need ei tekkinud kohe. Tähelepanu pöörame neile, mis on andnud olulise panuse selle suuna arengusse.

Esimene ja võib-olla kõige lihtsam mudel – Diskretsiooniline (valikuline) juurdepääsu haldamine (DAC – diskretsiooni juurdepääsu kontroll). See mudel tähendab, et kõik osalised jagavad õigusi juurdepääsuks. Iga kasutaja saab juurdepääsu konkreetsetele objektidele või toimingutele. Sisuliselt vastab siin paljusid õigusi omavad subjektid paljudele objektidele. See mudel on osutunud liiga paindlikuks ja keeruliseks hooldamiseks: juurdepääsulisted muudavad aja jooksul tohutuks ja neid on raske hallata.

Teine mudel on Mandaadi alusel juurdepääsu kontroll (MAC – Mandatory access control). Selle mudeli järgi saab iga kasutaja juurdepääsu objektile vastavalt väljastatud loa alusel selle või teise andmete konfidentsiaalsuse taseme jaoks. Vastavalt peab objekte klassifitseerima konfidentsiaalsuse taseme järgi. Erinevalt esimesest paindlikust mudelist, on see vastupidi osutunud liiga rangeks ja piiravaks. Selle rakendamine ei õigusta ennast, kui ettevõttes on palju erinevaid teaberessursse: erinevate ressursside juurdepääsu piiramiseks tuleb luua mitmeid kategooriaid, mis ei kattuks.

Seoses nende kahe meetodi ilmse ebaefektiivsusega jätkas IT-kogukond mudelite väljatöötamist, mis oleksid paindlikumad ja samas enam-vähem universaalsed erinevate organisatsioonide juurdepääsu kontrolli poliitikate toetamiseks. Ja siis tekkis kolmas rollipõhine juurdepääsu kontrolli mudel! See lähenemine on osutunud kõige perspektiivikamaks, kuna see nõuab mitte ainult kasutaja isiku autentimist, vaid ka tema tööülesandeid süsteemides.

Esimese täpselt kirjeldatud rollimudeli pakkusid Ameerika teadlased David Ferraiolo ja Richard Kuhn USA Riiklikust Standardite ja Tehnoloogiate Instituudist 1992. aastal. Just siis ilmnes esmakordselt termin RBAC (rollipõhine juurdepääsu kontroll). Need uuringud ja põhikomponentide kirjeldused koos nende omavahelise seosega said aluseks kehtivale standardsile INCITS 359-2012, mille heakskiitis Rahvusvaheline Infotehnoloogia Standardite Komitee (INCITS).

Standard määratleb rolli kui „ametifunktsiooni organisatsiooni kontekstis, millel on teatud seotud semantika seoses kasutajale määratud volituste ja vastutusega“. Dokument kehtestab RBAC põhielemendid – kasutajad, seansid, rollid, load, toimingud ja objektid, samuti nende vahelised suhted ja seosed.

Standardis on esitatud minimaalne vajalik struktuur rollimudeli loomiseks – õiguste koondamine rollidesse ja seejärel juurdepääsu andmine kasutajatele nende kaudu. On määratletud mehhanismid rollide koostamiseks objektidest ja toimingutest, kirjeldatud rollide hierarhiat ja volituste pärimist. Igas ettevõttes on rollid, mis ühendavad elementaarseid volitusi, mis on vajalikud kõikidele töötajatele. See võib olla juurdepääs e-kirjale, dokumentide haldamise süsteemile, ettevõtte portaalile jne. Need volitused saab koondada ühte üldrolli nimega „töötaja“, mistõttu ei ole vaja iga kõrgema taseme rolli puhul korduvalt loetleda kõiki elementaarseid õigusi. Piisab lihtsalt viidata rolli pärimise tunnusele „töötaja“.

Hiljem täiendas standard uusi juurdepääsu atribuute, mis on seotud pidevalt muutuva keskkonnaga. Lisandusid staatilised ja dünaamilised piirangud. Staatilised tähendavad rollide kombinatsiooni keeldu (see sama toimetamine ja operatsioonide kontroll, millest varem mainitud). Dünaamilised piirangud võivad olla määratud muutuvaid parameetreid, näiteks aega (töö-/vabaajad), asukohta (kontor/kodu) jne.

Eraldi väärib mainimist atribuutidele põhinev ligipääsuhaldus (ABAC — Attribute-based access control). Mudel põhineb juurdepääsu andmisel atribuutide jagamise reeglite kaudu. Seda mudelit saab kasutada iseseisvalt, kuid sageli täiendab see aktiivselt klassikalist rollimudelit: teatud rollile saab lisada kasutajate, ressursside ja seadmete atribuute, samuti aega või asukohta. See võimaldab kasutada vähem rolle, kehtestada täiendavaid piiranguid ja muuta juurdepääsu minimaalseteks, mistõttu suureneb ohutus.

Näiteks võib raamatupidajale lubada juurdepääsu kontodele, kui ta töötab konkreetses piirkonnas. Siis võrreldakse spetsialisti asukohta kindla mõõduandega. Või võib juurdepääsu kontodele anda ainult juhul, kui kasutaja logib sisse seadmest, mis on lubatud seadmete nimekirjas. Hea lisa rollimudelile, kuid seda kasutatakse iseseisvalt harva, kuna see nõuab palju reeglite ja lubade või piirangute tabelite loomist.

Toon näite ABAC-i rakendamisest oma "eelmisest elust". Meie pangas oli mitu filiaali. Klientide teeninduspunktide töötajad nendes filiaalides tegid absoluutselt sama protseduuri, kuid pidid töötama põhissüsteemis vaid oma piirkonna kontodega. Alguses hakkasime looma eraldi rolle igas piirkonnas – ja selliseid rolle, millel oli korduv funktsionaalsus, kuid juurdepääs erinevatele kontodele, tuli tõeliselt palju! Siis kasutasime kasutaja asukoha atribuut ja sidusime selle konkreetse kontode vahemikuga kontrollimiseks, mis vähendas oluliselt süsteemis olevate rollide arvu. Lõpuks jäid alles vaid ühe filiaali rollid, mida kopeeriti vastavatele ametikohtadele kõikides teistes panga territoriaalsetes osakondades.

Nüüd räägime vajalikest ettevalmistusastmetest, ilma milleta pole võimalik luua toimivat rollimudelit.

Samm 1. Loome funktsionaalse mudeli

Alustuseks tuleks luua funktsionaalne mudel – kõrgemal tasemel dokument, milles on üksikasjalikult kirjeldatud iga osakonna ja iga ametikoha funktsionaalsus. Reeglina pannakse sinna teave erinevatest dokumentidest: ametijuhenditest ja eraldi osakondade – osakondade, juhtide, departemangude – määrustest. Funktsionaalne mudel peab olema kooskõlastatud kõigi asjaosaliste osakondadega (äri, sisekontroll, turvalisus) ja kinnitatud ettevõtte juhtkonna poolt. Milleks on see dokument vajalik? Selleks, et rollimudel saaks sellele viidata. Näiteks kui soovite luua rollimudeli juba olemasolevate kasutajaõiguste põhjal – mis on välja toodud süsteemist ja „ühendatud ühise nimetajaga“. Siis rollide kooskõlastamisel süsteemi äripoolt omanikuga saab viidata funktsionaalse mudeli konkreetsele punktile, mille põhjal see või teine õigus rolli lisatakse.

Samm 2. Teeme IKT süsteemide auditi ja koostame prioriseerimise plaani

Teisel etapil tuleks läbi viia IKT süsteemide audit, et mõista, kuidas ligipääs neis korraldatud on. Näiteks minu finantsfirmas kasutati mitut sada infotehnoloogilist süsteemi. Kõikides süsteemides olid mõned idud rollide haldamisest, enamikus oli mõningaid rolle, kuid peamiselt paberil või süsteemi registris – need olid ammu aegunud ja ligipääs neis anti vastavalt kasutajate tegelikele soovidele. Loomulikult on raske luua rollimudelit üheaegselt mitmesajas süsteemis, seetõttu tuleb millegi kallal alustada. Me viisime läbi süvitsi mineva analüüsi ligipääsu haldamise protsessi osas, et määrata selle küpsuse tase. Analüüsi käigus töötasime välja infotehnoloogiliste süsteemide prioriseerimise kriteeriumid – kriitilisus, valmidus, plaanid mahavõtmiseks jne. Nende abil koostasime järjestuse rollimudelite väljatöötamiseks/aktualiseerimiseks nende süsteemide jaoks. Ja seejärel – lisasime rollimudelid identiteedihalduse lahendusega integreerimise plaani, et automatiseerida ligipääsu haldamist.

Kuidas siis määrata süsteemi kriitilisust? Vastake endale järgmistele küsimustele:

• Kas süsteem on seotud operatiivsete protsessidega, mille täitmine on ettevõtte põhitegevuse jaoks oluline?
• Kas süsteemi talitlushäired mõjutavad ettevõtte varade terviklikkust?
• Milline on süsteemi maksimaalne lubatud seisaku aeg, mille jooksul on tegevuse taastamine pärast katkestust võimatu?
• Kas süsteemi teabe terviklikkuse rikkumine võib põhjustada pöördumatuid tagajärgi, sealhulgas rahalisi ja mainekahjusid?
• Fraudi kriitilisus. Funktsioonide olemasolu, mille jätkusuutlik kontroll on ebapiisav, et takistada sisesed/välised petuskeemid;
• Millised on seadusandlikud nõuded ning sisereeglid ja -protseduurid nendele süsteemidele? Kas eeskirjade mittejärgimise eest on regulaatorite poolt trahve?

Oma finantsettevõttes läbi viidud auditi käigus. Juhtkond töötas välja Access Right Review auditi protseduuri, et tutvuda olemasolevate kasutajate ja õigustega kõigepealt prioriteetsetes teabesüsteemides. Selle protsessi omanikkonnaks määrati turbosakond. Kuid, et saada täielikku ülevaadet ligipääsu õigustest ettevõttes, tuli protsessis kaasata ka IT ja äri osakonnad. Siin hakkasid vaidlused, arusaamatused ja mõnikord isegi sabotaaž: keegi ei taha oma praegustest kohustustest lahkuda ja sekkuda mõnesse esialgu arusaamatuks peetud tegevusse.

Märkus. Suured ettevõtted, kellel on arenenud IT-protsessid, tunnevad kindlasti IT auditi protseduuri - IT üldkontrollid (ITGC), mis aitab tuvastada puudusi IT-protsessides ja tagada kontrolli, et parandada protsesse vastavalt parimate praktikate (ITIL, COBIT, IT Valitsemine jne) soovitustele. Selline audit võimaldab IT-l ja äri poolt paremini üksteist mõista ning koostada arengu strateegiat, analüüsida riske, optimeerida kulusid ja arendada tõhusamaid töömeetodeid.



Üks auditi suundi on määrata teabe süsteemide loogilise ja füüsilise juurdepääsu parameetreid. Saadud andmed võtsime aluseks edasiseks kasutamiseks rollimudeli loomisel. Sellise auditi tulemusena saime IT-süsteemide register, milles määrati nende tehnilised parameetrid ja anti kirjeldused. Lisaks määrati iga süsteemi jaoks ärivaldkonnast omanik, kelle huvides seda kasutati: just tema vastutas äriprotsesside eest, mida see süsteem teenindas. Määrati ka IT-teenistuse juht, kes vastutas konkreetse teabe süsteemi tehnilise realiseerimise eest ärinõuetes. Kõige kriitilisemaid ettevõtte süsteeme ja nende tehnilisi parameetreid, kasutuselevõtu ja kõrvaldamise tähtaegu jne fikseeriti. Need parameetrid aitasid oluliselt rollimudeli loomise ettevalmistamisprotsessis.

Samm 3 Loome metoodika

Iga ettevõtte edu võti on õigesti valitud meetod. Seetõttu on nii rollimudeli loomisel kui ka auditi läbiviimisel vajalik luua metoodika, milles kirjeldame osakondade vahelisi suhteid, fikseerime vastutuse ettevõtte regulatsioonides jne.
Esmalt tuleb uurida kõiki olemasolevaid dokumente, mis määratlevad juurdepääsu ja õiguste andmise korda. Raskusest on, et protsessid peaksid olema dokumenteeritud mitmel tasemel:

• üldised ettevõtte nõuded;
• nõuded IT-ala (sõltuvad organisatsiooni tegevussuundadest);
• nõuded tehnolooge protsessidele (juhised, juurdepääsumatriigid, meetodilised juhised, konfiguratsiooninõuded).

Meie finantsettevõttes leidsime palju aegunud dokumente – tuli need uute protsesside rakendamisega kooskõlla viia.

Juhi korraldusel loodi töögrupp, kuhu kuulusid esindajad turvalisuse, IT, äri ja sisekontrolli valdkondadest. Korralduses olid määratletud grupi loomise eesmärgid, tegevusjuhu suund, eksisteerimise tähtaeg ja vastutavad isikud kõigilt osapooltelt. Lisaks arendasime välja auditeerimise metoodika ja rollimudeli koostamise korrändid: need kohandati kõigi vastutavate esindajate poolt ning kinnitas ettevõtte juhtkond.

Dokumendid, mis kirjeldavad tööde läbiviimise järjekorda, tähtaegu, vastutust jne, on tagatiseks, et soovitud eesmärgi saavutamisel, mis alguses ei ole kõigile tõeliselt selge, ei tekita kellelgi küsimusi "miks me seda teeme, miks see meile vajalik on jne" ning ei võimalda "ära jooksma" või protsessi aeglustada.

Samm 4. Fikseerime olemasoleva juurdepääsuhalduse mudeli parameetrid

Koostame nn "süsteemi passi" juurdepääsu haldamise osas. Tegelikult on see küsitlus konkreetse infotehnoloogilise süsteemi kohta, kuhu on fikseeritud kõik juurdepääsu haldamise algoritmid. Ettevõtted, kes on juba rakendanud endale IdM klassi lahendusi, tunnevad kindlasti sellist küsitlust, kuna just sellest algab süsteemide uurimine.

Osa süsteemi ja omanike parameetreid kanti küsitlusse IT Registerist (vt samm 2, audit), kuid on lisandunud ka uusi:

• kuidas toimub kasutajakontode haldamine (otseselt andmebaasis või programmiliideste kaudu);
• kuidas kasutajad sisenemisel süsteemi toimivad (kasutades eraldi kasutajakontot või AD, LDAP vms kontot);
• milliseid juurdepääsutasemeid süsteemis kasutatakse (rakendustasand, süsteemitase, süsteemi võrgufailide ressursid);
• kirjeldus ja parameetrid serverid, millel süsteem töötab;
• milliseid kasutajakontode haldamise toiminguid toetatakse (blokeerimine, ümbernimetamine jne);
• mille järgi koosneb kasutaja identifikaator süsteemis;
• mille alusel saab luua seose töötaja arveandmissüsteemi kirje (Nimi, töötaja number või muu);
• kõik kasutajakonto võimalikud attribuudid ja nende täitmise reeglid;
• millised juurdepääsuõigused süsteemis eksisteerivad (rollid, grupid, atomaarne õigused jne, kas on pesemis- või hierarhilisi õigusi);
• juurdepääsu õiguste jaotamise mehhanismid (ametikohtade, osakondade, funktsioonide jms kaupa);
• kas süsteemis on olemas õiguste jaotamise reeglid (SOD – ülesannete eristamine) ja kuidas need toimivad;
• kuidas süsteemis töödeldakse puudumise, üleviimise, lahkumise, töötajate andmete värskendamise jne sündmusi.

Seda nimekirja saab jätkata täiendava detailiga erinevate parameetrite ja muude objektide kohta, mis on seotud ligipääsu haldamise protsessiga.

Samm 5. Loome äripõhised volituste kirjeldused

Veel üks dokument, mida vajame rollimudeli loomisel, on kõikide võimalikest õigustest (volitustest) loend, mida saab kasutajatele anda infotehnoloogias koos üksikasjaliku kirjeldusega äritegevusest, mis selle taga seisab. Tihti on süsteemis õigused kodeeritud teatud nimetustega, mis koosnevad tähtedest ja numbritest, ning äri töötajad ei saa aru, mis nende sümbolite taga peitub. Siis nad pöörduvad IT-osakonna poole, kuid seal... ei suudeta ka harva kasutatavate õiguste kohta vastata. Seetõttu on vajalik täiendav testimine.

Hea, kui ärikirjeldus on juba olemas või isegi on olemas nende õiguste rühmitamine rühmadesse ja rollidesse. Mõnede rakenduste puhul on parim praktika sarnase loendi loomine juba arendusetapis. Kuid seda juhtub harva, seega jälle pöördume IT-osakonna poole, et koguda teavet kõikide võimalike õiguste kohta ja need kirja panna. Meie lõplik loend sisaldab järgmist:

• volituse nimetus, sealhulgas objekt, millele ligipääsuõigus kehtib;
• ülesanne, mida on lubatud objektiga teha (vaadata, muuta jne, samuti võib olla piiranguid, näiteks territoriaalse tunnuse või kliendigruppide kaupa);
• volituse kood (süsteemi funktsiooni/otsealgatuse kood ja nimi, mida saab volituse abil täita);
• volituse kirjeldus (üksikasjalik kirjeldus toimingutest IS-is volituse rakendamisel ja nende tagajärgedest protsessile;
• volituse staatus: 'Aktiivne' (kui volitus on määratud vähemalt ühele kasutajale) või 'Mitteaktiivne' (kui volitust ei kasutata).

Samm 6 Laadime süsteemidest kasutajate ja õiguste andmed välja ja seostame need kaadriallikaiga

Viimases ettevalmistusetapis tuleb andmed välja laadida infosisüsteemidest kõigi kasutajate ja nende praeguste õiguste kohta. Siin on võimalikud kaks stsenaariumi. Esiteks: turvasektsioonil on otse juurdepääs süsteemile ja olemas vastavad aruande väljalaadimise vahendid, mis ei juhtu sageli, kuid on väga mugavad. Teiseks: saadame IT-le taotluse aruannete saamiseks vajalikus formaadis. Praktika näitab, et IT-ga kokkuleppimine ja vajalike andmete saamine esimesel katsel ei õnnestu. Peame tegema mitu katset, kuni info saadakse soovitud kujul ja formaadis.

Milliseid andmeid tuleb välja laadida:

• Kasutajakonto nimetus
• Töötaja nimi, kellele see on seotud
• Staatus (aktiivne või blokeeritud)
• Kasutajakonto loomise kuupäev
• Viimase kasutamise kuupäev
• Saadaval õiguste/gruppide/rollide loetelu

Seega oleme saanud süsteemist väljavõtte kõigi kasutajate ja neile antud õigustega. Ja panime kohe kõrvale kõik blokeeritud kontod, kuna tööd rollimudeli koostamisega tehakse ainult aktiivsete kasutajate osas.

Seejärel, kui teie ettevõttes pole automatiseeritud vahendeid töötajate juurdepääsu sulgemiseks (selline asi ei ole haruldane) või on killustunud automatiseerimine, mis ei toimi alati korrektselt, tuleb tuvastada kõik "surmad hing". Jutt käib juba lahkunud töötajate kasutajakontodest, kelle õigused mingil põhjusel ei ole blokeeritud – need tuleb blokeerida. Selleks seome väljavõtte andmed personali allikaga. Ka personali väljavõtte tuleb eelnevalt saada osakonnalt, mis haldab personalibaasi.

Eraldas on vaja eristada kontosid, mille omanikke ei leitud personalibaasis, mis ei ole kellegi alluvuses – seega hüljatud. Selle nimekirja jaoks on meil vaja viimase kasutamise kuupäeva: kui see on pigem hiljutine, tuleb siiski omanikke otsida. Siia võivad kuuluda väliste alltöövõtjate kontod või ametlikud kontod, mis ei ole kellegi all, kuid on seotud mõne protsessiga. Kontode kuuluvuse selgitamiseks võib saata kõikidele osakondadele kirjad palvega vastata. Kui omanikud leitud, sisestame nende andmed süsteemi: nii on kõik aktiivsed kontod tuvastatud ja ülejäänud blokeerime.

Niipea, kui meie väljaõnnistused on vabastatud liigsetest kirjetest ja alles on ainult aktiivsed kontod, saame alustada rollimudeli koostamist konkreetse teabehaldus süsteemi jaoks. Kuid sellest räägin juba järgmisel artiklil.

Autor: Lyudmila Sevastyanova, Solar inRightsi edendamise juht

Allikas: habr.com