Middleware i revizija baze podataka

Dosadašnja izlaganja su detaljno opisala prethodne poslovne procese IT revizije i time se stvorio preduslov za obavaljanje IT revizije baza podataka. U ovom delu izlaganja razmatraćemo reviziju sistema za upravljanje relacionim bazama podataka RDBMS (( RDBMS – Relational Database Management Systems )), u kojim je memorisana (zaključana) sadržina informacija poslovne organizacije. Razmatraće se kako da interni IT revizori priključe procese revizije na sledeće komponente koje direktno utiču na operativnu bezbednost memorisanih podataka.

• Dozvole (prava pristupa) bazama podataka,
• Bezbednost operativnog sistema u funkciji baza podataka,
• Strogost lozinke za pristup bazama podataka i delovi menadžerske odgovornosti,
• Aktivnost monitoringa baza podataka,
• Enkripcija baze podataka u cilju njihove zaštite,
• Ranjivost baze podataka, integritet i procesi “zakrpa” (eng patch),

Trenutni standardi interne revizije, iz dobrog razloga, sada već zahtevaju razmatranje upotrebe analize podataka. Upotreba analize podataka omogućava internim revizorima da vide visok nivo ustrojenih operacija i da dublje urone u same podatke. Pri tome, podaci moraju da budu maksimalno tačni i bezbedni.

Serija predviđenih predavanja ima za cilj da pomogne glavnim rukovodiocima interne revizije – CAE ((CAE – Chief Audit Executive )) u poslovnoj organizaciji da shvate kako da prevaziđu oprobane i istinite metode dosadašnjih ručnih procesa interne revizije prema poboljšanjima koje donosi korišćenje savremene tehnologije analize podataka. Cilj izlaganja je da ukaže internim IT revizorima kako bi mogli da:

• Razumeju zašto je analiza podataka značajna za poslovnu organizaciju.
• Znaju kako da obezbede mnogo efikasniju sigurnost uz korišćenje tehnologije analize podataka.
• Budu upoznati, odnosno familijarni sa izazovima i rizicima sa kojima će se suočiti prilikom sprovođenja analize podataka u odeljenju interne revizije poslovne organizacije.
• Znaju kako da inkorporiraju analizu podataka u poslovnoj organizaciji kroz adekvatno planiranje i odgovarajuće strukture resursa.
• Prepoznaju mogućnosti, trendove i prednosti koristeći tehnologije analize podataka.

Da bi se dalje pomoglo glavnim rukovodiocima interne revizije – CAE i drugim pojedincima u poslovnoj organizaciji, koji će prisustovati predavanjima, na kojima će se takođe uključiti mnogi detalji primene analitike podataka za izvršavanje kontrolnih aktivnosti.  U skladu sa, odnosno konzistentno sa tim gde počinje većina analiza podataka, ovi primeri su uglavnom fokusirani na jednostavano usklađivanje i ponovno izvođenje (reperformance) automatskih funkcionalnosti sistema koji se koriste u pružanju uverenja, odnosno pouzdanosti baza podataka.

Kada se danas u praksi referišemo na pojam baze podataka, termin tipično označava da se referišemo na relacione baze podataka – RDBMS. Istovremeno, mnogi generisani termini baza podataka mogu da se primene na bilo koju kolekciju podataka u bilo kojoj struktuiranoj formi. Na primer, ravan, sekvencijalan fajl sa korisničkim slogovima unutar njega može da posluži kao baza podataka za jednu aplikaciju. Međutim, u ovom izlaganju će se fokus staviti na reviziju punog i detaljng relacionig sistema za upravljanje bazom podataka.

Iako izuzetno važne i lako ranjive, baze podataka su najčešće zanemarivana oblast interne revizije. Tipično, jedna interna IT  revizija uključuje prilično detaljno razmatranje različitih oblasti, uključujući periferiju, operativni sistem, politiku i drugo. Ako vreme omogućava, jedna interna revizija može da pokrije jednu ili dve najkritičnije baze podataka. Oskudno znanje oko interne revizije baza podataka stvara ih pogodnim za zanemarivanje. Baze podataka su kompleksni  “problemi”  koji zahtevaju strpljenje i tehnički „znati kako” “know how” za internu reviziju i podesniju bezbednost.

Međutim, zanemarivanje baze podata je ozbiljna greška. Baza podataka je vitalna zaključana crna kutija informacionog perioda. Postavimo osnovno pitanje: Gde poslovna organizacija vrši memorisanje svojih najvrednijih sredstava? Ne na udaljene periferne jedinice, ne u e-mail sistem i ne u ravnim sekvencijalnim fajlovima. Poslovna organizacija ih po pravilu memoriše u zbirnu relacionu bazu podataka. Kada se u praksi čuju vesti vezane za mnoge bezbedonosne proboje i da su ukradeni osetljivi podaci, opravdano se postavlja pitajte gde ti podaci “žive” kada su napadnuti? Odgovor je jasan, u relacionoj bazi podataka.

