🥇Krijojmë një model roli për menaxhimin e aksesit. Pjesa e parë, përgatitore

Aktualisht po punoj në një kompani ofruese të softuerit, veçanërisht në zgjidhjet për menaxhimin e qasjes. Përvoja ime "nga jeta e kaluar" lidhet me anën e blerësit - një organizatë financiare të madhe. Atëherë, grupi ynë i kontrollit të qasjes në departamentin e sigurisë kibernetike nuk mund të krenoheshim me kompetenca të mëdha në IdM. Mësuam shumë gjatë procesit, na duhej të përballeshim me shumë sfida për të ndërtuar një mekanizëm funksional të menaxhimit të të drejtave të përdoruesve në sistemet informative të kompanisë.

Duke bashkuar përvojën time të fituar në anën e blerësit me njohuritë dhe kompetencat e ofruesit, dëshiroj të ndaj me ju një udhëzues hap pas hapi: si të krijoni një model rol për menaxhimin e qasjes në një kompani të madhe, dhe çfarë do të sjellë kjo në fund. Udhëzimi im përbëhet nga dy pjesë: pjesa e pare – përgatitemi për të ndërtuar modelin, e dyta – në të vërtetë e ndërtojmë. Para jush është pjesa e parë, përgatitore.

Shën. Ndërtimi i modelit të rolit – për fat të keq, nuk është një rezultat, por një proces. Në fakt, është edhe një pjesë e procesit të krijimit të një ekosistemi të menaxhimit të qasjes në kompani. Prandaj, përgatituni për një lojë afatgjatë.

Në fillim le të sqarojmë – çfarë është menaxhimi i aksesit të bazuar në role? Supozoni se keni një bankë të madhe me dhjetëra, madje edhe qindra mijëra punonjës (subjekte), secili prej të cilëve ka dhjetëra të drejta akses në qindra sisteme informacioni brenda bankës (objekte). Tani shumëzoni numrin e objekteve me numrin e subjekteve – aq shumë lidhje minimale duhet të krijoni e më pas të kontrolloni. A është e mundur ta bëni këtë manualisht? Sigurisht që jo – për zgjidhjen e kësaj sfide u krijuan rolet.

Rol është një grup fuqish që nevojitet për një përdorues ose grup përdoruesish për të përfunduar detyra të caktuara pune. Çdo punonjës mund të ketë një ose më shumë role, dhe çdo rol mund të përmbajë nga një deri në shumë fuqish, të cilat i janë lejuar përdoruesit brenda këtij roli. Rolis mund të lidhen me pozita të caktuara, departamente ose detyra funksionale të punonjësve.

Rolat zakonisht krijohen nga fuqitë e veçanta të punonjësve në çdo sistem informacioni. Më pas, nga rolet e secilit sistem formohen rolet globale të biznesit. për shembull, roli i biznesit "menaxher i kredisë" do të përfshijë disa role të veçanta në sistemet informacioni që përdoren në zyrën e klientëve të bankës. Le të themi, në sisteme të tilla si sistemi kryesor automatizuar bankar, moduli i arkës, sistemi i menaxhimit të dokumenteve elektronike, menaxheri i shërbimit dhe të tjerët. Rolat e biznesit, zakonisht, lidhen me strukturën organizative dhe të stafit – thjesht, me grupin e njësive të kompanisë dhe pozitat në to. Kështu formohet matrica globale e rolave (shembulli jepet në tabelën më poshtë).

