Skip to Content

Ohjeet tuoteomistajille ja projektipäälliköille (in Finnish)

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

Uhka-, riski- ja kriittisyystason kartoitus

Sovellukselle tulee tehdä jo suunnitteluvaiheessa uhka- ja riskitason kartoitus, jossa selvitetään millaisia uhkia sovellukseen kohdistuu ja mitä niiden toteutumisesta voi seurata. Samoin määritetään sovelluksen kriittisyysluokittelu, joka kuvaa sovelluksen tärkeyttä yliopiston toiminnalle.

Näiden pohjalta voidaan arvioida, millä tasolla tietoturva tulee huomioida kehityksen aikana ja kuinka se vaikuttaa mm. arkkitehtuurivalintoihin.

HY:n tavoitteena on, että itse tuotetuissa sovelluksissa olisi huomioitu sovelluksen kannalta tarkoituksenmukaiset OWASP ASVS:n kontrollit seuraavalla tavalla:

  • Erittäin matalan riskitason sovellukset: taso 1
  • Matalan ja keskitasoisen riskin sovellukset: taso 2
  • Korkean riskitason sovellukset: taso 3

Kriittisyys- ja riskitason määrittäminen

Järjestelmän suunnittelun alkuvaiheessa Sovellussalkkussa arvioidaan järjestelmän kriittisyystaso (Jatkuvuudenhallinta-välilehti), joka määrittää palvelun kriittisyyttä yliopistolle toiminnalle. 

Samoin täytetään Tietosuoja-välilehti ja kirjataan sinne järjestelmän riskitasot käyttäjän ja yliopiston näkökulmasta.

Uhkien kartoittaminen

Uhkien kartoittamiseen yksi yleinen menetelmä on uhkamallinnus.  Uhkamallinnuksesa kartoitetaan järjestelmän tietoturvaan ja tietosuojaan liittyviä riskejä ja keinoja niiden huomioimiseen. Uhkamallinnus toteutetaan yleensä työpajana, jossa arvioidaan keskustellen eri järjestelmien vaiheisiin liittyviä riskejä.

Esimerkki uhkamallinnuksen vaiheista:

1. Valmisteluna kuvataan palvelu, tietojärjestelmä tai toiminto, josta uhkia kartoitetaan.

  • Mitä suojattavaa tietoa järjestelmässä on.
  • Kuinka järjestelmä toimii, esim. vuokaavio.
  • Mikä on palvelulle hyväksyttävä riskitaso. HY:llä hyväksyttävä riskitaso riippuu osin riskin luonteesta. Tarkemmin näistä löytyy tietoturvan ja Flamman riskeinhallinnan ohjeista (linkit yllä).

2. Varsinaisessa työpajassa kirjataan ylös kaikki esille tulevat riskit.

  • Mikä voi mennä pieleen?
    • Pääsy väärään tietoon, toimiminen toisen oikeuksilla, järjestelmän tekeminen käyttökelvottomaksi, tiedon hävittäminen jne.
  • Mitä tapahtuu, jos asia menee pieleen?
    • Terveyden tai hengen vaarantuminen, oikeusturvan vaarantuminen, HY iltauutisissa jne.
    • Mikä/ketkä ovat koheet?
  • Ketkä ovat tekijät, kenellä on motivaatio tehdä näin?
    • Ulkoinen hakkeri, kokeileva työntekijä, oikeuksien väärinkäyttö, inhimillinen virhe.
  • Kuinka uhkaa vastaan voi suojautua?

3. Pisteytetään uhkat ja arvioidaan vaaditut toimet.

DVV:n turvallisen sovelluskehityksen käsikirjan ohje uhkamallinnuksen toteuttamiseen: https://wiki.dvv.fi/pages/viewpage.action?pageId=230471067 

Tietoturvan vastuuroolit

Käytännön roolit ja eri osa-alueiden vastuulliset henkilöt voivat vaihdella projektista toiseen ja alla oleva on vain yksi tapa, kuinka vastuut voidaan jakaa.

  • Omistaja
    • Vastuu sovelluksen tietoturvallisuudesta on viime kädessä sovelluksen omistajalla.
  • Tuoteomistaja
    • Tuoteomistaja vastaa siitä, että tietoturvaan liittyvät tehtävät on priorisoitu projektin työlistalle ja ne toteutetaan asianmukaisesti ja riittävillä resursseilla.
    • Tuoteomistajan tulee varmistaa, että tiimissä on ymmärretty tietoturvan huomioiminen erilaisten prosessien, testauksen, skannauksen ja monitorointien avulla.
  • Tekninen tietoturvavastuuhenkilö (tämän olisi hyvä olla kehitystiimin jäsen)
    • Vastaa siitä, että tietoturva toteutetaan oikein tietojärjestelmään.
    • Vastaa siitä, että kaikilla kehitystiimissä on selkeä kuva siitä, miten järjestelmän tietoturvasta huolehditaan.
    • Vastaa siitä, että mm. tietoturvakäytännöt, teknologiakomponentit ja poikkeustilasuunnitelmat on dokumentoitu ja prosesseja noudatetaan osana kehitystä. Teknisen tietoturvavastuuhenkilön ei tule tehdä kaikkea itse, vaan hän osallistaa koko kehitystiimiä.
  • Arkkitehti, sovelluskehittäjä, suunnittelija jne.
    • Kaikilla kehitykseen osallistuvilla on osaltaan vastuu huomioida tietoturva sovittujen käytäntöjen mukaisesti.

