TFL Vsebine / TFLGlasnik

1. UVOD

Podatki oz. iz njih izpeljane informacije so nedvomno največje bogastvo vsakega podjetja oz. organizacije. Pri tem so podatki v današnjem poslovnem okolju zelo heterogeni – različno organizirani, v različnih oblikah, na različnih medijih. Ne glede na organizacijo podatkov pa v informacijskem sistemu podjetja praviloma obstaja osrednja podatkovna zbirka. Ta deluje kot nekakšen motor oz. srce celotnega IS, okoli katerega je IS oblikovan za kar najboljšo podporo delovanju poslovnih funkcij.

Zato seveda ne preseneča, da je podatkovna zbirka vključena v praktično vsako revizijo IS. Pri tem gre lahko za revizijo upravljanja podatkov na splošnejši ravni, kot npr. pregled ustreznosti klasifikacije podatkov, upravljanje osebnih podatkov, splošna usklajenost ravnanja s podatki z internimi pravili, pravilniki in politikami idr. Lahko pa tudi za zelo tehnične rešitve, npr. za revizijo zmogljivosti, odzivnosti in pripadajočih nastavitev na konkretnih podatkovnih bazah. Največkrat gre za oboje, revizijski načrt pa je tako odvisen od revizijskih ciljev in tveganj, ki so predmet revizije. Članek zato ni poskus sestave revizijskega načrta za pregled sistema za upravljanje podatkovne baze, ampak skušamo opredeliti nekaj posebnosti podatkovnih baz, ki jih revizor IS lahko vključi v revizijski načrt.

2. VARNOST

2.1. Uporabniške pravice

Kadar se lotimo revizije podatkovne baze, je skoraj vedno treba preveriti varnostne nastavitve podatkovne baze. Prva oz. osnovna aktivnost je preverjanje uporabniških pravic oz. pristojnosti. Pregled je sestavljen predvsem iz poizvedb na podatkovni bazi. Znano je, v katerih tabelah in nastavitvah (tudi strežniških) so za posamezne podatkovne baze te pravice zapisane, zato so poizvedbe lahko pripravljene in izvedene vnaprej oziroma se pri »terenskem« pregledu pravice lahko hitro preverijo. Pomembno je, da tu ne gre le za osnovne pravice branja in sprememb podatkov, ampak so pomembne tudi pravice kreiranja objektov, pravice za poimenovanje, uporabo prostora idr., pravzaprav vse pravice privilegiranih dostopov do podatkovne baze. Še posebej poudarjamo pravice različnih množičnih obdelav podatkov (uvozi, izvozi, varnostno kopiranje idr.). Ključna revizorjeva aktivnost je pregled pripadajočih zahtevkov za dodelitev pravic, ukinjanje dostopov po odhodu iz podjetja ipd., s čimer navsezadnje zagotavljamo skladnost informacijske podpore z delovanjem poslovnih funkcij.

Posebna pozornost revizorja IS velja uporabniškim imenom, ki se praviloma ne prijavljajo prek delovnih postaj – tj. s servisnim oz. aplikacijskim uporabniškim računom. Gre za uporabniške račune z visokimi pooblastili, ki se v praksi uporabljajo v različne namene, seveda tudi take, ki niso nujno v skladu z internimi pravili, dobrimi praksami in informacijskimi standardi. Poleg tega gre praviloma za neimenske uporabniške račune, tako da je treba uporabo temeljito preveriti in pridobiti dokazno gradivo, predvsem ustrezne revizijske sledi. Pri pregledu je treba upoštevati tudi nekaj posebnosti podatkovnih baz. Tako se npr. V aplikacijskih okoljih Oraclovih podatkovnih baz pogosto pojavljajo uporabniki – lastniki podatkovnih shem tudi kot aplikacijski uporabniki, ki jih uporabljajo razni programerji. Poleg tega Oracle praviloma uporablja svojo shemo uporabnikov in prijavni postopek znotraj baze, medtem ko je pri drugih bazah prijavni postopek vključen v aktivni imenik oz. prijavne protokole LDAP¹. Po drugi strani imajo uporabniki podatkovne baze DB2 tudi določene pravice nad podatki, ki niso neposredno razvidne iz pravic nad tabelami, ampak vključene v pravico do uporabe določenih programov.

