Skip to Content

Ohjeet sovelluskehittäjille (in Finnish)

Last modified by Mikko Parviainen on 2026/06/15 12:32

Tunne kehittämäsi aihealueen tietoturvavaikutukset

OWASP Cheat Sheet Series tarjoaa useisiin aihealueisiin, kuten sessioiden hallintaan ja lokitukseen, tiiviitä tietopaketteja tietoturvan huomioimisesta: https://cheatsheetseries.owasp.org/

OWASP Application Security Verification Standard tarjoaa vastaavasti aihealueittain huomioitavia asioita tarkistuslistan muodossa: https://owasp.org/www-project-application-security-verification-standard/

Ennen osa-alueen toteutusta on hyvä miettiä karkean tason uhkamallinnusta kyseisen alueen osalta.

Integraatiot

HY:n keskitetyn API Gatewayn käyttöä suositellaan aina, mikäli useamman eri sovelluksen välillä halutaan vaihtaa tietoja ja sovellukset tukevat ko. rajapinnan käyttöä. 

Vaihtoehtona on myös integraatiopalveluiden palveluväylän (ESB) käyttäminen, jos tietojen vaihdossa tulee toteuttaa toimintalogiikkaa tai tietomuunnoksia rajapintojen välillä, tai integraatio vaatii tiukempaa tietoturvaa, kuten sovelluskohtaisia varmenteita. Näissä tilanteissa lisätietoja antaa Tietotekniikkakeskuksen Integraatiopalvelut-tiimi. 

Käyttäjätunnistus ja pääsynhallinta

Jos palvelu tarvitsee Helsingin yliopiston henkilökunnan tai opiskelijoiden tunnistamista, tulee kirjautuminen aina toteuttaa keskitetyn kirjautumisen kautta.

Kirjautumisen yhteydessä käyttäjästä voidaan välittää tietoja, joita voidaan käyttää pääsynhallintaan. Näitä ovat mm. IAM-ryhmät, sekä henkilön työsuhteeseen sidottavat, rooleihin perustuvat ryhmät.

Ylläpitotoimenpiteet tulee pystyä toteuttamaan henkilökohtaisilla ylläpitotunnuksilla, jotta toimenpiteistä ja esimerkiksi henkilötiedon käsittelystä saadaan käsittelijään johtava audit-trail.

Tarkempia tietoja käyttäjähallinnan vaihtoehdoista löytyy sivulta User Management

Lokitus

Helsingin yliopistolla on käytössä keskitetty lokivarasto audit-lokien tallentamiseen. Kaikki henkilötietoja käsittelevät järjestelmät tulee liittää keskitettyyn lokijärjestelmään.

Tietosuoja-asetus vaatii henkilötietojen käsittelyn lokittamista. Audit-lokeihin täytyy jäädä jälki mm.  henkilötiedon lukemisesta, muokkaamisesta, luomisesta ja poistosta. Lisäksi on tallennettava käyttäjän tunnistamiseen liittyvät merkinnät, kuten sisään tai ulos kirjautuminen ja käyttäjätason vaihtaminen.

Tämän lisäksi lokituksella voidaan havaita tietoturvapoikkeamia, järjestelmän virheellistä toimintaa jne.

Ohjeita lokituksen toteuttamiseen:

Teknologioiden ja sovelluskomponenttien valinta

Komponenttien arviointi

Käytetyt teknologiat ja komponentit tulisi arvioida tietoturvan kannalta. Kokonaisuus ratkaisee ja havainnoitavia osatekijöitä ovat mm.:

  • Tukipolitiikat ja/tai kehittäjäverkoston laajuus ja aktiivisuus.
  • Käytön laajuus.
  • Tietoturvahaavoittuvuuksien raportointikäytännöt.
  • Havaittuihin tietoturvaongelmiin reagointi, esim. GitHub issues.
  • Tuen saaminen tarvittaessa.
  • Mahdoliset geopoliittiset riskit.

Selvitä aina millä tavalla komponenttien haavoittuvuuksista ja korjauksista tiedotetaan ja huolehdi näiden seuranta osaksi sovelluksen valvontakäytäntöjä ja dokumentaatiota.

Ohjeita:

Missä tilanteissa valmiista komponenteista on erityisesti hyötyä

Kaikkea ei kannata tehdä itse. Erityisesti tämä pätee yleisesti käytettyihin ja monimutkaisiin osa-alueisiin kuten:

  • Yleisesti käytetyt protokollat: HTTP, TLS, kirjautuminen (SAML ja OIDC) jne.
  • Tietokantarajapinnat.
  • Kryptografia.

