Roletan oinarritutako sarbidea kontrolatzeko eredua eraikitzen ari gara. Lehen zatia, prestaketa

Gaur egun, software saltzaile batean lan egiten dut, zehazki, sarbide-kontrolerako soluzioentzat. Eta nire esperientzia "iraganeko bizitzatik" bezeroaren aldearekin lotuta dago: finantza-erakunde handi batekin. Garai hartan, informazio-segurtasun saileko gure sarbide-kontroleko taldeak ezin zuen IdM-n gaitasun handirik harrotu. Prozesuan asko ikasi dugu, kolpe asko jo behar izan ditugu enpresako informazio sistemetan erabiltzaileen eskubideak kudeatzeko lan mekanismo bat eraikitzeko.

Nire bezeroen esperientzia gogor lortutako saltzaileen ezagutza eta gaitasunekin konbinatuz, zuekin, funtsean, urratsez urratseko argibideak partekatu nahi ditut: nola sortu roletan oinarritutako sarbide-kontrol-eredu bat enpresa handi batean, eta horrek zer emango duen ondorioz. . Nire argibideak bi zati ditu: lehenengoa eredua eraikitzeko prestatzen ari da, bigarrena benetan eraikitzen ari da. Hona hemen lehen zatia, prestaketa zatia.

Oharra Eredu bat eraikitzea, zoritxarrez, ez da emaitza bat, prozesu bat baizik. Edo hobeto esanda, enpresan sarbide-kontroleko ekosistema bat sortzeko prozesuaren zati bat ere bai. Beraz, prest egon denbora luzez partidarako.

Lehenik eta behin, defini dezagun - zer da roletan oinarritutako sarbide-kontrola? Demagun hamarnaka edo ehunka mila langile (entitate) dituen banku handi bat duzula, eta horietako bakoitzak ehunka banku-informazio-sistema barne (objektu) sartzeko dozenaka eskubide ditu. Orain biderkatu objektu kopurua subjektu kopuruarekin - hau da lehenik eraiki eta gero kontrolatzeko behar dituzun konexio gutxieneko kopurua. Benetan posible al da hori eskuz egitea? Noski ez - rolak sortu ziren arazo hau konpontzeko.

Rol bat erabiltzaile edo erabiltzaile talde batek lan-zeregin jakin batzuk egiteko behar dituen baimen multzoa da. Langile bakoitzak rol bat edo gehiago izan ditzake, eta rol bakoitzak rol horren barruan erabiltzaileari baimentzen zaizkion baimen batetik bestera izan ditzake. Rolak langileen kargu, sail edo zeregin funtzional zehatzekin lotu daitezke.

Rolak, normalean, informazio-sistema bakoitzean langile indibidualaren baimenetatik sortzen dira. Ondoren, sistema bakoitzaren roletatik negozio globalak eratzen dira. Adibidez, "kreditu-kudeatzailea" negozio-eginkizunak hainbat rol bereiziko ditu bankuaren bezeroen bulegoan erabiltzen diren informazio-sistemetan. Adibidez, banku-sistema automatizatu nagusian, kutxako modulua, dokumentu elektronikoak kudeatzeko sistema, zerbitzu-kudeatzailea eta beste batzuk. Negozio-eginkizunak, oro har, antolakuntza-egiturari lotuta daude, hau da, enpresa-dibisio eta posizioen multzoari. Honela eratzen da rol-matrize global bat (adibide bat ematen dut beheko taulan).

Aipatzekoa da, besterik gabe, ezinezkoa dela %100eko eredu bat eraikitzea, merkataritza-egitura bateko lanpostu bakoitzeko langileei beharrezko eskubide guztiak emanez. Bai, hau ez da beharrezkoa. Azken finean, eredu bat ezin da estatikoa izan, etengabe aldatzen ari den ingurune baten araberakoa baita. Eta enpresaren negozio-jardueretan izandako aldaketetatik, eta horrek, horren arabera, antolakuntza-egituran eta funtzionaltasunean eragiten dituen aldaketetatik. Eta baliabideak guztiz hornitu ezetik, eta lanpostuen deskribapenak ez betetzetik, eta segurtasunaren kontura irabazi nahietatik eta beste hainbat faktoretik. Hori dela eta, beharrezkoa da lanpostu bat esleitzen denean erabiltzaileen beharren % 80ra arte bete ditzakeen oinarrizko eskubideen eredu bat eraikitzea. Eta, beharrezkoa izanez gero, gainerako % 20a eska dezakete geroago aplikazio bereizietan.

