Logid ja logimine

Süsteemi logi on süsteemis toimunud sündmuste kronoloogiline salvestus. Logisid kasutatakse erineval eesmärgil, tüüpilised logide kasutusvaldkonnad on infoturbe tegevused, süsteemide arendusel süsteemis toimuvate protsesside mõistmine ja probleemide lahendamine ning süsteemide testimine. Logisid saab kasutada ka ebatüüpiliselt, näiteks äri tööprotsesside analüüsiks: kus on pudelikaelad, kus kulutatakse kõige rohkem aega või kus midagi dubleeritakse.

Vähegi suurema süsteemi korral tekib logidesse kiiresti palju andmeid, mille töötlemine käib inimesel üle jõu, kuid mida on võimalik automatiseerida. Selleks tööks on võimalik võtta kasutusele turvateabe ja -sündmuste haldussüsteem (ingl security information and event management ehk SIEM). SIEM-i mõte on koguda logisid ja kaardistada infot süsteemi taristu ja äriprotsesside kohta, et võimaldada turbeanalüütikul teha kontekstist sõltuvaid otsuseid süsteemis toimuvate sündmuste kohta.

Süsteemi logi on tegevuste kronoloogiline salvestus, et hiljem oleks võimalik tuvastada, mis on süsteemis toimunud. Süsteemi logi võib olla nii kasutajategevuste salvestus kui ka süsteemse info salvestus (nt mingi andmehulga salvestamine mälupuhvrisse). IT-süsteemide usaldusväärsuse tagamiseks on tarvis, et logisse saaksid kirja kõik turbe seisukohast tähtsad sündmused.

Revisjonlogi ehk auditlogi (ingl audit trail, audit log) on kronoloogiliselt salvestatud tegevuste järjestus, mille abil on võimalik tuvastada, mis tegevusi tehti, et andmed/süsteem on jõudnud mingisse kindlasse olekusse. Revisjonlogi kirjed peavad tekkima süsteemi sisse- või väljalogimisest ja transaktsioonidest süsteemis, näiteks panganduse transaktsioonidest või isiku terviseandmetega tehtavatest tegevustest. Revisjonlogikirjete ulatus ja sisu sõltuvad konkreetse süsteemi vajadustest.

Logikirjete sisu sõltub logimise eesmärgist. Näiteks tarkvaraarenduse puhul võib olla vajadus kirjutada logisse ühte tüüpi andmeid, turvasündmuste analüüsiks aga teist tüüpi andmeid. Samuti on logikirjeid võimalik luua erineva detailsusega.

Logisid on võimalik luua eri tasemetel: mida kõrgema tasemega logi, seda vähem sinna üldjuhul kirjeid tekib, ja mida madalama tasemega logi, seda rohkem kirjeid tekib. Näiteks süsteemi arenduse korral on enamasti vaja rohkem logiinfot süsteemis toimuva kohta kui juba reaalses süsteemis.

Logide tasemed võivad olla on järgmised: Fatal, Error, Warning, Info, Debug ja Trace, kus iga järgmine toodab rohkem andmeid.

Turvasündmuste analüüsiks peavad logiandmed tüüpiliselt sisaldama vähemalt järgmist infot:

•ainulaadne logikirje tunnus (logiidentifikaator, nt ID);

•sündmuse toimumise aeg (ajatempel);

•lähteaadress (ingl source IP);

•sündmuse alustanud protsess (nimi, number);

•sündmusega seotud kasutajakonto (ingl account);

•siht-IP-aadress (ingl destination IP);

•mis sündmus toimus (nt sisselogimine);

•millisele protsessile/failile/kasutajale jne sündmus mõjus;

•sündmuse tulemus (õnnestumine, ebaõnnestumine vms).

Need andmed peavad logis olemas olema, et logiandmeid oleks võimalik turvasündmuste puhul analüüsida, kuid süsteemi vajaduste põhjal võib vajalikke andmeid lisada, samuti sisaldavad lisaandmeid auditlogide kirjed.

Revisjonlogi puhul on terviklikkuse ja puutumatuse nõuded kriitilised. Revisjonlogi protsessid peavad jooksma süsteemis suurte privileegidega, et nad saaksid ligipääsu ja jälgimisvõimaluse kõigi süsteemis toimetavate kasutajate tegevusele. Revisjonlogi loomise peatamine või logimisreeglite muutmine süsteemis peab nõudma väga suure privileegiga kasutajat või olema keelatud. Revisjonlogi failid või andmebaas peab olema tavaõigustega kasutajale ligipääsmatu. Üks variant revisjonlogi andmeid kaitsta on viia andmed kesksesse logiserverisse, kuhu on ligipääs üksnes piiratud isikute rühmal või kuhu on andmeid võimalik ainult salvestada, aga mitte muuta ega kustutada.

