Tietokantojen turvallisuus

Tietokantojen turvallisuus Miro Holopainen Jenni Kallanto IIO30220 Database Management Raportti Huhtikuu 2014 Ohjelmistotekniikan koulutusohjelma Tekniikan ja liikenteen ala

Sisällysluettelo 1 JOHDANTO...3 2 Miksi turvallisuus on tärkeää?...3 3 Luvaton käyttäjä, ei-tarkoitettu tapahtuma tietokannan käyttäjän, adminin tai hakkerien toimesta...7 4 Virukset / malwaret, DDOS...7 5 Ylivuodot / liian vähäinen tila tietokannalle...7 6 Varmuuskopiointi...8 7 Suunnitteluvika ja ohjelmoijan bugit itse Tietokannassa tai sitä käyttävässä ohjelmassa...9 8 Mitä tietokanta tekee / mitä sen EI pidä tehdä...9 9 Kuinka estää yllämainittuja...9 9.1 SQL-injektiot...9 9.2 Oikeuksien asettaminen... 10 9.3 Varmuuskopiointi... 10 9.4 Suunnitteluvika... 11 10 Riskien hallinta / Vaarojen valvonta... 11 11 Datan suojaaminen... 13 12 Negatiiviset tietokannat... 14 13 Suojattu yhteys (SSL ja tietokannat)... 15 14 Luotujen taulujen lupien hallinta... 16 15 Omat mietteet / yhteenveto... 16 Lähteet

1 JOHDANTO Raportin tarkoituksena on tutustua tietokantojen turvallisuuteen. Raportissa käsitellään muun muassa esimerkkitapauksia tietomurroista, uhkatekijöitä sekä mahdollisia keinoja parantaa tietokantojen turvallisuutta. Raportti on osa IIO30220 Database managementkurssia. 2 MIKSI TURVALLISUUS ON TÄRKEÄÄ? Tietokantojen turvallisuus on tärkeässä roolissa tietokantoja suunnitellessa, toteutettaessa ja ylläpidettäessä. Tietokantojen turvallisuuden merkitys kasvaa koko ajan, sillä ihmiset tallentavat yhä enemmän tietoja verkkoon useisiin eri palveluihin Tietokantojen turvallisuus koostuu neljästä eri osa-alueesta: laitteisto (hardware), ohjelmisto (software), ihmiset ja tieto (data). Tietokannan laitteistoon liittyviä uhkia ovat muun muassa tietokantapalvelimen rikkoutuminen/tuhoutuminen. Tietokannan turvallisuudesta huolehtiessa pitääkin varmistaa, etteivät ulkopuoliset henkilöt pääse käsiksi laitteistoon eikä tietokanta tuhoudu tai tietoja häviä, jos esimerkiksi tietokantapalvelin rikkoutuu. Näitä tilanteita voi ehkäistä esimerkiksi sijoittamalla palvelimet lukittuun tilaan sekä varmuuskopioimalla tietokannan tarpeeksi usein. Tietokannan varmuuskopioinnista puhutaan tarkemmin kohdassa 7. Ohjelmistoon liittyviä ongelmia ja uhkia ovat muun muassa SQL-injektiot sekä tietokantaa käyttävien ohjelmien haavoittuvuudet. Jos ohjelmistosta löytyy aukkoja, voi hakkeri päästä käsiksi tietoihin, joihin hänellä ei ole oikeuksia. Useat tietomurrot suoritetaankin juuri ohjelmistosta löytyviä aukkoja hyödyntämällä. Ihmisiin liittyviä uhkia voivat olla muun muassa tietokantaa ylläpitävien henkilöiden huolimattomuus tai näiden henkilöiden suorittamat tietovarkaudet. Myös tietokannan suunnittelijoiden ja toteuttajien osaamattomuus ja huolimattomuus voivat altistaa tietokannan hyökkäyksille ja tietomurroille. Tieto on se osa tietokantaa, johon murtautujat haluavat päästä käsiksi. Kaikista tärkeimmät tiedot tulee salata ja pitää piilossa ulkopuolisilta. Näitä tietoja ovat muun muassa käyttäjien salasanat ja luottokorttitiedot (tarkemmin kohdassa 13). Tieto pitää suojata myös käyttäjille annetuilla oikeuksilla, jolloin käyttäjät eivät pääse näkemään esimerkiksi toisten käyttäjien tietoja. Tietojen suojaamisen kannalta on erittäin tärkeää, että kaikki kolme edellistä kohtaa tietokantojen turvallisuudesta on kunnossa, sillä silloin myös tieto on turvassa väärinkäytöltä. Kuitenkin jos esimerkiksi tietokantaan syystä tai toisesta pääsee joku murtautumaan, on tärkeiden tietojen oltava salassa, jotta murtautuja ei pääse hyötymään tiedoista (esimerkiksi luottokorttitietojen avulla taloudellisesti). Kuitenkin aina välillä saadaan lukea uutisia, joissa kerrotaan tietomurroista, joissa on viety tuhansien ja jopa miljoonien käyttäjien tietoja. Tällöin jokin edellä mainituista neljästä tietokannan turvallisuuteen liittyvistä kohdista on päässyt pettämään. Pahimmissa tapauksissa tietomurron tekijät ovat saaneet käsiinsä muun muassa selkokielisiä salasanoja. Seuraavaksi on koottu uutisia kolmesta tietomurrosta vuosilta 2013 ja 2011.

