Gradimo model nadzora dostopa na podlagi vlog. Prvi del, pripravljalni

Trenutno delam za prodajalca programske opreme, zlasti rešitev za nadzor dostopa. In moja izkušnja "iz preteklega življenja" je povezana s strankino stranjo - veliko finančno organizacijo. Takrat se naša skupina za nadzor dostopa v oddelku za informacijsko varnost ni mogla pohvaliti z velikimi kompetencami v IdM. Pri tem smo se veliko naučili, morali smo naleteti na veliko zapletov, da smo zgradili delujoč mehanizem za upravljanje uporabniških pravic v informacijskih sistemih v podjetju.

Z združevanjem svojih težko prigaranih uporabniških izkušenj z znanjem in kompetencami prodajalcev želim z vami deliti v bistvu navodila po korakih: kako ustvariti model nadzora dostopa na podlagi vlog v velikem podjetju in kaj bo to dalo kot rezultat . Moja navodila so sestavljena iz dveh delov: prvi je priprava na sestavo modela, drugi pa dejansko sestava. Tukaj je prvi del, pripravljalni del.

Opomba: Gradnja vzornika žal ni rezultat, ampak proces. Oziroma celo del procesa ustvarjanja ekosistema nadzora dostopa v podjetju. Zato se dolgo pripravljajte na igro.

Najprej ga definirajmo – kaj je nadzor dostopa na podlagi vlog? Recimo, da imate veliko banko z desetinami ali celo stotisoči zaposlenih (entitet), od katerih ima vsak na desetine pravic dostopa do več sto internih bančnih informacijskih sistemov (objektov). Zdaj pomnožite število objektov s številom subjektov - to je najmanjše število povezav, ki jih morate najprej zgraditi in nato nadzorovati. Je to res možno narediti ročno? Seveda ne - vloge so bile ustvarjene za rešitev tega problema.

Vloga je nabor dovoljenj, ki jih uporabnik ali skupina uporabnikov potrebuje za izvajanje določenih delovnih nalog. Vsak zaposleni ima lahko eno ali več vlog in vsaka vloga lahko vsebuje od enega do več dovoljenj, ki so dovoljena uporabniku znotraj te vloge. Vloge so lahko vezane na določena delovna mesta, oddelke ali funkcionalne naloge zaposlenih.

Vloge so običajno kreirane iz posameznih pooblastil zaposlenih v vsakem informacijskem sistemu. Nato se iz vlog vsakega sistema oblikujejo globalne poslovne vloge. Na primer, poslovna vloga "kreditni menedžer" bo vključevala več ločenih vlog v informacijskih sistemih, ki se uporabljajo v pisarni za stranke banke. Na primer v glavnem avtomatiziranem bančnem sistemu, gotovinskem modulu, elektronskem sistemu za upravljanje dokumentov, upravitelju storitev in drugih. Poslovne vloge so praviloma vezane na organizacijsko strukturo – z drugimi besedami, na nabor oddelkov podjetja in položajev v njih. Tako se oblikuje globalna matrika vlog (primer navajam v spodnji tabeli).

Omeniti velja, da je preprosto nemogoče zgraditi 100-odstotni vzornik, ki zagotavlja vse potrebne pravice za zaposlene na vsakem položaju v komercialni strukturi. Da, to ni potrebno. Navsezadnje vzornik ne more biti statičen, saj je odvisen od nenehno spreminjajočega se okolja. In od sprememb v poslovnih dejavnostih družbe, kar posledično vpliva na spremembe v organizacijski strukturi in funkcionalnosti. In zaradi pomanjkanja polne preskrbljenosti z viri, pa zaradi neupoštevanja opisov delovnih mest, pa zaradi želje po dobičku na račun varnosti in zaradi številnih drugih dejavnikov. Zato je treba zgraditi vzor, ​​ki lahko pokrije do 80 % potreb uporabnika po potrebnih osnovnih pravicah, ko je dodeljen delovnemu mestu. Preostalih 20% pa lahko po potrebi zahtevajo pozneje na ločenih vlogah.

Seveda se lahko vprašate: "Ali ni 100-odstotnih vzornikov?" No, zakaj, to se zgodi na primer v neprofitnih strukturah, ki niso podvržene pogostim spremembam - v nekem raziskovalnem inštitutu. Ali v organizacijah vojaško-industrijskega kompleksa z visoko stopnjo varnosti, kjer je varnost na prvem mestu. To se zgodi v komercialni strukturi, vendar v okviru ločenega oddelka, katerega delo je dokaj statičen in predvidljiv proces.

