TTKK / J.Koskinen / Tietoturvallisuuden perusteet, 2002

Tietokannat

Sisältö: Tietokantojen turvaongelmia ja -tavoitteita; [1] Tietokantojen turvamekanismeja; [2] Monitasoisen tietokannan turvallisuus

Tietokantojen turvaongelmia ja -tavoitteita

Motivointia
Monet tietoturvan yhteydessä esille tulevat kohteet ovat jossain määrin "hajallaan": tiedostot, ohjelmat, viestit, transaktiot tai kokonaiset organisaatiot. Tietokanta on ainakin loogisessa katsannossa melko yhtenäinen ja selvärajainen kohde. Siitä pitää huolta hallintajärjestelmä (DBMS), jonka kautta käyttäjä on yhteydessä siihen, olipa itse tieto sitten tallennettu mihin järjestykseen ja miten hajautetusti hyvänsä. Voidaan siis pitkälti keskittyä siihen, millainen turvallisen hallintajärjestelmän pitäisi olla (ja miten sitä pitäisi käyttää).
Tämän jakson esitys soveltuu osittain myös sellaisiin tietojoukkoihin, joita ei yleensä mielletä tietokannoiksi. Tällaisia ovat koneen käyttäjäluettelo, pääsynvalvonnan tiedostot, verkonhallinnan informaatiokanta MIB, nimipalvelimen tiedot, reitittimen tiedot jne. Osa näistä kuuluu hakemistopalveluihin. Sellaisten merkitystä korostetaan artikkelissa Risky Business. (Netw.Mag Nov/Dec 2000), josta on seuraava lainaus: "Directory services have become vaults for increasingly sophisticated and valuable data, meaning threats to that data's security are inherently more serious. The answer is proactive security planning."

Sisältöä ja tavoitetta
Tällä sivulla esitellään tietokannoille ominaisia turvaongelmia ja tietokantojen yleiset turvallisuustavoitteet.
Tavoitekysymyksiä tulee paremmin esille tietokantojen turvamekanismien yhteydessä. Tenttitehtävän osana on esiintynyt tällainen:

Millä tavoin päättely voi olla tietoturvaongelmana tietokannoissa?

Tietokannoille ominaisia turvaongelmia

Harjoitus. Jokainen on tekemisissä niin monien tietojärjestelmien kanssa, että on helppo keksiä erityyppisiä esimerkkejä tietokannoista, jotka ovat tärkeitä yrityksissä tai julkishallinnossa. Näin tehdessäsi mieti niissä olevan tiedon luonnetta: Mistä ja miten se tulee kantaan, miten ja millä perusteilla sitä muutetaan ja kuka sitä tarvitsee ja saa käyttää? Tuleeko mieleesi tapauksia, joissa tieto on ollut väärää tai puutteellista? Entä millaisissa tilanteissa arkoja tietoja on voinut tai voisi päästä vääriin käsiin ilman, että varsinaisesti olisi tapahtunut mitään murtoa?

Laitteiston särkymisen, tavanomaisen kaatumisen ja muiden fyysisten seikkojen lisäksi kirjoitus tai sen puuttuminen voi aiheuttaa seuraavanlaisia eheysongelmia:

vahingossa väärät syöttötiedot: kerätty, laskettu tai vain kirjoitettu väärin;
asiattomien tekemät tahattomat tai tahalliset virheet;
saman tiedon ristiriitaiset tai toisteiset ilmentymät (esim. kun kannan tietoja koostetaan eri lähteistä);
eri tahoilta tulevat samanaikaiset muutokset (esim. lukumäärätietoon, jonka lähtöarvon kumpikin on lukenut ennen muutosta).

Lukeminen tuottaa ongelman luottamuksellisuuden suhteen lähinnä sellaisissa tietokannoissa, joissa osa tiedoista on julkisia ja osa täytyy suojata sivullisilta. Jos kaikki tieto olisi samaa lajia, voitaisiin koko järjestelmä hallita kyseisen lajin mukaisin keinoin ja ongelmia olisi korkeintaan käyttöjärjestelmän tasolla.

Arkaluonteinen tieto voi tietokannassa ilmetä yksinkertaisimmillaan siten, että jotkin tietueet tai jotkin kentät ovat luottamuksellisia. Arkojen tietojen paljastumista ei aina saisi tapahtua edes osittain. Tiedosta tai sen luonteesta voi kertoa liikaa esimerkiksi

