Ik wurkje op it stuit foar in softwareferkeaper, spesifyk oplossings foar tagongskontrôle. En myn ûnderfining "út it ferline libben" is ferbûn mei de kant fan 'e klant - in grutte finansjele organisaasje. Op dat stuit koe ús tagongskontrôlegroep yn 'e ôfdieling ynformaasjefeiligens net bogen fan grutte kompetinsjes yn IdM. Wy learden in protte yn it proses, wy moasten in protte bulten reitsje om in wurkjend meganisme te bouwen foar it behearen fan brûkersrjochten yn ynformaasjesystemen yn it bedriuw.
Troch myn hurde fertsjinne klantûnderfining te kombinearjen mei kennis en kompetinsjes fan leveransiers, wol ik yn essinsje stap-foar-stap ynstruksjes mei jo diele: hoe't jo in rol-basearre tagongskontrôlemodel meitsje kinne yn in grut bedriuw, en wat dit as gefolch sil jaan . Myn ynstruksjes besteane út twa dielen: de earste is klear om it model te bouwen, de twadde is eins bouwe. Hjir is it earste diel, it tariedende diel.
NB It bouwen fan in rolmodel is spitigernôch gjin resultaat, mar in proses. Of leaver, sels in diel fan it proses fan it meitsjen fan in ekosysteem foar tagongskontrôle yn it bedriuw. Sa meitsje jo klear foar it spultsje foar in lange tiid.
Litte wy it earst definiearje - wat is rol-basearre tagongskontrôle? Stel dat jo in grutte bank hawwe mei tsientallen, of sels hûnderttûzenen meiwurkers (entiteiten), dy't elk tsientallen tagongsrjochten hawwe foar hûnderten ynterne bankynformaasjesystemen (objekten). Fermannichfâldigje no it oantal objekten mei it oantal ûnderwerpen - dit is it minimale oantal ferbiningen dy't jo earst moatte bouwen en dan kontrolearje. Is it echt mooglik om dit mei de hân te dwaan? Fansels net - rollen waarden makke om dit probleem op te lossen.
In rol is in set fan tagongsrjochten dy't in brûker of groep brûkers nedich hat om bepaalde wurktaken út te fieren. Elke meiwurker kin ien of mear rollen hawwe, en elke rol kin fan ien oant in protte tagongsrjochten befetsje dy't tastien binne foar de brûker binnen dy rol. Rollen kinne wurde bûn oan spesifike posysjes, ôfdielingen of funksjonele taken fan meiwurkers.
Rollen wurde meastentiids oanmakke út yndividuele meiwurkers autorisaasjes yn elk ynformaasjesysteem. Dan wurde wrâldwide saaklike rollen foarme út 'e rollen fan elk systeem. Bygelyks, de saaklike rol "kredytbehearder" sil ferskate aparte rollen omfetsje yn 'e ynformaasjesystemen dy't wurde brûkt yn it klantkantoar fan' e bank. Bygelyks, lykas it haad automatisearre banksysteem, cashmodule, elektroanysk dokumintbehearsysteem, tsjinstbehearder en oaren. Bedriuwsrollen binne yn 'e regel bûn oan' e organisatoaryske struktuer - mei oare wurden, oan 'e set fan bedriuwsôfdielingen en posysjes dêryn. Dit is hoe't in globale rolmatrix wurdt foarme (ik jou in foarbyld yn 'e tabel hjirûnder).
It is de muoite wurdich op te merken dat it gewoan ûnmooglik is om in 100% rolmodel te bouwen, it leverjen fan alle nedige rjochten foar meiwurkers fan elke posysje yn in kommersjele struktuer. Ja, dit is net nedich. In rolmodel kin ommers net statysk wêze, om't it hinget fan in hieltyd feroarjende omjouwing. En fan feroaringen yn 'e bedriuwsaktiviteiten fan' e bedriuw, dy't, neffens, ynfloed hawwe op feroaringen yn 'e organisatoaryske struktuer en funksjonaliteit. En fan it gebrek oan folsleine oanbod fan middels, en fan net-neilibjen fan taakbeskriuwings, en fan 'e winsk foar winst op kosten fan feiligens, en fan in protte oare faktoaren. Dêrom is it nedich om in rolmodel te bouwen dat oant 80% fan brûkersferlet kin dekke foar de nedige basisrjochten by it tawizen fan in posysje. En se kinne, as nedich, de oerbleaune 20% letter oanfreegje op aparte applikaasjes.
Fansels kinne jo freegje: "Binne d'r net sa'n ding as 100% rolmodellen?" No, wêrom, dit bart, bygelyks, yn non-profit struktueren dy't net ûnderwurpen binne oan faak feroarings - yn guon ûndersyksynstitút. Of yn militêr-yndustriële komplekse organisaasjes mei in heech nivo fan feiligens, dêr't feiligens foarop komt. It bart yn in kommersjele struktuer, mar yn it ramt fan in aparte ôfdieling, wêrfan it wurk in frij statysk en foarsisber proses is.
It wichtichste foardiel fan rollen basearre behear is de ferienfâldiging fan it útjaan fan rjochten, om't it oantal rollen signifikant minder is as it oantal brûkers fan it ynformaasjesysteem. En dit is wier foar elke yndustry.
Litte wy in retailbedriuw nimme: it hat tûzenen ferkeapers yn tsjinst, mar se hawwe deselde set rjochten yn systeem N, en mar ien rol sil foar har makke wurde. As in nije ferkeaper by it bedriuw komt, wurdt hy automatysk de fereaske rol tawiisd yn it systeem, dat al alle nedige autoriteiten hat. Ek kinne jo yn ien klik de rjochten feroarje foar tûzenen ferkeapers tagelyk, bygelyks in nije opsje taheakje foar it generearjen fan in rapport. D'r is gjin need om tûzen operaasjes te dwaan, in nij rjocht te keppeljen oan elk akkount - foegje gewoan dizze opsje ta oan 'e rol, en it sil tagelyk foar alle ferkeapers ferskine.
In oar foardiel fan rol-basearre behear is it eliminearjen fan it útjaan fan ynkompatibele autorisaasjes. Dat is, in meiwurker dy't in bepaalde rol yn it systeem hat, kin net tagelyk in oare rol hawwe, wêrfan de rjochten net kombineare wurde moatte mei de rjochten yn 'e earste. In opfallend foarbyld is it ferbod op it kombinearjen fan de funksjes fan ynfier en kontrôle fan in finansjele transaksje.
Elkenien dy't ynteressearre is yn hoe't rol-basearre tagongskontrôle ûntstien is, kin
dûke yn skiednis
As wy nei de skiednis sjogge, tocht de IT-mienskip earst oer metoaden foar tagongskontrôle werom yn 'e jierren '70 fan' e XNUMXe ieu. Hoewol applikaasjes doedestiids frij ienfâldich wiene, krekt as no, woe elkenien echt de tagong ta har maklik beheare. Jou, feroarje en kontrolearje brûkersrjochten - gewoan om it makliker te meitsjen om te begripen hokker tagong elk fan har hat. Mar op dat stuit wiene d'r gjin mienskiplike noarmen, de earste systemen foar tagongskontrôle waarden ûntwikkele, en elk bedriuw wie basearre op har eigen ideeën en regels.
In protte ferskillende modellen foar tagongskontrôle binne no bekend, mar se ferskynden net fuortendaliks. Lit ús wenje op dyjingen dy't hawwe makke in wichtige bydrage oan de ûntwikkeling fan dit gebiet.
It earste en wierskynlik it ienfâldichste model is Diskresjonêre (selektyf) tagongskontrôle (DAC - Diskresjonêre tagongskontrôle). Dit model ymplisearret it dielen fan rjochten troch alle dielnimmers oan it tagongsproses. Elke brûker hat tagong ta spesifike objekten of operaasjes. Yn essinsje komt hjir de set fan ûnderwerpen fan rjochten oerien mei de set fan objekten. Dit model waard fûn te fleksibel en te dreech om te ûnderhâlden: tagongslisten wurde úteinlik enoarm en lestich te kontrolearjen.
It twadde model is Ferplichte tagongskontrôle (MAC - Ferplichte tagongskontrôle). Neffens dit model krijt elke brûker tagong ta in objekt yn oerienstimming mei de útjûne tagong ta in bepaald nivo fan gegevensfertroulikens. Dêrtroch moatte objekten wurde kategorisearre neffens har nivo fan fertroulikens. Oars as it earste fleksibele model, dizze, krekt oarsom, die bliken te strang en beheinend te wêzen. It gebrûk is net rjochtfeardige as it bedriuw in protte ferskillende ynformaasjeboarnen hat: om tagong ta ferskate boarnen te ûnderskieden, moatte jo in protte kategoryen ynfiere dy't net oerlappe.
Troch de foar de hân lizzende ûnfolsleinens fan dizze twa metoaden hat de IT-mienskip trochgean mei it ûntwikkeljen fan modellen dy't fleksibeler binne en tagelyk mear of minder universele om ferskate soarten organisatoarysk tagongskontrôlebelied te stypjen. En doe ferskynde it de tredde rol-basearre tagong kontrôle model! Dizze oanpak hat bewiisd de meast kânsrike te wêzen, om't it net allinich autorisaasje fan 'e identiteit fan' e brûker fereasket, mar ek syn operasjonele funksjes yn 'e systemen.
De earste dúdlik beskreaune rolmodelstruktuer waard foarsteld troch Amerikaanske wittenskippers David Ferrailo en Richard Kuhn fan it US National Institute of Standards and Technology yn 1992. Doe ferskynde de term earst RBAC (Role-basearre tagongskontrôle). Dizze stúdzjes en beskriuwingen fan 'e haadkomponinten, lykas har relaasjes, foarmen de basis fan' e INCITS 359-2012-standert, dy't hjoeddedei noch fan krêft is, goedkard troch it International Committee on Information Technology Standards (INCITS).
De standert definiearret in rol as "in baanfunksje yn 'e kontekst fan in organisaasje mei wat byhearrende semantyk oangeande de autoriteit en ferantwurdlikens dy't oan' e brûker tawiisd is oan 'e rol." It dokumint stelt de basiseleminten fan RBAC fêst - brûkers, sesjes, rollen, tagongsrjochten, operaasjes en objekten, lykas de relaasjes en ynterferbiningen tusken har.
De standert leveret de minimale needsaaklike struktuer foar it bouwen fan in rolmodel - it kombinearjen fan rjochten yn rollen en it jaan fan tagong ta brûkers fia dizze rollen. De meganismen foar it komponearjen fan rollen út objekten en operaasjes wurde sketst, de hierargy fan rollen en erfenis fan foegen wurde beskreaun. Ommers, yn elk bedriuw binne der rollen dy't kombinearje basis foech dy't nedich binne foar alle meiwurkers fan it bedriuw. Dit kin tagong wêze ta e-post, EDMS, bedriuwsportaal, ensfh. Dizze tagongsrjochten kinne wurde opnaam yn ien algemiene rol neamd "meiwurker", en it sil net nedich wêze om alle basisrjochten hieltyd wer te listjen yn elk fan 'e rollen op heger nivo. It is genôch om gewoan it erfskip karakteristyk fan 'e rol "meiwurker" oan te jaan.
Letter waard de standert oanfolle mei nije tagongsattributen yn ferbân mei de hieltyd feroarjende omjouwing. De mooglikheid om statyske en dynamyske beheiningen yn te fieren is tafoege. Statyske ymplisearret de ûnmooglikheid fan it kombinearjen fan rollen (deselde ynfier en kontrôle fan operaasjes neamd hjirboppe). Dynamyske beheiningen kinne wurde bepaald troch feroaring fan parameters, bygelyks tiid (wurk- / net-wurktiden of dagen), lokaasje (kantoar / thús), ensfh.
It is it wurdich om apart te neamen attribút-basearre tagong kontrôle (ABAC - Attribuut-basearre tagong kontrôle). De oanpak is basearre op it jaan fan tagong mei help fan regels foar dielen fan attribút. Dit model kin apart brûkt wurde, mar faak is it aktyf oanfolling op it klassike rolmodel: attributen fan brûkers, boarnen en apparaten, lykas tiid of lokaasje, kinne wurde tafoege oan in bepaalde rol. Hjirmei kinne jo minder rollen brûke, ekstra beheiningen ynfiere en tagong sa minimaal mooglik meitsje, en dêrom de feiligens ferbetterje.
Bygelyks, in boekhâlder kin tagong krije ta akkounts as hy yn in bepaalde regio wurket. Dan wurdt de lokaasje fan de spesjalist fergelike mei in bepaalde referinsjewearde. Of jo kinne tagong jaan ta akkounts allinich as de brûker ynloggt fan in apparaat opnommen yn 'e list mei tastiene. In goede oanfolling op in rolmodel, mar selden brûkt op syn eigen fanwege de needsaak om te meitsjen in protte regels en tabellen fan tagongsrjochten of beheinings.
Lit my jo in foarbyld jaan fan it brûken fan ABAC út myn "ferline libben". Us bank hie ferskate filialen. Meiwurkers fan kliïntkantoaren yn dizze tûken hawwe krekt deselde operaasjes útfierd, mar moasten allinich yn it haadsysteem wurkje mei akkounts yn har regio. Earst binne wy begûn mei it meitsjen fan aparte rollen foar elke regio - en d'r wiene safolle sokke rollen mei werheljende funksjonaliteit, mar mei tagong ta ferskate akkounts! Dan, troch in lokaasjeattribút foar de brûker te brûken en it te assosjearjen mei in spesifyk berik fan akkounts om te besjen, hawwe wy it oantal rollen yn it systeem signifikant fermindere. As gefolch, rollen bleaunen foar mar ien tûke, dy't waarden replicated foar de oerienkommende posysjes yn alle oare territoriale divyzjes fan 'e bank.
No litte wy prate oer de nedige tariedende stappen, sûnder dat it gewoan ûnmooglik is om in wurkjende rolmodel te bouwen.
Stap 1. Meitsje in funksjoneel model
Jo moatte begjinne mei it meitsjen fan in funksjoneel model - in dokumint op topnivo dat yn detail de funksjonaliteit fan elke ôfdieling en elke posysje beskriuwt. As regel, ynformaasje komt it út ferskate dokuminten: taakbeskriuwings en regeljouwing foar yndividuele ienheden - ôfdielings, divyzjes, ôfdielings. It funksjonele model moat wurde oerienkommen mei alle ynteressearre ôfdielingen (bedriuw, ynterne kontrôle, feiligens) en goedkard troch it bedriuwsmanagement. Wêr is dit dokumint foar? Sadat it rolmodel der nei ferwize kin. Jo sille bygelyks in rolmodel bouwe op basis fan de besteande rjochten fan meiwurkers - loslitten fan it systeem en "fermindere ta in mienskiplike neamer". Dan, by it oerienkommen fan de ûntfongen rollen mei de bedriuwseigner fan it systeem, kinne jo ferwize nei in spesifyk punt yn it funksjonele model, op basis wêrfan dit of dat rjocht yn 'e rol opnommen is.
Stap 2. Wy kontrolearje IT-systemen en meitsje in prioritearringsplan op
Yn 'e twadde etappe moatte jo in kontrôle fan IT-systemen útfiere om te begripen hoe't tagong ta har is organisearre. Bygelyks, myn finansjele bedriuw eksploitearre ferskate hûnderten ynformaasjesystemen. Alle systemen hiene guon rudiminten fan rol-basearre behear, de measte hiene guon rollen, mar meast op papier of yn it systeem triemtafel - se wiene lang ferâldere, en tagong ta harren waard ferliend op basis fan werklike brûkersoanfragen. Fansels is it gewoan ûnmooglik om in rolmodel te bouwen yn ferskate hûndert systemen tagelyk; jo moatte earne begjinne. Wy hawwe in yngeande analyse útfierd fan it proses foar tagongskontrôle om it nivo fan folwoeksenens te bepalen. Tidens it analyseproses waarden kritearia foar it prioritearjen fan ynformaasjesystemen ûntwikkele - krityk, reewilligens, plannen foar ûntmanteling, ensfh. Mei har help hawwe wy de ûntwikkeling / bywurking fan rolmodellen foar dizze systemen opsteld. En dan hawwe wy rolmodellen opnommen yn it plan foar yntegraasje mei de oplossing foar Identity Management om tagongskontrôle te automatisearjen.
Dus hoe bepale jo de kritikaliteit fan in systeem? Beantwurdzje sels de folgjende fragen:
- Is it systeem ferbûn mei de operasjonele prosessen wêrfan de kearnaktiviteiten fan it bedriuw ôfhingje?
- Sil systeem fersteuring beynfloedzje de yntegriteit fan it fermogen fan it bedriuw?
- Wat is de maksimum tastiene downtime fan it systeem, berikke dêr't it is ûnmooglik om te herstellen aktiviteit nei in ûnderbrekking?
- Kin in ynbreuk op de yntegriteit fan ynformaasje yn it systeem liede ta ûnomkearbere gefolgen, sawol finansjeel as reputaasje?
- Krityk oan fraude. De oanwêzigens fan funksjonaliteit, as net goed kontrolearre, kin liede ta ynterne / eksterne frauduleuze aksjes;
- Wat binne de wetlike easken en ynterne regels en prosedueres foar dizze systemen? Binne der boetes fan tafersjochhâlders foar net-neilibjen?
Yn ús finansjele bedriuw hawwe wy sa'n kontrôle útfierd. Behear ûntwikkele de kontrôleproseduere foar Access Rights Review om earst te sjen nei besteande brûkers en rjochten yn dy ynformaasjesystemen dy't op 'e list mei heechste prioriteit stiene. De feiligens ôfdieling waard tawiisd as de eigner fan dit proses. Mar om in folslein byld te krijen fan tagongsrjochten yn it bedriuw, wie it nedich om IT- en saaklike ôfdielingen by it proses te belûken. En hjir begûnen skeel, misferstannen, en soms sels sabotaazje: gjinien wol ôfbrekke fan har hjoeddeistige ferantwurdlikheden en belutsen wurde by guon, op it earste each, ûnbegryplike aktiviteiten.
NB Grutte bedriuwen mei ûntwikkele IT-prosessen binne wierskynlik bekend mei de IT-kontrôleproseduere - IT algemiene kontrôles (ITGC), wêrtroch jo tekoarten yn IT-prosessen kinne identifisearje en kontrôle fêststelle om prosessen te ferbetterjen yn oerienstimming mei bêste praktyk (ITIL, COBIT, IT) Bestjoer ensfh.) Sa'n kontrôle lit IT en bedriuw inoar better begripe en in mienskiplike ûntwikkelingstrategy ûntwikkelje, risiko's analysearje, kosten optimalisearje en effektiver wurkwize ûntwikkelje.
Ien fan 'e gebieten fan' e kontrôle is om de parameters fan logyske en fysike tagong ta ynformaasjesystemen te bepalen. Wy namen de krigen gegevens as basis foar fierdere gebrûk by it bouwen fan in rolmodel. As gefolch fan dizze kontrôle hiene wy in register fan IT-systemen, wêryn't har technyske parameters waarden bepaald en beskriuwingen waarden jûn. Derneist, foar elk systeem waard in eigner identifisearre út 'e saaklike rjochting yn waans belangen it waard eksploitearre: hy wie ferantwurdlik foar de saaklike prosessen dy't dit systeem tsjinne. In IT-tsjinstmanager waard ek beneamd, ferantwurdlik foar de technyske ymplemintaasje fan saaklike behoeften foar in spesifike IS. De meast krityske systemen foar it bedriuw en har technyske parameters, betingsten foar yn gebrûk nommen en ûntmanteling, ensfh.
Stap 3 Meitsje in metodyk
De kaai foar it sukses fan elk bedriuw is de juste metoade. Dêrom, sawol om in rolmodel te bouwen as om in kontrôle út te fieren, moatte wy in metodyk meitsje wêryn wy de ynteraksje tusken ôfdielingen beskriuwe, ferantwurdlikens fêststelle yn 'e regeljouwing fan it bedriuw, ensfh.
Earst moatte jo alle beskikbere dokuminten ûndersiikje dy't de proseduere fêststelle foar it jaan fan tagong en rjochten. Op in goede manier moatte prosessen op ferskate nivo's dokumintearre wurde:
- algemiene bedriuweasken;
- easken foar gebieten foar ynformaasjefeiligens (ôfhinklik fan 'e gebieten fan' e aktiviteiten fan 'e organisaasje);
- easken foar technologyske prosessen (ynstruksjes, tagongsmatriks, rjochtlinen, easken foar konfiguraasjes).
Yn ús finansjele bedriuw fûnen wy in protte ferâldere dokuminten; wy moasten se bringe yn oerienstimming mei de nije prosessen dy't wurde ymplementearre.
Yn opdracht fan behear is in wurkgroep makke, dy't fertsjintwurdigers fan feiligens, IT, bedriuw en ynterne kontrôle befette. De oarder sketste de doelen fan it meitsjen fan de groep, de rjochting fan aktiviteit, de perioade fan it bestean en de ferantwurdliken fan elke kant. Dêrnjonken hawwe wy in kontrôlemetoade ûntwikkele en in proseduere foar it bouwen fan in rolmodel: se waarden oerienkommen troch alle ferantwurdlike fertsjintwurdigers fan 'e gebieten en goedkard troch it bedriuwsmanagement.
Dokuminten dy't de proseduere beskriuwe foar it útfieren fan wurk, deadlines, ferantwurdlikheden, ensfh. - in garânsje dat op 'e wei nei it koestere doel, dat earst net foar elkenien dúdlik is, gjinien fragen sil hawwe "wêrom dogge wy dit, wêrom hawwe wy it nedich, ensfh." en d'r sil gjin kâns wêze om "ôf te springen" of it proses te fertragen.
Stap 4. Fixearje de parameters fan it besteande tagongskontrôlemodel
Wy meitsje in saneamd "systeempaspoart" op wat de tagongskontrôle oanbelanget. Yn essinsje is dit in fragelist oer in spesifyk ynformaasjesysteem, dat alle algoritmen registrearret foar it kontrolearjen fan tagong ta it. Bedriuwen dy't al oplossingen fan IdM-klasse hawwe ymplementearre binne wierskynlik bekend mei sa'n fragelist, om't dit is wêr't it ûndersyk fan systemen begjint.
Guon parameters oer it systeem en eigners streamden yn 'e fragelist fan it IT-register (sjoch stap 2, kontrôle), mar nije waarden ek tafoege:
- hoe't akkounts wurde beheard (direkt yn 'e database of fia software-ynterfaces);
- hoe't brûkers har oanmelde by it systeem (mei in apart akkount of mei in AD-akkount, LDAP, ensfh.);
- hokker nivo's fan tagong ta it systeem wurde brûkt (applikaasjenivo, systeemnivo, systeemgebrûk fan netwurkbestânboarnen);
- beskriuwing en parameters fan de servers dêr't it systeem rint;
- hokker operaasjes foar akkountbehear wurde stipe (blokkearje, omneame, ensfh.);
- hokker algoritmen of regels wurde brûkt foar it generearjen fan de systeembrûkersidentifikaasje;
- hokker attribút kin brûkt wurde om in ferbining te meitsjen mei it rekôr fan in meiwurker yn it personielsysteem (folsleine namme, personielnûmer, ensfh.);
- alle mooglike akkount attributen en regels foar it ynfoljen fan harren;
- hokker tagongsrjochten der binne yn it systeem (rollen, groepen, atoomrjochten, ensfh., binne der nêste of hiërargyske rjochten);
- meganismen foar it dielen fan tagongsrjochten (troch posysje, ôfdieling, funksjonaliteit, ensfh.);
- Hawwe it systeem regels foar segregaasje fan rjochten (SOD - Segregation of Duties), en hoe wurkje se;
- hoe't eveneminten fan ôfwêzigens, oerdracht, ûntslach, bywurkjen fan wurknimmergegevens, ensfh., wurde ferwurke yn it systeem.
Dizze list kin wurde fuortset, detaillearre de ferskate parameters en oare objekten dy't belutsen by de tagong kontrôle proses.
Stap 5. Meitsje in bedriuwsrjochte beskriuwing fan tagongsrjochten
In oar dokumint dat wy nedich binne by it bouwen fan in rolmodel is in referinsjeboek oer alle mooglike foegen (rjochten) dy't kinne wurde ferliend oan brûkers yn it ynformaasjesysteem mei in detaillearre beskriuwing fan 'e saaklike funksje dy't der efter stiet. Faak wurde autoriteiten yn it systeem fersifere mei bepaalde nammen besteande út letters en sifers, en saaklike meiwurkers kinne net útfine wat der efter dizze symboalen leit. Dan geane se nei de IT-tsjinst, en dêr... kinne se de fraach bygelyks oer selden brûkte rjochten ek net beäntwurdzje. Dan moatte ekstra testen dien wurde.
It is goed as der al in bedriuwsbeskriuwing is of sels as der in kombinaasje is fan dizze rjochten yn groepen en rollen. Foar guon applikaasjes is de bêste praktyk om sa'n referinsje te meitsjen yn 'e ûntwikkelingsstadium. Mar dit bart net faak, dat wy geane wer nei de IT-ôfdieling om ynformaasje oer alle mooglike rjochten te sammeljen en te beskriuwen. Us gids sil úteinlik it folgjende befetsje:
- namme fan 'e autoriteit, ynklusyf it objekt wêrop it tagongsrjocht jildt;
- in aksje dy't mei in objekt dien wurde kin (besjoch, feroarjen, ensfh., de mooglikheid fan beheining, bygelyks troch territoriale basis of troch groep kliïnten);
- autorisaasjekoade (koade en namme fan 'e systeemfunksje / fersyk dat kin wurde útfierd mei de autorisaasje);
- beskriuwing fan it gesach (detaillearre beskriuwing fan aksjes yn it IS by it tapassen fan it gesach en de gefolgen dêrfan foar it proses;
- tastimming status: "Aktyf" (as de tastimming wurdt tawiisd oan op syn minst ien brûker) of "Net aktyf" (as de tastimming wurdt net brûkt).
Stap 6 Wy downloade gegevens oer brûkers en rjochten fan 'e systemen en fergelykje se mei de personielsboarne
Op it lêste stadium fan tarieding moatte jo gegevens downloade fan ynformaasjesystemen oer alle brûkers en de rjochten dy't se op it stuit hawwe. D'r binne hjir twa mooglike senario's. Earst: de feiligensôfdieling hat direkte tagong ta it systeem en hat de middels om relevante rapporten te downloaden, wat net faak bart, mar tige handich is. Twad: wy stjoere in fersyk oan IT om rapporten yn it fereaske formaat te ûntfangen. De ûnderfining docht bliken dat it net mooglik is om de earste kear ta in oerienkomst te kommen mei IT en de nedige gegevens te krijen. It is needsaaklik om ferskate oanpak te meitsjen oant de ynformaasje wurdt ûntfongen yn 'e winske foarm en opmaak.
Hokker gegevens moatte wurde downloade:
- Account namme
- Folsleine namme fan de meiwurker oan wa't it is tawiisd
- Status (aktyf as blokkearre)
- Account oanmeitsjen datum
- Datum fan lêste gebrûk
- List fan beskikbere rjochten/groepen/rollen
Dat, wy krigen downloads fan it systeem mei alle brûkers en alle rjochten dy't har waarden ferliend. En se sette fuortendaliks alle blokkearre akkounts oan 'e kant, om't it wurk oan it bouwen fan in rolmodel allinich foar aktive brûkers wurdt útfierd.
Dan, as jo bedriuw gjin automatisearre middels hat om tagong ta ûntsleine meiwurkers te blokkearjen (dit bart faaks) of hat patchworkautomatisaasje dy't net altyd goed wurket, moatte jo alle "deade sielen" identifisearje. Wy prate oer de akkounts fan al ûntslein meiwurkers, waans rjochten om ien of oare reden net blokkearre binne - se moatte blokkearre wurde. Om dit te dwaan, fergelykje wy de opladen gegevens mei de personielsboarne. It lossen fan personiel moat ek foarôf krigen wurde fan 'e ôfdieling dy't de personielsdatabank ûnderhâldt.
Separate is it nedich om akkounts te setten wêrfan de eigners net fûn binne yn 'e personielsdatabank, net oan elkenien tawiisd - dat is, sûnder eigner. Mei dizze list sille wy de datum fan lêste gebrûk nedich hawwe: as it frij resint is, moatte wy noch sykje nei de eigners. Dit kin akkounts omfetsje fan eksterne oannimmers as tsjinstakkounts dy't net oan ien binne tawiisd, mar binne ferbûn mei alle prosessen. Om út te finen wa't de akkounts hearre, kinne jo brieven stjoere nei alle ôfdielingen mei de fraach om te reagearjen. As de eigners fûn binne, ynfiere wy gegevens oer har yn it systeem: op dizze manier wurde alle aktive akkounts identifisearre, en de rest wurde blokkearre.
Sadree't ús uploads binne wiske fan ûnnedige records en allinich aktive akkounts bliuwe, kinne wy begjinne in rolmodel te bouwen foar in spesifyk ynformaasjesysteem. Mar ik sil jo oer dit fertelle yn it folgjende artikel.
Auteur: Lyudmila Sevastyanova, promoasjemanager Solar inRights
Boarne: www.habr.com