3 Lokit ja lokityypit

Lokitiedostojen tulkinta edellyttää usein syvällistä tietämystä kyseessä olevan tietoteknisen ympäristön arkkitehtuurista ja järjestelmätoteutuksesta. Tässä luvussa käsitellään erityyppisiä lokitiedostoja, jotta ohjeen lukija saa kattavan käsityksen siitä, millaisia lokeja on olemassa ja mistä lokitietoja tyypillisesti syntyy. Lokit voidaan jakaa ja luokitella usealla tavalla. Ohjeessa käytetään neljä luokkaa sisältävää lokitietojen luokittelua:

  • ylläpitoloki

  • käyttöloki

  • muutosloki

  • virheloki.

Käytännössä kuitenkin monet lokit voivat tietosisällöstä riippuen kuulua moniin edellä mainittuihin luokkiin, eikä erilaisia lokeja voida tyhjentävästi sijoittaa yhteen ainoaan luokkaan.

Lokeja tuottavat tyypillisesti käyttöjärjestelmien varusohjelmistot, sovelluk­set, tietokannat ja verkkolaitteet. Lokeja tuottavan järjestelmän tai sovelluksen lisäksi lokit voidaan jakaa niiden tyypin, semanttisen sisällön tai käyttötarkoi­tuksen mukaan. Järjestelmälokien[17] ensisijainen tavoite on informoida toimin­tahäiriöistä ja -virheistä. Haltijalokin[18] tarkoituksena on osoittaa jonkin asian, esimerkiksi ip-osoitteen, haltija tietyllä ajanhetkellä. Pääsynvalvontalokien[19] tehtävänä on auttaa järjestelmän käytön ja turvallisuuden valvonnassa.

Lokin käyttötarkoituksesta riippuu, onko se osa varsinaista järjestelmää ja henkilörekisteriä, vai erillinen rekisteri. Silloin kun lokilla on itsenäinen käyttö­tarkoitus suhteessa kulloinkin kyseessä olevaan ydintoiminnon henkilötietojen käsittelyyn, on myös lokista laadittava henkilötietolain tarkoittama rekisteris­eloste. Kaikki lokit eivät ole henkilörekistereitä. Aina loki ei muodosta ollenkaan henkilörekisteriä, jolloin myöskään rekisteriselosteen tarvetta ei ole.

Jäljitettävyys- ja puuttumiskynnysten kannalta on tarkoituksenmukaista ylläpitää edellä mainittuja lokityyppejä, joiden tiedot voivat teknisesti sijaita yhdessä lokissa, useassa erillisessä lokissa tai mieluiten yhdessä lokien kerää­miseen omistetussa järjestelmässä.

Ylläpitoloki sisältää tiedot:

  • käyttöoikeuksien muutoksista, poistoista ja lisäyksistä

  • rekistereiden käyttöön liittyvien virhetilanteiden hallinnasta

  • järjestelmään tehdyistä muutoksista.

Käyttöloki sisältää tiedot:

  • sisään- ja uloskirjautumisista käyttäjä-, ryhmä- ja sovellustietotasoilla

  • epäonnistuneista kirjauksista

  • käyttöoikeuksien vaihdosta erityisesti normaalikäyttäjän oikeuksista etu­oikeutettuihin

  • tietokannan lukutapahtumista ja kyselytiedoista hakuehtoineen

  • tulostuksesta ja tallennuksesta.

Muutoslokin tulee sisältää tiedot:

  • järjestelmien tietosisällön muutoksista: poistoista ja lisäyksistä

  • järjestelmäparametrien ja asetustiedostojen muutoksista.

Virhelokin tulee sisältää tiedot:

  • seurattavassa järjestelmässä tai tapahtumassa havaituista virheistä

  • rekisterissä havaituista virheistä ja epäjatkuvuuksista.

3.1.1 Viestinnän loki

Viestinnän loki sisältää tietoja viestintätapahtumista. Lokien ensisijainen tar­koitus on viestintäjärjestelmän vikatilanteiden selvittäminen, mutta viestin­nän lokeja voidaan käyttää myös tietoturvapoikkeamatilanteiden hallintaan tai jonkin viestintätapahtuman näyttämiseen toteen.

Esimerkkejä viestinnän lokeista ovat sähköpostiloki ja keskustelujärjes­telmän loki. Sähköpostin välitysjärjestelmät kirjaavat lokiin tyypillisesti osa­puolten sähköpostiosoitteet, lähettäjän tai välittävän järjestelmän IP-osoitteen, kellonajan, viestin yksikäsitteisen tunnisteen, tilastotietoa toimituksesta, sekä toimituksen tilatiedon tarkennuksineen. Usein esimerkiksi sähköpostijärjestelmän lokia käytetään sen selvittämiseen, onko viesti, joka ei ole mennyt perille, lähtenyt oman organisaation järjestelmästä.