arvon vaihteluväli tai todennäköisyys jollekin arvolle;
olemassaolo tai -olemattomuus (rikosrekisteri, jokin kenttäotsikko tietueessa, tai yhtä hyvin: sejase ei ole käyttäjänä tietyssä koneessa);
komplementtitieto (attribuutin arvo ei ole jokin).

Tässä tullaan osittain jo päättelyprobleeman alueelle: Erityisongelma tietokannoissa ovat nimittäin päättelyt tietoja yhdistelemällä: luottamukselliseen tietoon voidaan päästä käsiksi useiden vähemmän arkojen tietojen perusteella tyypillisellä "salapoliisin työllä". Erityisesti yhteenvetotiedot, kuten lukumäärät ja keskiarvot voi olla luokiteltu vähemmän aroiksi, samoin sellaiset näkymät, joissa luetellaan kaikista tietueista vain jokin kenttä.

Esimerkki: Opiskelijoiden yksityisyyttä voidaan suojella julkaisemalla tenttituloslistoissa ainoastaan opiskelijanumerot ilman nimiä. Karkea virhe olisi tällöin päästää ketään asiatonta käsiksi luetteloon, jossa on sekä nimet että numerot. Toisaalta kursseista voi olla nimet sisältäviä ilmoittautumislistoja tms. Yhdistämällä riittävän paljon eri kurssien tietoja on mahdollista laatia tällainenkin luettelo. Käytännössä tämä vaatisi tietysti paljon enemmän työtä kuin ihmisiltä kyselemällä saada selville, kuka mitäkin sai tentistä.

Eri tietokannoista tehtävät yhdistelmät ovat vain hieman eri asia, mutta paljon hankalampi, eikä siihen mennä syvemmälle. Aihetta sivutaan tietosuojan yhteydessä, henkilörekisterien tapauksessa. Pieniä tiedonpaloja yhdistelemällä tehtävät päättelyt tulevat esille myös www-pipareiden yhteydessä. Yhdistelmien ongelmallisuutta lisää se, että joissain tapauksissa arkaluonteiset päätelmät saattavat olla mahdollisia hyvinkin pitkällä aikavälillä kerätyn aineiston perusteella.

Tietokantojen yleiset turvallisuustavoitteet

Fyysinen eheys: koskee laitteistoa ja sitä että ainakin tietyntasoisista vahingoista voidaan toipua, edellyttää normaalia varmuuskopiointia osana käyttöjärjestelmän toimia. Tästä ja fyysisestä turvasta yleisesti lisää jäljempänä.
Looginen eheys: rakenteen säilyminen eheänä, erityisesti viittaukset ja tietojen vaikutus toisiin tietoihin.
Tietoalkioiden eheys ja oikeellisuus.
Toimijoiden vastuullisuus: mahdollisuus jäljittää, ketkä ovat käyneet kohteissa tai muuttaneet niitä.
Pääsynvalvonta (kuten yleensäkin:) tietyt henkilöt vain tiettyjä toimia vain tietyille tiedoille.
Käyttäjien autentikointi, mahdollisesti vielä sen lisäksi, mitä käyttöjärjestelmän puitteissa on tehty.
Käytettävyys: tietokannan yleinen ja pääsynvalvonnan mukainen saatavillaolo.

Eheyden ja luottamuksellisuuden mekanismeja tietokannoissa

Motivointia
Tietokantaohjelmistoissa on toteutettu enemmän tai vähemmän täydellisesti ja tehokkaasti tässä esiteltävän kaltaisia turvamekanismeja. Ohjelmistoa valittaessa on hyvä tietää, millaisiin turvaominaisuuksiin kannattaa kiinnittää huomiota. Vastaavanlaisia mekanismeja voi tarvita myös muunlaisissa sovelluksissa, myös sellaisisssa, joita itse mahdollisesti suunnittelee tai ohjelmoi.

Sisältöä ja tavoitetta
Tässä esitetään melko luettelomaisesti useita turvamekanismeja yhtäältä eheyden ja toisaalta luottamuksellisuuden turvaamiseen. Lisäksi käsitellään monitasoisen tietokannan ongelmaa.
Tavoitekysymyksiä:

Missä suhteessa tietokannan eheyttä voidaan ylläpitää samoilla mekanismeilla kuin yleensä tiedostojärjestelmän eheyttä? Missä suhteessa tietokanta vaatii erityisjärjestelyjä? Mainitse kaksi sellaista.

Eheyden turvaamisessa tiivistefunktiolla on tärkeä merkitys. Mikä on yleinen periaate ja miten sitä sovelletaan tilanteeseen, jossa tiedon pitäisi säilyä muuttumattomana (a) tietyssä paikassa, (b) talletettaessa sitä tiedostoon tai tietokantaan, (c) vastaanotettaessa sitä esim. tietoverkon kautta siten, että sen sisältöä ei etukäteen tunneta?

