Vytvárame rolu modelu správy prístupu. Časť prvá, prípravná

Momentálne pracujem vo softvérovom dodávateľovi, konkrétne na riešeniach pre správu prístupu. Môj predchádzajúci skúsenosť je zo strany objednávateľa – veľkej finančnej organizácie. Vtedy naša skupina pre kontrolu prístupu v oddelení informačnej bezpečnosti nemohla poskytnúť veľké odborné znalosti v IdM. Počas procesu sme sa mnohému učili, museli sme prejsť veľa ťažkostí, aby sme vybudovali vo firme funkčný mechanizmus správy práv používateľov v informačných systémoch.

Spojením svojich cenných skúseností z pozície objednávateľa s dodávateľskými znalosťami a kompetenciami sa chcem s vami podeliť o praktický návod: ako v veľkej firme vytvoriť model správy prístupu na základe rolí a čo to prinesie. Môj návod pozostáva z dvoch častí: prvá – pripravujeme sa na vytvorenie modelu, druhá – samotné vytvorenie. Pred vami je prvá časť, prípravná.

N.B. Budovanie modelu rolí nie je, žiaľ, výsledok, ale proces. Presnejšie povedané, je to časť procesu vytvárania v spoločnosti ekosystému správy prístupu. Tak sa pripravte na dlhodobú hru.

Najprv si vyjasníme – čo presne je správa prístupu na základe rolí? Predpokladajme, že máte veľkú banku s desiatkami, ba aj stovkami tisíc zamestnancov (subjektov), z ktorých každý má desiatky práv prístupu do stovky vnútorných informačných systémov (objektov). A teraz vynásobte počet objektov číslom subjektov – presne toľko vzťahov musíte najprv vybudovať a potom kontrolovať. Dá sa to urobiť ručne? Samozrejme, že nie – práve na tento účel vznikli role.

Rola je súbor oprávnení, ktoré používateľovi alebo skupine používateľov umožňujú vykonávať konkrétne pracovné úlohy. Každý zamestnanec môže mať jednu alebo viac rolí a každá rola môže obsahovať od jedného po mnoho oprávnení, ktoré sú používateľovi povolené v rámci tejto roly. Roly môžu byť priradené k určitým pozíciám, oddeleniam alebo funkčným úlohám zamestnancov.

Roly sa zvyčajne vytvárajú z osobitných oprávnení zamestnanca v každom informačnom systéme. Následne sa z rolí každej sústavy formujú globálne podnikové roly. Napríklad podniková rola „kreditný manažér“ bude zahŕňať niekoľko samostatných rolí v informačných systémoch, ktoré sa používajú v klientskom kancelárii banky. Povedzme, v systémoch, ako sú hlavný automatizovaný bankový systém, pokladničný modul, systém elektronického spracovania dokumentov, servisný manažér a ďalšie. Podnikové roly sú spravidla viazané na organizačnú a pracovnú štruktúru – jednoducho povedané, na súbor oddelení firmy a pozícií v nich. Takto sa vytvára globálna rolová matica (príklad uvádzam v tabuľke nižšie).

Je potrebné poznamenať, že vybudovať 100% rolový model, ktorý zabezpečí všetkými potrebnými právami zamestnancov každej pozície v komerčnej štruktúre, je jednoducho nemožné. A ani to nie je potrebné. Veď rolový model nemôže byť statický, pretože závisí od neustále sa meniacich podmienok. A od zmeny podnikovej činnosti spoločnosti, čo logicky ovplyvňuje zmenu organizácie a funkcie. A od absencie úplného zabezpečenia prostriedkami, a od nedodržiavania pracovných predpisov, a od snahy o zisk na úkor bezpečnosti, a od mnohých ďalších faktorov. Preto je potrebné vytvoriť rolový model, ktorý dokáže pokryť až 80% potrieb používateľov v potrebných základných právach pri vymenovaní na pozíciu. A tých ostatných 20% si môžu v prípade potreby dodatočne žiadať neskôr prostredníctvom samostatných žiadostí.