Glavna prednost upravljanja z vlogami je poenostavitev izdajanja pravic, saj je število vlog bistveno manjše od števila uporabnikov informacijskega sistema. In to velja za vsako panogo.

Vzemimo maloprodajno podjetje: zaposluje na tisoče prodajalcev, vendar imajo enak nabor pravic v sistemu N in zanje bo ustvarjena le ena vloga. Ko v podjetje pride nov komercialist, se mu samodejno dodeli zahtevana vloga v sistemu, ki že ima vsa potrebna pooblastila. Prav tako lahko z enim klikom spremenite pravice za več tisoč prodajalcev hkrati, na primer dodate novo možnost za ustvarjanje poročila. Ni vam treba opraviti tisoč operacij in povezati nove pravice z vsakim računom - samo dodajte to možnost vlogi in prikazala se bo vsem prodajalcem hkrati.

Druga prednost upravljanja na podlagi vlog je odprava izdajanja nezdružljivih pooblastil. To pomeni, da zaposleni, ki ima določeno vlogo v sistemu, ne more hkrati imeti druge vloge, katere pravice ne bi smele biti združene s pravicami v prvi. Osupljiv primer je prepoved združevanja funkcij vnosa in nadzora finančne transakcije.

Kogar zanima, kako je nastal nadzor dostopa na podlagi vlog, lahko
potopite se v zgodovino
Če pogledamo v zgodovino, je IT skupnost o metodah nadzora dostopa prvič razmišljala že v 70. letih XNUMX. stoletja. Čeprav so bile aplikacije takrat dokaj preproste, si je tako kot danes vsak zelo želel priročno upravljati dostop do njih. Dodelite, spremenite in nadzirajte uporabniške pravice – samo zato, da boste lažje razumeli, kakšen dostop ima vsak od njih. Toda takrat še ni bilo skupnih standardov, razvijali so se prvi sistemi za nadzor dostopa in vsako podjetje je temeljilo na svojih idejah in pravilih.

Zdaj je znanih veliko različnih modelov nadzora dostopa, vendar se niso pojavili takoj. Oglejmo si tiste, ki so pomembno prispevali k razvoju tega področja.

Prvi in ​​verjetno najpreprostejši model je Diskrecijska (selektivna) kontrola dostopa (DAC – diskrecijska kontrola dostopa). Ta model pomeni delitev pravic med vsemi udeleženci v procesu dostopa. Vsak uporabnik ima dostop do določenih objektov ali operacij. V bistvu tu množica subjektov pravic ustreza množici predmetov. Ta model se je izkazal za preveč prilagodljivega in pretežkega za vzdrževanje: seznami dostopov sčasoma postanejo ogromni in jih je težko nadzorovati.

Drugi model je Obvezna kontrola dostopa (MAC - Mandatory access control). Po tem modelu vsak uporabnik prejme dostop do objekta v skladu z izdanim dostopom do določene stopnje zaupnosti podatkov. V skladu s tem je treba predmete kategorizirati glede na njihovo stopnjo zaupnosti. Za razliko od prvega fleksibilnega modela se je ta, nasprotno, izkazal za preveč strogega in restriktivnega. Njegova uporaba ni upravičena, če ima podjetje veliko različnih informacijskih virov: da bi razlikovali dostop do različnih virov, boste morali uvesti veliko kategorij, ki se ne bodo prekrivale.

Zaradi očitnih nepopolnosti teh dveh metod je skupnost IT še naprej razvijala modele, ki so bolj prilagodljivi in ​​hkrati bolj ali manj univerzalni za podporo različnih vrst organizacijskih politik nadzora dostopa. In potem se je pojavilo tretji model nadzora dostopa na podlagi vlog! Ta pristop se je izkazal za najbolj obetavnega, saj ne zahteva samo avtorizacije identitete uporabnika, temveč tudi njegove operativne funkcije v sistemih.

Prvo jasno opisano strukturo vzornika sta leta 1992 predlagala ameriška znanstvenika David Ferrailo in Richard Kuhn z ameriškega Nacionalnega inštituta za standarde in tehnologijo. Potem se je izraz prvič pojavil RBAC (nadzor dostopa na podlagi vlog). Te študije in opisi glavnih komponent ter njihovih odnosov so bili osnova standarda INCITS 359-2012, ki velja še danes in ga je odobril Mednarodni odbor za standarde informacijske tehnologije (INCITS).