Logiandmeid saab salvestada nii failidesse kui ka andmebaasi. Neid on võimalik hoida nii lokaalselt kui ka tsentraalselt.

Tsentraalne logiserveri kasutamisel on järgmised eeliseid.

•Terviklik ülevaade süsteemis toimuvast. Süsteemi eri osadest ühte logiserverisse kokku toodud logiandmed võimaldavad analüüsida logisid üle süsteemide ja saada terviklikumat ülevaadet süsteemis toimuvast.

•Saab vähendada logide mahtu rakenduseserverite andmebaasides ja kettal.

•Saab säilitada logide terviklikkust/puutumatust, kus administraator või ründaja ei saa ka rakendusserveri ründamise korral muudatusi teha.

Andmete transportimisel tsentraalsesse logiserverisse või SIEM-i tuleb tagada logide terviklikkus ja puutumatus.

Logiandmete puhul tuleb otsustada, kes ja mis eesmärgil pääseb logiandmetele ligi. See sõltub süsteemist ja organisatsioonist, kuid üldreegel on see, et logiandmetele peaks pääsema ligi võimalikult väike ja kindel rühm inimesi.

Sõltuvalt süsteemist ja rakendusest võib olla vaja logiandmeid krüpteerida ja/või aheldada, mis teeb peaaegu võimatuks andmete märkamatu muutmise ja tagab logide terviklikkuse. SIEM-i lahendus võib seda teha näiteks järgmiselt: logid arhiveeritakse failide kaupa ja arvutatakse failide räsid. Kui süsteem teeb terviklikkuse kontrolli, kontrollib ta üle logifailide räsid. Kui need ei klapi, on tuvastatud logifaili muudatus.

Logiandmeid tuleb säilitada nii kaua kuni hädapärast tarvis või nii pikalt, kui seadustest, regulatsioonidest või lepingutest tulenevad nõuded määravad.

Logiandmete säilitusaja möödumisel tuleb logiandmed kustutada kogu süsteemist, kaasa arvatud varukoopiatelt, väljavõtetelt ja erinevatest ajutisel otstarbel loodud arenduslogidest.

Infotehnoloogia toodetesse on üldjuhul logimise funktsioon sisse ehitatud ja logimise taset saab seadistada. Lahenduse eesmärgi järgi tuleb valida sobiv logimise tase, et nende logiandmete töötlemisel oleks võimalik saada ülevaade seadmega või tarkvaraga toimunust.

Logimist mittevõimaldava komponendi süsteemi lisamine peab olema teadlik otsus, mille tegemisel on hinnatud riske, mida võib logimisfunktsiooni puudumine põhjustada.

Logimise põhimõtted loodavale süsteemile tuleb paika panna juba süsteemi planeerimise faasis. See vähendab valminud süsteemi ümbertegemise vajadust ja aitab vältida näiteks olukordi, kus äriprotsess on üles ehitatud selliselt, et põhipunktides on väga keeruline luua piisavat logikirjet ja revisjonlogi loomiseks tuleb vastvalminud süsteemi ümber tegema hakata.

Riigi ja kohaliku omavalitsuse andmekogude pidamisel kasutatavate infosüsteemide loomisel on kohustuslik kasutada infosüsteemide kolmeastmelise etalonturbe raamistikku (ISKE) ja määrata süsteemile turvaklass. Määratud turvaklassi kirjelduses on toodud sellele turvaklassile esitatavad logimise nõuded. Neid nõudeid on võimalik kasutada süsteemi kirjeldamisel, et määrata logitavad sündmused ja logide sisu.

Arendajalt infosüsteemi tellimisel ja testsüsteemi kasutamisel tuleb arvestada, et kui testsüsteemis kasutatakse reaalseid andmeid, tuleb ka testsüsteemis andmetega toimuvate tegevuste kohta luua tegeliku süsteemiga sarnased logimisrakendused, et andmelekke korral põhjused leida.

Logidest ei ole turvasündmuste tuvastamisel ja analüüsil palju kasu, kui andmed on puudulikud. Tabelis on esitatud tavalisemad vead ja mida nende puhul ette võtta.