Duhet theksuar se ndërtimi i një modeli roler 100% të plotë, duke siguruar të gjitha të drejtat e nevojshme për punonjësit e çdo pozite në një strukturë komerciale, është thjesht e pamundur. Madje, kjo as nuk është e nevojshme. Një model roler nuk mund të jetë statik, sepse varet nga mjedisi që ndryshon vazhdimisht. Gjithashtu, ndryshimet në aktivitetin e biznesit të kompanisë ndikojnë përkatësisht në ndryshimin e strukturës organizative dhe funksionalitetit. Mungesa e mbështetjes së plotë me burime, mosrespektimi i udhëzimeve të detyrës, dëshira për fitim në dëm të sigurisë dhe shumë faktorë të tjerë janë gjithashtu të rëndësishëm. Prandaj, duhet ndërtuar një model roler që mund të mbulojë deri në 80% të nevojave të përdoruesve për të drejtat bazike të nevojshme kur emërohen në një pozitë. Ndërsa 20% e tjera ata mund t'i kërkojnë më vonë nëpërmjet aplikimeve të veçanta, nëse është e nevojshme.

Sigurisht, mund të pyesni: “A ekzistojnë modele 100% rolesh?” Po, ka raste të tilla, për shembull, në organizatat jofitimprurëse që nuk përballen me ndryshime të shpeshta, si në ndonjë institut kërkues. Ose në organizatat e industrisë së mbrojtjes me nivel të lartë sigurie, ku siguria ka prioritet. Ka raste edhe në strukturat tregtare, por brenda një njësi specifike, ku puna është një proces mjaft statik dhe parashikues.

Avantazhi kryesor i menaxhimit të rolit është thjeshtimi i dhënies së të drejtave, pasi numri i roleve është ndjeshëm më i vogël se ai i përdoruesve të sistemit informatik. Kjo është e vërtetë për çdo sektor.

Le të marrim një kompani shitjesh me pakicë: në të punojnë mijëra shitës, por niveli i të drejtave në sistemin N është i njëjtë për ta, dhe për ta do të krijohet vetëm një rol. Nëse një shitës i ri hyn në kompani, automatikisht i caktohet roli i nevojshëm në sistem, ku tashmë janë të gjitha autoritetet e nevojshme. Gjithashtu, me një klik, mund të ndryshoni të drejtat për mijëra shitës njëherësh, për shembull, të shtoni një opsion të ri për krijimin e raportit. Nuk është nevoja të bëni mijëra operacione, duke lidhur të drejtat e reja me çdo llogari – mjafton të shtoni këtë opsion në rol, dhe ai do të shfaqet për të gjithë shitësit njëkohësisht.

Një përfitim tjetër i menaxhimit të rolit është përjashtimi i dhënies së autoriteteve të papajtueshme. Kjo do të thotë se punonjësi, i cili ka një rol të caktuar në sistem, nuk mund të ketë në të njëjtën kohë një rol tjetër, të cilat të drejtat e të cilit nuk duhet të përputhen me të drejtat e rolit të parë. Një shembull i qartë është ndalimi i kombinimit të funksioneve të futjes dhe kontrollit të operacioneve financiare.

Të gjithë ata që janë të interesuar se si ka lindur menaxhimi i rolit të qasjes, mund
të hedhin një vështrim në historinë e tij
Nëse i kthehemi historisë, IT-komuniteti filloi të mendojë për metodat e menaxhimit të aksesit që në vitet '70 të shekullit XX. Edhe pse aplikacionet ishin mjaft të thjeshta atëherë, ashtu si sot, gjithkush dëshironte një menaxhim të lehtë të aksesit në to. Të ofronte, të ndryshonte dhe të kontrollonte të drejtat e përdoruesve – thjesht për të kuptuar më lehtë se çfarë akses kanë secili prej tyre. Por në atë kohë nuk kishte asnjë standard të përbashkët, po zhvilloheshin sistemet e para të menaxhimit të aksesit, dhe çdo kompani bazohej në përfytyrimet dhe rregullat e saj.

Sot dihen shumë modele të ndryshme të menaxhimit të aksesit, por ato nuk appeared menjëherë. Le të ndalemi te ato që kanë kontribuar në mënyrë të ndjeshme në zhvillimin e kësaj fushe.