Huomioitavaa lokin käsittelyssä:

Lokit sisältävät viestinnän tunnistamistietoja sekä henkilötietoja, joten niiden käsittelyssä on huomioitava sähköisen viestinnän tietosuojalain, henkilötieto­lain sekä työelämän tietosuojalain velvoitteet.

3.1.2 Haltijaloki

Haltijaloki kertoo, kenen hallussa jokin verkkotunniste, tyypillisesti IP- tai MAC-osoite[20], on ollut tiettynä ajanhetkenä. Haltijaloki voi perustua toden­nuslokiin, jossa ip-numero liitetään tiettyyn henkilökohtaiseen tunnisteeseen kuten käyttäjätunnukseen, tai DHCP-lokiin[21], jossa IP-numero annetaan tie­tyn MAC-osoitteen tai liittymätunnisteen käyttöön.

Lokien ensisijaisena tarkoituksena on varmistaa se, että tarvittaessa voidaan selvittää, minkä liittymän käytössä tietty iIP-osoite on ollut nimettynä hetkenä, jotta voidaan selvittää tapahtumien kulku ja osapuolet. Haltijalokia voidaan käyttää rajallisesti myös sen selvittämiseen, onko organisaation verkossa sinne kuulumattomia laitteita. Tämä voidaan saavuttaa vertaamalla lokissa olevia lait­teiden MAC-osoitteita laitekirjanpidossa oleviin osoitteisiin. On erittäin tärkeää, että organisaatiolla on ajantasainen laitekirjanpito ja tieto omista liittymistään sekä omien laitteidensa MAC-osoitteista. Koska MAC-osoitteet ovat laite- ja osittain myös valmistajakohtaisia[22] , voidaan lokin avulla erottaa toisistaan myös vaikkapa valmistajan X WLAN-tukiasemat valmistajan Y WLAN-tukiasemista. Kun tiedetään, että käytössä pitäisi olla vain valmistajan X tukiasemia, kaikki muut tukiasemat on yksinkertaista tunnistaa ylimääräisiksi.

Esimerkkejä tarpeellisista haltijalokeista ovat muun muassa:

  • DHCP-loki silloin, kun käyttäjien työasemilla tai muilla verkkolaitteilla ei ole käytössä staattista osoitetta.

  • Proxy-lokit silloin, kun organisaatiosta liikennöidään esimerkiksi HTTP- protokollalla yhden proxyn kautta. Proxy-lokin avulla on selvitettävissä[23], mistä organisaation sisäisestä IP-osoitteesta tietty yhteys todella tuli.

  • Mahdollisten yhteiskäyttöisten työasemien kirjautumisloki, joka voi toi­mia myös muutoin kuin sähköisesti.

Huomioitavaa lokin käsittelyssä:

Lokit sisältävät henkilö- tai tunnistamistietoja. Näiden tietojen käsittely on sal­littua vain lain sallimissa puitteissa ja tavoilla.

Viestinnän osapuolten oikeusturvan ja lokien hyödynnettävyyden kannalta on keskeistä, että lokia tuottavat laitteet ovat aikapalvelun avulla tarkalleen oikeassa ajassa ja että ylläpitäjä tietää mille aikavyöhykkeelle loki kirjataan. Tämä pätee laajemminkin kaikkiin lokityyppeihin.

 

Lokit sisältävät henkilö- tai tunnistamistietoja. Näiden tietojen käsittely on sallittua vain lain sallimissa puitteissa ja tavoilla.

Viestinnän osapuolten oikeusturvan ja lokien hyödynnettävyyden kannalta on keskeistä, että lokia tuottavat laitteet ovat aikapalvelun avulla tarkalleen oikeassa ajassa ja että ylläpitäjä tietää mille aikavyöhykkeelle loki kirjataan. Tämä pätee laajemminkin kaikkiin lokityyppeihin.

3.1.3 Sovellustason pääsyvalvontalokit

Sovellustason pääsynvalvontalokit kertovat, mistä (IP-osoitteesta) on muo­dostettu onnistuneesti yhteys johonkin suojattuun kohteeseen ja millä käyt­täjätunnisteella kohteeseen on kirjauduttu. Yleensä sovellukset pitävät kirjaa myös epäonnistuneista yhteysyrityksistä sekä yrityksistä ylittää omat käyttö­valtuudet.

