ProHoster > Blogs > Administrācija > Mēs veidojam uz lomām balstÄ«tu piekļuves kontroles modeli. Pirmā daļa, sagatavoÅ”anās

Mēs veidojam uz lomām balstÄ«tu piekļuves kontroles modeli. Pirmā daļa, sagatavoÅ”anās

PaÅ”laik strādāju pie programmatÅ«ras pārdevēja, Ä«paÅ”i piekļuves kontroles risinājumiem. Un mana pieredze ā€œno pagātnes dzÄ«vesā€ ir saistÄ«ta ar klienta pusi - lielu finanÅ”u organizāciju. Tolaik mÅ«su piekļuves kontroles grupa informācijas droŔības departamentā nevarēja lepoties ar lieliskām kompetencēm IdM jomā. Å ajā procesā mēs daudz iemācÄ«jāmies, nācās sasist ne mazums izciļņu, lai uzņēmumā izveidotu darba mehānismu lietotāju tiesÄ«bu pārvaldÄ«Å”anai informācijas sistēmās.
Mēs veidojam uz lomām balstÄ«tu piekļuves kontroles modeli. Pirmā daļa, sagatavoÅ”anās
Apvienojot savu grÅ«ti iegÅ«to klientu pieredzi ar pārdevēju zināŔanām un kompetencēm, es vēlos dalÄ«ties ar jums bÅ«tÄ«bā soli pa solim sniegtās instrukcijās: kā izveidot uz lomu balstÄ«tu piekļuves kontroles modeli lielā uzņēmumā un ko tas dos. . Mani norādÄ«jumi sastāv no divām daļām: pirmā gatavojas bÅ«vēt modeli, otrā faktiski bÅ«vē. Å eit ir pirmā daļa, sagatavoÅ”anas daļa.

NB Parauga veidoÅ”ana diemžēl nav rezultāts, bet gan process. Pareizāk sakot, pat daļa no piekļuves kontroles ekosistēmas izveides procesa uzņēmumā. Tāpēc gatavojieties spēlei uz ilgu laiku.

Vispirms definēsim to ā€” kas ir uz lomu balstÄ«ta piekļuves kontrole? Pieņemsim, ka jums ir liela banka ar desmitiem vai pat simtiem tÅ«kstoÅ”u darbinieku (entÄ«tiju), no kuriem katram ir desmitiem piekļuves tiesÄ«bu simtiem iekŔējo bankas informācijas sistēmu (objektu). Tagad reiziniet objektu skaitu ar priekÅ”metu skaitu - tas ir minimālais savienojumu skaits, kas vispirms jāizveido un pēc tam jākontrolē. Vai tieŔām to ir iespējams izdarÄ«t manuāli? Protams, ka nē ā€“ lomas tika radÄ«tas, lai atrisinātu Å”o problēmu.

Loma ir atļauju kopa, kas lietotājam vai lietotāju grupai ir nepiecieÅ”ama noteiktu darba uzdevumu veikÅ”anai. Katram darbiniekam var bÅ«t viena vai vairākas lomas, un katra loma var ietvert no vienas lÄ«dz daudzām atļaujām, kas ir atļautas lietotājam Å”ajā lomā. Lomas var saistÄ«t ar konkrētiem darbinieku amatiem, departamentiem vai funkcionāliem uzdevumiem.

Mēs veidojam uz lomām balstÄ«tu piekļuves kontroles modeli. Pirmā daļa, sagatavoÅ”anās

Lomas parasti tiek veidotas no individuālām darbinieku pilnvarām katrā informācijas sistēmā. Tad no katras sistēmas lomām veidojas globālās biznesa lomas. Piemēram, biznesa loma "kredÄ«ta menedžeris" ietvers vairākas atseviŔķas lomas informācijas sistēmās, kuras tiek izmantotas bankas klientu birojā. Piemēram, galvenajā automatizētajā banku sistēmā, kases modulÄ«, elektroniskajā dokumentu pārvaldÄ«bas sistēmā, pakalpojumu menedžerÄ« un citos. UzņēmējdarbÄ«bas lomas, kā likums, ir saistÄ«tas ar organizatorisko struktÅ«ru - citiem vārdiem sakot, ar uzņēmuma nodaļu kopumu un amatiem tajās. Tādā veidā tiek veidota globāla lomu matrica (es sniedzu piemēru zemāk esoÅ”ajā tabulā).

Mēs veidojam uz lomām balstÄ«tu piekļuves kontroles modeli. Pirmā daļa, sagatavoÅ”anās