Modeli i parë dhe, ndoshta, më i thjeshti – Menaxhimi i aksesit diskrecion (selekto) (DAC – Kontroll i aksesit në formë diskrecionale). Ky model parashikon ndarjen e të drejtave ndërmjet të gjithë pjesëmarrësve në procesin e aksesit. Çdo përdorues merr qasje në objekte ose operacione të caktuara. Në thelb, këtu shumë subjekte të të drejtave korrespondojnë me shumë objekte. Ky model ishte njohur si shumë fleksibël dhe shumë kompleks për t'u mbajtur: listat e aksesit me kalimin e kohës bëhen të mëdha dhe të vështira për t'u kontrolluar.

Modeli i dytë është Kontrolli i obliguar i aksesit (MAC – Mandatory access control). Sipas këtij modeli, çdo përdorues merr qasje në një objekt në përputhje me lejen e dhënë për nivelin e caktuar të konfidencialitetit të të dhënave. Për pasojë, objektet duhet të kategorizohen sipas niveleve të konfidencialitetit. Ndryshe nga modeli i parë fleksibël, ky, përkundrazi, ka rezultuar të jetë shumë i ashpër dhe kufizues. Përdorimi i tij nuk justifikohet kur kompania ka shumë burime informacioni të ndryshme: për të ndarë qasjen në burime të ndryshme, do të duhet të krijohen shumë kategori që nuk do të mbivendosen.

Për shkak të papërsosmërisë evidente të këtyre dy metodave, komuniteti IT vazhdoi të zhvillonte modele më fleksibël dhe më përpjekësisht universale për të mbështetur lloje të ndryshme të politikave organizative për kontrollin e aksesit. Kështu lindi modeli i tretë i menaxhimit të aksesit të bazuar në role! Ky qasje u tregua më e suksesshme, pasi kërkon jo vetëm autentifikimin e identitetit të përdoruesit, por edhe funksionet e tij të punës në sisteme.

Struktura e parë e përshkruar qartë e modelit të roleve u propozua nga shkencëtarët amerikanë David Ferraiolo dhe Richard Kuhn nga Instituti Kombëtar i Standardeve dhe Teknologjisë i SHBA-së në vitin 1992. Atëherë u paraqit për herë të parë termi RBAC (Kontrolli i Aksesit të BAZUAR në ROLES). Këto studime dhe përshkrime të komponenteve themelore, si dhe ndërveprimi i tyre, përbënë bazën e standardit aktual INCITS 359-2012, miratuar nga Komiteti Ndërkombëtar për Standardet e Teknologjive të Informacionit (INCITS).

Standarti përcakton rolin si "një funksion detyrash brenda kontekstit të organizatës me një semantikë lidhur me fuqitë dhe përgjegjësitë e ngarkuara me përdoruesin e emëruar në rol". Dokumenti përcakton elementet kryesore të RBAC - përdoruesit, sesionet, rolet, lejet, operacionet dhe objektet, si dhe marrëdhëniet dhe lidhjet midis tyre.

Në standard jepet struktura minimale e nevojshme për ndërtimin e një modeli roli - bashkimi i të drejtave në role dhe pastaj dhënia e aksesit përdoruesve nëpërmjet këtyre roleve. Përcaktohen mekanizmat për ndërtimin e roleve nga objektet dhe operacionet, punohet mbi hierarkinë e roleve dhe trashëgiminë e fuqive. Në çdo kompani ka role që bashkojnë fuqitë elementare, të cilat janë të nevojshme për të gjithë punonjësit e kompanisë. Kjo mund të jetë akses në postën elektronike, në menaxhimin e dokumenteve, në portalin korporativ dhe kështu me radhë. Këto fuqira mund të përfshihen në një rol të përgjithshëm me emrin "punonjës", dhe nuk do të jetë e nevojshme të renditen të gjitha të drejtat elementare në çdo rol më të lartë, herë pas here. Mjafton të tregoni veçorinë e trashëgimisë së rolit "punonjës".