Operatiivisessa järjestelmässä vastuuta voi olla myös tiedon omistajalla, pääkäyttäjillä, ylläpitäjillä, ulkoisilla yhteistyökumppaneilla jne. Vastuut on kuitenkin aina kuvattava eikä vastuuta voi täysin ulkoistaa. Viimekädessä kokonaisuudesta vastaa palvelun omistaja organisaation edustajana.

Tietosuojan huomioiminen sovelluskehityksessä

Silloin kun kehitettävällä sovelluksella tullaan käsittelemään henkilöihin tai heidän toimintaansa liittyviä on huomioitava tietosuoja. Tietosuoja ja tietoturva kulkevat kehityksessä rinta rinnan. Tietosuoja kertoo pääosin mitä tulee suojata, ja tietoturva kuinka se suojataan. Tietojen suojaamisen lisäksi tietosuojan osalta on pohdittava, miten rekisteröityjen oikeudet ja käsittelyn asianmukaisuus turvataan.

Tietoturvallisuusmyönteisen ilmapiirin luonti ja prosessit

Tietoturvallisuusmyönteisyys lähtee kulttuurista, jossa tietoturva nähdään tärkeänä osana organisaation toimintaa. Tietoturva lähtee aina ihmisistä, ei teknologiasta. Selkeät prosessit, tietoturvan tekeminen näkyväksi ja ihmisten osaamisen vahvistaminen helpottavat tietoturvan omaksumista osana jokapäiväistä työtä.  

Psykologinen turvallisuus luo hyvät edellytykset tietoturvan kehittämiseen. Turvallisessa ympäristössä uskalletaan puhua vaikeista ja keskeneräisistäkin asioista ja virheet nähdään mahdollisuutena oppia. Tällaisessa ympäristössä virheitä ei peitellä ja samaa virhettä tuskin tapahtuu toistamiseen. 

Tietoturvan huomioiminen tietojärjestelmän elinkaaren kaikissa vaiheissa

Alkuvaiheessa tehty uhka- ja riskikartoitus määrittää pitkälle, kuinka tietoturvaan tulee varautua arkkitehtuurissa ja kehitystyössä.

Tietoturvatason nostaminen jälkikäteen voi osoittautua todella kalliiksi tai vaatia sovelluksen osien tai jopa koko sovelluksen uudelleen toteutusta, jos arkkitehtuuria ei ole alun alkaen suunniteltu riittävän turvalliseksi.

Jo kehitysvaiheessa on hyvä toteuttaa järjestelmälle sisäistä auditointia esimerkiksi OWASP ASVS-tarkistuslistojen avulla: https://owasp.org/www-project-application-security-verification-standard/

Tuotantovaiheeseen siirryttäessä tulee varmistua, että ylläpito- ja seurantaprosessit on dokumentoitu ja niitä noudatetaan. Käytettyjen teknologioiden elinkaarta tulee seurata ja varata riittävät resurssit versiopäivityksiin tilanteissa, joissa aikaisempien versioiden tuki loppuu.

Kaikissa järjestelmissä, joiden HY:n sisäinen kriittisyysluokka on kolme tai sitä suurempi, tulee tehdä toipumissuunnitelma.

Luopumisvaiheessa tulee huolehtia esimerkiksi tiedon asianmukaisesta hävittämisestä. Vaikka kehitysympäristöissä ei tulisikaan käsitellä todellisia henkilötietoja tai luottamuksellista tietoa, on totuus usein toinen. Näiden järjestelmien, liitettyjen palveluiden jne. hallittu alasajo ja tietojen poistaminen liittyy kehitysprosessiin.

Auditointikäytännöt

Sisäistä auditointia tehdään jatkuvasti osana ohjelmistokehitysprosessia. Laajempia skannauksia ja esim. penetraatiotestejä voidaan tehdä harvemmin, mutta silti säännöllisesti osana kehitystä.

Kehitysjakson loppupuolella kriittisiin järjestelmiin voidaan tilata ulkopuolelta tietoturva-auditointi. Auditointi tulee tilata siinä vaiheessa, kun järjestelmä on riittävän valmis auditoitavaksi, mutta projektissa on vielä aikaa korjata auditoinnin löydökset.

Ulkoiset tietoturva-auditoinnit tulee kilpailuttaa.

  • Huom! Kilpailuttamiseen liittyvät ohjeet ovat valmistelussa.

Tietoturvaa auditoidaan usein OWASP Application Security Verification Standardin kysymysten avulla. Tätä voidaan tehdä myös omavalvontana, käymällä listaa läpi vaaditulla tietoturvan tasolla ja katsomalla toteuttaako sovellus vaaditut asiat. https://owasp.org/www-project-application-security-verification-standard/