Samozrejme, môžete sa opýtať: „A čo, nie sú predsa 100% rolové modely?“ No prečo nie, také sa vyskytujú, napríklad, v neziskových štruktúrach, ktoré nie sú náchylné na časté zmeny – v nejakom výskumnom ústave. Alebo v organizáciách obranného priemyslu s vysokou úrovňou zabezpečenia, kde je bezpečnosť na prvom mieste. Stáva sa to aj v komerčnej štruktúre, ale v rámci konkrétneho oddelenia, ktorého práca predstavuje dostatočne statický a predvídateľný proces.

Hlavná výhoda rolového riadenia spočíva v zjednodušení správy oprávnení, pretože množstvo rolí je podstatne menšie ako počet používateľov informačného systému. A to platí pre akékoľvek odvetvie.

Zoberme si maloobchodnú spoločnosť: pracuje v nej tisíce predajcov, ale v systéme N majú rovnaký súbor práv a pre nich bude vytvorená iba jedna rola. Keď do spoločnosti príde nový predajca, automaticky mu je priradená potrebná rola v systéme, v ktorom už sú všetky potrebné oprávnenia. Takisto jedným kliknutím môžete zmeniť práva pre tisíce predajcov naraz, napríklad pridať novú možnosť na vytváranie reportov. Nie je potrebné vykonávať tisíc operácií a viazať nové právo na každý záznam – stačí pridať túto možnosť do roly a tá sa objaví u všetkých predajcov súčasne.

Ďalšou výhodou rolového riadenia je vylúčenie priradenia nekompatibilných oprávnení. To znamená, že zamestnanec s určitou rolou v systéme nemôže mať súčasne inú rolu, ktorých práva by sa nemali kombinovať s právami v prvej. Príkladom je zákaz kombinácie funkcií zadávania a kontroly finančnej operácie.

Všetci, ktorých zaujíma, ako vlastne vzniklo rolové riadenie prístupu, môžu
sa ponoriť do exkurzu do histórie
Ak sa pozrieme do histórie, IT komunita sa prvýkrát zamyslela nad metódami riadenia prístupu už v 70. rokoch XX. storočia. Aj keď boli aplikácie vtedy pomerne jednoduché, všetci by chceli pohodlne riadiť prístup k nim. Poskytovať, meniť a kontrolovať práva používateľov – len aby bolo ľahšie pochopiť, aký prístup má každý z nich. Ale vtedy neexistovali žiadne spoločné štandardy, vyvíjali sa prvé systémy riadenia prístupu a každá spoločnosť sa zakladala na svojich vlastných predstavách a pravidlách.

Dnes už poznáme mnoho rôznych modelov riadenia prístupu, ale neprišlo to okamžite. Zastavme sa pri tých, ktoré prispeli k rozvoju tohto smeru.

Prvý a pravdepodobne najjednoduchší model – Diskrétny (vyberateľný) prístupový systém (DAC – Discretionary access control). Tento model predpokladá zdieľanie práv všetkými účastníkmi procesu prístupu. Každý používateľ má prístup k konkrétnym objektom alebo operáciám. V podstate tu množstvo subjektov práv zodpovedá množstvu objektov. Tento model bol uznaný za príliš flexibilný a príliš zložitý na údržbu: zoznamy prístupu sa v priebehu času stávajú obrovskými a ťažko kontrolovateľnými.

Druhý model – to je Mandátne riadenie prístupu (MAC — Mandatory access control). Podľa tohto modelu každý používateľ získa prístup k objektu v súlade s udeleným oprávnením na určitú úroveň dôvernosti údajov. Zodpovedajúce objekty musia byť kategorizované podľa úrovne dôvernosti. Na rozdiel od prvého flexibilného modelu sa tento ukázal ako príliš prísny a obmedzujúci. Jeho uplatnenie nie je opodstatnené, keď má spoločnosť množstvo rôznych informačných zdrojov: na to, aby sa rozlišoval prístup k rôznym zdrojom, bude potrebné zaviesť množstvo kategórií, ktoré sa nebudú prekrývať.