Standard opredeljuje vlogo kot "delovno funkcijo v kontekstu organizacije z neko povezano semantiko v zvezi s pooblastilom in odgovornostjo, dodeljeno uporabniku, dodeljenemu vlogi." Dokument vzpostavlja osnovne elemente RBAC - uporabnike, seje, vloge, dovoljenja, operacije in objekte ter odnose in medsebojne povezave med njimi.

Standard zagotavlja minimalno potrebno strukturo za izgradnjo vzornika – združevanje pravic v vloge in nato dodeljevanje dostopa uporabnikom prek teh vlog. Orisani so mehanizmi za sestavljanje vlog iz objektov in operacij, opisana je hierarhija vlog in dedovanje pooblastil. Navsezadnje v vsakem podjetju obstajajo vloge, ki združujejo osnovna pooblastila, ki so potrebna za vse zaposlene v podjetju. To je lahko dostop do e-pošte, EDMS, korporativnega portala itd. Ta dovoljenja je mogoče vključiti v eno splošno vlogo, imenovano »zaposleni«, in ne bo treba znova in znova navajati vseh osnovnih pravic v vsaki vlogi na višji ravni. Dovolj je, da preprosto navedete značilnost dedovanja vloge "zaposleni".

Kasneje je bil standard dopolnjen z novimi dostopnimi atributi, povezanimi z nenehno spreminjajočim se okoljem. Dodana je bila možnost uvajanja statičnih in dinamičnih omejitev. Statični pomenijo nezmožnost kombiniranja vlog (isti vnos in nadzor nad operacijami, omenjen zgoraj). Dinamične omejitve lahko določite s spreminjanjem parametrov, na primer časa (delovni/nedelovni čas ali dnevi), lokacije (pisarna/dom) itd.

Vredno je omeniti ločeno kontrola dostopa na podlagi atributov (ABAC - Attribute-based access control). Pristop temelji na odobritvi dostopa z uporabo pravil deljenja atributov. Ta model se lahko uporablja ločeno, pogosto pa aktivno dopolnjuje klasični vzor: določeni vlogi je mogoče dodati atribute uporabnikov, sredstev in naprav ter čas ali lokacijo. To vam omogoča, da uporabite manj vlog, uvedete dodatne omejitve in naredite čim manjši dostop ter tako izboljšate varnost.

Na primer, računovodji se lahko omogoči dostop do računov, če dela v določeni regiji. Nato se lokacija specialista primerja z določeno referenčno vrednostjo. Lahko pa omogočite dostop do računov le, če se uporabnik prijavi z naprave, ki je na seznamu dovoljenih. Dober dodatek k vzorniku, vendar se redko uporablja samostojno zaradi potrebe po ustvarjanju številnih pravil in tabel z dovoljenji ali omejitvami.

Naj vam dam primer uporabe ABAC iz mojega "prejšnjega življenja". Naša banka je imela več poslovalnic. Zaposleni v pisarnah strank v teh poslovalnicah so opravljali popolnoma enake operacije, vendar so morali delati v glavnem sistemu samo z računi v svoji regiji. Najprej smo začeli ustvarjati ločene vloge za vsako regijo – in bilo je toliko takih vlog s ponavljajočo se funkcijo, vendar z dostopom do različnih računov! Nato smo z uporabo atributa lokacije za uporabnika in njegovim povezovanjem z določenim obsegom računov za pregled znatno zmanjšali število vlog v sistemu. Posledično so vloge ostale samo za eno podružnico, ki so bile podvojene za ustrezne položaje v vseh drugih teritorialnih oddelkih banke.

Zdaj pa se pogovorimo o potrebnih pripravljalnih korakih, brez katerih preprosto ni mogoče zgraditi delujočega vzornika.

Korak 1. Ustvarite funkcionalni model

Začeti morate z ustvarjanjem funkcionalnega modela - dokumenta na najvišji ravni, ki podrobno opisuje funkcionalnost vsakega oddelka in vsakega položaja. Podatki vanj praviloma vstopajo iz različnih dokumentov: opisov delovnih mest in pravilnikov za posamezne enote – oddelke, oddelke, oddelke. Funkcionalni model mora biti usklajen z vsemi zainteresiranimi službami (poslovni, notranji nadzor, varnost) in potrjen s strani vodstva podjetja. Za kaj je ta dokument? Da se lahko vzornik sklicuje na to. Na primer, zgradili boste vzor na podlagi obstoječih pravic zaposlenih – razbremenjenih iz sistema in “zreduciranih na skupni imenovalec”. Nato se lahko pri dogovarjanju o prejetih vlogah s poslovnim lastnikom sistema sklicujete na določeno točko v funkcionalnem modelu, na podlagi katere je ta ali ona pravica vključena v vlogo.

