Käyttöjärjestelmistä tietokantoihin (syventävä)

Käyttöjärjestelmän ja hypervisorin hallinnoivan ja välittävän roolin kautta on helppo ymmärtää, että vastaavia tietoturvaongelmia ja ratkaisuja esiintyy myös muilla aloilla. Näistä keskeisin ovat tietokannat, joissa turvallisuus noudattaa samanlaisia periaatteita kuin käyttöjärjestelmissä.

Tietokantojen olemuksesta (syventävä)

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, database management system), 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ää).

Tietokantojen turvaominaisuudet soveltuvat osittain myös sellaisiin tietojoukkoihin, joita ei yleensä mielletä tietokannoiksi. Tällaisia ovat tietokoneen käyttäjäluettelo, pääsynvalvonnan tiedostot, verkonhallinnan informaatiokanta (MIB, mgmt information base), nimipalvelimen tiedot, reitittimen tiedot jne. Osa näistä kuuluu hakemistopalveluihin. Ne ovat nimensä mukaan tietokantoja, joista enimmäkseen haetaan ja harvemmin päivitetään (tai harvemmat päivittävät).

Tietokantojen yleiset turvallisuustavoitteet ovat:

• Fyysinen eheys: koskee laitteistoa ja sitä että ainakin tietyntasoisista vahingoista voidaan toipua, edellyttää normaalia varmuuskopiointia osana käyttöjärjestelmän toimia.
• Looginen eheys: rakenteen säilyminen eheänä, erityisesti viittaukset ja tietojen vaikutus toisiin tietoihin.
• Tietoalkioiden eheys ja oikeellisuus, esim. päivämäärä on oikeaa muotoa ja oikea.
• 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ä käyttöjärjestelmässä tehdyn lisäksi.
• Saatavuus: tietokannan pääsynvalvonnan mukainen saatavillaolo. Sen perustana omalla tasollaan on se, että kanta on käynnissä ja siihen saa yhteyden.

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, esim. kyselyjen SQL-kielessä (Structured Query Language).

Kyselyt muodostavat yhden tavallisimmista uhkista, jos käyttöliittymä (esim. www-lomake) ei suodata syötteitä. Datan sijasta hyökkääjä voi onnistua syöttämään SQL-lausekkeita. Tuloksena on SQL-injektio ja sen kautta mahdollisesti vapaa pääsy tietokantaan tai sen kautta muualle koneeseen tai verkkoon, jossa tietokanta sijaitsee (tai pelkkä tuho; sqlmap automatisoi injektioiden etsinnän; SQL- ja muista injektioista ks. myöhempi luku). Tässä suhteessa tietokannan pääsynvalvonta on paljon monimutkaisempaa kuin tiedostojen. Toisaalta tietokantoja palvelinohjelmistoineen (ja haavoittuvuuksineen) ilmenee osana monia sovelluksia (esim. kuva-arkistointi) ilman, että asentaja aina oivaltaa sitä — vähän samaan tapaan kuin sovelluksilla on tapana luoda omaan käyttöönsä liuta hakemistoja ja tiedostoja. Tietokantoja voi olla myös ohjelmien sisäisiin tarkoituksiin, mutta usein tietokannat sisältävät nimenomaan käyttäjien arvokasta dataa.

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).

Tietokannan eheyden varmistamiseksi tarvitaan hallintajärjestelmän toimia, ks. jäljempänä. Luottamuksellisuus on sen verran ilmeinen tarve, että sitä ei edes mainittu erikseen eo. luettelossa, vaan sen saavuttaminen sisältyi pääsynvalvontaan ja autentikointiin. Se ei kuitenkaan riitä, sillä luottamuksellisuuden ongelmat voivat olla hyvinkin vaikeita. Jatketaan ensin niistä.

Luottamuksellisuus (syventävä)

Tietokannan luottamuksellisuudessa on kolme näkökulmaa:

• yläpuolinen: miten päästetään kantaan vain ne, joilla on oikeus. Tämä ongelma on yksinkertaisin ja ratkeaa normaalilla pääsynvalvonnalla, joka voi eriyttää myös kannan sisäisiä osia, kuten tauluja. Luonnollisesti tällä “kantaan päästämisen” tasolla pitää torjua myös injektiohyökkäykset.
• sisäinen, erotteleva: miten osa tiedoista (erityisesti yhteenvetoina) voidaan tarjota laajemmalle käyttäjäkunnalle kuin jokin toinen osa.
• alapuolinen: miten vakuututaan siitä, ettei tieto vuoda tiedosto- ja käyttöjärjestelmän tasolla.

