17. veebruar 2019
Tähelepanu! Artikkel on enam kui 5 aastat vana ning kuulub väljaande digitaalsesse arhiivi. Väljaanne ei uuenda ega kaasajasta arhiveeritud sisu, mistõttu võib olla vajalik kaasaegsete allikatega tutvumine.

Logid ja logimine

Korralike logide põhjal on võimalik tuvastada, mis on süsteemis toimunud ja kes on süsteemis mingisuguseid tegevusi teinud, kirjutab Security Software OÜ projektijuht Helena Jürgenson.
Security Software OÜ projektijuht Helena Jürgenson.
Foto: Erakogu

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.

Logid

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

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üüs

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.

Logide terviklikkus ja puutumatus

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.

Logiandmete säilitamine

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.

Logimine valmistoodetes

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.

Logimine organisatsioonile arendatava süsteemi korral

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.

Vead logimisel

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.

Probleem
Lahendusvõimalus
Ei ole läbi mõeldud või pole teada, mis eesmärgil logisid kogutakse ja milleks on neid hiljem vaja kasutada.Tuleb selgitada nõudeid või sisemisi vajadusi logide kogumiseks, et otsustada kogutavate logide maht ja ulatus – nt vajalik logitase ja liik, säilitamise aeg (sh andmekaitsemääruse eesmärkide täitmine), kas logisid kasutatakse arendustööks, IT-süsteemi olukorra jälgimiseks, turvasündmuste kogumiseks jne.
IT-süsteemi logi on seadistamata või pole süsteem võimeline logi looma. IT-süsteemi logi tuleb seadistada ja kui süsteem ei ole võimeline logi looma, tuleb mõelda süsteemi uuendamise või väljavahetamise peale.
Liiga vähe logisid või väheinformatiivsed logid.Süsteemi logimise osa tuleb seadistada või vajaduse korral ümber teha.
Vajalikes kohtades ja vajaliku tasemega logimise lisamine süsteemi on keeruline või võimatu.See on probleem, mida on lihtsam ära hoida kui lahendada, seega tuleks logimise ja turbe nõuded lisada süsteemi juba süsteemi planeerimise ja hankimise faasis, et süsteemi üles ehitades oleks võimalik nendega arvestada.
Liiga palju logisid ehk olukord, kus logitakse peaaegu kõike suvalisel kujul ja vajaliku info leidmine muutub keeruliseks.Tuleb analüüsida logimise vajadusi ja seadistada logimine piisavalt detailselt.
Logisid ei jälgita.Tuleb luua toimingud logide jälgimiseks, et tuvastada tegevuste kõrvalekaldeid.

IT JUHTIMISE TEABEVARA

Artikkel ilmus Äripäeva Teabekeskuse väljaandes IT juhtimine.

Põhjalik ülevaade infotehnoloogia võimalustest ja otstarbeka rakendamise põhimõtetest. Kui vastutate ettevõtte strateegia ja investeeringute eest, siis saate põhjaliku info IT-valdkonna praktilisest poolest ning teete tulemuslikke juhtimisotsuseid.

Aastalitsentsiga saate

•ligipääsu igal kuul uuenevale teabevarale

•kasutada e-nõuandekeskust

•lisavõimalusena paberväljaande ja selle täiendused kord kvartalis

•e-uudiskirja Õigusuudised 10 korda aastas

Liitu ITuudiste uudiskirjaga!
Liitumisega nõustud, et Äripäev AS kasutab sinu e-posti aadressi sulle uudiskirja saatmiseks. Saad nõusoleku tagasi võtta uudiskirjas oleva lingi kaudu. Loe oma õiguste kohta lähemalt privaatsustingimustest
Indrek KaldITuudised.ee toimetajaTel: 511 1112
Anne WellsReklaami projektijuhtTel: 5880 7755