ESIMERKKITAPAUKSIA: 4.10.2013 Tietomurto Adobe Systemsin palvelimille Ohjelmistoyhtiö Adobe ilmoitti 2.10.2013 joutuneensa tietomurron kohteeksi. Tietomurron yhteydessä varastettiin jopa 2,9 miljoonan käyttäjän tietoja. Lisäksi ainakin Adobe Acrobat-, ColdFusion- ja ColdFusion Builder -ohjelmistojen lähdekoodit on varastettu. Adobe on varmistanut, että murtautujalla on ollut pääsy asiakkaiden Adobe ID - tunnuksiin ja salattuihin salasanoihin. Tämän lisäksi Adobe epäilee, että 2,9 miljoonan käyttäjän tiedot olisi viety. Nämä tiedot ovat sisältäneet asiakkaiden nimiä, salattuja pankki- ja luottokorttien numeroita ja korttien voimassaoloaikoja sekä muita asiakkaiden tilauksiin liittyviä tietoja. Adoben mukaan tällä hetkellä ei näytä todennäköiseltä, että murtautuja olisi onnistunut viemään salaamattomia pankki- ja luottokorttitietoja. Adobe on tiedottanut tietomurrosta käyttäjiään sekä varotoimenpiteenä ohjannut tapaukseen liittyvät käyttäjät vaihtamaan salasanansa, kun he kirjautuvat seuraavan kerran sisään palveluun. Adobe tulee ottamaan yhteyttä tapaukseen liittyvien pankki- ja luottokorttien haltijoihin ja on tiedottanut asiasta pankkeja Adobelle maksuja tehneiden asiakkaiden tilien suojaamiseksi. Adoben mukaan ei ole tiedossa tapauksia, joissa varastettuja tietoja olisi käytetty hyökkäyksissä sen tuotteita vastaan. Adobe kehottaa asiakkaitaan käyttämään ohjelmistojen tuettuja versioita. 4.11.2013 Lisätietoja Adobe Systemsin tietomurrosta (koskee edellistä uutista) Ohjelmistoyhtiö Adobe ilmoitti 2.10.2013 joutuneensa tietomurron kohteeksi. Adoben ilmoituksen mukaan tietomurron yhteydessä olisi varastettu jopa 2,9 miljoonan käyttäjän tietoja. Lokakuun 2013 lopussa tulleiden tietojen mukaan tuo lukema on kuitenkin huomattavasti suurempi, sillä internetiin ladatusta tiedostosta löytyy noin 150 miljoonan käyttäjän tietoja. Anonnews.org -sivustolle ladattu tiedosto sisältää kaikkiaan noin 150 miljoonan käyttäjän tietoja, kuten Adobe ID-tunnus sekä sähköpostiosoite. Näistä 130 miljoonasta löytyy myös salasana salatussa muodossa. Tiedostossa on myös esitetty salasanavihje, mikäli käyttäjä on tällaisen itselleen asettanut. Adoben edustajan mukaan aktiivisten käyttäjätunnusten osuus on näistä käyttäjätiedoista noin 38 miljoonaa. Tiedostosta löytyy myös noin 220 000.fi -loppuista sähköpostiosoitetta. Lisäksi lukuisia suomalaisia sähköpostiosoitteita löytyy myös muista kuin.fi -päätteisistä osoitteista, kuten esimerkiksi luukku.com, hotmail.com sekä gmail.com. Näin ollen suomalaisten tietojen osuus kokonaisuudesta onkin todennäköisesti suurempi kuin pelkästään.fi - päätteisten sähköpostiosoitteiden määrä. Esimerkiksi luukku.com sähköpostiosoitteita löytyy tiedostosta noin 35 000 kappaletta. Käytetystä salakirjoitustekniikasta johtuen voi olla mahdollista, että listassa olevat salasanat voidaan palauttaa selväkieliseen muotoon. Näin ollen kaikkien Adobe:n palveluihin rekisteröityneiden tulisi vaihtaa salasanansa Adobe:n palveluiden lisäksi

