Aktualisht po punoj në një kompani ofrues shërbimesh software, veçanërisht në zgjidhje për menaxhimin e aksesit. Përvoja ime "nga jeta e kaluar" është e lidhur me anën e klientit - një organizatë të madhe financiare. Atëherë, grupi ynë për kontrollin e aksesit në departamentin e sigurisë informative nuk mund të mburrej me kompetenca të mëdha në IdM. Ne mësuam shumë gjatë këtij procesi, duhej të kalonim nëpër një sasi të madhe provash që të ndihmonim në ndërtimin e një mekanizmi funksional të menaxhimit të të drejtave të përdoruesve në sistemet informative.
Duke bashkuar përvojën time të fituar me shumë mundim si klient me njohuritë dhe kompetencat e ofruesve, dëshiroj të ndaj me ju një udhëzim në thelb hap pas hapi: si të krijoni një model të menaxhimit të aksesit të bazuar në role në një kompani të madhe, dhe çfarë do të sjellë kjo në fund. Udhëzimi im përbëhet nga dy pjesë: e para - përgatitemi për të ndërtuar modelin, e dyta - ndërtimi i vetë modelit. Këtu është pjesa e parë, përgatitore.
Shënim: Ndërtimi i modelit të rolit - ndodh fatkeqësisht, nuk është një rezultat, por një proces. Më saktë, madje një pjesë e procesit të krijimit të një ekosistemi të menaxhimit të aksesit në kompani. Pra, përgatituni për një lojë afatgjatë.
Së pari, le të sqarojmë - çfarë është menaxhimi i aksesit të bazuar në role? Supozoni se keni një bankë të madhe me dhjetëra, madje qindra mijëra punonjës (subjekte), secili prej të cilëve ka dhjetëra të drejta akses në qindra sisteme informative bankare (objekte). Tani, shumëzoni numrin e objekteve me numrin e subjekteve - ashtu si kaq marrëdhënie minimale duhet të ndërtoni fillimisht dhe pastaj të kontrolloni. A është e mundur ta bëni këtë manualisht? Sigurisht që jo - për të zgjidhur këtë problem janë krijuar rolet.
Rol - Ă«shtĂ« njĂ« grup fuqish qĂ« nevojiten pĂ«r njĂ« pĂ«rdorues ose grup pĂ«rdoruesish pĂ«r tĂ« kryer 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Ă« fuqi, qĂ« i janĂ« lejuar pĂ«rdoruesit brenda kĂ«tij roli. Rolet mund tĂ« jenĂ« tĂ« lidhura me pozita tĂ« caktuara, departamente ose detyra funksionale tĂ« punonjĂ«sve.
Rollet zakonisht krijohen nga tĂ« drejtat individuale tĂ« punonjĂ«sve nĂ« çdo sistem informacioni. MĂ« pas, nga rolet e çdo sistemi formohen rolet globale tĂ« biznesit. PĂ«r shembull, roli biznesor 'menaxher krediti' do tĂ« pĂ«rfshijĂ« disa role tĂ« veçanta nĂ« sistemet informacioni tĂ« cilat pĂ«rdoren nĂ« zyrĂ«n e klientit tĂ« bankĂ«s. TĂ« themi, nĂ« sisteme si sistemi kryesor i bankĂ«s automatizuar, moduli i kasĂ«s, sistemi i menaxhimit tĂ« dokumenteve elektronike, menaxheri i shĂ«rbimeve dhe tĂ« tjerĂ«. Rolet e biznesit zakonisht lidhen me strukturĂ«n organizative - thĂ«nĂ« ndryshe, me grupin e departamenteve tĂ« kompanisĂ« dhe pozitat nĂ« to. Ădo kategori formon njĂ« matricĂ« globale rolesh (shembullin e jap nĂ« tabelĂ«n mĂ« poshtĂ«).
Duhet theksuar se ndĂ«rtimi i njĂ« modeli 100% tĂ« rolit, duke siguruar tĂ« gjitha tĂ« drejtat e nevojshme pĂ«r punonjĂ«sit e çdo pozite nĂ« njĂ« strukturĂ« tregtare, Ă«shtĂ« thjesht i pamundur. Ashtu siç nuk Ă«shtĂ« e nevojshme. Sepse modeli i rolit nuk mund tĂ« jetĂ« statik, pasi ai varet nga mjedisi qĂ« ndryshon vazhdimisht. Dhe nga ndryshimi i veprimtarisĂ« biznesore tĂ« kompanisĂ«, e cila pĂ«r pasojĂ« ndikon nĂ« ndryshimin e strukturĂ«s organizative dhe funksionalitetit. Dhe nga mungesa e sigurimit tĂ« plotĂ« me burime, dhe nga mosrespektimi i udhĂ«zimeve tĂ« punĂ«s, dhe nga dĂ«shira pĂ«r fitim nĂ« dĂ«m tĂ« sigurisĂ«, dhe nga shumĂ« faktorĂ« tĂ« tjerĂ«. Prandaj, duhet ndĂ«rtuar njĂ« model roli qĂ« mund tĂ« mbulojĂ« deri nĂ« 80% tĂ« nevojave tĂ« pĂ«rdoruesve pĂ«r tĂ« drejtat bazike tĂ« nevojshme kur emĂ«rohen nĂ« pozita. NdĂ«rsa 20% tĂ« tjerat ata mund tâi kĂ«rkojnĂ« mĂ« vonĂ« me kĂ«rkesa tĂ« veçanta, nĂ«se Ă«shtĂ« e nevojshme.
Sigurisht, mund tĂ« pyesni: 'A nuk ka fare modele 100% tĂ« rolit?' Pse jo, ndodhin, pĂ«r shembull, nĂ« struktura jo fitimprurĂ«se, tĂ« cilat nuk janĂ« tĂ« prekur nga ndryshime tĂ« shpeshta, â nĂ« ndonjĂ« institut kĂ«rkues. Ose nĂ« organizata tĂ« kompleksit industrial ushtarak me njĂ« nivel tĂ« lartĂ« mbrojtjeje, ku siguria Ă«shtĂ« prioritet. Po ashtu ndodhin edhe nĂ« struktura tregtare, por brenda njĂ« departamenti tĂ« veçantĂ«, puna e tĂ« cilit Ă«shtĂ« njĂ« proces mjaft statik dhe parashikues.
Pika kryesore e menaxhimit të rolit është thjeshtimi i ndarjes së të drejtave, sepse numri i rolëve është ndjeshëm më i vogël se sa numri i përdoruesve të sistemit informacionit. Kjo është e vërtetë për çdo industri.
Merrni njĂ« kompani shitjesh me pakicĂ«: aty punojnĂ« mijĂ«ra shitĂ«s, por grupi i tĂ« drejtave nĂ« sistemin N Ă«shtĂ« i njĂ«jtĂ« pĂ«r ta, dhe pĂ«r ta do tĂ« krijohet njĂ« rol i vetĂ«m. Kur vjen njĂ« shitĂ«s i ri nĂ« kompani, automatikisht i jepet roli i nevojshĂ«m nĂ« sistem, ku tashmĂ« janĂ« tĂ« gjitha kompetencat e nevojshme. NjĂ«soj, 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 raporteve. Nuk Ă«shtĂ« e nevojshme tĂ« bĂ«ni mijĂ«ra operacione, duke lidhur tĂ« drejtat e reja me çdo llogari â mjafton tĂ« shtoni kĂ«tĂ« opsion nĂ« rol, dhe ajo do tĂ« shfaqet pĂ«r tĂ« gjithĂ« shitĂ«sit nĂ« tĂ« njĂ«jtĂ«n kohĂ«.
Një tjetër avantazh i menaxhimit të rolit është përjashtimi i dhënies së të drejtave të papajtueshme. Domethënë, punonjësi që ka një rol të caktuar në sistem, nuk mund të ketë një rol tjetër njëkohësisht, të drejtat e të cilit nuk duhet të përkasin me të drejtat në rolin e parë. Një shembull i qartë është ndalimi i përzierjes së funksioneve të hyrjes dhe kontrollit të operacioneve financiare.
Të gjithë ata që janë të interesuar, si lindi menaxhimi i rolit të qasjes, mund
të bëjnë një zhytje në histori
NĂ«se i referohemi historisĂ«, pĂ«r herĂ« tĂ« parĂ« komuniteti IT filloi tĂ« mendojĂ« pĂ«r metodat e menaxhimit tĂ« qasjes qĂ« nĂ« vitet 70 tĂ« shekullit tĂ« 20. Edhe pse aplikacionet ishin atĂ«herĂ« mjaft tĂ« thjeshta, siç Ă«shtĂ« tani, tĂ« gjithĂ« dĂ«shironin tĂ« menaxhonin lehtĂ«sisht qasjen ndaj tyre. TĂ« ofronin, ndryshonin dhe kontrollonin tĂ« drejtat e pĂ«rdoruesve â thjesht pĂ«r tĂ« qenĂ« mĂ« e thjeshtĂ« pĂ«r tĂ« kuptuar se cila qasje kishte secili prej tyre. Por nĂ« atĂ« kohĂ« nuk kishte standarde tĂ« pĂ«rbashkĂ«ta, po zhvilloheshin sistemet e para tĂ« menaxhimit tĂ« qasjes, dhe çdo kompani bazohej nĂ« pĂ«rfytyrimet dhe rregullat e saj tĂ« veta.
Tani dihen shumë modele të ndryshme menaxhimi të qasjes, por ato nuk u shfaqën menjëherë. Le të ndalemi te ato që dhanë një kontribut të dukshëm në zhvillimin e këtij drejtimi.
Modeli i parĂ« dhe ndoshta mĂ« i thjeshtĂ« Ă«shtĂ« Menaxhimi diskrecional (zgjedhor) i qasjes (DAC â Kontrolli i aksesit tĂ« diskrecionit). Ky model supozon ndarjen e tĂ« drejtave nga tĂ« gjithĂ« pjesĂ«marrĂ«sit e procesit tĂ« aksesit. Ădo pĂ«rdorues merr qasje nĂ« objekte ose operacione tĂ« caktuara. NĂ« thelb, kĂ«tu shumĂ« subjekte tĂ« tĂ« drejtave korrespondon me shumĂ« objekte. Ky model u shpall shumĂ« fleksibĂ«l dhe shumĂ« i komplikuar pĂ«r t'u mbajtur: listat e aksesit me kalimin e kohĂ«s bĂ«hen gjigante dhe tĂ« vĂ«shtira pĂ«r t'u kontrolluar.
Modeli i dytĂ« Ă«shtĂ« Kontrolli i detyrueshĂ«m i aksesit (MAC â Kontrolli i detyrueshĂ«m i aksesit). Sipas kĂ«tij modeli, çdo pĂ«rdorues merr qasje nĂ« njĂ« objekt nĂ« pĂ«rputhje me lejen e dhĂ«nĂ« pĂ«r njĂ« nivel tĂ« caktuar tĂ« confidencialitetit tĂ« tĂ« dhĂ«nave. NĂ« pĂ«rputhje, objektet duhet tĂ« klasifikohen sipas nivelit tĂ« confidencialitetit. NĂ« ndryshim nga modeli i parĂ« mĂ« fleksibĂ«l, ky Ă«shtĂ« shumĂ« i rreptĂ« dhe kufizues. PĂ«rdorimi i tij nuk justifikohet kur njĂ« kompani ka shumĂ« burime informative tĂ« ndryshme: pĂ«r tĂ« ndarĂ« qasjen nĂ« burime tĂ« ndryshme, do tĂ« nevojitet tĂ« krijohen shumĂ« kategori qĂ« nuk do tĂ« pĂ«rputhen.
Në lidhje me përshtatshmërinë e dukshme të këtyre dy metodave, komuniteti IT vazhdoi zhvillimin e modeleve më fleksibël dhe më universale për të mbështetur lloje të ndryshme politikat organizative të kontrollit të aksesit. Dhe kështu lindi modeli i tretë i menaxhimit të aksesit të bazuar në role! Ky qasje u tregua më premtuese, pasi ai kërkon jo vetëm autorizimin e identitetit të përdoruesit, por edhe funksionet e tij të punës në sisteme.
Strukturën e parë të përshkruar qartë të modelit të rolit e propozuan shkencëtarët amerikanë Devid Ferrajllo dhe Richard Kun nga Instituti Kombëtar i Standardeve dhe Teknologjisë të SHBA-së në vitin 1992. Atëherë u shfaq për herë të parë termi RBAC (Kontrolli i aksesit të bazuar në role). Këto hulumtime dhe përshkrimet e komponenteve kryesore si dhe marrëdhëniet e tyre shërbyen si bazë për standardin aktual INCITS 359-2012, të miratuar nga Komiteti Ndërkombëtar për Standardet e Teknologjisë së Informacionit (INCITS).
Standardi definon rolin si "njĂ« funksion nĂ« kontekstin e organizatĂ«s me njĂ« semantikĂ« tĂ« lidhur nĂ« lidhje me kompetencat 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.
Standardi jep strukturĂ«n minimale tĂ« nevojshme pĂ«r ndĂ«rtimin e modelit tĂ« rolit â bashkimin e tĂ« drejtave nĂ« role dhe pastaj dhĂ«nien e aksesit pĂ«rdoruesve pĂ«rmes kĂ«tyre roleve. PĂ«rcaktohen mekanizmat e krijimit tĂ« roleve nga objektet dhe operacionet, dhe pĂ«rshkruhen hierarkia e roleve dhe trashĂ«gimia e kompetencave. NĂ« çdo kompani ekzistojnĂ« role qĂ« bashkojnĂ« kompetencat elementare, tĂ« cilat janĂ« tĂ« nevojshme pĂ«r tĂ« gjithĂ« punonjĂ«sit e kompanisĂ«. Kjo mund tĂ« jetĂ« aksesi nĂ« email, nĂ« SED, nĂ« portalin e kompanisĂ« etj. KĂ«to kompetenca mund tĂ« pĂ«rfshihen nĂ« njĂ« rol tĂ« pĂ«rbashkĂ«t tĂ« quajtur "punonjĂ«s", dhe nuk do tĂ« nevojitet tĂ« pĂ«rmenden tĂ« gjitha tĂ« drejtat elementare repetitivisht nĂ« çdo rol mĂ« tĂ« lartĂ«. Mjafton tĂ« thuhet thjesht se roli "punonjĂ«s" trashĂ«gohet.
Më vonë, standardi u plotësua me atribute të reja të aksesit të lidhura me ambientin që ndryshon vazhdimisht. U shtua mundësia për futjen e kufizimeve statike dhe dinamike. Kufizimet statike nënkuptojnë pamundësinë e kombinimit të roleve (ky është futja dhe kontrolli i operacioneve të përmendura më sipër). Kufizimet dinamike mund të përcaktohen nga parametra që ndryshojnë, për shembull, koha (orët e punës/jo të punës ose ditët), vendndodhja (zyra/shtëpi) etj.
Veçmas është e rëndësishme të përmendim menaxhimin e aksesit të bazuar në atribute (ABAC - Attribute-based access control). Qasja ndërttohet mbi ofrimin e aksesit përmes rregullave të ndarjes së atributeve. Ky model mund të përdoret veçmas, por shpesh plotëson aktivisht 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 sigurimin e një accessi minimal të nevojshëm, dhe, për pasojë, rritjen e sigurisë.
Për shembull, një kontabilist mund t'i jepet akses në llogaritë nëse punon në një rajon të caktuar. Atëherë vendndodhja e specialistit do të krahasohet me një vlerë referuese të caktuar. Ose mund të jepet akses në llogaritë vetëm nëse përdoruesi autentikohet nga një aparat i regjistruar në listën e pajisjeve të lejuara. Një shtesë e mirë për modelin e roleve, por nuk përdoret shpesh nga vetë natyra e nevojës për të krijuar shumë rregulla dhe tabela lejesh ose kufizimesh.
TĂ« jap njĂ« shembull tĂ« pĂ«rdorimit tĂ« ABAC nga jeta ime e "shkurtĂ«r". NĂ« bankĂ«n tonĂ« kishte disa degĂ«. PunonjĂ«sit e zyrave pĂ«r klientĂ« nĂ« kĂ«to degĂ« realizonin operacione krejt 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 kaq shumĂ« role me funksionalitet tĂ« pĂ«rsĂ«ritur dhe me akses nĂ« llogari tĂ« ndryshme rezultuan qĂ« kishim shumĂ« me tĂ« vĂ«rtetĂ«! PĂ«rshtatur duke pĂ«rdorur atributin e vendndodhjes pĂ«r pĂ«rdoruesit dhe duke e lidhur atĂ« me njĂ« gamĂ« tĂ« caktuar llogarish pĂ«r verifikim, reduktuam ndjeshĂ«m numrin e roleve nĂ« sistem. Si rezultat, mbetĂ«n vetĂ«m role pĂ«r njĂ« degĂ«, tĂ« cilat u kopjuan pĂ«rpozitat pĂ«rkatĂ«se nĂ« tĂ« gjitha degĂ«t e tjera territoriale tĂ« bankĂ«s.
Tani le të flasim për hapat përgatitorë të nevojshëm, pa të cilët është thjesht e pamundur të ndërtohet një model funksional roli.
Hapi 1. Krijojmë një model funksional
Sfillimi duhet tĂ« nisĂ« me krijimin e njĂ« modeli funksional â njĂ« dokumenti tĂ« nivelit tĂ« lartĂ« qĂ« pĂ«rshkruan detyrat e çdo njĂ«sie dhe çdo pozite. PĂ«rgjithĂ«sisht, informacioni nĂ« tĂ« pĂ«rfitohet nga dokumente tĂ« ndryshme: udhĂ«zime pozite dhe rregullore pĂ«r njĂ«sitĂ« e veçanta â departamentet, menaxhmet, departamentet. Modeli funksional duhet tĂ« jetĂ« nĂ« pĂ«rputhje me tĂ« gjitha njĂ«sitĂ« e interesuara (biznesi, kontrolli internal, sigurimi) dhe i miratuar nga drejtoria e kompanisĂ«. PĂ«r çfarĂ« Ă«shtĂ« ky dokument? NĂ« mĂ«nyrĂ« qĂ« modeli i rolit tĂ« mund tĂ« referohet nĂ« tĂ«. PĂ«r shembull, nĂ«se do tĂ« ndĂ«rtosh njĂ« model roli mbi bazĂ«n e tĂ« drejtave ekzistuese tĂ« punonjĂ«sve â tĂ« nxjerra nga sistemi dhe "tĂ« sjella nĂ« njĂ« standard tĂ« vetĂ«m". AtĂ«herĂ«, gjatĂ« miratimit tĂ« rolave tĂ« marra me pronarin e sistemit mund tĂ« referoheni nĂ« pikĂ«n specifike tĂ« modelit funksional, mbi tĂ« cilin pĂ«rfshihet ajo ose kjo e drejte nĂ« rol.
Hapi 2. Auditojmë sistemet IT dhe përgatitim një plan prioritetizimi
NĂ« fazĂ«n e dytĂ« duhet tĂ« bĂ«het njĂ« auditi i sistemeve IT, pĂ«r tĂ« kuptuar si Ă«shtĂ« organizuar aksesimi nĂ« to. PĂ«r shembull, nĂ« kompaninĂ« time financiare ishin nĂ« pĂ«rdorim disa qindra sisteme informacioni. NĂ« tĂ« gjitha sistemet kishte disa elemente tĂ« menaxhimit tĂ« rolit, nĂ« shumicĂ«n â disa role, por kryesisht nĂ« letĂ«r ose nĂ« manualin e sistemit â ato kishin kohĂ« qĂ« ishin tĂ« pĂ«rmbushura dhe aksesimi nĂ« to ishte ndarĂ« sipas kĂ«rkesave reale tĂ« pĂ«rdoruesve. Natyrisht, ndĂ«rtimi i njĂ« modeli roli menjĂ«herĂ« nĂ« disa qindra sisteme Ă«shtĂ« thjesht i pamundur, duhet tĂ« fillojmĂ« nga diçka. Ne bĂ«mĂ« njĂ« analizĂ« tĂ« thelluar tĂ« procesit tĂ« menaxhimit tĂ« aksesit, pĂ«r tĂ« pĂ«rcaktuar nivelin e tij tĂ« pjekurisĂ«. GjatĂ« analizĂ«s zhvilluam kritere pĂ«r prioritetizimin e sistemeve informacioni â kriticiteti, gatishmĂ«ria, planet pĂ«r çaktivizim etj. Me ndihmĂ«n e tyre vendosĂ«m rendin pĂ«r zhvillimin/aktualizimin e modeleve tĂ« rolit pĂ«r kĂ«to sisteme. PĂ«r mĂ« tepĂ«r, pĂ«rfshimĂ« modelet e rolit nĂ« planin pĂ«r integrimin me zgjidhjen e Menaxhimit tĂ« Identitetit, pĂ«r tĂ« automatizuar menaxhimin e aksesit.
Pra, si ta përcaktojmë kriticitetin e sistemit? Jepni vetes këto pyetje:
- A është sistemi i lidhur me proceset operacionale, nga të cilat varet aktiviteti kryesor i kompanisë?
- A dobish li shkelja e funksionimit të sistemit në integritetin e aseteve të kompanisë?
- Cila është koha maksimale e pranueshme e ndërprerjes së sistemit, pas së cilës është e pamundur të rikuperohet aktiviteti?
- A mund të çojë shkelja e integritetit të informacionit në sistem në pasoja të pakthyeshme, si financiare, ashtu edhe reputacionale?
- Kritikë ndaj mashtrimit. Prania e funksionalitetit, për të cilin, nëse nuk kontrollohet mjaftueshëm, është e mundur të kryhen veprime mashtruese të brendshme/ekstreme;
- Cilat janë kërkesat e legjislacionit, si dhe rregullat dhe procedurat e brendshme për këto sisteme? A do të ketë ndëshkime nga autoritetet rregullatore për mosrespektimin?
Në kompaninë tonë financiare kemi kryer një auditim siç e thashë. Menaxhmenti zhvilloi një procedurë auditimi të Rishikimit të të Drejtave të Qasjes, për të bërë një pasqyrë mbi përdoruesit ekzistues dhe të drejtat e tyre fillimisht në ato sisteme informacioni që ishin në listën e përparësive më të larta. Njësia e sigurisë u emërua si pronar i këtij procesi. Por për të marrë një pamje të plotë të të drejtave të qasjes në kompani, ishte e nevojshme të përfshiheshin në procesin e njësitë e IT dhe biznesit. Dhe këtu filluan mosmarrëveshjet, keqkuptimet, dhe ndonjëherë edhe sabotimi: askush nuk do të dëshirojë të largohet nga detyrat e tij aktuale dhe të angazhohet në aktivitete që, në shikim të parë, duken të paqarta.
ShĂ«nim: Kompani tĂ« mĂ«dha me procese tĂ« zhvilluara IT sigurisht qĂ« janĂ« tĂ« njohura me procedurĂ«n e auditimit IT â kontrolli i pĂ«rgjithshĂ«m IT (ITGC), i cili lejon identifikimin e mangĂ«sive nĂ« proceset IT dhe vendosjen e kontrollit nĂ« mĂ«nyrĂ« qĂ« tĂ« pĂ«rmirĂ«sojnĂ« 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Ă« zhvillojnĂ« qasje mĂ« efektive nĂ« punĂ«.
Një nga drejtimet e auditi është përcaktimi i parametrave të aksesit logjik dhe fizik në sistemet informatike. Të dhënat e marra i kemi përdorur si bazë për përdorim të mëtejshëm në ndërtimin e modelit të rolit. Si rezultat i këtij auditi, ne morëm një regjistër të sistemeve IT, ku u përcaktuan parametrat e tyre teknikë dhe u dhanë përshkrime. Për më tepër, për çdo sistem u caktua një pronar nga drejtimi biznesor, në interes të të cilit funksiononte: pikërisht ai ishte përgjegjës për proceset biznesore që ky sistem shërbente. Gjithashtu, u emërua një menaxher i shërbimit IT, përgjegjës për realizimin teknik të nevojave të biznesit në një IS specifike. U regjistruan sistemet më kritike për kompaninë dhe parametrat e tyre teknikë, afatet për futjen dhe heqjen nga funksionimi etj. Këta parametra ndihmuan shumë në procesin e përgatitjes për ndërtimin e modelit të rolit.
Hapi 3 Krijojmë metodologjinë
ĂelĂ«si i suksesit tĂ« çdo pune Ă«shtĂ« metoda e duhur. Prandaj, pĂ«r ndĂ«rtimin e modelit tĂ« rolit dhe pĂ«r kryerjen e auditit, na nevojitet tĂ« krijojmĂ« njĂ« metodologji, nĂ« tĂ« cilĂ«n do tĂ« pĂ«rshkruajmĂ« ndĂ«rveprimin ndĂ«rmjet njĂ«si, do tĂ« pĂ«rcaktojmĂ« pĂ«rgjegjĂ«sitĂ« nĂ« rregulloret e kompanisĂ« etj.
Për të filluar, është e nevojshme të shqyrtojmë të gjitha dokumentet që përcaktojnë rendin e ofrimit të të drejtave dhe qasjes. Në term të mirë, proceset duhet të jenë të dokumentuara në disa nivele:
- kërkesat e përgjithshme korporative;
- kërkesat për fushat e sigurisë së informacionit (varet nga drejtimet e aktivitetit të organizatës);
- kërkesat për proceset teknologjike (udhëzime, matricat e aksesit, orientimet metodologjike, kërkesat për konfigurimet).
NĂ« kompaninĂ« tonĂ« financiare, zbuluam shumĂ« dokumente tĂ« vjetruara â u detyruam t'i sjellim ato nĂ« pĂ«rputhje me proceset e reja tĂ« implementuara.
Me përporosinë e drejtuesve, u krijua një grup pune, në të cilin morën pjesë përfaqësuesit e fushave të sigurisë, IT-së, biznesit dhe kontrollit të brendshëm. Në porosinë u shënuan qëllimet e krijimit të grupit, drejtimi i veprimtarisë, periudha e ekzistencës dhe personat përgjegjës nga çdo anë. Përveç kësaj, ne zhvilluam një metodologji për kryerjen e auditeve 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 drejtësia e kompanisë.
Dokumentet që përshkruajnë rendin e zhvillimit të punëve, afatet, përgjegjësinë etj. janë garanci që në rrugën drejt qëllimit të dëshiruar, i cili në fillim nuk është i qartë për të gjithë, askush nuk do të ketë pyetje si "për çfarë po e bëjmë këtë, përse na nevojitet dhe të ngjashme" dhe nuk do të jetë e mundur të "shkëputet" ose të ngadalësohet procesi.
Hapi 4. Regjistrojmë parametrat e modelit aktual të menaxhimit të aksesit.
Krijojmë atë që quhet "pashaporti i sistemit" në lidhje me menaxhimin e aksesit. Në thelb, kjo është një anketë për një sistem të veçantë informacioni, në të cilin janë regjistruar të gjitha algoritmet e menaxhimit të aksesit ndaj tij. Kompanitë që kanë zbatuar tashmë zgjidhje të klasës IdM, sigurisht që janë të njohura me një anketë të tillë, pasi kjo është pikënisja për studimin e sistemeve.
Disa parametra të sistemit dhe pronarëve janë transferuar në anketë nga regjistri IT (shiko hapi 2, auditimi), por janë shtuar edhe të rinj:
- si realizohet menaxhimi i llogarive (drejt në DB ose përmes ndërfaqeve programore);
- si hyjnë përdoruesit në sistem (me një llogari të veçantë ose duke përdorur llogarinë AD, LDAP ose të tjera);
- cilat nivele aksesimi përdoren në sistem (niveli i aplikacionit, niveli sistemor, përdorimi i burimeve të skedarëve në rrjet);
- përshkrimi dhe parametrat serverësh, mbi të cilat operon sistemi;
- cilat operacione mbi menaxhimin e llogarive mbështeten (bllokim, rinovim etj.);
- për çfarë algoritmesh ose rregullash formohet identifikuesi i përdoruesit të sistemit;
- për cilin atribut mund të vendoset lidhja me regjistrin e punonjësit në sistemin e burimeve njerëzore (emri, numri i tabelës ose të tjera);
- të gjithë atributet e mundshme të llogarive dhe rregullat e plotësimit të tyre;
- cilat të drejta aksesimi ekzistojnë në sistem (rollet, grupet, të drejtat atomike etj., nëse ekzistojnë të drejta të përfshira ose hierarkike);
- mekanizmat e ndarjes së të drejtave të aksesit (sipërfaqeve, degëve, funksionaliteteve etj.);
- a ekzistojnĂ« rregulla pĂ«r ndarjen e tĂ« drejtave nĂ« sistem (SOD â Ndarja e Detyrave), dhe si funksionojnĂ« ato;
- si përpunohen në sistem ngjarjet e mungesës, kalimit, shkarkimit, përditësimit të të dhënave për punonjësit etj.
Mund të vazhdojmë këtë listë me detaje sipas parametrave të ndryshëm dhe objekteve të tjera që janë të angazhuara në procesin e menaxhimit të aksesit.
Hapi 5. Krijoni një përshkrim të orientuar nga biznesi për fuqitë
Një dokument tjetër që na nevojitet gjatë ndërtimit të modelit të funksioneve është një doracak për të gjitha fuqitë e mundshme (të drejtat) që mund t'u jepen përdoruesve në sistemin informacionit me një përshkrim të detajuar të funksionit të biznesit që qëndron pas saj. Shpesh fuqitë në sistem janë të koduara me emra të caktuar, përbërë nga shkronja dhe numra, dhe punonjësit e biznesit nuk mund të kuptojnë se çfarë qëndron pas këtyre simboleve. Atëherë ata shkojnë në shërbimin IT, dhe aty⊠gjithashtu nuk mund të përgjigjen në pyetje, për shembull, në lidhje me të drejtat e rrallë të përdorura. Atëherë duhet të bëhet testim shtesë.
Mirë është nëse përshkrimi i biznesit tashmë ekziston ose madje ekziston një bashkim i këtyre të drejtave në grupe dhe role. Për disa aplikacione, praktika më e mirë është krijimi i një doracak të tillë që në fazën e zhvillimit të tyre. Por kjo ndodh rrallë, prandaj sërish shkojmë në departamentin IT për të mbledhur informacion mbi të gjitha fuqitë e mundshme dhe për t'i përshkruar ato. Doracaku ynë në fund do të përmbajë sa vijon:
- emri i fuqisë, duke përfshirë objektin, për të cilin zbatohen të drejtat e aksesit;
- veprimi që lejohet të bëhet me objektin (shikimi, ndryshimi etj., mundësia e kufizimi, për shembull, sipas kritereve territoriale ose grupit të klientëve);
- kod i fuqisë (kodi dhe emri i funksionit/kërkesës së sistemit, të cilat mund të realizohen duke përdorur fuqinë);
- përshkrimi i fuqisë (një përshkrim i detajuar i veprimeve në SIS gjatë zbatimit të fuqisë dhe pasojave të saj për procesin;
- statusi i fuqisë: 'Aktiv' (nëse fuqia është caktuar të paktën një përdoruesi) ose 'Jo aktiv' (nëse fuqia nuk përdoret).
Hapi 6 Eksporto të dhënat nga sistemet mbi përdoruesit dhe të drejtat dhe përputhu me burimin e të dhënave mbi punonjësit
Në fazën përfundimtare të përgatitjes, është e nevojshme të eksportoni të dhënat nga sistemet informacioni për të gjithë përdoruesit dhe të drejtat që ata kanë në këtë moment. Këtu ka dy skenarë. Së pari: departamenti i sigurisë ka qasje direkte në sistem dhe ka mjete për të eksportuar raportet përkatëse, që ndodh rrallë, por është shumë e përshtatshme. Së dyti: dërgojmë një kërkesë në IT për të marrë raportet në formatin e duhur. Praktika tregon se: të bisedosh me IT-në dhe të marrësh të dhënat e nevojshme në herën e parë nuk është e lehtë. Duhet të bësh disa përpjekje derisa informacioni të merret në formatin e dëshiruar.
Cilat të dhëna duhet të eksportohen:
- Emri i llogarisë
- Emri dhe mbiemri i punonjësit, për të cilin është e lidhur
- Statusi (aktiv apo i bllokuar)
- Data e krijimit të llogarisë
- Data e përdorimit të fundit
- Lista e të drejtave/grupeve/rolave të disponueshme
Kështu, ne kemi marrë eksporte nga sistemi me të gjithë përdoruesit dhe të gjitha të drejtat që u janë dhënë atyre. Dhe menjëherë i kemi lënë mënjanë të gjitha llogaritë e bllokuara, pasi puna për ndërtimin e modelit të rolit do të zhvillohet vetëm për përdoruesit aktivë.
Pastaj, nĂ«se kompania juaj nuk ka mjete automatizuese pĂ«r mbylljen e aksesit pĂ«r punonjĂ«sit e pushuar (diçka qĂ« ndodh shpesh) ose ka njĂ« automatizim patchwork qĂ« nuk funksionon gjithmonĂ« siç duhet, duhet tĂ« identifikoni tĂ« gjithĂ« "shpirtrat e vdekur". KĂ«tu flasim pĂ«r llogaritĂ« e punonjĂ«sve tĂ« pushuar, tĂ« drejtat e tĂ« cilĂ«ve pĂ«r ndonjĂ« arsye nuk janĂ« bllokuar, â ato duhet tĂ« bllokohen. PĂ«r kĂ«tĂ«, ne pĂ«rputhim tĂ« dhĂ«nat e eksportuara me burimin e kadrove. Eksportin e kadrove gjithashtu duhet ta marrim paraprakisht nga departamenti qĂ« menaxhon bazĂ«n e tĂ« dhĂ«nave tĂ« punonjĂ«sve.
ĂshtĂ« e nevojshme tĂ« veçojmĂ« llogaritĂ«, pronarĂ«t e tĂ« cilave nuk janĂ« gjetur nĂ« bazĂ«n e tĂ« dhĂ«nave, tĂ« pa lidhura me askĂ«nd, pra llogaritĂ« pa pronar. Nga ky listĂ« do tĂ« na nevojitet data e pĂ«rdorimit tĂ« fundit: nĂ«se ajo Ă«shtĂ« relativisht e fundit, do tĂ« duhet akoma tĂ« kĂ«rkojmĂ« pronarĂ«t. KĂ«tu mund tĂ« pĂ«rfshihen llogaritĂ« e kontraktuesve tĂ« jashtĂ«m ose llogaritĂ« e shĂ«rbimit, tĂ« pa lidhura me askĂ«nd, por tĂ« lidhura me ndonjĂ« proces. PĂ«r tĂ« sqaruar pĂ«rkatĂ«sinĂ« e llogarive, mund tĂ« dĂ«rgojmĂ« letĂ«r nĂ« tĂ« gjitha njĂ«sitĂ« pĂ«r tĂ« kĂ«rkuar informacion. Kur pronarĂ«t tĂ« gjejnĂ«, do t'i fusim tĂ« dhĂ«nat e tyre nĂ« sistem: kĂ«shtu do tĂ« identifikohen tĂ« gjitha llogaritĂ« aktive, ndĂ«rsa tĂ« tjerat do t'i bllokojmĂ«.
Kur shkarkimet tona të jenë pastruar nga regjistrimet e panevojshme dhe të mbeten vetëm llogaritë aktive, mund të fillojmë ndërtimin e modelit të rolit për sistemin specifik të informacionit. Por për këtë do të flas në artikullin e ardhshëm.
Autori: Lyudmila Sevastyanova, menaxhere për avancimin e Solar inRights
Burimi: habr.com