2. korak. Revidiramo IT sisteme in pripravimo načrt prioritet

Na drugi stopnji bi morali opraviti revizijo IT sistemov, da bi razumeli, kako je organiziran dostop do njih. Moje finančno podjetje je na primer upravljalo več sto informacijskih sistemov. Vsi sistemi so imeli nekaj zametkov upravljanja z vlogami, večina jih je imela nekaj vlog, vendar večinoma na papirju ali v sistemskem imeniku - bili so že zdavnaj zastareli, dostop do njih pa se je omogočal na podlagi dejanskih zahtev uporabnikov. Seveda je preprosto nemogoče zgraditi vzor v več sto sistemih hkrati, nekje je treba začeti. Izvedli smo poglobljeno analizo procesa nadzora dostopa, da bi ugotovili njegovo stopnjo zrelosti. V procesu analize so bili razviti kriteriji za prioriteto informacijskih sistemov - kritičnost, pripravljenost, načrti za razgradnjo itd. Z njihovo pomočjo smo začrtali razvoj/posodabljanje vzornikov za te sisteme. Nato smo vključili vzornike v načrt za integracijo z rešitvijo za upravljanje identitete za avtomatizacijo nadzora dostopa.

Kako torej določite kritičnost sistema? Odgovorite si na naslednja vprašanja:

• Ali je sistem povezan z operativnimi procesi, od katerih je odvisna osnovna dejavnost podjetja?
• Bo sistemska motnja vplivala na celovitost premoženja podjetja?
• Kolikšen je najdaljši dopustni čas izpada sistema, pri katerem je po prekinitvi nemogoče obnoviti delovanje?
• Ali lahko kršitev celovitosti informacij v sistemu povzroči nepopravljive posledice, tako finančne kot ugledne?
• Kritičnost do prevare. Prisotnost funkcionalnosti, če ni ustrezno nadzorovana, lahko vodi do notranjih/zunanjih goljufivih dejanj;
• Kakšne so pravne zahteve ter notranja pravila in postopki za te sisteme? Bodo regulatorji za neskladnost kaznovali?

V naši finančni družbi smo izvedli takšno revizijo. Vodstvo je razvilo revizijski postopek Access Rights Review, da bi najprej pregledalo obstoječe uporabnike in pravice v tistih informacijskih sistemih, ki so bili na seznamu najvišje prioritete. Varnostni oddelek je bil dodeljen kot lastnik tega procesa. Toda za popolno sliko pravic dostopa v podjetju je bilo treba v proces vključiti IT in poslovne oddelke. In tu so se začeli spori, nesporazumi in včasih celo sabotaža: nihče se noče odtrgati od svojih trenutnih obveznosti in se vključiti v nekatere, na prvi pogled, nerazumljive dejavnosti.

Opomba: Velika podjetja z razvitimi IT procesi verjetno poznajo postopek IT revizije – IT general controls (ITGC), ki omogoča odkrivanje pomanjkljivosti v IT procesih in vzpostavitev nadzora za izboljšanje procesov v skladu z najboljšo prakso (ITIL, COBIT, IT). Governance itd.) Takšna revizija omogoča boljše razumevanje IT in podjetja ter razvoj skupne razvojne strategije, analizo tveganj, optimizacijo stroškov in razvoj učinkovitejših pristopov k delu.



Eno od področij presoje je ugotavljanje parametrov logičnega in fizičnega dostopa do informacijskih sistemov. Pridobljene podatke smo vzeli kot osnovo za nadaljnjo uporabo pri gradnji vzornika. Kot rezultat te revizije smo dobili register informacijskih sistemov, v katerem so bili določeni njihovi tehnični parametri in podani opisi. Poleg tega je bil za vsak sistem določen lastnik iz poslovne smeri, v interesu katerega je deloval: on je bil odgovoren za poslovne procese, ki jim je ta sistem služil. Imenovan je bil tudi vodja IT službe, odgovoren za tehnično izvedbo poslovnih potreb posameznega IS. Evidentirani so bili najbolj kritični sistemi za podjetje in njihovi tehnični parametri, roki zagona in razgradnje ... Ti parametri so bili v veliko pomoč pri pripravi na izdelavo vzornika.