Sisäinen, erotteleva näkökulma

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 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ä.

Eri tietokannoista tehtävät yhdistelmät ovat vain hieman eri asia, mutta paljon hankalampi, eikä siihen mennä syvemmälle. Aihe on silti tärkeä henkilörekistereissä ja selittää GDPR:n tiukat säännöt niistä. Tiedonpaloja yhdistelemällä tehtävät päättelyt voivat tulla esille myös www-evästeiden tapauksessa. Yhdistelmien ongelmallisuutta lisää se, että joissain tapauksissa arkaluonteiset päätelmät saattavat olla mahdollisia hyvinkin pitkällä aikavälillä kerätyn aineiston perusteella.

Miten arkuudeltaan erilaisia kyselytuloksia pystytään käsittelemään eri tavoin? Tavanomaisten pääsynvalvonnan ja sitä edeltävien autentikoinnin mekanismien lisäksi voidaan soveltaa seuraavanlaisia “päättelyn kontrollin” menetelmiä, joista osa (sekä muutama erilainen) on esillä myös henkilötietojen hämärryttämisen yhteydessä

• suppean aineiston sääntö: kysely hylätään jos tulos (esim. summa) perustuisi hyvin pieneen määrään tietueita (esim. alle kuuteen joissain terveystietokannoissa). Tästä säännöstä on edistyneempi versio, ns. (n,k)-sääntö: kysely hylätään, jos enintään n tietuetta tuottaa vähintään k % kyselyn tuloksesta. Tyypillisiä arvoja ovat n=3 ja k=70. Tällaiset säännöt koskevat 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. Jos tällaiset kyselyt voitaisiin tehdä, niin niiden yhteisen osan vaikutus saattaisi olla mahdollista poistaa, ja jäljelle voisi jäädä liian suppea aineisto.
• satunnaisotos, josta kyselyn tulokset muodostetaan (suuren tietokannan tapauksessa).
• vaihteluvälien ilmoittaminen tarkkojen arvojen sijasta: itse tuloksessa (esim. keskiarvossa) tai tuloksen luokittelussa (ikävuosittaisen lukumääräjakauman sijasta viiden vuoden välein).
• satunnainen muuntelu, perturbaatio, jolla tietoa hieman vääristellään mutta tulos on silti suuntaa-antava. Voidaan pyrkiä käyttämään samanlaista muuntelua eri kerroilla, jotta tulosta ei saataisi tarkennetuksi usean kerran keskiarvona.
• 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.

Esimerkiksi VRK:n sukunimihaku näyttää haetun nimen esiintymisestä vain kokonaismäärän eikä esim. sukupuolijakaumaa, jos nimiä on vähän (esim. 7). Kokonaismääräkin voidaan hämärryttää: esim. nimiä Bobrikov ja Putin oli Suomessa vuonna 2022 kumpiakin, mutta “alle 5”.

Tietokannan alapuolinen näkökulma

Vaikka tietokantatason pääsynhallinta rajoittaa, kuka saa pääsyn mihinkin tietokannan osiin, se ei estä pääsyä levyllä oleviin tietoihin käyttöjärjestelmätasolla. Tästä syystä monet DBMS:t tukevat taulun arkojen tietojen (jonkin sarakkeen eli kentän alkiot) salausta levyllä. Avaimet voidaan tallentaa myös tietokannan ulkopuolella olevaan moduuliin. Äärimmäisessä tapauksessa tietokannan tiedot voivat olla salattuja, ja vain käyttäjillä on avaimet.

Salattujen tietojen kysely on vaikeaa. Vaikka on kehittyneitä kryptografisia ratkaisuja, kuten homomorfinen salaus, ne ovat kalliita. Yleensä käytetään vain yksinkertaisia ratkaisuja. Jos jokin kenttä on salattu, sen käyttö hakuehdossa toimii tietysti suoraan, jos haetaan tarkkaa yhtä arvoa. Silloin kantaan kohdistuva hakuehto sisältää salatun arvon. Jos taas haetaan arvoja, jotka ovat jotain rajaa pienempiä, pitää DBMS:n lukea ja purkaa kaikki, jotta vertailu on mahdollinen. Salattujen tietokantojen kyselyongelma on aktiivinen tutkimusala.