kaikista muistakin palveluista, joissa on käytetty samaa salasanaa. Esillä oleva tapaus korostaakin jälleen yksilöllisten salasanojen merkitystä eri verkkopalveluissa. 11.11.2011 Tietomurto Steam-verkkokauppaan Valve Corporationin Steam-pelikauppaan on kohdistunut tietomurto, jossa murtautuja on päässyt käsiksi järjestelmän käyttäjätietoja sisältävään tietokantaan. Palvelua ylläpitävän Valve Corporationin mukaan tietokanta sisältää asiakkaiden käyttäjätunnukset, salasanoista lasketut tiivisteet, tiedot palvelun kautta tehdyistä ostoksista, sähköpostiosoitteet, laskutusosoitteet ja salakirjoittamalla suojatut luottokorttitiedot. Toistaiseksi ei ole todettu, että sivullisten käsiin olisi joutunut käyttäjien henkilökohtaisia tietoja tai että luottokorttinumeroiden tai salasanojen salausta olisi onnistuttu murtamaan. Steam-foorumin käyttäjät joutuvat vaihtamaan salasanansa kirjautuessaan seuraavan kerran foorumille, mutta palvelun ylläpitäjä ei ainakaan vielä pakota käyttäjiä vaihtamaan varsinaisen Steam-verkkokaupan tilin salasanaa. Lisäksi kannattaa seurata palveluun liittyvissä maksuissa käytettävän luottokortin tapahtumia tavallista tarkemmin. 27.4.2011 Sony PlayStation Network -käyttäjien tietoja varastettu tietomurron seurauksena Sonyn järjestelmiin tehtiin tietomurto 17.4. ja 19.4. välisenä aikana. Playstation Network suljettiin 20.4. välittömästi havainnon jälkeen. Tietomurron suorittanut tekijä on tämänhetkisen tiedon perusteella saanut käsiinsä kaikkien PlayStation Network- ja Qriocity-palvelujen käyttäjien tiedot. Suomessa PS3-konsoleita on myyty noin 240 000 ja PlayStation Network -käyttäjiä arvioidaan olevan ainakin useita kymmeniä tuhansia. Käyttäjien tiedoista on paljastunut ainakin nimi, osoite, maa, sähköpostiosoite, syntymäaika, salasana ja käyttäjätunnus. Profiilitiedot ja ostohistoria saattavat olla varastettujen tietojen joukossa. On mahdollista, että myös palveluun syötetyt luottokorttitiedot eli luottokortin numero ja voimassaoloaika ovat hyökkääjien hallussa. Luottokortin tarkastuskoodeja eli ns. CVV-numeroita ei ole saatu kuitenkaan selville. Sony tiedottaa murrosta kaikille käyttäjilleen. Lisätietoja saa tarvittaessa Sonyn tiedotteessa olevasta Suomen palvelunumerosta http://faq.en.playstation.com/cgibin/scee_gb.cfg/php/enduser/std_adp.php?locale=en_gb&p_faqid=5593. Päivitetty 28.4.2011: Sonyn ilmoituksen mukaan luottokorttitietoja on säilytetty järjestelmässä salatussa muodossa. Tällä hetkellä ei ole myöskään näyttöä siitä, että luottokorttitietoja olisi anastettu tietomurron yhteydessä. Suomalaisia PlayStation Network -palvelun käyttäjiä on Sonyn mukaan 330 000. Päivitetty 3.5.2011:

Sony on ilmoittanut, että huhtikuussa paljastunut tietomurto on kohdistunut myös Sony Online Entertainmentin (SOE) järjestelmiin. Sony Online Entertainmentilta varastettu tieto sisältää käyttäjien nimen, osoitteen, sähköpostiosoitteen, sukupuolen, syntymäajan, puhelinnumeron, käyttäjätunnuksen ja salasanasta muodostetun tiivisteen (hash). SOE:n verkkopalvelut suljettiin 2.5., kun tietomurto havaittiin. Sony on myös ilmoittanut, että joidenkin asiakkaiden luottokorttitiedot on onnistuttu varastamaan. Luottokorttitietoja on varastettu noin 12700 käyttäjältä. Niiden lisäksi noin 10000 hollantilaisen, saksalaisen, espanjalaisen ja itävaltalaisen asiakkaan suoraveloitukseen käytetty pankkitilin numero on varastettu. Sony on yhteydessä näihin asiakkaisiin suoraan tiedottaakseen varkaudesta. Päivitetty 17.5.2011: Sony PlayStation Network- ja Sony Online Entertainment -palvelut ovat jälleen käytettävissä. Molemmissa palveluissa vaaditaan pakollinen salasanan vaihto kirjautumisen yhteydessä. Lisäksi PS3-pelikonsoleille on saatavilla pakollinen ohjelmistopäivitys. VAROITUKSEN KOHDERYHMÄ: Sony PlayStation Network -käyttäjät Sony Online Entertainment -palveluiden käyttäjät Mielipiteitä tapauksista: Adoben tapauksessa kun tietokantaan on päästy murtautumaan ja useiden miljoonien käyttäjien tietoja on saatu vietyä, on vakavaa, että salasanat pystyisi vielä avaamaan salakirjoitustekniikasta johtuen. Salasanojen avaamista helpotti myös se, että murtautujat olivat saaneet saaneet käsiinsä myös salasanavihjeen, jos käyttäjä oli sellaisen asettanut. Koska varastetut tiedot oli ladattu nettisivulle kaikkien luettavaksi, mahdollisti se myös muiden kuin itse murtautujien yrittää saada käsiinsä selkokieliset salasanat. Adoben toiminta ja tiedotus tietomurron jälkeen oli myös hieman vajaata. Se, että aluksi epäiltiin 2,9 miljoonan käyttäjän tietojen varastamista ja kuukausi myöhemmin luku olikin jo noin 150 miljoonaa ja salasanojen avaaminen mahdollista varmasti heilutti yhtiön mainetta. Näin suuren mittaluokan tietomurron luulisi herättävän Adoben että myös monen muun yrityksen huolehtimaan käyttäjien tietojen suojaamisesta. Tällaiset murrot voivat samalla myös paljastaa heikkouksia muun muassa juuri salaustekniikassa, jolloin samaa tekniikkaa käyttävät yritykset voivat vaihtaa tekniikkaa ennen kuin joku yrittää päästä käsiksi näiden yritysten tietokannan tietoihin ja hyödyntää samaa aukkoa. Steamin kohdalla tietomurto on myös ollut laaja, mutta kiitos tietojen salaamisen murtautuja ei päässyt käyttämään tietoja hyväkseen. Tässäkin tapauksessa tietomurron mahdollisti ohjelmapuolella löytynyt haavoittuvuus, mikä onkin melko yleinen tietomurtojen mahdollistaja. Sonyn tapaus nousi uutisiin suurestikin ja ihan syystä, olihan murto kattava ja koski usean maan käyttäjiä. Tässäkin tapauksena oli onni, että tärkeitä tietoja oli salattu. Kuitenkin noin 12700 käyttäjän luottokorttitietojen joutuminen vääriin käsiin on todella vakavaa.