Lokien tarkoituksena on mahdollistaa ehjä kirjausketju yhdistämällä käyt­töoikeudet ja lähdeosoite tietoturvapoikkeamien selvittämiseksi. Lokien tois­sijainen tarkoitus on mahdollistaa järjestelmään kohdistuvien sanakirjahyök­käysyritysten seuranta.

Esimerkkejä tarpeellisista pääsyvalvontalokeista ovat muun muassa shell access-lokit (sshd[24], tcp wrapper[25]), sovellusten, kuten taloushallinnon järjes­telmien, tilausjärjestelmien, toiminnanohjausjärjestelmien ja muiden vastaa­vien lokit.

Huomioitavaa lokin käsittelyssä:

Lokit saattavat sisältää henkilö- tai tunnistamistietoja. Näiden tietojen käsittely on sallittua vain lain sallimissa puitteissa ja tavoilla.

Jos lokia tuottavassa järjestelmässä käsitellään henkilötietoja, turvaluokitel­tua tai muuten erityisesti suojattavaa aineistoa, pääsyvalvontalokeista on syytä ohjata automaattisesti kopio myös erilliseen lokipalvelimeen, johon mahdolli­nen murtautuja ei pääse samalla käsiksi.

3.1.4 Tarjottujen, julkisten verkkopalveluiden sovelluslokit

Tarjottujen verkkopalveluiden sovelluslokit eivät periaatteessa eroa edelli­sessä kappaleessa esitetyistä sovellustason lokeista. Ero tässä on se, että edel­lisessä kappaleessa käsiteltiin organisaation sisäisten sovellusten lokeja. Sisäi­sillä sovelluksilla pitäisi olla rajattu ja tiedossa oleva käyttäjäjoukko, kun taas näillä verkkopalveluiden sovelluksilla ei välttämättä ole.

Verkkopalveluiden sovelluslokista ilmenee, mistä verkko-osoitteesta pal­veluun on otettu milläkin hetkellä yhteys. Lokista ilmenee myös mahdollinen kirjautumiseen liittyvä käyttäjätunnus sekä tunnistautumisen onnistuminen tai epäonnistuminen silloin, kun palvelu vaatii käyttäjän tunnistusta.

Verkkopalveluiden lokien ensisijaisena tarkoituksena on yhdistää palvelu­tapahtuma ja lähdeosoite vikatilanteiden tai tietoturvapoikkeamien selvittä­miseksi. Lokien perusteella voidaan myös tuottaa tilastollista aineistoa palve­lun käytöstä tai jonkin sivuston osan tai muun vastaavan suosiosta sekä siitä, mistä sivustolle tullaan. Monissa tapauksissa on myös tärkeää pystyä lokien avulla toteennäyttämään jonkun tiedon luovuttaminen tai transaktion[26] toteu­tuminen.

Esimerkkejä tarpeellisista pääsyvalvonta- ja verkkopalveluiden sovelluslo­keista ovat muun muassa WWW-lokit. WWW-palveluissa tuotetaan tyypilli­sesti seuraavia lokeja:

 

  • Tapahtumaloki tai käyttöloki, joka luo WWW-palvelimelta haetusta tie­dosta lokimerkinnän.

  • Virheloki[27] , johon kirjataan sovelluksen virheet selityksineen.

  • Selaintyyppiloki, joka kerää tietoja asiakasohjelmistoista eli selaimen tyy­peistä sekä versioista.

  • Viittausloki, johon kerätään HTTP-yhteyteen liittyviä tietoja ja ne URL ­tiedot, mistä asiakasohjelmisto tuli organisaation sivuille.

Tyypillisesti tapahtuma-, käyttö-, selaintyyppi-, ja viittausloki ovat samassa lokitiedostossa ja niiden kerääminen on www-palvelinohjelmiston vastuulla.

Huomioitavaa lokin käsittelyssä:

Lokit saattavat sisältää henkilö- tai tunnistamistietoja. Näiden tietojen käsittely on sallittua vain lain sallimissa puitteissa ja tavoilla.

3.1.5 Muut käyttöjärjestelmä- ja sovelluslokit

Käyttöjärjestelmät keräävät aina lokia monista järjestelmässä tapahtuvista asi­oista, ellei tätä ominaisuutta erikseen ole poistettu käytöstä. Myös käyttöjär­jestelmän apuohjelmat ja muut sovellukset voivat toteutuksesta riippuen kerätä lokia sovelluksen toiminnasta ja virheistä.