Podatkovne baze omogočajo tudi ločevanje pristojnosti na najvišji ravni upravljanja, tako da privilegiran uporabnik z »vsemi« pravicami (ang.sysadmin, sysadm …) nima pristojnosti podeljevanja pravic, po drugi strani pa varnostni upravitelj (angl.security admin) nima vpogleda v podatke. Revizor IS je seveda dolžan preveriti uporabo teh uporabniških imen, če interna pravila to zahtevajo.

2.2. Šifriranje

Pomemben mehanizem varnosti podatkovnih baz je šifriranje. Za preprečevanje razkritja podatkov z vdori in krajo diskovnih datotek baze je potrebno kompletno šifriranje podatkovne baze. Mehanizmi so že dovolj izpopolnjeni, da ni potrebno posebno preverjanje, pomembno pa je, da so bila izvedena ustrezna (predvsem performančna) testiranja delovanja šifrirane podatkovne baze. Revizor IS mora pri šifriranju preveriti ravnanje s ključi – postopke kreiranja, prenosov, sprememb oz. zamenjave in uničenja. Preveriti je treba, kako so ključi zaščiteni v vseh postopkih delovanja, še posebno ker gre praviloma za vsaj dva ključa, postopke pa dodatno otežujejo še visokorazpoložljivostna (HA)² okolja, v katerih morajo biti poleg tega pripravljeni postopki prenosa na druge kopije/lokacije baze.

Revizor IS mora preveriti tudi šifriranje prometa oz. prenosa podatkov na relaciji aplikacija <=> podatkovna baza oz. uporabnik <=> podatkovna baza. Pri tem v praksi naletimo celo na nešifrirana prijavna gesla, češ kaj pa se nam lahko v notranjem omrežju zgodi. Revizorji IS seveda poznamo tveganja tudi v notranjem omrežju, tako da poleg šifriranja gesel preverjamo še šifriranje prometa podatkov v skladu z internimi akti.

2.3. Revizijske sledi

Revizijske sledi delovanja podatkovne baze so največkrat zastavljene skupaj z aplikacijsko infrastrukturo in jih aplikacije tudi zapisujejo. Te sledi so seveda odvisne od aplikacije in razvijalcev, obenem pa ne beležijo neposrednih posegov v bazo. Zato pri vsaki reviziji zelo priporočamo uvedbo revizijskih sledi podatkovne baze (angl. database audit), s katerimi beležimo predvsem vse neaplikativne posege v bazo, tako podatkovne kot strukturne in servisne. Izgovori, ki jih pri revizijah IS slišimo, da gre za prevelike količine podatkov, so neutemeljeni. Te sledi je mogoče zelo natančno nastaviti, in sicer točno, čemu in kdaj sledimo. Pri tem je treba seveda paziti, da kakšna pomembna sled ne izpade iz izbora, zato je naloga revizorja IS, da natančno preveri nastavitve in opredelitve teh revizijskih sledi.

Dodatno se revizijske sledi podatkovne baze lahko uvažajo tudi v t. i. orodja SIEM³, kjer jih je možno povezovati z drugimi sistemskimi sledmi in pridobiti celo vrsto novih relevantnih informacij o delovanju IS – npr. s katerih IP- naslovov se povezujejo izbrani privilegirani uporabniki in kdaj, kar je mogoče tudi omejevati itn.

3. OPERATIVNI POSTOPKI

Med operativnimi postopki na podatkovni bazi omenimo postopke arhiviranja in brisanja podatkov. Revizor IS mora najprej preveriti usklajenost teh postopkov z internimi pravili in standardi na eni strani ter uporabo različnih tehničnih možnosti na drugi. V teh postopkih se uporabljajo t. i. zgodovinske tabele, ki samodejno beležijo kopije spremenjenih (brisanih) podatkov, ter sprožilci (angl. trigger) in različne vgrajene (shranjene) procedure, ki samodejno nadgrajujejo oz. dodajajo logiko podatkovnim spremembam. Vse to povečuje kompleksnost postopkov in zahteva precejšnjo pozornost revizorja, predvsem npr. pri preverjanju zahtev GDPR-ja⁴ ali prisotnost številk PAN-a⁵ pri revidiranju zahtev PCI-ja⁶. Dodatno zahtevnost pregleda povečuje uporaba raznih uporabniških orodij za dostop do podatkovne baze.

