Käyttöjärjestelmä on yhtä turvallinen kuin sen päällä ajettavien ohjelmien tietoturva. Jotakuinkin näin ajattelen, käytännössä.
Ohjelmistopäivityksiä tulee yleensä vain oikeastaan kahdesta syystä: kehitys tai korjaus.
- ohjelmaa on kehitetty: uusia ominaisuuksia, jo olemassaolevia parannettu
- bugi korjataan: se voi olla harmiton, tai liittyä tietoturvaan
Usein automaattisissa ohjelmistopäivityksissä tulee molempia laatuja. Bugit ovat luonteeltaan sellaisia, että niitä havaitaan ajan kuluessa, ja kun käyttäjät huomaavat ohjelman käytön aikana jotain epänormaalia. Bugien “lopullista määrää” on teoriassakin mahdoton ennustaa; siksi ei voida sanoa, että ohjelma olisi koskaan täydellinen.
Etenkin älypuhelinten sovellusten päivitys on muuttunut varsin kivaksi käyttäjän kannalta. Itse tunnen lähinnä iOS (Applen puhelinten) toiminnan, ja koskaan sen kanssa ohjelmistopäivityksestä ei ole tullut mitenkään kynnyskysymystä.
Miksi ohjelmistopäivityksistä pitäisi tietää?
Ongelmallisimpia “koneita” ovat itse asiassa ne, joissa käyttäjällä ei ole mitään hajua, mikä on ohjelmisto, ja mitä tietoturvasta huolehtimatta jättäminen voi merkitä.
Tilanne, jossa tietokoneen annetaan olla niinkuin se on, ja pelätään asetusten muuttamista, on itse asiassa aika yleinen. Vaikka olen tehnyt käytännössä modernien (moniajavien, Windows- ja Linux käyttöjärjestelmien) parissa töitä ja harrastusta 20 vuotta, ajoittain huomaan itsekin nojautuvani tai ainakin toivovani voida valita passiivisen sivustakatselun. Tietotekniikkaa ja ohjelmistopäivityksiä voisi kuvata näin: ne ovat tosi kivoja, niin kauan kuin kaikki toimii kitkatta. Kun ongelmia tulee, selvittelytyöstä voi muodostua yllättävän pitkä ja mutkikas juttu.
Siksi – jotta nuo taustalla vaikuttavat asiat – valaistuisivat ja päivityksiin liittyvät pelot hälvenisivät, käyn hieman läpi myös tietotuvan ja ohjelmistojen päivitysten perusteita.
Tietoturva on “seksikäs” aihe mutta tavattoman tylsää tietyllä tapaa. Se on sellainen extra, jota useinkaan ei jaksaisi hoitaa käytännössä.
Olen ehkä siinä mielessä hieman poikkeus, että ihastuin tietoturvan periaatteisiin ja teoriaan koulun kautta. Silti, myönnän, että esimerkiksi pari kertaa viikossa aina 2 tuntia kerralla kuluttava podcast aihepiiristä on joskus puuduttavaa kuunnella. En voi aivan varauksetta suositella siis Steve Gibsonin ja Leo Laporten Security Now! -podcastia, vaikka se onkin alansa parhaita (jos haluat tarkkaa analyysiä erilaisista ajankohtaisista tietoturvaongelmia, paina ihmeessä Subscribe tuolle podcastille!). Se ei vain ole sellainen, joka kattaisi perustarpeita, vaan menee tosi syvälle asioiden taustoihin.
Itse asiassa: nyt käännyn teihin päin. Mikä on paras ja nasevin tietoturvauutispläjäys, joka antaisi myös käytännön ohjeet asioiden hoitamiselle? Kuunteletko tai katseletko säännöllisesti jotain tiettyä podcastia, vlogia tai vastaavaa? Laita kommentteihin!
Käyttäjänähän meitä kiinnostaa vain varsinaisten hommien tekeminen, eli se että tietokoneella saadaan aikaiseksi se, mitä alunperinkin alettiin tekemään.
Tietoturvaa vaivaa myös se, että asiasta puhutaan usein hyvin teknisin termein. Suomenkielistä, selkeää ja riittävän ytimekästä tietoa on myös aika vaikea saada – etenkin jos haluaa sitä riittävän nopeasti tietoturvaongelmien noustua.
Käyttis + softa + minä = kokonaisuus
Käyttöjärjestelmä (Windows tai Linux, Mac) on mikä on, mutta jos sen päällä olevat ohjelmat vuotavat ja bugittavat, “alla olevalla” turvalla ei ole merkitystä. Siksi käyttäjän itse tekemät päivitykset ja ennenkaikkea ymmärrys tietoturvasta on tärkeässä roolissa.
Kauan aikaa sitten, tarkoittaen 1980-lukua, käyttöjärjestelmissä ei ollut oikeastaan varsinaisesti mitään tietoturvaa. Ne oli ohjelmoitu olettaen, että ulkopuolisten ihmisten olisi hyvin vaikea päästä koneelle; Internetiä ei vielä ollut kotikäytössä.
Myös senaikaiset ohjelmistot eivät sisältäneet tarkoituksellisia heikkouksia, ja virukset ja muut haittaohjelmat olivat vasta tulossa 1990-luvulla.
Mikä “ohjelmisto” oikeastaan on?
Ohjelmisto (‘software’) on tietokoneen kannalta (näkökulmasta) kasa bittejä, jotka on tallennettu tiedostoon. Ennen ohjelman ajoa käyttöjärjestelmä lukee tiedoston muistiin, ja alkaa syöttää komentoja prosessorille. Ohjelma on siis aiemmin valmistettu ja käyttäjälle kopioitu, tiettyä järjestystä noudattava erityinen tiedosto.
Jos kirjoitat muistioon pienen pala tekstiä, se ei ole tietokoneohjelma. Jos tällaisen tiedoston yrittäisi syöttää prosessorille, saisit virheilmoituksen: prosessori ei tunnista komentoja mielekkääksi.
Joskus muinoin ohjelmat saattoivat olla niinkin pieniä kuin 5-10 tavua (eli lyhyitä, mitattuna komentojen määrällä). Lyhin ohjelma on periaatteessa 1 tavun mittainen, mikäli prosessorissa on sellainen komento, jonka tallennus vie vain 1 tavun muistia. Käytännössä ohjelmat ovat satojen tuhansien tai miljoonien tavujen mittaisia. Koon voit tarkistaa näin:
Ohjelmistotiedoston sanotaan olevan “executable”: ajettava eli ajokelpoinen. Vastakohtana ajokelpoisille tiedostoille ovat erilaiset data-tiedostot, jotka sisältävät ohjelmien käyttämää tietoa.
Kaikki ohjelmat koostuvat hyvin samanlaisista peruspalikoista: komennoista, joilla voidaan siirrellä tietoa keskusmuistissa. Tietoa voidaan verrata, kopioida, poistaa, ja näitä voidaan tehdä “loogisten ehtojen” voimin. Matemaattisesti operaatiot ovat
Automaattiset päivitykset
Aika usein nykyään käyttöjärjestelmä päivittää itsensä automaattisesti, eli ajastetusti ja “täydellisesti” (kaikkien osien suhteen). Tämä itsessään on ollut kenties eräs käytännön tietoturvan suurimmista edistysaskeleista. Hyvä niin!
Mutta, 3 syytä miksi automaattiset päivitykset eivät ole ratkaisu kaikkiin tietoturvaongelmiin:
- ajan kanssa kilpajuoksu
- automaatiikka on pois päältä
- joskus automatiikka ei sovellu (eli aiheuttaa enemmän ongelmia)
Ajan kanssa kilpajuoksu
Yksittäinen tietoturvauhka johtuu teknisesti “reiästä”, eli bugista ohjelmassa. Bugi on olemassa riippumatta siitä, onko sitä havaittu tai ei. Bugi on siis ohjelmakoodin logiikassa sellainen kombinaatio, joka on haitallista jos sitä käytetään tietoisesti (tai tahattakin). Esimerkkinä voisi heittää, että ohjelman on tarkoitus aina tarkistaa pääkäyttäjän salasana, ennenkuin se antaa tehdä tiettyjä toimintoja. Ohjelmaa on myöhemmin paranneltu, koodia kirjoitettu. Tuolloin koodaajalta on unohtunut lisätä tämä tarkistus. Ohjelmaan jää nyt bugi, jossa tietyssä erikoistapauksessa salasanaa ei tarkisteta, vaan normaali käyttäjä voi “luvatta” tehdä asian jonka pitäisi olla sallittu vain tunnistauneelle pääkäyttäjälle.
Mutta todennäköisyys, että joku oikeasti käyttäisi tuota ongelmallista bugia hyväksi, on aika pieni, jos reiän olemassaolosta ei ole tietoa. Tietoturvaan liittyvän bugin raportointi ja julkituonti on siis kaksiteräinen miekka. Samantien kun bugista tulee julkinen, alkaa myös mahdollisesti sen hyödyntäminen luvattomiin tarkoituksiin. Mutta raportointi saa liikkeelle prosessin, jossa yleensä joku kirjoittaa korjauspalasen (“patch”) – tälläinen tapahtuu yleensä 1-14 päivässä ja voimme käyttäjinä hyväksyä ohjelmistopäivityksen, jonka jälkeen ohjelma on turvallinen tämän bugin osalta.
Tietoturvahaavoittuvuuksista puhuttaessa, termi “responsible disclosure“ tarkoittaa sitä, että reiän ensimmäiseksi havainnut taho pyrkii tuomaan turvallisesti tiedon vain niiden (oletetusti “hyvien”) piiriin, jotka voivat korjata vian ennenkuin suuri yleisö saa siitä tietää. Etumatka voi olla merkittävä ja erittäin tärkeä, ja vähentää uhkan aiheuttamaa vahinkoa.
2. automaattiset ohjelmistopäivitykset tarkoituksella pois päältä
Aina siis automatiikka ei ole passé. Käytännössä tällaisia syitä, miksi käyttäjät estävät automaattipäivitykset, on joko että se häiritsee työntekoa, tai että esimerkiksi ohjelmistokehittäjänä itse haluaa kontrolloida tarkemmin mikä ohjelma muuttuu, ja milloin.
Keskinäinen riippuvuus ja “dependency hell”
Päivitysten kenties kaikkein arkaluonteisin puoli on, että ne saattavat aiheuttaa myös ongelmia. Tämä johtuu ohjelmistojen keskinäisestä riippuvuudesta.
Riippuvuudessa kysymys on: Jos tietokoneella on N kpl eri ohjelmistoa asennettuna, mitkä versiot kustakin pitää olla, jotta ne toimivat keskenään yhteen? Tarkemmin sanottuna yleensä kyse ei ole “kokonaisista sovelluksista”, vaan jaetuista ohjelmistokirjastoista. Kirjastoja asennetaan siksi, että ohjelmistokehitys helpottuu. Mutta tämä luo (tai; ainakin loi ennen) keskinäisriippuvuuden ja joskus myös noidankehän, jossa oli vaikea saada sopivia palasia paikalleen kokonaisuuden toimivuuden kannalta.
Käytännössä tuosta tulee matemaattisesti “N:n tekijän tulo”, eli kertolasku jossa on monta termiä. 3 ohjelmalla ja 5 versiolla jokaisesta saataisiin testijoukoksi 5*5*5 = 125 eri kombinaatiota. Todellisuudessa versioita on huomattavasti enemmän, samoin sovellusohjelmia. Käytännössä PC-koneella voisi kuvitella olevan 20 sovellusohjelmaa, ja niistä tarjolla ainakin tuo 5 versiota. 5^20 on aika tähtitieteellinen luku.
No totta puhuen nykyään – itse asiassa jo kauan aikaa sitten – tästä “dep hell” ongelmasta on päästy aika nerokkaalla mekanismilla yli: pidetään jokaisella ohjelmalle oma virtuaalinen kirjastonsa; eli jokainen voi kuvitella elävänsä omassa kopperossa, jossa käyttöjärjestelmä tarjoaa sopivat versiot.
Tosin dep hell toistuu eri muodoissa uudestaan. Eli pyörä keksitään myös uudestaan vuodesta toiseen, riippuen mistä ohjelmistoekosysteemistä ja käyttöjärjestelmästä puhutaan. Ratkaisumalli on olemassa, mutta sen käytännön sovelluksen rakentaminen on siis “work in progress”..
Edes täysin automaattisessa järjestelmässä kaikkien kombinaatioiden testaaminen ei olisi välttämättä kovin nopeata, saati käsin. Toinen iso ongelma todellisessa tilanteessa on, että kaikki operaatiot eivät välttämättä ole “peruttavissa” helposti. Toisinsanoen jos testataan A1.0 ja B1.0, jonka todetaan aiheuttavan ongelmia, ja haluttaisiin palata alkuperäiseen tilanteeseen jossa koneella ei ole kumpaistakaan ohjelmaa, voi olla niin että tuohon on vaikea päästä.
Käytännössä usein päädytään siihen, että kokeillaan toimisiko kaikista ohjelmista viimeisimmät (tuoreimmat versiot). Onneksi sovellusohjelmien kohdalla “itsenäisyys” ts. riippumattomuus on lisääntynyt. Ohjelmat eivät ole usein enää niin
Riippuvuus on monimutkainen asia, usein niin monimutkainen, että lopulta päädytään vain takaisin aivan yksinkertaiseen määritelmään. Usein toimivuuden testaajana on me, käyttäjät. Ideaalitilanteessa ohjelmistot voisivat olla itseäänkorjaavia (self-healing) ja mukautua erilaisiin tilanteisiin, mutta tietoteknisesti kyseessä on vielä suhteellisen kaukainen unelma.
Seuraavassa osassa: ohjelmistopäivitykset Linuxissa (aptitude), ja semantic versioning esittely. Ehkä. Ainakin tuo aptitude!
