Trenutno delam za podjetje, ki prodaja programsko opremo, zlasti rešitve za upravljanje dostopa. Moje izkušnje iz preteklega dela pa so povezane s strani naročnika - velike finančne ustanove. Takrat se naša skupina za nadzor dostopa v oddelku za informacijsko varnost ni mogla pohvaliti z veliko znanja o IdM. V procesu smo se veliko učili in doživeli kar nekaj težav, da smo v podjetju zgradili funkcionalen mehanizem za upravljanje uporabniških pravic v informacijskih sistemih.
Združil sem svoje izkušnje, pridobljene pri naročniku, s strokovnim znanjem in kompetencami dobavitelja ter želim z vami deliti korak za korakom navodila: kako zgraditi v veliki podjetju model upravljanja dostopa na osnovi vlog, in kaj to prinaša. Moja navodila so razdeljena na dva dela: prvi del - priprava na gradnjo modela, drugi del - sama gradnja. Pred vami je prvi del, pripravljalni.
N.B. Gradnja modela vlog ni, žal, rezultat, temveč proces. Natančneje, to je del procesa ustvarjanja ekosistema upravljanja dostopa v podjetju. Tako da se pripravite na dolgotrajno igro.
Sprva se opredelimo - kaj torej pomeni upravljanje dostopa na osnovi vlog? Recimo, da imate veliko banko z desetinami, morda celo sto tisoči zaposlenih (subjektov), od katerih vsak ima desetine pravic dostopa v stotine notranje bančne informacijske sisteme (objekti). Zdaj pomnožite število objektov s številom subjektov - prav toliko povezav morate najprej vzpostaviti in nato nadzorovati. Je to mogoče narediti ročno? Seveda ne - za rešitev te naloge so nastale vloge.
Vloga je niz pooblastil, ki jih potrebuje uporabnik ali skupina uporabnikov za opravljanje določenih delovnih nalog. Vsak zaposleni lahko ima ena ali več vlog, vsaka vloga pa lahko vsebuje od enega do več pooblastil, ki so dovoljena uporabniku v okviru te vloge. Vloge so lahko povezane z določenimi položaji, oddelki ali funkcionalnimi nalogami zaposlenih.
Vloge se običajno ustvarjajo iz ločenih pooblastil zaposlenih v vsakem informacijskem sistemu. Nato se iz vlog posameznih sistemov oblikujejo globalne poslovne vloge. Na primer, poslovna vloga „kreditni manager“ bo vključevala več ločenih vlog v informacijskih sistemih, ki se uporabljajo v strankinem uradu banke. Rekimo, v takih sistemih kot so glavna avtomatizirana bančna sistema, blagajniški modul, sistem elektronskega poslovanja, sistemski manager in drugi. Poslovne vloge so običajno vezane na organizacijsko-strukturno zasnovo – preprosto povedano, na skupek enot podjetja in položajev v njih. Tako se oblikuje globalna matrica vlog (primer prinašam v tabeli spodaj).
Omeniti velja, da je nemogoče zgraditi 100% vlogo modela, ki bi zaposlenim na vsaki poziciji v komercialni strukturi zagotovilo vsa potrebna pravice. Pa tudi ni potrebno. Vloga modela ne more biti statična, saj je odvisna od nenehno spreminjajočega se okolja. In od sprememb v poslovanju podjetja, kar ustrezno vpliva na spremembe v organizacijski strukturi in funkcionalnosti. In od pomanjkanja popolne oskrbe z viri, ter od nespoštovanja delovnih navodil, in od prizadevanj po dobičku na račun varnosti, in od mnogih drugih dejavnikov. Zato je potrebno zgraditi vlogo modela, ki lahko pokrije do 80% potreb uporabnikov po ustreznih osnovnih pravicah ob imenovanju na delovno mesto. Preostalih 20% bodo lahko, če bo potrebno, kasneje zaprosili po posameznih zahtevkih.
Seveda se lahko vprašate: „Ali sploh ne obstajajo 100% vloge modeli?“ No, zakaj ne, to se pojavlja, na primer, v neprofitnih strukturah, ki niso podvržene pogostim spremembam – v nekem raziskovalnem inštitutu. Ali v organizacijah vojaško-industrijskega kompleksa z visokim nivojem zaščite, kjer je varnost na prvem mestu. Občasno pa tudi v komercialni strukturi, vendar znotraj posebej izbrane enote, katere delo je dovolj statično in predvidljivo.
Glavna prednost vloge upravljanja je poenostavitev dodeljevanja pravic, saj je število vlog bistveno manjše od števila uporabnikov informacijskega sistema. In to velja za katerokoli panogo.
Предположим, у нас есть розничная компания, в которой работают тысячи продавцов. У всех у них одинаковый набор прав в системе N, и для них создается всего одна роль. Когда в компанию приходит новый продавец, ему автоматически назначается нужная роль в системе, где уже есть все необходимые полномочия. В один клик можно изменить права для тысяч продавцов одновременно, например, добавить новую опцию для формирования отчета. Нет необходимости выполнять тысячу операций, привязывая новое право к каждой учетной записи — достаточно просто внести эту опцию в роль, и она появится у всех продавцов сразу.
Еще одно преимущество ролевого управления — исключение выдачи несовместимых полномочий. То есть сотрудник, имеющий определенную роль в системе, не может одновременно иметь другую роль, права которой не должны сочетаться с правами первой. Яркий пример — запрет на совмещение функций ввода и контроля финансовой операции.
Все, кому интересно, как в принципе появилось ролевое управление доступом, могут
погрузиться в экскурсию по истории
Если обратиться к истории, то впервые ИТ-сообщество задумалось о методах управления доступом еще в 70-х годах XX века. Хотя приложения были тогда довольно простыми, но, как и сейчас, всем хотелось удобно управлять доступом к ним. Предоставлять, изменять и контролировать права пользователей — чтобы легче было понимать, какой доступ есть у каждого из них. Однако в то время не существовало общих стандартов, разрабатывались первые системы управления доступом, и каждая компания основывалась на своих собственных представлениях и правилах.
Сейчас известно много разных моделей управления доступом, но они не появились сразу. Остановимся на тех, которые внесли заметный вклад в развитие этого направления.
Первая и, наверное, самая простая модель — Дискреционное (избирательное) управление доступом (DAC – Discretionary access control). Ta model predlaga skupno uporabo pravic vsemi udeleženci v procesu dostopa. Vsak uporabnik dobi dostop do določenih predmetov ali operacij. V bistvu se tu veliko subjektov pravic ujema z mnogimi objekti. Ta model je bil prepoznan kot preveč prilagodljiv in preveč zapleten za vzdrževanje: seznami dostopa z vremenom postanejo ogromni in težko nadzorovani.
Druga model je Mandatno upravljanje dostopa (MAC — Mandatory access control). Po tej modelu vsak uporabnik dobi dostop do objekta v skladu s podeljenim dovoljenjem za določeno stopnjo zaupnosti podatkov. Objekti morajo biti ustrezno kategorizirani po stopnji zaupnosti. Nasprotno od prve prilagodljive model, je bila ta preveč stroga in omejevalna. Njena uporaba se ne izplača, kadar ima podjetje mnogo različnih informacijskih virov: da bi omejili dostop do različnih virov, bo potrebno uvedeti številne kategorije, ki se ne bodo prekrivale.
V luči očitne pomanjkljivosti teh dveh metod je IT-skupnost nadaljevala z razvojem modelov, ki so bolj prilagodljivi in hkrati bolj ali manj univerzalni za podporo različnim vrstam organizacijskih politik nadzora dostopa. In takrat je nastala tretja model upravljanja dostopa na osnovi vlog! Ta pristop se je izkazal za najbolj obetavnega, saj zahteva ne le avtentifikacijo identitete uporabnika, ampak tudi njegove delovne funkcije v sistemih.
Prvo jasno opredeljeno strukturo modela vlog sta predlagala ameriška znanstvenika David Ferraiolo in Richard Kuhn iz Nacionalnega inštituta za standarde in tehnologijo ZDA leta 1992. Takrat se je prvič pojavil izraz RBAC (Role-based access control). Ta raziskava in opisi osnovnih komponent ter njihovih medsebojnih povezav so postavili temelje za standard INCITS 359-2012, ki ga je potrdil Mednarodni odbor za standarde informacijske tehnologije (INCITS).
Standard definira ulogu kao "radnu funkciju unutar organizacije s određenom povezanošću semantike u vezi s ovlastima i odgovornostima koje su dodijeljene korisniku koji je imenovan u toj ulozi". Dokument postavlja osnovne elemente RBAC-a – korisnike, sesije, uloge, dozvole, operacije i objekte, kao i odnose i međusobne veze između njih.
U standardu je navedena minimalno potrebna struktura za izgradnju modela uloga – prikupljanje prava u uloge i zatim dodjela pristupa korisnicima putem tih uloga. Definirani su mehanizmi sastavljanja uloga iz objekata i operacija, opisani su hijerarhija uloga i nasljedstvo ovlasti. U svakoj kompaniji postoje uloge koje grupiraju elementarne ovlasti koje su potrebne svim zaposlenicima. To može uključivati pristup e-pošti, EDC-u, korporativnom portalu itd. Ove ovlasti mogu se uključiti u jednu zajedničku ulogu pod nazivom "zaposlenik", čime se izbjegava ponavljanje svih osnovnih prava u svakoj višoj ulozi. Dovoljno je jednostavno navesti znak nasljedstva uloge "zaposlenik".
Kasnije je standard dopunjen novim atributima pristupa, povezanim s stalno promjenjivim okruženjem. Uvedene su mogućnosti postavljanja statičkih i dinamičkih ograničenja. Statistička ograničenja podrazumijevaju nemogućnost kombiniranja uloga (unaprijed definirano unosa i kontrola operacija, kako je gore spomenuto). Dinamička ograničenja mogu se određivati promjenjivim parametrima, kao što su vrijeme (radno/neradno vrijeme ili dani), lokacija (ured/dom) itd.
Posebno se treba napomenuti upravljanje pristupom temeljenom na atributima (ABAC – Attribute-based access control). Pristup se temelji na davanju pristupa putem pravila zajedničkog korištenja atributima. Ovaj model može se koristiti samostalno, ali često aktivno dopunjuje klasičnu ulogu: određenoj ulozi mogu se dodavati atributi korisnika, resursa i uređaja, kao i vremena ili lokacije. To omogućuje korištenje manje uloga, uvođenje dodatnih ograničenja i postizanje minimalnog potrebnog pristupa, a posljedično povećava sigurnost.
Na primjer, računovođi se može dopustiti pristup računima ako radi u određenoj regiji. Tada će se lokacija stručnjaka uspoređivati s određenom referentnom vrijednošću. Ili se može dopustiti pristup računima samo ako se korisnik prijavi s uređaja koji je registriran na popisu dopuštenih. Dobar dodatak u modelu uloga, ali se rijetko koristi samostalno zbog potrebe za izradom mnogih pravila i tablica dopuštenja ili ograničenja.
Dat ću primjer primjene ABAC-a iz svog 'prošlog života'. U našoj banci bilo je nekoliko filijala. Zaposlenici klijentnih ureda u tim filijalama obavljali su apsolutno iste operacije, ali su u glavnom sustavu mogli raditi samo s računima svoje regije. Isprva smo počeli stvarati zasebne uloge za svaku regiju – i takvih uloga s ponavljajućom funkcionalnošću, ali s pristupom različitim računima, bilo je jako puno! Tada smo koristeći atribut lokacije za korisnika i povezavši ga s određenim rasponom računa za provjeru, značajno smanjili broj uloga u sustavu. Na kraju su ostale samo uloge za jednu filijalu, koje su se umnožavale za odgovarajuće pozicije u svim ostalim teritorijalnim jedinicama banke.
A sada razgovarajmo o potrebnim pripremnim koracima bez kojih jednostavno nije moguće izgraditi funkcionalan model uloga.
Korak 1. Stvaramo funkcionalni model
Začeti je treba s pripravo funkcionalnega modela – dokumenta na višji ravni, v katerem je podrobno opisana funkcionalnost vsakega oddelka in vsakega delovnega mesta. Običajno informacije vkljuujejo različne dokumente: delovna navodila in predpise za posamezne oddelke – agencije, oddelke, službe. Funkcionalni model mora biti usklajen z vsemi zainteresiranimi oddelki (poslovanje, notranji nadzor, varnost) in potrjen s strani vodstva podjetja. Zakaj je ta dokument potreben? Da se lahko referenčni model sklicuje na njega. Na primer, nameravate zgraditi referenčni model na podlagi obstoječih pravic zaposlenih – izvoženih iz sistema in „pripravljenih na enotno raven“. Takrat se lahko pri usklajevanju dobljenih vlog z poslovnim lastnikom sistema sklicujete na določen odstavek funkcionalnega modela, na podlagi katerega se v vlogo vključuje določena pravica.
Korak 2. Izvedemo revizijo IT-sistemov in pripravimo načrt prioritetizacije
V drugem koraku je potrebno izvesti revizijo IT-sistemov, da se ugotovi, kako je dostop organiziran. Na primer, v mojem finančnem podjetju je bilo v uporabi več sto informacijskih sistemov. V vseh sistemih so bili nekateri začetki upravljanja vlog, v večini – določene vloge, vendar večinoma na papirju ali v sistemskem imeniku – ti so že zdavnaj zastareli, dostop pa je bil podeljen na podlagi dejanskih zahtev uporabnikov. Seveda je nemogoče takoj zgraditi referenčni model v več sto sistemih, zato je potrebno nekje začeti. Izvedli smo poglobljeno analizo procesa upravljanja dostopa, da bi določili raven njegove zrelosti. V procesu analize smo oblikovali kriterije za prioritetizacijo informacijskih sistemov – kritičnost, pripravljenost, načrti za izločitev in podobno. Z njihovo pomočjo smo določili vrstni red za razvoj/aktualizacijo referenčnih modelov za te sisteme. Nato smo vključili referenčne modele v načrt integracije s rešitvijo za upravljanje identitet, da bi avtomatizirali upravljanje dostopa.
Torej, kako določiti kritičnost sistema? Odgovorite si na naslednja vprašanja:
- Ali je sistem povezan z operativnimi procesi, od katerih je odvisna osnovna dejavnost podjetja?
- Bodo vpliva okvara sistema na celovitost premoženja podjetja?
- Koliko je največje dovoljeno trajanje izpada sistema, po katerem ni mogoče obnoviti delovanja po prekinitvi?
- Ali lahko kršitev celovitosti informacij v sistemu privede do nepovratnih posledic, tako finančnih kot tudi reputacijskih?
- Kritičnost za goljufije. Obstožnost funkcionalnosti, pri katerih pomanjkljiv nadzor omogoča izvajanje notranjih/zunanjih goljufij;
- Kakšne so zahteve zakonodaje ter notranjih pravil in postopkov za te sisteme? Ali bodo kazni s strani regulatorjev za nespoštovanje?
V naši finančni družbi smo izvedli revizijo na naslednji način. Uprava je razvila postopek revizije Access Right Review, da bi se spoprijela z obstoječimi uporabniki in pravicami najprej v tistih informacijskih sistemih, ki so bila na seznamu najprioritetnejših. Lastnik tega postopka je bila imenovana varnostna enota. Toda za pridobitev celovite slike o pravicah dostopa v podjetju je bilo potrebno vključiti tudi oddelke IT in poslovanja v postopek. In tukaj so se začeli spori, nesporazumi in včasih celo sabotaže: nihče se ne želi odtrgati od svojih trenutnih nalog in se zapletati v nekatera, na prvi pogled, nerazumljiva opravila.
N.B. Velika podjetja z razvitimi IT-procesi so zagotovo seznanjena s postopkom IT revizije – IT general controls (ITGC), ki omogoča odkrivanje pomanjkljivosti v IT-procesih in vzpostavitev nadzora, tako da se izboljšajo procesi v skladu z najboljšimi praksami (ITIL, COBIT, IT Governance itd.). Takšna revizija omogoča IT-ju in poslovanju boljše razumevanje drug drugega ter oblikovanje skupne strategije razvoja, analizo tveganj, optimizacijo stroškov in oblikovanje bolj učinkovitih pristopov v delu.
Ena od usmeritev revizije je določitev parametrov logičnega in fizičnega dostopa do informacijskih sistemov. Pridobljeni podatki so postali osnova za nadaljnjo uporabo pri oblikovanju vloge modela. Kot rezultat te revizije smo pridobili register IT sistemov, v katerem so bili določeni njihovi tehnični parametri in opisi. Poleg tega je bil za vsak sistem določen lastnik iz poslovnega področja, v korist katerega je bil ta sistem uporabljen: prav on je bil odgovoren za poslovne procese, ki jih je ta sistem podpirala. Določili smo tudi vodjo IT službe, odgovornega za tehnično realizacijo potreb poslovanja v določenem IS. Zabeleženi so bili najbolj kritični sistemi za podjetje in njihovi tehnični parametri, roki za uvajanje in umik iz obratovanja itd. Ti parametri so nam zelo pomagali pri pripravi na oblikovanje vloge modela.
Korak 3 Ustvarimo metodologijo
Ključ do uspeha katerega koli dela je pravilno izbran način. Zato moramo tudi za oblikovanje vloge modela in izvedbo revizije ustvariti metodologijo, v kateri bomo opisali interakcijo med oddelki, opredelili odgovornosti v predpisih podjetja itd.
Najprej je potrebno raziskati vse obstoječe dokumente, ki določajo postopek dodeljevanja dostopa in pravic. V resnici bi morali biti procesi dokumentirani na več ravneh:
- splošni korporativni zahtevi;
- zahteve za področja informacijske varnosti (odvisno od smeri delovanja organizacije);
- zahteve za tehnološke procese (navodila, dostopne matrice, metodološke smernice, zahteve po konfiguracijah).
V naši finančni družbi smo odkrili veliko zastarelih dokumentov – morali smo jih uskladiti z novimi procesi, ki se uvajajo.
Na ukazanie voditel'stva byla sozdana rabochaya gruppa, v kotoruyu voshli predstaviteli napravleniy bezopasnosti, IT, biznesa i vnutrennego kontrolya. V ukaze byli oboznacheny tsely sozdaniya gruppy, napravlenie deyatel'nosti, srok sushchestvovaniya i otvetstvennye ot kazhdoy storony. Krome togo, my razrabotali metodiku provedeniyu audita i poryadok postroyeniya rolevoy modeli: ikh soglasovali vse otvetstvennye predstaviteli napravleniy i utverdilo rukovodstvo kompanii.
Dokumenty, opisivayushchie poryadok provedeniy rabot, sroki, otvetstvennost' i t.d. – zalog togo, chto na puti k zaветnoy tsely, kotoraya vnachale ne vsem ochevidna, ni u kogo ne vozniknet voprosov «a dlya chego my eto delayem, a zachem nam eto nuzhno i t.p.» i ne budet vozmozhnosti «saskochit'» ili zatormozhit' protsess.
Shag 4. Fiksiruem parametry suschestvuyushchey modeli upravleniya dostupom
Sostavlyaem tak nazivaemyy «pasport sistemy» v chasti upravleniya dostupom. Po suti, eto opsionik po konkretnoj informatsionnoj sisteme, v kotorom zafiksirovany vse algoritmy upravleniya dostupom k ney. Kompanii, kotorye uzhe vnedrili u sebya resheniya klassa IdM, navernyaka znakomyy s podobnym opsionikom, tak kak imenno s nego nachinaetsya issledovanie sistem.
Chast' parametrov o sisteme i vladeltsev peretekla v opsionik iz reestra IT (sm. shag 2, audit), no dobavilis' i novye:
- kak osushchestvlyaetsya upravlenie uchetными zapisyami (napryamuyu v BD ili cherez programmnye interfeysy);
- kak pol'zovateli vypolnyayut vkhod v sistemy (s pomoshch'yu otdel'noy uchetnoj zapisi ili s ispol'zovaniem uchetki AD, LDAP ili dr.);
- kakie urovni dostupa k sisteme ispol'zuyutsya (uroven' prilozheniya, sistemnyy urovny, ispol'zovanie sistemoy setevoih faylovykh resursov);
- opisanie i parametry strežnikov, na kotorikh rabotaet sistema;
- kakie operatsii po upravleniyu uchetными zapisyami podderzhivayutsya (blokirovka, pereimenovanie i t.p.);
- po kakim algoritmam ili pravlam formiruetsya identifikator pol'zovatelya sistemy;
- po kakomu atributu mozhno ustanovit' svyaz' s zapisi o sotrudnike v kadrovoy sisteme (FIO, tabel'nyy nomer ili dr.);
- vse vozmozhnyye atributy uchetной zapisi i pravila ikh zapolneniya;
- kakie prava dostupa sushchestvuyut v sisteme (roli, grupy, atomarnye prava i dr., yest' li vlozhennye ili ierarhicheskie prava);
- mehanizmi delitve pravic dostopa (po delovnih mestih, oddelkih, funkcionalnosti itd.);
- ali sistem vključuje pravila razmejitve pravic (SOD – Segregacija dolžnosti) in kako ta delujejo;
- kako se v sistemu obravnavajo dogodki odsotnosti, prenosa, odpuščanja, posodabljanja podatkov o zaposlenih ipd.
Ta seznam lahko nadaljujemo z dodatno podrobnostjo glede različnih parametrov in drugih objektov, ki so vključeni v proces upravljanja dostopa.
Korak 5. Ustvarimo poslovno usmerjen opis pooblastil
Še en dokument, ki ga potrebujemo pri oblikovanju vlog, je seznam vseh možnih pooblastil (pravic), ki jih lahko dodelimo uporabnikom v informacijskem sistemu s podrobnim opisom poslovne funkcije, ki stoji za njimi. Pogosto so pooblastila v sistemu zakodirana z določenimi imeni, ki so sestavljena iz črk in številk, in zaposleni v podjetju ne morejo razumeti, kaj skriva za temi simboli. Takrat se obrnejo na IT službo, ki prav tako ne more odgovoriti na vprašanje, na primer, glede redko uporabljenih pravic. Takrat je potrebno izvesti dodatno testiranje.
Dobro je, če poslovni opis že obstaja ali pa celo obstaja združitev teh pravic v skupine in vloge. Za nekatere aplikacije je najboljša praksa, da se podoben seznam ustvari že v fazi njihovega razvoja. Vendar se to redko dogaja, zato spet gremo v IT oddelek, da zberemo informacije o vseh mogočih pravicah in jih opišemo. Naš seznam bo na koncu vseboval naslednje:
- ime pooblastila, vključno z objektom, na katerega se nanaša pravica dostopa;
- dejanje, ki je dovoljeno izvajati z objektom (ogled, sprememba itd., možnost omejitve, na primer, po teritorialnem kriteriju ali po skupini strank);
- kodo pooblastila (koda in ime funkcije/poizvedbe sistema, ki jo lahko izvedemo z uporabo pooblastila);
- opis pooblastila (podroben opis dejanj v IS ob uporabi pooblastila in njihovih posledic za proces;
- status pooblastila: 'Aktivno' (če je pooblastilo dodeljeno vsaj enemu uporabniku) ali 'Neaktivno' (če pooblastilo ni uporabljeno).
Korak 6. Izvozimo podatke o uporabnikih in pravicah iz sistemov in jih uskladimo s kadrovsko bazo
Na zadnjemu koraku priprave je treba iz informacijskih sistemov pridobiti podatke o vseh uporabnikih in pravicah, ki jih trenutno imajo. Tukaj sta možna dva scenarija. Prvi: enota za varnost ima neposreden dostop do sistema in sredstva za pridobitev ustreznih poročil, kar se redko zgodi, a je zelo priročno. Drugi: pošljemo zahtevo IT-ju za pridobitev poročil v zahtevanem formatu. Praksa dokazuje, da se s IT-jem težko dogovorimo in dobimo potrebne podatke že pri prvem poskusu. Potrebno je večkrat pristopiti, dokler informacije ne bomo dobili v želeni obliki in formatu.
Katere podatke je treba pridobiti:
- Ime uporabniškega računa
- Ime in priimek zaposlenega, ki je povezan z njim
- Status (aktiven ali blokiran)
- Datum ustvarjanja uporabniškega računa
- Datum zadnje uporabe
- Seznam razpoložljivih pravic/skupin/rol
Torej, pridobili smo podatke iz sistema z vsemi uporabniki in vsemi pravicami, ki so jim dodeljene. Takoj smo odložili vse blokirane račune, saj se bo delo na oblikovanju vlog izvedlo le za aktivne uporabnike.
Nato, če v vaši družbi ni avtomatiziranih sredstev za zapiranje dostopa odpuščenim zaposlenim (to se pogosto zgodi) ali pa obstaja kosmate avtomatizacije, ki ne deluje vedno pravilno, je treba ugotoviti vse 'mrtve duše'. Govorimo o uporabniških računih že odpravljenih zaposlenih, katerih pravice iz kakršnegakoli razloga niso blokirane, – te je treba blokirati. Za to se podatki iz izpisa uskladijo z kadrovskim virom. Kadrovski izpis je prav tako treba najprej pridobiti od enote, ki vodi kadrovsko bazo.
Ločene moramo odložiti račune, katerih lastniki niso bili najdeni v kadrovski bazi, ki niso dodeljeni nikomur – torej brez lastnika. Ta seznam bo potreboval datum zadnje uporabe: če je precej svež, bomo vseeno morali poiskati lastnike. Sem lahko spadajo računi zunanjih izvajalcev ali službene račune, ki niso dodeljeni nikomur, a so povezani z nekaterimi procesi. Za ugotovitev pripadnosti računov lahko pošljemo vsem oddelkom e-pošto s prošnjo, da se oglasijo. Ko najdemo lastnike, vnesemo njihove podatke v sistem: na ta način so vsi aktivni računi prepoznani, ostale pa blokiramo.
Ko so naši izvozi očiščeni od odvečnih zapisov in so ostali samo aktivni računi, lahko začnemo z oblikovanjem vlog modela za specifični informacijski sistem. O tem pa bom govorila v naslednjem članku.
Avtor: Ljudmila Sevastjanova, vodja promocije Solar inRights
Izvor: habr.com