Sekin, että tietoja saatiin käyttäjistä melko paljon ja usean palvelun kautta, tuo esille tietojen salaamisen tärkeyden, sillä nyt näitä tietoja olisi voinut käyttää ristiin käyttäjien tunnuksien selvittämisessä. 3 LUVATON KÄYTTÄJÄ, EI-TARKOITETTU TAPAHTUMA TIETOKANNAN KÄYTTÄJÄN, ADMININ TAI HAKKERIEN TOIMESTA Koska tietokantaa pääsee yleensä käyttämään useampi henkilö, joudutaan tietokannan turvallisuutta suunnittelemaan ja pohtimaan siten, että kukin käyttäjä pääsee käyttämään tietokantaa tarvitsemallaan tavalla. Samalla pitää kuitenkin huolehtia siitä, ettei käyttäjät pääse suorittamaan sellaisia toimintoja tietokantaan, joita heidän ei tarvitse tehdä tai joita he eivät saa tehdä. Esimerkiksi tavallinen käyttäjä, joka hakee esimerkiksi verkkosivulla omia tilauksiaan, ei saa päästä vaikkapa poistamaan toisia käyttäjiä tietokannasta tai lukemaan heidän tietojaan. Tällaisen toiminnan ehkäisemiseksi olisikin hyvä, että tietokannan käyttäjille määriteltäisiin erilaisia rooleja, joille on annettu tietyt oikeudet. Oikeuksilla pystytään määrittelemään roolin luku-, kirjoitus- ja muokkausoikeudet tietokantaan. Tällöin edellisen esimerkin käyttäjällä olisi esimerkiksi vain lukuoikeudet kantaan, jolloin hän ei edes pääsisi poistamaan toisia käyttäjiä. Tämä ei kuitenkaan vielä estä käyttäjää lukemasta toisten käyttäjien tietoja. Tämä kuitenkin yleensä estetään sovelluspuolella, jolloin käyttäjälle ei käyttöliittymäpuolella anneta edes mahdollisuutta selata muiden tietoja ja muun muassa estämällä SQL-injektiot SQL-tietokantoja käytettäessä. 4 VIRUKSET / MALWARET, DDOS Tietokantaa ylläpitävän koneen virusturva on hyvä pitää ajan tasalla. Viikoittaiset virustarkastukset ovat suositeltuja, sillä niiden avulla voidaan löytää virukset, jotka esimerkiksi koittavat vahingoittaa tietokantaa. 5 YLIVUODOT / LIIAN VÄHÄINEN TILA TIETOKANNALLE Muistin saattaa päästä ylivuotamaan, jolloin keskusmuistiin kirjoitetaan tietoa päällekkäin. Tämä saattaa tuhota tai vääristää tietoja ja pahimmassa tapauksessa päästää luvattoman käyttäjän sisään. Sen takia on tärkeää käydä läpi tietokantaa käyttävä ohjelmisto, jotta se ei voi sitä aiheuttaa. Myös maksimikyselyjen määrää voidaan pakottaa pienemmäksi.

