Nüüd töötan tarkvaramüüja ettevõttes, eelkõige juurdepääsukontrollilahenduste osas. Ja minu kogemus "eelmisest elust" on seotud kliendipoolega – suure finantsasutusega. Sel ajal ei saanud meie infoturbe osakonna juurdepääsukontrolli grupp suurepäraste IdM-i kompetentsidega kiidelda. Õppisime selle käigus palju, tuli täita hunnik konarusi, et ehitada üles toimiv mehhanism infosüsteemide kasutajaõiguste haldamiseks ettevõttes.
Ühendades oma kliendikogemuse hankijate teadmiste ja pädevustega, tahan teiega jagada sisuliselt samm-sammult juhist: kuidas luua suures ettevõttes rollipõhist juurdepääsukontrolli mudelit ja mida see annab lõpp. Minu juhend koosneb kahest osast: esimene - me valmistume mudelit ehitama, teine - me tegelikult ehitame selle. Enne esimeseks osaks saamist valmistuge.
NB Eeskuju loomine ei ole kahjuks mitte tulemus, vaid protsess. Õigemini, kasvõi osa ettevõttes läbipääsukontrolli ökosüsteemi loomise protsessist. Nii et häälestuge mängule pikka aega.
Kõigepealt defineerime – mis on rollipõhine juurdepääsukontroll? Oletame, et teil on suur pank, kus töötab kümneid või isegi sadu tuhandeid töötajaid (subjekte), millest igaühel on kümneid juurdepääsuõigusi sadadele pangasisestele infosüsteemidele (objektidele). Ja nüüd korrutage objektide arv subjektide arvuga - nii palju ühendusi peate vähemalt kõigepealt looma ja seejärel juhtima. Kas seda on tõesti võimalik käsitsi teha? Muidugi mitte – rollid tundusid selle probleemi lahendamiseks.
Roll on õiguste kogum, mida kasutaja või kasutajate rühm vajab teatud tööülesannete täitmiseks. Igal töötajal võib olla üks või mitu rolli ja iga roll võib sisaldada ühte kuni mitut õigust, mis on antud rollis olevale kasutajale lubatud. Rollid võivad olla seotud töötajate teatud ametikohtade, osakondade või funktsionaalsete ülesannetega.
Rollid luuakse tavaliselt igas infosüsteemis üksikute töötajate volitustest. Seejärel moodustuvad iga süsteemi rollidest globaalsed ärirollid. Näiteks äriroll "laenuhaldur" hõlmab mitmeid eraldi rolle infosüsteemides, mida kasutatakse panga kliendikontoris. Näiteks sellistes nagu peamine automatiseeritud pangasüsteem, kassaaparaat, elektrooniline dokumendihaldussüsteem, teenindusjuht ja muud. Ärirollid on reeglina seotud organisatsioonilise struktuuriga - teisisõnu ettevõtte osakondade ja ametikohtadega neis. Nii moodustub globaalne rollimaatriks (allolevas tabelis toon näite).
Väärib märkimist, et on lihtsalt võimatu ehitada 100% eeskuju, mis tagab äristruktuuris iga ametikoha töötajatele kõik vajalikud õigused. Jah, see pole vajalik. Eeskuju ei saa ju olla staatiline, sest see sõltub pidevalt muutuvast keskkonnast. Ja ettevõtte äritegevuse muutusest, mis vastavalt mõjutab organisatsiooni struktuuri ja funktsionaalsuse muutust. Ja ressursside täieliku tagamise puudumisest ja ametijuhendite mittejärgimisest ja kasumisoovist turvalisuse arvelt ja paljudest muudest teguritest. Seetõttu on vaja üles ehitada eeskuju, mis suudab katta kuni 80% kasutajate vajadustest vajalike põhiõiguste järele nende ametikohale määramisel. Ja ülejäänud 20% saavad nad vajadusel hiljem eraldi taotluste alusel üle kuulata.
Muidugi võite küsida: "Mis, 100% eeskujusid pole üldse olemas?" Noh, miks, see juhtub näiteks mittetulunduslikes struktuurides, mis ei allu sageli muutumisele - mõnes uurimisinstituudis. Või kõrge turvalisuse tasemega sõjalis-tööstusliku kompleksi organisatsioonides, kus turvalisus on esikohal. See juhtub ja kaubanduslikus struktuuris, kuid ühe üksuse raames, mille töö on üsna staatiline ja etteaimatav protsess.
Rollipõhise juhtimise peamiseks eeliseks on õiguste väljastamise lihtsus, sest rollide arv on oluliselt väiksem kui infosüsteemi kasutajate arv. Ja see kehtib iga tööstuse kohta.
Võtame jaemüügiettevõtte: see annab tööd tuhandetele müügiinimestele, kuid neil on N-süsteemis samad õigused ja neile luuakse ainult üks roll. Firmasse tuli uus müüja – talle määrati süsteemis automaatselt vajalik roll, millel on juba kõik vajalikud volitused. Samuti saab ühe klikiga muuta tuhandete müüjate õigusi korraga, näiteks lisada uue võimaluse aruande genereerimiseks. Te ei pea tegema tuhandet toimingut, sidudes iga kontoga uue õiguse – lihtsalt lisage see valik rollile ja see kuvatakse kõigile müüjatele korraga.
Rollipõhise haldamise teine eelis on ühildumatute õiguste vältimine. See tähendab, et töötajal, kellel on süsteemis teatud roll, ei saa olla samaaegselt teist rolli, mille õigusi ei tohiks kombineerida esimeses nimetatud õigustega. Ilmekas näide on keeld kombineerida finantstehingu sisend- ja kontrollifunktsioone.
Kõik, kes on huvitatud sellest, kuidas rollipõhine juurdepääsukontroll üldse tekkis, saavad seda teha
sukelduda ajalukku
Kui pöörduda ajaloo poole, siis esimest korda mõtles IT-kogukond juurdepääsukontrolli meetoditele XX sajandi 70ndatel. Kuigi rakendused olid siis üsna lihtsad, tahtsid kõik, nagu ka praegu, neile juurdepääsu mugavalt hallata. Andke, muutke ja kontrollige kasutajaõigusi – lihtsalt selleks, et oleks lihtsam aru saada, milline juurdepääs igaühel on. Kuid sel ajal polnud ühtseid standardeid, töötati välja esimesed läbipääsusüsteemid ning iga ettevõte lähtus oma ideedest ja reeglitest.
Praegu on teada palju erinevaid juurdepääsukontrolli mudeleid, kuid need ei ilmunud kohe. Peatugem neil, kes on andnud käegakatsutava panuse selle suuna arengusse.
Первая и, наверное, самая простая модель – Suvaline (valikuline) juurdepääsukontroll (DAC – valikuline juurdepääsukontroll). See mudel eeldab õiguste jagamist kõigi juurdepääsuprotsessis osalejate vahel. Iga kasutaja saab juurdepääsu konkreetsetele objektidele või toimingutele. Tegelikult vastab siin õiguste subjektide kogum objektide hulgale. See mudel leiti olevat liiga paindlik ja liiga raske hooldada: juurdepääsuloendid muutuvad aja jooksul tohutuks ja neid on raske kontrollida.
Teine mudel on Kohustuslik juurdepääsukontroll (MAC). Selle mudeli kohaselt saab iga kasutaja juurdepääsu objektile vastavalt väljastatud juurdepääsule teatud andmete konfidentsiaalsuse tasemele. Sellest lähtuvalt tuleks objektid kategoriseerida vastavalt konfidentsiaalsustasemele. Erinevalt esimesest paindlikust mudelist osutus see vastupidi liiga rangeks ja piiravaks. Selle kasutamine ei õigusta ennast, kui ettevõttel on palju erinevaid inforessursse: erinevatele ressurssidele juurdepääsu piiritlemiseks tuleb kasutusele võtta palju kategooriaid, mis ei kattu.
Nende kahe meetodi ilmselge ebatäiuslikkuse tõttu on IT-kogukond jätkanud paindlikumate ja samal ajal enam-vähem universaalsete mudelite väljatöötamist, et toetada erinevat tüüpi organisatsiooni juurdepääsukontrolli poliitikaid. Ja siis see ilmus kolmas rollipõhise juurdepääsukontrolli mudel! See lähenemine osutus kõige lootustandvamaks, kuna see nõuab mitte ainult kasutaja identiteedi autoriseerimist, vaid ka tema tööfunktsioone süsteemides.
Esimese hästi kirjeldatud eeskujustruktuuri pakkusid välja Ameerika teadlased David Ferrailo ja Richard Kuhn USA riiklikust standardi- ja tehnoloogiainstituudist 1992. aastal. Siis ilmus see termin esmakordselt RBAC (rollipõhine juurdepääsukontroll). Need uuringud ja põhikomponentide kirjeldused ning nende seosed olid aluseks tänaseni kehtivale INCITS 359-2012 standardile, mille on heaks kiitnud Rahvusvaheline Infotehnoloogia Standardite Komitee (INCITS).
Standard määratleb rolli kui "tööfunktsiooni organisatsiooni kontekstis koos teatud semantikaga, mis puudutab rollile määratud kasutajale määratud volitusi ja vastutust". Dokumendis kehtestatakse RBAC-i põhielemendid – kasutajad, seansid, rollid, õigused, toimingud ja objektid, aga ka nendevahelised seosed ja seosed.
Standard annab minimaalse vajaliku struktuuri rollimudeli loomiseks – rollide õiguste kombineerimine ja seejärel kasutajatele juurdepääsu andmine nende rollide kaudu. Kirjeldatakse objektidest ja operatsioonidest rollide koostamise mehhanisme, kirjeldatakse rollide hierarhiat ja volituste pärilikkust. Tõepoolest, igas ettevõttes on rolle, mis ühendavad elementaarsed volitused, mis on vajalikud kõigile ettevõtte töötajatele. See võib olla juurdepääs e-postile, EDMS-ile, ettevõtte portaalile jne. Need õigused võivad sisalduda ühes üldises rollis, mida nimetatakse töötajaks, ja iga kõrgema taseme rolli puhul ei ole vaja kõiki elementaarseid õigusi ikka ja jälle loetleda. Piisab, kui märkida "töötaja" rolli pärimise märk.
Hiljem täiendati standardit uute juurdepääsuatribuutidega, mis on seotud pidevalt muutuva keskkonnaga. Lisatud võimalus kehtestada staatilisi ja dünaamilisi piiranguid. Staatilised tähendavad rollide kombineerimise võimatust (sama sisend ja ülalmainitud toimingute juhtimine). Dünaamilisi piiranguid saab määratleda muutes parameetreid nagu aeg (töö-/vaba tööaeg või päevad), asukoht (kontor/kodu) jms.
Eraldi tuleks sellest rääkida Atribuudipõhine juurdepääsukontroll (ABAC). Lähenemisviis põhineb juurdepääsu andmisel atribuutide jagamise reeglite abil. Seda mudelit saab kasutada eraldi, kuid üsna sageli täiendab see aktiivselt klassikalist eeskuju: konkreetsele rollile saab lisada kasutajate, ressursside ja seadmete atribuute, samuti aega või asukohta. See võimaldab teil kasutada vähem rolle, kehtestada täiendavaid piiranguid ja muuta juurdepääs minimaalselt piisavaks ning seeläbi suurendada turvalisust.
Näiteks võib raamatupidajale lubada juurdepääsu kontodele, kui ta töötab teatud piirkonnas. Seejärel võrreldakse spetsialisti asukohta teatud kontrollväärtusega. Või saate kontodele juurdepääsu anda ainult siis, kui kasutaja logib sisse seadmest, mis on kantud lubatud kontode registrisse. Hea täiendus eeskujule, kuid seda kasutatakse harva, kuna on vaja luua palju reegleid ja lubade või piirangute tabeleid.
Toon näite ABACi kasutamisest oma "eelmisest elust". Meie pangal oli mitu filiaali. Nende filiaalide kliendikontorite töötajad tegid täpselt samu toiminguid, kuid pidid põhisüsteemis töötama ainult oma piirkonna kontodega. Esiteks hakkasime looma iga piirkonna jaoks eraldi rolle – selliseid korduva funktsionaalsusega, kuid erinevatele kontodele juurdepääsuga rolle oli nii palju! Seejärel, kasutades kasutaja jaoks asukohaatribuuti ja sidudes selle kontrollimiseks teatud kontode vahemikuga, vähendasime süsteemis oluliselt rollide arvu. Selle tulemusel jäid rollid vaid ühele filiaalile, mida korrati vastavatele ametikohtadele kõigis teistes panga territoriaalsetes allüksustes.
Ja nüüd räägime vajalikest ettevalmistavatest sammudest, ilma milleta on lihtsalt võimatu ehitada toimivat eeskuju.
Samm 1. Looge funktsionaalne mudel
Alustada tasub funktsionaalse mudeli loomisest - tipptasemel dokument, mis kirjeldab üksikasjalikult iga üksuse ja iga positsiooni funktsionaalsust. Teave sisestatakse sellesse reeglina erinevatest dokumentidest: ametijuhendid ja reeglid üksikutele allüksustele - jaoskondadele, osakondadele, osakondadele. Funktsionaalne mudel tuleb kokku leppida kõigi huvitatud osakondadega (äri, sisekontroll, turvalisus) ja kinnitada ettevõtte juhtkonnaga. Mille jaoks see dokument on? Et eeskuju saaks sellele viidata. Näiteks kavatsete luua eeskuju, mis põhineb töötajate olemasolevatel õigustel - süsteemist maha laaditud ja "ühise nimetajani taandatud". Seejärel saab süsteemi ettevõtte omanikuga saadud rollide kokkuleppimisel viidata konkreetsele funktsionaalse mudeli punktile, mille alusel see või teine õigus rolli sisse lülitatakse.
Etapp 2. Auditeerime IT-süsteeme ja koostame prioriteetide seadmise plaani
Teises etapis tuleks läbi viia IT-süsteemide audit, et mõista, kuidas neile juurdepääs on korraldatud. Näiteks minu finantsettevõttel oli mitusada infosüsteemi. Kõigis süsteemides olid mõned rollihalduse alged, enamikus - mõned rollid, kuid enamasti paberil või süsteemikataloogis - on need ammu aegunud ja juurdepääs neile jagati tegelike kasutajate nõudmisel. Loomulikult on lihtsalt võimatu ehitada eeskuju mitmesajas süsteemis korraga, kuskilt tuleb alustada. Viisime läbi juurdepääsukontrolli protsessi põhjaliku analüüsi, et teha kindlaks selle küpsusaste. Analüüsi käigus töötati välja infosüsteemide prioriseerimise kriteeriumid - kriitilisus, valmisolek, dekomisjoneerimise plaanid jne. Nende abiga koostasime nende süsteemide eeskujude arendamise / värskendamise jada. Ja siis - kaasas eeskujud identiteedihalduse lahendusega integreerimise plaani, et automatiseerida juurdepääsu kontrolli.
Niisiis, kuidas teha kindlaks süsteemi kriitilisus? Vastake endale järgmistele küsimustele:
- Kas süsteem on seotud tegevusprotsessidega, millest sõltub ettevõtte põhitegevus?
- Kas süsteemi katkemine mõjutab ettevõtte varade terviklikkust?
- Kui suur on süsteemi maksimaalne lubatud seisakuaeg, mille saavutamisel ei ole võimalik pärast katkestust aktiivsust taastada?
- Kas teabe terviklikkuse rikkumine süsteemis võib kaasa tuua pöördumatuid tagajärgi, nii rahalisi kui mainet puudutavaid?
- Kriitilisus pettuse suhtes. Funktsionaalsuse olemasolu, mille ebapiisava kontrolliga on võimalik teostada sisemisi / väliseid pettusi;
- Millised on nende süsteemide juriidilised nõuded, samuti sise-eeskirjad ja protseduurid? Kas reguleerivad asutused karistavad eeskirjade eiramise eest?
Meie finantsettevõttes viisime läbi sellise auditi. Juhtkond on välja töötanud juurdepääsuõiguste ülevaatuse auditiprotseduuri, et tegeleda esmajärjekorras olemasolevate kasutajate ja õigustega nendes infosüsteemides, mis on prioriteetsete nimekirjas. Turvaosakonnale on määratud selle protsessi omanik. Kuid selleks, et saada täielikku ülevaadet ettevõtte juurdepääsuõigustest, oli protsessi vaja kaasata IT- ja äriosakonnad. Ja siit algasid vaidlused, arusaamatused ja mõnikord isegi sabotaaž: keegi ei taha oma senistest tööülesannetest lahti rebida ja mõne esmapilgul arusaamatu tegevusega kaasa lüüa.
NB Arenenud IT protsessidega suurettevõtetele on ilmselt tuttav IT auditi protseduur - IT üldkontrollid (ITGC), mis võimaldab tuvastada IT protsesside puudujääke ja luua kontroll nii, et protsesse parendada vastavalt parimale praktikale (ITIL, COBIT, IT Juhtimine jne) Selline audit võimaldab IT-l ja ettevõttel üksteist paremini mõista ning välja töötada ühine arendusstrateegia, analüüsida riske, optimeerida kulusid ja töötada välja tõhusamaid töövõtteid.
Üks auditi valdkondi on infosüsteemidele loogilise ja füüsilise juurdepääsu parameetrite määramine. Saadud andmed võtsime aluseks edasiseks kasutamiseks eeskuju ehitamisel. Sellise auditi tulemusena on meil IT-süsteemide register, milles määrati nende tehnilised parameetrid ja anti kirjeldused. Lisaks määrati iga süsteemi jaoks omanik ärisuunast, kelle huvides seda kasutati: just tema vastutas äriprotsesside eest, mida see süsteem teenindas. Määrati ka IT-teenuste juht, kes vastutab ärivajaduste tehnilise teostamise eest konkreetses IS-is. Salvestati ettevõtte jaoks kõige kriitilisemad süsteemid ja nende tehnilised parameetrid, kasutuselevõtu ja dekomisjoneerimise kuupäevad jpm. Need parameetrid aitasid palju kaasa eeskuju ehitamiseks valmistumisel.
3. samm Looge metoodika
Iga ettevõtte edu võti on õige meetod. Seetõttu peame nii eeskuju ehitamiseks kui ka auditi läbiviimiseks looma metoodika, milles kirjeldame osakondade omavahelist suhtlust, fikseerime vastutuse ettevõtte regulatsioonides jne.
Kõigepealt peate tutvuma kõigi olemasolevate dokumentidega, mis kehtestavad juurdepääsu ja õiguste andmise korra. Heas mõttes tuleks protsessid dokumenteerida mitmel tasandil:
- ettevõtte üldised nõuded;
- nõuded infoturbe valdkondadele (olenevad organisatsiooni tegevusest);
- nõuded tehnoloogilistele protsessidele (juhised, juurdepääsumaatriksid, juhised, konfiguratsiooninõuded).
Meie finantsettevõttes leidsime palju aegunud dokumente – pidime need kooskõlla viima uute juurutatavate protsessidega.
Juhtkonna korraldusel moodustati töörühm, kuhu kuulusid turva-, IT-, äri- ja sisekontrolli valdkonna esindajad. Käskkirjas toodi välja rühma loomise eesmärgid, tegevussuund, eksisteerimisperiood ja kummagi poole kohustused. Lisaks oleme välja töötanud auditi metoodika ja eeskuju ehitamise korra: need leppisid kokku kõigi valdkondade vastutavate esindajatega ja kinnitasid ettevõtte juhtkond.
Tööde teostamise korda, tähtaegu, vastutust jms kirjeldavad dokumendid. - garantii, et teel hinnalise eesmärgi poole, mis esialgu pole kõigile ilmne, ei teki kellelgi küsimusi "miks me seda teeme, miks me seda vajame jne." ja puudub võimalus "ära hüpata" või protsessi aeglustada.
Etapp 4. Olemasoleva juurdepääsukontrolli mudeli parameetrite fikseerimine
Juurdepääsukontrolli osas koostame nn süsteemipassi. Tegelikult on see küsimustik konkreetse infosüsteemi kohta, kuhu on salvestatud kõik sellele juurdepääsu haldamise algoritmid. Ettevõtted, kes on juba IdM-klassi lahendusi juurutanud, on ilmselt sellise küsimustikuga tuttavad, sest sellest algab süsteemide uurimine.
Osa parameetreid süsteemi ja omanike kohta on küsimustikku voolanud IT registrist (vt samm 2, audit), kuid lisatud on uusi:
- kuidas kontosid hallatakse (otse andmebaasis või programmiliideste kaudu);
- kuidas kasutajad süsteemi sisse logivad (kasutades eraldi kontot või kasutades AD kontot, LDAP vms);
- milliseid juurdepääsutasemeid süsteemile kasutatakse (rakenduse tase, süsteemitase, võrgufailiressursside kasutamine süsteemi poolt);
- serverite kirjeldus ja parameetrid, millel süsteem töötab;
- milliseid kontohaldustoiminguid toetatakse (blokeerimine, ümbernimetamine jne);
- milliseid algoritme või reegleid kasutatakse süsteemi kasutaja identifikaatori moodustamiseks;
- millise atribuudiga saab luua lingi personalisüsteemi töötaja kirjega (täisnimi, personali number jne);
- kõik võimalikud konto atribuudid ja nende täitmise reeglid;
- millised juurdepääsuõigused süsteemis eksisteerivad (rollid, rühmad, aatomiõigused jne, kas on olemas pesastatud või hierarhilised õigused);
- juurdepääsuõiguste eraldamise mehhanismid (positsioonide, osakondade, funktsionaalsuse jne järgi);
- kas süsteemil on õiguste eraldamise reeglid (SOD – Segregation of Duties) ja kuidas need töötavad;
- kuidas toimub süsteemis töölt puudumise, üleviimise, vallandamise, töötajate andmete uuendamise jms sündmuste töötlemine.
Loendit võiks jätkata, kirjeldades üksikasjalikult erinevaid parameetreid ja muid juurdepääsukontrolli protsessis osalevaid üksusi.
5. samm: looge ettevõttele suunatud volituse kirjeldus
Teine dokument, mida vajame eeskuju ehitamisel, on juhend kõigi võimalike volituste (õiguste) kohta, mida saab infosüsteemis kasutajatele anda, koos selle taga oleva ärifunktsiooni üksikasjaliku kirjeldusega. Sageli on süsteemis olevad volitused krüpteeritud teatud nimedega, mis koosnevad tähtedest ja numbritest ning ettevõtte töötajad ei saa aru, mis nende märkide taga peitub. Siis minnakse IT-teenindusse ja seal ... ei oska ka vastata küsimusele näiteks harva kasutatavate õiguste kohta. Siis peate tegema rohkem katseid.
On hea, kui ettevõtte kirjeldus on juba olemas või isegi kui need õigused on seotud rühmadeks ja rollideks. Mõne rakenduse puhul on parim tava koostada selline juhend arendusetapis. Kuid seda ei juhtu sageli, seega läheme taas IT-osakonda, et koguda teavet kõigi võimalike õiguste kohta ja neid kirjeldada. Meie juhend sisaldab lõpuks järgmist:
- asutuse nimi, sealhulgas objekt, millele juurdepääsuõigus kehtib;
- tegevus, mida on lubatud objektiga teha (vaatamine, muutmine jne, piiramise võimalus näiteks territoriaalselt või klientide grupil);
- volituse kood (süsteemi funktsiooni/päringu kood ja nimi, mida saab volituse abil täita);
- asutuse kirjeldus (üksikasjalik kirjeldus IS-is volituse rakendamisel tehtavatest toimingutest ja nende tagajärgedest protsessile;
- loa olek: "Aktiivne" (kui luba on määratud vähemalt ühele kasutajale) või "Pole aktiivne" (kui luba ei kasutata).
6. samm Laadime süsteemidest välja andmed kasutajate ja õiguste kohta ning võrdleme neid personaliallikaga
Ettevalmistuse viimases etapis peate infosüsteemidest üles laadima andmed kõigi kasutajate ja nende praeguste õiguste kohta. Siin on võimalikud kaks stsenaariumi. Esiteks on turvaosakonnal otsene juurdepääs süsteemile ja vahendid vastavate aruannete allalaadimiseks, mis on haruldane, kuid väga mugav. Teiseks: saadame IT-le taotluse nõutud formaadis aruannete saamiseks. Praktika näitab, et IT-ga läbirääkimisi pidada ja vajalikke andmeid esimese korraga kätte saada pole võimalik. Vaja on teha mitu lähenemist, kuni teave on soovitud kujul ja vormingus laekunud.
Milliseid andmeid tuleb üles laadida:
- Kasutaja nimi
- Selle töötaja nimi, kellele see on määratud
- Olek (aktiivne või blokeeritud)
- Konto loomise kuupäev
- Viimati kasutatud kuupäev
- Saadaolevate õiguste/rühmade/rollide loend
Seega oleme saanud süsteemist mahalaadimised kõigi kasutajatega ja kõigi neile antud õigustega. Ja nad panid kõik blokeeritud kontod kohe kõrvale, kuna eeskuju loomiseks tehakse tööd ainult aktiivsetele kasutajatele.
Seejärel, kui teie ettevõttel pole automatiseeritud vahendeid vallandatud töötajate juurdepääsu sulgemiseks (see pole haruldane) või on olemas lapitehnika, mis ei tööta alati õigesti, peate tuvastama kõik "surnud hinged". Jutt käib juba vallandatud töötajate kontodest, kelle õigusi mingil põhjusel ei blokeerita – need tuleb blokeerida. Selleks võrdleme üles laetud andmeid personaliallikaga. Personali mahalaadimine tuleb eelnevalt hankida ka personalibaasi juhtivalt üksuselt.
Eraldi on vaja kõrvale jätta kontod, mille omanikke personalibaasist ei leitud, kellelegi ei määratud - see tähendab omanikuta. Selle nimekirja jaoks on meil vaja viimase kasutuse kuupäeva: kui see on üsna värske, siis peame ikkagi omanikke otsima. See võib hõlmata väliste töövõtjate kontosid või teenusekontosid, mis pole kellelegi määratud, kuid on seotud mis tahes protsessidega. Konto omandiõiguse selgitamiseks võite saata kõigile osakondadele kirjad vastamissooviga. Kui omanikud on leitud, sisestame nende kohta andmed süsteemi: sel viisil tuvastatakse kõik aktiivsed kontod ja ülejäänud blokeeritakse.
Niipea, kui meie üleslaaditud failid on ebavajalikest kirjetest puhastatud ja alles on jäänud vaid aktiivsed kontod, saame hakata konkreetse infosüsteemi jaoks eeskuju ehitama. Kuid ma räägin sellest järgmises artiklis.
Autor: Ljudmila Sevastyanova, Solar inRightsi reklaamijuht
Allikas: www.habr.com