Ir vērts atzÄ«mēt, ka vienkārÅ”i nav iespējams izveidot 100% lomu modeli, nodroÅ”inot visas nepiecieÅ”amās tiesÄ«bas katras pozÄ«cijas darbiniekiem komercstruktÅ«rā. Jā, tas nav nepiecieÅ”ams. Galu galā paraugs nevar bÅ«t statisks, jo tas ir atkarÄ«gs no pastāvÄ«gi mainÄ«gas vides. Un no izmaiņām uzņēmuma saimnieciskajā darbÄ«bā, kas attiecÄ«gi ietekmē izmaiņas organizatoriskajā struktÅ«rā un funkcionalitātē. Un no pilnÄ«gas resursu trÅ«kuma, un no amata aprakstu neievēroÅ”anas, un no peļņas vēlmes uz droŔības rēķina, un no daudziem citiem faktoriem. Tāpēc ir jāveido paraugs, kas var segt lÄ«dz pat 80% lietotāju vajadzÄ«bas pēc nepiecieÅ”amajām pamattiesÄ«bām, pieŔķirot amatam. Un viņi, ja nepiecieÅ”ams, var pieprasÄ«t atlikuÅ”os 20% vēlāk, izmantojot atseviŔķus pieteikumus.

Protams, jÅ«s varat jautāt: "Vai nav tādas lietas kā 100% lomu modeļi?" Nu, kāpēc, tas notiek, piemēram, bezpeļņas struktÅ«rās, kas nav pakļautas biežām izmaiņām - kādā pētniecÄ«bas institÅ«tā. Vai arÄ« militāri rÅ«pniecisko kompleksu organizācijās ar augstu droŔības lÄ«meni, kur droŔība ir pirmajā vietā. Tas notiek komerciālā struktÅ«rā, bet atseviŔķas nodaļas ietvaros, kuras darbs ir diezgan statisks un prognozējams process.

Galvenā lomas vadÄ«bas priekÅ”rocÄ«ba ir tiesÄ«bu izsniegÅ”anas vienkārÅ”oÅ”ana, jo lomu skaits ir ievērojami mazāks nekā informācijas sistēmas lietotāju skaits. Un tas attiecas uz jebkuru nozari.

Ņemsim mazumtirdzniecÄ«bas uzņēmumu: tajā strādā tÅ«kstoÅ”iem pārdevēju, taču viņiem sistēmā N ir vienāds tiesÄ«bu kopums, un viņiem tiks izveidota tikai viena loma. Kad uzņēmumā ierodas jauns pārdevējs, viņam automātiski tiek pieŔķirta nepiecieÅ”amā loma sistēmā, kurā jau ir visas nepiecieÅ”amās pilnvaras. Tāpat ar vienu klikŔķi var mainÄ«t tiesÄ«bas uzreiz tÅ«kstoÅ”iem pārdevēju, piemēram, pievienot jaunu atskaites Ä£enerÄ“Å”anas opciju. Nav nepiecieÅ”ams veikt tÅ«kstoÅ” darbÄ«bu, katram kontam saistot jaunas tiesÄ«bas ā€“ vienkārÅ”i pievienojiet Å”o opciju lomai, un tā bÅ«s redzama visiem pārdevējiem vienlaikus.

Vēl viena uz lomu balstÄ«tas pārvaldÄ«bas priekÅ”rocÄ«ba ir nesaderÄ«gu atļauju izsniegÅ”anas novērÅ”ana. Tas ir, darbiniekam, kuram sistēmā ir noteikta loma, vienlaikus nevar bÅ«t cita loma, kuras tiesÄ«bas nevajadzētu apvienot ar pirmajām tiesÄ«bām. Spilgts piemērs ir aizliegums apvienot finanÅ”u darÄ«juma ievades un kontroles funkcijas.

Ikviens, kurÅ” interesējas par to, kā radās uz lomām balstÄ«ta piekļuves kontrole, var
ienirt vēsturē
Ja palÅ«kojamies vēsturē, IT sabiedrÄ«ba par piekļuves kontroles metodēm pirmo reizi domāja 70. gadsimta XNUMX. gados. Lai gan toreiz lietojumprogrammas bija diezgan vienkārÅ”as, tāpat kā tagad, ikviens ļoti vēlējās ērti pārvaldÄ«t piekļuvi tām. PieŔķiriet, mainiet un kontrolējiet lietotāja tiesÄ«bas ā€“ tikai tāpēc, lai bÅ«tu vieglāk saprast, kāda piekļuve ir katram no tiem. Bet tajā laikā nebija vienotu standartu, tika izstrādātas pirmās piekļuves kontroles sistēmas, un katrs uzņēmums bija balstÄ«ts uz savām idejām un noteikumiem.

