Hallitse API-riskejä julkisissa rajapinnoissa

APIen turvallisuuden rakentaminen alkaa palvelun tietoturvariskien kartoittamisesta. Lue blogistamme, mitä asioita tulee ottaa huomioon APIn turvallisuuden varmistamiseksi.

Edellisessä kirjoituksessamme annoimme käytännön esimerkin API-rajapintojen (Application Programming Interface, järjestelmärajapinta) hyödyistä Hammaslääkärin ajanvaraus- esimerkin kautta. Esimerkki on oikeasta elämästä, jossa sähköisesti tehty muuttoilmoitus rekisterinpitäjälle jäi ”byrokratian rattaisiin” viikoiksi, eikä hammaslääkäriajan varaaminen uudessa kunnassa onnistunut tästä syystä – vaikka hammaskipu olikin kova! APIn käyttö olisi nopeuttanut muuttoilmoituksen tietojen välitystä rekisteristä uuteen kuntaan, ja mahdollistanut hammaslääkärin ajanvarauksen nopeasti.

Viranomaisille tulee API-pakko, kuten Tivin uutisoinnissa saimme lukea. Vaikka siirtymäaika on neljä vuotta, töihin kannattaa ryhtyä heti. Koko prosessi hankinnasta toteutukseen vie oman aikansa, kun tietoturva otetaan huomioon API-suunnittelusta lähtien.

APIen, kuten muidenkin järjestelmien tulee olla turvallisia. Turvallisuuden rakentaminen alkaa palvelun tietoturvariskien kartoittamisesta. Potentiaalisia riskejä havainnollistetaan Hammaslääkärin ajanvaraus- esimerkin kautta. Tässä blogissa riskit (lista ei ole kattava!) on jaoteltu 1) tyypillisiin/yleisiin ja 2) palvelukohtaisiin riskeihin.

Tyypillisiä API-turvallisuusriskejä, joita tulee hallita hyvällä suunnittelulla

Lainsäädännön erityisvaateet ovat SoTe-tyyppisen tiedon turvaamiselle korkeat, joten myös riski erilaisista sanktioista tiedon turvaamisen pettäessä on merkittävä, ja tähän tulisikin siksi paneutua erikseen.

Tyypillisiin riskeihin varautumiseen on käytettävissä useita viitekehyksiä, joiden avulla eri tyyppisiä tietoturvariskejä voi kartoittaa. Tässä annetaan esimerkki nk. STRIDE- viitekehyksen riskityypeistä. 

1. S-Spoofing identity eli identiteetin väärinkäyttö – riskissä saadaan kaapattua toisen henkilön tunnukset ja salasanat, eli identiteetti. Toisin sanoen joku esimerkiksi varastaa hammaslääkäri-APIsta toisen henkilön tunnukset ja salasanan. Tämän jälkeen varas voi esimerkiksi varata hammaslääkäriaikoja niin, että maksu ohjautuu sinulle, tai nähdä terveystietosi API-rajapinnan kautta.
2. T- Tampering with data eli datan väärentäminen, muokkaaminen tai hävittäminen luvatta. Esimerkiksi aiempi hammashoitohistoria tuhotaan, jolloin lääkärillä on puutteelliset tai väärät tiedot esimerkiksi potilaan lääkeaineallergioista.
3. R-Repudiation – väärinkäytöksen tekeminen jälkiä jättämättä. Jos hammaslääkärijärjestelmän APIssa ole lokitusta päällä, ei tietoa väärinkäytöksistä näe järjestelmästä.
4. I-Information disclosure - luvaton tiedon julkaisu/saataville saattaminen. Varatessasi aikaa näetkin Hammaslääkäri-APIn kautta vaikkapa naapurisi terveystietoja, vaikka tietojen tulisi olla suojattuja muilta kuin henkilöltä itseltään ja hoitavalta lääkäriltä.
5. D-Denial of service - palvelun käytön estäminen. Palvelu ruuhkautetaan tahallaan, jotta ajanvaraus ei toimi.
6. E-Elevation of privilege - käyttövaltuuksien tarpeeton tai luvaton laajentaminen. Käyttäjä huomaakin aikaa varatessaan, että on saanut lääkärin oikeudet järjestelmään, ja pääsee muokkaamaan laajasti järjestelmän tietoja.

OWASP -top 10 (The Open Web Application Security Project) sisältää yleisimmät turvallisuusriskit, jotka pätevät myös APIeihin.  Näitä ovat erimerkiksi puutteellinen pääsynhallinta, virhekoodien kalastelu, haltuun saadut admin-oikeudet ja injektiot. 

Tapauskohtainen riskiarvio – oman palvelun riskit

Tapauskohtaisessa riskiarviossa on tärkeää:

1. Tunnistaa yleisistä riskeistä juuri meidän palveluamme koskevat riskit.
2. Tunnistaa omassa palvelussa käytettävän ympäristön erityisriskit – eli tässä tilanteessa APIen erityisriskit.
3. Tunnistaa omassa palvelussa olevan tiedon sensitiivisyys, ja palveluun kohdentuvat lainsäädännön erityisvaateet tiedon turvaamiselle.

Lopuksi riskejä kannattaa evaluoida kirjoittamalla palvelun tyypillisiä käyttötapauksia esim. 6-10 kappaletta. Käyttötapauksista arvioidaan niihin sisältyvät riskit ja tarkastetaan, tuleeko jo löydettyjen ja arvioitujen riskien lisäksi vielä joitain uusia riskejä. Käyttötapauksissa kannattaa huomioida käyttäjän keskeiset käyttötapaukset, eritoten viranomaisten tiedonvaihtoa koskevat käyttötapaukset, sekä joitain ylläpitäjän käyttötapauksia.