Tietokantaa ylläpitävällä koneella on oltava myös tarpeeksi muistia, jotta tietokanta voi pyöriä jouhevasti. Myös kiintolevytilaa tulee olla tarpeeksi, jotta kaikki tietotarve saadaan tyydytettyä. 6 VARMUUSKOPIOINTI Tietokanta on hyvä varmuuskopioida asianmukaisin aikavälein. Tietokantaa minkä tietoja päivitetään ja lisätään päivittäin, olisi hyvä varmuuskopioida vähintään muutaman tunnin välein. Mikäli tietokanta tuhoutuisi esimerkiksi tulipalossa, tiedot olisivat vain muutamaa tuntia jäljessä oikeasta tilanteesta. Pahinta mitä voi tehdä on, että varmuuskopioi harvoin. Tällöin datan tuhoutuessa saatetaan menettää koko vuoden aikana kerätyt tiedot. Tärkeissä ja suuria ihmismääriä koskettavissa tietokannoissa (pankit jne.) on hyvä tehdä varmuuskopioita useampaan kuin yhteen paikkaan. Tällöin alkuperäisen ja ensimmäisen varmuuskopion tuhoutuessa, on vielä tietoja jäljellä.

7 SUUNNITTELUVIKA JA OHJELMOIJAN BUGIT ITSE TIETOKANNASSA TAI SITÄ KÄYTTÄVÄSSÄ OHJELMASSA Joskus tietokanta vaarantuu esimerkiksi tietokannan suunnittelijan ajatteluvirheestä. Ei ole esimerkiksi hyvä tehdä näkymää, joka kantaa mukanaan arkaluontoista tietoa. Tietokantaa käyttävän ohjelmoijan tulee myös olla tarkka, ettei koodissa pääse tietokantaa hyväksikäyttävää bugia syntymään. Tällainen voi esimerkiksi olla nettisovellus, jossa tilausta tehdessä voi sivua päivittämällä luoda useita maksettuja tilauksia samoista tuotteista, vaikka ne on vain kerran maksanut. Tässä tosielämän esimerkki missä suunnitteluvirhe aiheuttaa suurta rahallista haittaa. Krakkeri huomasi, että Nike antoi huippu-urheilijoille tilit, joiden kautta pystyi tilaamaan tavaraa maksutta. Kun hän sai tietää tuntemiltaan ammattiurheilijoilta, miten järjestelmä toimii, hän pääsi käsiksi useisiin eri Niken ammattiurheilijoiden tileihin. Tilien kautta krakkeri tilasi itselleen tavaroita ilmoittamalla itsensä aina tilinomistajan vieraaksi. - mpc.fi/kaikki_uutiset/krakkeri... 8 MITÄ TIETOKANTA TEKEE / MITÄ SEN EI PIDÄ TEHDÄ Tietokantaa suunnitellessa, tulee miettiä rajat sille mitä siltä halutaan ja mitä taas ei haluta. Samalla lailla toimitaan ohjelmistoja suunnitellessa, joten sitä voi soveltaa myös tähän. Esimerkki: Kauppaketjun tietokannan ei tule ylläpitää Kiinan väestötietoja. Tällainen ratkaisu vaatii ylimääräistä tilaa ja suorituskykyä, mikä on huono asia. 9 KUINKA ESTÄÄ YLLÄMAINITTUJA 9.1 SQL-injektiot Voidaan estää parametrisoimalla ohjelmakoodissa kyselyssä olevat muuttujat tai käyttäjän syöte käydään läpi ja luvattomat merkit muutetaan sopivanlaisiksi. Esimerkki: käyttäjän pitää kirjautua. Normaalisti komento ajetaan: WHERE userid = %muuttuja; Jos muuttujaa ei tarkasteta tai parametrisoida, voidaan antaa sivustolla muuttujalle arvo:

pekka OR 1=1 Tällöin kysely on muotoa: SELECT * FROM Users WHERE userid = pekka OR 1=1; joka toteutuu aina koska 1=1. Näinollen hyökkääjä pääsee kirjautumaan ilman tunnuksia sisään. Parametrisoinnilla kyselystä tulisi tällainen: SELECT * FROM Users WHERE userid = pekka OR 1=1 ; Tällainen ei palautakkaan mitään ja luvaton käyttäjä pysyy ulkopuolella. 9.2 Oikeuksien asettaminen Tekemällä tietyt käyttäjät ja antamalla heille tietyt oikeudet, voidaan estää väärinkäytöksiä. Esimerkiksi nettisovelluksen tietokantakäyttäjä voi vaan lukea tietoja, tällöin kaikki kyselyt jotka muuttavat tai luovat uutta tietoa estyvät. Esimerkki: Pekka tajuaa pystyvänsä ajamaan nettisivuston kautta minkä tahansa komennon SQL injektiona. Hän tekee seuraavasti: CREATE USER hakkeripekka @ %, INDENTIFIED BY 1234 ; GRANT ALL ON database TO hakkeripekka @%; Tällöin Pekalla on oikeudet kaikkialle tietokannassa. Nyt hän voi luoda dumppeja, manipuloida dataa ja niin edelleen. Tämä oltaisiin voitu estää kieltämällä nettisovelluskäyttäjää luomasta tietokannan käyttäjää: CREATE USER hakkeripekka @ %, INDENTIFIED BY 1234 ; Result: User is not allowed to use command CREATE. Näin Pekka ei olisi saanut luotua itselleen käyttäjää, eikä tehtyä itsestään ylläpitäjää. 9.3 Varmuuskopiointi Varmuuskopiointi voidaan suorittaa esimerkiksi seuraavasti: MYSQLDUMP --single-transaction --all-databases > bakupfile.sql Näin olet tehnyt varmuuskopion, josta tietokanta voidaan palauttaa tarvittaessa. Tekemällä automaattisia komentoja, voit varmuuskopioida tietokantaasi tietyin aikavälein.