Keksi esimerkki tietokannasta, jossa yhtäältä joudutaan vastaamaan kyselijälle mutta toisaalta joudutaan pimittämään jotain samalta henkilöltä. Mainitse kolme mekanismia, joilla pimitystä voidaan toteuttaa.

Havainnollistusta
Eheys on keskeinen tavoite tietokannoissa. Otetaan tässä sen vuoksi esille muutama yleisempi näkökulma asiaan sekä yksi havainnollistus, joka sekään ei suoraan liity tietokantoihin.
Yleisen kahdennuksen tai varmuuskopioinnin lisäksi särkynyttä eheyttä voidaan paikata seuraavanlaisilla menetelmillä, kunhan ne ovat käytössä ennen kuin vahinkoja tapahtuu:

Versionhallinta (dokumenttien ja varsinkin ohjelmien kehittelyssä; ei ole käsitelty erikseen).
Aikomus-päätös-menettely ja muutosloki tietokantojen yhteydessä.
Yleisempi lokitieto (käyttöjärjestelmien yhteydessä).
Tiedostojen monivaiheinen hävittäminen: välivaiheena roskakori, joka tyhjennetään erikseen myöhemmin.
Tekstidokumenttien muutosloki, joka talletetaan dokumenttiin itseensä. Undo-toiminnolla voidaan palata taaksepäin. Vastaava toiminto on hyödyllinen monenlaisissa suunnittelu-, piirto-, taulukko-ohjelmissa yms. Automaattinen varmennustallennus eri tiedostoihin on myös tavallinen mekanismi, mutta se voidaan lukea yleisemmän kahdennuksen piiriin.
Tutustu, millaisia tietoja Wordin tai vastaavat ohjelmat tallettavat dokumentin lisäksi samaan tiedostoon, ja mieti millainen tietoturvauhka niistä voi muodostua. Katso tähän liittyvää varoittavaa esimerkkiä. Mihin ylläolevista kohdista tämä liittyy?

Yhteyksiä
Katso joitakin yhteyksiä kohdasta Havainnollistusta.

Eheyden ja luottamuksellisuuden mekanismeja tietokannoissa

Tietokantojen turvamekanismien pitää yleensä olla hienojakoisempia kuin käyttöjärjestelmän tarjoamat, sillä nämä eivät ylety tekemään erotteluja tiedostojen sisällä. Tietokannassa taas jokainen tietue voidaan joutua ottamaan huomioon erikseen. Sellaisena ongelma on kuitenkin samantapainen kuin tiedostoissa. Miten suojeltava kohde sitten rajataankin, eri toimijoiden erityyppiset oikeudet siihen pitää määritellä ja panna toimeen pääsynvalvonnan tekniikoilla.

Eheysmekanismeja tietokannoissa

Seuraavassa on lueteltu useita mekanismeja, joilla voidaan edistää tietokannan säilymistä eheänä. Kannattaa huomata, että useimmat näistä on tarkoitettu vahingossa tapahtuvien eheysrikkeiden torjumiseen.