Käyttöjärjestelmän tuottamat lokit vaihtelevat järjestelmästä toiseen, mutta tyypillisesti lokeja on samassakin järjestelmässä useita erilaisia. Esimerkiksi Windows-järjestelmä tuottaa sovellus-, suojaus- ja järjestelmälokeja (application, security ja system lokit). Sovelluslokit sisältävät tietoa muun muassa käynnisty­neistä ohjelmista, virheistä käynnistyksessä, ohjelman käynnistysajankohdan sekä tiedon käynnistäjästä. Suojausloki pitää kirjaa määritellyistä onnistuneista ja epäonnistuneista tapahtumista ja niiden toteuttajasta ja kellonajasta. Järjes­telmäloki puolestaan sisältää tietoa eräistä järjestelmän sisäisistä tapahtumista, niihin liittyvistä prosesseista ja virheistä. Windows-järjestelmässä sovelluksen lokin tuottaminen on yleensä sovelluksen itsensä vastuulla. Jos jokin sovellus ei erikseen tuota lokia, lokitietoa ei ole saatavilla.

UNIX-järjestelmät tuottavat tyypillisesti /var/log tai /var/adm-hakemistoi­hin runsaasti tietoa järjestelmän sisäisistä tapahtumista sekä käyttäjän teke­mistä toimista. Kaikki lokit eivät välttämättä sisällä kaikissa ympäristöissä ja toteutuksissa tarpeellisia tietoja. Lokin sisältö ja tarpeellisuus tulee varmistaa tapauskohtaisesti.

Lokin käyttötarkoitus riippuu siitä, mistä lokista on kyse. Tyypilliset käyt­tötarkoitukset ovat järjestelmän käytön ja oikean toiminnan valvonta, mahdol­listen tulevien tai piilevien vikatilanteiden paikallistaminen ja järjestelmän tur­vallisuuden valvonta sekä tapahtumaketjujen todentaminen (audit trail).

Käyttöjärjestelmät tarjoavat runsaasti mahdollisuuksia säätää ja määritellä, mitä lokeihin kirjoitetaan, kauan lokeja säilytetään ja mitä lokeille tehdään jonkun määrätyn tiedostokoon täyttyessä. Oletusasetukset eivät monesti ole tarkoituksenmukaisia, joten käyttöjärjestelmien lokiasetuksia on syytä säätää järjestelmäkehityksen yhteydessä ja dokumentoida lokimääritykset.

Huomioitavaa lokien käsittelyssä:

Nämä lokit eivät aina sisällä henkilö- tai tunnistamistietoja.

Käyttöjärjestelmät tarjoavat paljon mahdollisuuksia aktivoida tiettyjä lokeja sekä määritellä, mitä lokiin kirjataan. Esimerkiksi kirjataanko tietystä tapahtumasta mitään, kirjataanko tapahtuman onnistuminen tai epäonnistuminen. Näiden parametrien tarpeiden mukainen määrittely on tärkeää. Lisäksi on oleellista määritellä lokitiedostoille riittävä koko ja lokien kierrätysrutiinit, erityisesti jos lokeja ei siirretä keskitettyyn lokijärjestelmään, jossa riittävä levytila on helpompi varmistaa.

Erillisten sovellusten ja erityisesti räätälöityjen sovellusten lokit voivat olla ongelmallisia siirrettäviä keskitettyyn lokijärjestelmään. Usein sovellukset voivat kirjoittaa erillisiä lokeja ympäriinsä levyjärjestelmää ja hakemistorakennetta sekä käyttävät ei-standardeja tiedosto- tai tekstimuotoja lokien tallentamiseen. Hankintojen yhteydessä tulee varmistaa, että lokit saadaan järjestelmästä talteen oikeassa muodossa ja siirrettyä tarvittaessa keskitettyyn lokijärjestelmään.

Tietokannan varmistusloki sisältää kaikkia tietokantaan tallennettavia tietoja, joten sen tietosisältö on sama kuin ao. tietojärjestelmän ja sen käyttötarkoitus on niin suoraan sidoksissa itse kannan käyttötarkoitukseen, että siitä ei yleensä katsota tarpeelliseksi tehdä erillistä rekisteriselostetta.

3.1.6 Verkkotason pääsyvalvonta- ja yhteyslokit

Verkon aktiivilaitteet, kuten reitittimet ja palomuurit, keräävät lokeja niiden kautta kulkevista yhteyksistä. Verkkotason lokit kertovat tyypillisesti mistä osoitteesta on mennyt liikennettä mihin osoitteeseen. Korkeamman proto­kollatason lokista näkyy myös mihin tietoliikenneportteihin[28] liikennöinti on kohdistunut.