V súvislosti s očividnými nedostatkami týchto dvoch metód IT komunita pokračovala vo vývoji modelov, ktoré sú flexibilnejšie a viac-menej univerzálne na podporu rôznych typov organizačných politík riadenia prístupu. A práve vtedy sa objavil tretí model riadenia prístupu na základe rolí! Tento prístup sa ukázal ako najperspektívnejší, pretože vyžaduje nielen autorizáciu identity používateľa, ale aj jeho pracovných funkcií v systémoch.

Prvú jasne popísanú štruktúru modelu rolí navrhli americkí vedci David Ferraiolo a Richard Kuhn z Národného inštitútu štandardov a technológií USA v roku 1992. Vtedy sa prvýkrát objavil termín RBAC (Role-based access control). Tieto výskumy a opisy základných komponentov, ako aj ich vzájomné vzťahy, sa stali základom aktuálneho štandardu INCITS 359-2012, schváleného Medzinárodným výborom pre štandardy informačných technológií (INCITS).

Štandard definuje rolu ako „pracovnú funkciu v kontexte organizácie s určitými súvisiacimi významami vo vzťahu k právomociam a zodpovednostiam priradeným používateľovi, ktorému bola rola pridelená“. Dokument stanové základné prvky RBAC – používatelia, relácie, roly, povolenia, operácie a objekty, ako aj vzťahy a súvislosti medzi nimi.

Štandard poskytuje minimálnu potrebnú štruktúru pre vytvorenie rolového modelu – zjednotenie práv do rolí a následné poskytovanie prístupu používateľom prostredníctvom týchto rolí. Označujú sa mechanizmy zostavovania rolí z objektov a operácií, opisuje sa hierarchia rolí a dedičstvo právomocí. V každej firme existujú roly, ktoré kombinujú základné práva, ktoré sú potrebné všetkým zamestnancom. Môže to byť prístup k e-mailu, k EAD, k firemnému portálu a pod. Tieto práva môžu byť zahrnuté do jednej spoločnej role s názvom „zamestnanec“, a nie je potrebné v každej z rolí vyššej úrovne opakovane uvádzať všetky základné práva. Stačí jednoducho uviesť znak dedičstva role „zamestnanec“.

Neskôr bol štandard doplnený o nové atribúty prístupu, súvisiace s neustále sa meniacim prostredím. Pridala sa možnosť zavedenia statických a dynamických obmedzení. Statické predpokladajú nemožnosť kombinovania rolí (ten istý vstup a kontrola operácií, spomínaná vyššie). Dynamické obmedzenia môžu byť určované meniacimi sa parametrami, ako napríklad časom (pracovné/nepracovné hodiny alebo dni), lokalizáciou (kancelária/dom) a pod.

Samostatne treba uviesť riadenie prístupu na základe atribútov (ABAC — Attribute-based access control). Prístup je založený na poskytovaní prístupu pomocou pravidiel zdieľania atribútov. Tento model môže byť používaný samostatne, ale často aktívne dopĺňa klasický rolový model: k určitej role je možné pridať atribúty používateľov, zdrojov a zariadení, ako aj času alebo lokalizácie. To umožňuje použiť menej rolí, zavádzať dodatočné obmedzenia a sprístupniť prístup minimálne potrebným spôsobom, a tým zvýšiť bezpečnosť.

Napríklad, účtovníkovi môže byť povolený prístup k účtom, ak pracuje v určitej oblasti. Potom sa poloha špecialistu porovná s určenou referenčnou hodnotou. Alebo môže byť prístup k účtom povolený len v prípade, že sa používateľ autorizuje z zariadenia, ktoré je zahrnuté v zozname povolených. Dobrý doplnok k rolenému modelu, ale sám sa používa zriedkavo kvôli nutnosti vytvárať množstvo pravidiel a tabuliek oprávnení alebo obmedzení.