9.4 Suunnitteluvika Asiakas siirtyy maksamaan ostoskorinsa Odotetaan pankilta tulosta IF maksu onnistui uudelleenohjaa sivu onnistui-sivulle ELSE uudelleenohjaa epäonnistui-sivulle Onnistui-sivu: Aja kantaan INSERT tilaus, tilauksen_tuotteet, toimitusosoite - tietokantaan Näytä teksti: onnistui Nyt onnistui-sivua voidaan päivittää, jolloin nettiohjelma luo päivitysmäärien verran tilauksia, jotka pistetään tietokantaan. Näin ollen jos kukaan ei huomaa virhettä tuotteita postittaessa, käyttäjä voi saada 3 tilausta 1 hinnalla. Tällainen olisi pitänyt suunnitella näin: Asiakas siirtyy maksamaan ostoskorinsa Odotetaan pankilta tulosta IF maksu onnistui & tilauksen_tila = kesken IF Aja kantaan INSERT tilaus, tilauksentuotteet, toimitusosoite tilauksen_tila = valmis uudelleenohjaa onnistui-sivulle ELSE uudelleenohjaa yrita_uudelleen - sivulle ELSE uudelleenohjaa epäonnistui-sivulle Tällä tavoin onnistui-sivua päivittämällä ei voida luoda kuin 1 tilaus / 1 maksettu tilaus, koska kaikki tietokantaan tapahtuvat kyselyt tehdään pankilta saadun vahvistuksen yhteydessä, ennen uudelleenohjausta muualle. 10 RISKIEN HALLINTA / VAAROJEN VALVONTA Riskejä hallitakseen, tulee miettiä ja tehdä riskianalyysia mahdollisista vaaroista. Tätä on hyvä tehdä useamminkin kuin kerran suunnitteluvaiheessa. Esimerkiksi viikoittaisella riskianalyysipalaverilla saadaan esiin nousseet uudet riskit kartoitettua ja sitä kautta myös mahdollisesti estettyä

Lokeja tulee valvoa päivittäin. Lokeihin kun kirjoitetaan kaikkea mitä tietokannassa on tapahtunut ja mitkä kyselyt ovat epäonnistuneen ja niin edelleen, on hyvä käydä niitä läpi. Näin voidaan esimerkiksi huomata että luvaton käyttäjä on ottanut kopion käyttäjätaulusta sisältöineen, joku on muokannut tärkeitä tietoja ilman lupaa ja joku on katsonut häneltä kiellettyjä tietoja. Esimerkkikuva lokien yhteenvedosta:

11 DATAN SUOJAAMINEN Koska aina on olemassa riski sille että tietokannassa oleva data varastetaan, tulee arkaluontoinen tieto aina salata. Salaukseen on olemassa useita keinoja ja useita algoritmeja. Kun tiedot on salattu, niiden avaaminen vaikeutuu tai vaiva salauksen purkamiseen on liian iso verrattuna siihen hyötyyn, mikä avatulla arkaluontoisella tiedolla voidaan saavuttaa. Seuraavat tiedot on aina tärkeää salata: Salasanat, jotta käyttäjätaulujen vuotaessa ei kukaan pääse käsiksi toisen tiliin. Yksilöivät henkilötiedot, jotta voidaan välttää identiteettivarkaudet Luottokorttinumerot Lakien mukaiset salassapitotiedot, tietyn maan lakien mukaisesti esimerkiksi sairauksia ei saa pitää julkisina, jolloin ne on salattava. Salasanat tulee suolata erillisellä tunnisteella, jotta hyökkääjä ei voi käyttää sateenkaaritauluja tai hakkerin on purettava jokainen salasana erikseen, joka aiheuttaa huomattavan määrän työtä hyökkääjälle. Tästä seuraa että hyökkääjän ei kannata yrittää avata tietoja, koska siitä saavutettu hyöty jäisi pienemmäksi kuin purkamiseen käytetty työ. Mikäli jokin valmis taulu tai niiden yhdiste sisältää jonkun henkilön yksilöivän tiedon, tulee pohtia tarvitaanko kaikkea vai voidaanko jättää jotain pois suojellakseen käyttäjää. Mikäli kaikkea tarvitaan, pitää varmistaa, että esimerkiksi henkilötunnus on salattu ja käyttäjän syntymäpaikka myös. Luottokorttinumeroiden kanssa pitää olla todella tarkkana ja on hyvän käytännön mukaista, että kaikkea tietoa, jota korttimaksamisessa käytetään ei tallenneta. Esimerkiksi luottokortista tallennetaan vain neljä viimeistä numeroa, sekä turvakoodia ei kerätä talteen missään vaiheessa. Tällöin käyttäjän kuitenkin tulee tietää esimerkiksi kortin vanhenemispäivä tai turvakoodi asioidessaan tietokantaa käyttävässä nettisivustossa. Vuotaessaan tällainen tieto antaa mahdollisuuden siirtää rahaa, ostaa tuotteita tai kloonata kortti. Miten toteutat salauksen: Yleisimmät salausalgoritmit: http://fi.wikipedia.org/wiki/salaus#salausalgoritmeja. Alla muutama yksisuuntainen esimerkki salasanojen tallentamiseen: MD5 SHA Hyvin yleinen On onnistuttu murtamaan Suojaustaso varsin heikko, hieman tehokkaimmilla koneilla tiivisteiden läpikäynti on nopeaa MD5:sen yleisesti pidetty seuraaja Hyvin yleinen Useita versioita, SHA-1, SHA-2 ja uusi SHA-3. Suojaustaso SHA-2:lla usein riittävä