Më vonë, standardi u pasurua me atribute të reja aksesit, të lidhura me mjedisin në ndryshim të vazhdueshëm. U shtua mundësia për të vendosur kufizime statike dhe dinamike. Kufizimet statike nënkuptojnë pamundësinë e përputhjes së roleve (ajo hyrje dhe kontroll operacionesh, e përmendur më lart). Kufizimet dinamike mund të përcaktohen nga parametra që ndryshojnë, si për shembull, koha (orët ose ditët e punës / pushimit), vendndodhja (zyra / shtëpi) etj.

Në veçanti, duhet thënë për menaxhimin e aksesit të bazuar në atribute (ABAC — Attribute-based access control). Qasja ndërtohet mbi ofrimin e aksesit përmes rregullave të ndarjes së atributeve. Kjo modeli mund të përdoret veçmas, por shpesh e plotëson aktiv modelin klasik të rolit: për një rol të caktuar mund të shtohen atribute të përdoruesve, burimeve dhe pajisjeve, si dhe kohës ose vendndodhjes. Kjo lejon përdorimin e më pak roleve, vendosjen e kufizimeve shtesë dhe të sigurojë që aksesit të jetë minimalisht i mjaftueshëm, duke rritur kështu sigurinë.

Për shembull, një kontabilist mund t'i jepet akses në llogari nëse ai punon në një rajon të caktuar. Në këtë rast, pozita e specialistit do të krahasohet me një vlerë referimi të caktuar. Ose mund të jepet akses në llogari vetëm nëse përdoruesi autentikohet nga një pajisje e regjistruar në listën e atyre të lejuar. Një shtesë e mirë për modelin e rolit, por përdoret rrallë vetë për shkak të nevojës për të krijuar shumë rregulla dhe tabela të lejeve ose kufizimeve.

Do të jap një shembull të përdorimit të ABAC nga jeta ime e mëparshme. Në bankën tonë kishte disa degë. Punonjësit e zyrave të klientëve në këto dega kryenin operacione të njëjta, por duhej të punonin në sistemin kryesor vetëm me llogaritë e rajonit të tyre. Fillimisht, filluam të krijonim role të veçanta për çdo rajon – dhe numri i këtyre roleve me funksionalitet të përsëritur, por me akses në llogari të ndryshme, u bë vërtet shumë i madh! Atëherë, duke përdorur atributin e vendndodhjes për përdoruesin dhe duke e lidhur atë me një gamë specifike llogarish për verifikim, ne e reduktuam ndjeshëm numrin e roleve në sistem. Si rezultat, mbetën vetëm rolet për një degë, të cilat u kopjuan për pozitat përkatëse në të gjitha njësitë territoriale të tjera të bankës.

Tani le të flasim për hapat e nevojshëm përgatitorë, pa të cilët është thjesht e pamundur të ndërtohet një model rolësh funksional.

Hapi 1. Krijojmë modelin funksional

Duhet të filloni me krijimin e një modeli funksional – një dokument të nivelit të lartë, në të cilin përshkruhen në detaje funksionalitetet e çdo nëndivizioni dhe çdo pozite. Në përgjithësi, informacioni përmbushet nga dokumente të ndryshme: direktivat e punës dhe rregulloret për nëndivizione të veçanta – departamente, menaxhimente, drejtoritë. Modeli funksional duhet të miratohet nga të gjitha nëndivisionet e interesuara (biznesi, kontrolli të brendshëm, siguria) dhe të miratohet nga menaxhmenti i kompanisë. Për çfarë nevojitet ky dokument? Që modeli i rolëve të mund të referohet në të. Për shembull, nëse po planifikoni të ndërtoni një model roli mbi baza të të drejtave ekzistuese të punonjësve – të nxjerra nga sistemi dhe „të sjellë në një standard të përbashkët“. Atëherë, gjatë miratimit të rolëve të marra me pronarin e sistemit të biznesit, mund të referoheni në një pikë specifike të modelit funksional, mbi të cilin përfshihet një të drejtë e caktuar në rol.