3. korak Ustvarite metodologijo

Ključ do uspeha vsakega podjetja je prava metoda. Zato moramo tako za izgradnjo vzornika kot za izvedbo revizije izdelati metodologijo, v kateri opisujemo interakcijo med oddelki, ugotavljamo odgovornost v predpisih podjetja itd.
Najprej morate preučiti vse razpoložljive dokumente, ki določajo postopek za odobritev dostopa in pravic. V dobrem smislu je treba procese dokumentirati na več ravneh:

• splošne zahteve podjetja;
• zahteve za področja informacijske varnosti (odvisno od področij dejavnosti organizacije);
• zahteve za tehnološke procese (navodila, pristopne matrike, smernice, konfiguracijske zahteve).

V naši finančni družbi smo našli veliko zastarelih dokumentov, ki smo jih morali uskladiti z novimi procesi, ki se izvajajo.

Po nalogu vodstva je bila ustanovljena delovna skupina, v kateri so bili predstavniki varnosti, informatike, poslovanja in notranje kontrole. V ukazu so bili navedeni cilji ustanovitve skupine, smer delovanja, čas obstoja in odgovorni z vsake strani. Poleg tega smo razvili revizijsko metodologijo in postopek za izgradnjo vzornika: z njima so se strinjali vsi odgovorni predstavniki področij in potrdilo vodstvo družbe.

Dokumenti, ki opisujejo postopek izvajanja del, roke, odgovornosti itd. - zagotovilo, da na poti do zaželenega cilja, ki sprva ni vsem očiten, nihče ne bo imel vprašanj "zakaj to počnemo, zakaj to potrebujemo itd." in ne bo priložnosti, da bi "skočili" ali upočasnili proces.

Korak 4. Popravite parametre obstoječega modela nadzora dostopa

Izdelujemo tako imenovani »sistemski potni list« v smislu kontrole dostopa. V bistvu je to vprašalnik o določenem informacijskem sistemu, v katerem so zapisani vsi algoritmi za nadzor dostopa do njega. Podjetja, ki že implementirajo rešitve razreda IdM, takšen vprašalnik verjetno poznajo, saj se tu začne proučevanje sistemov.

Nekaj ​​parametrov o sistemu in lastnikih je priteklo v vprašalnik iz registra IT (glej 2. korak, revizija), dodani pa so bili tudi novi:

• kako se vodijo računi (neposredno v bazi ali preko programskih vmesnikov);
• kako se uporabniki prijavijo v sistem (z ločenim računom ali z uporabo računa AD, LDAP itd.);
• katere ravni dostopa do sistema se uporabljajo (aplikacijska raven, sistemska raven, sistemska uporaba omrežnih datotečnih virov);
• opis in parametre strežnikov, na katerih deluje sistem;
• katere operacije upravljanja računa so podprte (blokiranje, preimenovanje itd.);
• kateri algoritmi ali pravila se uporabljajo za generiranje identifikatorja uporabnika sistema;
• s katerim atributom je mogoče vzpostaviti povezavo z evidenco zaposlenega v kadrovskem sistemu (ime in priimek, personalna številka itd.);
• vsi možni atributi računa in pravila za njihovo izpolnjevanje;
• kakšne pravice dostopa obstajajo v sistemu (vloge, skupine, atomske pravice itd., ali obstajajo ugnezdene ali hierarhične pravice);
• mehanizmi delitve pravic dostopa (po položaju, oddelku, funkcionalnosti itd.);
• Ali ima sistem pravila za ločevanje pravic (SOD – Segregation of Duties) in kako delujejo;
• kako se v sistemu obdelujejo dogodki odsotnosti, premestitve, odpovedi, ažuriranje podatkov zaposlenih ipd.

Ta seznam je mogoče nadaljevati s podrobnostmi o različnih parametrih in drugih objektih, ki so vključeni v proces nadzora dostopa.

Korak 5. Ustvarite poslovno usmerjen opis dovoljenj

Drug dokument, ki ga bomo potrebovali pri gradnji vzornika, je priročnik o vseh možnih pooblastilih (pravicah), ki jih lahko uporabniki podelijo v informacijskem sistemu s podrobnim opisom poslovne funkcije, ki za tem stoji. Pogosto so avtoritete v sistemu šifrirane z določenimi imeni, sestavljenimi iz črk in številk, zaposleni v podjetju pa ne morejo ugotoviti, kaj se skriva za temi simboli. Potem gredo v IT službo, tam pa ... tudi ne znajo odgovoriti na vprašanje na primer o redko uporabljenih pravicah. Potem je treba opraviti dodatne teste.