Tagad ir zināmi daudzi dažādi piekļuves kontroles modeļi, taču tie neparādÄ«jās uzreiz. Pakavēsimies pie tiem, kas devuÅ”i bÅ«tisku ieguldÄ«jumu Ŕīs jomas attÄ«stÄ«bā.

Pirmais un, iespējams, vienkārŔākais modelis ir Diskrecionāra (selektÄ«va) piekļuves kontrole (DAC ā€” diskrecionāra piekļuves kontrole). Å is modelis paredz tiesÄ«bu koplietoÅ”anu starp visiem piekļuves procesa dalÄ«bniekiem. Katram lietotājam ir piekļuve noteiktiem objektiem vai darbÄ«bām. BÅ«tÄ«bā Å”eit tiesÄ«bu subjektu kopums atbilst objektu kopumam. Tika konstatēts, ka Å”is modelis ir pārāk elastÄ«gs un pārāk grÅ«ti uzturējams: piekļuves saraksti galu galā kļūst milzÄ«gi un grÅ«ti kontrolējami.

Otrais modelis ir Obligātā piekļuves kontrole (MAC ā€” obligāta piekļuves kontrole). Saskaņā ar Å”o modeli katrs lietotājs saņem piekļuvi objektam saskaņā ar pieŔķirto piekļuvi noteiktam datu konfidencialitātes lÄ«menim. AttiecÄ«gi objekti ir jāklasificē atbilstoÅ”i to konfidencialitātes lÄ«menim. AtŔķirÄ«bā no pirmā elastÄ«gā modeļa, Å”is, gluži pretēji, izrādÄ«jās pārāk stingrs un ierobežojoÅ”s. Tā izmantoÅ”ana nav attaisnojama, ja uzņēmuma rÄ«cÄ«bā ir daudz dažādu informācijas resursu: lai diferencētu pieeju dažādiem resursiem, bÅ«s jāievieÅ” daudzas kategorijas, kas nepārklāsies.

Å o divu metožu acÄ«mredzamo nepilnÄ«bu dēļ IT kopiena ir turpinājusi izstrādāt modeļus, kas ir elastÄ«gāki un vienlaikus vairāk vai mazāk universāli, lai atbalstÄ«tu dažāda veida organizācijas piekļuves kontroles politikas. Un tad parādÄ«jās treÅ”ais uz lomām balstÄ«ts piekļuves kontroles modelis! Å Ä« pieeja ir izrādÄ«jusies visdaudzsoloŔākā, jo prasa ne tikai lietotāja identitātes autorizāciju, bet arÄ« viņa darbÄ«bas funkcijas sistēmās.

Pirmo skaidri aprakstīto lomu modeļa struktūru ierosināja amerikāņu zinātnieki Deivids Ferailo un Ričards Kūns no ASV Nacionālā standartu un tehnoloģiju institūta 1992. gadā. Tad pirmo reizi parādījās termins RBAC (uz lomu balstīta piekļuves kontrole). Šie pētījumi un galveno komponentu apraksti, kā arī to sakarības veidoja pamatu INCITS 359-2012 standartam, kas joprojām ir spēkā un ir apstiprināts Starptautiskās informācijas tehnoloģiju standartu komitejā (INCITS).

Standarts definē lomu kā "darba funkciju organizācijas kontekstā ar noteiktu semantiku saistÄ«bā ar pilnvarām un atbildÄ«bu, kas pieŔķirta lomai pieŔķirtajam lietotājam". Dokuments nosaka RBAC pamatelementus - lietotājus, sesijas, lomas, atļaujas, darbÄ«bas un objektus, kā arÄ« attiecÄ«bas un savstarpējos savienojumus starp tiem.

Standarts nodroÅ”ina minimālo nepiecieÅ”amo struktÅ«ru, lai izveidotu lomu modeli ā€” tiesÄ«bu apvienoÅ”ana lomās un pēc tam piekļuves pieŔķirÅ”ana lietotājiem, izmantojot Ŕīs lomas. Ieskicēti mehānismi lomu salikÅ”anai no objektiem un operācijām, aprakstÄ«ta lomu hierarhija un pilnvaru pārmantoÅ”ana. Galu galā jebkurā uzņēmumā ir lomas, kas apvieno pamatpilnvaras, kas nepiecieÅ”amas visiem uzņēmuma darbiniekiem. Tā varētu bÅ«t piekļuve e-pastam, EDMS, korporatÄ«vajam portālam utt. Å Ä«s atļaujas var iekļaut vienā vispārÄ«gā lomā, ko sauc par ā€œdarbiniekuā€, un nebÅ«s nepiecieÅ”ams atkal un atkal uzskaitÄ«t visas pamattiesÄ«bas katrā augstākā lÄ«meņa lomā. Pietiek vienkārÅ”i norādÄ«t ā€œdarbiniekaā€ lomai raksturÄ«go mantojumu.