Murrettujen palvelinten levyiltä löytyviä lokeja tunkeutuja voi muuttaa, mikäli niitä ei ole siirretty suojaan keskitettyyn lokijärjestelmään tai kertakir­joitteiselle medialle. Sen sijaan verkkolaitteiden lokit ovat yleensä tunkeutujan ulottumattomissa, ellei tunkeilija ole päässyt murtautumaan itse verkkolait­teille. Myös verkkolaitteiden lokitiedot on suositeltavaa siirtää mahdollisuuk­sien mukaan keskitettyyn lokijärjestelmään, jolloin myös ne ovat paremmassa turvassa erilaisia hyökkäyksiä vastaan. Palomuuri- ja reititinlokeista selviää mahdollisten hyökkäysten kulkureitit kaikkein luotettavimmin, mutta nämä lokit eivät puolestaan kerro, mitä murretussa palvelimessa on tapahtunut tai että palvelin yleensäkin on murrettu.

Verkkotason pääsynvalvonta- ja yhteyslokien tarkoitus on vikatilanteiden selvittäminen, mutta niitä voidaan käyttää myös tietoturvapoikkeamien doku­mentointiin ja selvittämiseen. Monissa tapauksissa on perusteltua kerätä verk­kotason pääsynvalvontalokitietoja myös sallituista, ei pelkästään estetyistä yhteyksistä.

Esimerkkejä tarpeellisista verkkotason pääsynvalvonta ja yhteyslokeista ovat muun muassa reititinloki, palomuuriloki ja reititinten tuottama flow- data[29].

Huomioitavaa lokien käsittelyssä:

Salassapidettävää aineistoa sisältävän palvelimen suojana olevan palomuurin tulee kirjata onnistuneet yhteydet, ei pelkästään epäonnistuneita yhteyksiä. Palomuurien oletusasetuksissa korostetaan tyypillisesti liikaa epäonnistuneita yhteyksiä.

Myös verkkolaitteiden lokit on mahdollista ja suositeltavaa siirtää suojaan keskitetylle lokipalvelimelle.

Lokit sisältävät tunnistamistietoja.

3.1.7 Transaktiolokit

Transaktiolokiin kirjataan tietokantatapahtumia, kuten kirjoitus-, muutos-, poisto- ja lukuoperaatioita. Lokien varsinaisena tarkoituksena on ylläpitää järjestelmän yhtenäisyyttä ja käytännössä transaktioloki on toiminnallinen ja erottamaton osa itse tietokantaa. Lokeja voidaan kuitenkin käyttää myös sen selvittämiseksi, kuka teki jotain tietokantaan, esimerkiksi muutti tai luki[30] tietyn solun arvoa. Tietomurtotapauksissa tietokannat ovat yleensä murron perimmäinen syy ja kohde, sillä juuri tietokannassa säilytetään niitä tietoja, joilla on taloudellista tai muuta arvoa. Siksi tietokannat tulee suojata erityisen hyvin ja niiden käyttöä valvoa tehokkaasti.

Yleisesti transaktiolokilla tarkoitetaan tietokantojen yhteydessä tietokannan hallintajärjestelmän keräämää toimintohistoriaa, joilla pyritään varmista­maan nk. ACID-periaatteen eli tiedon oikeellisuuden säilymisperiaatteet:

  • Atomisuus (Atomicity). Jokainen operaatio pitää suorittaa loppuun asti tai peruuttaa kokonaisuudessaan.

  • Oikeellisuus (Consistency). Jokaisen tietokantatapahtuman jäljiltä tieto­kannan tulee olla oikeellisessa ja yhtenäisessä tilassa.

  • Eristys (Isolation). Tietokantatapahtumat eivät saa vaikuttaa toisiinsa ja keskeneräinen suoritus ei saa näkyä muille tapahtumille.

  • Kestävyys (Durability). Onnistuneiden tietokannan päivitysten pitää säi­lyä mahdollisen tietokannan virhetilanteen jälkeen.

Fyysisesti transaktioloki on tiedosto tietokantatapahtumista, jotka on tehty tietokantaan (esim. edellisen täysvarmistuksen jälkeen) ja sitä säilytetään eril­lään tietokannasta. Virhetilanteissa transaktiolokia voidaan käyttää palautta­maan tietokanta virhetilannetta edeltäneeseen tilaan. Tällöin tietokannan hal­lintajärjestelmä vertaa transaktiolokia tietokannan tilaan ja tekee transaktiolo­kiin merkityt tietokantatapahtumat uudelleen tietokantaan.