Jakina, galdetu dezakezu: "Ez al dago %100eko eredurik?" Beno, zergatik, hau gertatzen da, adibidez, maiz aldatzen ez diren irabazi asmorik gabeko egituretan - ikerketa institutu batzuetan. Edo segurtasun maila handiko erakunde militar-industrial konplexuetan, non segurtasuna lehenik. Egitura komertzial batean gertatzen da, baina zatiketa bereizi baten esparruan, zeinaren lana prozesu nahiko estatikoa eta aurreikus daitekeena.

Rolen bidezko kudeaketaren abantaila nagusia eskubideak jaulkitzearen sinplifikazioa da, rol kopurua informazio sistemaren erabiltzaile kopurua baino nabarmen txikiagoa delako. Eta hori egia da edozein industriarentzat.

Har dezagun txikizkako enpresa bat: milaka saltzaile enplegatzen ditu, baina eskubide multzo bera dute N sisteman, eta rol bakarra sortuko zaie. Saltzaile berri bat enpresara etortzen denean, automatikoki esleitzen zaio sisteman beharrezko eginkizuna, dagoeneko beharrezko agintari guztiak dituena. Gainera, klik bakarrean milaka saltzaileren eskubideak aldi berean alda ditzakezu, adibidez, txosten bat sortzeko aukera berri bat gehitu. Ez dago mila eragiketa egin beharrik, kontu bakoitzari eskubide berri bat lotuz - gehitu aukera hau rolari, eta saltzaile guztientzat agertuko da aldi berean.

Rolen bidezko kudeaketaren beste abantaila bat bateraezinak diren baimenen igorpena ezabatzea da. Hau da, sisteman eginkizun jakin bat duen langileak ezin du aldi berean beste eginkizunik izan, zeinaren eskubideak ez diren lehengo eskubideekin batu behar. Adibide deigarri bat finantza-transakzio baten sarrera eta kontrol funtzioak konbinatzeko debekua da.

Roletan oinarritutako sarbide-kontrola nola sortu zen jakiteko interesa duen edonork egin dezake
historian murgildu
Historiari erreparatzen badiogu, IT komunitateak lehen aldiz pentsatu zuen sarbidea kontrolatzeko metodoak XX. mendeko 70eko hamarkadan. Orduan aplikazioak nahiko sinpleak ziren arren, orain bezala, denek nahi zuten haien sarbidea eroso kudeatu. Eman, aldatu eta kontrolatu erabiltzailearen eskubideak, haietako bakoitzak zer sarbide duen errazago ulertzeko. Baina garai hartan ez zegoen estandar komunik, lehen sarbidea kontrolatzeko sistemak garatzen ari ziren, eta enpresa bakoitza bere ideia eta arauetan oinarritzen zen.

Sarbide kontrolatzeko eredu asko ezagutzen dira gaur egun, baina ez ziren berehala agertu. Arlo honen garapenean ekarpen esanguratsua egin dutenetan eztabaida gaitezen.

Lehenengo eredua eta seguruenik sinpleena da Sarbide-kontrol diskrezionala (selektiboa). (DAC – Diskreziozko sarbide-kontrola). Eredu honek sarbide prozesuan parte-hartzaile guztiek eskubideen partekatzea dakar. Erabiltzaile bakoitzak objektu edo eragiketa zehatzetarako sarbidea du. Funtsean, hemen eskubideen subjektu multzoa objektuen multzoari dagokio. Eredu hau malguegia eta mantentzea zaila zela ikusi zen: sarbide-zerrendak azkenean erraldoiak eta kontrolatzeko zailak bihurtzen dira.

Bigarren eredua da Derrigorrezko sarbide-kontrola (MAC - Derrigorrezko sarbide-kontrola). Eredu honen arabera, erabiltzaile bakoitzak objektu baterako sarbidea jasotzen du datuen konfidentzialtasun maila jakin baterako emandako sarbidearen arabera. Horren arabera, objektuak konfidentzialtasun-mailaren arabera sailkatu behar dira. Lehen eredu malgua ez bezala, hau, aitzitik, zorrotzegia eta murrizteegia izan zen. Bere erabilera ez da justifikatzen enpresak informazio-baliabide ezberdin asko dituenean: baliabide ezberdinetarako sarbidea bereizteko, gainjarri ez diren kategoria asko sartu beharko dituzu.