Mēs veidojam uz lomām balstÄ«tu piekļuves kontroles modeli. Pirmā daļa, sagatavoÅ”anās

Vēlāk standarts tika papildināts ar jauniem piekļuves atribÅ«tiem, kas saistÄ«ti ar pastāvÄ«gi mainÄ«go vidi. Ir pievienota iespēja ieviest statiskus un dinamiskus ierobežojumus. Statiskās lomas nozÄ«mē neiespējamÄ«bu apvienot lomas (tāda pati ievade un operāciju kontrole, kas minēta iepriekÅ”). Dinamiskos ierobežojumus var noteikt, mainot parametrus, piemēram, laiku (darba/bez darba laiks vai dienas), atraÅ”anās vietu (birojs/mājas) utt.

Ir vērts pieminēt atseviŔķi uz atribÅ«tiem balstÄ«ta piekļuves kontrole (ABAC ā€” uz atribÅ«tiem balstÄ«ta piekļuves kontrole). Pieeja ir balstÄ«ta uz piekļuves pieŔķirÅ”anu, izmantojot atribÅ«tu koplietoÅ”anas noteikumus. Å o modeli var izmantot atseviŔķi, taču diezgan bieži tas aktÄ«vi papildina klasisko lomu modeli: noteiktai lomai var pievienot lietotāju, resursu un ierīču atribÅ«tus, kā arÄ« laiku vai atraÅ”anās vietu. Tas ļauj izmantot mazāk lomu, ieviest papildu ierobežojumus un padarÄ«t piekļuvi pēc iespējas mazāku, tādējādi uzlabojot droŔību.

Piemēram, grāmatvedim var atļaut piekļuvi kontiem, ja viņŔ strādā noteiktā reÄ£ionā. Tad speciālista atraÅ”anās vieta tiks salÄ«dzināta ar noteiktu atsauces vērtÄ«bu. Vai arÄ« varat pieŔķirt piekļuvi kontiem tikai tad, ja lietotājs piesakās no ierÄ«ces, kas iekļauta atļauto kontu sarakstā. Labs papildinājums paraugam, taču reti tiek izmantots atseviŔķi, jo ir jāizveido daudzi noteikumi un atļauju vai ierobežojumu tabulas.

Ä»aujiet man sniegt jums piemēru, kā izmantot ABAC no manas ā€œiepriekŔējās dzÄ«vesā€. MÅ«su bankai bija vairākas filiāles. Klientu biroju darbinieki Å”ajās filiālēs veica tieÅ”i tādas paÅ”as darbÄ«bas, bet galvenajā sistēmā bija jāstrādā tikai ar kontiem savā reÄ£ionā. Pirmkārt, mēs sākām veidot atseviŔķas lomas katram reÄ£ionam ā€” un Ŕādu lomu bija tik daudz ar atkārtotu funkcionalitāti, bet ar piekļuvi dažādiem kontiem! Pēc tam, izmantojot lietotāja atraÅ”anās vietas atribÅ«tu un saistot to ar noteiktu kontu klāstu, kas jāpārskata, mēs ievērojami samazinājām lomu skaitu sistēmā. Rezultātā lomas palika tikai vienai filiālei, kuras tika atkārtotas atbilstoÅ”ajiem amatiem visās pārējās bankas teritoriālajās nodaļās.

Tagad parunāsim par nepiecieÅ”amajiem sagatavoÅ”anās posmiem, bez kuriem vienkārÅ”i nav iespējams izveidot darba paraugu.

Solis 1. Izveidojiet funkcionālo modeli