Asiat muuttuvat monimutkaisemmiksi, kun organisaatiot ulkoistavat tietohallintansa ulkopuolisille palveluntarjoajille. Tiedon omistaja luo ja päivittää tiedot ulkoisessa tietokannassa, joka käsittelee asiakkaiden kyselyt. Tähän asti esillä olleiden haasteiden lisäksi tulee uusia, ja ohi pelkän luottamuksellisuuden. Voidaanko luottaa, että palveluntarjoaja toimittaa kyselyihin aitoja, eheitä ja tuoreita tuloksia? Eheyteen ja aitouteen voi vaikuttaa allekirjoitusten avulla, tarkkuuden ja kuormituksen vaihdellessa hienojakoisuuden mukaan. Kehittyneemmätkin tietorakenteet ovat mahdollisia, kuten Merklen hash-puut. Jos allekirjoitukset ovat tarpeen vähäisen luottamuksen (trust)takia, luottamuksellisuudelle (confidentiality) ei ole perusteita, sillä palveluntarjoaja näkee sekä asiakkaiden kyselyt että niiden vastaukset.

Eheys (syventävä)

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 ('intent & commitment'). Yksinkertaisesti tulkittuna tämä on varsin yleinen eheysmekanismi.

  Tietokannan tapauksessa on usein kyse siitä, että niputetaan monivaiheinen kokonaisuus (transaktio), jossa toimen keskeytyminen tai muiden väliintulo voisi särkeä eheyden. Aikomusvaiheessa, mikäli kukaan muu ei ole varannut kohteita omille aikomuksilleen,

  • tehdään tarvittavat valmistelut: tiedoston avaukset, muuttujien tilanvaraukset, ...
  • kerätään kaikki tarpeellinen tieto ja tehdään laskutoimet, merkitään oma aikomusbitti tietokannan muutettaviin kohteisiin mutta ei vielä muuteta mitään.
  • jos aikomusbitti saatiin kaikkiin tarvittaviin paikkoihin, siirrytään päätösvaiheeseen nostamalla ne lukitusbiteiksi.
  Päätösvaiheessa kirjoitetaan uudet arvot, tehdään lokimerkinnät ja vapautetaan lukitukset. Jos aikomusvaiheen aikana tulee keskeytys, tietokanta on säilynyt eheänä ja vaihe voidaan uusia. Jos päätösvaihe keskeytyy, ongelmia voi tulla, mutta ne voidaan oikaista tekemällä kaikki kirjoitukset uudestaan.

  Aikomusvaihe (=myös vaatimusvaihe, request phase) 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ä voi aikomusbitin avulla ankarimmillaan estää muita edes lukemasta samaa tietoa ja jos tieto mahdollistaa varauksen (eli paikka tosiaan on vielä vapaa), aikomusvaihe pääsee eteenpäin. Toisaalta aikomusbitin riittää vain estää toisia aikomasta. Vielä lievempi ratkaisu on optimistinen muuttaminen, joka peruutetaan, jos tietuetta on joku muu muuttanut oman lukemisvaiheen jälkeen.

  Lukituksia voidaan luonnollisesti rakentaa eri tasoille: kanta, sivu (käyttöjärjestelmän tallennusyksikkö) tai taulu, tietue ja kenttä. Kuorma kasvaa ja joustavuus paranee, kun tässä listassa edetään.

• 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, jolloin uusi versio korvaa vanhan. Tätä voi kutsua "varovaisen korvaamisen menetelmäksi".
  • Operoinnin aikana voidaan 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. Lähes reaaliaikainen peilaus (pysyvään kantaan) on yksi mahdollisuus, mutta jollei viivettä ole, eheyttä ei voi paikata kuin laiterikkojen ja vastaavien katkojen tapauksessa. Viivettä saadaan aikaan lokitiedoilla, joiden perattu versio vasta ajetaan varjokantaan esim. kerran päivässä.
  • Päivityksen kohteena olevia työtiedostoja voi olla useitakin. "Varjon" sijasta niissä (eikä itse kannassa) onkin tuoreimmat versiot, joista viimeisin vain aika ajoin yhdistetään kantaan. Kyseessä on "differentiaali-menetelmä" sikäli että se toimii ikään kuin differentiaalinen varmuuskopio, joka ottaa huomioon kannan rakenteen. Tällainen järjestely voi olla muutoslokinkin takana.

• 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 (esim. JY 2002) 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ä. Turvalliseen ohjelmointiin liittyy myös tietokantaan syötettävän tiedon sanitointi.

SQL (syventävä)