Uvediem príklad aplikácie ABAC z môjho „predchádzajúceho života“. V našej banke boli niekoľko pobočiek. Zamestnanci klientskych kancelárií v týchto pobočkách vykonávali úplne rovnaké operácie, ale museli pracovať v hlavnom systéme len s účtami svojho regiónu. Najprv sme začali vytvárať samostatné role pre každý región – a týchto rolí s opakujúcou sa funkčnosťou, ale s prístupom k rôznym účtom sa nakoniec stalo naozaj veľmi veľa! Potom, pomocou atribútu polohy pre používateľa a jeho prepojením so špecifickým rozsahom účtov na kontrolu, sme výrazne znížili počet rolí v systéme. Nakoniec zostali role len pre jednu pobočku, ktoré sa duplicovali na príslušné pozície vo všetkých ostatných územných jednotkách banky.

A teraz sa porozprávajme o potrebných prípravných krokoch, bez ktorých jednoducho nie je možné vybudovať fungujúci rolený model.

Krok 1. Vytvárame funkčný model

Začať treba vytvorením funkčného modelu – vyššej úrovne dokumentu, v ktorom sú podrobne opísané funkcie každého oddelenia a každej pozície. Zvyčajne sa informácie do neho získavajú z rôznych dokumentov: pracovných inštrukcií a predpisov pre jednotlivé oddelenia – na oddelenia, správy, odbory. Funkčný model musí byť schválený všetkými zainteresovanými oddeleniami (biznis, interný dohľad, bezpečnosť) a schválený vedením spoločnosti. Na čo je tento dokument potrebný? Aby sa rolový model mohol na neho odvolávať. Napríklad, plánujete vytvoriť rolový model na základe už existujúcich práv zamestnancov – exportovaných zo systému a "prispôsobených jednotnému formátu". Potom pri schvaľovaní získaných rolí s vlastníkom systému môže byť citované konkrétne ustanovenie funkčného modelu, na základe ktorého sú do role zahrnuté rôzne práva.

Krok 2. Auditujeme IT systémy a zostavujeme plán priorizácie

V druhom kroku by sa mal uskutočniť audit IT systémov, aby sa zistilo, ako je organizovaný prístup do nich. Napríklad, v mojej finančnej spoločnosti bolo prevádzkovaných niekoľko sto informačných systémov. Vo všetkých systémoch existovali určité základy rolového manažmentu, väčšina z nich mala nejaké role, ale väčšinou na papieri alebo v adresári systému – tie už boli dávno zastarané, a prístup do nich bol udelený na základe samotných žiadostí používateľov. Samozrejme, vybudovanie rolového modelu naraz v niekoľkých stotinách systémov je jednoducho nemožné, treba začať niekde. Urobili sme hĺbkovú analýzu procesu správy prístupu, aby sme určili úroveň jeho zrelosti. Počas analýzy sme vypracovali kritériá prioritizácie informačných systémov – kritickosť, pripravenosť, plány na vyradenie z prevádzky a podobne. S ich pomocou sme usporiadali poradie vývoja/aktualizácie rolových modelov pre tieto systémy. A potom sme zapojili rolové modely do plánu integrácie s riešením Identity Management, aby sme automatizovali správu prístupu.

Takže, ako určiť kritickosť systému? Odpovedzte si na nasledujúce otázky:

• Je systém spojený s operačnými procesmi, od ktorých závisí hlavná činnosť spoločnosti?
• Bude mať porucha systému vplyv na integritu aktív firmy?
• Aký je maximálne prijateľný čas výpadku systému, po ktorom už nie je možné obnoviť činnosť po prerušenia?
• Môže porušenie integrity informácií v systéme viesť k nezvratným následkom, ako finančným, tak reputačným?
• Kritickosť voči podvodom. Existencia funkcie, pri nedostatočnej kontrole ktorej, môže dôjsť k uskutočneniu vnútorných/vonkajších podvodných činností;
• Aké sú požiadavky legislatívy, ako aj vnútorné pravidlá a postupy týchto systémov? Budú pokuty zo strany regulátorov za nedodržanie?

Vo svojej finančnej spoločnosti sme vykonali audit takto. Vedúci vypracoval procedúru auditu Review Práv Prístupu, aby sa vysporiadal so existujúcimi používateľmi a právami najprv v tých informačných systémoch, ktoré sa dostali na zoznam najprioritnejších. Majiteľom tohoto procesu bolo určené bezpečnostné oddelenie. Avšak na získanie celkového prehľadu o prístupových právach v spoločnosti bolo potrebné zapojiť do procesu aj oddelenia IT a biznisu. A tu začali spory, nedorozumenia, a niekedy aj sabotáž: nikto sa nechce odpútať od svojich súčasných povinností a zapájať sa do akýchsi, na prvý pohľad, nejasných aktivít.

N.B. Veľké spoločnosti s rozvinutými IT procesmi sú určite oboznámené s procedúrou IT auditu – IT general controls (ITGC), ktorá umožňuje odhaliť nedostatky v IT procesoch a nastaviť kontrolu tak, aby zlepšila procesy v súlade s best practice (ITIL, COBIT, IT Governance a pod.) Takýto audit umožňuje IT a biznisu lepšie si rozumieť a vypracovať spoločnú stratégiu rozvoja, analyzovať riziká, optimalizovať náklady, vypracovať efektívnejšie prístupy v práci.



Jedným z aspektov auditu je určenie parametrov logického a fyzického prístupu k informačným systémom. Získané údaje sme vzali ako základ pre ďalšie využitie pri budovaní rolového modelu. V dôsledku tohto auditu sme vytvorili registr IT systémov, v ktorom boli stanovené ich technické parametre a poskytnuté popisy. Navyše, pre každý systém bol určený vlastník z obchodného smerovania, v záujme ktorého bol prevádzkovaný: ten bol zodpovedný za obchodné procesy, ktoré tento systém obsluhoval. Bolo tiež menované oddelenie IT, zodpovedné za technickú realizáciu potrieb podnikania v konkrétnom IS. Boli zaznamenané najkritickejšie systémy pre spoločnosť a ich technické parametre, termíny uvedenia a vyradenia z prevádzky a ďalšie. Tieto parametre veľmi pomohli v procese prípravy na budovanie rolového modelu.

Krok 3 Vytvárame metodológiu

Kľúčom k úspechu akéhokoľvek projektu je správne zvolená metóda. Preto je dôležité vytvoriť metodológiu pre budovanie rolového modelu a realizáciu auditu, v ktorej opíšeme interakciu medzi oddeleniami, potvrdíme zodpovednosť v predpisoch spoločnosti a pod.
Na začiatok je potrebné preskúmať všetky existujúce dokumenty, ktoré stanovujú poriadok poskytovania prístupu a práv. V ideálnom prípade by mali byť procesy zdokumentované na niekoľkých úrovniach:

• všeobecné korporátne požiadavky;
• požiadavky na oblasti informačnej bezpečnosti (závisia od smerov činnosti organizácie);
• požiadavky na technologické procesy (návody, prístupové matice, metodické pokyny, požiadavky na konfigurácie).

Vo svojej finančnej spoločnosti sme objavili množstvo zastaraných dokumentov – museli sme ich prispôsobiť novým procesom, ktoré zavádzame.

Na príkaz vedenia bola vytvorená práca skupina, do ktorej sa zapojili zástupcovia oblastí bezpečnosti, IT, podnikania a interného kontroly. V príkaze boli určené ciele vytvorenia skupiny, smer činnosti, doba existencie a zodpovední z každej strany. Okrem toho sme vypracovali metodológiu vykonávania auditu a postup vytvorenia rolovej modelu: schválili ich všetci zodpovední zástupcovia oblastí a schválilo vedenie spoločnosti.