Jums vajadzētu sākt ar funkcionāla modeļa izveidi - augstākā lÄ«meņa dokumentu, kurā detalizēti aprakstÄ«ta katras nodaļas un katras pozÄ«cijas funkcionalitāte. Parasti informācija tajā tiek ievadÄ«ta no dažādiem dokumentiem: atseviŔķu struktÅ«rvienÄ«bu - departamentu, nodaļu, departamentu - amatu apraksti un noteikumi. Funkcionālais modelis ir jāsaskaņo ar visām ieinteresētajām nodaļām (biznesa, iekŔējās kontroles, droŔības) un jāapstiprina uzņēmuma vadÄ«bai. Kam paredzēts Å”is dokuments? Lai paraugs uz to varētu atsaukties. Piemēram, jÅ«s gatavojaties izveidot paraugu, pamatojoties uz esoÅ”ajām darbinieku tiesÄ«bām - izlādētas no sistēmas un ā€œsamazinātas lÄ«dz kopsaucējamā€. Pēc tam, vienojoties par saņemtajām lomām ar sistēmas uzņēmuma Ä«paÅ”nieku, var atsaukties uz konkrētu funkcionālā modeļa punktu, uz kura pamata lomai tiek iekļautas Ŕīs vai citas tiesÄ«bas.

2. solis. Mēs auditējam IT sistēmas un sastādām prioritāŔu plānu

Otrajā posmā jums jāveic IT sistēmu audits, lai saprastu, kā tiek organizēta piekļuve tām. Piemēram, manā finanÅ”u uzņēmumā bija vairāki simti informācijas sistēmu. Visām sistēmām bija daži uz lomām balstÄ«tas pārvaldÄ«bas pamati, lielākajai daļai bija dažas lomas, bet galvenokārt uz papÄ«ra vai sistēmas direktorijā - tās bija sen novecojuÅ”as, un piekļuve tām tika pieŔķirta, pamatojoties uz reāliem lietotāju pieprasÄ«jumiem. Protams, ir vienkārÅ”i neiespējami izveidot paraugu vairākos simtos sistēmu vienlaikus, kaut kur ir jāsāk. Mēs veicām piekļuves kontroles procesa padziļinātu analÄ«zi, lai noteiktu tā brieduma lÄ«meni. AnalÄ«zes procesā tika izstrādāti informācijas sistēmu prioritāŔu noteikÅ”anas kritēriji - kritiskums, gatavÄ«ba, ekspluatācijas pārtraukÅ”anas plāni u.c. Ar viņu palÄ«dzÄ«bu mēs sarindojām Å”o sistēmu lomu modeļu izstrādi/atjaunināŔanu. Un tad mēs iekļāvām lomu modeļus integrācijas plānā ar Identity Management risinājumu, lai automatizētu piekļuves kontroli.

Tātad, kā noteikt sistēmas kritiskumu? Atbildiet sev uz Ŕādiem jautājumiem:

  • Vai sistēma ir saistÄ«ta ar darbÄ«bas procesiem, no kuriem ir atkarÄ«ga uzņēmuma pamatdarbÄ«ba?
  • Vai sistēmas darbÄ«bas traucējumi ietekmēs uzņēmuma aktÄ«vu integritāti?
  • Kāds ir maksimāli pieļaujamais sistēmas dÄ«kstāves laiks, kuru sasniedzot nav iespējams atjaunot darbÄ«bu pēc pārtraukuma?
  • Vai informācijas integritātes pārkāpums sistēmā var radÄ«t neatgriezeniskas gan finansiālas, gan reputācijas sekas?
  • Kritiskums pret krāpÅ”anu. Funkcionalitātes klātbÅ«tne, ja tā netiek pareizi kontrolēta, var izraisÄ«t iekŔējas/ārējas krāpnieciskas darbÄ«bas;
  • Kādas ir Å”o sistēmu juridiskās prasÄ«bas un iekŔējie noteikumi un procedÅ«ras? Vai par noteikumu neievēroÅ”anu tiks uzlikti naudas sodi no regulatoriem?

MÅ«su finanÅ”u uzņēmumā mēs veicām Ŕādu revÄ«ziju. VadÄ«ba izstrādāja piekļuves tiesÄ«bu pārskatÄ«Å”anas audita procedÅ«ru, lai vispirms aplÅ«kotu esoÅ”os lietotājus un tiesÄ«bas tajās informācijas sistēmās, kuras bija visaugstāko prioritāŔu sarakstā. DroŔības departaments tika noteikts kā Ŕī procesa Ä«paÅ”nieks. Bet, lai iegÅ«tu pilnÄ«gu priekÅ”statu par piekļuves tiesÄ«bām uzņēmumā, procesā bija nepiecieÅ”ams iesaistÄ«t IT un biznesa nodaļas. Un te sākās strÄ«di, nesapraÅ”anās un dažkārt pat sabotāža: neviens nevēlas atrauties no saviem lÄ«dzÅ”inējiem pienākumiem un iesaistÄ«ties kādās, no pirmā acu uzmetiena nesaprotamās darbÄ«bās.

