{"id":87793,"date":"2020-07-10T13:41:57","date_gmt":"2020-07-10T11:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya"},"modified":"2020-07-10T13:41:57","modified_gmt":"2020-07-10T11:41:57","slug":"stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya","title":{"rendered":"Loome rollimudelit juurdep\u00e4\u00e4su haldamiseks. Esimene osa, ettevalmistav.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Praegu t\u00f6\u00f6tan ma tarkvaratoote tootja juures, spetsialiseerudes juurdep\u00e4\u00e4su haldamise lahendustele. Minu varasem kogemus tuli tellija poolelt \u2013 suurest finantsasutusest. Toona ei saanud meie turbejuurdep\u00e4\u00e4su meeskond uhkeldada suure kompetentsiga IdM-i alal. Me \u00f5ppisime palju protsessi k\u00e4igus ja pidime palju vigu tegema, et ettev\u00f5ttes v\u00e4lja t\u00f6\u00f6tada t\u00f5hus kasutajate \u00f5iguste haldamise mehhanism infotehnoloogilistes s\u00fcsteemides.
\n\"Loome
\nSamas \u00fchendades oma tellija poolelt saadud v\u00e4\u00e4rtusliku kogemuse tootja teadmiste ja oskustega, tahan jagada teiega praktilist, samm-sammult juhendit: kuidas luua suures ettev\u00f5ttes rollip\u00f5hine juurdep\u00e4\u00e4su haldamise mudel ja mida see l\u00f5puks toob. Minu juhend koosneb kahest osast: esimene \u2013 valmistume mudeli loomiseks, teine \u2013 loome ise mudeli. Teie ees on esimene, ettevalmistav osa.
\n<\/a><\/noindex>
\nN.B.<\/b> Rollimudeli loomine on kahjuks mitte l\u00f5pptulemus, vaid protsess. T\u00e4psemalt on see isegi osa protsessist, mille k\u00e4igus teie ettev\u00f5ttes luuakse ligip\u00e4\u00e4su haldamise \u00f6kos\u00fcsteem. Seega valmistuge pika m\u00e4ngu jaoks.
\n<\/i>
\nAlustame selgusest \u2013 mis siis on rollip\u00f5hine ligip\u00e4\u00e4su haldamine? Oletame, et teil on suur pank, kus t\u00f6\u00f6tab k\u00fcmneid tuhandeid, isegi sadu tuhandeid t\u00f6\u00f6tajaid (subjekte), kellel on k\u00fcmneid ligip\u00e4\u00e4su\u00f5igusi sadu sisepanganduse infos\u00fcsteemide (objektide) jaoks. Ja n\u00fc\u00fcd korrutage objektide arv subjektide arvuga \u2013 just nii palju seoseid peate alguses looma ja seej\u00e4rel kontrollima. Kas on v\u00f5imalik seda k\u00e4sitsi teha? Loomulikult mitte \u2013 just selle \u00fclesande lahendamiseks loodi rollid.<\/p>\n

Roll on m\u00e4\u00e4ratletud \u00f5iguste kogum, mis on vajalik kasutajale v\u00f5i kasutajate grupile teatud t\u00f6\u00f6\u00fclesannete t\u00e4itmiseks. Igal t\u00f6\u00f6tajal v\u00f5ib olla \u00fcks v\u00f5i mitu rolli, ning iga roll v\u00f5ib sisaldada \u00fchte v\u00f5i mitmeid \u00f5igusi, mis on kasutajale antud selle rolli raames. Rollid v\u00f5ivad olla seotud kindlate ametikohtade, osakondade v\u00f5i t\u00f6\u00f6tajate funktsionaalsete \u00fclesannetega.<\/p>\n

\"Loome
\n
\nRollid luuakse tavaliselt t\u00f6\u00f6taja eraldi volitustest igas teabe s\u00fcsteemis. Seej\u00e4rel moodustatakse igas s\u00fcsteemis olemasolevatest rollidest globaalsed \u00e4rirollid. N\u00e4iteks \u00e4riroll 'krediidihaldur' h\u00f5lmab endas mitmeid eraldi rolle teabe s\u00fcsteemides, mida kasutatakse panga kliendib\u00fcroos. Oletame, et sellistes s\u00fcsteemides nagu p\u00f5hiautomaatne panganduss\u00fcsteem, kassamoodul, elektroonilise dokumendihalduss\u00fcsteem, teenusehaldur ja teised. \u00c4riv\u00f5rke seostatakse tavaliselt organisatsioonilis-struktuurse \u00fclesehitusega \u2013 lihtsamalt \u00f6eldes, ettev\u00f5tte osakondade ja ametikohtade kogumiga. Nii moodustatakse globaalne rollide maatriks (n\u00e4idatakse tabelis allpool).<\/p>\n

\"Loome
\n
\nOluline on m\u00e4rkida, et 100% rollimudeli loomine, andes iga ametikoha t\u00f6\u00f6tajatele k\u00f5ik vajalikud \u00f5igused kommertsstruktuuris, on lihtsalt v\u00f5imatu. Ja see pole ka vajalik. Rollimudel ei saa olla staatiline, kuna see s\u00f5ltub pidevalt muutuvas keskkonnas. Samuti s\u00f5ltub see ettev\u00f5tte \u00e4ritegevuse muutumisest, mis omakorda m\u00f5jutab organisatsiooni struktuuri ja funktsionaalsust. Ning sellest, et ressursse ei pruugita t\u00e4ielikult tagada, et t\u00f6\u00f6\u00fclesandeid ei j\u00e4rgita, et p\u00fc\u00fctakse kasumit teenida ohutuse arvelt ja paljusid muid tegureid. Seep\u00e4rast tuleb luua rollimudel, mis suudab katta kuni 80% kasutajate vajadustest nende ametikohta m\u00e4\u00e4ramisel vajalike p\u00f5hioigustega. Ja \u00fclej\u00e4\u00e4nud 20% saavad nad vajadusel hiljem eraldi taotluste kaudu k\u00fcsida.<\/p>\n

Muidugi, v\u00f5ite k\u00fcsida: \u201eKas 100% rollimudeleid \u00fcldse ei eksisteeri?\u201c Muidugi, selliseid kohtab n\u00e4iteks mittetulundus\u00fchingutes, mis ei ole pidevatele muutustele alluvad, nagu n\u00e4iteks teadus- ja arendusasutustes. V\u00f5i ka kaitset\u00f6\u00f6stuse organisatsioonides, kus k\u00f5rge turvalisuse tase on prioriteet. On ka juhtumeid, kus see toimub ka kommertsstruktuurides, kuid ainult konkreetse osakonna raames, mille t\u00f6\u00f6 on piisavalt staatiline ja ettearvatav protsess.<\/p>\n

Peamine eelis rollihalduses on \u00f5iguste v\u00e4ljastamise lihtsustamine, kuna rollide arvu on oluliselt v\u00e4hem kui infotehnoloogia s\u00fcsteemi kasutajate arvu. Ja see kehtib iga valdkonna kohta.<\/p>\n

V\u00f5tame n\u00e4iteks jaekaubanduse ettev\u00f5tte: seal t\u00f6\u00f6tab tuhandeid m\u00fc\u00fcjaid, kuid s\u00fcsteemis N on neil k\u00f5ikidel samad \u00f5igused ja neile luuakse vaid \u00fcks roll. Kui ettev\u00f5ttesse tuleb uus m\u00fc\u00fcja, m\u00e4\u00e4ratakse talle automaatselt vajalik roll, millel on juba olemas k\u00f5ik vajalikud volitused. Samuti saab \u00fche kliki abil muuta \u00f5igusi tuhandete m\u00fc\u00fcjate jaoks, n\u00e4iteks lisada uus aruandlusv\u00f5imalus. Ei ole vaja teha tuhandeid toiminguid, sidudes uue \u00f5iguse iga kasutajakontoga \u2013 piisab, kui lisada see v\u00f5imalus rolli, ja see ilmub k\u00f5igile m\u00fc\u00fcjatele samal ajal.<\/p>\n

Veel \u00fcks rullimise haldamise eelis on kokkusobimatute volituste v\u00e4ljastamise v\u00e4listamine. See t\u00e4hendab, et t\u00f6\u00f6taja, kellel on s\u00fcsteemis teatud roll, ei saa samal ajal omada teist rolli, mille \u00f5igused ei tohiks olla koosk\u00f5las esimese \u00f5igustega. Hea n\u00e4ide on keeld \u00fchendada rahavoogude sisestamise ja kontrollimise funktsioone.<\/p>\n

K\u00f5ik, keda huvitab, kuidas rullimise \u00f5iguse haldamine \u00fcldiselt tekkis, v\u00f5ivad
\n sukelduda ajalukku<\/b>
\n Ajaloo vaatamine n\u00e4itab, et IT-kogukond m\u00f5tles juurdep\u00e4\u00e4suhalduse meetoditele esmakordselt juba XX sajandi 70. aastatel. Kuigi rakendused olid siis \u00fcsna lihtsad, soovis k\u00f5igile mugavalt juurdep\u00e4\u00e4su nendele hallata. Kasutajate \u00f5iguste andmine, muutmine ja kontrollimine oli vajalik, et lihtsustada arusaamist, millised on iga\u00fche juurdep\u00e4\u00e4suv\u00f5imalused. Kuid sel ajal puudusid \u00fcldised standardid, t\u00f6\u00f6tati v\u00e4lja esimesed juurdep\u00e4\u00e4suhalduss\u00fcsteemid ning iga ettev\u00f5te juhindus oma isiklikest arusaamadest ja reeglitest.<\/p>\n

T\u00e4naseks on teada palju erinevaid juurdep\u00e4\u00e4suhalduse mudeleid, kuid need ei tekkisid kohe. Peatume nende mudelite peal, mis on m\u00e4rkimisv\u00e4\u00e4rselt panustanud selle valdkonna arengusse.<\/p>\n

Esimene ja v\u00f5ib-olla k\u00f5ige lihtsam mudel on Dikreetne (valikuline) juurdep\u00e4\u00e4suhaldus<\/b> (DAC \u2013 Discretionary access control). See mudel t\u00e4hendab, et juurdep\u00e4\u00e4su \u00f5iguste jagamine toimub k\u00f5igi osalejate vahel. Igal kasutajal on juurdep\u00e4\u00e4s teatud objektidele v\u00f5i toimingutele. Sisuliselt vastab siin paljude \u00f5iguste subjektide hulk paljudele objektidele. See mudel on tunnustatud liiga paindlikuks ja liiga keeruliseks haldamiseks: juurdep\u00e4\u00e4su loendid muutuvad aja jooksul tohutuks ja neid on raske kontrollida.<\/p>\n

Teine mudel on Mandaatne juurdep\u00e4\u00e4suhaldus (MAC \u2013 Mandatory access control)<\/b>. Selle mudeli kohaselt saab iga kasutaja juurdep\u00e4\u00e4su objektile vastavalt kehtestatud litsentsile teatud tasemele konfidentsiaalsusandmete osas. Vastavalt sellele peavad objektid olema kategoriseeritud vastavalt konfidentsiaalsuse tasemele. Erinevalt esimesest paindlikust mudelist osutus see aga liiga rangeks ja piiravaks. Selle rakendamine ei \u00f5igusta end, kui ettev\u00f5ttes on mitmekesised teabeallikad: juurdep\u00e4\u00e4su piirmiseks erinevatele allikatele tuleb kehtestada lugematul hulgal kategooriaid, mis omavahel ei kohtu.<\/p>\n

Kuna nende kahe meetodi ilmsetest puudustest j\u00e4tkas IT kogukond mudelite loomist, mis oleksid paindlikumad ja enam-v\u00e4hem universaalsed, et toetada erinevaid organisatsioonilise juurdep\u00e4\u00e4su kontrolli poliitikas. Just siis tekkis kolmas rollip\u00f5hine juurdep\u00e4\u00e4su haldamise mudel!<\/b> See l\u00e4henemine osutus k\u00f5ige t\u00f5husamaks, kuna see n\u00f5uab mitte ainult kasutaja isiksuse autoriseerimist, vaid ka tema t\u00f6\u00f6h\u00f5ivet s\u00fcsteemides.<\/p>\n

Esimese selgelt kirjeldatud rollimudeli struktuuri pakkusid Ameerika teadlased David Ferraiolo ja Richard Kuhn USA Riiklikust Standardite ja Tehnoloogia Instituudist 1992. aastal. Siis ilmus esmakordselt m\u00f5isted RBAC (rollip\u00f5hine juurdep\u00e4\u00e4su haldamine). <\/b>Need uuringud ja peamiste komponentide kirjeldused koos nende omavaheliste seostega olid INCITS 359-2012 kehtiva standardi aluseks, mille on heaks kiitnud Rahvusvaheline Infotehnoloogia Standardite Komitee (INCITS).<\/p>\n

Standard m\u00e4\u00e4ratleb rolli kui \"ametikohta organisatsiooni kontekstis, millel on seotud semantika volituste ja vastutuse osas, mis on m\u00e4\u00e4ratud kasutajale, kellele roll antakse\". Dokumendis m\u00e4\u00e4ratletakse RBAC p\u00f5hielemendid \u2013 kasutajad, seansid, rollid, load, toimingud ja objektid, samuti nendevahelised suhted ja seosed.<\/p>\n

Standardis on esitatud minimaalne vajalik struktuur rollimudeli loomiseks \u2013 \u00f5iguste koondamine rollidesse ja seej\u00e4rel juurdep\u00e4\u00e4su andmine kasutajatele l\u00e4bi nende rollide. M\u00e4\u00e4ratletud on mehhanismid rollide koostamiseks objektidest ja toimingutest, kirjeldatakse rollide hierarhiat ja volituste p\u00e4rimist. Igas ettev\u00f5ttes on rollid, mis \u00fchendavad elementaarseid volitusi, mis on vajalikud k\u00f5ikidele ettev\u00f5tte t\u00f6\u00f6tajatele. See v\u00f5ib olla juurdep\u00e4\u00e4s e-posti, dokumentide haldamise s\u00fcsteemi, ettev\u00f5tte portaalile jne. Need volitused v\u00f5ib koondada \u00fche \u00fcldise rolli alla nimega \"t\u00f6\u00f6taja\", ja ei ole vaja iga k\u00f5rgeimal tasemel rollis iga kord loetleda k\u00f5iki elementaarseid \u00f5igusi. Piisab sellest, kui m\u00e4rkida rolli \"t\u00f6\u00f6taja\" p\u00e4rimise tunnus.<\/p>\n

\"Loome
\n
\nHiljem t\u00e4iendati standardit uute juurdep\u00e4\u00e4su atribuutidega, mis on seotud pidevalt muutuva keskkonnaga. \u00dcks v\u00f5imalus on staatiliste ja d\u00fcnaamiliste piirangute rakendamine. Staatilised piirangud t\u00e4hendab rollide kumulatsiooni v\u00e4ltimist (sama sissejuhatus ja operatsioonide kontroll, millest varem r\u00e4\u00e4giti). D\u00fcnaamilised piirangud v\u00f5ivad s\u00f5ltuda muutuvatest parameetritest, n\u00e4iteks ajast (t\u00f6\u00f6-\/vabaaja v\u00f5i -p\u00e4evad), asukohast (kontor\/kodu) jne.<\/p>\n

Erakordselt tasub r\u00e4\u00e4kida atribuutide p\u00f5hjal p\u00f5hinevast juurdep\u00e4\u00e4su haldusest (ABAC \u2014 Attribute-based access control).<\/b> L\u00e4henemine p\u00f5hineb juurdep\u00e4\u00e4su andmisel atribuutide jagamise reeglite kaudu. Seda mudelit saab kasutada iseseisvalt, kuid tihti t\u00e4iendab see klassikalist rollimudelit: teatud rollile saab lisada kasutajate, ressursside ja seadmete atribuute, samuti aega v\u00f5i asukohta. See v\u00f5imaldab v\u00e4hendada rollide arvu, kehtestada t\u00e4iendavaid piiranguid ja teha juurdep\u00e4\u00e4su minimaalseteks, seega t\u00f5sta turvalisust.<\/p>\n

N\u00e4iteks v\u00f5ib raamatupidajale lubada juurdep\u00e4\u00e4su kontodele, kui ta t\u00f6\u00f6tab teatud piirkonnas. Sel juhul v\u00f5rreldakse spetsialisti asukohta teatud standardv\u00e4\u00e4rtusega. V\u00f5i v\u00f5ib juurdep\u00e4\u00e4su anda kontodele ainult siis, kui kasutaja logib sisse seadmel, mis on kantud lubatud seadmete registrisse. Hea t\u00e4iendus rollimudelile, kuid seda kasutatakse iseseisvalt harva, kuna on vajalik luua palju reegleid ja lubade v\u00f5i piirangute tabeleid.<\/p>\n

Toon n\u00e4ide ABAC rakendamisest oma \"eelmises elus\". Meie pangas oli mitu filiaali. Klientide kontorite t\u00f6\u00f6tajad nendes filiaalides tegid t\u00e4iesti identsed toimingud, kuid nad pidid t\u00f6\u00f6tama p\u00f5hiss\u00fcsteemis ainult oma regiooni kontodega. Alguses hakkasime looma eraldi rolle igas piirkonnas \u2013 ja selliseid rolle, millel oli korduv funktsionaalsus, kuid juurdep\u00e4\u00e4s erinevatele kontodele, sai v\u00e4ga palju! Siis, kasutades kasutaja asukoha atribuuti ja seostades selle konkreetse konto vahemikuga kontrollimiseks, v\u00e4hendasime s\u00fcsteemis oluliselt rollide arvu. Tulemuseks j\u00e4id alles rollid ainult \u00fche filiaali jaoks, mis duplitseeriti vastavatele ametikohtadele k\u00f5igis \u00fclej\u00e4\u00e4nud pangas asuvates territoriaalsetes \u00fcksustes.<\/p>\n

N\u00fc\u00fcd r\u00e4\u00e4gime vajalikest ettevalmistusmeetmetest, ilma milleta lihtsalt ei saa \u00fcles ehitada toimivat rollimudelit.<\/p>\n

Samm 1. Loome funktsionaalse mudeli<\/h2>\n

\nAlustuseks tuleks luua funktsionaalne mudel \u2013 \u00fclevaatlik dokument, kus on detailselt kirjas iga sektori ja iga ametikoha funktsioonid. T\u00fc\u00fcpiliselt kogutakse teave sellest erinevatest dokumentidest: ametijuhenditest ja reeglitest, mis k\u00e4sitlevad vastavaid osi \u2013 osakondi, juhtimisi, departemente. Funktsionaalne mudel peab olema koosk\u00f5lastatud k\u00f5igi sidusr\u00fchmadega (\u00e4ri, sisekontroll, turvalisus) ja kinnitatud ettev\u00f5tte juhtkonna poolt. Miks on see dokument vajalik? Selleks, et rollimudel saaks sellele viidata. N\u00e4iteks, kui kavatsete koostada rollimudeli juba olemasolevate t\u00f6\u00f6tajate \u00f5iguste p\u00f5hjal \u2013 mis on v\u00e4lja antud s\u00fcsteemist ja \u201e\u00fchtlustatud\u201c. Seej\u00e4rel, kui lepitate kokku saadud rolle s\u00fcsteemi \u00e4riomanikuga, saab viidata konkreetsele punktile funktsionaalses mudelis, mille alusel h\u00f5lmatakse rolli teatud \u00f5igus.<\/p>\n

Samm 2. Auditeerime IT-s\u00fcsteeme ja koostame prioriseerimise plaani<\/h2>\n

\nTeises etapis tuleb l\u00e4bi viia IT-s\u00fcsteemide auditeerimine, et m\u00f5ista, kuidas nendele juurdep\u00e4\u00e4s on korraldatud. N\u00e4iteks minu finantsettev\u00f5ttes oli kasutuses mitu sada infotehnoloogiat. K\u00f5ikides s\u00fcsteemides olid mingid r\u00fchmad, enamasti paberil v\u00f5i s\u00fcsteemi soovitusel, mis olid juba ammu aegunud, ning juurdep\u00e4\u00e4su anti v\u00e4lja vastavalt kasutajate tegelikele taotlustele. Loomulikult on v\u00f5imatu kohe v\u00e4lja t\u00f6\u00f6tada rollimudelit mitmesajale s\u00fcsteemile \u2013 tuleb alustada kusagilt. Me viisime l\u00e4bi s\u00fcvaanal\u00fc\u00fcsi juurdep\u00e4\u00e4suhalduse protsessi kohta, et m\u00e4\u00e4rata selle k\u00fcpsuse tase. Anal\u00fc\u00fcsi k\u00e4igus v\u00e4lja t\u00f6\u00f6tatud kriteeriumide alusel prioritiseeriti infotehnoloogiaid \u2013 kriitilisus, valmidus, plaanid v\u00e4ljaarvamiseks jne. Nende abil koostasime j\u00e4rjestuse rollimudelite arendamiseks\/uuendamiseks nende s\u00fcsteemide jaoks. Ja seej\u00e4rel kaasasime rollimudelid identiteedihalduse lahendusega integreerimise plaani, et automatiseerida juurdep\u00e4\u00e4suhaldust.<\/p>\n

Nii kuidas m\u00e4\u00e4rata s\u00fcsteemi kriitilisust? Vastake endale j\u00e4rgmistele k\u00fcsimustele:<\/p>\n