Trenutačno radim za dobavljača softvera, konkretno rješenja za kontrolu pristupa. A moje iskustvo "iz prošlog života" povezano je sa stranom kupca - velikom financijskom organizacijom. Tada se naša grupa za kontrolu pristupa u odjelu informacijske sigurnosti nije mogla pohvaliti velikim kompetencijama u IdM-u. Puno smo naučili u procesu, morali smo naići na puno trzavica kako bismo izgradili radni mehanizam za upravljanje korisničkim pravima u informacijskim sustavima u tvrtki.
Kombinirajući svoje teško stečeno korisničko iskustvo sa znanjem i kompetencijama dobavljača, želim s vama podijeliti upute korak po korak: kako stvoriti model kontrole pristupa temeljen na ulogama u velikoj tvrtki i što će to dati kao rezultat . Moje upute se sastoje od dva dijela: prvi je priprema za izradu modela, drugi je zapravo izgradnja. Evo prvog dijela, pripremnog.
NB Izgradnja uzora, nažalost, nije rezultat, već proces. Ili bolje rečeno, čak dio procesa stvaranja ekosustava kontrole pristupa u tvrtki. Zato se dugo pripremajte za igru.
Prvo, definirajmo to - što je kontrola pristupa temeljena na ulogama? Pretpostavimo da imate veliku banku s desecima, pa čak i stotinama tisuća zaposlenika (entiteta), od kojih svaki ima desetke prava pristupa stotinama internih bankovnih informacijskih sustava (objekata). Sada pomnožite broj objekata s brojem subjekata - ovo je minimalni broj veza koje morate prvo izgraditi, a zatim kontrolirati. Je li to stvarno moguće učiniti ručno? Naravno da ne - uloge su stvorene da riješe ovaj problem.
Uloga je skup dozvola koje su korisniku ili grupi korisnika potrebne za obavljanje određenih radnih zadataka. Svaki zaposlenik može imati jednu ili više uloga, a svaka uloga može sadržavati od jedne do više dozvola koje su dopuštene korisniku unutar te uloge. Uloge se mogu vezati uz određene pozicije, odjele ili funkcionalne zadatke zaposlenika.
Uloge se obično kreiraju iz pojedinačnih ovlaštenja zaposlenika u svakom informacijskom sustavu. Zatim se iz uloga svakog sustava formiraju globalne poslovne uloge. Na primjer, poslovna uloga "kreditni menadžer" će uključivati nekoliko zasebnih uloga u informacijskim sustavima koji se koriste u uredu za klijente banke. Na primjer, u glavnom automatiziranom bankarskom sustavu, gotovinskom modulu, elektroničkom sustavu upravljanja dokumentima, upravitelju usluga i drugima. Poslovne uloge u pravilu su vezane uz organizacijsku strukturu – drugim riječima, uz skup odjela poduzeća i pozicija u njima. Ovako se formira globalna matrica uloga (dajem primjer u tablici ispod).
Vrijedno je napomenuti da je jednostavno nemoguće izgraditi 100% uzor, pružajući sva potrebna prava zaposlenicima na svakom radnom mjestu u komercijalnoj strukturi. Da, ovo nije potrebno. Uostalom, uzor ne može biti statičan, jer ovisi o okruženju koje se stalno mijenja. I od promjena u poslovanju društva, što shodno tome utječe na promjene u organizacijskoj strukturi i funkcionalnosti. I od nedovoljne opskrbljenosti resursima, i od nepoštivanja opisa poslova, i od želje za profitom na uštrb sigurnosti, i od mnogih drugih čimbenika. Stoga je potrebno izgraditi uzor koji može pokriti do 80% potreba korisnika za potrebnim osnovnim pravima pri dodijeli na radno mjesto. A preostalih 20% mogu po potrebi zatražiti naknadno na posebnim zahtjevima.
Naravno, možete pitati: "Zar ne postoje 100% uzori?" Pa, zašto, to se događa, na primjer, u neprofitnim strukturama koje nisu podložne čestim promjenama - u nekom istraživačkom institutu. Ili u organizacijama vojno-industrijskog kompleksa s visokom razinom sigurnosti, gdje je sigurnost na prvom mjestu. To se događa u komercijalnoj strukturi, ali u okviru zasebnog odjela, čiji je rad prilično statičan i predvidljiv proces.
Glavna prednost upravljanja temeljenog na ulogama je pojednostavljenje izdavanja prava jer je broj uloga znatno manji od broja korisnika informacijskog sustava. I to vrijedi za bilo koju industriju.
Uzmimo maloprodajnu tvrtku: ona zapošljava tisuće prodavača, ali oni imaju isti skup prava u sustavu N i za njih će biti stvorena samo jedna uloga. Dolaskom novog prodavača u tvrtku automatski mu se dodjeljuje tražena uloga u sustavu koji već ima sve potrebne ovlasti. Također, jednim klikom možete promijeniti prava za tisuće prodavača odjednom, na primjer, dodati novu opciju za generiranje izvješća. Nema potrebe za tisuću operacija, povezivanjem novog prava sa svakim računom - samo dodajte ovu opciju ulozi, i ona će se pojaviti za sve prodavače u isto vrijeme.
Još jedna prednost upravljanja temeljenog na ulogama je eliminacija izdavanja nekompatibilnih ovlaštenja. Odnosno, zaposlenik koji ima određenu ulogu u sustavu ne može istovremeno imati drugu ulogu čija prava ne bi trebala biti spojena s pravima iz prve. Upečatljiv primjer je zabrana kombiniranja funkcija unosa i kontrole financijske transakcije.
Svatko koga zanima kako je nastala kontrola pristupa temeljena na ulogama može
uroniti u povijest
Gledamo li u povijest, informatička zajednica prvi put je razmišljala o metodama kontrole pristupa još 70-ih godina XNUMX. stoljeća. Iako su tada aplikacije bile vrlo jednostavne, baš kao i sada, svi su željeli jednostavno upravljati pristupom njima. Dodjeljujte, mijenjajte i kontrolirajte korisnička prava - samo da biste lakše razumjeli koji pristup ima svaki od njih. Ali u to vrijeme nije bilo zajedničkih standarda, razvijali su se prvi sustavi kontrole pristupa, a svaka tvrtka se temeljila na svojim idejama i pravilima.
Sada je poznato mnogo različitih modela kontrole pristupa, ali se nisu pojavili odmah. Zadržimo se na onima koji su dali značajan doprinos razvoju ovog kraja.
Prvi i vjerojatno najjednostavniji model je Diskrecijska (selektivna) kontrola pristupa (DAC – Diskrecijska kontrola pristupa). Ovaj model podrazumijeva dijeljenje prava svih sudionika u procesu pristupa. Svaki korisnik ima pristup određenim objektima ili operacijama. U biti, ovdje skupu subjekata prava odgovara skup objekata. Utvrđeno je da je ovaj model previše fleksibilan i pretežak za održavanje: popisi pristupa s vremenom postaju ogromni i teško ih je kontrolirati.
Drugi model je Obvezna kontrola pristupa (MAC - Mandatory access control). Prema ovom modelu, svaki korisnik dobiva pristup objektu u skladu s izdanim pristupom određenoj razini povjerljivosti podataka. U skladu s tim, objekte treba kategorizirati prema njihovoj razini povjerljivosti. Za razliku od prvog fleksibilnog modela, ovaj se, naprotiv, pokazao prestrogim i restriktivnim. Njegova upotreba nije opravdana kada tvrtka ima mnogo različitih izvora informacija: kako biste razlikovali pristup različitim resursima, morat ćete uvesti mnoge kategorije koje se neće preklapati.
Zbog očitih nesavršenosti ovih dviju metoda, IT zajednica je nastavila razvijati modele koji su fleksibilniji, au isto vrijeme više ili manje univerzalni za podršku različitim vrstama organizacijskih politika kontrole pristupa. A onda se pojavilo treći model kontrole pristupa temeljen na ulogama! Ovaj pristup pokazao se kao najperspektivniji jer zahtijeva ne samo autorizaciju identiteta korisnika, već i njegove operativne funkcije u sustavima.
Prvu jasno opisanu strukturu uzora predložili su američki znanstvenici David Ferrailo i Richard Kuhn s američkog Nacionalnog instituta za standarde i tehnologiju 1992. godine. Tada se termin prvi put pojavio RBAC (Kontrola pristupa temeljena na ulogama). Ove studije i opisi glavnih komponenti, kao i njihovih odnosa, činili su osnovu standarda INCITS 359-2012, koji je još uvijek na snazi i danas, a odobrio ga je Međunarodni odbor za standarde informacijske tehnologije (INCITS).
Standard definira ulogu kao "poslovnu funkciju u kontekstu organizacije s određenom povezanom semantikom u vezi s ovlastima i odgovornostima dodijeljenima korisniku dodijeljenom ulozi." Dokument utvrđuje osnovne elemente RBAC-a - korisnike, sesije, uloge, dopuštenja, operacije i objekte, kao i odnose i međusobne veze između njih.
Standard pruža minimalnu potrebnu strukturu za izgradnju uzora - kombiniranje prava u uloge i zatim odobravanje pristupa korisnicima kroz te uloge. Ocrtani su mehanizmi sastavljanja uloga od objekata i operacija, opisana je hijerarhija uloga i nasljeđivanje ovlasti. Uostalom, u svakoj tvrtki postoje uloge koje objedinjuju osnovne ovlasti koje su potrebne svim zaposlenicima tvrtke. To može biti pristup e-pošti, EDMS-u, korporativnom portalu itd. Ova dopuštenja mogu se uključiti u jednu opću ulogu koja se zove "zaposlenik", i neće biti potrebe stalno iznova navoditi sva osnovna prava u svakoj od uloga više razine. Dovoljno je samo naznačiti karakteristiku nasljeđivanja uloge “zaposlenika”.
Kasnije je standard nadopunjen novim atributima pristupa koji se odnose na okruženje koje se stalno mijenja. Dodana je mogućnost uvođenja statičkih i dinamičkih ograničenja. Statički podrazumijevaju nemogućnost kombiniranja uloga (isti unos i kontrola operacija spomenutih gore). Dinamička ograničenja mogu se odrediti promjenom parametara, na primjer, vremena (radni/neradni sati ili dani), lokacije (ured/kuća) itd.
Zasebno, treba reći o kontrola pristupa temeljena na atributima (ABAC - Attribute-based access control). Pristup se temelji na odobravanju pristupa korištenjem pravila dijeljenja atributa. Ovaj se model može koristiti zasebno, ali vrlo često aktivno nadopunjuje klasični uzor: atributi korisnika, resursa i uređaja, kao i vrijeme ili lokacija, mogu se dodati određenoj ulozi. To vam omogućuje da koristite manje uloga, uvedete dodatna ograničenja i smanjite pristup što je više moguće, a time i poboljšate sigurnost.
Na primjer, računovođi se može dopustiti pristup računima ako radi u određenoj regiji. Tada će se lokacija stručnjaka usporediti s određenom referentnom vrijednošću. Ili možete dati pristup računima samo ako se korisnik prijavi s uređaja koji je na popisu dopuštenih. Dobar dodatak uzoru, ali se rijetko koristi samostalno zbog potrebe za stvaranjem mnogih pravila i tablica dopuštenja ili ograničenja.
Dat ću vam primjer korištenja ABAC-a iz mog "prošlog života". Naša banka je imala nekoliko poslovnica. Zaposlenici ureda za klijente u tim podružnicama obavljali su potpuno iste operacije, ali su morali raditi u glavnom sustavu samo s računima u svojoj regiji. Prvo smo počeli stvarati zasebne uloge za svaku regiju - a bilo je toliko takvih uloga s ponavljajućim funkcijama, ali s pristupom različitim računima! Zatim smo korištenjem atributa lokacije za korisnika i njegovim povezivanjem s određenim rasponom računa za pregled značajno smanjili broj uloga u sustavu. Kao rezultat toga, uloge su ostale za samo jednu podružnicu, koje su replicirane za odgovarajuće pozicije u svim drugim teritorijalnim odjelima banke.
Sada razgovarajmo o potrebnim pripremnim koracima, bez kojih je jednostavno nemoguće izgraditi radni uzor.
Korak 1. Izradite funkcionalni model
Trebali biste početi s izradom funkcionalnog modela - dokumenta najviše razine koji detaljno opisuje funkcionalnost svakog odjela i svakog radnog mjesta. Podaci u nju u pravilu ulaze iz različitih dokumenata: opisa poslova i pravilnika za pojedine jedinice – odjele, odsjeke, odjele. Funkcionalni model mora biti usuglašen sa svim zainteresiranim odjelima (poslovni, interna kontrola, sigurnost) i odobren od strane uprave poduzeća. Čemu služi ovaj dokument? Kako bi se uzor mogao pozvati na to. Na primjer, gradit ćete uzor temeljen na postojećim pravima zaposlenika – rasterećenim od sustava i “svedenim na zajednički nazivnik”. Zatim, kada se dogovorite o primljenim ulogama s poslovnim vlasnikom sustava, možete se pozvati na određenu točku u funkcionalnom modelu, na temelju koje je ovo ili ono pravo uključeno u ulogu.
Korak 2. Provjeravamo IT sustave i izrađujemo plan prioriteta
U drugoj fazi trebali biste provesti reviziju IT sustava kako biste razumjeli kako je organiziran pristup njima. Na primjer, moja financijska tvrtka upravljala je s nekoliko stotina informacijskih sustava. Svi sustavi su imali neke rudimente upravljanja temeljenog na ulogama, većina je imala neke uloge, ali uglavnom na papiru ili u direktoriju sustava - bili su davno zastarjeli, a pristup im se odobravao na temelju stvarnih zahtjeva korisnika. Naravno, jednostavno je nemoguće izgraditi uzor u nekoliko stotina sustava odjednom, morate negdje početi. Proveli smo dubinsku analizu procesa kontrole pristupa kako bismo odredili njegovu razinu zrelosti. Tijekom procesa analize razvijeni su kriteriji za prioritizaciju informacijskih sustava - kritičnost, spremnost, planovi razgradnje itd. Uz njihovu pomoć zacrtali smo razvoj/ažuriranje uzora za te sustave. Zatim smo uključili uzore u plan za integraciju s rješenjem za upravljanje identitetom za automatizaciju kontrole pristupa.
Dakle, kako odrediti kritičnost sustava? Odgovorite sebi na sljedeća pitanja:
- Je li sustav povezan s operativnim procesima o kojima ovisi temeljna djelatnost tvrtke?
- Hoće li poremećaj sustava utjecati na integritet imovine tvrtke?
- Koje je maksimalno dopušteno vrijeme zastoja sustava, nakon kojeg je nemoguće vratiti aktivnost nakon prekida?
- Može li povreda integriteta informacija u sustavu dovesti do nepovratnih posljedica, kako financijskih tako i reputacijskih?
- Kritičnost prema prijevari. Prisutnost funkcionalnosti, ako nije ispravno kontrolirana, može dovesti do unutarnjih/vanjskih prijevarnih radnji;
- Koji su pravni zahtjevi i interna pravila i procedure za te sustave? Hoće li regulatori biti kažnjeni za neusklađenost?
U našoj financijskoj tvrtki napravili smo ovakvu reviziju. Uprava je razvila proceduru revizije Access Rights Review kako bi prvo pogledala postojeće korisnike i prava u onim informacijskim sustavima koji su bili na listi najvišeg prioriteta. Odjel sigurnosti dodijeljen je kao vlasnik ovog procesa. No, da bismo dobili potpunu sliku prava pristupa u tvrtki, u proces je bilo potrebno uključiti IT i poslovne odjele. I tu su počeli sporovi, nesporazumi, a ponekad i sabotaže: nitko se ne želi otrgnuti od trenutnih obaveza i upustiti se u neke, na prvi pogled, neshvatljive poslove.
NB Velike tvrtke s razvijenim informatičkim procesima vjerojatno poznaju proceduru IT revizije - IT general controls (ITGC), koja vam omogućuje da identificirate nedostatke u IT procesima i uspostavite kontrolu kako bi se procesi poboljšali u skladu s najboljom praksom (ITIL, COBIT, IT Upravljanje i sl.) Takva revizija omogućuje IT-u i poslovanju da se bolje razumiju i razviju zajedničku strategiju razvoja, analiziraju rizike, optimiziraju troškove i razviju učinkovitije pristupe radu.
Jedno od područja revizije je utvrđivanje parametara logičkog i fizičkog pristupa informacijskim sustavima. Dobivene podatke uzeli smo kao osnovu za daljnje korištenje u izgradnji uzora. Kao rezultat ove revizije dobili smo registar IT sustava u kojem su utvrđeni njihovi tehnički parametri i dani opisi. Osim toga, za svaki sustav identificiran je vlasnik iz poslovnog smjera u čijem je interesu djelovao: on je bio odgovoran za poslovne procese koje je ovaj sustav opsluživao. Također je imenovan voditelj informatičke službe zadužen za tehničku provedbu poslovnih potreba za pojedini IS. Snimljeni su najkritičniji sustavi za tvrtku i njihovi tehnički parametri, rokovi puštanja u pogon i dekomisioniranja itd. Ti su parametri bili od velike pomoći u procesu pripreme za izradu uzora.
Korak 3 Izradite metodologiju
Ključ uspjeha svakog posla je prava metoda. Stoga, kako za izgradnju uzora, tako i za provođenje revizije, moramo izraditi metodologiju u kojoj opisujemo interakciju između odjela, utvrđujemo odgovornost u regulativi tvrtke itd.
Prvo morate ispitati sve dostupne dokumente koji utvrđuju postupak za odobravanje pristupa i prava. Na dobar način, procesi bi trebali biti dokumentirani na nekoliko razina:
- opći korporativni zahtjevi;
- zahtjevi za područja informacijske sigurnosti (ovisno o područjima aktivnosti organizacije);
- zahtjevi za tehnološke procese (upute, pristupne matrice, smjernice, konfiguracijski zahtjevi).
U našoj financijskoj tvrtki pronašli smo puno zastarjelih dokumenata, morali smo ih uskladiti s novim procesima koji se provode.
Po nalogu uprave formirana je radna skupina u koju su uključeni predstavnici sigurnosti, informatike, poslovanja i interne kontrole. U nalogu su navedeni ciljevi stvaranja grupe, smjer djelovanja, razdoblje postojanja i odgovorni sa svake strane. Osim toga, razvili smo metodologiju revizije i proceduru za konstruiranje uzora: s njima su se složili svi odgovorni predstavnici područja i odobrila uprava tvrtke.
Dokumenti koji opisuju postupak obavljanja poslova, rokove, odgovornosti i sl. - jamstvo da na putu do željenog cilja, koji u početku nije svima očit, nitko neće imati pitanja "zašto to radimo, zašto nam je to potrebno itd." i neće biti prilike za "iskakanje" ili usporavanje procesa.
Korak 4. Popravite parametre postojećeg modela kontrole pristupa
Izrađujemo takozvanu „putovnicu sustava“ u smislu kontrole pristupa. U biti, radi se o upitniku o određenom informacijskom sustavu, koji bilježi sve algoritme za kontrolu pristupa istom. Tvrtke koje su već implementirale IdM-class rješenja vjerojatno poznaju takav upitnik, budući da tu počinje proučavanje sustava.
Neki parametri o sustavu i vlasnicima dospjeli su u upitnik iz IT registra (vidi korak 2, revizija), ali su dodani i novi:
- kako se upravlja računima (izravno u bazi podataka ili putem softverskih sučelja);
- kako se korisnici prijavljuju u sustav (korištenjem zasebnog računa ili korištenjem AD računa, LDAP-a itd.);
- koje se razine pristupa sustavu koriste (razina aplikacije, razina sustava, korištenje sustava resursima mrežnih datoteka);
- opis i parametre poslužitelja na kojima se sustav izvodi;
- koje su operacije upravljanja računom podržane (blokiranje, preimenovanje itd.);
- koji se algoritmi ili pravila koriste za generiranje identifikatora korisnika sustava;
- kojim se atributom može uspostaviti veza s evidencijom zaposlenika u kadrovskom sustavu (ime i prezime, matični broj itd.);
- sve moguće atribute računa i pravila za njihovo ispunjavanje;
- koja prava pristupa postoje u sustavu (uloge, grupe, atomska prava, itd., postoje li ugniježđena ili hijerarhijska prava);
- mehanizmi za podjelu prava pristupa (po poziciji, odjelu, funkcionalnosti itd.);
- Ima li sustav pravila za odvajanje prava (SOD – Segregation of Duties) i kako ona funkcioniraju;
- kako se u sustavu obrađuju događaji odsutnosti, premještaja, otkaza, ažuriranja podataka zaposlenika i sl.
Ovaj popis se može nastaviti s pojedinostima o različitim parametrima i drugim objektima koji su uključeni u proces kontrole pristupa.
Korak 5. Napravite poslovno orijentirani opis dopuštenja
Drugi dokument koji će nam trebati pri izgradnji uzora je priručnik o svim mogućim ovlastima (pravama) koja se mogu dodijeliti korisnicima u informacijskom sustavu s detaljnim opisom poslovne funkcije koja iza toga stoji. Često su autoriteti u sustavu šifrirani određenim nazivima koji se sastoje od slova i brojki, a poslovni zaposlenici ne mogu shvatiti što se krije iza tih simbola. Onda odu u informatičku službu, a tamo... također ne znaju odgovoriti na pitanje, primjerice, o rijetko korištenim pravima. Tada je potrebno napraviti dodatna ispitivanja.
Dobro je ako već postoji opis poslovanja ili čak ako postoji kombinacija ovih prava u grupe i uloge. Za neke je aplikacije najbolja praksa stvoriti takvu referencu u fazi razvoja. Ali to se ne događa često, pa opet idemo u IT odjel prikupiti podatke o svim mogućim pravima i opisati ih. Naš će vodič na kraju sadržavati sljedeće:
- naziv tijela, uključujući objekt na koji se odnosi pravo pristupa;
- radnja koju je dopušteno činiti s predmetom (razgledavanje, mijenjanje i sl., mogućnost ograničenja, npr. po teritorijalnoj osnovi ili po skupini klijenata);
- autorizacijski kod (šifra i naziv funkcije/zahtjeva sustava koji se može izvršiti korištenjem autorizacije);
- opis ovlasti (detaljan opis radnji u IS-u prilikom primjene ovlasti i njihovih posljedica za proces;
- status dopuštenja: “Aktivno” (ako je dopuštenje dodijeljeno barem jednom korisniku) ili “Nije aktivno” (ako se dopuštenje ne koristi).
Korak 6. Preuzimamo podatke o korisnicima i pravima iz sustava i uspoređujemo ih s izvorom osoblja
U završnoj fazi pripreme potrebno je preuzeti podatke iz informacijskih sustava o svim korisnicima i pravima koja trenutno imaju. Ovdje su moguća dva scenarija. Prvo: sigurnosni odjel ima izravan pristup sustavu i ima sredstva za preuzimanje relevantnih izvješća, što se ne događa često, ali je vrlo zgodno. Drugo: IT-ju šaljemo zahtjev za primanje izvješća u potrebnom formatu. Iskustvo pokazuje da se s IT-om nije moguće dogovoriti i dobiti potrebne podatke iz prvog puta. Potrebno je napraviti nekoliko pristupa dok se informacija ne dobije u željenom obliku i obliku.
Koje podatke je potrebno preuzeti:
- Korisničko ime
- Puno ime zaposlenika kojem je dodijeljen
- Status (aktivno ili blokirano)
- Datum kreiranja računa
- Datum zadnje upotrebe
- Popis dostupnih prava/grupa/uloga
Dakle, dobili smo preuzimanja sa sustava sa svim korisnicima i svim pravima koja su im dodijeljena. I odmah stavljaju po strani sve blokirane račune, jer će se raditi na izgradnji uzora samo za aktivne korisnike.
Zatim, ako vaša tvrtka nema automatizirana sredstva za blokiranje pristupa otpuštenim zaposlenicima (to se često događa) ili ima patchwork automatizaciju koja ne radi uvijek ispravno, trebate identificirati sve "mrtve duše". Riječ je o računima zaposlenika koji su već dobili otkaz, a čija prava iz nekog razloga nisu blokirana – treba ih blokirati. Da bismo to učinili, uspoređujemo učitane podatke s izvorom osoblja. Iskrcaj osoblja također se mora unaprijed dobiti od odjela koji održava bazu podataka o osoblju.
Zasebno je potrebno izdvojiti račune čiji vlasnici nisu pronađeni u bazi podataka o osoblju, nisu dodijeljeni nikome - to jest, bez vlasnika. Koristeći ovaj popis, trebat će nam datum zadnje upotrebe: ako je sasvim novi, još ćemo morati potražiti vlasnike. To može uključivati račune vanjskih izvođača ili račune usluga koji nisu nikome dodijeljeni, ali su povezani s bilo kojim procesima. Kako biste saznali čiji računi pripadaju, možete poslati pisma svim odjelima tražeći od njih da odgovore. Kada se vlasnici pronađu, podatke o njima unosimo u sustav: na taj način se identificiraju svi aktivni računi, a ostali se blokiraju.
Čim se naši prijenosi očiste od nepotrebnih zapisa i ostanu samo aktivni računi, možemo početi graditi uzor za određeni informacijski sustav. Ali o tome ću vam reći u sljedećem članku.
Autor: Lyudmila Sevastyanova, voditeljica promocije Solar inRights
Izvor: www.habr.com