Bi metodo hauen akats nabariak direla eta, IT komunitateak malguagoak eta, aldi berean, gehiago edo gutxiago unibertsalak diren ereduak garatzen jarraitu du antolakuntza-sarbideen kontrol-politika mota desberdinak onartzen dituztenak. Eta orduan agertu zen hirugarren roletan oinarritutako sarbidea kontrolatzeko eredua! Ikuspegi hau itxaropentsuena dela frogatu da, erabiltzailearen identitatearen baimena ez ezik, sistemak dituen funtzio operatiboak ere eskatzen dituelako.

Argi deskribatutako lehen ereduaren egitura AEBetako Estandar eta Teknologia Institutu Nazionaleko David Ferrailo eta Richard Kuhn zientzialari estatubatuarrek proposatu zuten 1992an. Orduan, terminoa agertu zen lehen aldiz RBAC (Roletan oinarritutako sarbide-kontrola). Osagai nagusien azterketa eta deskribapen horiek, baita haien harremanak ere, gaur egun indarrean dagoen INCITS 359-2012 arauaren oinarria izan zen, International Committee on Information Technology Standards (INCITS) onartutakoa.

Estandarrak rol bat bezala definitzen du: "Rol horri esleitutako erabiltzaileari esleitutako agintaritzari eta erantzukizunari lotutako semantika batzuk dituen erakunde baten testuinguruko lan funtzioa". Dokumentuak RBACen oinarrizko elementuak ezartzen ditu: erabiltzaileak, saioak, rolak, baimenak, eragiketak eta objektuak, baita haien arteko harremanak eta interkonexioak ere.

Estandarrak eredu bat eraikitzeko beharrezkoa den gutxieneko egitura eskaintzen du: eskubideak roletan konbinatuz eta, ondoren, rol horien bidez erabiltzaileei sarbidea ematea. Objektuetatik eta eragiketetatik rolak osatzeko mekanismoak azaltzen dira, rolen hierarkia eta botereen herentzia deskribatzen dira. Azken finean, edozein enpresatan badira enpresako langile guztientzat beharrezkoak diren oinarrizko ahalmenak batzen dituzten rolak. Hau posta elektronikorako sarbidea izan daiteke, EDMS, atari korporatiboa, etab. Baimen hauek "langilea" izeneko rol orokor batean sar daitezke, eta ez da beharrezkoa izango oinarrizko eskubide guztiak behin eta berriro zerrendatu goi-mailako rol bakoitzean. Nahikoa da, besterik gabe, "langile" eginkizunaren herentzia ezaugarria adieraztea.

Geroago, estandarra etengabe aldatzen ari den ingurunearekin lotutako sarbide-atributu berriekin osatu zen. Murrizketa estatiko eta dinamikoak sartzeko gaitasuna gehitu da. Estatikoek rolak bateratzeko ezintasuna suposatzen dute (lehen aipatutako eragiketen sarrera eta kontrol bera). Murrizketa dinamikoak parametroak aldatuz zehaztu daitezke, adibidez, ordua (laneko orduak edo ez-lanak edo egunak), kokapena (bulegoa/etxea), etab.

Bereizita, buruz esan behar da atributuetan oinarritutako sarbide-kontrola (ABAC - Attribute-based access control). Planteamendua atributuak partekatzeko arauak erabiliz sarbidea ematean oinarritzen da. Eredu hau bereiz erabil daiteke, baina sarritan aktiboki osatzen du eredu klasikoa: erabiltzaileen, baliabideen eta gailuen atributuak, baita denbora edo kokapena ere, eginkizun jakin bati gehi daitezke. Horri esker, rol gutxiago erabili, murrizketa gehigarriak ezarri eta sarbidea ahalik eta gutxien egin dezakezu eta, beraz, segurtasuna hobetu.