Dobro je, če že obstaja opis podjetja ali celo, če obstaja kombinacija teh pravic v skupine in vloge. Za nekatere aplikacije je najboljša praksa ustvariti takšno referenco v fazi razvoja. A to se ne zgodi pogosto, zato gremo spet na IT oddelek, da zberemo podatke o vseh možnih pravicah in jih opišemo. Naš vodnik bo na koncu vseboval naslednje:

• ime organa, vključno s predmetom, za katerega velja pravica dostopa;
• dejanje, ki ga je dovoljeno izvajati s predmetom (ogled, spreminjanje ipd., možnost omejitve, na primer po teritorialni podlagi ali po skupini strank);
• avtorizacijska koda (koda in ime sistemske funkcije/zahteve, ki se lahko izvede s pomočjo avtorizacije);
• opis pooblastila (podroben opis dejanj v IS pri uporabi pooblastila in njihovih posledic za proces;
• status dovoljenja: »Aktivno« (če je dovoljenje dodeljeno vsaj enemu uporabniku) ali »Ni aktivno« (če dovoljenje ni uporabljeno).

6. korak Iz sistemov prenesemo podatke o uporabnikih in pravicah ter jih primerjamo s kadrovskim virom

Na zadnji stopnji priprave morate iz informacijskih sistemov prenesti podatke o vseh uporabnikih in pravicah, ki jih trenutno imajo. Tukaj sta možna dva scenarija. Prvič: varnostni oddelek ima neposreden dostop do sistema in ima sredstva za prenos ustreznih poročil, kar se ne zgodi pogosto, a je zelo priročno. Drugič: IT-ju pošljemo zahtevo za prejemanje poročil v zahtevani obliki. Izkušnje kažejo, da se z informatiko ni mogoče dogovoriti in pridobiti potrebnih podatkov že prvič. Potrebno je narediti več pristopov, dokler informacije niso prejete v želeni obliki in obliki.

Katere podatke je treba prenesti:

• Ime računa
• Polno ime zaposlenega, ki mu je dodeljen
• Status (aktiven ali blokiran)
• Datum ustvarjanja računa
• Datum zadnje uporabe
• Seznam razpoložljivih pravic/skupin/vlog

Tako smo prejeli prenose iz sistema z vsemi uporabniki in vsemi pravicami, ki so jim bile podeljene. In takoj dajo na stran vse blokirane račune, saj bodo dela na izgradnji vzornika potekala samo za aktivne uporabnike.

Potem, če vaše podjetje nima avtomatiziranih sredstev za blokiranje dostopa odpuščenim zaposlenim (to se pogosto zgodi) ali ima patchwork avtomatizacijo, ki ne deluje vedno pravilno, morate identificirati vse "mrtve duše". Govorimo o računih že odpuščenih delavcev, ki jim pravice iz nekega razloga niso blokirane - jih je treba blokirati. Da bi to naredili, primerjamo naložene podatke z virom osebja. Razklad osebja je treba predhodno pridobiti tudi pri oddelku, ki vzdržuje kadrovsko bazo podatkov.

Ločeno je treba ločiti račune, katerih lastniki niso bili najdeni v zbirki podatkov o osebju, niso bili dodeljeni nikomur - to je brez lastnika. Če uporabimo ta seznam, bomo potrebovali datum zadnje uporabe: če je nov, bomo še vedno morali iskati lastnike. To lahko vključuje račune zunanjih izvajalcev ali storitvene račune, ki niso nikomur dodeljeni, vendar so povezani s kakršnimi koli procesi. Če želite izvedeti, komu pripadajo računi, lahko pošljete pisma vsem oddelkom in jih prosite za odgovor. Ko lastnike najdemo, podatke o njih vnesemo v sistem: tako so identificirani vsi aktivni računi, ostali pa blokirani.

Takoj ko so naša nalaganja očiščena nepotrebnih zapisov in ostanejo samo aktivni računi, lahko začnemo graditi vzor za določen informacijski sistem. Toda o tem vam bom povedal v naslednjem članku.

Avtor: Lyudmila Sevastyanova, vodja promocije Solar inRights

Vir: www.habr.com