Figurativno rečeno, može se smatrati da je baza podataka ”blažena” jer je relativno retko izložena direktnim tipovima napada zato što su po pravilu, web server, firewall ((firewall – zaštitni zid, (u prevodu vatreni zid, vatrobran) je hardver ili softver koji u sklopu računarske mreže ima mogućnost da spreči nepropisni ili neželjeni prenos podataka preko mreže koji je zabranjen od strane sigurnosne politike postavljene na mreži. Zaštitni zid ima zadatak da kontroliše (dozvoljava ili odbija) protok podataka između različitih zona u računarskoj mreži. Zone se dele na osnovu količine poverenja u bezbednost nekog dela mreže. Obično se zona Interneta smatra nesigurnom, dok se lokalna mreža smatra relativno sigurnom. Najbitniji cilj je ostvarivanje normalnog odnosa između ove dve zone, tako da jedna ne naškodi drugoj. Najčešće, zaštitni zid se brine da sa globalne mreže — Interneta — na računar ne dospe štetni kod (virus, crv itd). Zaštitni zid sprečava viruse da dospeju na računar, ali ih ne leči, odnosno ne uklanja. Pošto u našem jeziku ne postoji termin za ovaj pojam, u daljem tekstu će se koristiti engleski termin – firewall. Izvor Wikipedia)) i drugi sistemi odbrane memorisanja suočavaju sa tim problemima. Baze podataka bi trebalo da su i skoro uvek duboko zavučene i daleko iza firewall-a. Mnoge poslovne oprganizacije su dosta prepredene pa znaju da ne stavljaju svoje najvrednije podatake dostupne izlasku u nebezbednu javnu mrežu – Internet. Po pravilu, naravno, poslovne oprganizacije nisu uzele u razmatranje da napadi, takvi kao što su SQL ((SQL – Structured Querry Language, je programski jezik namenjen za upravljanje podacima u relacionim sistemima za upravljanje bazama podataka. Obuhvata unos podataka, upite, ažuriranje i brisanje, šeme kreiranja i menjanja, kao i podatke za kontrolu pristupa. SQL je najviše korišćen programski jezik za baze podataka. SQL je postao standard Američkog nacionalnog instituta za standarde (ANSI) u 1986. god., kao i Međunarodne organizacije za standarde (ISO) u 1987. god. Od tada standard je poboljšan nekoliko puta sa dodatim funkcijama. Izvor Wikipedia)) ubacivanja, lako mogu da naprave svoj put kroz firewall i da izvrše napad na samu bazu podataka.

Baze podataka se figurativno mogu smatrati ”ukletim” zbog nekih ekzaktnih razloga. Zato što su baze podataka toliko daleke iza firewall-a, bezbednost i interna revizija baza podataka poslovne organizacija se razmatra kao naknadna misao, a ponekad bi se to uradilo ako bi interni revizori imali posebno vreme i možda samo u jednoj ili dve kritične baze podataka. To dovodi internu reviziju u situaciju u kojoj je bezbednost baza podataka tipično ostavljena u jadnim uslovima. U praksi, tipični adminstrator baza podataka najčešće zaista veruje da je baza podataka potpuno sigurna, pošto se nalazi dosta daleko iza zaštitite firewall-a tako da može da se desi da adminstratori baza podataka nemaju primenjenu čak ni rudimentarnu bezbedonosnu meru.

Dobra periferija za memorisanje podataka može da služi kao dovoljna zaštita za baze podataka u savršenom svetu. Nepovoljno je to što mi ne živimo u savršenom svetu i zaštita putem firewall-a nije uvek validna “zadnja linija odbrane”. Fokus se sada pomerio na zaštitu prava podataka gde su oni smešteni, kao i prava pristupa u bazu podataka. U svom radu jedan interni revizor će, verovatno, najčešće da nađe da je baza podataka slabo povezana u bezbedonosni lanac poslovne organizacije. To je bitno za internog revizora zato što nekoliko relativno jednostavnih preporuka može da kreira široko poboljšanje u bezbednosti baza podataka.

Ako interni revizori žele da budu sposobni da efikasno vrše procese revizije baze podataka, oni bi trebalo da poseduju osnovno znanje o tome kako baza podataka radi. Ovom serijom predavanja pokriće se širok skup komponenti koje bi interni revizori trebalo da razumeju, da bi podesno obavili procese revizije baze podataka.