Eheyden tarkistus kenttiä syötettäessä: joko
- kenttäkohtaisesti asetetun ehdon perusteella, esim. arvon oltava numeerinen joltain väliltä, päivämäärä, tai sen on täytettävä jokin sanastollinen ehto; tai
- kokonaisuuden perusteella. Yksinkertaisimmillaan avaimeksi määritellyn kentän pitää olla erisuuri eri tietueissa, tai tietynlaisten tehtävänimikkeiden kohdalla palkalla on tietyt rajat. Tällaisten yhtä tilaa koskevien rajoitusten ohella voidaan rajoittaa tilasiirtymiä, eli tietojen muutokset voivat edellyttää joitain alkuehtoja ja/tai joitain muita muutoksia (esim. tilausrajan alitus aiheuttaa tilauksen, joka pitää merkitä tietokantaan).
Tällaisissa on yhtäältä kyse siitä, miten tietokannan eheys on määritelty (siis tavallaan tietoturvapoliittinen kysymys), ja toisaalta miten hallintajärjestelmä pystyy ottamaan kaiken huomioon.
Kaksivaiheinen päivitys: aikomus ja päätös ('commitment'). Yksinkertaisesti tulkittuna tämä on varsin yleinen turvamekanismi ja sopii moneen yhteyteen. Esimerkiksi tiedostojen tuhoamisessa voidaan tehdä ensin 'delete' tai 'remove' roskakoriin ja vasta eri komennolla 'expunge', 'purge' tai 'empty', jolla kori tyhjennetään.
Tietokannan tapauksessa on usein kyse siitä, että niputetaan monivaiheinen kokonaisuus (transaktio), jossa toimen keskeytyminen tai muiden väliintulo voisi särkeä eheyden. Tällöin aikomusvaiheessa tehdään tarvittavat valmistelut (tiedoston avaukset, toisten sulkeminen pois samalta alueelta, ...), kerätään kaikki tarpeellinen tieto ja tehdään laskutoimet, mutta ei vielä muuteta mitään. Päätöksen jälkeen nostetaan "commit"-lippu ja kirjoitetaan sen suojissa uudet arvot. Jos tämän aikana tulee keskeytys, kirjoitus voidaan toipumisen jälkeen tehdä kokonaan uudestaan. Lopuksi lasketaan lippu.
Aikomusvaihe kuvaa tietokannan hallintajärjestelmän toimia eikä esim. matkatoimiston käyttöliittymän ääressä tehtyä pohdintaa: Siinä vaiheessa, kun esim. paikkavaraus varsinaisesti aiotaan tehdä, hallintajärjestelmä estää muita edes lukemasta samaa tietoa ja jos tieto mahdollistaa varauksen (eli paikka tosiaan on vielä vapaa), aikomusvaihe pääsee eteenpäin.
Muutosloki, eräänlainen "on-line backup", joka mahdollistaa "undo"-toiminnon, eli tehtyjen muutosten peruuttamisen - enemmän tai vähemmän pitkälle historiaan. Mekanismi on tuttu monista tekstureista, mutta sitä voi soveltaa laajemminkin jolloin peruuttaminen on mahdollista myös täysimittaisen vahingon jälkeen - vaikka sitten varmuuskopion ja paperilla olevan lokin avulla.
Muu redundanssi: muutoksen kohteena olevan tietokantataulun tai tiedoston alkuperäinen versio voi olla kopioituna levyllä, kunnes suoritetaan talletus tai operaatio on kokonaan valmis. Operoinnin aikana voidaan myös säännöllisin väliajoin tehdä varmistustalletuksia rinnakkaiseen tiedostoon, joka istunnon päätyttyä joko hävitetään tai jätetään. Tällaista redundanssia voi kutsua varjotiedoksi.
Kirjoitusoikeuden rajoitukset voidaan joutua erittelemään tarkemmin kuin yleensä tiedostoissa: mahdollisia vakiotoimiahan ovat tietueen lisääminen tai poistaminen, vanhan tiedon muuttaminen tai pelkkä uuden liittäminen jatkoksi. Rakenteen muuttaminen esim. lisäämällä uusia kenttä tai poistamalla vanhoja ei yleensä kuulu tavallisen käyttäjän toimiin, eivätkä myöskään pääsyoikeuksien muutokset.

Tietokantoihin keskittyvillä kursseilla esitellään lisäksi oikeaoppisia relaatiotietokannan rakenneperiaatteita, joilla edistetään mm. eheyden säilymistä. Niiden huomioiminen on hyvän ohjelmoinnin periaatteisiin rinnastettava perusedellytys em. eheysmekanismien hyödyllisyydelle. Yksi näiden ns. normalisointivaiheiden tavoitteita on redundanssin vähentäminen tietokannasta, mutta siinä on siis kyse eri tason asiasta kuin edellä mainitussa redundanssin lisäämisessä.

Luottamuksellisuuden tavoittelua tietokannoissa

Tavanomaisten pääsynvalvonnan ja sitä edeltävien autentikoinnin mekanismien lisäksi voidaan soveltaa seuraavanlaisia "päättelyn kontrollin" menetelmiä:

suppean aineiston sääntö: kysely hylätään jos tulos (esim. lukumäärä) perustuisi hyvin pieneen määrään tietueita, jotka kuitenkin muodostavat suuren osan jonkin laajemman ehdon mukaisista tietueista (joka saataisiin esim. jättämällä jokin "ja"-ehto pois). Vastaava sääntö koskee yleisemminkin tilastoaineistoista julkaistavia raportteja.
tulosten yhdistelmät: hylätään kysely, jos sen tuloksena olevien tietueiden joukko on suurelta osin (mutta ei tarkkaan) sama kuin edellisellä kerroilla.
satunnaisotos, josta kyselyn tulokset muodostetaan (suuren tietokannan tapauksessa).
vaihteluvälien ilmoittaminen tarkkojen arvojen sijasta.
satunnainen muuntelu, perturbaatio, jolla tietoa hieman vääristellään mutta tulos on silti suuntaa-antava.
kyselyanalyysi: Tietokantapalvelin voi pitää kirjaa käyttäjän aiemmista kyselyistä (jopa aiemmilla käyttökerroilla) ja laskea, voiko se enää vastata uusiin kyselyihin antamatta käyttäjälle tilaisuutta tehdä yhdistelmiä, johon tällä ei ole oikeutta. Ymmärrettävästi tätä on kuitenkin erittäin vaikea toteuttaa.