Transaktiolokin lokimerkintä koostuu seuraavista osista:

  • Lokimerkinnän numero (LSN, Log Sequence Number): Jokaisella transak­tiolokin lokimerkinnällä tulee olla uniikki tunnistetieto.

  • Tieto edellisen lokimerkinnän numerosta (LSN), jotta lokimerkintöjen keskinäinen järjestys voidaan selvittää.

  • Tietokantatapahtuman tunnistetieto, jotta tiedetään, mikä tietokantata­pahtuma aiheutti lokimerkinnän.

  • Lokimerkinnän tyyppi, joka kertoo tietokantatapahtuman tyypin.

  • Tieto itse tietokantatapahtuman generoimasta muutoksesta, joka tietokan­taan tehtiin ja jonka vuoksi transaktiolokin merkintä kirjoitettiin.

Esimerkkejä transaktiolokeista ovat erilaiset operatiivisten tietokantajär­jestelmien tietokantalokit, kuten toiminnanohjausjärjestelmien tietokantojen transaktiolokit. Esimerkiksi toiminnanohjausjärjestelmästä voidaan ottaa päi­vittäin täysi tietokantavarmistus. Tämän jälkeen tulee jokaisesta transaktiosta kirjoittaa transaktiolokia varmistuksen jälkeisistä tietokantatapahtumista seu­raavaan täysvarmistukseen asti. Näin ollen tietokanta voidaan päivän aikana palauttaa täysvarmistuksesta ja transaktiolokista takaisin siihen tilaan, missä se oli mahdollisen virhetilanteen tapahtuessa.

Transaktiolokin lisäksi tietokannat pitävät tai voivat[31] pitää muita lokeja. Tyy­pillisesti tietokannat ovat kykeneviä kirjaamaan lokitietoja

  • kirjautumisista ja uloskirjautumisesta

  • tietokantojen käynnistyksestä, uudelleen käynnistämisestä ja sammutta­misesta

  • järjestelmävirheistä ja vioista

  • käyttöoikeuksien muutoksista

  • tietokannan rakenteen muutoksista

  • tietokannan ylläpitäjän toimista[32]

  • tietokannan tietojen luvusta ja muutoksista.

Erityisesti tunnettujen tietokantavalmistajien uusimmat tietokantaversiot sisältävät erittäin kehittyneet loki ja auditointiominaisuudet, jotka eivät kui­tenkaan välttämättä ole oletuksena käytössä. Vanhemmissa tietokannoissa on rajoittuneemmat mahdollisuudet muun muassa tietokannan ylläpitäjien toi­mien seurantaan ja kirjaamiseen sekä tehtävien eriyttämiseen.

Huomioitavaa lokien käsittelyssä:

Jos järjestelmässä käsitellään salassapidettävää aineistoa, myös transaktiolokit tulisi kopioida automaattisesti suojattuun lokipalvelimeen.

Myös luku- ja pääsyvalvontatapahtumista tulee kirjata lokia. Tietokannoissa tapahtumien kirjaamisella lokiin voi olla konkreettiseia vaikutuksia järjestelmän suorituskykyyn. Tämä on huomioitava järjestelmän suunnittelussa.

3.1.8 Muiden lokien käsittelylokit

Muiden lokien käsittelyloki pitää kirjaa siitä, kuka on lukenut, muuttanut, poistanut tai muutoin käsitellyt jotain tiettyä lokitietoa tai lokitiedostoa. Vaa­timus lokienkäsittelyn lokien keräämisestä liittyy erityisesti teleyritysten hal­lussa olevien viestinnän lokien käsittelyyn, mutta hyvin rakennetussa lokiym­päristössä kaikesta lokien käsittelystä pidetään kirjaa ja seuranta on erotettu järjestelmien operoinnista ja ylläpidosta.

Käsittelyloki ei tyypillisesti synny automaattisesti, vaan lokia tuottavan orga­nisaation tulee itse rakentaa sellainen järjestelmä ja lokiympäristö, että tarvit­tava lokienkäsittelyn kirjaaminen ja seuranta on mahdollista.