Ako bi napravili kratku retrospektivu posmatrajući razvoj baza podataka, u ranim 90-tim godinama prošlog veka, aplikacije su pisane korišćenjem klijent server modela. To se sastojalo od desktop programa konektovanih preko mreže direktno na krajnju podršku bazi podataka. To nas referiše na na takozvane dvoslojne aplikacije.

U kasnim 90-tim godinama prošlog veka troslojne aplikacije postaju norma, odnosno standardni način rada. Ovaj novi model se sastoji od web browser-a, pretraživača priključenog na srednji sloj web aplikacija. Srednji sloj se tada konektuje na krajnju podršku bazi podataka. Pojava troslojnih aplikacija je veliki korak napred. Naručeni softver nije potreban na svakoj klijentskoj stanici. Ažuriranje softvera je potrebno primeniti samo na centralnom serveru. Klijenti mogu da izvode bilo koji operativni sistem koji podržava osnovni pretraživač browser. Osim toga, u toslojnom modelu, mnogo je jednostavnije osigurati bezbednost baza podataka.

Naravno, zahteva se da infrastruktura baza podataka još uvek podržava i dvoslojne aplikakacije koje još uvek postoje kao način rada sa bazama podataka pored standardizovanih troslojnih aplikacija. Posebno je potrebno istaći da u takvim situacijama, sada postoji dodatna opasnost da će jedan maliciozni napadač pokušati da zaobiđe web aplikacije i da napadne krajnju podršku bazi podataka.

Danas u svetu postoje mnogi proizvođači softverskih rešenja za upravljanje bazama podataka, a kao ilustrativan primer navodimo samo neke od njih, To su:

• Oracle,
• IBM – DB2,
• MYSQL,
• Sybase – SAP
• Microsoft – MS SQL

Komponente baze podataka 

Svaki prodavac baza podataka ima neznatno različitu implementaciju raznovrsnih komponenti baze podataka. Međutim, teorija i principi primene na sve različite platforme su prilično univerzalne. U nastavku izlaganja obradiće se samo elementarne osnove  dajući potrebne poglede na ovu problematiku. Iz toga bi interni revizori trebalo da dobiju elementarna saznanja sa kojima bi mogli lakše da prate tehničke priručnike za specifične platforme baza podataka. Niže su dati glavni delovi baze podataka koju bi interni revizori trebalo da razumeju iz revizorske perspektive.

Programski fajl

Baza podataka se implementira kao softverski sistem i kao takav, on je napravljen kao posebno jezgro, odnosno skup operativnih sistemskih fajlova. Ovi fajlovi uključuju izvršne (exe) fajlove koje će izvoditi sistem za upravljanje bazom podataka. On takođe može da sadrži druge ne izvršne programske fajlove, kao što su help fajl, izvorni (source) fajlovi, fajlovi za uključivanje, instalacioni fajlovi itd.

Fajl konfiguracionih vrednosti

Baza podataka se oslanja mnogo na konfiguraciono podešavanje da bi se odredilo kako sam sistem funkcioniše. Zaštita ovog podešavanja je važan element prilaza internih revizora zato što se sa konfiguracijom može manipulisati, a samim tim može da bude podrivena bezbednost informacija poslovne organizacije.

Fajlovi podataka

Baza podataka bi trebalo da memoriše sve poslovne podatke koje drži u fizičkim operativnim sistemskim fajlovima. Tipično, to uključuje seriju fajlova. Pri tom format fajla mora da bude podesan a fajl podataka, između ostalog može da sadrži i sledeće podatke:

• Pointere, odnosno pokazivače sa jednog polja do sledećeg polja ili od jednog reda ka sledećem redu,
• Indeks podataka, uključujući pointere od indeksa do fizičkog podatka.

Važnost SQL iskaza

Jezik za struktuirane upite – SQL i njegov iskaz se koristi da se “izvade“ potrebni podaci iz baze podatraka. SQL je izgrađen oko četiri osnovna iskaza kao što je to ilustravano u tabeli niže u tekstu. Sa svojim velikim mogućnostima i lakoćom rada, primena SQL naredbi iz komandne linije operativnog sistema, ako se neautorizovano izvršava, može da podrije bezbednist informacionog sistema pa zato zahteva posebnu pažnju i analizu internih revizora.

Kontrolna lista provere “checklist“ ima 19 osnovih tačaka za razmatranje kojima bi trebalo da se bavi interni IT revizor. Po potrebi,  kontrolna lista provere može i treba da se proširi sa dopunskim elementima.

U daljem izlaganju izložićemo nastavak oblasti i dalje postupke u kojima deluje interna IT revizija.

• Revizija aplikacija
• Revizija kompanijskih projekata
• Okvir i standardi
• Forenzičko računovodstvo
• Forenzička IT revizija