Jos jokin tietue halutaan pitää salaisena, mutta toisaalta siinä on tietoja, joiden pitäisi olla julkisia (esim. epäluulojen välttämiseksi), voidaan tehdä kaksi tietuetta, joista toinen sisältää kaikki tiedot ja toinen vain sen mikä voidaan näyttää julkisesti. Tempun tekninen nimi on "polyinstantiation". Tällainen toisteisuus voi olla myös haitallista ja sellaiseen voidaan joutua, kun alemmin oikeuksin varustettu toimija lisää jonkin tiedon, joka kuitenkin on jo kannassa mutta ylemmässä turvaluokassa ja siksi häneltä näkymättömissä. Tämä on yksi esimerkki monitasoisen tietokannan ongelmista.

Monitasoinen tietokanta

Turvaluokitukseltaan monitasoista tietoa sisältävässä tietokannassa voidaan soveltaa edellä kuvattujen menettelyjen sijasta tai lisäksi esim. seuraavia. Näistä kaksi ensimmäistä edustavat pääsynvalvonnan yhteydessä mainittuja fyysistä ja kryptograafista erottelumekanismia ja lopuilla pyritään loogiseen erotteluun ja siihen, että käyttäjän kannalta tietokantaan säilyisi yhtenäinen näkymä - ikäänkuin häneltä kiellettyjä tietoja ei olisikaan.

Jaetaan kanta yksinkertaisesti turvaluokituksen mukaisiin erillään toimiviin osiin - kovin kankea järjestely, mutta joissain tapauksissa mahdollinen.
Salataan arat tiedot. Jos tietyllä turvaluokalla on yksi ja sama avain, alemman luokan käyttäjä saattaa yrittää valitun selvätekstin hyökkäystä tallettamalla itseään kiinnostavan tietoalkion ylemmälle tasolle. Tämän jälkeen hän pystyy kääntämään tuloksena olevan kryptotekstin missä muualla se esiintykään. Tämä ongelma voidaan torjua muuntelemalla avainta vaikkapa tietueen avainkentän perusteella tai ketjuttamalla tietueen kenttien salaus CBC-moodin tapaan. Joka tapauksessa ongelmana on kyselyiden toteuttamisessa vaadittava alituinen dekryptaus.
Jokaiseen tietueeseen tai jopa kenttään asennetaan (eheys- tai arkuus-)lukko, joka vastaa dokumentin turvaleimaa. Lukkoa käsittelee luotettu pääsynvalvontajärjestelmä, jonka kautta tavallinen tietokantajärjestelmä käsittelee kantaa. Jotta lukkoa ei voi kopioida toiseen paikkaan eikä väärentää, sen osana on tarkistussumma, joka on laskettu salaisella avaimella tietuenumerosta, turvaleimasta ja tiedosta, jota itseään ei tarvitse salata.
Asetetaan tietokantaohjelma luotettavan käyttöliittymän eli vahdin ('guard') ja luotettavan pääsynvalvontajärjestelmän väliin. Vahti tarkistaa kyselyä lähettäessään käyttäjän oikeudet ja tuloksia vastaanottaessaan niiden luvallisuuden ja suodattaa tarvittaessa. Jos vahti suodattaa myös toiseen suuntaan eli muokkaa kyselyä, puhutaan kommutatiivisesta suodattimesta. Yleisemminkin, jos tietokantaohjelma suunnitellaan alusta pitäen ottamaan turvallisuus huomioon, siitä tulee luontevasti monikerroksinen - itse tietokanta ytimenä ja käyttöliittymä päällimmäisenä.
Tietokannan hallinta voidaan jakaa kahden tavallisen tietokantaohjelman vastuulle siten, että toinen käsittelee alempien tasojen ja toinen ylempien tasojen tietoja. Luotettu käyttöjärjestelmä toimii näiden molempien ja käyttäjän välissä. Järjestelmää voidaan toteuttaa joko ajamalla kahta tietokantaohjelmaa samassa koneessa ("fragmented architecture") tai eri koneissa ("replicated architecture").