Hapi 2. Auditojmë sistemet IT dhe hartojmë një plan për prioritetizimin

Në fazën e dytë, duhet të kryhet një auditim i sistemëve IT për të kuptuar si është organizuar qasja në to. Për shembull, në kompaninë time financiare, eksistuan disa qindra sisteme informative. Në të gjitha sistemet kishte disa elemente të menaxhimit të rolit, në shumicën e rasteve ndonjë rol, por kryesisht në letër ose në manualin e sistemit - ato ishin shumë të vjetra, dhe qasja në to u jepnin sipas kërkesave faktike të përdoruesve. Natyrisht, ndërtimi i një modeli roli menjëherë në disa qindra sisteme është thjesht e pamundur, duhet të fillohet nga diçka. Ne kryem një analizë të thellë të procesit të menaxhimit të qasjes për të përcaktuar nivelin e saj të pjekurisë. Gjatë analizës, zhvilluam kritere për priorizimin e sistemeve informative - kriticiteti, gatishmëria, planet për daljen nga funksionimi etj. Me ndihmën e tyre, organizuam renditjen për zhvillimin/aktualizimin e modeleve të rolit për këto sisteme. Pastaj, përfshimë modelet e rolit në planin për integrimin me zgjidhjen e Menaxhimit të Identitetit, për të automatizuar menaxhimin e qasjes.

Pra, si mund të përcaktoni kriticitetin e sistemit? Jepni vetes këto pyetje:

A është sistemi i lidhur me proceset operative, të cilat varen nga aktiviteti kryesor i kompanisë?
A do të ndikojë prishja e funksionimit të sistemit në integritetin e aseteve të kompanisë?
Cili është koha maksimale e pranueshme e ndalesës së sistemit, pas së cilës nuk është e mundur të rikthehet aktiviteti pas ndërprerjes?
A mund të prishja e integritetit të informacionit në sistem të sjellë pasoja të pakthyeshme, si financiare ashtu edhe reputacionale?
Kritikë ndaj mashtrimit. Prania e funksionalitetit, për të cilin, nën kontroll të pamjaftueshëm, është e mundur kryerja e veprimeve mashtruese të brendshme/jeshtme;
Cilat janë kërkesat ligjore, si dhe rregullat dhe procedurat e brendshme për këto sisteme? A do të ketë gjobita nga rregullatorët për mosrespektim?

Në kompaninë tonë financiare, ne e realizuam auditimin në këtë mënyrë. Menaxhmenti zhvilloi procedurën e Auditimit të Rregullave të Aksesit për të kuptuar përdoruesit ekzistues dhe të drejtat e tyre fillimisht në ato sisteme informative që ishin renditur si më prioritarët. Njësia e sigurisë u caktua si pronar i këtij procesi. Por për të marrë një pamje të plotë mbi të drejtat e aksesit në kompani, ishte e nevojshme që të përfshiheshin në proces njësitë e IT-së dhe biznesit. Dhe këtu filluan mosmarrëveshjet, keqkuptimet, madje dhe sabotimi: askush nuk dëshiron të largohet nga detyrat e tij aktuale dhe të angazhohet në aktivitete, që për të, duket se nuk kanë kuptim të qartë.

Shën. Kompani të mëdha me procese të zhvilluara IT-së, sigurisht që janë të njohura me procedurën e auditimit IT – IT general controls (ITGC), e cila lejon identifikimin e mangësive në proceset IT dhe vendosjen e kontrollit në mënyrë që të përmirësohet proceset në përputhje me praktikat më të mira (ITIL, COBIT, IT Governance etj.). Ky auditim lejon IT-në dhe biznesin të kuptojnë më mirë njëri-tjetrin dhe të zhvillojnë një strategji të përbashkët, të analizojnë rreziqet, të optimizojnë kostot dhe të krijojnë qasje më efikase në punë.

