Eelmistes artiklites oleme juba vaadanud, mis on IdM, kuidas aru saada, kas teie organisatsioon vajab sellist süsteemi, milliseid probleeme see lahendab ja kuidas juurutuseelarvet juhtkonnale põhjendada. Täna räägime olulistest etappidest, mille organisatsioon ise peab läbima, et saavutada õige küpsusaste enne IdM-süsteemi juurutamist. IdM on ju loodud protsesside automatiseerimiseks, aga kaose automatiseerimine on võimatu.
Kuni ettevõte ei kasva suure ettevõtte suuruseks ja pole kogunud palju erinevaid ärisüsteeme, ei mõtle ta tavaliselt juurdepääsukontrollile. Seetõttu ei ole selles õiguste ja kontrollivolituste saamise protsessid struktureeritud ja neid on raske analüüsida. Töötajad täidavad juurdepääsutaotlusi vastavalt oma soovile, ka heakskiitmise protsess pole vormistatud ja mõnikord pole seda lihtsalt olemas. Ei ole võimalik kiiresti aru saada, milline juurdepääs töötajal on, kes selle heaks kiitis ja mille alusel.
Arvestades, et juurdepääsu automatiseerimise protsess mõjutab kahte peamist aspekti - personaliandmed ja infosüsteemide andmed, millega integreeritakse, siis kaalume vajalikke samme tagamaks, et IdM-i juurutamine sujuks ja ei põhjustaks tagasilükkamist:
- Personaliprotsesside analüüs ja töötajate andmebaasi toe optimeerimine personalisüsteemides.
- Kasutajate ja õiguste andmete analüüs, samuti juurdepääsukontrolli meetodite uuendamine sihtsüsteemides, mida plaanitakse ühendada IdM-iga.
- Organisatsioonilised tegevused ja personali kaasamine IdM-i rakendamise ettevalmistamise protsessi.
Personali andmed
Personaliandmete allikas võib organisatsioonis olla üks või mitu. Näiteks võib organisatsioonil olla üsna lai filiaalide võrk ja iga filiaal võib kasutada oma personalibaasi.
Kõigepealt tuleb mõista, milliseid põhiandmeid töötajate kohta personaliarvestussüsteemis hoitakse, milliseid sündmusi fikseeritakse ning hinnata nende täielikkust ja ülesehitust.
Sageli juhtub, et kõiki personalisündmusi ei märgita personaliallikasse (ja veelgi sagedamini märgitakse need üles enneaegselt ja mitte täiesti õigesti). Siin on mõned tüüpilised näited:
- Lehti, nende kategooriaid ja tähtaegu (tavalised või pikaajalised) ei registreerita;
- Osalise tööajaga töötamist ei kajastata: näiteks pikaajalisel lapse hooldamise puhkusel olles saab töötaja samaaegselt töötada osalise tööajaga;
- kandidaadi või töötaja tegelik staatus on juba muutunud (vastuvõtt / üleviimine / vallandamine) ja selle sündmuse kohta antakse korraldus hilinemisega;
- töötaja viiakse vallandamise teel üle uuele korralisele ametikohale, samas kui personalisüsteem ei salvesta teavet, et tegemist on tehnilise vallandamisega.
Samuti tasub erilist tähelepanu pöörata andmete kvaliteedi hindamisele, kuna usaldusväärsest allikast ehk personalisüsteemidest saadud vead ja ebatäpsused võivad tulevikus olla kulukad ja tekitada IdM-i juurutamisel palju probleeme. Näiteks personalitöötajad sisestavad töötajate ametikohti personalisüsteemi sageli erinevas vormingus: suur- ja väiketähed, lühendid, erinev tühikute arv jms. Selle tulemusena saab sama ametikoha personalisüsteemis registreerida järgmistes variatsioonides:
- Vanemjuht
- vanemjuht
- vanemjuht
- Art. juhataja…
Sageli peate tegelema oma nime kirjapildi erinevustega:
- Shmeleva Natalja Gennadievna,
- Shmeleva Natalia Gennadievna...
Edasiseks automatiseerimiseks on selline segadus vastuvõetamatu, eriti kui need atribuudid on identifitseerimise võtmemärk, see tähendab, et andmeid töötaja ja tema volituste kohta süsteemides võrreldakse täpselt täisnime järgi.
Lisaks ei tohiks unustada nimekaimude ja täisnimekaimude võimalikku esinemist ettevõttes. Kui organisatsioonil on tuhat töötajat, võib selliseid vasteid olla vähe, kui aga 50 tuhat, siis võib see saada kriitiliseks takistuseks IdM-süsteemi korrektsel toimimisel.
Kõike eelnevat kokku võttes järeldame: organisatsiooni personaliandmebaasi andmete sisestamise formaat peab olema standarditud. Nimede, ametikohtade ja osakondade sisestamise parameetrid peavad olema selgelt määratletud. Parim variant on see, kui personalitöötaja ei sisesta andmeid käsitsi, vaid valib need eelnevalt loodud osakondade ja ametikohtade struktuuri kataloogist, kasutades selleks personaliandmebaasis olevat funktsiooni “select”.
Et vältida edasisi sünkroonimisvigu ja mitte aruannete lahknevusi käsitsi parandada, eelistatuim viis töötajate tuvastamiseks on ID sisestamine iga organisatsiooni töötaja kohta. Selline tunnus määratakse igale uuele töötajale ja see ilmub nii personalisüsteemis kui ka organisatsiooni infosüsteemides kohustusliku kontoatribuudina. Pole vahet, kas see koosneb numbritest või tähtedest, peaasi, et see oleks iga töötaja jaoks unikaalne (näiteks paljud kasutavad töötaja personalinumbrit). Tulevikus hõlbustab selle atribuudi kasutuselevõtt oluliselt töötajate andmete sidumist personaliallikas tema kontode ja asutustega infosüsteemides.
Seega tuleb analüüsida ja korrastada kõiki personaliarvestuse etappe ja mehhanisme. On täiesti võimalik, et mõnda protsessi tuleb muuta või muuta. See on tüütu ja vaevarikas töö, kuid vajalik, sest vastasel juhul toob personalisündmuste kohta selgete ja struktureeritud andmete puudumine kaasa vigu nende automaatsel töötlemisel. Halvimal juhul on struktureerimata protsesse üldse võimatu automatiseerida.
Sihtsüsteemid
Järgmises etapis peame välja mõtlema, kui palju infosüsteeme soovime IdM-i struktuuri integreerida, milliseid andmeid kasutajate ja nende õiguste kohta neis süsteemides hoitakse ning kuidas neid hallata.
Paljudes organisatsioonides ollakse arvamusel, et installime IdM-i, konfigureerime sihtsüsteemide pistikud ja võluvitsa lainega töötab kõik ilma meiepoolse täiendava pingutuseta. Seda paraku ei juhtu. Ettevõtetes infosüsteemide maastik areneb ja suureneb järk-järgult. Igal süsteemil võib juurdepääsuõiguste andmisel olla erinev lähenemine, see tähendab, et saab konfigureerida erinevaid juurdepääsukontrolli liideseid. Kusagil toimub juhtimine API (rakenduse programmeerimisliidese) kaudu, kuskil andmebaasi kaudu, kasutades salvestatud protseduure, kuskil ei pruugi interaktsiooniliideseid üldse olla. Peaksite olema valmis selleks, et peate läbi vaatama paljud olemasolevad protsessid kontode ja õiguste haldamiseks organisatsiooni süsteemides: muutke andmevormingut, parandage eelnevalt interaktsiooniliideseid ja eraldage selle töö jaoks ressursse.
Eeskuju
Eeskuju kontseptsiooniga puutute tõenäoliselt kokku IdM-i lahenduse pakkuja valiku etapis, kuna see on juurdepääsuõiguste haldamise valdkonnas üks võtmemõisteid. Selles mudelis tagatakse juurdepääs andmetele rolli kaudu. Roll on juurdepääsude kogum, mis on teatud ametikohal töötajale oma funktsionaalsete kohustuste täitmiseks minimaalselt vajalik.
Rollipõhisel juurdepääsukontrollil on mitmeid vaieldamatuid eeliseid:
- samade õiguste määramine suurele hulgale töötajatele on lihtne ja tõhus;
- samade õigustega töötajate juurdepääsu viivitamatu muutmine;
- õiguste üleliigsuse kõrvaldamine ja kasutajate kokkusobimatute volituste piiritlemine.
Rollimaatriks ehitatakse esmalt igasse organisatsiooni süsteemi eraldi ja seejärel skaleeritakse kogu IT maastikule, kus iga süsteemi rollidest moodustatakse globaalsed ärirollid. Näiteks äriroll "Raamatupidaja" sisaldab mitut eraldi rolli iga ettevõtte raamatupidamisosakonnas kasutatava infosüsteemi jaoks.
Viimasel ajal on peetud “parimaks tavaks” eeskuju loomist isegi rakenduste, andmebaaside ja operatsioonisüsteemide arendamise etapis. Samas tuleb sageli ette olukordi, kus rollid pole süsteemis konfigureeritud või neid lihtsalt pole. Sel juhul peab selle süsteemi administraator sisestama konto andmed mitmesse erinevasse faili, teeki ja kataloogi, mis annavad vajalikud õigused. Eelmääratletud rollide kasutamine võimaldab teil anda õigusi mitmesuguste toimingute tegemiseks keerukate liitandmetega süsteemis.
Rollid infosüsteemis jaotatakse reeglina ametikohtade ja osakondade kaupa vastavalt personalistruktuurile, kuid neid saab luua ka teatud äriprotsesside jaoks. Näiteks finantsorganisatsioonis on mitu arveldusosakonna töötajat samal ametikohal - operaator. Kuid osakonna sees toimub ka jaotus eraldi protsessideks, vastavalt erinevat tüüpi toimingutele (välised või sisemised, erinevates valuutades, organisatsiooni erinevate segmentidega). Et tagada ühe osakonna igale ärivaldkonnale juurdepääs infosüsteemile vastavalt nõutud spetsiifikale, on vaja kaasata õigused üksikutesse funktsionaalsetesse rollidesse. See võimaldab anda iga tegevusvaldkonna jaoks piisava minimaalse volituste kogumi, mis ei hõlma üleliigseid õigusi.
Lisaks on sadade rollide, tuhandete kasutajate ja miljonite õigustega suurte süsteemide puhul hea tava kasutada rollide hierarhiat ja privileegide pärimist. Näiteks pärib vanemarolli Administraator alamrollide õigused: kasutaja ja lugeja, kuna administraator saavad teha kõike, mida saavad teha kasutaja ja lugeja, lisaks on tal täiendavad administraatoriõigused. Hierarhiat kasutades ei ole vaja sama mooduli või süsteemi mitmes rollis samu õigusi uuesti määrata.
Esimeses etapis saate luua rolle nendes süsteemides, kus võimalik õiguste kombinatsioonide arv ei ole väga suur ja sellest tulenevalt on väikest rollide arvu lihtne hallata. Need võivad olla tüüpilised õigused, mida nõuavad kõik ettevõtte töötajad avalikult juurdepääsetavatele süsteemidele, nagu Active Directory (AD), meilisüsteemid, teenusehaldur jms. Seejärel saab infosüsteemide jaoks loodud rollimaatriksid lisada üldisesse rollimudelisse, kombineerides need Ärirollideks.
Seda lähenemist kasutades on tulevikus IdM-süsteemi juurutamisel lihtne automatiseerida kogu juurdepääsuõiguste andmise protsess loodud esimese etapi rollide alusel.
NB Te ei tohiks püüda integratsiooni koheselt kaasata võimalikult palju süsteeme. Keerulisema arhitektuuri ja juurdepääsuõiguste haldusstruktuuriga süsteemid on parem ühendada IdM-iga esimeses etapis poolautomaatses režiimis. See tähendab, et rakendage personalisündmuste põhjal ainult juurdepääsutaotluse automaatne genereerimine, mis saadetakse administraatorile täitmiseks ja ta konfigureerib õigused käsitsi.
Pärast esimese etapi edukat läbimist saate laiendada süsteemi funktsionaalsust uutele laiendatud äriprotsessidele, rakendada täielikku automatiseerimist ja skaleerimist täiendavate infosüsteemide ühendamisega.
Ehk siis selleks, et valmistuda IdM-i juurutamiseks, on vaja hinnata infosüsteemide valmisolekut uueks protsessiks ning eelnevalt viimistleda välised interaktsiooniliidesed kasutajakontode ja kasutajaõiguste haldamiseks, kui selliseid liideseid ei ole. süsteemis saadaval. Samuti tuleks uurida infosüsteemides rollide järkjärgulist loomist igakülgseks juurdepääsukontrolliks.
Korralduslikud üritused
Ärge vähendage ka korralduslikke probleeme. Mõnel juhul võivad need mängida otsustavat rolli, sest kogu projekti tulemus sõltub sageli osakondade tõhusast suhtlusest. Tavaliselt soovitame selleks luua organisatsiooni protsessis osalejatest meeskonna, kuhu kuuluvad kõik kaasatud osakonnad. Kuna see on inimestele lisakoormus, proovige kõigile tulevases protsessis osalejatele eelnevalt selgitada nende rolli ja olulisust suhtlusstruktuuris. Kui "müüte" IdM-i idee selles etapis oma kolleegidele, saate tulevikus vältida paljusid raskusi.
Tihti on infoturbe- või IT-osakonnad ettevõttes IdM-i juurutamisprojekti “omanikud” ning äriosakondade arvamusi ei arvestata. See on suur viga, sest ainult nemad teavad, kuidas ja millistes äriprotsessides iga ressurssi kasutatakse, kellele tuleks sellele juurdepääs anda ja kellele mitte. Seetõttu on ettevalmistusetapis oluline märkida, et just ettevõtte omanik vastutab funktsionaalse mudeli eest, mille alusel infosüsteemi kasutajaõiguste (rollide) komplektid välja töötatakse, ning ka selle eest, et ettevõtte omanik vastutab infosüsteemi kasutajaõiguste (rollide) komplektide väljatöötamise eest. neid rolle hoitakse ajakohasena. Eeskuju ei ole staatiline maatriks, mis on üks kord üles ehitatud ja mille peale saab rahuneda. See on “elav organism”, mis peab pidevalt muutuma, uuenema ja arenema, järgides muutusi organisatsiooni struktuuris ja töötajate funktsionaalsuses. Vastasel juhul tekivad probleemid seoses juurdepääsu andmise viivitusega või infoturberiskid seoses liigsete juurdepääsuõigustega, mis on veelgi hullem.
Teatavasti "seitsmel lapsehoidjal on laps ilma silmata", seega peab ettevõte välja töötama metoodika, mis kirjeldab eeskuju arhitektuuri, konkreetsete protsessis osalejate suhtlust ja vastutust selle ajakohasena hoidmise eest. Kui ettevõttel on palju äritegevuse valdkondi ja vastavalt ka palju divisjone ja osakondi, siis iga valdkonna (näiteks laenuandmine, operatiivtöö, kaugteenused, vastavus ja muu) puhul osana rollipõhise juurdepääsuhalduse protsessist on vaja määrata eraldi kuraatorid. Nende kaudu on võimalik kiiresti saada teavet osakonna struktuuri muudatuste ja iga rolli jaoks vajalike juurdepääsuõiguste kohta.
Protsessis osalevate osakondade vaheliste konfliktsituatsioonide lahendamiseks on hädavajalik kaasata organisatsiooni juhtkonna toetus. Ja konfliktid iga uue protsessi juurutamisel on vältimatud, uskuge meie kogemust. Seetõttu vajame vahekohtunikku, kes lahendab võimalikud huvide konfliktid, et mitte raisata aega kellegi teise arusaamatuste ja sabotaaži tõttu.
NB Hea koht teadlikkuse tõstmise alustamiseks on oma töötajate koolitamine. Tulevase protsessi toimimise ja iga selles osaleja rolli üksikasjalik uurimine vähendab raskusi uuele lahendusele üleminekul.
Kontrollnimekiri
Kokkuvõtteks võtame kokku peamised sammud, mida organisatsioon, kes kavatseb IdM-i juurutada, peaks astuma:
- viia korda personaliandmetesse;
- sisestage iga töötaja jaoks kordumatu identifitseerimisparameeter;
- hindab infosüsteemide valmisolekut IdM-i rakendamiseks;
- välja töötada liidesed suhtlemiseks juurdepääsu kontrolli infosüsteemidega, kui need puuduvad, ja eraldada selleks tööks ressursse;
- arendada ja ehitada eeskuju;
- ehitada üles eeskujulik juhtimisprotsess ja kaasata sellesse kuraatorid igast ärivaldkonnast;
- valige IdM-iga esmaseks ühendamiseks mitu süsteemi;
- luua tõhus projektimeeskond;
- saada toetust ettevõtte juhtkonnalt;
- rongi personal.
Ettevalmistusprotsess võib olla keeruline, nii et võimalusel kaasake konsultante.
IdM-i lahenduse juurutamine on raske ja vastutusrikas samm ning selle edukaks elluviimiseks on olulised nii iga osapoole – äriosakondade töötajate, IT- ja infoturbeteenuste töötajate – pingutused eraldiseisvalt kui ka kogu meeskonna koostoimimine tervikuna. Kuid pingutused on seda väärt: pärast IdM-i juurutamist ettevõttes väheneb ülemääraste volituste ja volitamata õigustega seotud juhtumite arv infosüsteemides; töötajate seisakud puudumisest/pikaajast vajalike õiguste ootamise tõttu kaovad; Tänu automatiseerimisele vähenevad tööjõukulud ning suureneb IT- ja infoturbeteenuste tööviljakus.
Allikas: www.habr.com