{"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":"Ehitage rollimudeli juurdep\u00e4\u00e4su haldamiseks. Osa \u00fcks, ettevalmistav","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Praegu t\u00f6\u00f6tan tarkvaravaldkonna tootja juures, t\u00e4psemalt ligip\u00e4\u00e4su haldamise lahenduste valdkonnas. Minu varasem kogemus on seotud tellija poolega \u2013 suure finantsorganisatsiooniga. Toona ei saanud meie infokaitse osakonna ligip\u00e4\u00e4su kontrolli grupp kiidelda suurte oskustega IdM-is. Me \u00f5ppisime paljusid asju protsessi k\u00e4igus ning pidime sisse v\u00f5tma palju k\u00f5va p\u00e4he, et ettev\u00f5ttes luua t\u00f5hus kasutaja\u00f5iguste haldamise mehhanism teabes\u00fcsteemides.
\n\"Ehitage
\nLiites oma tellija poolt saadud kogemuse tootja teadmiste ja oskustega, soovin jagada teiega praktilist samm-sammult juhendit: kuidas luua suures ettev\u00f5ttes rollip\u00f5hine ligip\u00e4\u00e4su haldamise mudel ja mida see tulemusena toob. Minu juhend koosneb kahest osast: esimeses valmistame ette mudeli ehitamiseks, teises osas ehitame seda m\u00f5istetavalt. Teie ees on esimene osa, ettevalmistav.
\n<\/a><\/noindex>
\nM\u00e4rkus.<\/b> Rollip\u00f5hise mudeli loomine on kahjuks mitte tulemus, vaid protsess. T\u00e4psemalt on see osa ettev\u00f5tte ligip\u00e4\u00e4su haldamise \u00f6kos\u00fcsteemi loomise protsessist. Nii et valmistuge pikaajaliseks m\u00e4nguks.
\n<\/i>
\nEsiteks, m\u00e4\u00e4ratleme \u2013 mis on rollip\u00f5hine ligip\u00e4\u00e4su haldamine? Oletame, et teil on suur pank, kus t\u00f6\u00f6tavad k\u00fcmned v\u00f5i isegi sadade tuhandete t\u00f6\u00f6tajate (subjektide) seas, kellel on k\u00fcmneid ligip\u00e4\u00e4su\u00f5igusi sadu sise-pankade teabes\u00fcsteemides (objektid). N\u00fc\u00fcd korruta objektide arv subjektide arvuga \u2013 just nii palju sidemeid peate esmalt looma ja seej\u00e4rel kontrollima. Kas on seda v\u00f5imalik k\u00e4sitsi teha? Loomulikult mitte \u2013 selle \u00fclesande lahendamiseks loodi rollid.<\/p>\n

Roll on \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, kusjuures igal rollil v\u00f5ib olla \u00fcks v\u00f5i mitu \u00f5igust, mis on antud kasutajale selle rolli piires. Rollid v\u00f5ivad olla seotud teatud ametikohtade, osakondade v\u00f5i t\u00f6\u00f6tajate funktsionaalsete \u00fclesannetega.<\/p>\n

\"Ehitage
\n
\nRollid luuakse tavaliselt t\u00f6\u00f6taja individuaalsetest \u00f5igustest igas infosisystemis. Seej\u00e4rel koostatakse igas s\u00fcsteemis olevatest rollidest globaalne \u00e4rirulli. N\u00e4iteks \u00e4rirull \"krediidihaldur\" sisaldab mitmeid individuaalseid rolle infosisystemites, mida kasutab panga kliendib\u00fcroo. \u00dctleme, et n\u00e4iteks sellistes s\u00fcsteemides nagu peamine automatiseeritud panganduss\u00fcsteem, kassamoodul, elektroonilise dokumendihalduse s\u00fcsteem, teenusehaldur ja muud. \u00c4riv\u00f5imalused on tavaliselt seotud organisatsiooni struktuuri \u2013 lihtsamalt \u00f6eldes, ettev\u00f5tte osakondade ja ametikohtade komplekti. Nii luuakse globaalne rollide maatriks (n\u00e4idet toob v\u00e4lja tabel allpool).<\/p>\n

\"Ehitage
\n
\nTuleb m\u00e4rkida, et 100% rollimudeli loomine, tagades k\u00f5igile kommertstruktuuri ametikohtade t\u00f6\u00f6tajatele k\u00f5ik vajalikke \u00f5igusi, on lihtsalt v\u00f5imatu. Ja see pole ka vajalik. L\u00f5ppude l\u00f5puks ei saa rollimudel olla staatiline, sest see s\u00f5ltub pidevalt muutuvast keskkonnast. Ja ettev\u00f5tte \u00e4ritegevuse muutumisest, mis vastavalt m\u00f5jutab organisatsioonistruktuuri ja funktsioone. Ja sellest, et ressursse pole t\u00e4ielikult, ja ametijuhendite mittet\u00e4itmisest, ja soovist teenida kasumit ohutuse arvelt ning paljusid teisi tegureid. Seet\u00f5ttu on vajalik luua rollimudel, mis suudab katta kuni 80% kasutajate vajadustest vajalike p\u00f5hiteenuste saamiseks ametikoha nimel. \u00dclej\u00e4\u00e4nud 20% saavad nad vajadusel hiljem eraldi taotlustega k\u00fcsida.<\/p>\n

Muidugi v\u00f5ite k\u00fcsida: \"Kas on siis t\u00f5esti olemas 100% rollimudeleid?\" Miks mitte, sellised esinevad n\u00e4iteks mittetulundus\u00fchingutes, mis ei puutu sageli muutumisse, \u2013 n\u00e4iteks m\u00f5nes teadus- ja arendustegevuses. V\u00f5i k\u00f5rgendatud usaldusv\u00e4\u00e4rsusega kaitset\u00f6\u00f6stuses, kus ohutus on esikohal. On ka juhuseid, kus see esineb ka kommertsinstitutsioonides, kuid kindlas osakonnas, mille t\u00f6\u00f6 on piisavalt staatiline ja prognoositav protsess.<\/p>\n

Rollihalduse peamine eelis on \u00f5iguste m\u00e4\u00e4ramise lihtsustamine, sest rollide arv on oluliselt v\u00e4iksem kui infosisestuse kasutajate arv. See kehtib iga t\u00f6\u00f6stusharu kohta.<\/p>\n

V\u00f5tame kaupluse, kus t\u00f6\u00f6tab tuhandeid m\u00fc\u00fcjaid, kuid neil on s\u00fcsteemis N samad \u00f5igused ja neile luuakse vaid \u00fcks roll. Kui ettev\u00f5ttesse tuleb uus m\u00fc\u00fcja, m\u00e4\u00e4ratakse talle automaatselt vajalik roll s\u00fcsteemis, kus on juba k\u00f5ik vajalikud volitused. \u00dche kl\u00f5psuga saab ka tuhandete m\u00fc\u00fcjate \u00f5igusi korraga muuta, n\u00e4iteks lisada uus valik aruande genereerimiseks. Ei ole vaja teha tuhandet operatsiooni, sidudes uue \u00f5iguse iga konto k\u00fclge \u2013 piisab, kui lisada see valik rolli, ja see ilmub k\u00f5igile m\u00fc\u00fcjatele korraga.<\/p>\n

Veel \u00fcks rullide haldamise eelis on kokkusobimatute \u00f5iguste v\u00e4ljastamise v\u00e4ltimine. See t\u00e4hendab, et t\u00f6\u00f6taja, kes omab s\u00fcsteemis teatud rolli, ei saa samal ajal omada teist rolli, mille \u00f5igused ei tohi olla koosk\u00f5las esimese omadega. Selge n\u00e4ide \u2013 keelatud on andmete sisestamise ja finantstehingute kontrollimise funktsioonide \u00fchitamine.<\/p>\n

K\u00f5ik, keda huvitab, kuidas rullide haldus \u00f5igupoolest tekkis, v\u00f5ivad
\n sukelduda ajaloo ekskursiooni<\/b>
\n Kui vaadata ajalukku, siis esmakordselt m\u00f5tles IT-kogukond juurdep\u00e4\u00e4su haldamise meetodite \u00fcle juba 1970. aastatel. Kuigi rakendused olid siis \u00fcsna lihtsad, soovisid k\u00f5ik mugavalt juurdep\u00e4\u00e4su nende haldamiseks. Kasutajate \u00f5iguste andmine, muutmine ja kontrollimine \u2013 parandades arusaamist, milline juurdep\u00e4\u00e4s on iga\u00fchel. Kuid sel ajal ei olnud \u00fchtegi \u00fcldist standardit, arendati esimesi juurdep\u00e4\u00e4su haldamise s\u00fcsteeme ning iga ettev\u00f5te p\u00f5hines omaenda arusaamadel ja reeglitel.<\/p>\n

Praeguseks on teada palju erinevaid juurdep\u00e4\u00e4su haldamise mudeleid, kuid need ei tekkinud kohe. T\u00e4helepanu p\u00f6\u00f6rame neile, mis on andnud olulise panuse selle suuna arengusse.<\/p>\n

Esimene ja v\u00f5ib-olla k\u00f5ige lihtsam mudel \u2013 Diskretsiooniline (valikuline) juurdep\u00e4\u00e4su haldamine<\/b> (DAC \u2013 diskretsiooni juurdep\u00e4\u00e4su kontroll). See mudel t\u00e4hendab, et k\u00f5ik osalised jagavad \u00f5igusi juurdep\u00e4\u00e4suks. Iga kasutaja saab juurdep\u00e4\u00e4su konkreetsetele objektidele v\u00f5i toimingutele. Sisuliselt vastab siin paljusid \u00f5igusi omavad subjektid paljudele objektidele. See mudel on osutunud liiga paindlikuks ja keeruliseks hooldamiseks: juurdep\u00e4\u00e4sulisted muudavad aja jooksul tohutuks ja neid on raske hallata.<\/p>\n

Teine mudel on Mandaadi alusel juurdep\u00e4\u00e4su kontroll (MAC \u2013 Mandatory access control)<\/b>. Selle mudeli j\u00e4rgi saab iga kasutaja juurdep\u00e4\u00e4su objektile vastavalt v\u00e4ljastatud loa alusel selle v\u00f5i teise andmete konfidentsiaalsuse taseme jaoks. Vastavalt peab objekte klassifitseerima konfidentsiaalsuse taseme j\u00e4rgi. Erinevalt esimesest paindlikust mudelist, on see vastupidi osutunud liiga rangeks ja piiravaks. Selle rakendamine ei \u00f5igusta ennast, kui ettev\u00f5ttes on palju erinevaid teaberessursse: erinevate ressursside juurdep\u00e4\u00e4su piiramiseks tuleb luua mitmeid kategooriaid, mis ei kattuks.<\/p>\n

Seoses nende kahe meetodi ilmse ebaefektiivsusega j\u00e4tkas IT-kogukond mudelite v\u00e4ljat\u00f6\u00f6tamist, mis oleksid paindlikumad ja samas enam-v\u00e4hem universaalsed erinevate organisatsioonide juurdep\u00e4\u00e4su kontrolli poliitikate toetamiseks. Ja siis tekkis kolmas rollip\u00f5hine juurdep\u00e4\u00e4su kontrolli mudel!<\/b> See l\u00e4henemine on osutunud k\u00f5ige perspektiivikamaks, kuna see n\u00f5uab mitte ainult kasutaja isiku autentimist, vaid ka tema t\u00f6\u00f6\u00fclesandeid s\u00fcsteemides.<\/p>\n

Esimese t\u00e4pselt kirjeldatud rollimudeli pakkusid Ameerika teadlased David Ferraiolo ja Richard Kuhn USA Riiklikust Standardite ja Tehnoloogiate Instituudist 1992. aastal. Just siis ilmnes esmakordselt termin RBAC (rollip\u00f5hine juurdep\u00e4\u00e4su kontroll). <\/b>Need uuringud ja p\u00f5hikomponentide kirjeldused koos nende omavahelise seosega said aluseks kehtivale standardsile INCITS 359-2012, mille heakskiitis Rahvusvaheline Infotehnoloogia Standardite Komitee (INCITS).<\/p>\n

Standard m\u00e4\u00e4ratleb rolli kui \u201eametifunktsiooni organisatsiooni kontekstis, millel on teatud seotud semantika seoses kasutajale m\u00e4\u00e4ratud volituste ja vastutusega\u201c. Dokument kehtestab RBAC p\u00f5hielemendid \u2013 kasutajad, seansid, rollid, load, toimingud ja objektid, samuti nende vahelised 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 nende kaudu. On m\u00e4\u00e4ratletud mehhanismid rollide koostamiseks objektidest ja toimingutest, kirjeldatud rollide hierarhiat ja volituste p\u00e4rimist. Igas ettev\u00f5ttes on rollid, mis \u00fchendavad elementaarseid volitusi, mis on vajalikud k\u00f5ikidele t\u00f6\u00f6tajatele. See v\u00f5ib olla juurdep\u00e4\u00e4s e-kirjale, dokumentide haldamise s\u00fcsteemile, ettev\u00f5tte portaalile jne. Need volitused saab koondada \u00fchte \u00fcldrolli nimega \u201et\u00f6\u00f6taja\u201c, mist\u00f5ttu ei ole vaja iga k\u00f5rgema taseme rolli puhul korduvalt loetleda k\u00f5iki elementaarseid \u00f5igusi. Piisab lihtsalt viidata rolli p\u00e4rimise tunnusele \u201et\u00f6\u00f6taja\u201c.<\/p>\n

\"Ehitage
\n
\nHiljem t\u00e4iendas standard uusi juurdep\u00e4\u00e4su atribuute, mis on seotud pidevalt muutuva keskkonnaga. Lisandusid staatilised ja d\u00fcnaamilised piirangud. Staatilised t\u00e4hendavad rollide kombinatsiooni keeldu (see sama toimetamine ja operatsioonide kontroll, millest varem mainitud). D\u00fcnaamilised piirangud v\u00f5ivad olla m\u00e4\u00e4ratud muutuvaid parameetreid, n\u00e4iteks aega (t\u00f6\u00f6-\/vabaajad), asukohta (kontor\/kodu) jne.<\/p>\n

Eraldi v\u00e4\u00e4rib mainimist atribuutidele p\u00f5hinev ligip\u00e4\u00e4suhaldus (ABAC \u2014 Attribute-based access control).<\/b> Mudel p\u00f5hineb juurdep\u00e4\u00e4su andmisel atribuutide jagamise reeglite kaudu. Seda mudelit saab kasutada iseseisvalt, kuid sageli t\u00e4iendab see aktiivselt klassikalist rollimudelit: teatud rollile saab lisada kasutajate, ressursside ja seadmete atribuute, samuti aega v\u00f5i asukohta. See v\u00f5imaldab kasutada v\u00e4hem rolle, kehtestada t\u00e4iendavaid piiranguid ja muuta juurdep\u00e4\u00e4su minimaalseteks, mist\u00f5ttu suureneb ohutus.<\/p>\n

N\u00e4iteks v\u00f5ib raamatupidajale lubada juurdep\u00e4\u00e4su kontodele, kui ta t\u00f6\u00f6tab konkreetses piirkonnas. Siis v\u00f5rreldakse spetsialisti asukohta kindla m\u00f5\u00f5duandega. V\u00f5i v\u00f5ib juurdep\u00e4\u00e4su kontodele anda ainult juhul, kui kasutaja logib sisse seadmest, mis on lubatud seadmete nimekirjas. Hea lisa rollimudelile, kuid seda kasutatakse iseseisvalt harva, kuna see n\u00f5uab palju reeglite ja lubade v\u00f5i piirangute tabelite loomist.<\/p>\n

Toon n\u00e4ite ABAC-i rakendamisest oma \"eelmisest elust\". Meie pangas oli mitu filiaali. Klientide teeninduspunktide t\u00f6\u00f6tajad nendes filiaalides tegid absoluutselt sama protseduuri, kuid pidid t\u00f6\u00f6tama p\u00f5hiss\u00fcsteemis vaid oma piirkonna kontodega. Alguses hakkasime looma eraldi rolle igas piirkonnas \u2013 ja selliseid rolle, millel oli korduv funktsionaalsus, kuid juurdep\u00e4\u00e4s erinevatele kontodele, tuli t\u00f5eliselt palju! Siis kasutasime kasutaja asukoha atribuut ja sidusime selle konkreetse kontode vahemikuga kontrollimiseks, mis v\u00e4hendas oluliselt s\u00fcsteemis olevate rollide arvu. L\u00f5puks j\u00e4id alles vaid \u00fche filiaali rollid, mida kopeeriti vastavatele ametikohtadele k\u00f5ikides teistes panga territoriaalsetes osakondades.<\/p>\n

N\u00fc\u00fcd r\u00e4\u00e4gime vajalikest ettevalmistusastmetest, ilma milleta pole v\u00f5imalik luua toimivat rollimudelit.<\/p>\n

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

\nAlustuseks tuleks luua funktsionaalne mudel \u2013 k\u00f5rgemal tasemel dokument, milles on \u00fcksikasjalikult kirjeldatud iga osakonna ja iga ametikoha funktsionaalsus. Reeglina pannakse sinna teave erinevatest dokumentidest: ametijuhenditest ja eraldi osakondade \u2013 osakondade, juhtide, departemangude \u2013 m\u00e4\u00e4rustest. Funktsionaalne mudel peab olema koosk\u00f5lastatud k\u00f5igi asjaosaliste osakondadega (\u00e4ri, sisekontroll, turvalisus) ja kinnitatud ettev\u00f5tte juhtkonna poolt. Milleks on see dokument vajalik? Selleks, et rollimudel saaks sellele viidata. N\u00e4iteks kui soovite luua rollimudeli juba olemasolevate kasutaja\u00f5iguste p\u00f5hjal \u2013 mis on v\u00e4lja toodud s\u00fcsteemist ja \u201e\u00fchendatud \u00fchise nimetajaga\u201c. Siis rollide koosk\u00f5lastamisel s\u00fcsteemi \u00e4ripoolt omanikuga saab viidata funktsionaalse mudeli konkreetsele punktile, mille p\u00f5hjal see v\u00f5i teine \u00f5igus rolli lisatakse.<\/p>\n

Samm 2. Teeme IKT s\u00fcsteemide auditi ja koostame prioriseerimise plaani<\/h2>\n

\nTeisel etapil tuleks l\u00e4bi viia IKT s\u00fcsteemide audit, et m\u00f5ista, kuidas ligip\u00e4\u00e4s neis korraldatud on. N\u00e4iteks minu finantsfirmas kasutati mitut sada infotehnoloogilist s\u00fcsteemi. K\u00f5ikides s\u00fcsteemides olid m\u00f5ned idud rollide haldamisest, enamikus oli m\u00f5ningaid rolle, kuid peamiselt paberil v\u00f5i s\u00fcsteemi registris \u2013 need olid ammu aegunud ja ligip\u00e4\u00e4s neis anti vastavalt kasutajate tegelikele soovidele. Loomulikult on raske luua rollimudelit \u00fcheaegselt mitmesajas s\u00fcsteemis, seet\u00f5ttu tuleb millegi kallal alustada. Me viisime l\u00e4bi s\u00fcvitsi mineva anal\u00fc\u00fcsi ligip\u00e4\u00e4su haldamise protsessi osas, et m\u00e4\u00e4rata selle k\u00fcpsuse tase. Anal\u00fc\u00fcsi k\u00e4igus t\u00f6\u00f6tasime v\u00e4lja infotehnoloogiliste s\u00fcsteemide prioriseerimise kriteeriumid \u2013 kriitilisus, valmidus, plaanid mahav\u00f5tmiseks jne. Nende abil koostasime j\u00e4rjestuse rollimudelite v\u00e4ljat\u00f6\u00f6tamiseks\/aktualiseerimiseks nende s\u00fcsteemide jaoks. Ja seej\u00e4rel \u2013 lisasime rollimudelid identiteedihalduse lahendusega integreerimise plaani, et automatiseerida ligip\u00e4\u00e4su haldamist.<\/p>\n

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