Skip to Content

Tietoturva sovelluskehityksessä

Last modified by Jukka Karvonen on 2025/04/07 09:54

1. Johdanto ja sisällys

Ohjeisiin on koottu periaatteita, hyviä käytäntöjä ja käytännön ohjeita tietoturvan huomioimisesta sovelluskehityksestä.

Sovelluskehittäjän ohjeet-wikin sisältö on elävää ohjeistusta, joka kehittyy ajan kanssa.

1.1. Periaatteet

  • Tietoturva huomioidaan sovelluksen elinkaaren kaikissa vaiheissa suunnittelusta luopumiseen.
  • Sovelluksien riski- ja uhkataso määritellään ja tietoturvasta huolehditaan riski- ja uhkatason edellyttämällä tasolla.
  • Tietoturva- ja testiautomaatio on kriittinen osa sovelluskehityksen- ja ylläpidon prosesseja. Sovelluskehittäjien tulee varmistaa, että sovellus testataan kattavasti.
  • IT-projekteissa sovitaan tietoturvan vastuuroolit.
  • Lue myös HY:n tietoturvaperiaatteet (Flamma työryhmät, vaatii kirjautumisen). 

1.2. Ohjeiden tarkoitus

  • Edistää hyviä käytäntöjä tietoturvan huomioimisessa sovelluskehityksen eri vaiheissa.
  • Antaa tiivistetty yleiskuva minkälaisia tietoturva-asioita sovelluskehityksessä tulee huomioida ja kuinka ne voidaan ottaa huomioon.
  • Auttaa eri rooleissa toimivia henkilöitä hahmottamaan heidän oma roolinsa tietoturvan edistämisessä ja varaamaan heille riittävästi aikaa erityisroolissa toimimiseen.

1.3. Tietoturvan rooli sovelluskehityksessä

  • Tietoturva ja tietosuoja ovat toisistaan erottamattomia.
    • Tietoturvan päätarkoitus on suojata tietoa, esimerkiksi tietoon pääsyä ja tiedon oikeellisuutta.
    • Tietosuoja puolestaan suojaa tiedon kohteena olevan henkilön perusoikeutta yksityisyyteen ja henkilötietojen suojaan sekä vahvistaa hallintaa hänestä kerätyistä tiedoista.
  • Hyvin toteutettu tietoturva mahdollistaa sovelluksen häiriöttömän ja tarkoituksenmukaisen käytön.
  • Sovelluksen tietoturvaongelmat voivat johtaa myös muiden järjestelmien vaarantumiseen.

1.4. Tietoa aiheesta muualla

1.4.1. DVV Turvallisen sovelluskehityksen käsikirja

Digi- ja väestötietoviraston turvallisen sovelluskehityksen käsikirja on kattava opas tietoturvan huomioimisesta julkishallinnon sovelluskehityksessä.

Käsikirja kuvaa erityisesti tietoturvan kannalta tärkeitä prosesseja. 

https://wiki.dvv.fi/pages/viewpage.action?pageId=230470940

1.4.2. Trendejä tietoturvassa

1.4.3. OWASPin projektit

The Open Worldwide Application Security Project (OWASP) on voittoa tavoittelematon säätiö, jonka tehtävänä on kehittää sovellusten tietoturvaa. Eri projekteissaan he luovat malleja ja työkaluja sovellusten tietoturvan kehittämiseen ja varmistamiseen.

OWASP on suurimpia avoimia tietoturvamäärityksiä ja ohjeita kehittäviä organisaatioita, ja monia sen projekteja pidetään käytännön standardeina alla.

Alla on kuvattu muutamia sovelluskehityksen kannalta merkittäviä projekteja. 

1.4.3.1. OWASP Application Security Verification Standard

1.4.3.2. OWASP Cheat Sheet Series

1.4.4. Muita lähteitä

1.4.4.1. CIS Benchmarks

Kattavia ohjeita eri sovellusten koventamiseen. Ei-kaupalliseen käyttöön ilmaisia CC BY-NC-SA 4.0-lisenssillä.

https://www.cisecurity.org/cis-benchmarks

1.4.4.2. MITRE ATT&CK

Tietomurroissa käytettyjen tekniikoiden ja taktiikoiden luokittelua tosielämän havaintoihin perustuen.

https://attack.mitre.org/

2. Ohjeet tuoteomistajalle ja projektipäällikölle

2.1. 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

2.1.1. 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.

2.1.2. Uhkien kartoittaminen

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

Karkeasti uhka- ja riskitason kartoituksessa mietitään: 

  • 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.
  • Kenellä on motivaatio tehdä näin? 
    • Ulkoinen hakkeri, kokeileva työntekijä, oikeuksien väärinkäyttö.
  • Kuinka uhkia vastaan voi suojautua?

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

2.2. 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.

2.3. 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.

2.4. 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. 

2.5. 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.

2.6. 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/

3. Ohjeet sovelluskehittäjälle

3.1. 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.

3.2. 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. 

3.3. 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 Käyttäjähallinta.

3.4. 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:

3.5. Teknologioiden ja sovelluskomponenttien valinta

3.5.1. 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:

3.5.2. 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.

3.6. 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.

3.6.1. 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 

3.6.2. 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

3.6.3. 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/ 

3.6.4. 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ä.

3.7. 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.

3.7.1. 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.

3.7.1.1. 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.

3.7.1.2. Ohjeita ja työkaluja

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

3.7.2. 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.

3.7.3. 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.

3.8.0 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.

4. Tämän ohjeen kehittäminen

Näissä ohjeissa raapaistaan pintaa ja moni osa-alue kaipaisi tarkennuksia, tai puuttuu kokonaan.

Tiedossa olevia jatkokehityskohteita ovat mm:

  • Tarkistuslistat eri kehityksen ja elinkaaren vaiheisiin.
    • Käytännön esimerkki mitä huomioidaan missäkin vaiheissa projektia.
  • Kattavampi linkitys muualle HY:n ohjeistuksiin.
  • Auditointiohjeet, erityisesti tilaaminen ja kilpailutus.
  • Ohjeet salaisuuksien hallintaan. Enemmän operointia, mutta DevOps ei erottele.
  • Ohjeita turvallisen työympäristön kehitykseen ja linkkaukset muualle HY:n käytäntöihin ja -kanaviin.
  • HY:n tarjoamat tietoturvakoulutukset ja -verkostot sekä tietoturvaviestintä.
  • Erillisten tietosoujaohjeiden integrointi osaksi näitä.