Dokumenty, ktoré opisujú postup vykonávania prác, termíny, zodpovednosti atď. – zárukou toho, že na ceste k vytúženej cieľ, ktorý na začiatku nie je všetkým zrejmý, nikto nebude mať otázky „na čo to robíme, prečo nám to je potrebné a pod.“ a nebude možnosť „vymaniť sa“ alebo spomaliť proces.

Krok 4. Zaznamenávame parametre existujúceho modelu riadenia prístupu

Pripravujeme takzvaný „pasport systému“ v oblasti riadenia prístupu. V podstate ide o dotazník pre konkrétny informačný systém, v ktorom sú zaznamenané všetky algoritmy riadenia prístupu k nemu. Spoločnosti, ktoré už zaviedli riešenia triedy IdM, sú s podobným dotazníkom určite oboznámené, pretože práve týmto sa začína skúmanie systémov.

Časť parametrov o systéme a vlastníkoch prešla do dotazníka z registra IT (pozri krok 2, audit), no pridali sa aj nové:

• ako je riadenie používateľských účtov uskutočňované (priamo v DB alebo prostredníctvom programových rozhraní);
• ako sa používatelia prihlasujú do systému (s pomocou samostatného účtu alebo pri použití účtu AD, LDAP a pod.);
• aké úrovne prístupu k systému sa používajú (úroveň aplikácie, systémová úroveň, využívanie sieťových súborových zdrojov systémom);
• popis a parametre serverov, na ktorých systém pracuje;
• aké operácie pri správe používateľských účtov sú podporované (blokovanie, premenovanie atď.);
• akými algoritmami alebo pravidlami sa formuje identifikátor používateľa systému;
• podľa ktorého atribútu je možné ustanoviť spojenie s záznamom o zamestnancovi v personálnom systéme (Meno, číslo zamestnanca a pod.);
• všetky možné atribúty používateľského účtu a pravidlá ich vypĺňania;
• aké práva prístupu existujú v systéme (role, skupiny, atomárne práva atď., existujú vnorené alebo hierarchické práva);
• mechanizmy delenia prístupových práv (podľa pozícií, oddelení, funkcií atď.);
• existujú v systéme pravidlá na rozdelenie práv (SOD – Segregácia povinností), a ako fungujú;
• ako sa v systéme spracovávajú udalosti absencie, presunu, prepustenia, aktualizácie údajov o zamestnancoch a pod.

Tento zoznam môžeme pokračovať s podrobnosťami podľa rôznych parametrov a ďalších objektov, ktoré sa podieľajú na procese správy prístupu.

Krok 5. Vytvárame podnikovo orientovaný popis právomocí

Ďalší dokument, ktorý budeme potrebovať pri výstavbe rolového modelu, je zoznam všetkých možných právomocí (práv), ktoré môžeme poskytnúť používateľom v informačnom systéme s podrobným popisom obchodnej funkcie, ktorá za tým stojí. Práva sú často v systéme zakódované určitými názvami, ktoré pozostávajú z písmen a číslic, a zamestnanci podnikania nemôžu rozlúštiť, čo sa za týmito symbolmi skrýva. Potom prichádzajú do IT služieb, kde... tiež nemôžu odpovedať na otázku, napríklad o málo používaných právach. Potom sa musí robiť dodatočné testovanie.

Dobré je, ak podnikový popis už existuje alebo je dokonca zoskupenie týchto práv do skupín a rolí. Pre niektoré aplikácie je najlepšou praxou vytvoriť podobný zoznam už v etape ich vývoja. Ale to sa nestáva často, takže opäť ideme do IT oddelenia, aby sme zhromaždili informácie o všetkých možných právach a popisali ich. Náš zoznam nakoniec bude obsahovať nasledujúce:

• názov právomoci, vrátane objektu, na ktorý sa aplikuje právo prístupu;
• činnosť, ktorú je povolené vykonávať s objektom (prehľadávanie, zmena atď., možnosť obmedzenia, napríklad podľa územného hľadiska alebo podľa skupiny klientov);
• kód právomoci (kód a názov funkcie/pýtania systému, ktoré môžeme vykonať s využitím právomoci);
• popis právomoci (podrobný opis činností v IS pri aplikovaní právomoci a ich následkov pre proces;
• stav právomoci: 'Aktívne' (ak je právomoc priradená aspoň jednému používateľovi) alebo 'Neaktívne' (ak sa právomoc nepoužíva).

Krok 6 Exportujeme z systémov údaje o používateľoch a právach a porovnávame ich so zdrojom zamestnancov.

Na záverečnej fáze prípravy je potrebné exportovať údaje z informačných systémov o všetkých používateľoch a právach, ktoré v súčasnosti majú. Existujú dva možné scenáre. Prvý: bezpečnostné oddelenie má priamy prístup do systému a prostriedky na exportovanie príslušných správ, čo nie je často, ale je to veľmi výhodné. Druhý: posielame žiadosť IT oddeleniu o získanie správ v požadovanom formáte. Prax ukazuje: dohodnúť sa s IT a získať potrebné údaje na prvýkrát sa zvyčajne nepodarí. Je potrebné vykonať niekoľko pokusov, kým sa informácie získa v požadovanej forme a formáte.

Aké údaje je potrebné exportovať:

• Názov účtu
• Meno a priezvisko zamestnanca, ktorej je priradené
• Stav (aktívne alebo zablokované)
• Dátum vytvorenia účtu
• Dátum posledného použitia
• Zoznam dostupných práv/skupín/rolí

Takže sme dostali exporty zo systému so všetkými používateľmi a so všetkými právami, ktoré im boli poskytnuté. A okamžite sme odložili všetky zablokované účty, pretože pracovná činnosť na vytvorení modelu rolí bude prebiehať iba pre aktívnych používateľov.

Potom, ak vaša spoločnosť nemá automatizované prostriedky na zablokovanie prístupu zamestnancom, ktorí odišli (čo sa často vyskytuje), alebo ak je tu súhrnná automatizácia, ktorá nie vždy správne funguje, je potrebné identifikovať všetky "mŕtve duše". Ide o účty už odídených zamestnancov, ktorých práva z nejakého dôvodu neboli zablokované – tie je potrebné zablokovať. Na to porovnáme exportované údaje s personálnym zdrojom. Personálny export je tiež potrebné najskôr získať od oddelenia, ktoré vedie personálnu databázu.

Osobitne je potrebné oddeliť konto, ktorých vlastníkov sa nepodarilo nájsť v personálnej databáze, ktoré nie sú pridelené nikomu, teda sú bez vlastníka. K tomuto zoznamu budeme potrebovať dátum posledného použitia: ak je celkom čerstvý, bude potrebné hľadať vlastníkov. Môžu sem patriť účty externých dodávateľov alebo služobné účty, ktoré nie sú pridelené nikomu, ale sú spojené s nejakými procesmi. Na zistenie vlastníctva účtov môžeme rozoslať e-maily všetkým oddeleniam s prosbou o odpoveď. Keď sa vlastníci nájdu, zaznamenáme údaje o nich do systému: takto budú všetky aktívne účty identifikované, a ostatné zablokujeme.

Akonáhle sú naše exporty vyčistené od zbytočných záznamov a zostali len aktívne účty, môžeme pristúpiť k vytvoreniu rolového modelu pre konkrétny informačný systém. O tom už však poviem v nasledujúcom článku.

Autor: Ľudmila Sevaťjanová, manažérka propagácie Solar inRights

Zdroj: habr.com