Adibidez, kontulari bati kontuetarako sarbidea baimendu ahal izango zaio eskualde jakin batean lan egiten badu. Ondoren, espezialistaren kokapena erreferentzia-balio jakin batekin alderatuko da. Edo kontuetarako sarbidea eman dezakezu erabiltzailea baimendutakoen zerrendan sartutako gailu batetik hasten bada bakarrik. Eredu baten osagarri ona, baina bere kabuz oso gutxitan erabiltzen den arau eta baimen edo murrizketa ugari sortu behar direlako.

Eman dezadan nire "iraganeko bizitza" ABAC erabiltzearen adibide bat. Gure bankuak hainbat bulego zituen. Bulego horietako bezeroen bulegoetako langileek eragiketa berdinak egiten zituzten, baina sistema nagusian lan egin behar izan zuten beren eskualdeko kontuekin soilik. Lehenik eta behin, eskualde bakoitzerako rol bereiziak sortzen hasi ginen, eta horrelako rol asko zeuden funtzionalitate errepikakorrak, baina kontu ezberdinetarako sarbidea! Ondoren, erabiltzailearen kokapen-atributu bat erabiliz eta berrikusteko kontu sorta zehatz batekin lotuz, sistemako rol kopurua nabarmen murriztu dugu. Ondorioz, sukurtsal bakarreko rolak geratu ziren, bankuaren gainerako lurralde-zatiketa guztietan dagozkien postuetarako errepikatu zirenak.

Orain hitz egin dezagun beharrezko prestaketa-urratsei buruz, eta horiek gabe ezinezkoa da lan-eredu bat eraikitzea.

1. urratsa. Sortu eredu funtzional bat

Eredu funtzional bat sortzen hasi beharko zenuke: sail bakoitzaren eta kargu bakoitzaren funtzionaltasuna zehatz-mehatz deskribatzen duen goi-mailako dokumentua. Oro har, informazioa hainbat dokumentutatik sartzen da: lan-deskribapenak eta banakako unitateen araudia - sailak, dibisioak, sailak. Eredu funtzionala interesa duten sail guztiekin (enpresa, barne-kontrola, segurtasuna) adostu eta enpresako zuzendaritzak onartu beharko du. Zertarako balio du dokumentu hau? Ereduak hari erreferentzia egin dezan. Adibidez, langileen dauden eskubideetan oinarritutako eredu bat eraikiko duzu, sistematik deskargatuta eta "izendatzaile komun batera murriztuta". Ondoren, sistemaren enpresa-jabearekin jasotako rolak adostean, eredu funtzionalaren puntu zehatz batera jo dezakezu, zeinaren arabera eskubide hau edo beste eginkizunean sartzen den.

2. urratsa. Sistema informatikoak ikuskatzen ditugu eta lehentasun-plan bat egiten dugu

Bigarren fasean, sistema informatikoen auditoria bat egin beharko zenuke, haietarako sarbidea nola antolatzen den ulertzeko. Esaterako, nire finantza-enpresak ehunka informazio sistemak funtzionatzen zituen. Sistema guztiek roletan oinarritutako kudeaketaren oinarri batzuk zituzten, gehienek rol batzuk zituzten, baina gehienetan paperean edo sistemaren direktorioan - aspaldi zaharkituta zeuden, eta erabiltzaileen benetako eskaeren arabera ematen zen haietarako sarbidea. Jakina, ezinezkoa da aldi berean ehunka sistematan eredu bat eraikitzea; nonbait hasi behar duzu. Sarbide-kontrolaren prozesuaren azterketa sakona egin dugu, bere heldutasun-maila zehazteko. Azterketa-prozesuan, informazio-sistemei lehentasuna emateko irizpideak garatu ziren -kritikotasuna, prestutasuna, desafektatzeko planak, etab. Haien laguntzarekin, sistema hauen ereduen garapena/eguneratzea lerrokatu genuen. Eta gero, sarbide-kontrola automatizatzeko Identity Management irtenbidearekin integratzeko planean ereduak sartu genituen.

Beraz, nola zehazten duzu sistema baten kritikotasuna? Erantzun zeure buruari galdera hauei:

• Loturik al dago sistema enpresaren oinarrizko jarduerak menpe dauden prozesu operatiboekin?
• Sistemaren etenaldiak enpresaren aktiboen osotasunean eragingo al du?
• Zein da sistemaren gehienezko geldialdi onargarria, etenaldi baten ondoren jarduera berrezartzea ezinezkoa izateraino?
• Sistemako informazioaren osotasuna urratzeak ondorio itzulezinak ekar ditzake, bai finantzarioak, bai ospezkoak?
• Iruzurrarekiko kritikotasuna. Funtzionalitateak egoteak, behar bezala kontrolatzen ez badira, barne/kanpoko iruzurrezko ekintzak sor ditzake;
• Zeintzuk dira sistema horien legezko baldintzak eta barne-arauak eta prozedurak? Arautzaileen isunak egongo dira ez betetzeagatik?

Gure finantza-konpainian, horrelako auditoria bat egin genuen. Zuzendaritzak Access Rights Review auditoria-prozedura garatu zuen lehendik dauden erabiltzaileak eta eskubideak lehentasun handieneko zerrendan zeuden informazio-sistemetan lehenik aztertzeko. Segurtasun saila esleitu zen prozesu honen jabe gisa. Baina enpresaren sarbide-eskubideen argazki osoa lortzeko, beharrezkoa zen prozesuan IT eta negozio sailak inplikatzea. Eta hemen hasi ziren gatazkak, gaizki-ulertuak eta, batzuetan, sabotajeak ere: inork ez ditu bere egungo ardurak hautsi nahi eta lehen begiratuan ulertezineko jarduera batzuetan sartu.

Oharra Garatutako informatika-prozesuak dituzten enpresa handiek ziurrenik ezagutzen dute IT auditoretza-prozedura - IT kontrol orokorrak (ITGC), eta horrek aukera ematen dizu IT prozesuen gabeziak identifikatzea eta kontrola ezartzeko, prozesuak praktika onen arabera hobetzeko (ITIL, COBIT, IT). Gobernantza, etab.) Ikuskaritza horri esker, IT eta negozioak elkar hobeto ulertzea eta garapen estrategia bateratua garatzea, arriskuak aztertzea, kostuak optimizatzea eta lanerako ikuspegi eraginkorragoak garatzea ahalbidetzen du.



Ikuskaritzaren arloetako bat informazio sistemetarako sarbide logiko eta fisikoaren parametroak zehaztea da. Lortutako datuak oinarritzat hartu ditugu eredu bat eraikitzeko gehiago erabiltzeko. Ikuskaritza horren ondorioz, sistema informatikoen erregistro bat genuen, eta bertan haien parametro teknikoak zehaztu eta deskribapenak ematen ziren. Gainera, sistema bakoitzerako, jabe bat identifikatu zen zeinen interesen arabera jarduten zen negozioaren zuzendaritzatik: bera zen sistema honek zerbitzatzen zituen negozio prozesuen arduraduna. Informatika zerbitzuen arduradun bat ere izendatu zen, IS zehatz baterako negozio-beharren ezarpen teknikoaz arduratzen dena. Enpresarentzako sistema kritikoenak eta haien parametro teknikoak, martxan jartzeko eta desafektatzeko baldintzak eta abar erregistratu ziren.Parametro hauek oso lagungarriak izan ziren eredu bat sortzeko prestatzeko prozesuan.

3. urratsa Sortu metodologia

Edozein negozioren arrakastaren gakoa metodo egokia da. Hori dela eta, bai eredu bat eraikitzeko, bai auditoretza egiteko, metodologia bat sortu behar dugu, non sailen arteko elkarrekintza deskribatu, enpresaren araudian erantzukizuna ezartzeko, etab.
Lehenik eta behin sarbidea eta eskubideak emateko prozedura ezartzen duten dokumentu eskuragarri guztiak aztertu behar dituzu. Modu onean, prozesuak hainbat mailatan dokumentatu behar dira:

• eskakizun korporatibo orokorrak;
• Informazioaren segurtasun arloetarako eskakizunak (erakundearen jarduera-eremuen arabera);
• prozesu teknologikoen eskakizunak (argibideak, sarbide-matrizeak, jarraibideak, konfigurazio-eskakizunak).

Gure finantza-konpainian, dokumentu zaharkitu asko aurkitu ditugu, martxan jarritako prozesu berrien arabera ekarri behar izan ditugu.