NB Lielajiem uzņēmumiem ar attÄ«stÄ«tiem IT procesiem droÅ”i vien ir zināma IT audita procedÅ«ra - IT vispārējās kontroles (ITGC), kas ļauj identificēt IT procesu nepilnÄ«bas un izveidot kontroli, lai pilnveidotu procesus atbilstoÅ”i labākajai praksei (ITIL, COBIT, IT). PārvaldÄ«ba utt.) Šāds audits ļauj IT un biznesam labāk saprast vienam otru un izstrādāt kopÄ«gu attÄ«stÄ«bas stratēģiju, analizēt riskus, optimizēt izmaksas un izstrādāt efektÄ«vākas pieejas darbam.

Mēs veidojam uz lomām balstÄ«tu piekļuves kontroles modeli. Pirmā daļa, sagatavoÅ”anās

Viena no audita jomām ir informācijas sistēmu loÄ£iskās un fiziskās piekļuves parametru noteikÅ”ana. IegÅ«tos datus ņēmām par pamatu turpmākai izmantoÅ”anai parauga veidoÅ”anā. Å Ä« audita rezultātā mums bija IT sistēmu reÄ£istrs, kurā tika noteikti to tehniskie parametri un doti apraksti. Turklāt katrai sistēmai tika noteikts Ä«paÅ”nieks no biznesa virziena, kura interesēs tā tika vadÄ«ta: viņŔ bija atbildÄ«gs par biznesa procesiem, kuriem Ŕī sistēma kalpoja. Tika iecelts arÄ« IT servisa vadÄ«tājs, kurÅ” atbild par biznesa vajadzÄ«bu tehnisko realizāciju konkrētai IS. Tika fiksētas uzņēmumam kritiskākās sistēmas un to tehniskie parametri, nodoÅ”anas ekspluatācijā un izbeigÅ”anas termiņi u.c.. Å ie parametri ļoti palÄ«dzēja, gatavojoties parauga izveidei.

3. solis Izveidojiet metodiku

Jebkura biznesa panākumu atslēga ir pareizā metode. Tāpēc gan parauga veidoÅ”anai, gan audita veikÅ”anai ir jāizveido metodika, kurā aprakstām struktÅ«rvienÄ«bu mijiedarbÄ«bu, nosakām atbildÄ«bu uzņēmuma nolikumā utt.
Vispirms jums ir jāpārbauda visi pieejamie dokumenti, kas nosaka piekļuves un tiesÄ«bu pieŔķirÅ”anas procedÅ«ru. Labā nozÄ«mē procesi ir jādokumentē vairākos lÄ«meņos:

  • vispārējās korporatÄ«vās prasÄ«bas;
  • prasÄ«bas informācijas droŔības jomām (atkarÄ«bā no organizācijas darbÄ«bas jomām);
  • prasÄ«bas tehnoloÄ£iskajiem procesiem (instrukcijas, piekļuves matricas, vadlÄ«nijas, konfigurācijas prasÄ«bas).

MÅ«su finanÅ”u uzņēmumā mēs atradām daudz novecojuÅ”u dokumentu, kas mums bija jānes saskaņā ar jaunajiem procesiem, kas tiek ieviesti.

Pēc vadÄ«bas rÄ«kojuma tika izveidota darba grupa, kurā bija droŔības, IT, biznesa un iekŔējās kontroles pārstāvji. RÄ«kojumā tika iezÄ«mēti grupas izveides mērÄ·i, darbÄ«bas virziens, pastāvÄ“Å”anas periods un atbildÄ«gie no katras puses. Papildus izstrādājām audita metodiku un lomu modeļa konstruÄ“Å”anas procedÅ«ru: par tām vienojās visi atbildÄ«gie jomu pārstāvji un apstiprināja uzņēmuma vadÄ«ba.

Dokumenti, kas apraksta darbu veikÅ”anas kārtÄ«bu, termiņus, pienākumus utt. - garantija, ka ceļā uz loloto mērÄ·i, kas sākotnēji nav skaidrs visiem, nevienam neradÄ«sies jautājumi "kāpēc mēs to darām, kāpēc mums tas ir vajadzÄ«gs utt." un nebÅ«s iespējas ā€œatlēktā€ vai bremzēt procesu.

Mēs veidojam uz lomām balstÄ«tu piekļuves kontroles modeli. Pirmā daļa, sagatavoÅ”anās

4. solis. Labojiet esoŔā piekļuves kontroles modeļa parametrus

