V súčasnosti pracujem pre dodávateľa softvéru, konkrétne pre riešenia riadenia prístupu. A moja skúsenosť „z minulého života“ je spojená so stranou zákazníka - veľkou finančnou organizáciou. Naša skupina kontroly prístupu na oddelení informačnej bezpečnosti sa v tom čase nemohla pochváliť veľkými kompetenciami v IdM. Veľa sme sa pri tom naučili, museli sme naraziť na množstvo prešľapov, aby sme vybudovali fungujúci mechanizmus na správu užívateľských práv v informačných systémoch vo firme.
Spojením mojich ťažko získaných zákazníckych skúseností so znalosťami a kompetenciami dodávateľa sa s vami chcem podeliť v podstate o podrobné pokyny: ako vytvoriť model riadenia prístupu na základe rolí vo veľkej spoločnosti a čo to prinesie. . Môj návod pozostáva z dvoch častí: prvá je príprava na stavbu modelu, druhá je vlastne stavanie. Tu je prvá časť, prípravná časť.
NB Budovanie vzoru nie je, žiaľ, výsledok, ale proces. Alebo skôr dokonca súčasťou procesu vytvárania ekosystému kontroly prístupu vo firme. Pripravte sa teda na hru dlho.
Najprv si to definujme – čo je riadenie prístupu založené na rolách? Predpokladajme, že máte veľkú banku s desiatkami, ba až stovkami tisíc zamestnancov (subjektov), z ktorých každý má desiatky prístupových práv k stovkám interných bankových informačných systémov (objektov). Teraz vynásobte počet objektov počtom subjektov - to je minimálny počet spojení, ktoré musíte najprv vybudovať a potom ovládať. Je to naozaj možné urobiť ručne? Samozrejme, že nie – na vyriešenie tohto problému boli vytvorené roly.
Rola je množina povolení, ktoré potrebuje používateľ alebo skupina používateľov na vykonávanie určitých pracovných úloh. Každý zamestnanec môže mať jednu alebo viac rolí a každá rola môže obsahovať jedno až viacero povolení, ktoré má používateľ v rámci danej roly povolené. Roly môžu byť viazané na konkrétne pozície, oddelenia alebo funkčné úlohy zamestnancov.
Roly sa spravidla vytvárajú z jednotlivých oprávnení zamestnancov v každom informačnom systéme. Potom sa z úloh každého systému formujú globálne obchodné roly. Napríklad obchodná rola „credit manager“ bude zahŕňať niekoľko samostatných rolí v informačných systémoch, ktoré sa používajú v zákazníckej kancelárii banky. Napríklad v hlavnom automatizovanom bankovom systéme, pokladničnom module, systéme elektronickej správy dokumentov, manažérovi služieb a iných. Obchodné roly sú spravidla viazané na organizačnú štruktúru - inými slovami, na súbor divízií spoločnosti a pozícií v nich. Takto sa vytvára globálna matica rolí (príklad uvádzam v tabuľke nižšie).
Stojí za zmienku, že je jednoducho nemožné vybudovať 100% vzor, ktorý poskytuje všetky potrebné práva pre zamestnancov každej pozície v komerčnej štruktúre. Áno, nie je to potrebné. Vzor predsa nemôže byť statický, pretože závisí od neustále sa meniaceho prostredia. A to zo zmien v obchodných aktivitách spoločnosti, čo teda ovplyvňuje zmeny v organizačnej štruktúre a funkčnosti. A z nedostatku plného zabezpečenia zdrojov a z nedodržiavania popisu práce a z túžby po zisku na úkor bezpečnosti a z mnohých ďalších faktorov. Preto je potrebné vybudovať taký vzor, ktorý dokáže pokryť až 80 % potrieb používateľov na potrebné základné práva pri priradení k pozícii. A v prípade potreby môžu požiadať o zvyšných 20 % neskôr v samostatných aplikáciách.
Samozrejme, môžete sa opýtať: „Neexistujú žiadne také veci ako 100% vzory? No prečo, to sa deje napríklad v neziskových štruktúrach, ktoré nepodliehajú častým zmenám – v nejakom výskumnom ústave. Alebo v organizáciách vojensko-priemyselného komplexu s vysokou úrovňou zabezpečenia, kde je bezpečnosť na prvom mieste. Deje sa tak v komerčnej štruktúre, ale v rámci samostatnej divízie, ktorej práca je dosť statický a predvídateľný proces.
Hlavnou výhodou rolového manažmentu je zjednodušenie vydávania práv, pretože počet rolí je podstatne menší ako počet užívateľov informačného systému. A to platí pre každé odvetvie.
Vezmime si maloobchodnú spoločnosť: zamestnáva tisíce predajcov, ktorí však majú rovnakú sadu práv v systéme N a bude pre nich vytvorená iba jedna rola. Pri príchode nového obchodníka do firmy je mu automaticky pridelená požadovaná rola v systéme, ktorý už má všetky potrebné oprávnenia. Jedným kliknutím môžete tiež zmeniť práva pre tisíce predajcov naraz, napríklad pridať novú možnosť generovania prehľadu. Nie je potrebné robiť tisíc operácií, pripájať nové právo ku každému účtu - stačí pridať túto možnosť do role a zobrazí sa všetkým predajcom súčasne.
Ďalšou výhodou rolového manažmentu je eliminácia vydávania nekompatibilných autorizácií. To znamená, že zamestnanec, ktorý má v systéme určitú úlohu, nemôže mať súčasne inú úlohu, ktorej práva by sa nemali spájať s právami prvej. Pozoruhodným príkladom je zákaz spájania funkcií vstupu a kontroly finančnej transakcie.
Každý, koho zaujíma, ako vznikla kontrola prístupu na základe rolí, môže
ponorte sa do histórie
Ak sa pozrieme do histórie, IT komunita prvýkrát premýšľala o metódach kontroly prístupu už v 70. rokoch XNUMX. storočia. Aj keď boli aplikácie vtedy celkom jednoduché, rovnako ako teraz, naozaj každý chcel pohodlne spravovať prístup k nim. Udeľujte, meňte a kontrolujte používateľské práva – len aby ste ľahšie pochopili, aký prístup má každý z nich. Ale v tom čase ešte neexistovali spoločné štandardy, vyvíjali sa prvé systémy kontroly vstupu a každá firma si zakladala na vlastných predstavách a pravidlách.
V súčasnosti je známych veľa rôznych modelov riadenia prístupu, ale neobjavili sa okamžite. Pozastavme sa pri tých, ktoré významnou mierou prispeli k rozvoju tejto oblasti.
Prvý a asi najjednoduchší model je Diskrečná (selektívna) kontrola prístupu (DAC – Diskretionary access control). Tento model predpokladá zdieľanie práv všetkými účastníkmi prístupového procesu. Každý používateľ má prístup k špecifickým objektom alebo operáciám. V podstate tu súbor predmetov práv zodpovedá súboru predmetov. Zistilo sa, že tento model je príliš flexibilný a príliš náročný na údržbu: zoznamy prístupových práv sa nakoniec stanú obrovskými a ťažko kontrolovateľnými.
Druhý model je Povinná kontrola prístupu (MAC – Povinná kontrola prístupu). Podľa tohto modelu každý užívateľ získa prístup k objektu v súlade s poskytnutým prístupom k určitej úrovni dôvernosti údajov. Predmety by sa preto mali kategorizovať podľa úrovne ich dôvernosti. Na rozdiel od prvého flexibilného modelu sa tento naopak ukázal ako príliš prísny a obmedzujúci. Jeho použitie nie je opodstatnené, keď má spoločnosť veľa rôznych informačných zdrojov: na rozlíšenie prístupu k rôznym zdrojom budete musieť zaviesť veľa kategórií, ktoré sa nebudú prekrývať.
Kvôli zjavným nedokonalostiam týchto dvoch metód IT komunita pokračovala vo vývoji modelov, ktoré sú flexibilnejšie a zároveň viac-menej univerzálne na podporu rôznych typov organizačných politík riadenia prístupu. A potom sa to objavilo tretí model riadenia prístupu založený na rolách! Tento prístup sa ukázal ako najsľubnejší, pretože vyžaduje nielen autorizáciu identity používateľa, ale aj jeho prevádzkových funkcií v systémoch.
Prvú jasne opísanú štruktúru vzoru navrhli americkí vedci David Ferrailo a Richard Kuhn z amerického Národného inštitútu pre štandardy a technológie v roku 1992. Potom sa prvýkrát objavil termín RBAC (Role-based access control). Tieto štúdie a popisy hlavných komponentov, ako aj ich vzťahov, tvorili základ normy INCITS 359-2012, ktorá je v platnosti dodnes, schválená Medzinárodným výborom pre štandardy informačných technológií (INCITS).
Norma definuje rolu ako "pracovnú funkciu v kontexte organizácie s nejakou pridruženou sémantikou týkajúcou sa oprávnenia a zodpovednosti pridelenej užívateľovi pridelenému role." Dokument stanovuje základné prvky RBAC – používateľov, relácie, roly, oprávnenia, operácie a objekty, ako aj vzťahy a prepojenia medzi nimi.
Norma poskytuje minimálnu potrebnú štruktúru na vybudovanie vzoru – kombinovanie práv do rolí a následné udeľovanie prístupu používateľom prostredníctvom týchto rolí. Načrtnuté sú mechanizmy skladania rolí z objektov a operácií, popísaná je hierarchia rolí a dedenie právomocí. Koniec koncov, v každej spoločnosti existujú úlohy, ktoré kombinujú základné právomoci, ktoré sú potrebné pre všetkých zamestnancov spoločnosti. Môže ísť o prístup k e-mailu, EDMS, firemnému portálu atď. Tieto povolenia možno zahrnúť do jednej všeobecnej roly nazývanej „zamestnanec“ a nebude potrebné znovu a znovu uvádzať všetky základné práva v každej z rolí vyššej úrovne. Stačí jednoducho uviesť dedičnú charakteristiku roly „zamestnanca“.
Neskôr bol štandard doplnený o nové prístupové atribúty súvisiace s neustále sa meniacim prostredím. Bola pridaná možnosť zaviesť statické a dynamické obmedzenia. Statické znamenajú nemožnosť kombinovania rolí (rovnaký vstup a kontrola operácií, ako je uvedené vyššie). Dynamické obmedzenia možno určiť zmenou parametrov, napríklad času (pracovný/nepracovný čas alebo dni), miesta (kancelária/domov) atď.
Samostatne by sa malo povedať o riadenie prístupu založené na atribútoch (ABAC – Attribute-based access control). Prístup je založený na udeľovaní prístupu pomocou pravidiel zdieľania atribútov. Tento model je možné použiť samostatne, ale pomerne často aktívne dopĺňa klasický model role: k určitej úlohe je možné pridať atribúty používateľov, zdrojov a zariadení, ako aj čas alebo miesto. To vám umožní používať menej rolí, zaviesť ďalšie obmedzenia a čo najmenej obmedziť prístup, a tým zlepšiť bezpečnosť.
Napríklad účtovníkovi možno povoliť prístup k účtom, ak pracuje v určitom regióne. Potom sa poloha špecialistu porovná s určitou referenčnou hodnotou. Alebo môžete poskytnúť prístup k účtom iba vtedy, ak sa používateľ prihlási zo zariadenia, ktoré je uvedené v zozname povolených. Dobrý doplnok k vzoru, ale zriedka sa používa samostatne kvôli potrebe vytvoriť veľa pravidiel a tabuliek povolení alebo obmedzení.
Dovoľte mi uviesť príklad používania ABAC z môjho „minulého života“. Naša banka mala niekoľko pobočiek. Zamestnanci klientskych kancelárií v týchto pobočkách vykonávali úplne rovnaké operácie, ale v hlavnom systéme museli pracovať len s účtami vo svojom regióne. Najprv sme začali vytvárať samostatné roly pre každý región – a takých rolí s opakujúcimi sa funkciami, ale s prístupom k rôznym účtom, bolo toľko! Potom sme použitím atribútu polohy pre používateľa a jeho priradením ku konkrétnemu rozsahu účtov na kontrolu výrazne znížili počet rolí v systéme. V dôsledku toho zostali úlohy len pre jednu pobočku, ktoré boli replikované na zodpovedajúce pozície vo všetkých ostatných teritoriálnych divíziách banky.
Teraz si povedzme o nevyhnutných prípravných krokoch, bez ktorých je jednoducho nemožné vybudovať fungujúci vzor.
Krok 1. Vytvorte funkčný model
Mali by ste začať vytvorením funkčného modelu – dokumentu najvyššej úrovne, ktorý podrobne popisuje funkčnosť každého oddelenia a každej pozície. Spravidla doň vstupujú informácie z rôznych dokumentov: náplne práce a predpisov pre jednotlivé útvary – oddelenia, divízie, oddelenia. Funkčný model musí byť dohodnutý so všetkými zainteresovanými útvarmi (obchod, vnútorná kontrola, bezpečnosť) a schválený vedením spoločnosti. Na čo slúži tento dokument? Aby sa naň vzor mohol odvolávať. Napríklad sa chystáte vybudovať model založený na existujúcich právach zamestnancov – vyňatých zo systému a „redukovaných na spoločného menovateľa“. Potom, keď sa dohodnete na prijatých rolách s obchodným vlastníkom systému, môžete sa odvolať na konkrétny bod vo funkčnom modeli, na základe ktorého je to alebo ono právo zahrnuté do roly.
Krok 2. Vykonávame audit IT systémov a zostavujeme plán priorít
V druhej fáze by ste mali vykonať audit IT systémov, aby ste pochopili, ako je organizovaný prístup k nim. Napríklad moja finančná spoločnosť prevádzkovala niekoľko stoviek informačných systémov. Všetky systémy mali nejaké základy správy založenej na rolách, väčšina mala nejaké roly, ale väčšinou na papieri alebo v systémovom adresári – boli dávno zastarané a prístup k nim bol udeľovaný na základe skutočných požiadaviek používateľov. Prirodzene, postaviť vzor v niekoľkých stovkách systémov naraz je jednoducho nemožné, niekde začať treba. Vykonali sme hĺbkovú analýzu procesu riadenia prístupu, aby sme určili jeho úroveň zrelosti. Počas procesu analýzy boli vyvinuté kritériá pre prioritizáciu informačných systémov - kritickosť, pripravenosť, plány vyraďovania atď. S ich pomocou sme nalinkovali vývoj/aktualizáciu vzorov pre tieto systémy. A potom sme zahrnuli vzory rolí do plánu integrácie s riešením Identity Management na automatizáciu riadenia prístupu.
Ako teda určíte kritickosť systému? Odpovedzte si na nasledujúce otázky:
- Je systém prepojený s prevádzkovými procesmi, od ktorých závisia hlavné činnosti spoločnosti?
- Ovplyvní narušenie systému integritu majetku spoločnosti?
- Aký je maximálny povolený prestoj systému, pri dosiahnutí ktorého nie je možné obnoviť činnosť po prerušení?
- Môže narušenie integrity informácií v systéme viesť k nezvratným následkom, finančným aj reputačným?
- Kritickosť voči podvodom. Prítomnosť funkčnosti, ak nie je riadne kontrolovaná, môže viesť k interným/externým podvodným akciám;
- Aké sú právne požiadavky a interné pravidlá a postupy pre tieto systémy? Budú za nedodržiavanie pravidiel hroziť pokuty od regulátorov?
V našej finančnej spoločnosti sme urobili takýto audit. Manažment vyvinul postup auditu Access Rights Review, aby sa najprv pozrel na existujúcich používateľov a práva v tých informačných systémoch, ktoré boli na zozname s najvyššou prioritou. Vlastníkom tohto procesu bolo poverené bezpečnostné oddelenie. Aby sme však získali úplný obraz o prístupových právach vo firme, bolo potrebné do procesu zapojiť IT a obchodné oddelenia. A tu sa začali spory, nedorozumenia a niekedy aj sabotáže: nikto sa nechce odtrhnúť od svojich doterajších povinností a zapojiť sa do nejakých na prvý pohľad nepochopiteľných činností.
NB Veľké spoločnosti s rozvinutými IT procesmi pravdepodobne poznajú postup IT auditu – IT všeobecné kontroly (ITGC), ktorý umožňuje identifikovať nedostatky v IT procesoch a zaviesť kontrolu tak, aby sa procesy zlepšovali v súlade s osvedčenými postupmi (ITIL, COBIT, IT Riadenie atď.) Takýto audit umožňuje IT a biznisu lepšie sa navzájom porozumieť a vytvoriť spoločnú stratégiu rozvoja, analyzovať riziká, optimalizovať náklady a vyvinúť efektívnejšie prístupy k práci.
Jednou z oblastí auditu je zisťovanie parametrov logického a fyzického prístupu k informačným systémom. Získané dáta sme brali ako základ pre ďalšie využitie pri budovaní vzoru. Výsledkom tohto auditu bol register IT systémov, v ktorom boli stanovené ich technické parametre a uvedený popis. Okrem toho bol pre každý systém identifikovaný vlastník z obchodného smeru, v záujme ktorého bol prevádzkovaný: bol to on, kto bol zodpovedný za obchodné procesy, ktorým tento systém slúžil. Bol vymenovaný aj manažér IT služieb, zodpovedný za technickú realizáciu obchodných potrieb pre konkrétny IS. Boli zaznamenané pre spoločnosť najkritickejšie systémy a ich technické parametre, termíny uvádzania do prevádzky a vyraďovania z prevádzky atď.. Tieto parametre boli veľmi nápomocné v procese prípravy na vytvorenie vzoru.
Krok 3 Vytvorte metodiku
Kľúčom k úspechu každého podnikania je správna metóda. Preto na vybudovanie vzoru a na vykonanie auditu musíme vytvoriť metodiku, v ktorej popíšeme interakciu medzi oddeleniami, stanovíme zodpovednosť v predpisoch spoločnosti atď.
Najprv musíte preskúmať všetky dostupné dokumenty, ktoré stanovujú postup udeľovania prístupu a práv. V dobrom zmysle by procesy mali byť zdokumentované na niekoľkých úrovniach:
- všeobecné firemné požiadavky;
- požiadavky na oblasti informačnej bezpečnosti (v závislosti od oblastí činnosti organizácie);
- požiadavky na technologické procesy (inštrukcie, prístupové matice, smernice, požiadavky na konfiguráciu).
V našej finančnej spoločnosti sme našli veľa neaktuálnych dokumentov, museli sme ich dať do súladu s novými zavádzanými procesmi.
Na základe príkazu vedenia bola vytvorená pracovná skupina, v ktorej boli zástupcovia z oblasti bezpečnosti, IT, obchodu a vnútornej kontroly. V rozkaze boli načrtnuté ciele vytvorenia skupiny, smer činnosti, obdobie existencie a zodpovední z každej strany. Okrem toho sme vyvinuli metodiku auditu a postup na zostavenie vzoru: odsúhlasili ich všetci zodpovední zástupcovia oblastí a schválilo ich vedenie spoločnosti.
Dokumenty popisujúce postup pri vykonávaní prác, termíny, zodpovednosti atď. - záruka, že na ceste k drahocennému cieľu, ktorý na začiatku nie je každému zrejmé, nikto nebude mať otázky „prečo to robíme, prečo to potrebujeme atď. a nebude tu možnosť „vyskočiť“ alebo spomaliť proces.
Krok 4. Opravte parametre existujúceho modelu riadenia prístupu
Vypracúvame takzvaný „systémový pas“ z hľadiska kontroly vstupu. V podstate ide o dotazník na konkrétnom informačnom systéme, ktorý eviduje všetky algoritmy na riadenie prístupu k nemu. Spoločnosti, ktoré už implementovali riešenia triedy IdM, takýto dotazník pravdepodobne poznajú, keďže tu začína výskum systémov.
Niektoré parametre o systéme a vlastníkoch prešli do dotazníka z IT registra (pozri krok 2, audit), ale boli pridané aj nové:
- ako sa spravujú účty (priamo v databáze alebo cez softvérové rozhrania);
- ako sa používatelia prihlasujú do systému (pomocou samostatného účtu alebo pomocou účtu AD, LDAP atď.);
- aké úrovne prístupu do systému sa používajú (úroveň aplikácie, systémová úroveň, systémové využitie zdrojov sieťových súborov);
- popis a parametre serverov, na ktorých systém beží;
- aké operácie správy účtu sú podporované (blokovanie, premenovanie atď.);
- aké algoritmy alebo pravidlá sa používajú na generovanie identifikátora používateľa systému;
- aký atribút možno použiť na vytvorenie spojenia so záznamom zamestnanca v personálnom systéme (celé meno, osobné číslo atď.);
- všetky možné atribúty účtu a pravidlá na ich vyplnenie;
- aké prístupové práva existujú v systéme (role, skupiny, atómové práva atď., či existujú vnorené alebo hierarchické práva);
- mechanizmy delenia prístupových práv (podľa pozície, oddelenia, funkcionality atď.);
- Má systém pravidlá pre segregáciu práv (SOD – Segregation of Duties) a ako fungujú?
- ako sa v systéme spracúvajú udalosti neprítomnosti, prestupu, prepúšťania, aktualizácie údajov zamestnancov a pod.
Tento zoznam môže pokračovať a podrobne uvádza rôzne parametre a ďalšie objekty, ktoré sú zahrnuté v procese riadenia prístupu.
Krok 5. Vytvorte obchodne orientovaný popis povolení
Ďalším dokumentom, ktorý budeme potrebovať pri budovaní vzoru, je referenčná kniha o všetkých možných právomociach (právach), ktoré môžu byť udelené používateľom v informačnom systéme s podrobným popisom obchodnej funkcie, ktorá za tým stojí. Orgány v systéme sú často zašifrované určitými názvami, ktoré pozostávajú z písmen a číslic, a obchodní zamestnanci nedokážu prísť na to, čo sa skrýva za týmito symbolmi. Potom idú do IT služby a tam... tiež nevedia odpovedať na otázku napríklad o zriedka používaných právach. Potom je potrebné vykonať dodatočné testovanie.
Je dobré, ak už existuje popis firmy alebo dokonca existuje kombinácia týchto práv do skupín a rolí. Pre niektoré aplikácie je osvedčeným postupom vytvoriť takúto referenciu vo fáze vývoja. Ale to sa nestáva často, takže opäť ideme na IT oddelenie, aby sme zhromaždili informácie o všetkých možných právach a popísali ich. Náš sprievodca bude nakoniec obsahovať nasledovné:
- názov orgánu vrátane objektu, na ktorý sa prístupové právo vzťahuje;
- úkon, ktorý je možné s objektom vykonať (prezeranie, zmena a pod., možnosť obmedzenia napr. podľa územného základu alebo podľa skupiny klientov);
- autorizačný kód (kód a názov systémovej funkcie/požiadavky, ktorú možno vykonať pomocou autorizácie);
- popis oprávnenia (podrobný popis úkonov v IS pri uplatňovaní oprávnenia a ich dôsledky pre proces;
- stav povolenia: „Aktívne“ (ak je povolenie pridelené aspoň jednému používateľovi) alebo „Neaktívne“ (ak sa povolenie nepoužíva).
6. krok Zo systémov stiahneme údaje o používateľoch a právach a porovnáme ich s personálnym zdrojom
V záverečnej fáze prípravy je potrebné stiahnuť údaje z informačných systémov o všetkých používateľoch a právach, ktoré momentálne majú. Tu sú možné dva scenáre. Po prvé: bezpečnostné oddelenie má priamy prístup do systému a má prostriedky na stiahnutie relevantných správ, čo sa nestáva často, ale je to veľmi pohodlné. Po druhé: do IT odošleme požiadavku na prijímanie správ v požadovanom formáte. Prax ukazuje, že dohodnúť sa s IT a získať potrebné údaje nie je možné hneď na prvýkrát. Je potrebné vykonať niekoľko prístupov, kým sa informácie nedostanú v požadovanej forme a formáte.
Aké údaje je potrebné stiahnuť:
- Názov účtu
- Celé meno zamestnanca, ktorému je pridelená
- Stav (aktívne alebo zablokované)
- Dátum vytvorenia účtu
- Dátum posledného použitia
- Zoznam dostupných práv/skupín/rolí
Zo systému sme teda dostali stiahnuté súbory so všetkými používateľmi a všetkými právami, ktoré im boli udelené. A okamžite odložili všetky zablokované účty, pretože práca na budovaní vzoru sa bude vykonávať iba pre aktívnych používateľov.
Potom, ak vaša spoločnosť nemá automatizované prostriedky na blokovanie prístupu prepusteným zamestnancom (často sa to stáva) alebo má patchwork automatizáciu, ktorá nie vždy funguje správne, musíte identifikovať všetky „mŕtve duše“. Hovoríme o účtoch zamestnancov, ktorí už dostali výpoveď, ktorých práva nie sú z nejakého dôvodu zablokované – treba ich zablokovať. Za týmto účelom porovnávame nahrané údaje s personálnym zdrojom. Personálne vyloženie je potrebné vopred získať aj na oddelení, ktoré vedie personálnu databázu.
Samostatne je potrebné vyčleniť účty, ktorých majitelia neboli nájdení v personálnej databáze, neboli nikomu pridelení – teda bez vlastníka. Pomocou tohto zoznamu budeme potrebovať dátum posledného použitia: ak je pomerne nedávny, stále budeme musieť hľadať vlastníkov. To môže zahŕňať účty externých dodávateľov alebo účty služieb, ktoré nie sú priradené nikomu, ale sú spojené s akýmikoľvek procesmi. Ak chcete zistiť, komu účty patria, môžete poslať listy všetkým oddeleniam a požiadať ich o odpoveď. Po nájdení vlastníkov zadáme do systému údaje o nich: týmto spôsobom sa identifikujú všetky aktívne účty a zvyšok sa zablokuje.
Hneď ako budú naše uploady vyčistené od nepotrebných záznamov a zostanú len aktívne účty, môžeme začať budovať vzor pre konkrétny informačný systém. Ale o tom vám poviem v ďalšom článku.
Autor: Lyudmila Sevastyanova, manažérka propagácie Solar inRights
Zdroj: hab.com