Vsaka revizija podatkovne baze vključuje preverjanje postopkov nadzora, s katerimi zagotavljamo razpoložljivost in odzivnost podatkovne baze. Nadzorni postopki so praviloma že utečeni, orodja za nadzor pa dovolj razvita in uporabna, da z nadzorom ne bi smelo biti težav. Nekatere tehnične težave lahko povzročajo postopki preverjanja razpoložljivosti baze. Pri tem vsekakor ni dovolj, da se npr. strežnik odzove na ukaz »ping«, ker to ne zagotavlja delovanja baze. Problem postane kompleksnejši v visokorazpoložljivostnem (HA) okolju, v katerem sodelujeta dva ali celo več med seboj povezanih strežnikov, ki se usklajujejo, kateri je primarno delujoči, kateri pa rezervni strežnik baze. Pri tem je težava, da je praktično nemogoče predvideti in testirati vse možnosti in situacije, ki pri takem delovanju lahko nastanejo, tako da tveganje neoperativnosti baze kljub vsemu okolju HA ostaja. Še več, med sistemskimi upravitelji kroži šala, da je okolje HA večkrat vzrok kot rešitev za nedelovanje strežnika.

4. UPRAVLJANJE SPREMEMB

Revizija upravljanja sprememb podatkovne baze obsega spremembe arhitekture oz. strukture podatkovne baze, nastavitev in postopke apliciranja sprememb programske opreme. Revizijski načrt zajema standardne postopke brez posebnosti. Poudarek je na izčrpnem testiranju, čeprav je v praksi praktično nemogoče preveriti vse možne situacije, kot smo že omenili na področju HA. Testiranje se največkrat izvaja kar ob aplikacijskem testiranju.

Testni scenariji, pripravljeni posebej za podatkovno bazo, so v praksi redki.

Iz lastne prakse lahko omenimo postopke nadgrajevanja programske opreme, ki večkrat vključujejo tudi nadgradnjo oz. spremembe podatkovne baze, vendar ta ne omogoča obnovitve starega stanja (angl. fallback). V konkretnem primeru je pri apliciranju nadgradnje operativne (produkcijske) podatkovne baze nastala napaka, ki je povzročila nekonsistentno stanje, to pa ni omogočalo ne obnovitve stare ne postavitve nove različice programske opreme. To je pomenilo štiri ure nedelovanja ključne aplikacije.

Revizor IS preverja tudi postopke nadgrajevanja programske opreme, pri čemer je pozoren, da so varnostni popravki aplicirani čim prej oz. v skladu s stopnjo tveganja. Pri tem si lahko pomaga z namenskimi orodji za odkrivanje ranljivosti, ki so že pogosto v uporabi upravljavcev IS. Pri t. i. rednih popravkih programske opreme je pomembno, da so ustrezno načrtovani in v skladu s strategijo Is.

5. NEPREKINJENOST

Postopki neprekinjenosti zagotavljajo delovanje podatkovne baze v različnih primerih izpada. Osnovni postopki varnostnega kopiranja, ki vključujejo uporabo rezervne lokacije, so v praksi praviloma že utečeni. Pri tem je revizorjeva naloga preveriti politike zagotavljanja rezervnih kopij in obnovitev ter redno (praviloma vsaj letno) testiranje postopkov.

V praksi opažamo, da so IS precej dobro podprti s postopki neprekinjenosti ob katastrofi, medtem ko se pri izpadu posameznih komponent v najboljšem primeru zanašajo na visoko razpoložljivost. Različni scenariji delnih izpadov Is in postopki obnovitve zato niso vedno izdelani. Včasih so postopki tudi pomanjkljivi. Tako se še dogaja, da obnovitev podatkovne baze predvideva povrnitev stanja »na včerajšnji dan«, čeprav podatkovna baza ponuja obnovitve na točno določen čas (angl. Point in Time).

6. REVIDIRANJE PODATKOVNE BAZE V OBLAKU