Zuzendaritzaren aginduz, lantalde bat sortu zen, eta bertan segurtasun, informatika, negozio eta barne kontroleko ordezkariak zeuden. Aginduak taldea sortzeko helburuak, jardueraren nondik norakoak, existentziaren aldia eta alde bakoitzeko arduradunak zehazten zituen. Horrez gain, auditoretza-metodologia eta eredu bat eraikitzeko prozedura bat garatu genuen: arloetako ordezkari arduradun guztiek adostu eta enpresako zuzendaritzak onartu zituen.

Lanak egiteko prozedura, epeak, ardurak eta abar deskribatzen dituzten agiriak. - Hasieran denentzat begi-bistakoa ez den helburu kuttunaren bidean inork ez duela galderarik izango “zergatik egiten dugu hau, zergatik behar dugu, etab”. eta ez da “jauzi egiteko” edo prozesua moteltzeko aukerarik izango.

4. urratsa. Konpondu lehendik dagoen sarbide-kontrol ereduaren parametroak

Sarbideen kontrolari dagokionez “sistema pasaportea” deritzon bat egiten ari gara. Funtsean, informazio-sistema zehatz bati buruzko galdetegia da, eta horretarako sarbidea kontrolatzeko algoritmo guztiak erregistratzen ditu. Dagoeneko IdM mailako soluzioak ezarri dituzten enpresek ziurrenik ezagutzen dute horrelako galdetegi bat, hor hasten baita sistemen azterketa.

Sistemari eta jabeei buruzko parametro batzuk IT erregistrotik sartu ziren galdetegian (ikus 2. urratsa, auditoria), baina berriak ere gehitu ziren:

• kontuak nola kudeatzen diren (zuzenean datu-basean edo software interfazeen bidez);
• erabiltzaileak sisteman nola hasten diren saioa (bereiz kontu bat erabiliz edo AD kontu bat, LDAP, etab. erabiliz);
• zer-nolako sarbide-maila erabiltzen diren sistemarako (aplikazio-maila, sistema-maila, sareko fitxategi-baliabideen sistemaren erabilera);
• sistemak exekutatzen dituen zerbitzarien deskribapena eta parametroak;
• zer kontu kudeatzeko eragiketa onartzen diren (blokeatzea, izena aldatzea, etab.);
• zer algoritmo edo arau erabiltzen diren sistemaren erabiltzaile-identifikatzailea sortzeko;
• zer atributu erabil daitekeen langile baten erregistroarekin lotura bat ezartzeko pertsonal sisteman (izen-abizenak, langile-zenbakia, etab.);
• kontu-atributu posible guztiak eta horiek betetzeko arauak;
• zer sarbide-eskubide dauden sisteman (rolak, taldeak, eskubide atomikoak, etab., eskubide habiaratuak edo hierarkizatuak dauden);
• sarbide-eskubideak banatzeko mekanismoak (postuaren, sailaren, funtzionalitatearen, etab.);
• Ba al ditu sistemak eskubideak bereizteko arauak (SOD – Segregation of Duties), eta nola funtzionatzen duten;
• sisteman absentzia, lekualdatze, kaleratze, langileen datuak eguneratzeko eta abar gertaerak nola tratatzen diren.

Zerrenda honek sarbide-kontrol-prozesuan parte hartzen duten hainbat parametro eta bestelako objektuei buruzko xehetasunekin jarraitu daiteke.

5. urratsa. Sortu negozioari zuzendutako baimenen deskribapena

Eredu bat eraikitzerakoan beharko dugun beste dokumentu bat da, informazio-sisteman erabiltzaileei eman dakizkiekeen ahalmen (eskubide) posible guztiei buruzko erreferentzia-liburua, horren atzean dagoen negozio-funtzioaren deskribapen zehatzarekin. Askotan, sistemako agintariak letraz eta zenbakiz osatutako izen batzuekin zifratzen dira, eta negozioetako langileek ezin dute asmatu ikur horien atzean zer dagoen. Gero informatika zerbitzura joaten dira, eta hor... galderari ere ezin diote erantzun, adibidez, gutxi erabiltzen diren eskubideei buruzkoa. Ondoren, proba osagarriak egin behar dira.

Ona da dagoeneko negozioaren deskribapena badago edo eskubide horiek talde eta roletan konbinatzen badira ere. Aplikazio batzuetarako, praktikarik egokiena garapen fasean erreferentzia hori sortzea da. Baina hori ez da askotan gertatzen, beraz, berriro ere informatika sailera joaten gara eskubide posible guztiei buruzko informazioa biltzeko eta horiek deskribatzeko. Gure gidak, azken batean, honako hauek izango ditu:

• agintaritzaren izena, sarbide-eskubidea aplikatzen zaion objektua barne;
• objektu batekin egin daitekeen ekintza bat (ikustea, aldatzea, etab., mugatzeko aukera, adibidez, lurraldearen arabera edo bezero taldeen arabera);
• baimen-kodea (baimena erabiliz exekutatu daitekeen sistemaren funtzio/eskaeraren kodea eta izena);
• Agintearen deskribapena (IS-ko ekintzen deskribapen zehatza agintaritza aplikatzean eta prozesurako dituzten ondorioak;
• baimenaren egoera: "Aktibo" (baimena gutxienez erabiltzaile bati esleituta badago) edo "Ez aktibo" (baimena erabiltzen ez bada).

6. urratsa Erabiltzaileei eta eskubideei buruzko datuak sistemetatik deskargatzen ditugu eta langileen iturriarekin konparatzen ditugu

Prestaketaren azken fasean, erabiltzaile guztiei eta gaur egun dituzten eskubideei buruzko informazio sistemetako datuak deskargatu behar dituzu. Hemen bi eszenatoki posible daude. Lehena: segurtasun sailak sistemarako sarbide zuzena du eta txosten garrantzitsuak deskargatzeko bitartekoak ditu, hori ez da askotan gertatzen, baina oso erosoa da. Bigarrena: ITra eskaera bat bidaltzen dugu txostenak behar den formatuan jasotzeko. Esperientziak erakusten du ezin dela ITrekin akordio batera iritsi eta beharrezko datuak lehen aldiz eskuratzea. Hainbat hurbilketa egin behar dira informazioa nahi den forman eta formatuan jaso arte.

Zein datu deskargatu behar diren:

• Kontuaren izena
• Esleitu zaion langilearen izen-abizenak
• Egoera (aktibo edo blokeatuta)
• Kontua sortzeko data
• Azken erabileraren data
• Eskuragarri dauden eskubide/talde/rolen zerrenda

Beraz, sistematik deskargak jaso genituen erabiltzaile guztiekin eta haiek emandako eskubide guztiekin. Eta berehala alde batera utzi dituzte blokeatutako kontu guztiak, eredu bat eraikitzeko lanak erabiltzaile aktiboentzat bakarrik egingo baitira.

Orduan, zure enpresak ez badu kaleratutako langileen sarbidea blokeatzeko bitarteko automatizaturik (hau askotan gertatzen da) edo beti behar bezala funtzionatzen ez duen adabaki automatizazioa badu, "hildako arima" guztiak identifikatu behar dituzu. Dagoeneko kaleratu dituzten langileen kontuez ari gara, haien eskubideak arrazoiren batengatik blokeatuta ez daudenez -blokeatu egin behar dira-. Horretarako, igotako datuak langileen iturriarekin konparatzen ditugu. Langileen deskarga ere aldez aurretik lortu behar da langileen datu-basea mantentzen duen sailean.

Bereiz, beharrezkoa da langileen datu-basean jabeak aurkitu ez diren kontuak alde batera utzi, inori esleitu ez zaizkion kontuak, hau da, jaberik gabekoak. Zerrenda hau erabiliz, azken erabileraren data beharko dugu: nahiko berria bada, jabeak bilatu beharko ditugu oraindik. Inori esleitzen ez zaizkion, baina edozein prozesurekin lotuta dauden kanpoko kontratisten kontuak edo zerbitzu kontuak izan daitezke. Kontuak norenak diren jakiteko, eskutitzak bidali ditzakezu sail guztietara erantzuteko eskatuz. Jabeak aurkitzen direnean, haiei buruzko datuak sartzen ditugu sisteman: horrela, aktibo dauden kontu guztiak identifikatzen dira, eta gainerakoak blokeatzen dira.

Gure kargak alferrikako erregistroetatik garbitu eta kontu aktibo bakarrik geratzen diren bezain laster, informazio-sistema zehatz baterako eredu bat eraikitzen has gaitezke. Baina honi buruz hurrengo artikuluan kontatuko dizut.

Egilea: Lyudmila Sevastyanova, sustapen-kudeatzailea Solar inRights

Iturria: www.habr.com