Mēs izstrādājam tā saukto ā€œsistēmas pasiā€ piekļuves kontroles ziņā. BÅ«tÄ«bā Ŕī ir anketa par konkrētu informācijas sistēmu, kurā tiek ierakstÄ«ti visi algoritmi piekļuves kontrolei. Uzņēmumi, kas jau ir ieviesuÅ”i IdM klases risinājumus, visticamāk, ir pazÄ«stami ar Ŕādu anketu, jo ar to sākas sistēmu izpēte.

Daži parametri par sistēmu un Ä«paÅ”niekiem ieplÅ«da anketā no IT reÄ£istra (skat. 2. soli, audits), taču tika pievienoti arÄ« jauni:

  • kā tiek pārvaldÄ«ti konti (tieÅ”i datu bāzē vai ar programmatÅ«ras saskarnēm);
  • kā lietotāji piesakās sistēmā (izmantojot atseviŔķu kontu vai izmantojot AD kontu, LDAP utt.);
  • kādi piekļuves lÄ«meņi sistēmai tiek izmantoti (lietojumprogrammas lÄ«menis, sistēmas lÄ«menis, tÄ«kla failu resursu sistēmas izmantoÅ”ana);
  • to serveru apraksts un parametri, uz kuriem sistēma darbojas;
  • kādas konta pārvaldÄ«bas darbÄ«bas tiek atbalstÄ«tas (bloÄ·Ä“Å”ana, pārdēvÄ“Å”ana utt.);
  • kādi algoritmi vai noteikumi tiek izmantoti sistēmas lietotāja identifikatora Ä£enerÄ“Å”anai;
  • kādu atribÅ«tu var izmantot, lai izveidotu saikni ar darbinieka ierakstu personāla sistēmā (pilns vārds, personāla numurs utt.);
  • visi iespējamie konta atribÅ«ti un to aizpildÄ«Å”anas noteikumi;
  • kādas piekļuves tiesÄ«bas pastāv sistēmā (lomas, grupas, atomtiesÄ«bas utt., vai ir ligzdotas vai hierarhiskas tiesÄ«bas);
  • piekļuves tiesÄ«bu sadalÄ«Å”anas mehānismi (pēc amata, departamenta, funkcionalitātes utt.);
  • Vai sistēmai ir tiesÄ«bu noŔķirÅ”anas noteikumi (SOD ā€“ Pienākumu nodalÄ«Å”ana) un kā tie darbojas;
  • kā sistēmā tiek apstrādāti notikumi par prombÅ«tni, pārcelÅ”anu, atlaiÅ”anu, darbinieku datu aktualizÄ“Å”anu u.c.

Šo sarakstu var turpināt, detalizēti norādot dažādus parametrus un citus objektus, kas ir iesaistīti piekļuves kontroles procesā.

5. darbÄ«ba. Izveidojiet uz uzņēmējdarbÄ«bu orientētu atļauju aprakstu

Vēl viens dokuments, kas mums bÅ«s nepiecieÅ”ams, veidojot lomu modeli, ir uzziņu grāmata par visām iespējamajām pilnvarām (tiesÄ«bām), kuras var pieŔķirt lietotājiem informācijas sistēmā, ar detalizētu biznesa funkcijas aprakstu, kas atrodas aiz tā. Bieži vien sistēmas iestādes ir Å”ifrētas ar noteiktiem nosaukumiem, kas sastāv no burtiem un cipariem, un uzņēmuma darbinieki nevar saprast, kas slēpjas aiz Å”iem simboliem. Tad viņi aiziet uz IT servisu, un tur... arÄ« nevar atbildēt uz jautājumu, piemēram, par reti izmantotām tiesÄ«bām. Pēc tam jāveic papildu pārbaude.