Revizija podatkovne baze kot oblačne storitve pri uporabniku storitev v oblaku se tehnično ne razlikuje bistveno od klasične revizije. Ker gre za obliko storitve zunanjega dobavitelja, je pomembno, ali gre za nekakšno gostovanje, storitev virtualizacije strežnikov ali oblačno storitev, ki jo označujejo:

• širok medmrežni (internetni) dostop;
• elastičnost oz. hitra prilagodljivost storitve; možnost merjenja storitev;
• dodatne storitve in spremembe na zahtevo uporabnika storitve.
• prav tako je revizijski načrt odvisen od vsebine storitve, ki jo zagotavlja ponudnik oblačne storitve, in sicer:
• ali gre le za storitev infrastrukture (Iaas – iz angl. Infrastructure as a Service);
• ali vključuje tudi podatkovno raven in (navidezne) strežnike (Paas – angl. Platform as a Service);
• ali pa ponudnik skrbi tudi za aplikacijo in podatke (saas – angl. Software as a Service).

Revizor Is bo na podlagi politike uporabe oblačnih storitev in pogodbe s ponudnikom presodil, ali je uporaba oblačnih storitev v skladu s poslovno strategijo in strategijo razvoja IS ter ali je uporaba oblačnih storitev v sam IS ustrezno integrirana. Preveril bo, ali je bila migracija IS (oz. določenega dela Is) v oblak ustrezna, ali so bila pred tem primerno ocenjena tveganja in grožnje migracije in delovanja v oblaku ter katere dodatne kontrole so bile pri tem potrebne.

Skladno z revizijskimi cilji bo potrebna tudi evaluacija oz. ocena ponudnika. Preveriti bo treba, ali je storitev ustrezna in ali je ponudnik zanesljiv in izkušen. Po pogodbenih obveznostih bo treba preveriti odgovornosti ponudnika (in uporabnika) storitve, pri čemer bo treba ugotoviti, ali so v medsebojnem odnosu nedorečenosti, manjkajoči dogovori oz. »luknje« v pogodbi.

Namen članka ni opisovati vse zakonske zahteve in zahteve standardov, želimo pa poudariti, da je pri reviziji oblačnih storitev potrebna osrednja pozornost oz. skrb podatkom uporabnika storitve. Navsezadnje gre za prenos največjega bogastva podjetja – tj. podatkov izven neposredne kontrole, zato je dobro vsa tveganja natančno opredeliti in obvladati. Pri prehodu v oblak bo zato potrebna klasifikacija podatkov, ki nam bo pomagala odgovoriti tudi na dileme, kot so:

• ali lahko migriramo podatke in komu (tj. ali lahko zaupamo vsem ali samo nekaterim ponudnikom); ali lahko migriramo vse ali samo šifrirane in/ali (psevdo)anonimizirane podatke;
• kje so (lahko) podatki;
• ali so ustrezno opredeljene vloge obdelovalca podatkov in nadzora; drugo (npr. sporočanje o vdoru in/ali razkritju podatkov).

7. ZAKLJUČEK

V članku opredelimo nekaj možnosti in zahtev, ki jih revizor informacijskih sistemov lahko ugotovi pri revidiranju podatkovnih baz. Skušali smo razjasniti, zakaj je pri nekaterih revizijskih ciljih potrebno tudi določeno tehnično znanje s področja delovanja podatkovnih baz, ki nam omogoča, da preverimo natančno določene nastavitve, parametre in revizijske sledi ter ugotavljamo tveganja. Seveda pa je uporaba takega znanja odvisna od naročnika revizije – ta bo po revizijskih ciljih opredelil tveganja, ki jih bo v reviziji podatkovne baze treba preveriti.

Opombe

* Iztok Jeras, univ. dipl. ekon., CIsA, preizkušeni revizor, Interes, d. o. o., iztok.jeras@interes.si.

1. Angl. Lightweight Directory Access Protocol, slov. internetni protokol za dostop do imenikov.

2. Angl. High Availability.

3. Angl. Security Information and Event Management, slov. sistem za upravljanje varnostnih informacij in dogodkov.

4. Angl. General Data Protection Regulation, slov. splošna uredba o varstvu podatkov.

5. Angl. Primary account number, slov. številka plačilne kartice.

6. Angl. Payment Card Industry, slov. industrija plačilnih kartic.