Sähköisen viestinnän tunnistamistietojen käsittelylokin käsittely on hyvä tehdä erityisesti siihen tarkoitukseen luodulla käyttäjätunnuksella[33]. Nämä tun­nukset tulee myöntää vain rajoitetulle ja nimetylle joukolle ihmisiä. Mahdolli­suuksien mukaan järjestelmien ylläpito tulee erottaa käytön valvonnasta. Lokien sisältämää tietoa voidaan luovuttaa vain Sähköisen viestinnän tietosuojalain 33 § mukaisesti tietyissä tapauksissa ohjaus- ja valvontaviranomaisille. Kaikista tunnistamistietojen käsittelykerroista tulisi tallentaa ainakin:

  • käsittelyn aloitus- ja lopetusaika ja päivämäärä

  • käsittelijän koko nimi tai yksilöllinen käyttäjätunnus, joka on yhdistettä­vissä yksittäiseen henkilöön

  • mitä tunnistamistietoja on käsitelty

  • minkä ajankohdan tunnistamistietoja on käsitelty

  • käsittelyn peruste, eli miksi kyseistä lokia on katsottu tai muuten käsitelty

  • mahdollinen kuvaus käsittelystä.

Huomioitavaa lokien käsittelyssä:

Lokien käsittelyn loki voidaan tuottaa esimerkiksi ohjaamalla tärkeät lokit eril­liseen lokipalvelimeen, jonne kirjaudutaan omalla tunnuksella ja käsittelemällä lokeja omilla tunnuksilla.

3.1.9 Automaattisesti raakalokia tulkiten tuotettu aineisto

Raakalokista tulkiten tuotettu aineisto perustuu olemassa oleviin lokeihin ja lokimerkintöihin ja sitä voidaan pitää raporttina lokeista. Esimerkkejä tällai­sista raporteista on erilaisin analyysimenetelmin muodostetut poikkeavien lokimerkintöjen listat, kuten IDS[34] ja palomuuriraportit. Tällaisten lokitie­dosta muodostettujen raporttien tarkoituksena on etsiä hyökkäykseen viittaa­via ennalta tunnettuja sormenjälkiä. Käyttö ja analysointi tulee olla linjassa lokin keräämistarkoituksen kanssa.

Huomioitavaa raporttien käsittelyssä:

Ylläpitäjän on ymmärrettävä automaattista lokitietojen analysointia suorittavan ohjelman / järjestelmän rajoitukset. IDS-järjestelmä ei pysty havaitsemaan kuin pienen osan poikkeamista. IDS-järjestelmät havaitsevat tapahtumia ennalta määriteltyjen hyökkäyssormenjälkien perusteella. Tosin monet järjestelmät voi­vat tehdä myös heuristista analyysiä tapahtumista ja niiden merkityksestä.

Analysointi tulee perustua lokien alkuperäiseen keräämistarkoitukseen ja olla linjassa tämän kanssa.

Lokien tiivistys on usein tarpeellista valtavan tietomäärän hallitsemiseksi ja tallennustilan säästämiseksi.

3.1.10 Kuormitusraportit

Kuormitusraportti osoittaa määritetyn palvelimen, järjestelmän tai verkon kapasiteetin ja kuormituksen kehityksen. Kuormitusraportteja käytetään nk. pullonkaularesurssien etsimiseen, jotta kapasiteetti ja kuormitus saadaan optimoitua. Kuormitusraportteja käytetään laite- ja verkkoresurssien suunnit­teluun, muutosten tarkistamiseen ja optimointiin sekä kuormantasaukseen[35].

3.1.11 Tilastot

Erilaiset sovellukset (esim. web-sovellukset) keräävät tilastotietoja sovellusten ja sivustojen käytöstä, käyttäjistä jne. Tilastoinnilla selvitetään web-sovellus­ten ja sivustojen käytön määrää ja voidaan esimerkiksi analysoida kävijöiden etenemistä palvelussa, jolloin voidaan optimoida sovelluksen käyttäjäystäväl­lisyyttä ja käytettävyyttä. Tilastointi voidaan toteuttaa muun muassa eväs­teitä[36] hyödyntäen, joiden perusteella käyttäjä tunnistetaan tämän palatessa uudelleen samaan www-palveluun. Näin palvelujen käytöstä saadaan tilas­toja lokianalyysia käyttäen. Näiden tilastojen avulla voidaan suorittaa esim. palvelun käyttäjien tyypittelyä. Lokitietoja analysoimalla voidaan esim. sel­vittää käyttäjien kiinnostusta tiettyihin aiheisiin tai käyttäjien ajankäyttöä palvelussa / sivustolla. Systemaattinen käyttäjien yksilöllinen seuraaminen ja yhdistely henkilötietoihin aiheuttavat henkilön tietosuojan loukkauksen, mutta anonyymissä analyysissä käytettynä tilastojen lokianalyysi on hyödyl­linen tapa www-palveluiden kehittämiseksi.

 

17 Järjestelmälokin tyypistä ja sisällöstä riippuen järjestelmäloki on tyypillisesti virhe tai käyt­töloki.

18 Haltijaloki ilmaisee jonkin tunnisteen haltijan ja on siten käyttöloki.