Një nga drejtimet e auditi është përcaktimi i parametrave të aksesit logjik dhe fizik në sistemet informatikë. Të dhënat e marra shërbyen si bazë për përdorim të mëtejshëm në ndërtimin e modelit të roli. Si rezultat i këtij auditi, ne krijuam një regjistër të sistemeve IT, ku u përcaktuan parametrat teknikë dhe u dhanë përshkrime. Për më tepër, për çdo sistem u caktua një pronar nga drejtimi biznesor, në të cilin ai ishte në funksion: ai ishte përgjegjës për proceset biznesore që ky sistem shërbente. Po ashtu, u emërua një menaxher i shërbimit IT, përgjegjës për zbatimin teknik të nevojave të biznesit në një IS të caktuar. U regjistruan sistemet më kritike për kompaninë dhe parametrat e tyre teknikë, afatet e kërkuara për aktivizim dhe çaktivizim, etj. Këta parametra ishin shumë të dobishëm në procesin e përgatitjes për ndërtimin e modelit të roli.

Hapi 3 Krijojmë metodologjinë

Çelësi i suksesit të çdo projekti është zgjedhja e saktë e metodës. Prandaj, për të ndërtuar një model rol dhe për të realizuar audite, na duhet të krijojmë një metodologji në të cilën do të përshkruajmë bashkëpunimin ndërmjet degëve, do të përcaktojmë përgjegjësitë në rregulloret e kompanisë etj.
Në fillim është e nevojshme të shqyrtojmë të gjithë dokumentet ekzistuese që përcaktojnë rregullat e dhënies së aksesit dhe të drejtave. Proceset duhet të dokumentohen në disa nivele:

kërkesat e përgjithshme korporative;
kërkesat për fushat e sigurisë së informacionit (varet nga drejtimet e veprimtarisë së organizatës);
kërkesat për proceset teknologjike (udhëzime, matricat e aksesit, orientimet metodologjike, kërkesat për konfiguracionet).

Në kompaninë tonë financiare, zbuluam shumë dokumente të vjetruara – duhej t'i sillnim ato në përputhje me proceset e reja që po implementonim.

Mezgji i krijuar nga drejtoria përfshin përfaqësues nga fushat e sigurisë, IT-it, biznesit dhe kontrollit të brendshëm. Në urdhrin e lëshuar janë përshkruar qëllimet e krijimit të grupit, drejtimi i veprimtarisë, periudha e ekzistencës dhe përgjegjësitë nga ana e çdo palë. Për më tepër, zhvilluam metodologjinë për zhvillimin e auditit dhe rendin e ndërtimit të modelit të rolit: ato u miratuan nga të gjithë përfaqësuesit përgjegjës të fushave dhe u miratua nga drejtoria e kompanisë.

Dokumentet që përshkruajnë rendin e ekzekutimit të punëve, afatet, përgjegjësinë etj. janë një garanci që në rrugën drejt qëllimit të shenjtë, i cili në fillim nuk është i qartë për të gjithë, askush nuk do të ketë pyetje «pse po e bëjmë këtë, për çfarë na nevojitet etj.» dhe nuk do të ketë mundësi të «shkëputet» ose të ngadalësojë procesin.

Hapi 4. Regjistrojmë parametrat e modelit ekzistues të menaxhimit të aksesit

Krijojmë atë që quhet "pasaporta e sistemit" në lidhje me menaxhimin e aksesit. Në thelb, kjo është një pyetësor për një sistem informacioni të caktuar, në të cilin janë regjistruar të gjitha algoritmet e menaxhimit të aksesit në të. Kompanitë që tashmë kanë implementuar zgjidhje të klasës IdM do të jenë patjetër të njohura me një pyetësor të tillë, pasi pikërisht nga ai fillon hulumtimi i sistemeve.

