Aktualisht punoj për një shitës softuerësh, veçanërisht për zgjidhjet e kontrollit të aksesit. Dhe përvoja ime "nga një jetë e kaluar" është e lidhur me anën e klientit - një organizatë e madhe financiare. Në atë kohë, grupi ynë i kontrollit të aksesit në departamentin e sigurisë së informacionit nuk mund të mburrej me kompetenca të mëdha në IdM. Ne mësuam shumë gjatë procesit, na u desh të goditnim shumë goditje në mënyrë që të ndërtonim një mekanizëm funksional për menaxhimin e të drejtave të përdoruesve në sistemet e informacionit në kompani.
Duke kombinuar përvojën time të fituar me vështirësi të klientit me njohuritë dhe kompetencat e shitësit, dua të ndaj me ju udhëzime në thelb hap pas hapi: si të krijoni një model kontrolli aksesi të bazuar në role në një kompani të madhe dhe çfarë do të japë kjo si rezultat . Udhëzimet e mia përbëhen nga dy pjesë: e para është përgatitja për të ndërtuar modelin, e dyta është në të vërtetë ndërtimi. Këtu është pjesa e parë, pjesa përgatitore.
NB Për fat të keq, ndërtimi i një modeli nuk është rezultat, por proces. Ose më mirë, edhe pjesë e procesit të krijimit të një ekosistemi të kontrollit të aksesit në kompani. Pra, përgatituni për lojën për një kohë të gjatë.
Së pari, le ta përcaktojmë - çfarë është kontrolli i aksesit i bazuar në role? Supozoni se keni një bankë të madhe me dhjetëra, apo edhe qindra mijëra punonjës (entitete), secili prej të cilëve ka dhjetëra të drejta aksesi në qindra sisteme të brendshme të informacionit të bankës (objekte). Tani shumëzoni numrin e objekteve me numrin e subjekteve - ky është numri minimal i lidhjeve që ju nevojiten së pari për të ndërtuar dhe më pas kontrolluar. A është vërtet e mundur ta bëni këtë me dorë? Sigurisht që jo - rolet u krijuan për të zgjidhur këtë problem.
Një rol është një grup lejesh që i nevojiten një përdoruesi ose grupi përdoruesish për të kryer detyra të caktuara pune. Çdo punonjës mund të ketë një ose më shumë role dhe secili rol mund të përmbajë nga një deri në shumë leje që i lejohen përdoruesit brenda atij roli. Rolet mund të lidhen me pozicione specifike, departamente ose detyra funksionale të punonjësve.
Rolet zakonisht krijohen nga autorizimet individuale të punonjësve në çdo sistem informacioni. Pastaj rolet globale të biznesit formohen nga rolet e secilit sistem. Për shembull, roli i biznesit "menaxheri i kredisë" do të përfshijë disa role të veçanta në sistemet e informacionit që përdoren në zyrën e klientit të bankës. Për shembull, në sistemin bankar kryesor të automatizuar, modulin e parave të gatshme, sistemin elektronik të menaxhimit të dokumenteve, menaxherin e shërbimit etj. Rolet e biznesit, si rregull, janë të lidhura me strukturën organizative - me fjalë të tjera, me grupin e ndarjeve të kompanisë dhe pozicioneve në to. Kështu formohet një matricë e roleve globale (Unë jap një shembull në tabelën më poshtë).
Vlen të përmendet se është thjesht e pamundur të ndërtohet një model roli 100%, duke siguruar të gjitha të drejtat e nevojshme për punonjësit e çdo pozicioni në një strukturë tregtare. Po, kjo nuk është e nevojshme. Në fund të fundit, një model nuk mund të jetë statik, sepse varet nga një mjedis që ndryshon vazhdimisht. Dhe nga ndryshimet në aktivitetet e biznesit të kompanisë, të cilat, në përputhje me rrethanat, ndikojnë në ndryshimet në strukturën organizative dhe funksionalitetin. Dhe nga mungesa e sigurimit të plotë të burimeve, dhe nga mosrespektimi i përshkrimeve të punës, dhe nga dëshira për fitim në kurriz të sigurisë, dhe nga shumë faktorë të tjerë. Prandaj, është e nevojshme të ndërtohet një model që mund të mbulojë deri në 80% të nevojave të përdoruesve për të drejtat e nevojshme themelore kur caktohen në një pozicion. Dhe ata, nëse është e nevojshme, mund të kërkojnë 20% të mbetur më vonë në aplikime të veçanta.
Sigurisht, ju mund të pyesni: "A nuk ka gjë të tillë si modele 100%?" Epo, pse, kjo ndodh, për shembull, në strukturat jofitimprurëse që nuk janë subjekt i ndryshimeve të shpeshta - në disa institute kërkimore. Ose në organizata komplekse ushtarako-industriale me nivel të lartë sigurie, ku siguria është e para. Ndodh në një strukturë komerciale, por në kuadrin e një ndarjeje të veçantë, puna e së cilës është një proces mjaft statik dhe i parashikueshëm.
Avantazhi kryesor i menaxhimit të bazuar në role është thjeshtimi i lëshimit të të drejtave, sepse numri i roleve është dukshëm më i vogël se numri i përdoruesve të sistemit të informacionit. Dhe kjo është e vërtetë për çdo industri.
Le të marrim një kompani me pakicë: ajo punëson mijëra shitës, por ata kanë të njëjtat të drejta në sistemin N dhe do t'u krijohet vetëm një rol. Kur një shitës i ri vjen në kompani, atij i caktohet automatikisht roli i kërkuar në sistem, i cili tashmë ka të gjitha autoritetet e nevojshme. Gjithashtu, me një klikim mund të ndryshoni të drejtat për mijëra shitës në të njëjtën kohë, për shembull, shtoni një opsion të ri për gjenerimin e një raporti. Nuk ka nevojë të bëni një mijë operacione, duke lidhur një të drejtë të re për secilën llogari - thjesht shtoni këtë opsion në rol dhe ai do të shfaqet për të gjithë shitësit në të njëjtën kohë.
Një avantazh tjetër i menaxhimit të bazuar në role është eliminimi i lëshimit të autorizimeve të papajtueshme. Domethënë, një punonjës që ka një rol të caktuar në sistem nuk mund të ketë njëkohësisht një rol tjetër, të drejtat e të cilit nuk duhet të kombinohen me të drejtat në të parën. Një shembull i mrekullueshëm është ndalimi i kombinimit të funksioneve të hyrjes dhe kontrollit të një transaksioni financiar.
Kushdo që është i interesuar se si lindi kontrolli i aksesit i bazuar në role, mundet
zhyten në histori
Nëse shikojmë historinë, komuniteti i IT-së së pari mendoi për metodat e kontrollit të aksesit në vitet 70 të shekullit të XNUMX-të. Megjithëse aplikacionet ishin mjaft të thjeshta në atë kohë, ashtu si tani, të gjithë donin të menaxhonin me lehtësi aksesin në to. Jepni, ndryshoni dhe kontrolloni të drejtat e përdoruesve - vetëm për ta bërë më të lehtë të kuptoni se çfarë aksesi ka secili prej tyre. Por në atë kohë nuk kishte standarde të përbashkëta, sistemet e para të kontrollit të aksesit po zhvilloheshin dhe secila kompani bazohej në idetë dhe rregullat e veta.
Tani njihen shumë modele të ndryshme të kontrollit të aksesit, por ato nuk u shfaqën menjëherë. Le të ndalemi në ato që kanë dhënë një kontribut të rëndësishëm në zhvillimin e kësaj zone.
Modeli i parë dhe ndoshta më i thjeshtë është Kontrolli i qasjes diskrecionale (selektive). (DAC – Kontrolli i qasjes diskrecionale). Ky model nënkupton ndarjen e të drejtave nga të gjithë pjesëmarrësit në procesin e aksesit. Çdo përdorues ka akses në objekte ose operacione specifike. Në thelb, këtu grupi i subjekteve të të drejtave i përgjigjet grupit të objekteve. Ky model u zbulua se ishte shumë fleksibël dhe shumë i vështirë për t'u mbajtur: listat e aksesit përfundimisht bëhen të mëdha 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 akses në një objekt në përputhje me aksesin e dhënë në një nivel të caktuar të konfidencialitetit të të dhënave. Prandaj, objektet duhet të kategorizohen sipas nivelit të tyre të konfidencialitetit. Ndryshe nga modeli i parë fleksibël, ky, përkundrazi, doli të ishte shumë i rreptë dhe kufizues. Përdorimi i tij nuk justifikohet kur kompania ka shumë burime të ndryshme informacioni: për të diferencuar aksesin në burime të ndryshme, do të duhet të prezantoni shumë kategori që nuk do të mbivendosen.
Për shkak të papërsosmërive të dukshme të këtyre dy metodave, komuniteti i IT-së ka vazhduar të zhvillojë modele që janë më fleksibël dhe në të njëjtën kohë pak a shumë universale për të mbështetur lloje të ndryshme të politikave të kontrollit të aksesit organizativ. Dhe pastaj u shfaq modeli i tretë i kontrollit të aksesit të bazuar në role! Kjo qasje ka rezultuar të jetë më premtuese sepse kërkon jo vetëm autorizimin e identitetit të përdoruesit, por edhe funksionet e tij operacionale në sisteme.
Struktura e parë model e përshkruar qartë u propozua nga shkencëtarët amerikanë David Ferrailo dhe Richard Kuhn nga Instituti Kombëtar i Standardeve dhe Teknologjisë i SHBA-së në 1992. Pastaj u shfaq për herë të parë termi RBAC (Kontrolli i aksesit i bazuar në role). Këto studime dhe përshkrime të komponentëve kryesorë, si dhe marrëdhëniet e tyre, formuan bazën e standardit INCITS 359-2012, i cili është ende në fuqi edhe sot, i miratuar nga Komiteti Ndërkombëtar i Standardeve të Teknologjisë së Informacionit (INCITS).
Standardi e përcakton një rol si "një funksion pune në kontekstin e një organizate me disa semantikë të lidhur në lidhje me autoritetin dhe përgjegjësinë që i caktohet përdoruesit të caktuar në rol". Dokumenti përcakton elementet bazë të RBAC - përdoruesit, seancat, rolet, lejet, operacionet dhe objektet, si dhe marrëdhëniet dhe ndërlidhjet ndërmjet tyre.
Standardi ofron strukturën minimale të nevojshme për ndërtimin e një modeli roli - duke kombinuar të drejtat në role dhe më pas duke u dhënë akses përdoruesve përmes këtyre roleve. Përshkruhen mekanizmat për kompozimin e roleve nga objektet dhe operacionet, përshkruhet hierarkia e roleve dhe trashëgimia e pushteteve. Në fund të fundit, në çdo kompani ka role që kombinojnë fuqitë themelore që janë të nevojshme për të gjithë punonjësit e kompanisë. Kjo mund të jetë qasja në email, EDMS, portal korporativ, etj. Këto leje mund të përfshihen në një rol të përgjithshëm të quajtur "punonjës" dhe nuk do të ketë nevojë të renditen të gjitha të drejtat bazë vazhdimisht në secilin prej roleve të nivelit më të lartë. Mjafton thjesht të tregoni karakteristikën e trashëgimisë së rolit të "punonjësit".
Më vonë, standardi u plotësua me atribute të reja aksesi që lidhen me mjedisin që ndryshon vazhdimisht. Është shtuar aftësia për të futur kufizime statike dhe dinamike. Ato statike nënkuptojnë pamundësinë e kombinimit të roleve (të njëjtat hyrje dhe kontroll të operacioneve të përmendura më lart). Kufizimet dinamike mund të përcaktohen duke ndryshuar parametrat, për shembull, kohën (orët ose ditët e punës/jo pune), vendndodhjen (zyra/shtëpi), etj.
Më vete, duhet thënë për Kontrolli i aksesit i bazuar në atribute (ABAC - Kontrolli i aksesit i bazuar në atribute). Qasja bazohet në dhënien e aksesit duke përdorur rregullat e ndarjes së atributeve. Ky model mund të përdoret veçmas, por mjaft shpesh ai plotëson në mënyrë aktive modelin klasik: atributet e përdoruesve, burimet dhe pajisjet, si dhe koha ose vendndodhja, mund t'i shtohen një roli të caktuar. Kjo ju lejon të përdorni më pak role, të futni kufizime shtesë dhe ta bëni aksesin sa më minimal të jetë e mundur, dhe për këtë arsye të përmirësoni sigurinë.
Për shembull, një kontabilist mund t'i lejohet aksesi në llogari nëse ai punon në një rajon të caktuar. Pastaj vendndodhja e specialistit do të krahasohet me një vlerë të caktuar referimi. Ose mund të jepni akses në llogaritë vetëm nëse përdoruesi identifikohet nga një pajisje e përfshirë në listën e atyre të lejuara. Një shtesë e mirë për një model, por përdoret rrallë më vete për shkak të nevojës për të krijuar shumë rregulla dhe tabela të lejeve ose kufizimeve.
Më lejoni t'ju jap një shembull të përdorimit të ABAC nga "jeta ime e kaluar". Banka jonë kishte disa degë. Punonjësit e zyrave të klientëve në këto degë kryenin saktësisht të njëjtat operacione, por duhej të punonin në sistemin kryesor vetëm me llogari në rajonin e tyre. Së pari, filluam të krijonim role të veçanta për çdo rajon - dhe kishte kaq shumë role të tilla me funksione të përsëritura, por me akses në llogari të ndryshme! Më pas, duke përdorur një atribut të vendndodhjes për përdoruesin dhe duke e lidhur atë me një gamë specifike llogarish për t'u rishikuar, ne reduktuam ndjeshëm numrin e roleve në sistem. Si rezultat, rolet mbetën vetëm për një degë, të cilat u përsëritën për pozicionet përkatëse në të gjitha ndarjet e tjera territoriale 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 pune.
Hapi 1. Krijo një model funksional
Ju duhet të filloni duke krijuar një model funksional - një dokument të nivelit të lartë që përshkruan në detaje funksionalitetin e çdo departamenti dhe çdo pozicioni. Si rregull, informacioni hyn në të nga dokumente të ndryshme: përshkrimet e punës dhe rregulloret për njësitë individuale - departamente, divizione, departamente. Modeli funksional duhet të miratohet me të gjitha departamentet e interesuara (biznesi, kontrolli i brendshëm, siguria) dhe të miratohet nga menaxhmenti i kompanisë. Për çfarë shërben ky dokument? Në mënyrë që modeli i rolit t'i referohet asaj. Për shembull, ju do të ndërtoni një model të bazuar në të drejtat ekzistuese të punonjësve - të shkarkuar nga sistemi dhe "reduktuar në një emërues të përbashkët". Pastaj, kur bini dakord për rolet e marra me pronarin e biznesit të sistemit, mund t'i referoheni një pike specifike në modelin funksional, në bazë të së cilës kjo apo ajo e drejtë përfshihet në rol.
Hapi 2. Ne auditojmë sistemet e TI-së dhe hartojmë një plan prioritizimi
Në fazën e dytë, duhet të kryeni një auditim të sistemeve të TI-së për të kuptuar se si organizohet qasja në to. Për shembull, kompania ime financiare operonte disa qindra sisteme informacioni. Të gjitha sistemet kishin disa elemente të menaxhimit të bazuar në role, shumica kishin disa role, por kryesisht në letër ose në drejtorinë e sistemit - ato ishin të vjetruara prej kohësh dhe qasja në to jepej bazuar në kërkesat aktuale të përdoruesve. Natyrisht, është thjesht e pamundur të ndërtosh një model në disa qindra sisteme menjëherë; duhet të filloni diku. Ne kryem një analizë të thellë të procesit të kontrollit të aksesit për të përcaktuar nivelin e pjekurisë së tij. Gjatë procesit të analizës u zhvilluan kriteret për prioritizimin e sistemeve të informacionit - kritikiteti, gatishmëria, planet për dekomisionim, etj. Me ndihmën e tyre, ne rreshtuam zhvillimin/përditësimin e modeleve për këto sisteme. Dhe më pas kemi përfshirë modele në planin për integrim me zgjidhjen e Menaxhimit të Identitetit për të automatizuar kontrollin e aksesit.
Pra, si e përcaktoni kritikitetin e një sistemi? Përgjigjuni vetes pyetjeve të mëposhtme:
- A është sistemi i lidhur me proceset operacionale nga të cilat varen aktivitetet kryesore të kompanisë?
- A do të ndikojë ndërprerja e sistemit në integritetin e aseteve të kompanisë?
- Cila është koha maksimale e lejueshme e ndërprerjes së sistemit, deri në të cilën është e pamundur të rivendoset aktiviteti pas një ndërprerjeje?
- A mund të çojë një shkelje e integritetit të informacionit në sistem në pasoja të pakthyeshme, si financiare ashtu edhe reputacionale?
- Kriticiteti ndaj mashtrimit. Prania e funksionalitetit, nëse nuk kontrollohet siç duhet, mund të çojë në veprime mashtruese të brendshme/të jashtme;
- Cilat janë kërkesat ligjore dhe rregullat dhe procedurat e brendshme për këto sisteme? A do të ketë gjoba nga rregullatorët për mospërputhje?
Në kompaninë tonë financiare, ne kemi kryer një auditim të tillë. Menaxhmenti zhvilloi procedurën e auditimit të Rishikimit të të Drejtave të Aksesit për të parë përdoruesit ekzistues dhe të drejtat së pari në ato sisteme informacioni që ishin në listën me prioritet më të lartë. Si pronar i këtij procesi u caktua departamenti i sigurisë. Por për të marrë një pamje të plotë të të drejtave të aksesit në kompani, ishte e nevojshme përfshirja e departamenteve të IT dhe biznesit në proces. Dhe këtu filluan mosmarrëveshjet, keqkuptimet dhe ndonjëherë edhe sabotimet: askush nuk dëshiron të shkëputet nga përgjegjësitë e tyre aktuale dhe të përfshihet në disa, në shikim të parë, aktivitete të pakuptueshme.
NB Kompanitë e mëdha me procese të zhvilluara të TI-së ndoshta janë të njohura me procedurën e auditimit të TI-së - kontrollet e përgjithshme të TI-së (ITGC), e cila ju lejon të identifikoni mangësitë në proceset e TI-së dhe të vendosni kontroll në mënyrë që të përmirësoni proceset në përputhje me praktikat më të mira (ITIL, COBIT, IT Qeverisja etj.) Një auditim i tillë lejon IT-në dhe biznesin të kuptojnë më mirë njëri-tjetrin dhe të zhvillojnë një strategji të përbashkët zhvillimi, të analizojnë rreziqet, të optimizojnë kostot dhe të zhvillojnë qasje më efektive ndaj punës.
Një nga fushat e auditimit është përcaktimi i parametrave të aksesit logjik dhe fizik në sistemet e informacionit. Të dhënat e marra i morëm si bazë për përdorim të mëtejshëm në ndërtimin e një modeli. Si rezultat i këtij auditimi kemi pasur një regjistër të sistemeve të TI-së, në të cilin janë përcaktuar parametrat teknikë të tyre dhe janë dhënë përshkrimet. Për më tepër, për secilin sistem, u identifikua një pronar nga drejtimi i biznesit në interesat e të cilit operohej: ishte ai që ishte përgjegjës për proceset e biznesit që ky sistem i shërbente. U emërua gjithashtu një menaxher i shërbimit IT, përgjegjës për zbatimin teknik të nevojave të biznesit për një IS specifik. U regjistruan sistemet më kritike për kompaninë dhe parametrat e tyre teknikë, kushtet e vënies në punë dhe nxjerrjes jashtë përdorimit etj.. Këto parametra ndihmuan shumë në procesin e përgatitjes për krijimin e një modeli.
Hapi 3 Krijoni një metodologji
Çelësi i suksesit të çdo biznesi është metoda e duhur. Prandaj, si për të ndërtuar një model roli ashtu edhe për të kryer një auditim, ne duhet të krijojmë një metodologji në të cilën të përshkruajmë ndërveprimin midis departamenteve, të vendosim përgjegjësinë në rregulloret e kompanisë, etj.
Së pari ju duhet të shqyrtoni të gjitha dokumentet e disponueshme që përcaktojnë procedurën për dhënien e aksesit dhe të drejtave. Në një mënyrë të mirë, proceset duhet të dokumentohen në disa nivele:
- kërkesat e përgjithshme të korporatës;
- kërkesat për fushat e sigurisë së informacionit (në varësi të fushave të aktiviteteve të organizatës);
- kërkesat për proceset teknologjike (udhëzimet, matricat e aksesit, udhëzimet, kërkesat e konfigurimit).
Në shoqërinë tonë financiare gjetëm shumë dokumente të vjetruara, të cilat duhej t'i sillnim në përputhje me proceset e reja që po zbatoheshin.
Me urdhër të menaxhmentit, u krijua një grup pune, i cili përfshinte përfaqësues nga siguria, IT, biznesi dhe kontrolli i brendshëm. Urdhri përshkruan qëllimet e krijimit të grupit, drejtimin e veprimtarisë, periudhën e ekzistencës dhe përgjegjësit nga secila anë. Përveç kësaj, ne zhvilluam një metodologji auditimi dhe një procedurë për ndërtimin e një modeli roli: për to u ra dakord nga të gjithë përfaqësuesit përgjegjës të fushave dhe u miratuan nga menaxhmenti i kompanisë.
Dokumentet që përshkruajnë procedurën e kryerjes së punës, afatet, përgjegjësitë etj. - një garanci që në rrugën drejt qëllimit të dashur, i cili në fillim nuk është i dukshëm për të gjithë, askush nuk do të ketë pyetje "pse po e bëjmë këtë, pse na duhet, etj." dhe nuk do të ketë asnjë mundësi për të "kaluar" ose ngadalësuar procesin.
Hapi 4. Rregulloni parametrat e modelit ekzistues të kontrollit të aksesit
Ne jemi duke hartuar një të ashtuquajtur "pasaportë të sistemit" për sa i përket kontrollit të aksesit. Në thelb, ky është një pyetësor për një sistem informacioni specifik, i cili regjistron të gjitha algoritmet për kontrollin e aksesit në të. Kompanitë që kanë implementuar tashmë zgjidhje të klasës IdM janë të njohur me një pyetësor të tillë, pasi këtu fillon studimi i sistemeve.
Disa parametra në lidhje me sistemin dhe pronarët erdhën në pyetësor nga regjistri i IT (shih hapin 2, auditimi), por u shtuan gjithashtu të rinj:
- si menaxhohen llogaritë (drejtpërsëdrejti në bazën e të dhënave ose përmes ndërfaqeve të softuerit);
- si hyjnë përdoruesit në sistem (duke përdorur një llogari të veçantë ose duke përdorur një llogari AD, LDAP, etj.);
- cilat nivele të aksesit në sistem përdoren (niveli i aplikacionit, niveli i sistemit, përdorimi i sistemit të burimeve të skedarëve të rrjetit);
- përshkrimi dhe parametrat e serverëve në të cilët funksionon sistemi;
- cilat operacione të menaxhimit të llogarisë mbështeten (bllokim, riemërim, etj.);
- cilat algoritme ose rregulla përdoren për të gjeneruar identifikuesin e përdoruesit të sistemit;
- çfarë atributi mund të përdoret për të krijuar një lidhje me të dhënat e një punonjësi në sistemin e personelit (emri i plotë, numri i personelit, etj.);
- të gjitha atributet e mundshme të llogarisë dhe rregullat për plotësimin e tyre;
- çfarë të drejtash aksesi ekzistojnë në sistem (rolet, grupet, të drejtat atomike, etj., a ka të drejta të mbivendosura apo hierarkike);
- mekanizmat për ndarjen e të drejtave të aksesit (sipas pozicionit, departamentit, funksionalitetit, etj.);
- A ka sistemi rregulla për ndarjen e të drejtave (SOD – Segregation of Duties), dhe si funksionojnë ato;
- si përpunohen në sistem ngjarjet e mungesës, transferimit, largimit nga puna, përditësimit të të dhënave të punonjësve etj.
Kjo listë mund të vazhdohet, duke detajuar parametrat e ndryshëm dhe objektet e tjera që përfshihen në procesin e kontrollit të aksesit.
Hapi 5. Krijo një përshkrim të orientuar drejt biznesit të lejeve
Një dokument tjetër që do të na duhet kur ndërtojmë një model roli është një libër referimi për të gjitha fuqitë (të drejtat) e mundshme që mund t'u jepen përdoruesve në sistemin e informacionit me një përshkrim të detajuar të funksionit të biznesit që qëndron pas tij. Shpesh, autoritetet në sistem janë të koduara me emra të caktuar që përbëhen nga shkronja dhe numra, dhe punonjësit e biznesit nuk mund të kuptojnë se çfarë fshihet pas këtyre simboleve. Pastaj ata shkojnë në shërbimin e IT, dhe atje ... ata gjithashtu nuk mund t'i përgjigjen pyetjes, për shembull, për të drejtat e përdorura rrallë. Pastaj duhet të bëhen testime shtesë.
Është mirë nëse ekziston tashmë një përshkrim biznesi ose edhe nëse ekziston një kombinim i këtyre të drejtave në grupe dhe role. Për disa aplikacione, praktika më e mirë është krijimi i një referimi të tillë në fazën e zhvillimit. Por kjo nuk ndodh shpesh, kështu që ne përsëri shkojmë në departamentin e IT për të mbledhur informacione për të gjitha të drejtat e mundshme dhe për t'i përshkruar ato. Udhëzuesi ynë përfundimisht do të përmbajë sa vijon:
- emrin e autoritetit, duke përfshirë objektin për të cilin zbatohet e drejta e aksesit;
- një veprim që lejohet të kryhet me një objekt (shikimi, ndryshimi, etj., mundësia e kufizimit, për shembull, sipas territorit ose sipas grupit të klientëve);
- kodi i autorizimit (kodi dhe emri i funksionit/kërkesës së sistemit që mund të ekzekutohet duke përdorur autorizimin);
- përshkrimi i autoritetit (përshkrimi i detajuar i veprimeve në SI gjatë zbatimit të autoritetit dhe pasojat e tyre për procesin;
- statusi i lejes: "Aktiv" (nëse leja i është caktuar të paktën një përdoruesi) ose "Jo aktive" (nëse leja nuk përdoret).
Hapi 6 Ne shkarkojmë të dhëna për përdoruesit dhe të drejtat nga sistemet dhe i krahasojmë ato me burimin e personelit
Në fazën përfundimtare të përgatitjes, duhet të shkarkoni të dhëna nga sistemet e informacionit për të gjithë përdoruesit dhe të drejtat që ata kanë aktualisht. Këtu ka dy skenarë të mundshëm. Së pari: departamenti i sigurisë ka akses të drejtpërdrejtë në sistem dhe ka mjetet për të shkarkuar raporte përkatëse, gjë që nuk ndodh shpesh, por është shumë e përshtatshme. Së dyti: ne dërgojmë një kërkesë në IT për të marrë raporte në formatin e kërkuar. Përvoja tregon se nuk është e mundur të arrihet një marrëveshje me IT dhe të merren të dhënat e nevojshme herën e parë. Është e nevojshme të bëhen disa qasje derisa informacioni të merret në formën dhe formatin e dëshiruar.
Cilat të dhëna duhet të shkarkohen:
- Emri i llogarise
- Emri i plotë i punonjësit të cilit i është caktuar
- Statusi (aktiv ose i bllokuar)
- Data e krijimit të llogarisë
- Data e përdorimit të fundit
- Lista e të drejtave/grupeve/rolet e disponueshme
Pra, kemi marrë shkarkime nga sistemi me të gjithë përdoruesit dhe të gjitha të drejtat që u janë dhënë. Dhe ata menjëherë lënë mënjanë të gjitha llogaritë e bllokuara, pasi puna për ndërtimin e një modeli do të kryhet vetëm për përdoruesit aktivë.
Pastaj, nëse kompania juaj nuk ka mjete të automatizuara për të bllokuar aksesin ndaj punonjësve të pushuar (kjo ndodh shpesh) ose ka automatizim me lara-lara që nuk funksionon gjithmonë si duhet, ju duhet të identifikoni të gjithë "shpirtrat e vdekur". Ne po flasim për llogaritë e punonjësve tashmë të pushuar nga puna, të drejtat e të cilëve për ndonjë arsye nuk janë të bllokuara - ata duhet të bllokohen. Për ta bërë këtë, ne krahasojmë të dhënat e ngarkuara me burimin e personelit. Shkarkimi i personelit duhet gjithashtu të merret paraprakisht nga departamenti që mirëmban bazën e të dhënave të personelit.
Më vete, është e nevojshme të lihen mënjanë llogaritë, pronarët e të cilave nuk u gjetën në bazën e të dhënave të personelit, nuk i janë caktuar askujt - domethënë pa pronar. Duke përdorur këtë listë, do të na duhet data e përdorimit të fundit: nëse është mjaft e fundit, do të duhet të kërkojmë akoma pronarët. Kjo mund të përfshijë llogaritë e kontraktorëve të jashtëm ose llogari shërbimi që nuk i janë caktuar askujt, por janë të lidhura me ndonjë proces. Për të zbuluar se kujt i përkasin llogaritë, mund t'u dërgoni letra të gjitha departamenteve duke u kërkuar atyre të përgjigjen. Kur gjenden pronarët, ne futim të dhëna rreth tyre në sistem: në këtë mënyrë, të gjitha llogaritë aktive identifikohen dhe pjesa tjetër bllokohen.
Sapo ngarkimet tona të pastrohen nga të dhënat e panevojshme dhe të mbeten vetëm llogaritë aktive, ne mund të fillojmë të ndërtojmë një model për një sistem specifik informacioni. Por unë do t'ju tregoj për këtë në artikullin tjetër.
Autor: Lyudmila Sevastyanova, menaxhere e promovimit Solar inRights
Burimi: www.habr.com