STRIDE-viitekehyksen riskityypeissä käsiteltiin jo kohtia 1 ja 2. Lisäksi skenaariossamme oli otettu mukaan ympäristöstä tieto siitä, että varausongelman ratkaiseva API olisi pilvessä. Tästä seuraa, että palvelun tietoturvariskeihin tulee sisällyttää pilvipalveluiden tyypillisiä riskejä (esimerkiksi lokaatio, kyky palautua/palautta toiminta, palvelun tietojen turvaaminen ja kopiointimenettelyt) riittävässä laajuudessa.

Hammaslääkäri-tapauksessa palvelussa oleva tieto on (kohta 3, tiedon sensitiivisyys):

• Henkilötietoa, ja nk. erityistä henkilötietoa (potilaan tiedot ovat sekä GDPR-lain mukaista erityistietoa, että SoTe-tiedon luonteen vuoksi korotetun tietoturvan tietoa),
• Hammaslääkärin tietojen ja aikatietojen välittämisestä (tietoja hoitopaikasta, ei erityissuojattavaa tietoa).

Tiedon sensitiivisyydestä seuraa, että eritoten seuraavat riskit tulee huomioida korostetusti:

• Tiedon joutuminen nk. vääriin käsiin, tiedon muuntelu tai poistaminen itsessään on vakava riski.
• Edelliseen liittyen riski siitä, että väärinkäytöksestä ei jää kiinni, saa myös lisää painoarvoa (seurantatiedon keruu ja turvaaminen on tärkeää).
• Tiedon katoaminen teknisestä syystä on myös vakava riski (kopiointi, kahdentaminen tärkeää).
• Tiedon lokaation tulee olla tiedossa ja mieluiten ETA/EU alueella. Tiedon siirtyminen/siirtäminen teknisellä alustalla tai sen kautta määritetyn alueen ulkopuolelle aiheuttaa riskin GDPR-sanktiosta.

Uuden tiedonhallintalain mukaan tulisi olla erityisen tarkkana siitä, että myös viranomaisten välillä jaeltavalle tiedolle ja sen käsittelylle on oltavat lainsäädännölliset perusteet. Tämä tarkoittaa sitä, että viranomaisilla ei automaattisesti ole luku-muokkaus-poisto-oikeuksia toistensa tietoihin, vaan oikeudet vaihtelevat sen mukaan, mikä on kulloisenkin viranomaisen oikeus toisen viranomaisen tiedon saantiin, muokkaamiseen ja edelleen jakeluun.

Kaikkea tietoa ei myöskään ole oikeutta nk. “korjata” vaikka viranomaisella itsellään oleva tieto olisi uudempaa kuin toisella viranomaisella oleva tieto. Hammaslääkäri ei esimerkiksi välttämättä voi päivittää kansallisiin SoTe-tietoihin kansalaisen muuttuneita lääkeallergioita, vaikka nk. “maalaisjärjellä ajatellen” näin pitäisikin toimia. Näin ollen kaikkeen käyttövaltuushallintaan, ei vain käyttäjien vaan APIeja käyttävien viranomaisten osalta liittyvät riskit ovat moninaiset ja korkeat – riskit sisältävät sekä riskejä tiedon väärinkäytöstä, että riskin väärinkäytösten johdosta laukeaviin sanktioihin. Tämän vuoksi käyttövaltuushallinnan käyttötapauksia ja niihin liittyviä riskejä tulee evaluoida erityisellä huolella riskitarkastelun lopuksi.

Kun riskit on koottu ja listattu, niiden todennäköisyys ja kriittisyys kannattaa arvioida, ja edellisten summana saadaan kullekin riskille (riskityypille) suunnittelua varten painoarvo. Tietoturvan suunnittelun tärkein tehtävä on riskien ja uhkien ennalta ehkäiseminen.

Tietoturvallisen APIn suunnitteluun paneudutaan seuraavassa blogissamme. Tätä odotellessa kannattaa mieliin painaa turvallisen APIn suunnittelun tarkastuslista:

• Vain määritellyt applikaatiot ja käyttäjät pystyvät käyttämään APIa ja pääsemään sen kautta järjestelmän tietoon käsiksi.
• APIa voidaan käyttää vain määritellyllä tavalla.
• API-tietoon päästään käsiksi vain määriteltyjen käyttäjien ja roolien kautta.
• API-tiedonsiirto internetin yli on suojattua, ulkopuolinen ei saa selkokielellä tietoa.
• APIa ei voida käyttää hyökkäyksessä järjestelmää vastaan, eli sillä ei voida hajottaa APIa tai järjestelmää.

Riskejä ja niiden toteutumisskenaarioita miettiessä ei tässä tapauksessa eräälle kirjoittajalle käynyt ongelma, eli hammaslääkäriin pääsyn pitkittyminen, ehkä olekaan pahinta, mitä voi tapahtua. Vilkkaalla mielikuvituksella varustettuna voisi tietoturvaton API aiheuttaa hänelle väärän vastaanottoajan, vääriä laskuja, ja mahdollisesti väärää tietoa hänen lääkeallergioistaan. Pahimmassa mahdollisessa riskiskenaariossa hänelle olisi voinut tapahtua monenlaista, ehkä jopa hampaiden turha poisto väärien ajanvaraustietojen takia!

Blogin kirjoittajat ovat Ari Lappalainen, Anne Honkaranta, Suna Koljonen ja Tiina Davidsson.