Pjesa e parametrave mbi sistemin dhe pronarët e tij ka kaluar në pyetësor nga regjistri IT (shih hapin 2, auditimi), por janë shtuar edhe të rinj:

si realizohet menaxhimi i llogarive (drejtë në DB apo përmes ndërfaqeve programore);
si hyjnë përdoruesit në sistem (nëpërmjet një llogarie të veçantë ose duke përdorur llogarinë AD, LDAP ose të tjera);
çfarë nivelesh aksesit në sistem përdoren (niveli i aplikacionit, niveli sistemor, përdorimi i burimeve të skedarëve në rrjet nga sistemi);
përshkrimi dhe parametrat servera, mbi të cilat funksionon sistemi;
cilat operacione mbi menaxhimin e llogarive mbështeten (bllokimi, rinamingu etj.);
sipas cilëve algoritmave ose rregullave formohet identifikuesi i përdoruesit në sistem;
me cilin atribut mund të vendoset lidhja me regjistrimin e punonjësit në sistemin kadrovik (Emri dhe mbiemri, numri i tabelës ose diçka tjetër);
të gjitha atributet e mundshme të regjistrimit dhe rregullat e plotësimit të tyre;
çfarë të drejtash accessi ekzistojnë në sistem (rolet, grupet, të drejtat atomike etj., a ka të drejta të ngulitura ose hierarkike);
mekanizmat e ndarjes së të drejtave të aksesit (sipërmarrjet, departamentet, funksionaliteti etj.);
a ka në sistem rregulla ndarjeje të të drejtave (SOD – Segregation of Duties), dhe si funksionojnë ato;
si trajtohen në sistem ngjarjet e mungesës, transferimit, shkarkimit, përditësimit të të dhënave për punonjësit etj.;

Mund të vazhdojmë këtë listë me detaje për parametra të ndryshëm dhe objekte të tjera që janë të përfshira në procesin e menaxhimit të aksesit.

Hapi 5. Krijoni një përshkrim të orientuar ndaj biznesit për autorizimet

Një dokument tjetër që do na nevojitet për ndërtimin e modelit të rolit është një manual për të gjitha mundësitë (të drejtave) që mund të jepen përdoruesve në sistemin informacioni me një përshkrim të detajuar të funksionit biznesor që qëndron pas tij. Shpesh, të drejtat në sistem janë të koduara me emra të caktuar, të përbërë nga letra dhe numra, dhe punonjësit e biznesit nuk janë në gjendje të kuptojnë çfarë fshihen pas këtyre simboleve. Atëherë ata shkojnë në shërbimin IT, dhe atje… as nuk mund të përgjigjen në pyetje, për shembull, për të drejtat që përdoren rrallë. Atëherë duhet të kryhen teste të tjera.

Është mirë nëse përshkrimi biznesor tashmë ekziston ose madje ka një bashkim të këtyre të drejtave në grupe dhe role. Për disa aplikacione, praktika më e mirë është krijimi i një manuali të tillë edhe në fazën e zhvillimit të tyre. Por kjo ndodh rrallë, prandaj sërish shkojmë në seksionin IT për të grumbulluar informacion mbi të gjitha të drejtat e mundshme dhe për t'i përshkruar ato. Manuali ynë do të përmbajë në fund:

emri i të drejtës, duke përfshirë objektin për të cilin aplikohet e drejta e aksesit;
veprimi që lejohet të bëhet me objektin (shikimi, modifikimi etj., mundësia e kufizimit, për shembull, sipas vendndodhjes ose grupit të klientëve);
kodi i autorizimit (kodi dhe emri i funksionit/pyetjes së sistemit që mund të ekzekutohet duke përdorur autorizimin);
përshkrimi i autorizimit (përshkrimi i detajuar i veprimeve në IS gjatë përdorimit të autorizimit dhe pasojat e tyre për procesin;
statusi i autorizimit: "Aktiv" (nëse autorizimi është caktuar të paktën një përdoruesi) ose "Jo aktiv" (nëse autorizimi nuk përdoret).

Hapi 6 Nxjerrim nga sistemet të dhënat në lidhje me përdoruesit dhe të drejtat dhe i përputhim me burimin e punës

Në fazën përfundimtare të përgatitjes, nevojitet të eksportohen të dhënat nga sistemet informative për të gjithë përdoruesit dhe të drejtat që ata kanë në këtë moment. Këtu ka dy skenarë të mundshëm. Skenari i parë: njësi e sigurisë ka qasje direkte në sistem dhe ka mjete për të eksportuar raportet përkatëse, gjë që ndodh rrallë, por është shumë e përshtatshme. Skenari i dytë: dërgojmë një kërkesë në IT për të marrë raportet në formatin e nevojshëm. Praktika tregon: negociatat me IT-në dhe marrja e të dhënave të nevojshme herën e parë nuk arrijnë të realizohen. Duhet të bëjmë disa përpjekje derisa informacioni të merret në formën dhe formatin e nevojshëm.

Cilat të dhëna nevojiten për eksportim:

Emri i llogarisë
Emri dhe mbiemri i punonjësit, për të cilën është e lidhur
Statusi (aktive ose e bllokuar)
Data e krijimit të llogarisë
Data e përdorimit të fundit
Lista e të drejtave/grupeve/rolit të disponueshëm

Pra, ne kemi marrë eksportet nga sistemi me të gjithë përdoruesit dhe me të gjitha të drejtat që u janë dhënë atyre. Dhe menjëherë kemi lënë në anë të gjitha llogaritë e bllokuara, pasi puna për ndërtimin e modelit të rolit do të bëhet vetëm me përdoruesit aktivë.

Më pas, nëse në kompaninë tuaj nuk ka mjete automatizimi për mbylljen e aksesit për punonjësit e larguar (kjo ndodh shpesh) ose nëse ka një automatizim patchwork, i cili nuk funksionon gjithmonë siç duhet, është e nevojshme të identifikoni të gjitha "shpirtrat e vdekur". Këtu flasim për llogaritë e punonjësve të larguar, të drejtat e të cilëve për një arsye ose tjetër nuk janë bllokuar – ato duhet të bllokohen. Për këtë, do të krahasojmë të dhënat e ngarkuara me burimin e të dhënave të punonjësve. Shkarkimi i të dhënave të punonjësve gjithashtu duhet të merret paraprakisht nga një divizion që menaxhon bazën e të dhënave të punonjësve.

Është e nevojshme të ndahen llogaritë, pronarët e të cilave nuk janë gjetur në bazën e të dhënave të punonjësve, që nuk janë lidhur me askënd, - pra, llogaritë pa pronar. Për këtë listë do të na nevojitet data e përdorimit të fundit: nëse ajo është mjaft e freskët, do të duhet të kërkojmë pronarët. Këtu mund të përfshihen llogaritë e kontraktorëve të jashtëm apo llogaritë e shërbimit, që nuk janë lidhur me askënd, por që lidhen me procese të caktuara. Për të sqaruar përkatësinë e llogarive, mund të dërgojmë letra në të gjitha degët me kërkesën që të përgjigjen. Kur të gjenden pronarët, do të fusim të dhënat e tyre në sistem: kështu të gjitha llogaritë aktive do të identifikohen dhe të tjerat do të bllokohen.

Sa më shpejt që eksportet tona janë pastruar nga regjistrat e panevojshëm dhe kanë mbetur vetëm llogaritë aktive, mund të fillojmë ndërtimin e modelit të rolit për sistemin informacion. Por për këtë do të flas më në artikullin tjetër.

Autor: Lyudmila Sevastyanova, menaxhere për promovimin e Solar inRights

Burimi: habr.com