Näihin löytyy kaikista kielistä yleisesti ja pitkään käytettyjä kirjastoja, sovelluskehyksiä ja vakioituja ratkaisuja, jotka voivat auttaa toiminnallisuuksien toteuttamisessa tietoturvallisesti.

Huom. usein esimerkiksi sovelluskehysten ohjeet ja oletusasetukset kuvaavat helpon tavan tehdä asia, eivät tietoturvallista. Tutustu aina käytettyjen ratkaisujen asetuksiin ja tarkempaan dokumentaatioon.

Testauskäytännöt ja koodin laatu

Helposti ymmärrettävä ja ylläpidettävä koodi ja kattava dokumentaatio on merkittävä osa tietoturvaa.

Organisaatioissa täytyy aina varautua siihen, että kehittäjät ja ylläpitäjät vaihtuvat, usein ilman merkittävää varoaikaa. Vaikka osaaminen olisi kahdennettu lomien ja sairastapauksien hoitamiseksi, joudutaan poikkeustilanteissa päivityksiä ja korjauksia tekemään myös muiden toimesta, dokumentaatioon nojautuen.

Erilaiset lintterit, tyylin tarkastukseen liittyvät työkalut ja vastaavat voidaan siten mieltää myös osaksi tietoturva-automaatiota. Käytettävissä on myös laajemmin koodia analysoivia tai sovellusta testaavia työkaluja, joiden päätyypit on kuvattu alla.

Staattinen koodin testaus (STAT)

Staattinen koodianalyysi on tehokas tapa tutkia lähdekoodia ja löytää siitä haavoittuvuuksia, virheitä, syntaksivirheitä ja muita heikkouksia sekä laatupoikkeamia. Koodianalyysi tuottaa raportin, jonka pohjalta koodi voidaan korjata varhaisessa vaiheessa. Staattisen koodianalyysin työkalut voidaan integroida osaksi CI/CD-putkea. 

Staattisen koodianalyysin avulla koodin haavoittuvuudet pyritään löytämään ennen koodin julkaisua, jolloin virheellistä ohjelmakoodia ei päädy järjestelmään. Aikaisen koodin tarkistuksen avulla kehittäjä saa heti palautteen kirjoittamastaan koodista, mikä lisää ymmärrystä haavoittuvuuksista ja koodin laadusta.  

HY:n tarjoamat tai suosittelemat työkalut 

Dynaaminen testaus (DAST)

Dynaaminen skannaus tarkoittaa järjestelmän ulkopuolelta tehtävää havainnointia tai hyökkäystä, jonka tehtävänä on löytää järjestelmän haavoittuvuudet. DAST-työkalut voidaan integroida osaksi CI/CD-putkea. Testauksen avulla voidaan testata esimerkiksi syöttökenttien validointia.

Kaikkia haavoittuvuuksia ei löydy lähdekoodista, vaan virheet havaitaan vasta ajon aikana. Dynaamisen testauksen avulla voidaan löytää monia erilaisia heikkouksia. Testausraportista saa ohjeita heikkouksien korjaamiseen.

HY:llä ei ole tällä hetkellä tarjolla kehittäjien ja ylläpitäjien käytössä olevaa dynaamisen testauksen palvelua. Alla on hyödyllisiä sovelluksia ja palveluita.

  • Zed Attack Proxy (ZAP)
    • https://www.zaproxy.org/
    • Kattava avoimen koodin testausohjelmisto.
    • Mahdollistaa periaatteessa automatisoinnin osaksi CI-putkea esim. kontissa ajettuna, mutta ei sisällä verkkopalvelua havaintojen käsittelyyn.
  • Mozilla HTTP Observatory

Yleiset testauskäytännöt tietoturvan kannalta

  • Raja-arvojen testaus.
  • Testaa pääsynhallinta sekä se, että käyttäjä pystyy tekemään tietyllä roolilla vain niille tarkoitettuja toimintoja.
  • Syöttökenttien tarkistukset (kenttä ottaa vastaan vain oikeanlaista dataa, varmista, että esim. SQL-injektiot eivät onnistu).
  • Session hallinta.
  • Virheiden käsittely ja virheviestit (esim. varmista, etteivät järjestelmän virheviestit vuoda käyttöliittymään).

OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/ 

Koodin tarkastus toisen kehittäjän toimesta

Kaikki koodi tulisi testata merkittäviltä osin automaattisesti, mutta sen lisäksi ohjelmakoodi tulee arvioida jonkun toisen kehittäjän toimesta. Tällöin koodi arvioidaan teknisestä sekä laadullisesta näkökulmasta. Projektin Pull/Merge request-käytännöt katselmointeineen on hyvä kirjata selkeästi kehitysohjeisiin.