NSA:n kehittämä, joten voidaan olettaa, että he pystyvät purkamaan salauksen koska vain SHA-1 on jo murrettu, SHA-2 tällä hetkellä murtamaton, mutta asiantuntijoiden mukaan ei enää kauaa SHA-3 ei ole NSA:n, standardoiminen vielä kesken Suojaustaso keskinkertainen, ei voida murtaa ainakaan helposti kotikonstein Näin turvallinen salaus toimii käytännössä: 1. Pekka valitsee salasanakseen: kissa 2. Sanaan kissa, lisätään satunnainen suola, jolloin se näyttää tältä: kissahy_23 3. Muodostetaan tiiviste salasana + suola-yhdistelmästä: e890e43bd3f97c81525fd64c15a44a0eb5 4. Tallennetaan tiiviste ja käytetty suola Pekan tietueeseen. 5. Pekka kirjautuu ja syöttää salasanan: kissa 6. Siihen lisätään Pekan tietoihin tallennettu suola: hy_23 7. Luodaan tiiviste tästä ja verrataan luotua tiivistettä tallennettuun tiivisteeseen. 8. Jos se on sama, Pekan salasana on oikein. Voidaan kirjautua sisään. Muut tiedot pitää salata monisuuntaisesti, jolloin niiden avaukseen tarvitaan avain. Näin suojataan esimerkiksi henkilötietoja, jotka täytyy pitää salassa. Vertaa salasanojen turvallisuutta alla olevien kuvien avulla. Salaamaton: Salattu: 12 NEGATIIVISET TIETOKANNAT Negatiivinen tietokanta on sellainen tietokanta, joka sisältää kaikki mahdolliset yhdistykset tietyissä tietokokoelmassa paitsi juuri sen halutun tietokokoelman. Se sisältää paljon ei olennaista tietoa ja sen läpi ei siis voi päästä ilman juuri oikeaa tietokokoelmaa. Tämä hidastaa ja ikään kuin luo suojan tiedon ja tietokannan väliin.

Alla olevassa kuvassa näkyy sen toimintaidea: Negatiivisia tietokantoja käytetään esimerkiksi pankkitoiminnoissa ja luottokorttiyhtiöiden korttitiedoissa. Luottokorttitiedoissa tämä on hyvin kätevää, koska alkuperäinen sivusto, joka on tallentanut osan kortin tiedoista, pystyy hakemaan luottokorttiyrityksen tiedoista kaiken halutun tiedon turvallisesti. Esimerkiksi: Sivusto.com on tallentanut asiakkaansa kortin neljä ensimmäistä ja viimeistä numeroa ja kortin vanhenemispäivämäärän. Sivusto.com tekee kyselyn luottokorttiyrityksen tietokantaan seuraavalla kokoelmalla: 1255 **** **** 2556 ja 09/14. Kysely saavuttaa negatiivisen tietokannan, joka toteaa että kyseistä kokoelmaa ei löydy ja välittää kyselyn positiiviseen tietokantaan. Sieltä tiedot palautetaan salattuina Sivusto.com:lle. 13 SUOJATTU YHTEYS (SSL JA TIETOKANNAT) Tietokantaa suunnitellessa kannattaa muistaa että vaikka tietokanta itsessään on turvallinen, internetin yli tehdyt kyselyt ja niiden tulokset pystyy nappaamaan kesken matkan. Tietoturvallisuudesta pitää siis huolehtia ja varmistaa että SSH on kytketty myös tietokannan ja palvelimen välillä, sekä siitä toivottavasti myös palvelimen ja käyttäjän välillä. 2014 vuoden huhtikuun alussa OpenSSH:ssa on havaittu koko internetin historian vakavin bugi Hearth Bleed. Tälle ei tietokannan suunnittelija tai ylläpitäjä voi mitään, koska kyse on ohjelman omasta virheestä. Kannattaa kuitenkin pohtia miten tämä voi