Tietokantojen käyttöliittymät ovat usein hyvin korkealla abstraktiotasolla, esimerkiksi www-lomakkeina. Niiden taustalla on useimmiten relaatiotietokannan käyttökieli SQL, Structured Query Language. Nimestään huolimatta se ei ole pelkästään kyselykieli, vaan se sisältää kaikki tarvittavat operaatiot tietokannan luomisesta alkaen.

SQL:n turvamalli sisältää normaalit pääsynvalvonnan osat:

• toimijat: heillä on käyttöjärjestelmän suorittaman autentikoinnin perusteella käyttäjätunnukset, mutta tietokanta voi myös sisältää oman autentikoinnin.
• toimet: SELECT, UPDATE, DELETE, INSERT ja muita erikoisempia toimia.
• kohteet: taulut ja näkymät sekä näiden sarakkeet eli kentät (tai attribuutit). Lisäksi on muuntyyppisiä kohteita.

Kun käyttäjä luo kohteen, hänestä tulee sen omistaja, ja alunperin vain hänellä on siihen pääsy. Muille käyttäjille pitää tarpeen mukaan myöntää pääsy (privilege), joka voi sisältää delegointioikeuden. Käyttäjistä voidaan muodostaa ryhmiä, joihin oikeudet liitetään.

Oikeuden myöntäminen ja peruminen tapahtuvat GRANT- ja REVOKE-operaatioilla tähän tapaan:

GRANT SELECT, UPDATE (sarake3), INSERT
   ON TABLE taulu
   TO aino, bertil
   WITH GRANT OPTION

Jos jokin tässä myönnetyistä kolmesta oikeudesta perutaan, järjestelmän pitää perua oikeudet myös niiltä, joille käyttäjä aino tai bertil ovat niitä myöntäneet (tätä varten revoke-operaatiolla on cascade-määre, joka on oletusarvo). Eri kerroilla myönnetyt oikeudet tulevat entisten lisäksi. Nimi PUBLIC tarkoittaa kaikkia käyttäjiä, myös myöhemmin mukaan tulevia. Käyttäjien oikeudet tallennetaan mysql-nimisen tietokannan user-tauluun.

Näkymät ovat olemassa olevien taulujen (relaatioiden) johdannaisia. Sellaisia muodostetaan tähän tapaan:

CREATE VIEW maisema AS
   SELECT sarake2, sarake3 FROM taulu
   WHERE sarake1 > 0
   WITH CHECK OPTION

Tähän näkymään voitaisiin nyt myöntää oikeuksia aivan samoin kuin edellä, mutta INSERT-oikeus ei olisi järkevä, koska käyttäjä ei pääsisi täyttämään saraketta 1. Jos viimeinen rivi eli CHECK-vaatimus jätetään pois, maisemaan INSERT-oikeutettu käyttäjä pystyisi kyllä luomaan taulukkoon rivin, jossa sarake1=0. Kyseessä olisi sokea kirjoitus sikäli, ettei hän voisi itse enää nähdä kyseistä riviä.

Esimerkin sarake1 voi toimia eräänlaisena turvaleimana. Taulun rivejä, joissa se on nolla (tai <0), ei näytetä tavallisille käyttäjille.

Näkymät ovat pääsynvalvonnan kannalta käteviä, sillä niillä saadaan aikaan monipuolisia säätöjä. Tietysti voidaan myös tehdä monimutkaisia virityksiä, joista muodostuu turva-aukkoja tai jotka hidastavat suoritusta.

SQL-kielestä löytyy helposti lisätietoja ja toteutuksia, kuten avoimen koodin ohjelmistot MySQL, MariaDB ja PostgreSQL. Kaksi ensimmäistä ovat toistensa "sisaruksia" (myös My on nimi). Tässä on MySQL:n GRANT-syntaksi. Iso osa tietokantajärjestelmien turvallisuudesta on tällaisten toteutusten vastuulla. Tietokannan sisäinen pääsynvalvonta ja esim. kenttien arvoille asetettavat tarkistukset voivat toteuttaa vain melko suppeita, joskin tärkeitä sovelluskohtaisia tietoturvatarpeita.

Tässä vaiheessa ei tarvitse opetella, mutta jos asia on jo osittain tuttu, on hyvä kerrata, että tietokannan hallinnan järjestelmätason haasteita ovat ACID-ominaisuudet: Atomicity, Consistency, Isolation, Durability. Nämä ovat samoja kuin turvallisten käyttöjärjestelmien vaatimukset. Isolaatio on ollut eniten esillä tässä materiaalissa.

Palautusta lähetetään...