19 Pääsynvalvontaloki ilmaisee onnistuneet tai epäonnistuneet yritykset käyttää järjestelmän suojattuja resursseja ja on siten käyttöloki. Pääsynvalvontaloki voitaisiin luokitella myös virhelokiksi, koska se ilmaisee virheelliset yritykset käyttää suojattuja resursseja.

20 Media Access Control, verkkolaitteen yksilöivä tunniste. Myös tämä tunniste on väärennettävissä.

21 Dynamic Host Configuration Protocol. Käytetään tyypillisesti vaihtuvien IP-osoitteiden jakamiseen työasemille.

22 MAC-osoitteen ensimmäinen puolisko (6 ensimmäistä merkkiä) osoittaa laitteet, yleensä verkkokortin, valmistajan.

23 Mikäli perusteet selvittämiselle on olemassa.

24 Secure Shell, salattu etäkäyttöprotokolla.

25 Tcp wrapper on pääsynvalvontatoteutus, jonka avulla on laitekohtaisesti mahdollista mää­ritellä, mistä jokin tietty yhteys on sallittua muodostaa.

26 Kuten viranomaisen dokumentin luovuttaminen tai tiedoksi saattaminen.

27 Tämä on tyylillisesti sovelluksen vastuulla. Myös www-palvelinohjelmisto voi kerätä virhelokia, mutta tämän virhelokin merkitys on vähäisempi kuin sovelluksen virhelokin.

28 Yleensä TCP tai UDP portti. Yleensä tietyt palvelut ovat määrätyssä portissa, kuten salaa­maton www-palvelu portissa 80/TCP tai SSH portissa 22/TCP. Sovellusten ei kuitenkaan ole pakko käyttää määritettyjä standardiportteja, vaan ne voivat olla myös järjestelmän rakentajan määräämässä muussa portissa.

29 Esimerkki flow-datasta on Ciscon NetFlow, joka on avoin, mutta tekijänoikeuksin suojattu
protokolla. Siitä ollaan kehittämässä IETF:n standardia; Internet Protocol Flow Information
eXport (IPFIX). Tyypillisesti NetFlow data sisältää tiedot versionumerosta, sekvenssinumerosta,
SNMP liittymätiedot, aikatiedot verkkoliikenteen kestosta, siirretyn datan määrästä,
OSI tason 3 otsikkotiedoista, lähde ja kohde IP osoitteista, lähde- ja kohdeporttiosoitteista,
käytetystä IP protokollasta sekä OSI-tason 3 reititystiedoista.

30 Salassapidettävien tietojen osalta on perustelua kirjata lokiin myös tietojen luku, ei ainoastaan muutokset solujen arvoihin.

31 Tyylillisesti monet tietokannan tietoturvallisuuden ja käytön seurannan kannalta keskeiset lokiasetukset ovat oletuksena pois päältä, jolloin tietokanta pitää vain pakollisia transakti­olokeja, joiden avulla varmistetaan kannan oikea toiminta.

32 Tämä on erityisen tärkeää tietokannan turvallisuuden varmistamiseksi. DBA (tietokannan ylläpitoloki) loki tulee olla suojattu tietokannan ylläpitäjän muutoksilta.

33 Myös tämän tunnuksen tulee olla henkilökohtainen, niin kuin kaikkien muidenkin luotet­tavaan lokiympäristöön liittyvien käyttäjätunnusten.

34 Intrusion Detection System, tunkeutumisen havaitsemisjärjestelmä.

35 Kuormantasauksella tarkoitetaan tietyn tehtävän suorittamisen aiheuttaman kuorman jakamista usealle palvelimelle ja sitä käytetään suurta tehokkuutta vaativissa järjestelmissä sekä toteutuksen mahdollistamiseksi, että kustannustehokkuuden aikaansaamiseksi

36 Cookie eli eväste on dataa, jonka web-palvelin tallentaa käyttäjän tietokoneelle. Selain lähettää evästeet vain kyseiselle palvelimelle. Evästeet ovat ratkaisu HTTP-protokollan tilattomuuteen. Jokainen HTTP-kutsu on täysin riippumaton toisistaan. Tämä vaikeuttaa istunnon seuraamista ja käyttäjän yksilöimistä: Käyttäjätunnus pitää piilottaa piilotettuihin CGI-kutsujen kenttiin. Evästeen avulla palvelin voi tallentaa dataa käyttäjälle joko tilapäisesti kyseisen istunnon ajaksi, tai pitemmäksi aikaa.

Vahti- ylläpito08.10.2009 / 10:34:02
Tulosta