vaarantaa tietokannan tietoja. Haavoittuvuus liittyy TLS:n heartbeat-protokollaan, jota käytetään TLS-istunnon ylläpitämiseen. OpenSSL-kirjaston toteutus kyseisestä protokollasta voi palauttaa vastauspaketissaan pyydetyn määrän, kuitenkin korkeintaan 65 kilotavua, satunnaista muistin sisältöä. Palautetun sisällön joukossa on testeissa havaittu muiden käyttäjien viestien sisältöä, käyttäjätunnus-salasanapareja, evästeitä, istuntokohtaisia avaimia ja palvelun käyttämiä salaisia avaimia. Toistamalla protokollapyyntöjä voi olla mahdollista saada lisää muistisisältöä. Hyökkäyksestä ei ole todettu jäävän jälkiä sovelluslokeihin. - https://www.cert.fi/haavoittuvuudet/2014/haavoittuvuus-2014-049.html 14 LUOTUJEN TAULUJEN LUPIEN HALLINTA Tietokannan turvallisuutta voidaan lisätä antamalla käyttäjille tai käyttäjäryhmille oikeuksia vain tiettyihin tauluihin. GRANT ja REVOKE-komentoja käytetään taulujen oikeuksien muuttamiseen. GRANT-komennon syntaksi näyttää seuraavalta: GRANT oikeudet ON <tietokanta.taulu> TO <käyttäjätunnus@isäntäkone> INDENTIFIED BY <salasana> Oikeuksien myöntämisen periaatteena on, että käyttäjälle annetaan mahdollisimman vähän oikeuksia eli vain juuri sen verran, mitä tämä tarvitsee. Jos käyttäjän tarpeet jostain syystä muuttuvat, voidaan käyttäjälle myöhemmin antaa lisää oikeuksia, mutta varalta niitä ei kuitenkaan anneta. Oikeudet voidaan puolestaan perua REVOKE-komennolla: REVOKE oikeudet ON <tietokanta.taulu> FROM <käyttäjätunnus@isäntäkone> MySQL-tietokannan oikeuksia voi muuttaa taulutason lisäksi myös palvelin-, tietokanta- tai kenttätasolla. 15 OMAT MIETTEET / YHTEENVETO Suojaamalla tietokanta injektioita vastaan saattaa tuntua yleensä kaikenkattavalta ratkaisulta tehdä tietokanta täysin turvalliseksi. Tämä ajattelutapa on kuitenkin täysin väärä. Tietokannan suojaaminen ei ole mikään yksinkertainen asia. Kuten huomasimme, turvallisuutta pitää ajatella lähes jokaiselta mahdolliselta kannalta. Vain siten voidaan saavuttaa turvallinen ympäristö itse tietokannalle, sitä käyttäville sovelluksille ja niiden loppupään käyttäjille. Tärkeää on ollut myös huomata miten kannattaa toimia, jos pahin mahdollinen tapahtuu ja joku pääsee tietokantaasi käsiksi ja varastaa ja/tai tuhoaa kaiken. Jos data on suojattu

asianmukaisesti ja varmuuskopionti on kunnossa, varkaus tai tuho voidaan korjata suhteellisen helposti. Nopeasti toimiessa voidaan myös välttää vahingonkorvaukset ja kasvojen menetys. Tärkein opetus meille on ollut se että, koskaan et ole täysin turvassa, mutta voit tehdä kaikkesi ollaksesi mahdollisimman turvallinen.

LÄHTEET https://www.cert.fi/tietoturvanyt/2013/10/ttn201310041306.html 7.4.2014 https://www.cert.fi/tietoturvanyt/2013/11/ttn201311041048.html 7.4.2014 https://www.cert.fi/tietoturvanyt/2011/11/ttn201111111108.html 7.4.2014 https://www.cert.fi/varoitukset/2011/varoitus-2011-01.html 7.4.2014 http://www.schell.com/top_ten_database_threats.pdf 6.2.2014 http://en.wikipedia.org/wiki/database_security 6.2.2014 http://www.oracle.com/technetwork/database/security/twp-security-checklist-database-1-132870.pdf 6.2.2014 http://docs.oracle.com/cd/b14117_01/server.101/b10743/security.htm 6.2.2014 http://www.oamk.fi/sbc/www/mysql.php 13.4.2014 http://www.mpc.fi/kaikki_uutiset/krakkeri+loysi+aukon+niken+verkkokaupasta+ndash+v arasti+80+000+dollarin+edesta+tavaraa/a823290?s=r&wtm=mikropc/-24072012& 12.4.2014