Ir labi, ja jau ir uzņēmuma apraksts vai pat ja Ŕīs tiesÄ«bas ir apvienotas grupās un lomās. Dažām lietojumprogrammām labākā prakse ir izveidot Ŕādu atsauci izstrādes stadijā. Taču tas nenotiek bieži, tāpēc mēs atkal ejam uz IT nodaļu, lai apkopotu informāciju par visām iespējamām tiesÄ«bām un aprakstÄ«tu tās. MÅ«su ceļvedis galu galā ietvers tālāk norādÄ«to.

  • iestādes nosaukums, ieskaitot objektu, uz kuru attiecas piekļuves tiesÄ«bas;
  • darbÄ«ba, ko atļauts veikt ar objektu (apskatÄ«Å”ana, maiņa u.tml., ierobežojuma iespēja, piemēram, pēc teritoriālā pamata vai klientu grupas);
  • autorizācijas kods (sistēmas funkcijas/pieprasÄ«juma kods un nosaukums, ko var izpildÄ«t, izmantojot autorizāciju);
  • iestādes apraksts (detalizēts apraksts par darbÄ«bām IS, piemērojot pilnvaru, un to sekas uz procesu;
  • atļaujas statuss: ā€œAktÄ«vsā€ (ja atļauja pieŔķirta vismaz vienam lietotājam) vai ā€œNav aktÄ«vaā€ (ja atļauja netiek izmantota).

6. darbība Mēs lejupielādējam datus par lietotājiem un tiesībām no sistēmām un salīdzinām tos ar personāla avotu

SagatavoÅ”anas pēdējā posmā no informācijas sistēmām ir jālejupielādē dati par visiem lietotājiem un viņiem paÅ”laik pieŔķirtajām tiesÄ«bām. Å eit ir divi iespējamie scenāriji. Pirmkārt: droŔības nodaļai ir tieÅ”a piekļuve sistēmai un iespēja lejupielādēt attiecÄ«gos pārskatus, kas nenotiek bieži, bet ir ļoti ērti. Otrkārt: nosÅ«tām pieprasÄ«jumu IT saņemt atskaites vajadzÄ«gajā formātā. Pieredze rāda, ka ar IT vienoties un iegÅ«t nepiecieÅ”amos datus pirmajā reizē nav iespējams. Ir nepiecieÅ”ams veikt vairākas pieejas, lÄ«dz informācija tiek saņemta vēlamajā formā un formātā.

Kādi dati ir jālejupielādē:

  • Konta vārds
  • Tā darbinieka pilns vārds, uzvārds, kuram tas ir pieŔķirts
  • Statuss (aktÄ«vs vai bloķēts)
  • Konta izveides datums
  • Pēdējās lietoÅ”anas datums
  • Pieejamo tiesÄ«bu/grupu/lomu saraksts

Tātad, mēs saņēmām lejupielādes no sistēmas ar visiem lietotājiem un visām viņiem pieŔķirtajām tiesÄ«bām. Un viņi nekavējoties nolika malā visus bloķētos kontus, jo darbs pie parauga veidoÅ”anas tiks veikts tikai aktÄ«viem lietotājiem.

Pēc tam, ja jÅ«su uzņēmumam nav automatizētu lÄ«dzekļu, lai bloķētu piekļuvi atlaistajiem darbiniekiem (tas bieži notiek) vai arÄ« tajā ir automatizācija, kas ne vienmēr darbojas pareizi, jums ir jāidentificē visas "miruŔās dvēseles". Runa ir par jau atlaisto darbinieku kontiem, kuriem tiesÄ«bas nez kāpēc nav bloķētas - vajag bloķēt. Lai to izdarÄ«tu, mēs salÄ«dzinām augÅ”upielādētos datus ar personāla avotu. Personāla izkrauÅ”ana iepriekÅ” jāsaņem arÄ« nodaļā, kas uztur personāla datu bāzi.

AtseviŔķi ir jāatliek konti, kuru Ä«paÅ”nieki netika atrasti personāla datu bāzē, nevienam nav pieŔķirti - tas ir, bezsaimnieka. Izmantojot Å”o sarakstu, mums bÅ«s nepiecieÅ”ams pēdējās lietoÅ”anas datums: ja tas ir pavisam nesen, mums joprojām bÅ«s jāmeklē Ä«paÅ”nieki. Tas var ietvert ārējo darbuzņēmēju kontus vai pakalpojumu kontus, kas nav pieŔķirti nevienam, bet ir saistÄ«ti ar jebkādiem procesiem. Lai uzzinātu, kam konti pieder, varat nosÅ«tÄ«t vēstules visām nodaļām ar lÅ«gumu atbildēt. Kad Ä«paÅ”nieki ir atrasti, mēs ievadām datus par viņiem sistēmā: tādējādi tiek identificēti visi aktÄ«vie konti, bet pārējie tiek bloķēti.

TiklÄ«dz mÅ«su augÅ”upielādēs ir notÄ«rÄ«ti nevajadzÄ«gi ieraksti un paliek tikai aktÄ«vie konti, mēs varam sākt veidot paraugu konkrētai informācijas sistēmai. Bet par to es jums pastāstÄ«Å”u nākamajā rakstā.

Autore: Ludmila Sevastjanova, Solar inRights veicināŔanas menedžere

Avots: www.habr.com

Pievieno komentāru