Rajapinnan vaarat: pieni muutos, ja Wilma pullautti vieraiden lasten tietoja vanhemmille
”Tämä on yllättävän yleinen moka”. Apien käyttötarkoitukset ja käyttäjäroolit pitäisi asiantuntijoiden mielestä määritellä nykyistä tarkemmin.

Samalla kun organisaatiot avaavat järjestelmiinsä api-rajapintoja datansa ympärille rakentuvien ekosysteemien toivossa, rajapintoihin liittyvät tietoturvaloukkaukset ja tahattomat vuodot lisääntyvät.

Syyskuussa joukko Wilma Plus -sovellusta käyttäviä huoltajia näki sovelluksessa heille kuulumattomia vieraiden oppilaiden tietoja. Tiedot olivat peräisin Visman kehittämän Wilma-järjestelmän kolmansille osapuolille tarkoitetusta rajapinnasta.

Visman koululiiketoimintajohtaja Teemu Lehtonen kertoo, että puutteellinen määrittely oli ollut rajapinnassa pidempään, mutta se tuli ilmi vasta kun kolmannen osapuolen sovellus käytti rajapintaa uudella tavalla.

”Rajapinnassa oli liikaa oikeuksia, eikä se näkynyt missään virheenä. Meidän olisi pitänyt olla tarkempia.”

Visma poisti Wilman rajapinnat kolmansien osapuolien käytöstä, kun asia tuli ilmi.

Api-talouteen ja -konsultointiin keskittyvän Osaango-yrityksen perustaja Marjukka Niinioja tunnistaa tilanteen, jossa tiettyyn käyttötarkoitukseen tehtyä rajapintaa ryhdytään käyttämään uudella tavalla, ja liikaa dataa livahtaa apista ulos.

”Tämä on yllättävän yleinen moka. Jokainen yritys, mukaan lukien Google ja Facebook, on mokannut vastaavassa asiassa.”

Vaaran paikkoja ovat myös tilanteet, jossa aiemmin julkaistuun rajapintaan tehdään muutoksia tai sinne lisätään dataa, mutta muutoksista ei viestitä rajapintaa hyödyntäville osapuolille tai viesti ei mene perille. Silloin voidaan päätyä tilanteeseen, jossa kolmannen osapuolen sovellus tekee saman api-kutsun kuin ennenkin, mutta vastauksen mukana tulee ylimääräistä dataa.

”Jos lisätään uutta dataa, tehdään apiin uusi endpoint. Tai sitten tehdään kokonaan uusi api, jos rakennetta muutetaan radikaalisti”, Niinioja tiivistää.

Haaste julkisissa api-rajapinnoissa on se, että julkaisija ei voi tietää, mihin kolmas osapuoli apin kautta saamaansa dataa käyttää. Sopimusteknisesti käyttötarkoituksia voidaan rajata, mutta väärinkäyttöä se ei estä.

Sen sijaan apien käyttötarkoitukset pitäisi määritellä selkeästi, ja apien käyttöä ja käyttöoikeuksia tulisi rajata teknisin keinoin toteuttamaan vain määritelmän mukaisia toimintoja.

Datan kahmiminen rajapinnasta useampien api-kutsujen välttämiseksi on edelleen yleistä, vaikka riskit varmasti tiedostetaan.

Tietoturvayhtiö Fraktalin teknologiajohtaja Tuomo Makkonen sanoo yhä törmäävänsä sovelluksiin, jotka esimerkiksi yhden käyttäjän tietojen sijaan pyytävät apilta useamman käyttäjän tiedot kerrallaan, ja käyttäjän päädyssä oleva sovelluslogiikka hoitaa datan rajaamisen, käsittelyn ja näyttämisen.

Makkonen on huolissaan siitä, että useista rajapinnoista saa myös kaavittua tarpeettoman paljon dataa pelkkiä api-kyselyn parametreja päättelemällä ja muuntamalla. Näin on esimerkiksi silloin, kun käyttäjätunnukset tai vaikkapa käyttäjän julkaisujen uniikit tunnukset on ilmoitettu järjestysnumeroin eikä satunnaistetuilla tunnisteilla.

Esimerkiksi Makkonen nostaa Clubhouse-keskustelusovelluksen tapauksen. Palvelussa oli puutteelliset tietoturvakontrollit, jolloin käyttäjien sähköpostiosoitteet ja julkisen profiilidatan pystyi pyytämään apilta parametrejä numeroimalla.

”Clubhouse puolustautui sillä, että kaikki se oli julkista tietoa, mutta ei se ole hyvä, että yhdellä skriptillä saa hankittua miljoonien käyttäjien tietokannan.”

Suurin osa verkon api-rajapinnoista toteutetaan yhä rest-arkkitehtuurilla, mutta uudempi graphql-arkkitehtuuri yleistyy samaan aikaan. Graphql-kehittäjien täytyy olla erityisen tarkkana, sillä datan verkostomaisen luonteen takia graphql-rajapinnasta on helpommin saatavilla ulos paljon dataa kerralla kuin tarkempia kyselyitä vaativasta rest-rajapinnasta.

Merkittäväksi huoleksi Makkonen nostaa lisäksi supply chain -haavoittuvuudet, kuten viimevuotisen ­Log4Shellin. Modernit ohjelmistot ovat riippuvaisia niin monista eri tuottajien komponenteista, että ketjuista löytyy väkisinkin haavoittuvuuksia.

Api-vuoto on merkittävä mainehaitta ja aiheuttaa usein myös rahallisia sanktioita vastuussa olevalle organisaatiolle. Osaangon Marjukka Niinioja kertoo ulkomaisesta pankkialan yrityksestä, jolle oli käynyt kiusallinen vahinko.

”Eräs pankki kärähti oikein kunnolla, kun testiympäristössä oli käytetty tuotannon dataa, ja henkilötietoja oli vuotanut sitä kautta todella paljon. Pitäisi olla prosessit ja automatiikkaa varmistamassa, ettei näin tapahdu.”

Vahingonkorvausvelvollisuus sekä henkilötietoja käsiteltäessä merkittävät gdpr-sakot voivat muodostaa jopa organisaation olemassaoloa uhkaavan seuraamuksen.

Niinioja sanoo, että apien testaus olisi syytä nivoa osaksi jatkuvan kehityksen ci/cd-syklin vaiheita. Ulkopuolista auditointia voi harkita silloin, kun apiin tehdään isompia muutoksia.

”Testaamiseen on hyviä työkaluja, mutta niiden käyttöä voisi helpottaa se, että apit on suunniteltu sellaisilla standardeilla ja tekniikoilla, että ne istuvat näihin työkaluihin.”