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 serverëve, 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