Välillä voi olla hyödyllistä järjestää laajempia koodikatselmointeja, jolloin ohjelmakoodi käydään läpi ryhmän kehittäjien kesken. Myös parikoodaus on hyödyllinen työkalu koodin arviointiin ja sen avulla voidaan kouluttaa juniorikehittäjiä.

Ylläpito- ja seurantakäytännöt

Järjestelmästä tulee olla olemassa ylläpitoon tarvittava dokumentaatio. Poikkeustilanteissa palvelua voi joutua päivittämään joku muu kuin ensisijainen ylläpitäjä, tai ainakin tekemään arvion päivitysten tärkeydestä.

  • Järjestelmän päivityskäytännöt on kirjattu ylös vaihe vaiheelta.
  • Prosessi haavoittuvuuksien korjaustarpeen arvioimiseen sekä korjauksien toteuttamiseen on kirjattu ylös ja vastuutettu.
  • Ongelmien ja esimerkiksi tietomurron selvittelyssä tarvittavien lokien sijainnit on kirjattu ylös.

Teknologioiden ja komponenttien päivitysten ja haavoittuvuuksien seuranta

Käytetyistä teknologioista ja sovelluskomponenteista tulee pitää selkeää dokumentaatiota, josta selviää mm. eri versioiden elinkaari ja tukiaikataulut. Tällöin versioiden päivitystarpeisiin voidaan varautua ajoissa ja sovellus pitää tietoturvan kannalta tuetuissa versioissa.

Dokumentaatiosta tulee myös selvitä missä mahdollisista haavoittuvuuksista tiedotetaan. Sovellusten tietoturvatiedotteet tulee olla seurannassa ja haavoittuvuudet automaattisessa valvonnassa.

Dependency Track

HY ylläpitää Dependency Track-palvelua, jolla voidaan seurata tunnettuja haavoittuvuuksia komponenteissa.

Dependency Trackiin syötetään järjestelmän käyttämät komponentit SBOM (Software Bill of Materials) muodossa ja se seuraa useista lähteistä haavoittuvuusilmoituksia ja hälyttää, jos komponentista on ilmoitettu haavoittuvuus.

Lisätietoja Dependency Trackin käytöstä omalla sivullaan: Dependency Track.

Ohjeita ja työkaluja

Haavoittuvuuksien tarkistukset ja pakettien päivitykset tulee ajaa päivittäin automaattisesti.

Poikkeustilannesuunnitelmat

Huolehdi, että sovelluksella on poikkeustilannesuunnitelmat myös tietoturvan kannalta merkittäviin tilanteisiin, kuten tietomurtoon.

Valmiilla suunnitelmilla voidaan varmistaa nopeampi reagointi, vaurioiden rajoittaminen sekä mahdollisuus selvittää poikkeaman syyt sekä palautua tapahtumasta mahdollisimman joustavasti.

Versionhallinnan suojaus

Projektin oman versionhallinnan suojauksesta tulee huolehtia tasolla, jotta asiaankuulumatonta koodia ei päästä syöttämään joukkoon.

  • Varmista että ainakin laajempia käyttöoikeuksia omaavat tahot käyttävät monivaiheista tunnistusta.
  • Käytä branchja ja luo selkeät käytännöt MR/PR-katselmonneille.

Tietoturvahavainnoinnin käytännöt

  • Ymmärrä sovellukseen ja sen tietoihin kohdistuvat uhat: Uhka- riski- ja kriittisyystason kartoitus
    • Huomio nämä uhat suunnittelusta alkaen.
  • Seuraa sovelluksen komponentteja ja riippuvuuksia.
    • Huomioi muualla havaitut haavoittuvuudet.
    • Yliopistolla on Dependency Track palvelu helpottamaan riippuvuuksien seuraamista.
  • Koodin tarkastukset tietoturvan kannalta.
    • Katselmoikaa koodia painottaen tietoturvaa ja väärinkäyttöä.
    • Käyttäkää havaintotyökaluja, kuten SonarQube automatisoimaan helppojen virheiden havainnointia.
  • Arvioikaa tarve tietoturvatestaukselle.
    • Sovelluksia voi säännöllisesti testata kehitystiimin toimesta, esimerkiksi simuloimalla hyökkäyksiä ZAP:lla testipalvelua vastaan.
      • Ainakin otettaessa uutta sovellusta käyttöön, tehdessä merkittäviä muutoksia tai päivittäessä taustalla olevaa infrastruktuuria ja konfiguraatiota.
    • Etenkin korkean riskitason sovelluksiin tulisi arvioida tarve ulkoiselle, kattavamalle tietoturvatestaukselle.