Turvallisen sovelluskehityksen käsikirja



Turvallisen sovelluskehityksen k?sikirja TOC \o "1-3" \h \z \u 1Johdanto PAGEREF _Toc40680185 \h 51.1Millaiseen ohjelmistotuotantoon ohje on suunnattu? PAGEREF _Toc40680186 \h 51.2Ohjeen kohdeyleis? PAGEREF _Toc40680187 \h 62Vaatimustenmukaisuus PAGEREF _Toc40680188 \h 73Tietoturva ja tietosuoja ohjelmistokehitysprosessissa PAGEREF _Toc40680189 \h 113.1Yleiskuvaus PAGEREF _Toc40680190 \h 113.2Vaatimukset ohjelmistokehitysprosessille PAGEREF _Toc40680191 \h 123.3Vastuunjako PAGEREF _Toc40680192 \h 133.3.1Palvelunomistajan vastuut PAGEREF _Toc40680193 \h 153.3.2Tuoteomistajan vastuut PAGEREF _Toc40680194 \h 153.3.3Arkkitehtien vastuut PAGEREF _Toc40680195 \h 173.3.4Ohjelmistokehitt?jien vastuut PAGEREF _Toc40680196 \h 183.3.5Tietoturva-asiantuntijan vastuut PAGEREF _Toc40680197 \h 193.3.6Pilviasiantuntijan vastuut PAGEREF _Toc40680198 \h 193.3.7K?ytt?palvelun toimittajan vastuut PAGEREF _Toc40680199 \h 203.4Erityishuomioita tiettyihin ohjelmistokehitys- ja kulttuurisiin malleihin PAGEREF _Toc40680200 \h 203.4.1Scrum PAGEREF _Toc40680201 \h 203.4.2Kanban PAGEREF _Toc40680202 \h 213.4.3DevOps PAGEREF _Toc40680203 \h 213.4.4Automaatio, jatkuva integraatio ja toimitus PAGEREF _Toc40680204 \h 224Ohjelmistoturvallisuuden seurannan ja ulkoisen tuen malli PAGEREF _Toc40680205 \h 224.1Jatkuva tietoturvaty?n n?kyvyys ja ty?n j?lkik?teinen auditoitavuus PAGEREF _Toc40680206 \h 224.2Tukipalveluiden ty?nohjausmalli PAGEREF _Toc40680207 \h 225Tuotantoon viennin vaatimukset (Liite 1) PAGEREF _Toc40680208 \h 235.1Vaatimusten pakottavuus ja poikkeusten dokumentointi PAGEREF _Toc40680209 \h 235.2Tuotantoon viennin vaatimusten kriteerit PAGEREF _Toc40680210 \h 235.3Tuotantoon viennin vaatimukset PAGEREF _Toc40680211 \h 246Tietoturvallisuuden yleisperiaatteet (Liite 2) PAGEREF _Toc40680212 \h 256.1Tietoturvallisen arkkitehtuurin ja suunnittelun yleisperiaatteet PAGEREF _Toc40680213 \h 256.2K?ytt?palveluymp?rist?t ja operationaaliset yleisperiaatteet PAGEREF _Toc40680214 \h 296.3Tietosuojan suunnittelun yleisperiaatteet PAGEREF _Toc40680215 \h 316.4Auditoitavuuden yleisperiaatteet PAGEREF _Toc40680216 \h 336.5Kehitysymp?rist?jen ja tuotantoon viennin yleisperiaatteet PAGEREF _Toc40680217 \h 356.6Pilviymp?rist?jen tietoturvaperiaatteet ja -vaatimukset PAGEREF _Toc40680218 \h 376.7Tietoturvallisten palvelurajapintojen ja k?ytt?liittymien yleisperiaatteet PAGEREF _Toc40680219 \h 396.8 PAGEREF _Toc40680220 \h 416.9Tietoturvatestauksen ja teknisen tarkastuksen yleisperiaatteet PAGEREF _Toc40680221 \h 427Uuden tai muuttuneen toiminnallisuuden tietoturva- ja tietosuojaty?n tarkastuslista (Liite 3) PAGEREF _Toc40680222 \h 448Tietoturva-arkkitehtuurin dokumentoinnin v?himm?isvaatimukset (Liite 4) PAGEREF _Toc40680223 \h 469Uhkamallinnuksen toteutusohje (Liite 5) PAGEREF _Toc40680224 \h 479.1Uhkamallinnus yleisesti PAGEREF _Toc40680225 \h 479.2Uhkamallinnuksen aikataulutus PAGEREF _Toc40680226 \h 489.3Uhkamallinnus k?yt?nn?ss? PAGEREF _Toc40680227 \h 489.4Uhkamallinnuksen laatu PAGEREF _Toc40680228 \h 519.5Uhkamallinnus, kun tekninen ratkaisu on viel? tuntematon PAGEREF _Toc40680229 \h 5110Tietosuojan toteutumisen varmistaminen (Liite 6) PAGEREF _Toc40680230 \h 5310.1Tietosuojavaikutusten arviointi yleisesti PAGEREF _Toc40680231 \h 5310.2Tietosuoja-asetuksen vaatima tietosuojavaikutusten arviointi (DPIA) PAGEREF _Toc40680232 \h 5411Tekninen liite (Liite 7, ohje) PAGEREF _Toc40680233 \h 5511.1Palvelimen TLS-asetukset PAGEREF _Toc40680234 \h 5511.1.1Yleist? TLS-asetuksien noudattamisesta PAGEREF _Toc40680235 \h 5511.1.2Protokollaversio PAGEREF _Toc40680236 \h 5511.1.3Varmenteet PAGEREF _Toc40680237 \h 5611.1.4Varmenteiden my?nt?j?t PAGEREF _Toc40680238 \h 5711.1.5Salausalgoritmit PAGEREF _Toc40680239 \h 5711.2Muut kryptografiset toteutukset PAGEREF _Toc40680240 \h 5911.2.1Satunnaisen tunnisteen luominen eri ohjelmointikielill? PAGEREF _Toc40680241 \h 5911.3HTTP PAGEREF _Toc40680242 \h 6011.3.1Ev?steet PAGEREF _Toc40680243 \h 6011.3.2HTTP-otsakkeet selaimille PAGEREF _Toc40680244 \h 6011.3.3Subresource Integrity PAGEREF _Toc40680245 \h 6511.3.4Istuntotunnisteet PAGEREF _Toc40680246 \h 6611.4Lokitus PAGEREF _Toc40680247 \h 6711.4.1Pyynt?tunnisteet PAGEREF _Toc40680248 \h 6811.5Docker, Kubernetes ja Terraform PAGEREF _Toc40680249 \h 6911.5.1Is?nt?kone PAGEREF _Toc40680250 \h 6911.5.2Docker-kontin asetukset PAGEREF _Toc40680251 \h 6911.5.3Kubernetes PAGEREF _Toc40680252 \h 7111.5.4Terraform PAGEREF _Toc40680253 \h 7311.6Salaisuuksienhallinta PAGEREF _Toc40680254 \h 7311.7Ohjelmointirajapinnat (API) PAGEREF _Toc40680255 \h 7411.7.1API-turvallisuus yleisesti PAGEREF _Toc40680256 \h 7511.7.2Cross-Origin Resource Sharing (CORS) PAGEREF _Toc40680257 \h 7611.7.3CSRF-tunniste PAGEREF _Toc40680258 \h 7711.7.4Parametrit ja luottamuksellinen tieto PAGEREF _Toc40680259 \h 7712Technical Appendix (Appendix 7, instructions) PAGEREF _Toc40680260 \h 7812.1TLS settings of servers PAGEREF _Toc40680261 \h 7812.1.1Recommendations on TLS in general PAGEREF _Toc40680262 \h 7812.1.2Protocol version PAGEREF _Toc40680263 \h 7912.1.3Certificates PAGEREF _Toc40680264 \h 7912.1.4Certificate issuers PAGEREF _Toc40680265 \h 8012.1.5Encryption algorithms PAGEREF _Toc40680266 \h 8012.2Other cryptographic implementations PAGEREF _Toc40680267 \h 8212.2.1Creating random identifiers in various programming languages PAGEREF _Toc40680268 \h 8312.3HTTP PAGEREF _Toc40680269 \h 8312.3.1Cookies PAGEREF _Toc40680270 \h 8312.3.2HTTP headers towards browsers PAGEREF _Toc40680271 \h 8412.3.3Subresource Integrity PAGEREF _Toc40680272 \h 8912.3.4Session identifiers PAGEREF _Toc40680273 \h 8912.4Logging PAGEREF _Toc40680274 \h 9012.4.1The request identifier pattern PAGEREF _Toc40680275 \h 9212.5Docker, Kubernetes and Terraform PAGEREF _Toc40680276 \h 9212.5.1Docker hosts PAGEREF _Toc40680277 \h 9212.5.2Docker containers PAGEREF _Toc40680278 \h 9312.5.3Kubernetes PAGEREF _Toc40680279 \h 9412.5.4Terraform PAGEREF _Toc40680280 \h 9612.6Secrets management PAGEREF _Toc40680281 \h 9612.7Application Programming Interfaces (APIs) PAGEREF _Toc40680282 \h 9712.7.1API security in general PAGEREF _Toc40680283 \h 9812.7.2Cross-Origin Resource Sharing (CORS) PAGEREF _Toc40680284 \h 9912.7.3CSRF tokens PAGEREF _Toc40680285 \h 10012.7.4Confidential data in parameters PAGEREF _Toc40680286 \h 100JohdantoT?ss? dokumentissa kuvataan <organisaatio> sovelluskehityksen keskeiset tietoturvallisuuden periaatteet, vaatimukset sek? kontrollit. Dokumenttia k?ytet??n <organisaatio> sovelluskehityksess?.Millaiseen ohjelmistotuotantoon ohje on suunnattu?Ohje on kirjoitettu olettaen, ett? ohjelmistotuotannossa seurataan nykyaikaiselle ohjelmistotuotannolle ominaisia periaatteita:Kehitett?v?n kohteen toiminnallisuutta kehitet??n iteratiivisesti ja kehityksen kohde voi muuttua nopeastikin (agile eli ketter? kehitt?minen).Tuotetiimi on suurelta osin autonominen ja yhdess? tuoteomistajan kanssa kantavat liiketoimintavastuun my?s tietoturvasta ja joissakin tapauksissa my?s tuotannonaikaisista toimenpiteist? (DevOps ja DevSecOps).Tuotantoon viennin prosessi on automatisoitu, jos kyseess? on pilvipalvelu. Muissa tapauksissa integraation ja tuotantoon viennin automatisoinnille (continuous integration / delivery / deployment) ei saisi olla esteit?, vaikka sit? ei viel? olisikaan toteutettu. Jos kyseess? on pilvipalvelu, sen infrastruktuuri kuvataan versiohallittuna koodina (infrastructure as code tai declarative infrastructure). Tilanteessa, jossa n?it? periaatteita ollaan ottamassa k?ytt??n, ohjeen voi ottaa k?ytt??n soveltuvin osin samalla kun periaatteet kehittyv?t.K?sikirjan kuvaamat ty?nkulut on tarkoitettu k?ytett?v?ksi <organisaatio> kokonaisketter?n kehityksen viitekehyksess?. Se kuitenkin soveltuu k?ytett?v?ksi my?s yksitt?isiss? projekteissa, jotka eiv?t ole kokonaisketter?n kehityksen alaisuudessa.Mik?li ohjelmistotuotanto on osin ulkoistettu - esimerkiksi ostavalla organisaatiolla on tuoteomistaja, mutta itse ohjelmistokehitys tehd??n toimittajan toimesta toisaalla - ohjetta voi soveltaa niiden roolien osalta, jotka ovat ostavan organisaation hallussa. Muut ohjeen osat tulisi vaatia toimittajalta sopimuksin.Useat ohjeen tietoturvaperiaatteet on kirjoitettu niist? l?ht?kohdista, ett? arkkitehtuuri voi olla nk. pilvinatiivi ja palvelu- tai mikropalveluorientoitunut, ja ett? tuotetiimill? voi olla valtaa ja vastuuta k?yt?naikaisista toimenpiteist?. Ohjetta voi kuitenkin soveltaa, vaikka n?in ei olisikaan.Ohjeen kohdeyleis?Ohjeen kohdeyleis?n? ovat seuraavat roolit. Riippuen organisaatiosta, sama henkil? voi toimia useissa eri rooleissa. T?ss? ohjeessa roolien nimi? k?ytet??n siten kuin ne on kuvattu <organisaatio> roolikuvauksissa, eik? niill? ole v?ltt?m?tt? suoraa vastaavuutta virkanimikkeisiin. Tyypillisess? ohjelmistokehitystiimiss? henkil?ll? voi olla useita rooleja. Esimerkiksi p??kehitt?j?ll? on vastuita, jotka ulottuvat helposti arkkitehdin vastuualueelle. Itse palvelunsa infrastruktuurista huolehtivan tuotetiimin kehitt?jille kuuluu my?s k?ytt?palveluvastuita.Tarkempi roolien vastuunjako on kuvattu kappaleessa Vastuunjako.Palveluiden omistajat ("liiketoimintaomistajat"). Palveluiden omistajat vastaavat palvelun liiketoiminnan kehitta?misesta?, palvelun konseptista, strategiasta ja palvelun budjetoinnista. Viime k?dess? vastaavat my?s tietoturvan ja tietosuojan toteutumisesta resurssoinnin ja budjetoinnin kautta. Tietoturvasta huolehtimiseen kuuluvat palveluiden kriittisyysluokittelu, riskienhallinta sek? lakien ja hyv?n tiedonhallintatavan, ohjeiden ja politiikkojen noudattaminen.Tuoteomistajat (product owner). Tuoteomistaja arvopakettien analyysista? ja pilkkomisesta ominaisuuksiksi ja ka?ytta?j?tarinoiksi, sek? tuotetiimin tukemisesta ja tuotantoon vientien koordinoinnista yhdess? tuotetiimin kanssa. T?m?n vuoksi h?nell? on t?ll? tasolla my?s valtaa ajan ja muiden resurssien k?ytt??n ja j??nn?sriskien hyv?ksynt??n. Tuoteomistaja vastaa viime k?dess? siit?, ett? tietoturva- ja tietosuojavaatimukset ovat n?kyviss? teht?v?listalla.Arkkitehti vastaa kehitett?v?n palvelun tai sovelluksen sopivuudesta sit? ymp?r?iv??n tietotekniseen ymp?rist??n ja tunnistaa l?pileikkaavat asiat, joihin monet tietoturva- ja tietosuoja-asiatkin kuuluvat. Arkkitehti merkitt?v?ss? roolissa k?ytettyjen strategisten tekniikkavalintojen suhteen. Arkkitehdin suunnitteluhorisontti on yleens? koko palvelun elinkaaren mittainen, ja h?nelt? odotetaan n?kemyst? palvelun toteutukseen my?s erityisn?k?kulmista, joista t?m?n dokumentin n?k?kulmasta mainittakoon tietoturva-arkkitehtuuri ja jatkuvuussuunnittelu.Ohjelmistokehitt?j?t (tuotetiimeiss?). Ohjelmistokehitt?j?t toimivat useimmiten pienehk?iss? tiimeiss? ja ovat vastuussa toiminnallisuuden toteuttamisesta, testaamisesta, tuotantoon viennist?. Tietoturvamieless? ohjelmistokehitt?jill? on p??vastuu tietoturvan teknisest? toteutumisesta tuotehallinnan tarpeiden mukaisesti. Tuotetiimeiss? on my?s vastuuta ei-rutiininomaisista k?yt?naikaisista toimenpiteist?, joista tietoturvaan liittyv?t esimerkiksi lokien seuraamisen ja monitorointikyvykkyyden j?rjest?minen, jatkuvuuden hallinta, toipumissuunnittelu ja tuen antaminen tietoturvapoikkeamatilanteissa.Tietoturva-asiantuntijat. Tuoteomistajat, arkkitehdit ja ohjelmistokehitt?j?t voivat tarvittaessa k?ytt?? apuna erityisesti tietoturvaan keskittyneit? henkil?it?, joita ovat kehitysprojektiin varatut tietoturvatestaajat, -arkkitehdit tai -asiantuntijat. Tietoturva-asiantuntijat tukevat tyypillisesti tietoturvariskien l?yt?misess? ja arvioinnissa (esimerkiksi uhkamallinnuksessa), suunnitteluperiaatteiden ja ohjelmakoodin tarkistamisessa, tutkivassa tietoturvatestauksessa ja tietoturvaty?kalujen integroimisessa tuotantoon viennin automaatioon. My?s ohjelmistokehitystiimeiss? itsess??n voi olla tietoturvaan erikoistuneita henkil?it?. Tietoturva-asiantuntijat ovat t?ss? ohjeessa konsultatiivisessa roolissa, ja lopullinen vastuu tietoturvan toteutumisesta on yll?mainituilla rooleilla.Pilvipalveluasiantuntijat ("pilvitiimi"). Pilvitiimin vastuulla on pilvipalvelujen l?pileikkaavien tietoturvaratkaisujen kehitt?minen. Tuotetiimien on pystytt?v? luottamaan pilvitiimin suosittelemien pilviratkaisujen laadukkuuteen tietoturvan?k?kulmista.K?ytt?palvelujen toimittajat. <organisaatio> on voitava luottaa siihen, ett? k?ytt?palvelujen toimittaja takaa tietoturvan toteutumisen omalta osaltaan. Pilvipalveluilla on nk. jaetun vastuun malli, jonka vastuunjakolinja k?ytt?palvelun tarjoajan ja tuotetiimin v?lill? kulkee vaihtelevassa kohdin k?ytetty? teknologiapinoa (technology stack). Jakolinja voi vaihdella eri k?ytt?palvelujen tarjoajien v?lill?, vaikka k?ytett?v? teknologiapino olisi samankaltainen. T?m?n vuoksi pilvipalveluita k?ytett?ess? k?ytt?palvelujen tarjoajan ja <organisaatio>:n v?lisen vastuujaon on oltava selke?sti ymm?rrettyVaatimustenmukaisuusJokaisesta pakollisesta vaatimuksesta sek? valinnaisista toteutettavaksi p??tetyist? vaatimuksista on luotava joko vaatimus tuotteen teht?v?listalle tai vaatimuksen t?yttymist? on ajettava jollakin tietoturva-aktiviteetilla, josta j?? todiste (kuten esimerkiksi testitulos). T?ll? tavoin vaatimuksista syntyy auditoitavissa oleva todiste my?hemp?? tarvetta varten.Pakolliset (lakiin perustuvat) vaatimukset otetaan huomioon kokonaisketter?n kehitysmallin portfoliokanbanissa. Tuotantoon viennin vaatimukset otetaan huomioon p??osin kokonaisketter?n kehityksen suunnittelutasolla. N?m? johtavat todenn?k?isesti lopulta teht?v?listan teht?viin, joilla vaatimustenmukaisuus syntyy.Yleiset tietoturvaperiaatteet on koottu ryhmiksi, joista kussakin roolissa olevan henkil?n on omaksuttava omaan rooliinsa liittyv?t periaatteet ja huolehtia periaatteiden noudattamisesta oman ty?ns? viitekehyksess?. Esimerkiksi k?ytt?liittym?suunnittelijoiden tulisi tutustua rajapintoja ja k?ytt?liittymi? koskeviin yleisiin tietoturvavaatimuksiin.VaatimustyyppiVaatimusl?hdeKuka voi p??tt?? vaatimuksen tekem?tt? j?tt?misest?HuomioitaPakolliset vaatimuksetKansallinen lains??d?nt?, GDPR [*], eIDAS [*] ja tuleva ePrivacy-asetusHuomioidaan portfoliokanbanissa.Lain ja asetusten vaatimuksia ei voi j?tt?? tekem?tt?. <organisaatio>:n tietosuojavastaava voi tarjota apuaan niiden tulkinnassa.Tulkinnat on dokumentoitava Business Outcome -dokumenttiin.Tuotantoon viennin vaatimuksetLiite 1: Tuotantoon viennin vaatimuksetTuoteomistaja konsultoituaan <organisaatio>:n tietoturvahenkil?st??Huomioidaan suunnittelukanbanissa.Tietoturvavaatimuksesta poikkeaminen on dokumentoitava Business Outcome -dokumenttiin.Yleiset tietoturvaperiaatteetLiite 2: Tietoturvallisuuden yleisperiaatteetTuotetiimi konsultoituaan <organisaatio>:n tietoturvahenkil?st??Kussakin roolissa toimiva henkil? tutustuu itselleen olennaisiin periaatteisiin ja huolehtii niiden t?yttymisest? oman ty?ns? kontekstissa.Tekem?tt? j?tt?misp??t?s on dokumentoitavaLis?tietol?hteetKs. seuraava taulukkoTuotetiimiN?ist? l?hteist? otetaan vaatimuksia mukaan vain tarvittaessa, esimerkiksi kun tarvitaan tietyn aihealueen tarkempaa ohjeistusta.Yll? mainittujen vaatimustyyppien lis?ksi tietyt ulkoiset l?hteet on valittu lis?tietol?hteiksi. Lis?tietol?hteet on tarkoitettu ensisijaisiksi l?hteiksi tietoturva-aktiviteetteja laajennettaessa esimerkiksi asiakasvaatimusten pohjalta. Tuoteomistajan tulee tunnistaa asiakasvaatimuksista tietoturvatarpeet ja k?ytt?? n?it? l?hteit? – mahdollisesti tietoturva-asiantuntijan avustuksella – vaatimuksen t?ytt?miseen. Lis?tietol?hdeSoveltamisalaLinkki l?hteeseenOWASP Application Security Verification Standard (ASVS)Tietoturvatestauksen ja auditoinnin m??rittely tehd??n l?ht?kohtaisesti ASVS Level 2 -tason mukaisestiOWAP ASVSMITRE ATT&CK Enterprise MatrixK?ytt?ymp?rist?jen ja sovellusten uhkamallien muodostaminen. Pilvipalveluissa Cloud Matrixin mukaisestiMITRE ATT&CK Enterprise MatrixMITRE ATT&CK Cloud MatrixCIS BenchmarksYksitt?isten teknologioiden suojaamis- ja kovennusohjeistusCIS BenchmarksPilvipalveluiden turvallisuuden arviointikriteerist? (PiTuKri)Pilvipalveluiden valinta ja vastuunjaon m??ritt?minen, kun k?sitell??n salassa pidett?v??, henkil?- tai turvaluokiteltua tietoaPiTuKriGuidelines on Data Protection Impact Assessment (DPIA) wp248rev.01Tietosuojavaikutusten arviointiWp248rev.01VAHTI Sovelluskehityksen tietoturvaohje 1/2013Turvallinen sovelluskehitys niilt? osin, kun tarvitaan lis?ohjeistusta t?m?n k?sikirjan lis?ksiVAHTI 1/2013Tietoturva ja tietosuoja ohjelmistokehitysprosessissaYleiskuvausTietoturva ja tietosuoja tuodaan tuotekehitysprosessiin tekem?ll? ne n?kyv?ksi ty?nohjauksessa. Yleisell? tasolla t?rkein perusperiaate on esitetty kuvassa.Tietoturva- ja tietosuojaty? alkaa kokonaisketter?n kehitysmallin portfolio- ja suunnittelutasoilla. N?ill? tasoilla luodaan edellytykset suurimpien tietoturvavaatimusten noudattamiselle.Tekstin sujuvuuden vuoksi dokumentissa puhutaan jatkossa p??osin tietoturvaty?st?, vaikka sill? tarkoitetaan my?s tietosuojaty?t?. Samaten tietoturvateht?v? voi olla mink? tasoinen teht?v? vain, esimerkiksi k?ytt?j?tarina tai yksinkertainen bugikorjaus.Valtaosa k?yt?nn?n suunnittelun ja toteutuksen tietoturva- ja tietosuojaty?st? tuodaan n?kyv?ksi tuotteen teht?v?listalla (engl. product backlog). T?rkein ty?teht?v? on uhkamallinnus (threat modelling), jossa l?ydet??n suurin osa muista tarpeellisista tietoturvateht?vist?.Uhkamallinnuksen tarve sidotaan yksitt?isiin tuotteen teht?v?listan teht?viin. Suositeltava tapa on valita tiimille sopiva teht?v?koko, joihin uhkamallinnus liitet??n erillisen? tikettin? tai hyv?ksynt?kriteerin? oletusarvoisesti aina. Tuotetiimi tai tuoteomistaja suorittaa tarvearvioinnin (triage) ja voi sen pohjalta tehd? p??t?ksen, ett? uhkamallinnusta ei suoriteta. T?m? p??t?s voidaan dokumentoida esimerkiksi kommenttina tikettiin.Tuotetiimi suorittaa uhkamallinnuksen ja lis?? sen perusteella l?ytyneet uudet tietoturvateht?v?t teht?v?listalle.L?ytyneet tietoturvateht?v?t luokitellaan (label) yhteisesti sovittuihin luokkiin, ja linkitet??n siihen toteutusteht?v??n, johon ne liittyv?t. N?in organisaation tietoturvahenkil?st? voi seurata tietoturvaty?n kertymist? ja etenemist? ja mahdollisessa auditointitilanteessa on helpompi l?yt?? todisteet tehdyst? ty?st?.T?rkeimm?t dokumentissa mainitut tietoturvateht?v?t ovat uhkamallinnus, tietosuojavaikutusten arviointi, tietoturva-arkkitehtuurin yll?pito ja tietoturvatestaus. N?iden v?linen suhde on tiivis. K?yt?nn?ss? kaikissa teht?viss? on yhteisi? osa-alueita, ja ne hy?tyv?t toisistaan n?ilt? osin - sama ty? tehd??n vain kertaalleen. Suhdetta voidaan kuvata seuraavasti:Vaatimukset ohjelmistokehitysprosessilleJotta ohjelmistokehitysprosessi mahdollistaa tietoturvallisen kehityksen ja tietosuojan tason t?m?n ohjeen mukaisesti, sen on t?ytett?v? joitakin perusvaatimuksia. Ohjelmistokehitys, jossa seuraavat vaatimukset eiv?t t?yty, ei ole t?m?n tietoturvaohjeen mukainen. T?m? koskee ohjelmistokehityst? my?s alihankintatilanteessa, vaikka alihankkijan prosessit ja ty?kalut eiv?t olisikaan ostajalle n?kyviss?.Huoltovarmuuskriittisten j?rjestelmien toteutuksessa n?iden vaatimusten toteutumisesta, esimerkiksi kehitys- ja tuotantoon vientity?kalujen saatavuudesta, on huolehdittava my?s jatkuvuussuunnittelumieless?.Ohjelmistotuotantoprosessissa on oltava k?yt?ss?:Tuotteen teht?v?lista (product backlog), joka on priorisoitu luettelo ty?teht?vist?, joita tuotteen (palvelun tai sovelluksen) toteuttamiseksi on teht?v?. Teht?vill? voi olla eri tasoja, kuten epic, kertomus eli story ja teht?v? eli task. T?ss? dokumentissa "teht?v?" voi olla mink? tahansa tasoinen.Tuoteomistajan (product owner) rooli, joka on kuvattu aiemmin t?m?n ohjeen kohderyhm?n?.Tietoturva- ja tietosuojariskien hyv?ksyminen on p??osin vastuutettu t?lle roolille kuten aiemmassa vaatimusluokittelussa on kuvattu.Tietoturvaty?n priorisointi suhteessa muuhun ty?h?n on oltava vastuutettu t?lle roolille, eik? esimerkiksi erilliselle ohjausryhm?lle.Tiket?intiin pohjautuva ty?nohjausj?rjestelm?, joka tukee luokituksia (label tai tag). T?m? tarkoittaa sit?, ett? teht?v?listalla olevien ty?teht?vien edistymist? voidaan erikseen ja yksitt?in seurata, ty?listalle ilmestyv?t tietoturva- ja tietosuojateht?v?t voidaan helposti huomata, ja ty?teht?vien teosta j?? auditoitava j?lki. Useimmiten tuotteen teht?v?lista ja ty?nohjausj?rjestelm? toimivat samassa ty?kalussa, mutta v?ltt?m?tt? n?in ei ole.Koodin versionhallintaj?rjestelm?, joka mahdollistaa koodin vertaiskatselmoinnin koordinoidun suorittamisen osana toteutusty?t?. T?llainen voi olla esimerkiksi nk. pull request -menettely.Pilvipalveluissa tuotantoon viennin automaatio (nk. CI/CD-putki), joka mahdollistaa pilvipalvelun infrastruktuurin m??ritt?misen koodina, tuotantoon viennin mahdollisimman v?h?isell? ihmisty?ll? sek? jossain m??rin mahdollisuuksia tietoturvatestauksen automatisointiin.Teht?v?listan ja ty?nohjausj?rjestelm?n on k?yt?nn?ss? tarpeen el?? ty?kalussa, joka on standardoitu useamman projektin v?lille, koska esimerkiksi linkkien luominen eri projektien ty?teht?vien v?lill? on t?rke??. T?llainen ty?kalu on <organisaatio>:n k?ytt?m? Jira-j?rjestelm?.VastuunjakoOhjeen kohdeyleis? -kappaleessa luetelluilla rooleilla on tarkasti m??ritellyt vastuualueet. Vastuu seuraa rooleja eik? henkil?it?; henkil?ll? voi olla useita rooleja ja toisaalta rooli voi olla jaettu useammalle henkil?lle.Mik?li rooli on jaettu useammalle henkil?lle, n?iden henkil?iden osalta on sovittava, kuka kantaa p??vastuut seuraavassa luetelluista tietoturvavastuista. Mik?li p??vastuullista henkil?? ei ole jaetun roolin tilanteessa m??ritelty, ohjelmistokehitysprosessi ei ole t?m?n tietoturvaohjeen mukainen.Vastuutus on viestitt?v? kohdeyleis?tahoille.RooliVastuut (tarkemmin alla)PalvelunomistajaTietoturva- ja tietosuojaty?n resurssointi ja budjetointiPalvelun kriittisyysluokittelu ja riskienhallintaLakien, hyv?n tiedonhallintotavan, politiikkojen ja ohjeiden noudattaminenTuoteomistajaVaatimuksista poikkeamisesta p??tt?minen (j??nn?sriskin hyv?ksynt?)Tietoturvavaatimusten n?kyvyyden varmistaminen tuotteen teht?v?listallaUuden ja muuttuvan toiminnallisuuden tietosuojavaikutusten arviointiTietoturva- ja tietosuojaty?n priorisointi suhteessa muuhun ty?h?nArkkitehtiYleisten ja l?pileikkaavien tietoturvaperiaatteiden noudattaminen suunnittelussaYleisen tietoturva-arkkitehtuurin rakentaminen ja yll?pitoOhjelmistokehitt?j?Tietoturvaty?n tiket?inti ja siirto tuotteen teht?v?listalleTietoturvaty?n suorittaminen, mukaan lukien k?yt?naikaiset ei-rutiininomaiset tietoturvateht?v?t Rajatuissa tapauksissa vaatimuksista poikkeamisesta p??tt?minen ja t?ten j??nn?sriskin hyv?ksyminen (yleens? koko tuotetiimi yhdess?)Tietoturva-asiantuntijaSovitun tietoturvaty?n suorittaminen ja dokumentointi (silt? osin, kun sovittu ohjelmistokehitt?jien kanssa)Pilvipalveluasiantuntija (esim. osana pilvi-infrastruktuurin tukitiimi?)Tietoturvaty?n koordinointi tuotetiimien v?lill? jaettujen palvelujen osaltaPilvi-infrastruktuurin parhaiden k?yt?nteiden levitt?minen kaikille tiimeilleJaettujen tietoturvaan liittyvien palveluiden tarjoaminenK?ytt?palvelun toimittajaSovitun tietoturvaty?n suorittaminen ja dokumentointi?Palvelunomistajan vastuutTietoturva- ja tietosuojaty?n resurssointi ja budjetointiPalvelunomistajien on otettava huomioon tietoturvaty?n tarvitsemat resurssit sek? ajallisessa ett? rahallisessa budjetoinnissa. Ajallisesti tietoturvaty? aiheuttaa jonkin verran ty?t? esimerkiksi uhkamallinnuksen muodossa. Budjetointimieless? ulkoisilta tahoilta ostetut tietoturvatarkastukset ovat suurimpia yksitt?isi? menoeri?. Resurssointimieless? palvelunomistaja voi vaikuttaa my?s ohjeistamalla tietoturvaty?n painopistealueita esimerkiksi tuomalla tietoturvaty?t? aikaisempaan kehitysty?n vaiheeseen ja vaatimalla tietoturvaty?n n?kyvyytt? teht?v?listoilla, jolloin kustannusten seuranta on mahdollista.Palvelun kriittisyysluokittelu ja riskienhallintaPalvelunomistajien tulee m??ritell? palvelun kriittisyys ja pit?? yll? kuvaa siihen liittyvist? tietoturvariskeist?. Kriittisyysluokan ja riskien tulee olla sidoksissa palvelun toteutuksen (toiminnallisiin tai ei-toiminnallisiin) vaatimuksiin. N?in voidaan parhaassa tapauksessa johtaa suora vaatimuslinja kriittisyysluokasta ja riskeist? toteutustason teht?viin. Lakien, hyv?n tiedonhallintotavan, politiikkojen ja ohjeiden noudattaminenPalvelunomistajien tulee olla tietoisia palveluun kohdistuvasta lains??d?nn?st? ja muusta regulaatiosta. Kuten my?s kriittisyysluokan ja riskien osalta (yll?), lains??d?nn?n ja politiikojen vaatimusten tulisi olla sidoksissa palvelun (toiminnallisiin tai ei-toiminnallisiin) vaatimuksiin. N?in voidaan parhaassa tapauksessa johtaa suora vaatimuslinja toteutustason teht?viin.Tuoteomistajan vastuutVaatimuksista poikkeamisesta p??tt?minen (j??nn?sriskin hyv?ksynt?)Mik?li ohjelmistotuotantoprosessissa on tarve poiketa tietoturva- tai tietosuojavaatimuksista, tuoteomistajan tai joissakin rajatuissa tapauksissa tuotetiimin on teht?v? p??t?s t?st? aiheutuvan riskin hyv?ksynn?st?. P??t?s on dokumentoitava (esimerkiksi huomioimalla riskin mahdollisuus tietoturva-arkkitehtuuridokumentissa tai yksitt?isten teknisten vaatimusten osalta tiketin kommenteissa). P??t?nt?valta on kuvattu tarkemmin kappaleessa Vaatimustenmukaisuus.Tietoturvavaatimusten n?kyvyyden varmistaminen tuotteen teht?v?listallaTuoteomistajan on varmistettava, ett? tietoturvavaatimukset on tunnistettu. Vaatimusl?hteet on lueteltu kappaleessa Vaatimustenmukaisuus. Tuoteomistaja varmistaa, ett? n?m? vaatimukset on muutettu tuotteen teht?v?listalle teht?viksi. Teht?v?t voivat olla eri tasoisia (esimerkiksi kehitysaihio- (epic-) tai kertomustasoisia).Laeista ja asetuksista kumpuavat vaatimukset voivat olla haastavia, kun vaatimuksia muutetaan teht?viksi. T?m?n vuoksi tuotantoon vientivaatimukset (Liite 1: Tuotantoon viennin vaatimukset) ja yleiset tietoturvavaatimukset (Liite 2: Tietoturvallisuuden yleisperiaatteet) on tehty kattamaan useimmat lakitekniset vaatimukset. On kuitenkin erityistilanteita, joissa ne eiv?t v?ltt?m?tt? riit?, jolloin tilanteen analysointi yhdess? lain tulkitsijan – esimerkiksi organisaation juristin – kanssa on tarpeen.Joissakin tapauksissa pakollinen vaatimus ei v?ltt?m?tt? ole yksitt?inen toiminnallisuus tai teht?v?, vaan esimerkiksi vaatimus tehd? ohjelmistokehityst? tietyll? tavalla, kuten esimerkiksi vaatimus tehd? jatkuvaa koodikatselmointia. Jatkuvia tai yh? uudelleen toistuvia teht?vi? ei voi j?rkev?sti vied? tuotteen teht?v?listalle.?T?ll?in se voidaan muuttaa prosessikehitysteht?v?ksi esimerkiksi "kehitt?j?t m??rittelev?t koodikatselmointiperiaatteet ja kouluttavat sen kaikille tiimil?isille" tai portfolioty?ss? mukaan otetaan tarvittavia sidosryhmi?, jotka muutoin eiv?t olisi olleet mukana.K?yt?nn?ss? monien toiminnallisten vaatimusten vienti teht?v?listalle voidaan tehd? kertaluonteisesti merkitt?v?n uuden kehityshankkeen alussa. Yll?pitovaiheessa tilanne voidaan katselmoida esimerkiksi vuosittain. Tuoteomistajan varmistettava, ett? tietoturvaan ja tietosuojaan liittyv?t teht?v?t on merkitty tikettipohjaisessa ty?nohjausj?rjestelm?ss? erityisin luokituksin (label). N?in organisaation tietoturva- ja tietosuojaorganisaatiot voivat seurata n?iden osa-alueiden etenemist?.Luokituksissa k?ytett?v?t avainsanat on kuvattu dokumentissa Liite 3: Uuden tai muuttuneen toiminnallisuuden tietoturva- ja tietosuojaty?n tarkastuslista.Luokitukset on tarkoitettu ainoastaan auditoitavuus- ja seurantatarkoituksiin. Luokituksilla ei ole vaikutusta priorisointiin eik? ty?teht?vien elinkaaren vaiheisiin. Niit? ei my?sk??n k?ytet? ryhmittelem??n ty?nohjaustikettej?.Uuden ja muuttuvan toiminnallisuuden tietoturvavaikutusten arviointiTuoteomistajan on vaadittava toteutuksen hyv?ksynt?kriteerein? tietoturvariskien selvitys ("uhkamallinnus") sek? mahdollisesti soveltuvan tasoinen tietoturvatarkistus. Uhkamallinnuksen yleinen ohje on Liite 5: Uhkamallinnuksen toteutusohje. Uhkamallinnusteht?v? on n?kyviss? tuotteen teht?v?listalla.Mik?li on selv??, ett? toteutuksessa ei ole tietoturvariskej?, uhkamallinnus voidaan j?tt?? tekem?tt?. K?yt?nn?ss? tuoteomistajalla on k?yt?ss??n lyhyt ja korkealla tasolla kirjoitettu tarkastuslista (Liite 3: Uuden tai muuttuneen toiminnallisuuden tietoturva- ja tietosuojaty?n tarkastuslista), jonka perusteella riskialttiit toiminnot voidaan tunnistaa. Yleens? tuoteomistajan on helpointa tehd? t?m? uhkamallinnustarpeen arviointi osana tuotteen teht?v?listan parannusty?t? (backlog maintenance, backlog grooming).Uuden ja muuttuvan toiminnallisuuden tietosuojavaikutusten arviointiVastaavasti kuin edell? tietoturvan osalta, my?s tietosuojaan vaikuttava uusi tai muuttunut toiminnallisuus on tunnistettava. T?m? tehd??n samalla tavalla kuin tietoturvan osalta, mutta tietoturvauhkamallinnuksen sijaan tai lis?ksi tuoteomistaja luo tuotteen teht?v?listalle vaatimuksen tietosuojavaikutusten arvioinnista (DPIA, data protection impact assessment). K?sitteellisesti kyse on saman tyyppisest? ty?st?. Ohje on dokumentissa Liite 6: Tietosuoja.Tietoturva- ja tietosuojaty?n priorisointi suhteessa muuhun ty?h?nTuoteomistaja m??rittelee tuotteen teht?v?listalla olevien teht?vien keskin?isen prioriteetin. K?yt?nn?ss? t?m? tarkoittaa, ett? tuoteomistaja m??rittelee teht?viin k?ytett?viss? olevan ajan.Koska tietoturva- ja tietosuojaty? on n?kyviss? tuotteen teht?v?listalla, t?m? tarkoittaa sit?, ett? tuoteomistaja p??tt?? my?s t?m?n ty?n prioriteeteista ja sit? kautta hyv?ksyy j??nn?sriskin, mik?li tietoturvateht?v?t v?istyv?t muiden (toteutus)teht?vien tielt?.Arkkitehtien vastuutYleisten tietoturvaperiaatteiden noudattamisen suunnittelussaArkkitehti on vastuussa siit?, ett? yleisi? arkkitehtuuriperiaatteita noudatetaan ohjelmiston suunnittelutoiminnassa. Arkkitehtuuriperiaatteet on kuvattu kappaleessa Tietoturvallisen arkkitehtuurin ja suunnittelun yleisperiaatteet.Yleisen tietoturva-arkkitehtuurin m??rittely ja yll?pitoArkkitehtiroolin vastuulla on my?s yleisen tietoturva-arkkitehtuurin yll?pito yli kaikkien toteutustiimien. T?h?n liittyv?t muun muassa tiimien v?liset tietoturvaolettamat ja viestiminen k?ytt?palveluiden tuottajien kanssa siit?, miten k?ytt?palvelut vaikuttavat sovellustason tietoturva-arkkitehtuuriin.Ohjelmistokehitt?jien vastuutTietoturvaty?n tiket?inti ja siirto tuotteen teht?v?listalleJotta tietoturvaty? tulisi n?kyv?ksi ja sille varattaisiin riitt?v?sti aikaa, ohjelmistokehitt?jien t?rkeimpi? vastuita on varmistua siit?, ett? tietoturvaty? n?kyy ty?nhallintaj?rjestelm?ss?. Kun tietoturvaty? on kirjattu teht?v?ksi tikettiin, esimerkiksi ty?jaksojen sis?lt?? m??ritelt?ess? on selke?mp??, paljonko aikaa tietoturvaty? vie.Mik?li ohjelmistokehitt?j? havaitsee uutta tietoturvaty?t?, jota pit?isi tehd?, heid?n vastuullaan on lis?t? se tuotteen teht?v?listalle. Tyypillisimmin t?m? tapahtuu uhkamallinnuksen seurauksena, jolloin l?ydettyjen riskien hallitsemiseksi luodaan uusia teht?vi?.N?kyvyyden varmistamiseksi ohjelmistokehitt?jien tulee my?s luokitella tiketit kuten Liite 3: Uuden tai muuttuneen toiminnallisuuden tietoturva- ja tietosuojaty?n tarkastuslista kuvaa.Tietoturvaty?n suorittaminen ja dokumentointiVastuu tietoturvaty?n suorittamisesta on ohjelmistokehitt?jill?.On selv??, ett? kaikki ohjelmistokehitystiimit eiv?t aina pysty suorittamaan kaikkia n?it? tietoturvateht?vi? aika- tai kompetenssirajoitteista johtuen. Vastuu ei kuitenkaan t?ll?in siirry, vaan rajoite on ratkaistava joko koulutuksella, priorisoinnilla tai tiimin ulkopuolisiin resursseihin tukeutumalla.Joissakin tapauksissa ymp?r?iv? organisaatio voi luoda palvelun, jonka k?ytt? on kustannustehokkaampaa kuin tiimin sis?isten resurssien k?ytt?. Esimerkiksi tutkivan tietoturvatestauksen asiantuntijaresurssit voi olla tehokkaampaa hankkia keskitetysti koko organisaation k?ytt??n.Toteutusaikainen tietoturvaty? koostuu yleisimmin seuraavista teht?vist?:Kehitysymp?rist?jen ja -ty?kalujen tietoturvasta vastaaminen (ks. kappale Kehitysymp?rist?jen ja tuotantoon viennin yleisperiaatteet)Uhkamallinnus (ks. Liite 5: Uhkamallinnuksen toteutusohje ja kappale Tietoturvallisen arkkitehtuurin ja suunnittelun yleisperiaatteet)Tietosuojavaikutusten arviointi (ks. Liite 6: Tietosuoja)Koodikatselmointi tai staattinen analyysi (eli koneellinen koodikatselmointi)Automaattisten testitapausten toteutus (ks. kappale Tietoturvatestauksen ja teknisen tarkastuksen yleisperiaatteet)Tutkiva tietoturvatestaus (ks. kappale Tietoturvatestauksen ja teknisen tarkastuksen yleisperiaatteet)Ohjelmistoriippuvuuksien haavoittuvuusseuranta ja paikkaus (ks. kappale Tietoturvallisen arkkitehtuurin ja suunnittelun yleisperiaatteet)Tuotantoon viennin tietoturvadokumentaation yll?pito (ks. kappale Kehitysymp?rist?jen ja tuotantoon viennin yleisperiaatteet)Palvelun (mukaan lukien tuotetiimin yll?pit?m?n infrastruktuurin) monitoroinnin ja tietoturvapoikkeamiin reagoinnin j?rjest?minenTehdyn tietoturvaty?n dokumentointi tehd??n ensisijaisesti tiket?intij?rjestelm??n ja versiohallittuihin dokumentteihin (esimerkiksi wiki).Mik?li ohjelmistokehitt?j?t tukeutuvat joiltakin osin k?ytt?palvelutoimittajan komponentteihin (esimerkiksi k?ytt?j?rjestelm??n tai pilvipalvelun orkestrointirajapintaan), ohjelmistokehitt?jien vastuulla on m??ritell? vastuunjaon raja k?ytt?palvelutoimittajaan n?hden. K?ytt?palvelutoimittajan vastuualueista on sovittava sopimuksellisesti.Tietoturva-asiantuntijan vastuutSovitun tietoturvaty?n suorittaminen ja dokumentointiTietoturva-asiantuntijan vastuulla on h?nelt? pyydetyn tietoturvaty?n toteuttaminen riskil?ht?isesti ja parhaan asiantuntemuksensa mukaisesti. H?nen on my?s dokumentoitava tietoturvaty?n tulokset. Dokumentointi tehd??n ensisijaisesti tiket?intij?rjestelm??n ja versiohallittuihin dokumentteihin (esimerkiksi wiki). Tietoturvatestaukseen ja -tarkastukseen liittyv?t vaatimukset on lueteltu kappaleessa Tietoturvatestauksen ja teknisen tarkastuksen yleisperiaatteet.Pilviasiantuntijan vastuutTietoturvaty?n koordinointi tuotetiimien v?lill? jaettujen palveluiden osaltaUseamman tuotetiimin (kehitystiimin) k?ytt?ess? jaettua tai keskitetysti suositeltua pilvipalvelua pilviasiantuntijan (pilvitiimin) vastuulla on koordinoida tietoturvaty? tuotetiimien v?lill?.Yksinkertaisimmillaan t?m? voi olla esimerkiksi tietoturvallinen k?ytt?- ja kovennusohje tai tietoturvatarkastuksen tarjoaminen tietylle pilvipalvelulle.Mik?li useampi tiimi k?ytt?? jaettua palvelua, pilvitiimin vastuulla on koordinoida, etteiv?t tiimit vahingossa riko toistensa tietoturvaolettamia.Pilvi-infrastruktuurin parhaiden k?yt?nteiden levitt?minen kaikille tiimeillePilvi-infrastruktuurin parhaat k?yt?nteet kehittyv?t varsin nopeasti ja pilvipalveluntarjoajilla on paljon uusia (tietoturva)palveluita ja materiaalia. N?iden seuraaminen erikseen jokaisen tuotetiimin (kehitystiimin) osalta ei ole v?ltt?m?tt? j?rkev??.Pilviasiantuntijan (pilvitiimin) vastuulla on identifioida olennaisimmat ja parhaat k?yt?nteet, esimerkiksi pilvipalveluntarjoajan uudet tietoturvaan liittyv?t asetukset ja referenssiarkkitehtuurit ja levitt?? n?ist? helposti ymm?rrett?v?? tietoa tuotetiimeille.Jaettujen tietoturvaan liittyvien palveluiden tarjoaminenKaikkia tietoturvaan liittyvi? palveluita ei ole tarkoituksenmukaista tuottaa jokaisessa tuotetiimiss? (kehitystiimiss?), vaikka ne olisivatkin DevOps-tiimej?. T?llaisia ovat esimerkiksi lokien ker?yksen tekninen j?rjest?minen ja palvelunestohy?kk?yssuojaus kaikille organisaation palveluille. Pilviasiantuntijan (pilvitiimin) vastuulla on identifioida ne tietoturvapalvelut, jotka kannattaa tuottaa keskitetysti joko kustannus-, tehokkuus- tai tietoturvasyist? ja tarjota niit? tuotetiimien k?ytt??n.Jaetuissa palveluissa on kuitenkin huomioitava, ett? tuotetiimi ymm?rt?? oman vastuunsa rajat. Esimerkiksi lokien ker?yksess? niiden tekninen ker?ys voidaan m??ritell? yhteisesti, mutta lokien sis?lt? ja niiden tulkintaohje esimerkiksi <organisaatio>:n SOCille ovat edelleen tuotetiimien vastuulla, koska ne ovat palvelukohtaisia.K?ytt?palvelun toimittajan vastuutSovitun tietoturvaty?n suorittaminen ja dokumentointiK?ytt?palvelun toimittajilta odotetaan, ett? se suorittaa k?ytt?palveluja hankkivan organisaation kanssa sovitun tietoturvaty?n. Viitteellisesti n?m? kattavat kappaleissa Auditoitavuuden yleisperiaatteet ja K?ytt?palveluymp?rist?t ja operationaaliset yleisperiaatteet luetellut asiat.Muut k?ytt?palvelutoimittajan osalle siirretyt vastuut on m??ritelt?v? sopimuksellisesti.Erityishuomioita tiettyihin ohjelmistokehitys- ja kulttuurisiin malleihinKetter?? ja lean-ohjelmistokehityst? voidaan tehd? useilla eri malleilla. T?ss? kappaleessa on lyhyesti kuvattu, miten yll? mainitut vastuut voidaan ottaa mukaan kussakin mallissa.ScrumUhkamallinnuksen tarpeen arviointi voidaan sis?llytt?? teht?vien Definition of Ready -kriteereihin, jos niit? k?ytet??n esiehtona ty?n aloittamiselle.Tietoturvaty?teht?v?t sis?llytet??n Scrum-ty?jaksoihin (sprint) aivan kuin ne olisivat toiminnallisten vaatimusten toteutusta. Esimerkiksi uhkamallinnuksen ja tutkivan tietoturvatestauksen tarve tuodaan esille teht?v?n? tai teht?v??n sidottuna hyv?ksynt?kriteerin?.Yleisi? kaikkiin kehitysteht?viin liittyvi? Definition of Done -kriteereit? ei k?ytet? tietoturvaty?n ohjaamiseen, koska t?ll?in niille ei erikseen varata aikaa. Ohjelmistokehitt?j?t saavat toki omatoimisesti tehd? tietoturvaan liittyvi? Definition of Done -kriteerej? oman laadunvalvontansa tueksi.Jos tietoturvaty? luodaan teht?v?listalle erillisen? teht?v?n?, se merkit??n yleens? riippuvuudeksi toiminnallisuuden toteutuksen valmistumiselle. T?m? tehd??n tyypillisess? tiket?intij?rjestelm?ss? linkitt?m?ll? teht?v?t toisiinsa.Koska Scrum-ty?jakson suunnitteluvaiheessa (sprint planning) on yleens? sitouduttava tiettyyn ty?m??r??n, esimerkiksi uhkamallinnusty? kannattaa yleens? tehd? aiemmassa ty?jaksossa kuin miss? varsinainen toiminnallisuus toteutetaan. Uhkamallinnus saattaa muuttaa ty?m??r?arvioita voimakkaastikin.KanbanTietoturvaty?teht?vien hallinta noudattelee Scrumin mallia (yll?). Koska kanban-menetelm?ss? ei ole ty?jakson pituuteen perustuvaa ty?m??r?n (Work in Progress) rajoitusta, esimerkiksi uhkamallinnus on luonnollisemmin toteutettavissa toiminnallisuuden hyv?ksynt?kriteerin? sen sijaan, ett? se olisi erillinen ty?teht?v?.DevOpsKulttuurisena k?sitteen? DevOps eli autonomisten kehitys- ja tuotantoaikaisista toimenpiteist? vastaavien tiimien luominen on tietoturvan kannalta l?hes aina positiivinen asia. DevOps-kypsyyden parantaminen on t?m?n vuoksi suositeltavaa.Tietoturvan yhteydess? k?ytet??n enenev?ss? m??rin termi? DevSecOps, jolla viitataan siihen, ett? tuotetiimill? on vastuuta k?yt?naikaisten toimenpiteiden (Ops) lis?ksi my?s tietoturvasta (Sec).Pilvipalveluiden osalta tuotetiimin vastuuttaminen tietoturvan k?yt?naikaiseen havainnointiin ja reagointiin voi olla kuormittavaa ja vaatia kehittyneit? ty?kaluja. Vastuuta ei voi siirt?? tuotetiimille ilman riitt?v?? tukea ja resursseja, joten organisaation on l?ydett?v? kehitystiimeille sopiva malli, jossa tiimit voivat tukeutua kaikille yhteisiin malleihin. Esimerkiksi pilvipalveluiden standardiratkaisujen k?ytt??nottoa ja tietoturvan monitorointi- ja reagointimallien luomista voidaan helpottaa keskitetyn pilvipalvelutiimin toimesta.Automaatio, jatkuva integraatio ja toimitusNe tietoturvateht?v?t, jotka ovat luonteeltaan nopeasti toistuvia tai jatkuvia, kuten staattinen analyysi, automaattiset haavoittuvuusskannaukset, riippuvuuksien haavoittuvuusseuranta ja k?yt?naikainen tietoturvaan liittyv? monitorointi, pit?isi mahdollisuuksien mukaan automatisoida.Kun automatiikka on riitt?v?n kyps??, jatkuvan integraation (continuous integration tai CI) j?rjestelm??n voidaan rakentaa logiikkaa, joka est?? tuotantoon viennin, jos automatiikka huomaa mahdollisen tietoturvariskin.Tietoturvateht?vien automatisointi on itsess??n ty?t?, ja sik?li kun ohjelmistokehitt?j?t toteuttavat automatisoinnin, t?m?kin kehitysty? ohjataan tuotteen teht?v?listan kautta. T?ll?in sen kustannukset ja priorisointi tulevat k?sitellyksi.Ohjelmistoturvallisuuden seurannan ja ulkoisen tuen malliJatkuva tietoturvaty?n n?kyvyys ja ty?n j?lkik?teinen auditoitavuusJotta tietoturvaty?n edistymist? voidaan seurata reaaliaikaisesti, tietoturvaty?t? ohjaavat teht?v?t luokitellaan ja ne linkitet??n siihen toiminnallisuuteen, mihin ne liittyv?t. Organisaation tietoturva- ja tietosuoja-toiminnot voivat t?ll?in identifioida ne projektit, joissa luokittelua ei tapahdu ja reagoida asiaan aikaisessa vaiheessa. Tietoturva-aktiviteettien toteutumisen n?kyvyys kokonaisketter?n mallin portfoliotasolle voidaan tehd? samalla tavalla.Luokittelu on kuvattu kappaleessa Liite 3: Uuden tai muuttuneen toiminnallisuuden tietoturva- ja tietosuojaty?n tarkastuslista. Linkitys tehd??n k?ytetyn tiket?intij?rjestelm?n linkkej? k?ytt?en.Jos ohjelmistoja teetet??n ulkoisena hankintana, jossa kehityst? ei tehd? ostajan ty?nohjauksen alaisuudessa, ostaja voi halutessaan pyyt?? n?kym?? ty?nohjausj?rjestelm??n ja vaatia sopimuksellisesti vastaavan luokittelun. N?in ostaja voi varmistua siit?, ett? tietoturva- ja tietosuojaty?t? tehd??n jatkuvasti koko kehitysty?n ajan.Tukipalveluiden ty?nohjausmalliOhjelmistokehitt?jille, arkkitehdeille ja tuoteomistajille voidaan tarjota erilaisia tietoturvan ja tietosuojan tukipalveluita. Tyypillisin n?ist? on tutkiva tietoturvatestaus, joka tehd??n usein ohjelmistotiimin ulkoisia resursseja k?ytt?anisaatio luo tukipalveluiden toimittamista varten oman erillisen teht?v?listansa (backlog), johon kuka tahansa organisaation kehitysteht?viss? toimiva henkil? voi lis?t? tarvitsemansa tukipalvelutarpeen kuvauksen.Mik?li teht?v?listaa yll?pidet??n samassa tiket?intij?rjestelm?ss? kuin tuotteen teht?v?listaa, tukipalvelupyynt? voidaan linkitt?? ristiin n?iden teht?v?listojen v?lill?. N?in tukipalveluiden tarve tehd??n n?kyv?ksi.Tuotetiimi? ymp?r?iv? organisaatio tuottaa tukipalveluita keskitetysti t?m?n teht?v?listan pohjalta ja m??rittelee prioriteettij?rjestyksen toimitettaville tukipalveluille.Tuotantoon viennin vaatimukset (Liite 1)Vaatimusten pakottavuus ja poikkeusten dokumentointiSeuraavat hyv?ksynt?kriteerit on t?ytett?v? ennen kuin kehitett?v?n toiminnallisuuden saa vied? tuotantoon. N?ist? kriteereist? poikkeaminen on sallittua vain tuoteomistajan erillisell? p??t?ksell?.P??t?s on dokumentoitava. Dokumentointi tulisi tehd? tavalla, joka mahdollistaa p??t?ksen perusteiden l?yt?misen my?hemmin (esimerkiksi tietoturvapoikkeaman j?lkihoidossa) ja ennen kaikkea niin, ett? mahdollinen j??nn?sriski otetaan huomioon my?hemm?ss? toiminnassa. Mahdollisuuksia ovat esimerkiksiKirjaus yleiseen riskirekisteriin, jolloin j??nn?sriski? voidaan seurata riskienhallintaprosessissaKirjaus (tietoturva-)arkkitehtuuridokumenttiin, jolloin puute pysyy n?kyviss? ja voidaan ottaa huomioon jatkosuunnittelussaYksitt?isiss? teht?viss? kirjaus tikettiin esimerkiksi avaamalla asiasta tiketti ja viem?ll? se ty?jonoon tulevaisuudessa toteutettavaksiTuotantoon viennin vaatimusten kriteeritTuotantoon viennin vaatimukset otetaan kokonaisketter?ss? kehityksess? mukaan suunnittelukanbanissa.Jotta jatkuva tuotantoon vienti on mahdollista, n?iden vaatimusten on oltava sellaisia, jotka voidaan jokot?ytt?? suunnittelu- tai kehitysaikaisesti ennen kuin koodi menee automaattiseen integraatioon tai tuotantoon vientiin; taivoidaan toteuttaa kertaluontoisesti vain yhden kerran koko j?rjestelm?n elinaikana, taivoidaan toteuttaa automaattisin ty?kaluin osana tuotantoon vienti?.Dokumentointi- ja auditoitavuusvaatimukset tehd??n ensisijaisesti joko ty?nohjauksessa k?ytetyn tiketin sis?ll?ss? tai tilassa, versiohallitussa wikisivussa tai automaattisen ty?kalun tuottamassa tiedossa, joka tallennetaan. Erillisi? vaatimustenmukaisuusdokumentteja kirjoitetaan vain, jos niiden tuottamiselle on erillinen teht?v? teht?v?listalla.Tuotantoon viennin vaatimuksetOhjelmiston yleisarkkitehtuurille ja p??asiallisille toiminnallisuuksille on toteutettu uhkamallinnus noudattaen liitteen 5 ohjeita soveltuvin osin ja mahdollinen j??nn?sriski on dokumentoidusti hyv?ksytty. Uhkamallinnuksen toteutus ja sen tulokset on tiket?ity. T?m? vaatimus voi t?ytty? yhdistelem?ll? kertaluontoisia uhkamallinnuksia ja t?m?n prosessin kuvaamia toiminnallisuuskohtaisia pienemmist? uhkamallinnuksista. Ohjelmistolle on suoritettu tietosuojavaikutusten arviointi (tietosuoja-asetuksen tarkoittama Data Protection Impact Assessment, DPIA), mik?li se on lakis??teisesti tarpeellista. Suoritettu tietosuojavaikutusten arviointi ja sen tulokset ovat auditoitavissa.Mik?li ohjelmisto k?sittelee henkil?tietoja, ohjelmistosta on olemassa ajantasainen kuvaus henkil?tietovirroista ja niiden tallennuspaikoista, henkil?tietotyyppikohtaisesti eriteltyin?. T?m? vaatimus on erillinen tietosuojavaikutusten arvioinnista ja sen tulee toteutua kaikille henkil?tietoja k?sitteleville ohjelmistoille.Ohjelmiston tietoturvatestaustarpeet on m??ritelty ja ne on dokumentoitu. Ensisijaisesti testaustarpeet dokumentoidaan tikettein? tuotteen teht?v?listalla.Ohjelmistolle on tehty s??nn?llinen game day. Game dayss? tunnistetaan ja havaitaan (uusia) riskej?, selvitet??n ohjelmiston palautumiskyvykkyys ja koulutetaan tiimien j?seni? pilvioperointiin ja toimintaohjeiden (playbook tai runbook) noudattamiseen. Game dayn konseptin omistaa kirjoitushetkell? pilvitiimi. Ohjelmistosta on olemassa ajantasainen tietoturva-arkkitehtuurikuvaus, joka t?ytt?? minimivaatimukseltaan kappaleen Liite 4: Tietoturva-arkkitehtuurin dokumentoinnin v?himm?isvaatimukset vaatimukset.Muutosoikeudet k?ytt?palvelujen yll?pitoon on rajattu vain henkil?ille, joiden on tarpeen tehd? tuotannonaikaisia toimenpiteit?. T?m? sis?lt?? ajoymp?rist?jen virtuaalikoneet, k?ytt?j?rjestelm?t, orkestrointij?rjestelm?t, koodivarastot (repositories), automaattisen tuotantoon viennin j?rjestelm?t ja verkon konfiguraatiot. Jos infrastruktuuri on kuvattu koodina, my?s versionhallinnan katsotaan kuuluvaksi k?ytt?palvelujen yll?pitoon.K?ytt?palvelujen yll?pitoon liittyvien ymp?rist?jen (yll?) omistajuus ja p?ivitysperiaatteet on vastuutettu ja kuvattu selke?sti.K?ytt?palvelut t?ytt?v?t niille erikseen asetetut kovennusvaatimukset noudatellen palvelutoimittajan ja palvelun k?ytt?j?n vastuurajoja. Ellei kovennusvaatimuksia ole erikseen m??ritelty, l?htein? k?ytet??n ensisijaisesti CIS Benchmark -dokumentteja.Ohjelmiston tuottamat lokit siirret??n keskitettyyn lokij?rjestelm??n.Ohjelmiston ajallisesti rajoitetut komponentit (kuten varmenteet) sek? salaisuuksien hallinta on dokumentoitu, ja niiden hallinta on siirretty mahdollisen tuotantoa hoitavan tahon haltuun. L?hteet:Tietosuojavaikutusten arviointitarpeen m??rittelee yleisen tietosuoja-asetuksen 35. artikla sek? Article 29 Data Protection Working Partyn ohje WP248 ‘Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is “likely to result in a high risk” for the purposes of Regulation 2016/679’.Center for Internet Security Benchmarks: yleisperiaatteet (Liite 2)Tietoturvallisen arkkitehtuurin ja suunnittelun yleisperiaatteetPeriaateKuvausJ?rjestelm?n ei-julkinen tieto on tunnistettu ja sen k?sittelyperiaatteet on m??riteltyTunnistetaan, mit? ei-julkista tietoa j?rjestelm?ss? k?sitell??n, ja sille m??ritell??n k?sittelyn tietoturva- ja tietosuojavaatimukset. N?iden vaatimusten tulisi p??ty? tuotteen teht?v?listalle, jotta vaatimukset voidaan ottaa huomioon uhkamallinnuksessa. Palvelun keskeiset k?ytt?tilanteet on tunnistettuTunnistetaan palvelun k?ytt?tapaukset (use case) ja erityisesti tietosuojamieless? k?ytt?kokemus (user experience). Erityisen kiinnostavia ovat poikkihallinnolliset k?ytt?tilanteet, joissa tietoa siirret??n organisaatioiden v?lill?, sek? yll?pito- ja hallintak?ytt?tilanteet. Tiedot v?litet??n ohjelmistokehitt?jille k?ytt?tapauskuvauksissa, jotta vaatimukset voidaan ottaa huomioon uhkamallinnuksessa.Arkkitehtuurin tietoturva ja tietosuoja on dokumentoituKs. Liite 4: Tietoturva-arkkitehtuurin dokumentoinnin v?himm?isvaatimuksetArkkitehtuuri on modulaarinenArkkitehtuuri rakentuu m??ritellyin rajapinnoin eriytetyist? komponenteista tai palveluista, jotka toteuttavat itsen?isesti tietyn toiminnallisuuden tai tarjoavat p??syn palvelun tarvitsemaan tietoon. Esimerkki: Mikropalvelut (microservices) ovat yksi tapa tuottaa t?m?nkaltainen arkkitehtuuri. Niit? kutsutaan tarkasti m??ritellyn rajapinnan kautta, eik? esimerkiksi niiden hallitsemiin tietoihin ole p??sy? kiertoteitse.Arkkitehtuuri eriytt?? palveluntarjoajista riippuvat osat selkeill? rajapinnoillaJatkuvuussuunnittelun helpottamiseksi erityisesti pilvipalveluiden tietyst? tarjoajasta riippuva toiminnallisuus on eriytett?v? selkeill? rajapinnoilla.Esimerkki: Palvelussa p??tet??n k?ytt?? pilvialustan omaa serverless-toteutusta tai vaikkapa valmista pilvitietokantapalvelua. Arkkitehtuuri on suunniteltava niin, ett? n?iden korvaaminen eri toteutuksella ei pakota muuttamaan koko ymp?r?iv?? arkkitehtuuria.Tietojen k?sittely ja rajapintojen syntaktinen monimutkaisuus on minimoitavaPalvelun osan tulee toteuttaa vain halutun toiminnallisuuden kannalta v?ltt?m?tt?m?t toiminnot. T?m? p?tee sek? tiedon k?sittelyyn ett? rajapintojen toiminnallisuuteen ja ilmaisuvoimaan.Henkil?tietoja saa k?sitell? vain niin siin? laajuudessa, kuin palvelun tekniseen toteuttamiseen vaaditaan.Esimerkki: REST-rajapinnat m??ritell??n OpenAPI-dokumentteina ja niiden kautta vastaanotetun tiedon syntaktinen oikeellisuus varmistetaan tiukasti. Esimerkiksi DDD (Domain-Driven Design) saattaa auttaa t?ss? ajattelussa, ks. Johnsson et al., Secure by Design (Manning Publications, 2019).Arkkitehtuurissa on selv??, mik? osa on vastuussa tietojen pysyv?st? tallennuksestaSe palvelun osa, joka tallentaa tietoja pysyv?sti (persistence), on my?s vastuussa tietojensa p??synhallinnasta ja niiden poistamisesta elinkaaren aikana. N?iden osien m??r? kannattaa minimoida.Esimerkki: Arkkitehtuurisuunnittelu ja teknologiavalinnat mahdollistavat sen, ett? palveluiden osia voidaan ajaa read-only -tiedostoj?rjestelmist? niin laajalti kuin mahdollista. T?ll?in tietoja k?sitell??n vain muistinvaraisesti.Arkkitehtuuriin on luotava selv?t luottamusalueet, jotka on dokumentoitu tietoturva-arkkitehtuurissaJokaisen komponentin osalta on m??ritelt?v?, mihin muihin komponentteihin se luottaa, ja t?m? m??rittelee luottamusalueet. Eri luottamusalueiden v?lille on suunniteltava verkko- ja ajoymp?rist?jen riitt?v? erottaminen ja tietovirtojen sis?ll?n oikeellisuuden tarkistus ja todennus.Komponentit, joilla on rajapinta loppuk?ytt?j??n tai kolmannen osapuolen palveluun eriytet??n omaan luottamusalueeseensa.Jos luottamusalueilla on keskin?inen hierarkia (esimerkiksi suojaustaso), suojaustasojen v?liset eheys- ja luottamuksellisuusvaatimukset on m??ritelt?v?.Esimerkki: Kubernetes-klusterissa ajettavat mikropalvelut luokitellaan eri nimiavaruuksiin esimerkiksi sen mukaan, palvelevatko ne suoraan Internetiss? olevaa asiakasta vai muita taustapalveluita ja onko mikropalveluilla hallussaan p??syavaimia taustapalveluihin (esim. tietokantoihin). Niiden v?linen kommunikointi rajataan esimerkiksi NetworkPolicy-m??rittelyll? siten, ett? vain toiminnan kannalta oleelliset yhteydet ovat mahdollisia.Tietovarannot on eriytett?v? luottamusalueiden v?lill?Kaikki tietovirrat luottamusalueiden v?lill? on toteutettava rajapinnoilla. Suorat tietovarantop??syt luottamusalueelta toisille (esimerkiksi vapaamuotoiset tietokantakyselyt tai tiedostoj?rjestelm?n luku) on arkkitehtuurin tasolla estett?v?.Luottamusalueella, jolla on suora yhteys loppuk?ytt?j??n tai kolmannen osapuolen palveluun ei saa sijaita tietovarantoja, vaan tiedot on noudettava tarvittaessa rajapinnan kautta.Esimerkki: Useat erilaiset mikropalvelut tarvitsevat tietoa samasta tietokannasta. Sen sijaan, ett? kaikille eri mikropalveluille annetaan suora tietokantap??sy, ne kutsuvat erillist? rajapintaa, joka tarjoaa niille tarpeellisen p??syn (mutta ei mit??n muuta). Itse tietokantaan annetaan p??sy vain t?m?n rajapinnan toteutukselle.Tietovirtojen tietoturva- ja tietosuojavastuut on selke?sti m??riteltyVastuu tietovirtojen sis?ll?n oikeellisuuden tarkistamisesta ja niihin luottamisesta on aina vastaanottajalla.Tietosuojan osalta vastuu siit?, ett? tietoja ei luovuteta toiselle komponentille lain vastaisesti, on aina l?hett?j?ll?.Esimerkki: Jos komponentti hakee tietoa rajapinnasta esitett?v?ksi esimerkiksi k?ytt?liittym?ss?, on rajapinnan kutsujan vastuulla varmistaa, ett? tiedon sis?llytt?minen esimerkiksi web-sivun kontekstissa on turvallista. Tietokannalla tai sinne tietoa tallentavilla tahoilla ei voi olla tietoa kaikista niist? konteksteista, joissa tietoa joskus tullaan esitt?m??n ja mit? erityistarpeita esimerkiksi syntaksille tuolloin on.Esimerkki: Jos henkil?tietoja l?hetet??n kolmannen osapuolen rajapintaan, l?hett?j?n on poistettava siit? ne tiedot, joita ei teknisesti tarvita. Jos vastuu t?st? siirrett?isiin vastaanottajalle, on se lakiteknisesti jo liian my?h?ist?.J?rjestelm?n saatavuustavoitteiden on oltava selkeit? vaatimuksiaSaatavuustavoitteet on m??ritelt?v? ja niille on l?ydett?v? tekninen ratkaisu esimerkiksi hajauttamalla ja automaattisella skaalautumisella. Erityishuomiota on kiinnitett?v? vanhojen j?rjestelmien integraatiopisteisiin ja komponentteihin, joita voi k?sitteellisesti olla vain yksi kappale.Valmiita toteutuksia ja ohjelmistoriippuvuuksia k?ytett?ess? tietoturvavastuu on m??ritelt?v?Mik?li k?ytet??n jonkin muun tahon kirjoittamia ohjelmistoja, tietoturvavastuu kuuluu sille komponentille, joka valmista toteutusta k?ytt??. Vastuun voi siirt?? sopimuksellisesti, mik?li k?ytt? perustuu sopimukseen. Tyypillisess? avoimen l?hdekoodin tapauksessa k?ytt? perustuu vain rajoitettuun lisenssiin, jolloin tietoturvavastuuta ei voida siirt??.Esimerkki: Halutaan ottaa k?ytt??n kirjasto, joka s??st?? kehitysaikaa arviolta henkil?ty?kuukauden. Arvion mukaan kirjaston tietoturvatestaus ja haavoittuvuusseuranta kuitenkin aiheuttaisi elinkaaren aikana t?t? enemm?n lis?ty?t?, joten kirjastoa ei oteta vain t?m?n projektin vuoksi k?ytt??n.Kolmannen osapuolen komponenttien laatu on selvitett?v? ja seurattavaOhjelmistokehityksess? k?ytett?vien, ulkopuolelta hankittavien (esim. avoin l?hdekoodi tai valmis ostettu komponentti) haavoittuvuustilannetta on seurattava jatkuvasti. T?m? tulisi tehd? automatisoidulla j?rjestelyll?. K?ytt??n otettaessa ulkopuolisen komponentin tausta ja yll?pitotilanne on selvitett?v? ja siihen liittyv?t riskit on hallittava.Esimerkki: Halutaan ottaa k?ytt??n kirjasto, mutta sen taustatarkistuksessa ilmenee, ett? sill? on vain yksi aktiivinen kehitt?j? ja tietoturvaongelmia on korjattu ilman, ett? niille on haettu CVE-numeroa tai mainittu versiodokumentaatiossa. Tutkitaan, olisiko muita vaihtoehtoja olemassa.K?ytt?palveluymp?rist?t ja operationaaliset yleisperiaatteetPeriaateKuvausPilviymp?rist?jen erityishuomiotK?ytt?palveluymp?rist?n on toteutettava turvallisuusarkkitehtuurin luottamusalueetTietoturva-arkkitehtuurissa kuvattujen luottamusalueiden (ks. Tietoturvallisen arkkitehtuurin ja suunnittelun yleisperiaatteet) on oltava n?kyviss? ja teknisesti toteutettu verkko- ja ajoymp?rist?jen toteutuksessa, sik?li kun niiden toteutus on t?ll? tasolla mahdollista.Luottamusalueiden toteutuksesta Kubernetes-klusterissa ks. tekninen liite.Kehityst? tukeva p??sy tuotantoaikaisiin k?ytt?palveluymp?rist?ihin on toteutettava turvallisestiMik?li kehityst? varten on avattava p??sy tuotantoaikaisiin k?ytt?palveluymp?rist?ihin, p??syn on oltava avoin vain erikseen nimetyille henkil?ille, tehdyist? toimenpiteist? on j??t?v? auditoitava merkint?, ja p??sy on rajattava verkkoteknisesti pienimp??n mahdolliseen.?Forensiikka- ja viantutkintatapauksissa pit?? ensisijaisesti luoda pilviresurssista kopio, jota voidaan tutkia.Auditointilokien seuraaminen on j?rjestett?v?Auditointilokeja (ks. Auditoitavuuden yleisperiaatteet) on seurattava automaattisin h?lytyksin. H?lytykset m??ritell??n perustuen uhkamallinnukseen ja t?rkeimpiin k?ytt?tapauksiin (ks. Tietoturvallisen arkkitehtuurin ja suunnittelun yleisperiaatteet ja Tietoturvallisten palvelurajapintojen ja k?ytt?liittymien yleisperiaatteet).Palvelun saatavuuden monitorointi on j?rjestett?v?Palvelun saatavuutta on monitoroitava sek? palvelun k?ytt?jille tarkoitetusta rajapinnasta ett? monitorointirajapintojen kautta (ks. Auditoitavuuden yleisperiaatteet). Saatavuusongelmiin on m??ritelt?v? soveltuvat h?lytykset.Ajoymp?rist?t on kovennettavaPalvelun sovellusten ajamiseen k?ytett?v?t ajoymp?rist?t on kovennettava. Suositeltava kovennustapa on CIS-kovennusohjeiden noudattaminen soveltuvin osin, sek? sovellusten ajaminen rajoitetuissa ajoymp?rist?iss? (esim. kontit) mahdollisuuksien mukaan.Docker- ja Kubernetes-ymp?rist?ist? ks. tekninen liite.Internetiin avoinna olevien sovelluspalveluiden edustalla tulee olla sis?ll?njakeluverkko (content delivery network), v?lityspalvelin tai kuormantasainSovelluksen itsens? tulee olla p??tepiste mahdollisimman ohuelle protokollapinolle, jotta mahdolliset tuntemattomat haavoittuvuudet n?iss? protokollissa eiv?t vaikuta suoraan sovelluksen ajoymp?rist??n.Esimerkki: Sovelluspalvelimen eteen laitetaan kuormantasain, joka terminoi TLS-kerroksen ja sen alapuolella olevat protokollakerrokset. Kuormantasain v?litt?? selaimen ulkoisen IP-osoitteen sovellukselle lokitusta varten.Kuormantasaukseen ja jakeluverkkona k?ytet??n mieluiten pilvipalvelun tarjoamia palveluita, joilla on tunnetusti hyv? suorituskyky.Ks. tekninen ohje TLS-protokollasta ja lokien luonnista.Liikenteen salausKaikki julkisen Internetin yli siirrett?v? tieto on salattava kulloinkin vahvana pidett?v?ll? tavalla. Jos muuta ei ole m??ritelty, soveltuva tapa on uusin TLS-protokollan versio Kyberturvallisuuskeskuksen konfiguraatio-ohjetta noudattaen.Mik?li k?ytetty pilvipalvelukomponentti (esimerkiksi kuormantasain) ei tue m??riteltyj? TLS-vaatimuksia, tehd??n p??t?s siit?, onko riskialttiimpaa toteuttaa komponentti itse vai hyv?ksy? poikkeava salauskonfiguraatio. Ks. tekninen ohje TLS-protokollasta.Tallennettavan tiedon salausKaikilla henkil?tietoja tai turvallisuusluokiteltua materiaalia sis?lt?vill? tallennusmedioilla on oltava k?yt?ss? tallennusmediatason salaus. Muilta osin salauksen tarve voidaan vaatia riskiperusteisesti erikseen.Tietosuojan suunnittelun yleisperiaatteetN?m? periaatteet p?tev?t ainoastaan j?rjestelmiin, joissa k?sitell??n henkil?tietoja. Osa vaatimuksista on mainittu muissa yleisperiaatelistoissa, jolloin t?ss? on annettu niihin vain viite.PeriaateKuvausTietosuoja otetaan huomioon uhkamallinnuksessaKun suoritetaan uhkamallinnusta (ks. Tietoturvallisen arkkitehtuurin ja suunnittelun yleisperiaatteet), henkil?tietovirtojen osalta keskustelussa on k?yt?v? l?pi my?s tietosuoja-asiat.Esimerkki: Jos uhkamallinnusta tehd??n esimerkiksi Microsoft STRIDE -menetelm?ll?, laajennetaan keskustelua esimerkiksi TRIM-menetelm?ll? (ks. uhkamallinnuksen ohje) tai muulla kevyell? tietosuojavaikutusten arvioinnin menetelm?ll?.Henkil?tietoja k?sitell??n vain, jos se on teknisesti tarpeenHenkil?tietojen k?sittelyn tulee olla teknisesti v?ltt?m?t?nt? halutun toiminnallisuuden toteuttamiseksi. Jos toiminnallisuus voidaan toteuttaa ilman jotakin tietty? henkil?tietoa, sit? ei pid? k?sitell? lainkaan.Henkil?tietojen siirto j?rjestelmien v?lill? on teht?v? rajapintojen avullaHenkil?tietoja ei saa siirt?? tiedostovientien tai suoran tietokanta- tai tiedostoj?rjestelm?p??syn kautta, vaan niiden j?rjestelmien v?lill? siirt?mist? varten on luotava kontrolloitu rajapinta.Esimerkki: SQL-tietokanta sis?lt?? henkil?tietoja, joita useampi sovellus tarvitsee. Toteutetaan HTTP-rajapinta, josta henkil?tiedot ovat saatavilla ja ainoastaan HTTP-rajapinnan toteutus p??see SQL-kantaan. HTTP-rajapinta luo auditointilokitapahtumia rajapinnan k?yt?st?.Tietosuoja-asetuksen n?in vaatiessa j?rjestelm?n on toteutettava v?liaikainen k?sittelyn keskeytysJos tietosuoja-asetus k?sittelyn perusteet huomioon ottaen t?t? vaatii (artiklat 18 ja 21), j?rjestelm?n on toteutettava kullekin j?rjestelm?ss? rekister?idylle henkil?lle tila, jossa j?rjestelm? lopettaa kyseisen henkil?n tietojen k?sittelyn (ml. lukemisen) muihin kuin erikseen m??riteltyihin yll?pidollisiin tai viranomaistarkoituksiin. Tila on oltava kytkett?viss? p??lle ja pois. Henkil?tiedot on pystytt?v? tuomaan j?rjestelm?st?J?rjestelm?n on toteutettava riitt?v?t rajapinnat sille, ett? tietyn rekister?idyn henkil?n henkil?tiedot ja h?nt? koskevat j?rjestelm?n k?yt?st? syntyneet tiedot voidaan tuoda ulos koneluettavassa muodossa.Henkil?tiedot on pystytt?v? poistamaanJ?rjestelm?n on toteutettava rajapinta henkil?n poistamiselle j?rjestelm?st?, mik?li j?rjestelm?n k?ytt?tarkoitus mahdollistaa poistopyynn?t lain nojalla tai jos henkil?tietoja k?sitell??n suostumukseen perustuen. T?m? asettaa vaatimuksia k?ytetylle tietovarantorakenteelle, joka ei saa joutua ep?konsistenttiin tilaan henkil?iden poistamisen vuoksi.Henkil?tietojen viennist? toiselle rekisterinpit?j?lle on j??t?v? merkint?Mik?li henkil?tietoja vied??n toiselle rekisterinpit?j?lle, viennist? on j??t?v? merkint?. Merkinn?n on oltava saatavissa, jos rekister?ity k?ytt?? lakis??teist? tietojenpoisto-oikeuttaan, ja n?m? luovutustiedot on pystytt?v? tuomaan j?rjestelm?st?. Jos vientej? s??nn?nmukaisesti tehd??n vain ja ainoastaan tietyille muille rekisterinpit?jille, t?t? ominaisuutta ei v?ltt?m?tt? tarvita.Henkil?tietojen k?sittelyyn pyydett?v?st? suostumuksesta ja sen perumisesta on j??t?v? merkint?Ks. Tietoturvallisten palvelurajapintojen ja k?ytt?liittymien yleisperiaatteetHenkil?tietojen k?ytt??n liittyv?t tiedot ja valinnat tuodaan k?ytt?jille oikea-aikaisesti ja oikeassa viitekehyksess?Ks. Tietoturvallisten palvelurajapintojen ja k?ytt?liittymien yleisperiaatteetHenkil?tietojen siirto on teht?v? aina salattua yhteytt? k?ytt?enKs. K?ytt?palveluymp?rist?t ja operationaaliset yleisperiaatteetHenkil?tiedot on salattava silloin, kun ne on tallennettuKs. K?ytt?palveluymp?rist?t ja operationaaliset yleisperiaatteet. Tapauskohtaisesti on harkittava, tarvitaanko my?s tietovarantotasoista (esimerkiksi tietokantataulu- tai rivikohtaista) salausta.Henkil?tietoihin kohdistuvista luku- ja muutostapahtumista on teht?v? merkint?Ks. Auditoitavuuden yleisperiaatteetHenkil?tietoja paljastavan rajapinnan on aina tarkistettava tunnistus ja valtuutusKs. Tietoturvallisten palvelurajapintojen ja k?ytt?liittymien yleisperiaatteetViitteen? henkil??n tulisi k?ytt?? satunnaista, k?ytt?tapauskohtaista tunnistettaEllei ole erityist? syyt? muuhun, mik?li henkil??n pit?? antaa viite esimerkiksi toiselle palvelulle tai sidosryhm?lle tai lokitiedostoon, viitteeksi pit?isi luoda kryptografisesti satunnainen ja k?ytt?tapauskohtainen tunniste. Tunnisteen korrelointi henkil??n tulisi j?rjestelm?n ulkopuolella olla vaikeaa tai mahdotonta.Henkil?tiedoille on m??ritelty enimm?iss?ilytysaikaTallennettaville henkil?tiedoille on m??ritelty maksimis?ilytysaika, joka perustuu lakiin tai operatiiviseen tarpeeseen. On my?s m??ritelty, miten tiedot teknisesti poistetaan maksimis?ilytysajan umpeuduttua.Auditoitavuuden yleisperiaatteetPeriaateKuvausJ?rjestelmien tulee tuottaa riitt?v?sti lokitietoa oleellisista tapahtumistaOsana uhkamallinnusta kartoitetaan ne toiminnat, mist? lokitietoa on ker?tt?v?, sek? mit? tietoa on ker?tt?v?. Useimmiten lokitiedon ker?ys tehd??n rajapintakutsun yhteydess?. Lokimerkint?jen sis?ll?st? on seurattava periaatteita, jotka on kuvattu teknisess? liitteess?.Erityisesti henkil?tietojen lukemisesta ja muuttamisesta on aina teht?v? lokimerkint?, jonka perusteella voidaan selvitt?? henkil?, joka on suorittanut lukemisen tai tehnyt muutoksen.Sis??n- ja uloskirjautumisista sek? sovelluksen ett? alustaj?rjestelmien tasolla, k?ytt?oikeustason muutoksista, asetustiedostojen muutoksista ja luvusta sek? ulkoisesta syyst? aiheutuneista virhetilanteista on aina teht?v? lokimerkint?.Lokitapahtumien tietoturvamerkityksen on oltava lokien seurannan tiedossaLokeissa ja monitoroinnissa saattaa olla tapahtumia, joilla on merkityst? tietoturvahavaintoina. Erillisen operationaalisen tietoturvaseurannan (SOC, Security Operations Centre) on kuitenkin l?hes mahdotonta pysty? havaitsemaan esimerkiksi liiketoimintalogiikkakohtaisia tietoturvahavaintoja, ellei heille ole annettu n?ist? tietoa ja tulkintaohjetta etuk?teen.Tietoturvan kannalta merkitt?v?t sovelluskohtaiset loki- ja monitorointitapahtumat tulee tuoda SOCin tietoon, jotta niiden tapahtuminen voidaan havaita.Esimerkki: Tuotetiimi toteuttaa rajapinnan, johon pit?isi tulla vain hyvin muodostuneita kutsuja luotetusta toisesta j?rjestelm?st?. Tiimi toteaa uhkamallinnuksessaan, ett? mahdollinen v??rin muotoiltu kutsu on selv? merkki mahdollisesta tietoturvapoikkeamasta ja ne kirjataan sis?lt?ineen lokiin. SOCille kerrotaan, ett? t?llainen lokitapahtuma on todenn?k?isesti joko osoitus tietomurrosta (IoC, Indication of Compromise) tai ainakin vikaantuneesta palvelusta; kummassakin tapauksessa v?lit?n h?lytys on aiheellinen. SOC lis?? t?m?n erityistapauksen seurantaan.Henkil?tietojen tallennusta lokij?rjestelm??n on v?ltett?v?Lokij?rjestelm??n ei saa tallentaa henkil?tietoja, ellei sit? voida teknisesti muutoin toteuttaa.Esimerkki: IP-osoitteen, k?ytt?j?tunnuksen tai vastaavan tunnisteen tallennus lokiin voidaan tehd?, jos ilman sit? lokimerkint?? ei voida k?yt?nn?ss? k?ytt?? tarkoitukseensa.Eri j?rjestelmien lokien on oltava korreloitavissa kesken??nKaikki lokil?hteet tulee ker?t? lopulta samaan paikkaan, jotta niiden analyysi on mahdollista yhdess? ja samassa j?rjestelm?ss?. T?m? mahdollisuus tulee tuottaa tiimeille yhteisen? palveluna.Kaikki lokitallennus synkronoidaan koordinoituun yleisaikaan (UTC) luotetun aikapalvelimen avulla ja jokainen lokimerkint? varustetaan aikaleimalla, jonka tarkkuus on mahdollisimman suuri mutta v?hint??n sekuntitasolla.On lis?ksi suositeltavaa, ett? j?rjestelm?n ulkopuolelta tuleviin pyynt?ihin sidotaan satunnainen pyynt?tunniste (request ID), joka v?litet??n taustaj?rjestelm?lt? toiselle ja kirjataan lokiin. N?in lokeista voidaan n?hd?, mitk? toimenpiteet liittyiv?t mihinkin ulkopuolelta tulleeseen pyynt??n ja miten pyynn?t ketjuuntuvat (mikro)palveluarkkitehtuurissa. T?m?n voi toteuttaa my?s hajautetulla pyynt?seurantaj?rjestelm?ll? (distributed tracing), jos sellainen on k?yt?ss? esimerkiksi virheiden tutkimista varten.Rajapintoihin tulevien pyynt?jen l?hdeosoite on kirjattava lokiinRajapintoihin tulevien pyynt?jen l?hdeosoite (IP-osoite) on kirjattava lokiin, my?s mik?li rajapinta sijaitsee ei-julkisessa, luotetussa verkossa. Luotettujen verkkojen IP-osoitteiden varaamisesta k?ytt??n on pidett?v? loki, josta k?y ilmi IP-osoitteiden ja sit? k?ytt?neiden laitteiden laitteisto-osoitteiden vastaavuus. Julkisesta Internetist? tulevien pyynt?jen l?hde-IP-osoite on otettava yl?s verkon ulkolaidalla ja tallennettava lokiin tai taustapalvelimelle lokitusta varten.Auditointilokimerkinn?t on siirrett?v? s??nn?llisesti pois niit? luovilta palvelimiltaRiippumatta lokienhallinnan ja -analyysin ymp?rist?st?, lokit tulee siirt?? s??nn?llisesti ja mielell??n reaaliaikaisesti pois kohteesta, jota lokitetaan. T?ll? varmistetaan lokien luotettavuus, mik?li kohteen eheys vaarantuu. Siirrosta riippumatta lokeja s?ilytet??n my?s l?hdepalvelimella 14 p?iv?n ajan lokieheyden varmistamiseksi.Lokimerkinn?t on luotava standardoidulla tavallaOrganisaation omissa sovelluksissa lokimerkinn?t on teht?v? rakenteisessa muodossa, mieluiten JSON-muotoisina, jotta niiden analyysi ja j?sennys on helposti teht?viss?. Lokimerkint?jen teknisest? toteutuksesta on seurattava periaatteita, jotka on kuvattu teknisess? liitteess?.Valmisohjelmistojen osalta on pyritt?v? yleisesti k?yt?ss? olevien konventioiden seuraamiseen.Monitorointirajapinnan toteutus saatavuusongelmien havaitsemiseenJ?rjestelm?n osien on toteutettava sis?inen monitorointirajapinta, tai monitorointi voidaan suorittaa lokeja seuraamalla.Uusissa monitorointirajapinnoissa tulisi pyrki? julkaisemaan onnistuneiden pyynt?jen m??r? aikayksikk?? kohti, ep?onnistuneiden pyynt?jen m??r? aikayksik?ss? ja pyynn?n k?sittelyaika sekunneissa (pienin, isoin, keskim??r?inen, mediaani) aikayksik?ss? (eli nk. RED-tiedot: rate, errors, duration).Kehitysymp?rist?jen ja tuotantoon viennin yleisperiaatteetPeriaateKuvausOhjelmistokehitykseen k?ytett?v?t tietokoneet ja muut p??telaitteet on suojattavaP??telaitteet, joilla otetaan yhteyksi? ohjelmistokehityksen palvelimiin (kuten versionhallintaan tai tuotantoonvientiautomaatioon) tai joilla tehd??n yll?pidollisia toimia, on tuotava organisaation tietotekniikkayll?pidon m??rittelemien tietoturvavaatimusten piiriin (vakiointi, p?ivitykset, haittaohjelmilta suojautuminen, jne.).T?m? vaatimus ei p?de, mik?li p??telaitteella tehd??n vain testausta julkisiksi tarkoitettuja k?ytt?liittymi? tai rajapintoja vasten.Ohjelmistokehitykseen k?ytett?vien palvelinten on oltava lokienhallinnan piiriss?Ohjelmistokehityksess? k?ytett?v?t palvelimet, kuten versionhallinta-, integrointi- ja muut palvelimet, on tuotava lokienhallinnan piiriin. Lokienhallinnan vaatimukset sovelletaan kappaleen Auditoitavuuden yleisperiaatteet perusteella.Kehitysymp?rist?t ja ty?kalut on suojattava ja niiden saatavuus on taattavaKehitysymp?rist?jen ja -ty?kalujen tietoturvavastuu kuuluu oletusarvoisesti ohjelmistokehitt?jille. Vastuu voidaan siirt?? erikseen sopimalla tai k?ytt?m?ll? organisaation toimittamia standardoituja ymp?rist?j? ja ty?kaluja. Kehitysymp?rist?jen ja -ty?kalujen haavoittuvuuksien seuranta on j?rjestett?v? kuten kappaleessa Tietoturvallisen arkkitehtuurin ja suunnittelun yleisperiaatteet on kuvattu.Kehitys- ja tuotantoinfrastruktuurin k?ytt?oikeudet on rajoitettava mahdollisuuksien mukaanKehitys- ja tuotantoinfrastruktuurissa on v?ltett?v? jaettuja tunnuksia ihmisten k?yt?ss?, paitsi jos sit? ei voi teknisesti v?ltt??. Automaation k?ytt?mien tunnusten oikeudet on rajoitettava niihin toimintoihin, jotka automaatio tarvitsee.Ohjelmistokehitt?jien k?ytt?oikeudet on sidottava projektissa ty?skentelyynOhjelmistokehitt?jien oikeudet on poistettava, mik?li he eiv?t en?? ty?skentele projektissa. Mik?li k?ytet??n jaettua tunnusta, jaetun tunnuksen tunnistustiedot on uusittava aina, kun jokin tunnusta jakanut henkil? ei en?? ty?skentele projektissa.Ihmisten kehitysj?rjestelmien k?ytt?j?tunnuksissa on k?ytett?v? kaksivaiheista tunnistustaIhmisten k?yt?ss? olevilla k?ytt?j?tunnuksilla on oltava k?yt?ss? kaksiosainen tunnistus. Esimerkki: Kaksiosainen tunnistus ei v?ltt?m?tt? ole interaktiivinen. Kaksi vaihetta voivat olla esimerkiksi versionhallintaa kehitt?j?n koneelta k?ytett?ess? tietokoneen kiintolevyn salausavain ja t?ll? kiintolevyll? s?ilytett?v? ssh-avain. Interaktiivisen kaksivaiheisen tunnistuksen tulisi mieluiten olla erikseen laskettava aikapohjainen tunniste (TOTP), eik? esimerkiksi tekstiviestitodennus.Salaisuuksien hallinta on j?rjestett?v?Salaisuudet, esimerkiksi salaus- ja rajapinta-avaimet, on hallittava niin, ett? ne voidaan tarvittaessa helposti vaihtaa niin testaus- kuin tuotantoymp?rist?iss?kin, ja ett? p??sy salaisuuksiin on vain nimetyill? henkil?ill?. Salaisuudet on viet?v? tuotantoon konfiguraationa. Salaisuuksien s?ilytys osana l?hdekoodia on kielletty.Ohjelmistoriippuvuuksien ja koodin versionhallinnan saatavuus on turvattavaKaikki ohjelmistoriippuvuudet on tunnettava ja t?m? koskee my?s riippuvuuksien riippuvuuksia. Mik?li j?rjestelm? on huoltovarmuuskriittinen, ohjelmistoriippuvuuksia (ja n?iden riippuvuuksia) on k?ytett?v? Suomessa sijaitsevan kopion v?lityksell?. Versionhallinnan sek? tuotantoon vientiautomaation on sijaittava kokonaisuudessaan Suomessa.Ohjelmistoriippuvuuksien ja koodin eheys on taattavaMik?li ohjelmistoriippuvuus tukee k?ytett?v?n komponentin eheyden tarkastamista kryptografisin menetelmin (esimerkiksi digitaalinen allekirjoitus), se on teht?v?.Mik?li koodin versionhallinta tukee digitaalisin allekirjoituksin toteutettua eheystarkistusta, sen k?ytt??nottoa tulisi harkita.Ohjelmakoodi katselmoidaanOhjelmakoodille tehd??n koodikatselmointia (code review tai automaattisena staattista analyysi?, static analysis). Ohjelmistotuotetiimi valitsee heille parhaiten sopivan tavan suorittaa t?t?. Suosituksena on nk. pull request -menettelyn k?ytt? koodikatselmointiin. Erityist? tietoturvakatselmointia tarvittaessa t?m? on syyt? pyyt?? ja tiket?id? erikseen.Tuotantoon viedyist? komponenteista tallennetaan kopio forensiikkatarkoituksiinLuodaan kyky selvitt?? j?lkik?teen, mit? koodia tuotannossa on ollut ajossa. Esimerkiksi kontteja k?ytett?ess? tuotantoon viet?v?st? kontin kuvasta voidaan tehd? arkistokopio.Pilviymp?rist?jen tietoturvaperiaatteet ja -vaatimuksetPeriaateKuvausVerkkoliikenteen oletetaan aina kulkevan ei-luotetussa verkossa (zero-trust networking)Kun komponentit liikenn?iv?t kesken??n, mit??n verkkoyhteytt? ei arkkitehtuurin tasolla oleteta oletusarvoisesti turvalliseksi. Verkon osa voidaan olettaa turvalliseksi vain, jos sen konfiguraatio ja siihen p??sy on riitt?v?n hyvin suojattu ja suojausmekanismi on teknisesti arvioitavissa, eli turvallisuus ei perustu pelk??n tietoturvapolitiikan m??rittelyyn.Esimerkki: Pilvipalvelusta halutaan yhteys itse hallinnoituun (on-premises) tietokantaan, johon on AWS Direct Connect -yhteys. T?st? huolimatta tietokantayhteydess? on k?ytett?v? salausta ja kummankin p??n todennusta.Esimerkki: Kubernetes-klusterissa on monimutkainen mikropalvelu. Arkkitehtuurisuunnittelussa kartoitetaan mahdollisuus turvata palveluiden v?liset yhteydet k?ytt?en service meshi?, joka tuottaa palveluiden v?lille salatut ja tunnistetut yhteydet.Esimerkki: Kubernetes-klusteri sijaitsee yhdess? AWS:n VPC:ss?. Klusterin ty?kuormien luonne huomioon ottaen riskihyv?ksynt?p??t?ksen? todetaan, ett? VPC:n sis?iseen liikenteeseen voidaan suhtautua niin, ett? klusterin sis?ll? ei t?ss? tapauksessa tarvita salattuja yhteyksi?.Ty?kuormat vied??n aina tuotantoon konteissaTy?kuormat vied??n aina tuotantoon kontitettuna, jotta niiden riippuvuudet ovat selkeit? ja on selv??, mik? koodi kulloinkin on ajossa.Esimerkki: Arkkitehtuuri hy?tyisi tilanteessa nopeasti skaalautuvasta rinnakkaisprosessoinnista, joka olisi helppo toteuttaa serverless- tai FaaS (Function as a Service) palvelulla kuten AWS:n Lambdalla ilman konttia. Koska koodilla ei ole ulkoisia riippuvuuksia eik? se ole jatkuvuussuunnittelun kannalta kriittinen osa palvelua, p??tet??n, ett? kontittoman Lambdan k?yt?n riski on hyv?ksytt?viss?.Pilvipalveluntarjoajan tilej? k?ytet??n erottelemaan sovellukset ja niiden eri ymp?rist?t toisistaanEri sovelluksia tai sovellusten eri versioita (testaus/tuotantoversio) ei saa ajaa samalla tilill?.Esimerkki: Tiimi yll?pit?? kahta eri sovellusta, joilla ei ole suoria ajoaikaisia riippuvuuksia. Kummallekin on luotu tuotantoa varten oma AWS-tili (account), jotka molemmat on alistettu saman AWS-organisaation (organization) alaisuuteen.Identiteetin- ja p??synhallinnassa k?ytet??n minimioikeuksin varustettuja roolejaOikeudet pilvipalvelun rajapintoihin jaetaan roolien kautta. K?ytt?j?t saavat k?ytt??ns? roolin, jolla on minimim??r? tarvittavia oikeuksia.Esimerkki: Kehitt?j?ll? on verraten harvoin ilmenev? tarve kutsua ”k?sin” jotakin pilvipalvelun rajapintaa. T?t? varten luodaan rooli, jolla t?m? oikeus on ja kehitt?j? omaksuu t?m?n roolin (AssumeRole) vain tarvittaessa. K?sin tapahtuvassa k?yt?ss? roolin omaksuminen voi viel? vaatia kaksivaiheisen tunnistautumisen.Esimerkki: Pilvipalvelun tuotantokonfiguraatiolle tilataan tutkivaa tietoturvatarkastusta. T?t? varten erilliseen tietoturvatestausta varten luotuun AWS-tiliin luodaan uusi k?ytt?j? ulkoiselle testaajalle. Tuotantotilille luodaan rooli, joka mahdollistaa konfiguraatioiden lukemisen ja tarkastelun. Testaajan k?ytt?j?tunnukselle annetaan mahdollisuus omaksua t?m? lukurooli. Testauksen loputtua t?m? oikeus ja testaajan tunnus poistetaan.Pilvess? ajettavien ty?kuormien verkkoliikenteen kohteet minimoidaanKun pilvess? ajetaan ty?kuormia, n?iden pit?isi voida ottaa yhteytt? ainoastaan paikkoihin, joihin niiden on tarkoituskin olla yhteydess?.Esimerkki: Pilvipalvelussa ajetaan kontteja Kubernetes-orkestraattorilla. Kubernetes-klusteriin m??ritell??n politiikka (NetworkPolicy) tai service mesh, joka est?? yhteydenotot muihin kuin erikseen m??riteltyihin kohteisiin.Pilvess? ajettavien ty?kuormien eheys varmistetaanPilvess? ajettavien ty?kuormien (workload) eheydest? on varmistuttava. Eheyden tulisi kattaa koko ajettavan koodin ja sen riippuvuuksien k?sittelyketju.Esimerkki: Riippuvuudet, kuten Docker-pohjakuvat ja kirjastoriippuvuudet kiinnitet??n tiettyihin versioihin ja mieluiten varmistetaan kryptografisesti. Tarvittavia artefakteja k?ytet??n Suomessa sijaitsevasta luotetusta kopiosta.Esimerkki: Eritt?in suurta tietoturvan tasoa vaativissa sovelluksissa harkitaan, pit?isik? my?s versionhallinnassa k?ytt?? kryptografisia eheytt? tukevia toimintoja kuten Gitin allekirjoitettuja muutoksia.Pilvess? ajettavien ty?kuormien elinkaari on auditoitavissaPilvess? ajettavien ty?kuormien elinkaaresta j?? auditoitavia todisteita, joiden avulla voidaan j?lkik?teen p??tell?, mit? koodia kulloinkin oli ajossa.Esimerkki: Kaikista tuotantoon viedyist? Docker-konteista tehd??n erillinen arkistokopio. Kubernetes-podien poistamisesta ja luomisesta j?? auditoitava lokimerkint?.Pilvipalveluntarjoajan palvelut on rajattu vain tarpeellisiinPilvipalveluiden tarjoajien palvelut rajataan niin, ett? vain tarpeellisia palveluita ja maantieteellisi? alueita voidaan k?ytt??.Esimerkki: AWS-tilit luodaan AWS-organisaation alle, jolla on asianmukaiset palvelupolitiikat (service control policies). N?ill? estet??n esimerkiksi muiden alueiden (region) k?ytt?. Pilvipalveluntarjoajan tallennetun tiedon salausratkaisut ovat k?yt?ss?Pilvipalvelut tarjoavat yleens? tavan salata niihin tallennetun tiedon niin, ett? salaus on palvelun k?ytt?j?lle l?pin?kyv??. Vaikka t?m? ei suojaakaan tietoa sovelluksen haavoittuvuuksilta, n?it? tulee kuitenkin k?ytt?? siksi, ett? tieto tallennetaan pilvipalveluntarjoajan muistiv?lineille salattuna.Esimerkki: AWS:n S3-?mp?reiden oletusarvoinen salaus otetaan k?ytt??n.Tietoturvamonitorointi on vastuutettuTuotetiimi m??rittelee tuotteen uhkamalliin perustuen, mit? tietoturvaan liittyvi? tapahtumia on seurattava. Tapahtumien seurannan vastuutus on m??ritelty.Esimerkki: Mik?li k?ytet??n erillist? SOCia, tuotetiimi kertoo SOCille ne tietoturvatapahtumat, joiden seuranta tuotteen osalta on t?rke??. Tuotetiimi huolehtii siit?, ett? n?m? tapahtumat luodaan lokitapahtumavirtaan.Pilvipalveluiden resurssit hallitaan versionhallinnassa s?ilytett?v?n konfiguraation kauttaPilvipalvelun konfiguraatiota hallitaan versionhallinnassa. K?sity?n? teht?v?? pilvipalveluiden hallintaa ei tuotannossa saa tehd? salaisuuksien hallintaa lukuun ottamatta, eik? sit? suositella my?sk??n testiymp?rist?ille.Mik?li pilvipalvelun tarjoaja antaa k?ytt??n inventaariorajapinnan, sit? k?ytet??n apuna ylim??r?isten pilviresurssien havaitsemisessa.Tietoturvallisten palvelurajapintojen ja k?ytt?liittymien yleisperiaatteetPeriaateKuvausK?ytt?liittym?t ja rajapinnat eriytet??n k?ytt?j?tyyppien tarpeiden perusteellaK?ytt?j?tyypit jaotellaan k?ytt?tapaustensa mukaan, esimerkiksi viranomaiset, kuluttajat/kansalaiset/asiakkaat, yll?pito, yritykset ja avoimen datan rajapinnat. K?ytt?tapausten salliessa rajapinnat eriytet??n siten, ett? samasta rajapinnasta ei saa erityyppist? palvelua pelk?st??n esimerkiksi todennetun k?ytt?j?tyypin perusteella, vaan esimerkiksi rajapinnan osoite tai polku on erilainen yll?pito- ja loppuk?ytt?j?toiminnallisuudessa. K?ytt?liittym?t rajataan toiminnallisesti sis?lt?m??n vain k?ytt?j?ryhm?n tarvitsema minimitoiminnallisuus.Esimerkki: Sama palvelu tarjoaa rajapintoja kansalaisille ja yll?pidolle. Koska palvelu on monoliittinen ja sit? ei olla jakamassa esimerkiksi mikropalveluihin, p??tet??n?tarjota yll?pitotoiminnallisuudet ulkoisen rajapinnan tasolla "eri" rajapinnasta (esim. juuresta alkaen eri URI-polku), vaikka toteutus onkin samassa sovelluksessa. T?m? mahdollistaa rajapintojen helpomman valvonnan esimerkiksi lokij?rjestelmiss? tai web-sovelluspalomuureissa.K?ytt?valtuudet hallitaan keskitetysti ja ne sovitetaan kulloiseenkin tarpeeseenK?ytt?valtuudet hallitaan keskitetyst? paikasta, jotta v?ltet??n hajautetun valtuuksien hallinnan mahdolliset ristiriitaisuudet ja katvealueet. K?ytt?jill? on k?ytt?kokemukseen ja -tarpeeseen sovitetut k?ytt?valtuustasot ja tarvittaessa mahdollisuus vaihtaa niit?, jotta kaikkia toimintoja ei tarvitse tehd? aina korkeimmalla tasolla.Henkil?tietojen k?ytt??n liittyv?t tiedot ja valinnat tuodaan k?ytt?jille oikea-aikaisesti ja oikeassa viitekehyksess?Henkil?tietojen k?sittelyyn (erityisesti ker??miseen ja siirtoon) liittyv?t tiedotteet ja luvat n?ytet??n k?ytt?jille k?ytt?kokemuksen perusteella parhaiten soveltuvassa tilanteessa ja ilmaisu on tehty k?ytt?j?n ymm?rrystason huomioon ottaen. Henkil?tietojen ker?yksest? informoidaan asteittain tarkentuvalla tiedolla sen mukaan, kuinka tarkkoja tietoja k?ytt?j? tietojen k?yt?st? haluaa (nk. layered notice).Suostumuksen kysymisen k?ytt?liittym?ss? on oltava auditoitavissaSuostumusta k?ytt?j?lt? kysytt?ess? sen perumisen on oltava yht? helppoa kuin sen antaminen. Suostumuksen antamisesta ja perumisesta on j??t?v? aikaleimattu merkint?.K?ytt?j? saa tehd? tietoturvaan vaikuttavan p??t?ksen vain, jos se on tarpeellistaK?ytt?j? saa tehd? tietoturvaan vaikuttavan p??t?ksen (esimerkiksi poikkeustilanteen hyv?ksynn?n) vain, jos k?ytt?j? voi todellisuudessa tuoda p??t?kseen lis?tietoa, jota j?rjestelm?ll? itsell??n ei ole. K?ytt?liittym?n on uskottavasti pystytt?v? takaamaan, ett? k?ytt?j? ymm?rt?? p??t?ksens? seuraukset. Muussa tapauksessa j?rjestelm?n tulee automaattisesti tehd? turvallinen p??t?s k?ytt?j?n puolesta, eik? k?ytt?j? saa pysty? ohittamaan p??t?st?.Rajapinnat toteutetaan kieliopiltaan mahdollisimman yksinkertaisiksiRajapintojen hyv?ksymien sy?tteiden kieliopin on oltava mahdollisimman yksinkertainen, jotta sy?tteen oikeellisuuden tarkastaminen on helppoa tai edes mahdollista.K?ytt?liittym?t ja rajapinnat hylk??v?t v??r?t sy?tteet kokonaisuudessaanMik?li rajapintaan tulee v??r? sy?te, koko sy?te hyl?t??n mahdollisimman varhaisessa vaiheessa. Sy?tett? ei yritet? tulkita, mik?li se on osittainkin virheellinen.K?ytt?liittym?t ja rajapinnat piilottavat tietovarantojen sis?isen toiminnallisuudenTietovarantojen sis?iseen toiminnallisuuteen liittyv?t asiat, kuten tietokantarivien j?rjestysnumerot tai palvelimen tiedostoj?rjestelm?n nimet eiv?t ole n?kyviss? rajapinnan tai k?ytt?liittym?n l?pi.Jokainen rajapinta vaatii todennuksen ja valtuutuksen riippumatta verkkoymp?rist?st?Jokaisen tarjottavan rajapinnan on todennettava kutsujan ja tarkistettava sen valtuutus. Rajapintoja ei saa avata edes luotettuun verkkoon niin, ett? kuka tahansa verkon alueelta pystyy kutsumaan rajapintaa tunnistautumatta. T?st? ainoana poikkeuksena ovat tilanteet, joissa rajapintojen v?lill? on pisteest? toiseen toteutettu VPN-yhteys tai jos rajapinta on julkisen tiedon haku- tai monitorointirajapinta.Rajapinnoissa suositaan standardejaRajapintojen toteutuksissa suositaan protokollia ja tietojen esitys- ja siirtomuotoja, jotka ovat laajalti hyv?ksyttyj? ja k?yt?ss?.Organisaation eri osissa standardoidaan ja yhten?istet??n samoihin tarkoituksiin tarkoitetut rajapinnat ja n?iden toteutukset.Rajapintojen todennuksessa ja valtuutuksessa k?ytet??n standardoituja protokollia ja algoritmejaTodennus ja valtuutus perustuvat kryptografiaan. Kryptografisten protokollien ja algoritmien suunnittelu itse ei ole sallittua. Yleisesti hyv?ksyttyjen todennus- ja valtuutusprotokollien toteutus itse on sallittua, mutta niille on teht?v? tarkka suunnittelu- ja toteutuskatselmointi sek? testaus.J?rjestelmien l?htev?n s?hk?postin asetukset ehk?isev?t roskapostia ja tietojen kalasteluaL?htev?? s?hk?postia varten on m??ritelty domain-pohjainen l?htev?n s?hk?postin todennus (DMARC), joka pyyt?? vastaanottajaa hylk??m??n vialliset viestit.Esimerkki: Organisaation domain-yll?pito m??rittelee DKIM-, SPF- ja DMARC-tiedot ja tarjoaa sovelluskehitt?jille tavan l?hett?? s?hk?postia n?iden alaisuudessa.Tietoturvatestauksen ja teknisen tarkastuksen yleisperiaatteetPeriaateKuvausTietoturvatestauksen ja -tarkastuksen kohteet m??ritell??n hy?kk?yspinnan ja mahdollisen vaikutuksen mukaanTietoturvatarkastukset ja niiden tyyppi kohdennetaan arvioimalla eri toiminnallisuudelle suhteellinen riski hy?kk?yspinnan (riskin todenn?k?isyys) ja toiminnallisuuden t?rkeyden tai k?siteltyjen tietojen (riskin vaikutus) mukaan. Suositeltavaa on tehd? t?m? uhkamallinnuksen yhteydess?. Tietoturvatestaus jakaantuu p??asiassa automaattisiin testitapauksiin ja tutkivaan testaukseen; tutkiva testaus kohdistetaan ensisijaisesti niihin kohteisiin, jotka ovat suhteessa riskialttiimpia.Tietoturvatarkastuksen kattavuus ja tyyppi m??ritell??n hy?kk?yspinnan ja mahdollisen vaikutuksen mukaanTietoturvatarkastuksen tarvittava taso on l?ht?kohtaisesti OWASP ASVS Level 2, mik?li se on kohteeseen sovellettavissa. OWASP ASVS -dokumenttia voi k?ytt?? my?s testauksen tarkastuslistana ostettaessa web-sovelluksen tietoturvatarkastusta. Joissakin tapauksissa tarkastuksen tyypin on mahdollisesti oltava esimerkiksi Liikenne- ja viestint?viraston akkredointi. Pilvipalveluiden tarkastuksessa tarkastuksen on katettava my?s t?ss? listassa luetellut pilvipalveluiden erityisalueet.Tietoturvatestaustarpeet ja tekniset tarkastukset merkit??n teht?vin? tuotteen teht?v?listalleAutomaattisen tietoturvatestauksen kehitysteht?v?t merkit??n tuotteen teht?v?listalle kehitt?jille tarkoitettuina ty?teht?vin?. Tekniset tarkastukset, vaikka ne tekisikin tuotetiimin ulkopuolinen taho, merkit??n my?s omina teht?vin??n tuotteen teht?v?listalle, jotta niiden tilasta j?? j?lki. Ulkoisen testauksen ty?listateht?vien omistaja on oletusarvoisesti tuoteomistaja, ellei niit? erikseen delegoida.Tietoturvatestauksen ja teknisen tarkastuksen l?yd?kset merkit??n tuotteen teht?v?listalleKaikki tietoturvatestauksesta ja tarkastuksesta kumpuavat l?yd?kset lis?t??n tuotteen teht?v?listalle niin, ett? teht?v?n? on joko korjata ongelma, tuottaa kompensoiva kontrolli tai hyv?ksy? riski.Tutkivasta tietoturvatestauksesta yll?pidet??n vallitsevan tilanteen kuvaustaTutkiva tietoturvatestaus tuottaa tuloksenaan l?yd?sten lis?ksi tietoturvan vallitsevan tilanteen kuvauksen, jota yll?pidet??n kohdej?rjestelm?kohtaisesti versioituna dokumenttina. T?m?n dokumentin p?ivitys vastuutetaan tutkivan tietoturvatestauksen suorittajalle.HTTP-rajapintojen tekniset kovennukset pidet??n ajan tasalla selainten ja standardien kehittyess? Rajapintoja vasten tehd??n joko automaattista tai tutkivaa testausta, jolla huomataan puuttuvat rajapintojen tekniset kovennukset (esimerkiksi HTTP-tietoturvaotsakkeet, jotka on kehitetty sovelluksen alkuper?isen k?ytt??noton j?lkeen).Esimerkki: Hankittavilta tietoturvaskannereilta ja tietoturvatestaajilta vaaditaan hankinnan ja toimeksiannon yhteydess?, ett? he huomioivat rajapintojen teknisten kovennusten ajantasaisuuden suhteessa alati kehittyviin standardeihin. Koodina hallittu infrastruktuuri on osa tietoturvatarkastustaTietoturvatarkastuksen kattaessa pilvipalvelun my?s kyseisen palvelun infrastruktuurikuvaukset katselmoidaan tarkastuksen yhteydess?.Esimerkki: Tilataan tietoturvatarkastus sovellukselle, jota ajetaan Kubernetes-klusterissa AWS:ss?. Tietoturvatarkastukseen sis?llytet??n AWS:n Terraform-konfiguraatiot, Kubernetes-klusterin konfiguraatiot sek? konttien Dockerfilet.Pilvi-infrastruktuurin identiteetin- ja p??synhallinta on osa tietoturvatarkastustaTietoturvatarkastuksen kattaessa pilvipalvelun my?s kyseisen palvelun IAM-konfiguraatio katselmoidaan tarkastuksen yhteydess?.Tuotantoonviennin automaatio on tietoturvatarkastuksen piiriss?Tuotetiimin k?ytt?m? tuotantoonviennin automaatio (CI/CD) kuuluu tarkastettaviin kokonaisuuksiin kuten tuotetiimin yll?pit?m?t sovelluksetkin. Tarkastettavat osa-alueet ovat v?hint??n p??synhallinta itse CI/CD-automaatioon, salaisuuksien hallinta sek? CI/CD-automaation p??synhallinnan j?rjest?minen pilvi-infrastruktuuriin.Tunnusten luontia ja vanhentumista on seurattavaPilvipalvelun tunnusten luontia, roolien omaksuntaa ja niiden k?ytt?? on valvottava.Esimerkki: Uusien IAM-k?ytt?jien, p??syavainten (access keys) ja roolien luomisesta on tultava her?te, jonka ihminen (esimerkiksi SOC) tarkastaa ilman suurta viivett?. Roolin omaksumisesta (AssumeRole) on tallennettava auditoitava lokitapahtuma. K?ytt?j?tunnukset ja p??syavaimet, joita ei ole k?ytetty tietyn ajan j?lkeen, on s??nn?llisesti poistettava.Uuden tai muuttuneen toiminnallisuuden tietoturva- ja tietosuojaty?n tarkastuslista (Liite 3)Tietoturva- ja tietosuojaty? tulee kohdentaa oikein, jotta resursseja ei tuhlata kohteisiin, joissa ei ole merkitt?vi? tietoturvariskej?. T?t? tarkastuslistaa voidaan k?ytt?? sen m??ritt?miseen, mit? tietoturvaty?t? toiminnallisuudelle on tarpeen tehd?.Tarkastuslista ei kata kaikkia tietoturva-aktiviteetteja vaan ainoastaan ne teht?v?t, joiden avulla loput aktiviteetit voidaan l?yt??. Tyypillisimmin olennaisin teht?v? on uhkamallinnus. Uhkamallinnuksen suorittaminen paljastaa muut tietoturvatarpeet.Tarkastuslistaa voidaan k?ytt?? eri tasoisille ty?listan teht?ville. Yleisimmin kohteena on k?ytt?j?kertomustasoinen (user story) teht?v?, mutta erityisesti tietosuojakysymyksiin voidaan usein vastata korkeammalla tasolla (epic). Joskus taas tarkastuslistan l?pik?yminen voi olla tarpeen my?s hyvin matalan tason teht?villekin - esimerkiksi jos todennusmekanismissa suoritetaan bugikorjaus.Tarkastuslistaa k?ytet??n vastaamalla vasemman sarakkeen kysymyksiin. Jos vastaus on my?nt?v?, varmistetaan, ett? teht?v?listalla on oikeassa sarakkeessa merkitty teht?v?. Syv?llisemp?? analyysi? ei v?ltt?m?tt? t?ss? vaiheessa tarvita; listan lopussa on esitetty mallitekstej?, jotka voi yleisimmin leikata ja liimata.Teht?v?t luokitellaan k?ytt?en ty?nohjausj?rjestelm?n leimoja (label tai tag), jotta tietoturva- ja tietosuojaty?n seuraaminen on mahdollista.Liittyyk? uusi tai muuttunut toiminnallisuus......uuden tietovarannon kuten tietokannan k?ytt??nottoon?...todennuksen, valtuutuksen tai istuntojen hallinnan toteutukseen?...j?rjestelm?n tuotantoonviennin periaatteen muutoksiin?...uuden kolmannen osapuolen riippuvuuden k?ytt??nottoon?...uuden rajapintaintegraation k?ytt??nottoon?...olemassa olevan oman rajapinnan toiminnallisuuden laajentamiseen?Teht?v?listalla on teht?v? (1) joka linkitet??n toiminnallisuuden toteuttavaan teht?v??nTeht?v?listan teht?v?ll? on (1) luokitus "uhkamallinnus"...muutokseen henkil?tietojen k?sittelyss? (mit? tai miten k?sitell??n)?...muutokseen analytiikassa, mainostuksessa tai profiloinnissa?Tuotteen teht?v?listalla on teht?v? (2) joka linkitet??n toiminnallisuuden toteuttavaan teht?v??nToiminnallisuuden toteuttavalla teht?v?ll? on luokitus "tietosuoja" ja lis?tyll? teht?v?ll? (2) luokitus "pia"Tuotteen teht?v?listalla on teht?v? (1) joka linkitet??n toiminnallisuuden toteuttavaan teht?v??nTeht?v?ll? (1) on luokitus "uhkamallinnus"...henkil?tietojen laajamittaisen k?sittelyn, kattavan profiloinnin, j?rjestelm?llisen valvonnan tai tietojen EU:n ulkopuolelle viennin aloittamiseen?...muutokseen henkil?iden arvioinnissa, automaattiseen oikeusvaikutusten luomisessa?...muutokseen arkaluontoisten tai haavoittuvassa asemassa olevien henkil?iden tietojen k?sittelyss??...uuden tai innovatiivisen henkil?tietojen hankinnan tai k?sittelytekniikan k?ytt??nottoon?Tuotteen teht?v?listalla on teht?v? (3) joka linkitet??n toiminnallisuuden toteuttavaan teht?v??nToiminnallisuuden toteuttavalla teht?v?ll? on luokitus "tietosuoja" ja lis?tyll? teht?v?ll? (3) luokitus "pia"Tuotteen teht?v?listalla on teht?v? (1) joka linkitet??n toiminnallisuuden toteuttavaan teht?v??nLis?tyll? teht?v?ll? (1) on luokitus "uhkamallinnus"Teht?v? (1): "Suoritetaan uhkamallinnus toiminnallisuudelle k?ytt?en STRIDE-menetelm?? (turvallisen ohjelmistokehityksen k?sikirjan Liite 5: Uhkamallinnuksen toteutusohje). Uhkamallinnuksessa l?ytyvien riskien ehk?isemiseen tarkoitetut vaatimukset kirjataan tuotteen teht?v?listalle."Teht?v? (2): "Suoritetaan tietosuojavaikutusten arviointi (turvallisen ohjelmistokehityksen k?sikirjan Liite 6: Tietosuoja). Tietosuojavaikutusten arvioinnissa l?ytyvien riskien ehk?isemiseen ja lain noudattamiseen tarkoitetut vaatimukset kirjataan tuotteen teht?v?listalle."Teht?v? (3): "Suoritetaan tietosuojavaikutusten arviointi tietosuoja-asetuksen m??r??m?ll? tavalla (DPIA) (turvallisen ohjelmistokehityksen k?sikirjan Liite 6: Tietosuoja). Tietosuojavaikutusten arvioinnissa l?ytyvien riskien ehk?isemiseen ja lain noudattamiseen tarkoitetut vaatimukset kirjataan tuotteen teht?v?listalle."Tietoturva-arkkitehtuurin dokumentoinnin v?himm?isvaatimukset (Liite 4)Tietoturva-arkkitehtuurikuvaus tulisi mieluiten tehd? versiohallittuun kirjoitusalustaan (esimerkiksi Confluenceen), jotta erillisten, vanhentuvien dokumenttien levi?mist? ehk?ist??n.Tietoturva-arkkitehtuurin kuvauksen t?sm?llinen muoto ja sis?lt? riippuu toteutettavasta palvelusta, mutta minimiss??n se sis?lt?? kolme tietovuokuvausta (Data Flow Diagram):J?rjestelm?n kontekstitason kuva, joka n?ytt?? tietovirrat ja eriteltyin? henkil?tietovirrat j?rjestelm?n ja sen ulkopuolisten liitynt?jen v?lill?, mukaan lukien k?ytt?j?t. Kontekstitason yhteydess? kirjoitetaan my?s auki keskeisimm?t k?ytt?tapaukset lyhyesti; k?ytt?tapauksissa mainittujen j?rjestelmien tulisi olla n?kyviss? kuvassa.J?rjestelm?n komponenttitason kuva, joka n?ytt??j?rjestelm?n rakenteen yksitt?isten k?ytt?j?rjestelm?prosessien tasolle; sek?n?iden prosessien v?liset tietovirrat, henkil?tietoja sis?lt?v?t tietovirrat erikseen merkittyin?; sek?j?rjestelm?n luottamusalueet eli mitk? komponentit luottavat absoluuttisesti toisiinsa eli eiv?t tarvitse keskin?ist? todennusta eiv?tk? valtuutusta; sek?monimutkaisemmista protokollista tai interaktioista viestisekvenssikaaviot (Message Sequence Chart). Tuotantoon viennin tietovirtakaavio, joka n?ytt?? tuotantoon viennin j?rjestelm?t ja tietovirrat. N?it? j?rjestelmi? ovat muun muassa kehitt?jien koneet, versionhallinta, integraatiopalvelimet ja salaisuuksien hallinnassa k?ytett?v?t palvelut.Kuvat voidaan tuottaa osana uhkamallinnusta ja henkil?tietoihin liittyv? osuus tietosuojavaikutusten arvioinnin yhteydess?.Mik?li arkkitehti hallitsee t?it??n tiket?intipohjaisen ty?nohjauksen kautta, arkkitehtuuridokumentaation p?ivitt?minen kannattaa my?s tiket?id?, jotta sille tulee varattua riitt?v?sti aikaa.Mik?li organisaatio ei ole osoittanut tietosuojavaikutusten arviointien tuloksille erillist? paikkaa, my?s tietosuojavaikutusten arviot kirjataan tietoturva-arkkitehtuurikuvauksen jatkoksi. T?m?n dokumentaation sis?lt? on kuvattu kappaleessa Tietosuoja.Uhkamallinnuksen toteutusohje (Liite 5)Uhkamallinnus yleisestiUhkamallinnus (threat modeling tai architectural risk analysis) on menetelm?, jossa kartoitetaan arkkitehtuurin ja tietovuokaavion avulla mahdollisia sovellusturvallisuuden ja tietosuojan riskej? sek? riskien hallintamekanismeja.T?ss? ohjeessa suositellaan k?ytett?v?ksi Microsoftin STRIDE-menetelm??. Projektin tietoturva-asiantuntijaa, mik?li t?llainen on nimetty, voi k?ytt?? uhkamallinnuksen fasilitaattorina, jolloin mukana olijat oppivat menetelm?n ty?n ohessa. Lyhyt selitys menetelm?st? on my?s alempana.Uhkamallinnuksen tulisi olla tuotetiimin yhteisty?n tulos. Uhkamallinnuksen tavoite on olla luova riskienkartoitusharjoitus ja usean eri henkil?n n?k?kulmat yhdess? antavat yleens? paremman n?kyvyyden mahdollisiin ongelmiin. Uhkamallinnuksen tuloksena syntyy lista mahdollisista tietoturvaheikkouksista tai haavoittuvuuksista ja yleens? my?s suoraan ehdotuksia asioista, mit? n?ille voisi tehd?. Tyypillisi? tuloksia ovat esimerkiksi testaustarpeet, tietyt yksitt?iset testitapaukset, tarve muuttaa arkkitehtuuria tai matalamman tason suunnittelua, tai jonkin tietoturvaominaisuuden lis??minen.N?m? l?yd?kset siirret??n tuotteen teht?v?listalle uusina teht?vin? tai olemassa olevien teht?vien hyv?ksynt?kriteerein?. Uudet teht?v?t luokitellaan avainsanalla "uhkamallinnus".L?hteet:STRIDE-metodi: Adam Shostack: Threat Modeling: Designing for Security. Wiley, 2014.Uhkamallinnuksen aikataulutusParas tulos uhkamallinnukselle saadaan, jos sit? vaaditaan osana tuotteen teht?v?listaa t?rkeimpien toiminnallisten vaatimusten hyv?ksynt?kriteerin? tai erillisen? teht?v?n?, joka on linkitetty toiminnalliseen vaatimukseen. N?in mallinnusteht?v?t s?ilyv?t j?rjellisen kokoisina ja asioista keskustellaan ajoissa, jolloin muutosten teko on helpointa.Mik?li k?ytet??n Scrum-mallia, uhkamallinnusta ei yleens? kannata tehd? osana Sprint Planningia vaan pikemminkin ty?jakson (sprintin) kest?ess?. Yksi vaihtoehto on poimia ty?jakson sis?lt??n esimerkiksi tulevien ty?jaksojen toiminnallisuuksien uhkamallinnusta, jolloin uhkamallinnus kulkee 1-2 ty?jaksoa toteutusta edell?. Uhkamallinnuksen tekeminen edelt?v?ll? ty?jaksolla ehk?isee my?s sit?, ett? ty?jakso ep?onnistuisi ilmenev?n lis?ty?n vuoksi. Uhkamallinnuksen k?yt?nn?n aikataulutus on my?s vapaampaa, jos se ei kohdistu juuri sill? hetkell? toteutuksen alaisena olevaan toiminnallisuuteen. Ks. my?s kappale Erityishuomioita tiettyihin ohjelmistokehitys- ja kulttuurisiin malleihin.Uhkamallinnuksen voi my?s suorittaa toteutuksen j?lkeen. Vaikka se ei tuolloin pystyk??n ennustamaan tietoturvaongelmia, toimii se silti erinomaisena retrospektiivin?. J?lkik?teisen uhkamallinnuksen tulokset ovat usein konkreettisempia ja se toimiikin hyv?n? tietoturvatarkastusta edelt?v?n? aktiviteettina.Uhkamallinnus k?yt?nn?ss?Tyypillinen uhkamallinnus suoritetaan ty?pajatyyppisesti. Paikalle pyydet??n kaikki ne henkil?t, jotka tiet?v?t tekniset yksityiskohdat arkkitehtuurista ja toteutuksesta. Organisaation pilvitiimin edustajan tulisi olla mukana uhkamallinnuksessa ainakin silloin, kun toiminnallisuudella on yhtym?kohtia pilvi-infrastruktuuriin tai l?pileikkaaviin, kaikille tuotetiimille yhteisiin teemoihin. K?yt?nn?ss? noin viisi henkil?? on sopiva m??r?. Paikalle kannattaa pyyt?? my?s tuoteomistaja ja k?ytt?kokemuksesta vastaava henkil?, mik?li mallinnettava toiminnallisuus on t?ysin uutta. Ty?pajalle on hyv? varata 1-2 tuntia aikaa. Pienet toiminnallisuudet hoituvat nopeammin, jopa kahvip?yt?keskusteluna, mutta kaksi tuntia ylitt?? yleens? ihmisten sietokyvyn. Jos kyseess? on laaja analyysi, esimerkiksi jo rakennetun toiminnan retrospektiivinen mallinnus, sessioita on todenn?k?isesti j?rjestett?v? useita.Ty?pajassa piirret??n tussitaululle tietovuokaavio (data flow diagram, DFD) tai viestisekvenssi-kaavio (message sequence chart, MSC). Viestisekvenssikaavio kannattaa mahdollisesti tuottaa jo ennakkoon niiden monimutkaisuuden vuoksi.Tietovuokaaviota k?ytet??n, jos mallinnetaan ajossa olevaa j?rjestelm?? (sen prosesseja, tietovarastoja ja eri komponenttien v?list? kommunikaatiota) tai tuotantoon viennin arkkitehtuuria, kuten yhteyksi? versionhallintaj?rjestelmiin tai CI/CD-putkea.Viestisekvenssikaaviota k?ytet??n, jos mallinnetaan useita viestej? edestakaisin l?hett?vi? toiminnallisuuksia - esimerkiksi todennusta tai toiminnallisuutta, jossa selainta ohjataan eri rajapintoihin tai palveluihin toiminnon aikana.Kaavion piirt?minen tussitaululle on olennainen osa mallinnusta. Valmiita kuvia voi k?ytt?? referenssin?, mutta niit? ei pit?isi (monimutkaista MSC:t? lukuun ottamatta) ottaa suoraan pohjaksi. Usein k?y niin, ett? valmis kuva ei vastaakaan todellisuutta tai kaikkien osallistujien k?sitys arkkitehtuurista ei ole yhtenev?inen. N?m? olettamusten erot ovat kokemusper?isesti usein tietoturvaongelmien l?hde.Kaavion voi piirt?? esimerkiksi yksi k?ytt?j?tarina kerrallaan, jolloin mukaan otetaan ne komponentit, jotka kulloinkin tarvitaan. Kaaviosta ei pid? unohtaa ihmisi?, joita ovat sek? k?ytt?j?t, kehitt?j?t ett? yll?pito.Kun kuva on valmis, jokainen piirretty tietovuo ja tietovarasto k?sitell??n keskustelemalla kuutta eri aihealuetta (STRIDE):Spoofing eli todennukseen liittyv?t asiat (esim. komponenttien v?lisen liikenteen p??tepisteiden todennus)Tampering eli eheyteen liittyv?t asiat (esim. hy?kk??j?n mahdollisuus muuttaa tietoa)Repudiation eli kiistett?vyyteen liittyv?t asiat (esim. auditointilokin luonti ja mit? sinne tallennetaan)Information disclosure eli luottamuksellisuuteen liittyv?t asiat (esim. p??seek? hy?kk??j? k?siksi salaamattomaan tietoon, tai vuotaako tietoa sivukanavia pitkin)Denial of Service eli saatavuus ja palvelunestohy?kk?ykset (esim. jos tietty komponentti ei vastaa, mit? se aiheuttaa, tai onko jonkin komponentin kautta mahdollisuus generoida liikaa kuormaa jollekin toiselle komponentille)Elevation of Privilege eli k?ytt?valtuuksien ylitt?minen (esim. koodi-injektiohy?kk?ykset)Keskustelun voi ohjata esimerkiksi niin, ett? kehitt?j?t ottavat yhden tietovuon kerrallaan (joko DFD- tai MSC-kuvasta) ja lausuvat ??neen teknisen perusteen sille, miksi esimerkiksi todennus on turvallisesti tehty.Esimerkki: "Palvelin A tiet??, ett? sit? kutsuu palvelin B, koska niiden v?lill? k?ytet??n TLS:?? ja palvelin A laittaa palvelinkohtaisen API-avaimen jokaisen HTTP-kutsun otsakkeeseen."Muiden teht?v? on kyseenalaistaa t?t? argumenttia ja tehd? tarkentavia kysymyksi?. Esimerkki: "Tuo sama API-avain on k?yt?ss? my?s A:n testiversiolla, joten tarkasti ottaen B ei tied?, kutsuuko sit? tuotanto- vai testiversio." "Muuten hyv?, mutta emme ole vaihtaneet API-avainta vuosiin." "Ja API-avain on tallennettu versionhallintaan koodin kanssa."Vastalauseet saavat olla hypoteettisia, kunhan ne ovat jollakin tavoin perusteltuja. Vastalauseista kirjataan tiketti, joka korjaa kunkin havaitun ongelman tai heikkouden tai v?hent?? hypoteettisen ongelman riski?.Kun kukaan ei en?? pysty keksim??n heikkoja kohtia argumentaatiosta (tai argumentti on osoitettu vaillinaiseksi ja tarvittavat toimenpiteet on kirjattu), voidaan siirty? eteenp?in. Seuraava keskustelun kohde voidaan valita mekanistisesti STRIDE-mallin mukaan tai vapaammin mielenkiinnon ja prioriteettien mukaan.Mik?li uhkamallinnusta tehd??n henkil?tietoja k?sittelev?lle toiminnallisuudelle, keskustelua voidaan jatkaa nk. TRIM-lis?yksell?, jota k?ytet??n aivan samoin kuin STRIDE?:Transfer of personal data: Siirret??nk? tietovuossa henkil?tietoja maan, organisaation tai sopimusteknisen rajan ylitse, ja onko t?h?n oikeutus ja lupa? Onko siirron kohde oma rekisterinpit?j?ns? vai ainoastaan k?sittelij? ja jos j?lkimm?inen, onko se sopimuksellisesti sovittu?Retention / Removal: Jos komponentti tallentaa henkil?tietoja, onko m??ritelty aika- tai muu kriteeri, jonka perusteella tallennetut tiedot tuhotaan; miten teknisesti toteutetaan yksitt?isen henkil?n tietojen poisto tarvittaessa ja miten yksitt?isen henkil?n tietojen k?sittely voidaan pyynn?st? keskeytt??.Inference: Yhdisteleek? komponentti useista eri l?hteist? tulevia henkil?tietoja muodostaen niist? uusia henkil?tietotyyppej?, joita tallennetaan tai v?litet??n edelleen? Muuttaako se tietoa, joka aiemmin ei ollut henkil?tietoa, henkil?tiedoksi yhdist?m?ll? sit? muuhun henkil?tietoon? Onko n?m? uudet henkil?tietotyypit otettu huomioon tietosuojavaikutusten arvioinnissa?Minimisation: Kun komponentti l?hett?? henkil?tietoja eteenp?in (esimerkiksi johonkin rajapintaan), onko t?m? henkil?tietojen joukko teknisesti ottaen pienin mahdollinen, vai voisiko sit? viel? entisest??n pienent?? teknisen toiminnallisuuden k?rsim?tt??TRIM ei korvaa tietosuojavaikutusten arviointia (PIA, privacy impact assessment tai DPIA, data protection impact assessment), mutta se toimii alimman tason turvaverkkona sen suhteen, ett? jos henkil?tietojen k?sittelyst? ei ole aiemmin tehty vaatimuksia, asia nousee viimeist??n t?ss? vaiheessa keskusteluun.Mik?li TRIM-analyysiss? ilmenee, ett? jokin tietosuojan?k?kanta on huonosti selvitetty, lis?t??n teht?v?listalle uusi teht?v? tietosuojavaikutusten arvioinnista (ks. Liite 6: Tietosuoja), joka luokitellaan avainsanalla "pia".Uhkamallinnuksen laatu?Uhkamallinnuksen tulosten laatuun vaikuttaa usein melko paljon sit? tekevien henkil?iden kokemus. Monet heikkoudet nimitt?in ilmenev?t eri j?rjestelmiss? uudestaan ja uudestaan, ja kokemus mahdollistaa tehokkaan uhkamallinnuksen paremmin kuin vain listojen l?pik?ynti.Kuitenkin on k?ynyt kokemuksen pohjalta selv?ksi, ett? nimenomaan STRIDE-tyyppinen, suhteellisen vapaamuotoinen mutta kuitenkin ohjattu analyysimenetelm? tuottaa varsin hyvi? tuloksia ammattimaisten ohjelmistokehitt?jien k?siss? jo yhden tai kahden fasilitoidun esimerkkity?pajan j?lkeen.Yksi t?rkeimmist? laadun takeista on olla hyv?ksym?tt? oletuksiin perustuvia tietoturva-argumentteja. Jos keskustelussa k?y ilmi, ett? jostakin tietovirrasta tai sen sis?ll?st? ei ole t?ytt? varmuutta, se kannattaa varmistaa esimerkiksi koodia lukemalla, rajapintakuvauksesta tai protokolla-analysaattorilla. Samaten kuvan piirt?misess? kannattaa olla huolellinen; notaatiolla ei juuri ole merkityst?, kunhan on selv??, mik? komponentti keskustelee mink?kin kanssa.Uhkamallinnus, kun tekninen ratkaisu on viel? tuntematonJos uhkamallinnusta tehd??n korkean tason teht?v?lle (epic), esimerkiksi portfoliokanbanin analyysivaiheessa tietosuojatarkastelun ohessa, on hyvin mahdollista, ett? toteutusta ei viel? tunneta riitt?v?ll? tarkkuudella DFD- ja MSC -tyyppisten kaavioiden piirt?miseksi ja STRIDE-keskustelun pohjaksi.T?ll?in voidaan k?ytt?? muita riskienl?yt?menetelmi?. Yksi sellaisista on nk. hy?kk??j?tarinoiden (attacker story tai abuse case) luominen, jossa pyrit??n l?yt?m??n ei-toivottuja k?ytt?j?tarinoita, jotka ovat yleens? muotoa"Hy?kk??j? (jokin j?rjestelm?n kanssa yhteydess? oleva ihminen) k?ytt?? hyv?kseen (hypoteettista) heikkoutta tai haavoittuvuutta (oletetussa) kohdej?rjestelm?ss? ja saa aikaan teknisen vaikutuksen, joka johtaa liiketoiminnalliseen vaikutukseen (ei-toivottuun lopputulokseen)."Hy?kk??j?tarinat voidaan kirjata k?ytt?j?tarinoiksi, mutta niiden toteutus tehd??n toteuttamalla tietoturvatoiminnallisuutta (kontrolleja) tai tietoturva-aktiviteetteja. Hy?kk??j?tarinan olemassaolo teht?v?listalla kuitenkin varmistaa sen, ett? identifioitu tietoturvaty? tulee n?kyv?ksi.Hy?kk??j?tarinoita voi luoda yksinkertaisesti luomalla esimerkiksi valkotaululle nelj? saraketta, joihin saadaan sis?lt? seuraavasti:Hy?kk??j?t: Kaikki ihmiset, jotka pystyv?t toimimaan j?rjestelm?n kanssa kuten k?ytt?j?t, kehitt?j?t, yll?pit?j?t, asiakaspalvelu, satunnaiset Internet-k?ytt?j?t, jne.Hy?kk?ysskenaariot: Voivat olla hypoteettisia, eli n?iden heikkouksien olemassaoloa ei tarvitse todistaa - kunhan ne ovat realistisia.Vaikutukset j?rjestelmille: Tiedossa olevat tekniset j?rjestelm?t ja millaisen vaikutuksen niille voisi aiheuttaa.Ei-toivottu lopputulos: Jotakin, jota ei haluta tapahtuvan.K?yt?nn?ss? sarakkeiden t?ytt?minen kannattaa aloittaa reunoilta (hy?kk??j?t ja ei-toivotut lopputulokset). Ei-toivotut lopputulokset voidaan saada selville ottamalla toivottu lopputulos ja listaamalla tapoja, joilla ne voivat menn? pieleen. Esimerkiksi "asiakas saa s?hk?postilla kuittauksen" voisi muuttua muotoihin "s?hk?postikuittausten saaminen estyy" tai "s?hk?postikuittaus l?hetet??n hy?kk??j?n osoitteeseen".?Vaikutuksen ei tarvitse olla liiketoiminnallinen tai organisatorinen - tietosuojamieless? my?s vaikutus johonkuhun rekister?ityyn henkil??n voi olla ei-toivottu lopputulos.Vaikutukset j?rjestelmille on usein helpohko johtaa ei-toivotuista lopputuloksista kysym?ll?, millainen j?rjestelm?ongelma sitten aiheuttaisi asianomaisen ei-toivotun lopputuloksen. N?it? saattaa olla useampia. Esimerkiksi edell? mainitun s?hk?postikuittauksen saamisen estymisen voisi aiheuttaa s?hk?postipalvelimen palvelunestotila tai s?hk?postien p??tyminen roskapostiin, koska palvelin on p??tynyt mustalle listalle.Hy?kk?ysskenaarioiden luetteleminen on n?ist? ehk? hankalin vaihe, mutta t?h?n voi k?ytt?? esimerkiksi tietoturva-asiantuntijan tai MITREn ATT&CK- ja CAPEC-resurssien apua. MITRE ATT&CK on t?ss? k?sikirjassa mainittu aiemmin yhten? ohjeellisena vaatimusl?hteen?. MITRE CAPEC toimii sovellustasolla sen vastinparina.Kun kaikissa sarakkeissa on sis?lt??, n?it? yhdistelem?ll? voidaan luoda hy?kk??j?tarinoita, jotka voidaan sitten kirjata teht?v?listalle "negatiivisina" k?ytt?tapauksina. Hy?kk??j?tarinoiden keskin?inen t?rkeysj?rjestys voidaan saada selville valitsemalla ik?vimm?t ei-toivotut vaikutukset ja seuraamalla n?ihin loppuvia tarinan kaaria.?Tietosuojan toteutumisen varmistaminen (Liite 6)Tietosuojavaikutusten arviointi yleisestiTietosuojavaikutusten arvioinnin tarvittavat taustatiedot ja monet toimenpiteetkin ovat k?yt?nn?ss? samat kuin uhkamallinnuksen ja tietoturva-arkkitehtuurin, joten samat henkil?t, jotka ovat tekem?ss? uhkamallinnusta ja dokumentoimassa arkkitehtuuria ovat todenn?k?isesti parhaita tekem??n my?s tietosuojavaikutusten arvioinnin. Tarvittaessa apua voidaan pyyt?? organisaation tietosuojafunktiolta.Tietosuojavaikutusten arvioinnin vaiheet ovat:M??ritell??n kohde. Yleens? t?m? on tietyn tuotteen teht?v?listan teht?v?n kuvaama toiminnallisuus tai laajempi kokonaisuus. Tietosuojavaikutusten arvioinnista avataan dokumentointia varten oma teht?v?, joka linkitet??n kohteena olevaan teht?v??n ja luokitellaan avainsanalla "pia".Selvitet??n kohteen henkil?tietovirrat ja tallennuspaikat konteksti- ja komponenttitasolla. T?m? on sama vaatimus kuin mik? tarvitaan tietoturva-arkkitehtuurin dokumentaatioon (ks. Liite 4: Tietoturva-arkkitehtuurin dokumentoinnin v?himm?isvaatimukset). Henkil?tietovirroista on selvitett?v? niiss? siirrett?v?t henkil?tietotyypit ja se, mill? tavalla siirron tai tallennuksen suojaus on toteutettu.Varmistetaan, ett? kohteen uhkamallinnus (ks. Liite 5: Uhkamallinnuksen toteutusohje TRIM-lis?yksin) on tehty.Kohdassa 2 selvitetyille henkil?tietovirroille ja -varannoille kirjataan:K?sittelyn laillinen perusteK?sitelt?vien henkil?tietojen m??r? ja laatu. Mik?li k?sitell??n erityisi? henkil?tietoryhmi? eli "arkaluonteisia" henkil?tietoja tai erillislains??d?nn?n alaisia henkil?tietoja, t?m? on huomioitava erikseenHenkil?tietojen maantieteellinen sijainti ja peruste niiden viemiselle pois EU:n alueelta, jos n?in tapahtuuLuettelo ulkopuolisista tietojen k?sittelij?ist?, jotka saavat henkil?tietoja, mukaan lukien mahdolliset k?ytt?palvelun toimittajat; jos n?it? on, varmistetaan, ett? sopimuksissa on huomioitu tietosuoja-asetuksen vaatimuksetK?yd??n l?pi kappaleen Tietosuojan suunnittelun yleisperiaatteet vaatimukset ja varmistetaan, ett? ne t?yttyv?tMik?li kohdan 4 keskustelussa ilmenee puutteita tavoitetilaan (esimerkiksi vastausta ei osata antaa), puutteiden korjaamisesta luodaan teht?v? tuotteen teht?v?listalle. T?m? teht?v? linkitet??n kohteena olevaan teht?v??n ja luokitellaan avainsanalla "pia".Muut kohdan 4 tiedot dokumentoidaan mieluiten versioituun kirjoitusalustaan kuten wikiin, ja luodut korjausteht?v?t linkitet??n t?h?n dokumentaatioon. Organisaation tietosuojatoiminto voi osoittaa t?lle dokumentaatiolle keskitetyn paikan. Muussa tapauksessa dokumentaatio kirjataan tietoturva-arkkitehtuurikuvauksen yhteyteen.Mik?li yll? kuvattujen analyysien ja uhkamallinuksen pohjalta p??dyt??n siihen, ett? henkil?tietoihin kohdistuu todenn?k?isesti korkea riski, otetaan yhteytt? <organisaatio>:n tietosuojavastaavaan. Tietosuojavastaava k?ynnist?? tarvittaessa tietosuoja-asetuksen vaatiman tietosuojavaikutusten arvioinnin (DPIA). Todenn?k?isesti korkea riski muodostuu aina kun k?sitell??n suuria m??ri? henkil?tietoja tai laajamittaisesti erityisi? henkil?tietoluokkia ("arkaluontoisia" tietoja). Tietosuoja-asetuksen vaatima tietosuojavaikutusten arviointi (DPIA)<organisaation> tietosuojavastaavan k?ynnist?m?ss? ja ohjaamassa tietosuoja-asetuksen tarkoittamassa tietosuojavaikutusten arvioinnissa (Data Protection Impact Assessment, DPIA) kehitysprojekti toimittaa ainakin seuraavat tiedot:j?rjestelm?llinen kuvaus suunnitelluista k?sittelytoimista ja k?sittelyn tarkoituksista; jaarvio k?sittelytoimien tarpeellisuudesta ja oikeasuhteisuudesta tarkoituksiin n?hden; jaarvio rekister?ityjen oikeuksia ja vapauksia koskevista riskeist?; jasuunnitellut toimenpiteet riskeihin puuttumiseksi, mukaan lukien suoja- ja turvallisuustoimet ja mekanismit.Kohdan 4 osalta tuotetiimin tulisi pysty? identifioimaan ne tuotteen teht?v?listan teht?v?t, joissa suunnitellut toimenpiteet on kuvattu.Tietosuojavaikutusten arvioinnissa yll?mainittujen kohtien teemat keskustellaan tietosuojavastaavan, tuoteomistajan ja tarvittavien tuotetiimin teknisten asiantuntijoiden kesken. Keskustelu dokumentoidaan. Mik?li keskustelun tuloksena vaaditaan toiminnallisia muutoksia, ne avataan uusina teht?vin? tuotteen teht?v?listalle samoin kuin uhkamallinnuksesta seuraaville uusille vaatimuksille tehd??n. N?m? uudet teht?v?t leimataan avainsanalla ”pia”.Tekninen liite (Liite 7, ohje) Palvelimen TLS-asetukset Yleist? TLS-asetuksien noudattamisestaK?ytett?ess? pilvipalveluiden tarjoamia edustapalveluita, kuten CDN:?? (content delivery network) tai kuormantasaimia (load balancer), t?ytt? kontrollia TLS:n konfiguraatioon ei ehk? ole. T?ll?in on k?ytett?v? parhaiten vaatimuksia vastaavaa pilvipalveluntarjoajan TLS-konfiguraatiota. Riippuen arkkitehtuurista saattaa olla my?s mahdollista k?ytt?? kuormantasaukseen TCP/UDP-tason kuormantasainta (esimerkiksi AWS:n Network Load Balancer) ja purkaa TLS vasta sovelluksen omassa edustapalvelimessa (esimerkiksi Kubernetes-klusterin Ingress-resurssi). T?m? tietenkin siirt?? osan protokollapinosta tuotetiimin vastuulle, joka ei v?ltt?m?tt? muista syist? ole toivottava tilanne.Riskit, jotka syntyv?t vaatimusten vastaisesta TLS-konfiguraatiosta verrattuna TLS:n purkuun l?hell? ty?kuormia ovat erilaisia. Vaatimusten vastainen TLS-konfiguraatio liittyy l?hinn? aktiivisten v?lityshy?kk?ysten ja laajamittaisen tiedustelun riskeihin. TLS:n purku (esimerkiksi) Kubernetes-klusterin sis?ll? taas tuo monimutkaisuutta ja lis?? hy?kk?yspintaa ja voi altistaa t?t? kautta tietomurrolle. Jos TLS-toteutusta aiotaan hallita itse, l?hitulevaisuuden kannalta on tarpeellista ottaa huomioon HTTP/3 ja TLS 1.3, jotka tulevat yhten?ist?m??n TLS-vaatimuksia ja toisaalta tuomaan tarpeita uusille protokollatoteutuksille (QUIC) ja UDP:n tukemiselle siirtoprotokollana.CDN:n osalta riskit ovat TLS:n osalta yleens? pienemm?t, koska staattinen sis?lt? ei yleens? ole luottamuksellista. CDN:n sis?ll?n suhteen suurempi huolenaihe on sis?ll?n eheys. T?t? voidaan esimerkiksi ajettavan JavaScript-koodin osalta auttaa subresource integrityll? (ks. my?hemmin). ProtokollaversioPalveluiden tulee tukea TLS 1.2 -versiota ja tukea TLS 1.3:ta heti kun mahdollista. Nykyaikaiset selaimet tukevat lis??ntyv?ss? m??rin TLS 1.3 -versiota jo nyt.TLS:n versiota 1.1 tulee k?ytt?? ainoastaan, jos toinen osapuoli ei tue 1.2-versiota. On kuitenkin hyvin harvinaista, ett? osapuoli tukisi 1.1:t? mutta ei 1.2:ta. Vanhempia TLS- tai SSL-versioita (TLS 1.0, SSL) ei tule tukea.Tuen poistaminen TLS 1.0 -protokollalta aiheuttaa yhteensopivuusongelmia l?hinn? vanhempien mobiiliselainten kuten Android 4.4:n WebView’n, sek? Java 8:aa vanhempien versioiden kanssa, koska ne tukevat ainoastaan TLS 1.0:aa.L?hteet:YhteensopivuustaulukotTLS 1.3-tuki 1.2 -tuki m??r?ys 72A/2018 s?hk?isist? tunnistus- ja luottamuspalveluista, joka vaatii TLS 1.2:n k?ytt??:: VarmenteetJ?rjestelmiss?, joilla ei ole kansallista suojaustasoa, varmenteiden tulee olla joko RSA-avaimia, jolloin tulee k?ytt?? v?hint??n 2048-bittisi? avaimia, tai ECDSA-avaimia, jolloin tulee k?ytt?? v?hint??n 224-bittisi? avaimia. Varmenteiden allekirjoitus tulee perustua SHA-256-tiivisteeseen. N?m? avaimenpituus- ja algoritmisuositukset tulee s??nn?llisesti tarkistaa, jotta edistysaskeleet kryptoanalyysiss? otetaan huomioon. Pitk?ik?isiksi tarkoitetuissa j?rjestelmiss? pit?? huomioida se, ett? k?ytettyj? algoritmeja ja avainpituuksia voidaan vaihtaa tarvittaessa.Jos j?rjestelm?lle on m??ritelty kansallinen suojaustaso, avainpituuksissa tulisi noudattaa Viestint?viraston kryptografisen vahvuuden ohjetta (ks. L?hteet).Varmenteen vanhetessa tulisi luoda uusi avain ja t?lle avaimelle hakea uusi varmenne. Varmenteet eiv?t saa olla wildcard-varmenteita, jotka ovat kelpoja kaikille alidomaineille.Uusista my?nnett?vist? varmenteista tallennetaan tieto Certificate Transparency -lokeihin. T?m? mahdollistaa seuraamisen organisaatiolle my?nnetyist? varmenteista. T?m? my?s saattaa paljastaa sis?isesti k?ytettyj? palveluosoitteita, jos n?ille haetaan varmenne julkisesta l?hteest?.Varmenteiden voimassaolo voidaan tarkistaa OCSP-protokollalla (Online Certificate Status Protocol). OCSP:n k?ytt? aiheuttaa sen, ett? selain l?hett?? varmenteen my?nt?j?lle pyynt?j? ja n?m? pyynn?t saattavat vuotaa tietoa selailusta varmenteen my?nt?j?lle. T?m?n vuoksi palvelinten tulisi k?ytt?? proaktiivista OCSP-vasteiden jakelua TLS-k?ttelyss?, joka tunnetaan nimell? OCSP Stapling. T?m? my?s nopeuttaa yhteyksien luomista.L?hteet:Kyberturvallisuuskeskuksen ohjeen 190/651/2015 ajantasainen versio: Kryptografiset vahvuusvaatimukset luottamuksellisuuden suojaamiseen – kansalliset suojaustasot , mm. OCSP Staplingin tarkastaminen: Varmenteiden my?nt?j?tK?ytett?vien juurivarmenteiden tulee olla kaikkien palvelua k?ytt?vien tahojen laitteissa oletuksena luotettuna. T?m?n tulisi sis?lt?? ainakin k?ytetyimm?t selaimet, k?ytt?j?rjestelm?t ja mobiililaitteet. K?ytt?ji? tulee tukea ymm?rt?m??n varmennevirheiden tietoturvavaikutukset, kuten ohjeistaa olemaan hyv?ksym?tt? selaimen antamaa varoitusviesti? ep?kelvosta varmenteesta. SalausalgoritmitTLS 1.3:n algoritmit m??ritell??n TLS 1.3-protokollan m??rittelyiss? ja toteutusten tulee seurata t?t?, ellei toimivaltainen viranomainen ole antanut eri ohjetta tietty? k?ytt?tarkoitusta varten.Jos k?yt?ss? on TLS 1.2, noudatetaan alla olevia ohjeita.Avaintenvaihto (TLS 1.2)Jos j?rjestelm?lle ei ole m??ritetty kansallista suojaustasoa, avaintenvaihdossa on k?ytett?v? ECDHE- tai DHE-menetelmi?. K?ytett?ess? ECDHE-menetelm?? tulee avaimen pituuden olla v?hint??n 256 bitti?, DHE-menetelm?? k?ytett?ess? 2048 bitti?. N?m? avaimenpituus- ja algoritmisuositukset tulee s??nn?llisesti tarkistaa, jotta edistysaskeleet kryptoanalyysiss? otetaan huomioon. Pitk?ik?isiksi tarkoitetuissa j?rjestelmiss? pit?? huomioida se, ett? k?ytettyj? algoritmeja ja avainpituuksia voidaan vaihtaa tarvittaessa.Jos j?rjestelm?lle on m??ritelty kansallinen suojaustaso, avainpituuksissa tulisi noudattaa Viestint?viraston kryptografisen vahvuuden ohjetta (ks. L?hteet).K?ytett?ess? elliptisten k?yrien menetelmi? (ECC) tulee kaikki k?ytett?v?t k?yr?t luetella konfiguraatiossa.Suositeltuja k?ytett?vi? k?yri? ovat BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, NIST Curve P-224, NIST Curve P-256, NIST Curve P-384 ja NIST Curve P-521.Allekirjoitus (TLS 1.2)Jos j?rjestelm?lle ei ole m??ritetty kansallista suojaustasoa, allekirjoitusalgoritmina voidaan k?ytt?? joko ECDSA- tai RSA-algoritmia. ECDSA-avaimen pituus tulee olla v?hint??n 256 bitti? ja RSA-avaimen 2048 bitti?. N?m? avaimenpituus- ja algoritmisuositukset tulee s??nn?llisesti tarkistaa, jotta edistysaskeleet kryptoanalyysiss? otetaan huomioon. Pitk?ik?isiksi tarkoitetuissa j?rjestelmiss? pit?? huomioida se, ett? k?ytettyj? algoritmeja ja avainpituuksia voidaan vaihtaa tarvittaessa.Jos j?rjestelm?lle on m??ritelty kansallinen suojaustaso, avainpituuksissa tulisi noudattaa Viestint?viraston kryptografisen vahvuuden ohjetta (ks. L?hteet).Symmetrinen salaus (TLS 1.2)Salausalgoritmin tulee olla AES k?ytt?en joko 128-bittist? tai 256-bittist? avainta. Salausmoodin on oltava CBC tai GCM. N?m? avaimenpituus- ja algoritmisuositukset tulee s??nn?llisesti tarkistaa, jotta edistysaskeleet kryptoanalyysiss? otetaan huomioon. Pitk?ik?isiksi tarkoitetuissa j?rjestelmiss? pit?? huomioida se, ett? k?ytettyj? algoritmeja ja avainpituuksia voidaan vaihtaa tarvittaessa.Jos j?rjestelm?lle on m??ritelty kansallinen suojaustaso, avainpituuksissa tulisi noudattaa Viestint?viraston kryptografisen vahvuuden ohjetta (ks. L?hteet).Tiivistefunktiot (TLS 1.2)Tiivistefunktion on oltava joko SHA-256, SHA-384, SHA-512 tai SHA-3. N?m? algoritmisuositukset tulee s??nn?llisesti tarkistaa, jotta edistysaskeleet kryptoanalyysiss? otetaan huomioon. Pitk?ik?isiksi tarkoitetuissa j?rjestelmiss? pit?? huomioida se, ett? k?ytettyj? algoritmeja ja avainpituuksia voidaan vaihtaa tarvittaessa.Jos j?rjestelm?lle on m??ritelty kansallinen suojaustaso, tiivistefunktion valinnassa tulisi noudattaa Viestint?viraston kryptografisen vahvuuden ohjetta (ks. L?hteet).TLS-salausalgoritmim??ritykset (TLS 1.2)J?rjestelmille, joille ei ole m??ritelty kansallista suojaustasoa, alla on listattu n?m? ehdot t?ytt?v?t TLS 1.2-algoritmit:DHE-RSA-AES256-GCM-SHA384ECDHE-ECDSA-AES256-GCM-SHA384ECDHE-RSA-AES256-GCM-SHA384DHE-RSA-AES128-GCM-SHA256ECDHE-ECDSA-AES128-GCM-SHA256ECDHE-RSA-AES128-GCM-SHA256DHE-RSA-AES256-SHA256ECDHE-ECDSA-AES256-SHA384ECDHE-RSA-AES256-SHA384DHE-RSA-AES128-SHA256ECDHE-ECDSA-AES128-SHA256ECDHE-RSA-AES128-SHA256L?hteet:Viestint?viraston ohjeen 190/651/2015 ajantasainen versio: Kryptografiset vahvuusvaatimukset luottamuksellisuuden suojaamiseen – kansalliset suojaustasot 1.3, RFC 8446 - Cryptographic requirements for the Interoperability FrameworkM??r?ys s?hk?isist? tunnistus- ja luottamuspalveluista, Viestint?virasto 72A/2018 M: tarkastaminen: Muut kryptografiset toteutuksetOmien kryptografisten toteutuksien tekemist? tulee v?ltt??. K?ytett?ess? kryptografisia kirjastoja on suositeltavaa k?ytt?? tunnettuja ja aktiivisesti yll?pidettyj? kirjastoja, jotka tarjoavat korkean tason rajapinnat kryptografisiin operaatioihin. Matalan tason kryptografisten primitiivien k?ytt?? tulee v?ltt??.Algoritmi- ja avainpituusvalinnoissa seurataan TLS 1.2:n valintojen periaatteita (yll?). Satunnaisen tunnisteen luominen eri ohjelmointikielill? Javaimport java.util.SecureRandom;SecureRandom random = new SecureRandom();byte bytes[] = new byte[32];random.nextBytes(bytes); Python 3.6 ja uudemmatimport secretssecrets.token_urlsafe() Python ennen versiota 3.6import randomgenerator = random.SystemRandom()generator.getrandbits(256) JavaScriptvar array = new Uint32Array(8);window.crypto.getRandomValues(array).join(""); HTTPHTTP-palvelut tulee kehitt?? ilman riippuvuuksia selaimeen asennettaviin lis?osiin (plugin) kuten esimerkiksi Javaan tai Flashiin. Ev?steetEv?steet (cookies) tulisi rajata mahdollisimman tiukasti ainoastaan niit? tarvitsevien palveluiden k?ytt??n. Mahdollisia kaikilla selaimilla toimivia rajauskeinoja ovat Path-parametri sek? Secure ja HttpOnly -attribuutit.Ev?steiden nime?misess? kannattaa lis?ksi k?ytt?? __Secure- -etuliitett? ev?steille, jotka on asetettu HTTPS-l?hteest?. Jos ev?ste voidaan rajata vain tiettyyn palvelinnimeen (alidomainit eiv?t tarvitse ev?stett?), nimi kannattaa aloittaa __Host-, joka sis?lt?? my?s __Secure- -toiminnallisuuden.Kaikkien k?ytettyjen ev?steiden tulisi poistua k?ytt?j?n selaimesta kun selain suljetaan, ellei vastakkaiselle ole erikseen m??ritelty? vaatimusta, jonka tietoturvariski on arvioitu. T?m? saavutetaan j?tt?m?ll? ev?steest? pois Expires-arvo. HTTP-otsakkeet selaimilleOtsakkeet on asetettava v?hint??n kaikille niille HTTP-vastauksille, joita kutsutaan web-selaimista.Yleisesti on my?s suositeltavaa asettaa n?m? otsakkeet rajapinnoille, joita selaimien ei ole tarkoitus kutsua, erityisesti jos n?m? rajapinnat ovat avoinna Internetiin. Lis?? tietoa API-turvallisuudesta on t?m?n ohjeen API-turvallisuuskappaleessa.Content Security PolicyContent Security Policy (CSP) -otsakkeesta on m??ritelty tasot 1 ja 2. Kaikki modernit selaimet tukevat CSP taso 2:ta. Huomionarvoisesti Internet Explorer 11 ei tue standardia CSP-otsaketta.CSP-otsakkeella voidaan rajata, mist? l?hteist? selain saa ladata sivulle esimerkiksi kuvia, skriptej? tai tyylitiedostoja.On suositeltavaa asettaa niin tiukka CSP-otsake kuin suinkin mahdollista, sallien ainoastaan nimetyt l?hteet. Mik?li tuki Internet Explorer 11 -selaimelle on tarpeen, my?s vanhemmat tietoturvaotsakkeet (alempana) pit?isi asettaa.Esimerkkej? CSP-otsakkeista:Seuraava otsake sallii sis?ll?n latauksen ainoastaan samasta l?hteest? ja rajoittaa kehysten k?ytt??:Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'; child-src 'self'; frame-ancestors 'none'Seuraava otsake on sama kuin edellinen, mutta lis?ksi raportoi poikkeukset raportointirajapintaan, josta voi olla hy?ty? konfiguraatio-ongelmien l?yt?misess?:Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'; child-src 'self'; frame-ancestors 'none'; report-uri/some-report-uriSeuraava otsake ainoastaan raportoi s??nt?j? rikkovat pyynn?t, muttei rajoita niiden lataamista. T?t? vaihtoehtoa kannattaa k?ytt?? vain palvelun kehitysvaiheessa, ei tuotannossa.Content-Security-Policy-Report-Only: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'; child-src 'self'; frame-ancestors 'none'; report-uri/some-report-uriL?hteet:CSP-otsakkeen selaintukitaulukko ty?kalu raporttien seurantaan Strict Transport SecurityHTTP Strict Transport Security (HSTS) -otsake pakottaa selaimen k?ytt?m??n kaikissa tulevissa yhteyksiss? sivustolle HTTPS-protokollaa. HSTS-otsake tulisi asettaa kaikille HTTPS-yhteyden kautta annettaville vastauksille, ja koska kaikki palvelut tulisi tarjota TLS:ll?, HSTS tulisi asettaa kaikille vastauksille.S??nn?lle annetaan yl?raja sekunteina, jonka j?lkeen voidaan taas muodostaa salaamattomia yhteyksi?. Sopiva arvo HSTS-otsakkeelle on 6 kuukautta eli 15 552 000 sekuntia. Palveluille, joita k?ytet??n samalta selaimelta harvemmin (esimerkiksi kerran vuodessa), pidempi ajanjakso voi olla tarpeen. S??nt? voidaan my?s ulottaa k?sitt?m??n kaikki aliosoitteet includeSubDomains -parametrilla.HSTS-otsake saattaa est?? palvelun k?yt?n, jos palvelimen varmenne on unohdettu uusia tai jos kuormantasaus tai CDN-palvelu k?ytt?? samaa osoitetta ilman toimivaa varmennetta.HTTPS:n oletusarvoisen k?yt?n varmistamiseksi sivusto voidaan my?s ilmoittaa etuk?teen selainvalmistajien ’preload’ -listalle (ks. L?hteet). T?ll?in otsakkeeseen on lis?tt?v? preload -direktiivi.Esimerkki:Strict-Transport-Security: max-age=15552000L?hteet: ilmoittaminen preload-listalle: otsakkeetSeuraavat otsakkeet ovat poistuvia otsakkeita, jotka ovat korvautuneet selainten uusilla ominaisuuksilla tai Content Security Policy -otsakkeella. Koska TLS-vaatimukset est?v?t monien vanhojen selainten k?yt?n, vanhat otsakkeet ovat tarpeen l?hinn? Internet Explorer 11:n vuoksi. Kirjoitushetkell? n?iden otsakkeiden tarve poistunee viimeist??n Windows 10:n my?t? 2025, elleiv?t uudet TLS-vaatimukset sulje IE 11:t? pois ennen sit?. X-Content-Type-OptionsEst?? selaimia arvaamasta sis?ll?n tyyppi?. Yleisesti ottaen kaikkien palvelimen vastausten tulisi aina m??ritell? sis?ll?n tyyppi Content-Type -otsakkeella, jossa pit?isi my?s m??ritt?? k?ytetty merkist?, jos sis?lt?tyyppi on teksti?.Esimerkki:X-Content-Type-Options: nosniffL?hteet: X-XSS-ProtectionKertoo selaimelle ottaa k?ytt??n suojaukset XSS-hy?kk?yksi? vastaan. T?m? on vanha otsake ja sis?llytetty ainoastaan Internet Explorer 11:n vuoksi, joka ei tue Content Security Policy?. Moderni vaihtoehto on Content Security Policy, joka ei salli unsafe-inline?.Esimerkki:X-XSS-Protection: 1; mode=blockL?hteet: X-Frame-OptionsX-Frame-Options -otsakkeella voidaan est?? selaimia upottamasta sivua osaksi toista sivustoa. T?t? k?ytet??n suojaamaan k?ytt?ji? clickjacking-hy?kk?yksilt?, jossa k?ytt?j? houkutellaan painamaan selaimessa linkki?, jonka "eteen" on asetettu n?kym?t?n linkki, jota k?ytt?j? todellisuudessa tulee painaneeksi.Nykyaikaisilla selaimilla Content Security Policy tason 2 frame-ancestors -direktiivill? saadaan aikaan sama efekti. Content Security Policyss? on lis?ksi frame-src -direktiivi, jolla kontrolloidaan sivun itse lataamia kehyksi?, ja t?t? X-Frame-Options ei kata.Esimerkkej?:X-Frame-Options: DENYX-Frame-Options: SAMEORIGINX-Frame-Options: ALLOW-FROM ja ExpiresCache-Control-otsakkeella ohjataan selaimen v?limuistin ja mahdollisten v?lityspalvelimien toimintaa. Otsakkeella voidaan m??ritt?? sis?ll?lle vanhenemisaika, rajoittaa sis?ll?n tallentamista v?limuisteihin ja ohjeistaa v?limuistia sis?ll?n p?ivitt?misest?.Turvallisuusn?k?kulmasta voi olla tarpeen est?? luottamuksellisen tiedon tallennus v?limuistiin. Seuraava otsake-esimerkki kielt?? sis?ll?n tallentamisen v?limuistiin, kielt?? kaiken HTTP-pyynt??n liittyv?n tiedon tallentamisen ja pakottaa selaimen aina tekem??n pyynn?n uudestaan. T?t? otsaketta ei tulisi asettaa staattisten resurssien osalta suorituskykyvaikutusten vuoksi.Esimerkki:Cache-Control: no-cache, no-store, must-revalidateExpires-otsake m??ritt?? aikaleiman, jolloin kyseinen sis?lt? tulisi merkit? vanhentuneeksi. N?m? esimerkit m??ritt?v?t tiedon olevan jo valmiiksi vanhentunutta. T?m?nkaltaista vanhenemisotsaketta tulisi k?ytt?? yhdess? Cache-Control -otsakkeen kanssa.Esimerkkej?:Expires: Thu, 01 Jan 1970 00:00:00 GMTExpires: 0L?hteet: key pinningJulkisen avaimen sitominen (public key pinning) tarkoittaa, ett? palvelimelta hyv?ksyt??n vain ennakkoon m??ritelty julkinen avain tai varmenne. T?m?n tietoturvaominaisuuden tarkoitus oli pienent?? riski? siit?, ett? hy?kk??j?n avaimelle my?nnet??n varmenne, joka mahdollistaa palvelimeksi tekeytymisen.Tuki julkisen avaimen sitomiselle on kuitenkin poistumassa selaimista, koska siit? ei tullut kovin suosittua ja koska sit? k?ytett?ess? on suuri riski itseaiheutetusta palvelunestotilasta. Jotkin selaimet tukevat sit? edelleen, mutta huomionarvioisesti Chrome poisti sen k?yt?st? ja Safari ei koskaan tukenutkaan sit?.Julkisen avaimen sitomista tulisi edelleen k?ytt?? mobiilikehityksess?, jossa mobiilisovellukselle on helpompaa m??ritell? luotettujen varmenteiden joukko, ja luotetut varmenteet voidaan h?t?tilassa p?ivitt?? ohjelmistop?ivityksell? sovelluskauppojen kautta.Julkisen avaimen sitominen selaimissa tehd??n HPKP-otsakkeella, Public-Key-Pins.HPKP:n sijaan organisaation tulisi aktiivisesti seurata Certificate Transparency -lokeja ja reagoida, jos heid?n hallussaan oleville domaineille my?nnet??n varmenteita ilman lupaa.L?hteet: ja noopenerOsana HTTP-otsakkeiden oikein m??rittely? kannattaa my?s varmistaa, ett? uuteen v?lilehteen avautuvilla ulkoisilla (ja ei v?ltt?m?tt? luotetuilla) linkeill? on asetettu attribuutti rel=noopener. noopener-attribuutti est?? sen, ettei uudessa v?lilehdess? avattu sivusto voi ohjata alkuper?ist? v?lilehte? uudelleen esimerkiksi tietojenkalastelusivustolle. Mik?li tuki Internet Explorer 11 -selaimelle on t?rke??, t?m?n lis?ksi asetetaan rel=noreferrer, jolla on sama (sivu)vaikutus. Ulkoisiin kohteisiin linkitettyjen pyynt?jen mukana kulkee my?s Referrer-otsake. T?m? saattaa vuotaa tietoja siit?, mit? henkil? oli tekem?ss? ennen kuin h?n seurasi sivulla olevaa linkki?. V??rin toteutetuissa sovelluksissa Referrer-tieto saattaa vuotaa my?s esimerkiksi tunnisteita. T?m?n vuoksi on suositeltavaa asettaa Referrer-Policy -otsake, esimerkiksiReferrer-Policy: same-originEsimerkin otsake l?hett?? Referrer-tiedot vain samalle sivustolle kuin miss? linkkikin oli. N?in sivuston omat tilastoinnit eiv?t mene rikki. Sivustoilla, joilla tieto siell? k?ymisest?kin saattaa olla arkaluontoista, otsakkeelle voi antaa arvon no-referrer.L?hteet:noopener: : Subresource IntegritySubresource integrity mahdollistaa v?hemm?n luotetusta l?hteest? kuten esimerkiksi CDN-palveluista ladattavan JavaScript-kirjastojen eheyden tarkistamisen selaimessa. Subresource integrity? voidaan k?ytt?? my?s joidenkin toimitusketjuhy?kk?ysten est?miseen: subresource integrity hylk?? hy?kk??j?n muuttamat JavaScript-riippuvuudet, ellei hy?kk??j? muuta my?s eheyden tarkistukseen k?ytett?vi? tiivisteit?.Subresource integrity? tulisi k?ytt?? kaikelle JavaScriptille, joka ladataan kolmannen osapuolen hallussa olevasta sijainnista.K?ytett?ess? subresource integrity -tarkisteita resurssit on haettava l?hteest?, joka osoittaa resurssin tunnettuun ja muuttumattomaan versioon. Subresource integrity? k?ytt?ess? ei ole mahdollista osoittaa ajoittain muuttuvaan, viimeisimp??n (’latest’) versioon.Esimerkkin? jQuery-kirjaston version 3.3.1 sis?llytt?minen sivulle ja sen eheyden tarkistus SHA-256-tiivisteen avulla:<script src=""integrity="sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU="crossorigin="anonymous"></script>Kirjaston SHA-256-tiiviste Base64-muodossa voidaan laskea seuraavalla komennolla, jos l?hdeosoitteeseen voidaan luottaa komennon ajohetkell?:curl -s | openssl dgst -sha256 -binary | openssl base64 -AL?hteet: IstuntotunnisteetHTTP-protokolla on tilaton, jolloin k?ytt?j?n k?ytt?m? selain on yksil?it?v? jollain sovellustason parametrilla, ts. istuntotunnisteella. Turvallisia tapoja istuntotunnisteen v?litt?miseksi ovat ev?steet, lomakkeiden kohdalla POST-pyynn?n parametrit, ja JavaScript-kutsuissa HTTP-otsakkeet.Mik?li k?yt?ss? on valmis ja luotettavana pidetty istuntotunnisteet hoitava sovelluskehikko, sit? tulee k?ytt??.Istuntotunnisteena k?ytett?v?n tunnisteen tulee olla yksil?llinen, riitt?v?n pitk?, ja kryptografisesti satunnainen. Suositeltu ratkaisu on k?ytt?? v?hint??n 256 bitti? pitk?? satunnaista tunnistetta.Monissa tilanteissa on saatavissa UUID-tunniste. Jos k?ytet??n UUID-tunnisteita, tulee varmistua, ett? k?ytet??n UUIDv4-muotoisia tunnisteita, jotka generoidaan satunnaisesti. T?ll?inkin tulee varmistua, ett? UUIDv4-toteutuksessa k?ytet??n kryptografisesti vahvaa satunnaislukugeneraattoria. Tyypillisesti t?m? sanotaan selv?sti UUID-kirjaston dokumentaatiossa.Istuntotunniste on luotava uudelleen aina kun k?ytt?j?n tunnistautumisen tila tai valtuutustaso muuttuu (esimerkiksi sis??nkirjautumisessa, p??k?ytt?j?ksi siirtyess? tai kirjautuessa ulos). Edellisen istuntotunnisteen on t?m?nkaltaisissa tilanteissa vanhennuttava.Jos sessiossa k?ytet??n JWT:t? (JSON Web Token), sen kryptografiset vaatimukset noudattelevat TLS 1.2:n vaatimuksia soveltuvin osin (yll?).L?hteet:UUIDv4: LokitusSovellusten tulisi tuottaa auditointilokia, joka mahdollistaa forensisen analyysin. Lokitiedot tulisi l?hett?? reaaliaikaisesti keskitetylle lokien ker?ily- ja analyysij?rjestelm?lle, jollaisen organisaatio yleens? tuottaa yhteisen? palveluna.Jotta lokitiedot olisivat k?ytt?kelpoisia forensiikkaan, on t?rke??, ett? lokitiedoissa on tarkat UTC-aikaan sidotut aikaleimat. Kaikkien palvelinten on oltava synkronoituja yhteiseen aikastandardiin, yleens? NTP:ll?. Aikaleimojen tallennukseen tulisi k?ytt?? yhtenev?ist? kielioppia, mieluiten RFC 3339:n mukaan.Lis?ksi erityisesti mikropalveluarkkitehtuureissa lokitietoihin tulisi tallentaa pyynt?tunniste, jota voidaan k?ytt?? korreloimaan lokitapahtumia eri mikropalveluiden v?lill?. Pyynt?tunnisteesta on lis?kuvaus alempana.Palveluiden tulisi lokittaa kaikki sis??n tulevat rajapintapyynn?t. Lokiin tulisi merkit? my?s pyynn?n l?hett?nyt IP-osoite, vaikka palvelu olisikin auki vain sis?verkkoon. Mik?li palvelu on kuormantasaimen tai v?lityspalvelimen takana, v?lityspalvelin on konfiguroitava v?litt?m??n ulkoinen IP-osoite edelleen proxy-protokollalla tai X-Forwarded-For -otsakkeessa.Lokitapahtumien tulisi yleens? olla JSON-objekteja. T?m? mahdollistaa uusien ja tapauskohtaisten tietoelementtien lis??misen sek? helpon lokien j?sent?misen mill? tahansa nykyaikaisella lokianalyysity?kalulla.Erityisesti ymp?rist?ss?, joka skaalautuu elastisesti kuorman mukaan, palvelujen tulisi tallentaa lokiin my?s yksik?sitteinen instanssitunnisteensa, joka koostuu sovelluksen ajossa olevan komponentin nimest? ja esimerkiksi prosessin, virtuaalikoneen tai Kubernetes-podin tunnisteesta.Kehitt?j?n tulee pysty? liitt?m??n vapaamuotoista kontekstuaalista tietoa lokitapahtumiin. T?m?n tiedon tulisi antaa tietoa siit?, mit? sovellus yritti kyseisess? tilanteessa tehd?. Jos sovellus saa lokitettavaan tapahtumaan liittyen toiselta sovellukselta ihmisluettavan virheviestin, se on hyv? liitt?? mukaan.Tapahtumat, jotka tulisi kirjoittaa lokimerkint?, ovat:Henkil?tietojen lukeminen, muuttaminen ja poisto. Lokikirjauksen tulisi sis?lt?? sovelluksen sis?inen tunniste siit? henkil?st?, kenen tietoihin kajottiin ja kuka niihin kajosi, mutta yleens? ei henkil?tietoja itsess??nHenkil?tietojen k?yt?n suostumus ja suostumuksen peruminen, k?ytt?ehtojen hyv?ksyminen, viestint?asetusten muuttuminenMuutokset istuntojen todennuksen tai valtuutuksen tilassa (sis??nkirjautuminen, k?ytt?j?tason vaihtuminen, uloskirjautuminen)Istuntotunnisteiden tarkistuksen virheetEp?onnistuneet todennus- tai valtuutusyrityksetSeuraavat tapahtumat voivat generoida liikaa lokidataa, mutta niit? voidaan my?s harkita auditointitarkoituksiin:Ep?onnistuneet kutsut taustapalvelimelle tai muihin mikropalveluihin, koska t?m? saattaa olla merkki v??rist? kutsuparametreista. Lokiin tulisi t?ll?in kirjoittaa palautettu virheviesti vapaamuotoisena tietona, jos sellainen on.Ep?onnistunut sy?tteen tarkastus (esimerkiksi rajapintakutsu, johon tulee v??r?nlainen sy?te). Internetiin auki olevista avoimista rajapinnoista voi tulla liikaa t?m?nkaltaisia lokitapahtumia, mutta suljettujen rajapintojen osalta vialliset kutsut tulisi todenn?k?isesti aina kirjata lokiin.L?hteet:RFC 3339: : Pyynt?tunnisteetPyynt?tunniste on erityisesti mikropalveluarkkitehtuureille hy?dyllinen tapa korreloida lokitietoja. Niiden avulla voidaan j?lkik?teen rakentaa kuva siit?, mit? sis??n tulleen pyynn?n seurauksena tapahtui.Sovelluksella saattaa olla k?yt?ss? hajautettu pyynt?jen seuranta (distributed tracing). T?llaista j?rjestely? voidaan k?ytt?? pyynt?jen seurantaan, mik?li se tuottaa riitt?v?n pysyv?n lokitiedon. Mik?li t?llaista j?rjestely? ei ole olemassa, pyynt?tunnisteet voidaan toteuttaa my?s seuraavasti.Pyynt?tunnisteen tulisi olla satunnainen tunniste, joka luodaan mahdollisimman aikaisessa vaiheessa sis??n tulevia pyynt?j? k?sitelless? (esimerkiksi kuormantasaimessa). Se lis?t??n HTTP-pyynt??n sopivassa otsakkeessa, kuten X-Request-Id. On huomattava, ett? ulkopuolelta sy?tetyt pyynt?tunnisteet tulee poistaa, koska ne ovat hy?kk??j?n manipuloitavissa.Jokainen palvelu (mikropalvelu), joka vastaanottaa X-Request-Id -arvon, kopioi vastaavan arvon kaikkiin muihin palveluihin l?hett?miins? pyynt?ihin. Lis?ksi palvelu tallentaa t?m?n arvon jokaiseen auditointilokitapahtumaan, jotka pyynt? aiheutti.Yhdistettyn? aikaleimoihin pyynt?tunniste antaa mahdollisuuden muodostaa t?ydellisen kuvan mikropalveluiden kutsuhierarkiasta ja korreloida kaikki pyynn?t siihen ulkoiseen IP-osoitteeseen, josta alkuper?inen pyynt? tuli. Docker, Kubernetes ja TerraformDockerin ja konttien orkestrointiin k?ytett?vien ohjelmistojen (mm. Kubernetes) kovennus on laaja kokonaisuus, jota varten esimerkiksi Center for Internet Security (CIS) on luonut omat ohjeensa. T?ss? ohjeessa keskityt??n l?hinn? arkkitehtuuri- ja ohjelmistosuunnittelutason aspekteihin. Docker- tai orkestrointity?kalun varsinaisen asennuksen kovennus tulee toki my?s varmistaa. Is?nt?koneDocker-kontteja ajavien is?nt?koneiden tulee olla vain t?ss? k?yt?ss?. Palvelimella ei saa ajaa muita palveluja.Yhdell? palvelimella tulee ajaa ainoastaan saman turvatason kontteja: esimerkiksi ulkoisille k?ytt?jille n?kyv?t Docker-kontissa ajettavat palvelut tulee ajaa eri palvelimella kuin miss? taustapalvelinkontteja ajetaan.Orkestrointij?rjestelm?t voivat antaa mahdollisuuksia konttien asetteluun virtuaalikoneille. Esimerkiksi Kubernetes tukee ominaisuutta nimelt? ’node restriction’.L?hteet:CIS Docker Benchmark: Docker-kontin asetuksetYksitt?isen Docker-kontin tulee pohjautua luotettavaan pohjakuvaan (base image), johon on kontin rakennusvaiheessa asennettu ohjelmistoja vain luotetuista l?hteist?. L?hteiden luotettavuus voi perustua kryptografisten allekirjoitusten tarkastamiseen tai siihen, ett? ne ovat organisaation hallussa.Docker-konttien pohjakuvaan tulee viitata SHA-256-tunnisteella, eik? esimerkiksi viitata uusimpaan versioon latest-m??reell?. T?t? viittaustapaa on k?ytett?v? my?s silloin, kun pohjakuva on sis?isesti luotu.Alla esimerkki hyv?ksytyst? tavasta viitata julkisesta l?hteest? saatavaan pohjaan:FROM alpine@sha256:3dcdb92d7432d56604d4545cbd324b14e647b313626d99b889d0626de158f73aKun kontteja rakennetaan Dockerfilell?, kaikkien asennettavien ohjelmien eheydest? on varmistuttava. Jos Dockerfile hakee ohjelmiston ei-luotetusta l?hteest?, saman Dockerfilen ei pit?isi hakea eheystarkistukseen tarvittavia avaimia niin ik??n ei-luotetusta l?hteest?.Riippuvuudet tulisi mieluiten asentaa paikallisesta varastosta. T?m? mahdollistaa sen, ett? organisaatio voi kontrolloida k?ytettyj? riippuvuuksien versioita, pit?? yll? muutoshallintaprosessia, ja rakentaa Docker-kontit vaikka kolmannen osapuolen varasto ei olisi saatavilla.Docker-kontit tulee aina ajaa read-only -tiedostoj?rjestelm?ll?, ellei ole eritt?in painavaa syyt? p??tt?? toisin.Docker-konttia ei tule koskaan ajaa --privileged-asetuksella tai antaa kontille p??sy? docker.sock-hallintaliittym??n. Lis?ksi Docker-kontille tulee antaa p??sy mahdollisimman pieneen osaan is?nt?koneen tiedostoj?rjestelm?? ja verkkoa. Kontista ei saisi p??st? kutsumaan esimerkiksi pilvipalveluntarjoajan virtuaalikoneille tarjoamaa metadata-rajapintaa.K?ytett?ess? orkestrointij?rjestelm??, joka tarjoaa nk. overlay-verkon, konttien verkkoliikenne tulisi rajata vain niihin kohteisiin, joiden kanssa niiden on pystytt?v? kommunikoimaan. Esimerkiksi Kubernetes tuntee t?m?n nimell? NetworkPolicy.Kun Dockeria tai orkestrointia k?ytt?v?lle j?rjestelm?lle tehd??n tietoturvatarkastus, Dockerfilen ja orkestrointij?rjestelm?n konfiguraation tarkastuksen on aina sis?llytt?v? tietoturvatarkastukseen.L?hteet:CIS Docker Benchmark: KubernetesKubernetes-klustereilla on monia turvattomasta konfiguraatiosta johtuvia ongelmamahdollisuuksia. Mik?li tuotetiimi p??tt?? k?ytt?? itse hallittua Kubernetes-klusteria, heid?n tulee huolehtia sen turvallisuudesta. Kuberneteksen kovennus on laaja aihealue ja erillisen kovennusohjeen yll?pito j?? helposti ajastaan j?lkeen. T?m?n vuoksi on suositeltavaa k?ytt?? CISin Kubernetes-kovennusohjetta.Ohjeen lis?ksi on olemassa ty?kaluja, joilla klusterin asetuksien turvallisuutta voidaan arvioida. T?llaisia ovat esimerkiksi kube-bench CIS-kovennusohjeen tarkastukseen ja kube-hunter klusterin avoimien resurssien l?yt?miseen. N?iden ty?kalujen k?ytt? itse hallitun klusterin yhteydess? on suositeltavaa, joskaan ne eiv?t t?ydellisesti korvaa CIS-kovennusohjeen l?pik?ynti? k?sin. Mainituista ty?kaluista kube-hunteria voi ajaa my?s klusterin sis?puolelta, jolloin saadaan k?sitys siit?, mit? hy?kk??j? n?kisi, jos se saisi Kubernetes-podin haltuunsa.On suositeltavaa k?ytt?? Kubernetesia valmiina palveluna (Platform-as-a-Service). Esimerkki t?llaisesta on AWS:n Elastic Kubernetes Service (EKS). On kuitenkin huomattava, ett? jaetun vastuun periaate t?ytyy ymm?rt?? hyvin. Esimerkiksi jotkin Kubernetes-alustat vaativat, ett? alustan k?ytt?j?n on huolehdittava klusteria py?ritt?vien koneiden p?ivityksest? itse. Vastuu ei ole v?ltt?m?tt? jakaantunut teknologiapinossa selke?? rajaa my?ten. Jos pilvipalvelulla on kovennusopas Kubernetest? varten, t?t? tulee noudattaa.Kubernetes-palvelun tulee joka tapauksessa olla CNCF-sertifioitu (CNCF Certified Kubernetes).Kubernetes perii useita Docker-turvallisuuden osa-alueita, jotka on lueteltu ylemp?n?. N?it? ovat esimerkiksi Kubernetes-podien ajaminen read-only-tiedostoj?rjestelm?st? ja konttien ulkopuolisten tiedostoj?rjestelmien k?yt?n v?ltt?minen.Kuberneteksess? ajettavissa sovelluksissa tulisi k?ytt?? arkkitehtuuria, joka pakottaa hy?kk??j?n useampikerroksisen puolustuksen l?pi. Esimerkki ajattelusta oheisessa kuvassa:Perusajatuksena on se, ett? Kubernetes-podit luokitellaan erillisiin luottamusluokkiin sen mukaan, kuinka paljon hy?kk?yspintaa ne avaavat mahdollisten hy?kk??jien suuntaan. Yll? olevassa kuvassa edustapodit oletettavasti j?sent?v?t ja prosessoivat ulkopuolisen hy?kk??j?n sovelluskerroksen tietovirrat, joten niiden avaama hy?kk?yspinta on taustapodeja isompi.Tietokannat ja taustapalvelut tarvitsevat todenn?k?isesti salaisuuksia p??synhallintaa varten, jolloin t?ss? esimerkiss? salaisuudet annetaan vain taustapodeille.Liikenne taustapodeille pakotetaan kulkemaan edustapodien kautta ja toisaalta liikenne tietokantoihin ja taustapalveluihin on sallittu vain taustapodien kautta. T?h?n voi k?ytt?? esimerkiksi NetworkPolicy? tai service meshi?. Toisin kuin virtuaalikoneilla, podien v?lill? ei ole hypervisor-erottelua. Jos taustapalveluilla on erityisi? turvatarpeita, voi t?m?n vuoksi olla my?s tarpeen harkita Kubernetesin inter-pod anti-affinity -asetusta, jonka perusteella Kubernetes laittaa m??ritellyt podit ajoon eri virtuaalikoneisiin. Hyvin korkeiden turvavaatimusten sovelluksia saattaa olla joskus tarpeen pilkkoa ajoon jopa eri pilvipalvelutileille, jolloin luonnollisesti niit? ajetaan kokonaan eri klusterissakin.Yll? luottamustasoja on kaksi, mutta sovelluksissa niit? voi loogisesti olla useampiakin.T?m?nkaltainen tavoitearkkitehtuuri hankaloittaa hy?kk??j?n toimintaa, koska edustapodilta on vaikeampi vaikuttaa vapaavalintaisiin verkossa oleviin kohteisiin. Toisaalta edustapodin t?ydellinenk??n hy?kk??j?n kontrolliin p??tyminen ei viel? aiheuta esimerkiksi tietokantojen p??syavaimien vuotamista, vaikka edustalta voidaankin tietysti t?ll?in tehd? pyynt?j? taustapodien l?pi. Verkkoliikenteen rajoittaminen vain sallittuihin kohteisiin est?? my?s sen, ettei hy?kk??j?n haltuunsa saamilta podeilta voida liikenn?id? esimerkiksi pilvipalvelun metadata- tai Kubernetes-klusterin hallinnollisiin rajapintoihin.Huomionarvoista on my?s se, ett? kuormantasauskerros tai sis??ntulokerros (ingress) ei v?ltt?m?tt? puutu sovellustason dataan lainkaan, jolloin niiden vaikutus edustan kovennuksessa on pienempi.Jos sovelluksen arkkitehtuuri on alun perin monoliittinen, sit? ei kannata suin p?in muuttaa yll? kuvatun kaltaiseksi vaan tietoturvan tavoitearkkitehtuuri tulisi pit?? mieless? silloin, kun sovelluksen arkkitehtuuria muutenkin muutetaan.L?hteet:kube-bench: : Certified Kubernetes: anti-affinity: : TerraformTerraformin suurimmat tietoturvariskit liittyv?t siihen, ett? jollakin osalla tuotantoonvientiautomaatiossa on oltava kyky muuttaa infrastruktuuria Terraform-konfiguraation mukaiseksi. N?m? oikeudet ovat varsin laajat. Infrastruktuuri koodina -ajattelua toteuttavalla tiimill? infrastruktuurin suojaus ei voi olla paremmalla tasolla kuin heid?n tuotantoon vientiprosessiensa suojaus.Terraform tallentaa infrastruktuurin vallitsevan tilan tilatiedostoon (state file). Terraform tukee tilan tallentamista jaettuun paikkaan, esimerkiksi AWS:n S3-?mp?riin. Tilatiedoston p??synhallinnasta t?ytyy varmistua, jotta sen luvaton muokkaus ei ole mahdollista. SalaisuuksienhallintaSalaisuuksia, kuten salasanoja, salaamattomia yksityisi? avaimia tai rajapintatunnuksia (API token), ei tule koskaan tallentaa selv?kielisen? esimerkiksi versionhallintaan tai Dockerfile-tiedostoon. Pitk?aikaiseen s?il??n salaisuudet kannattaa tallettaa salaisuuksienhallintaj?rjestelm?ll?. N?it? on erilaisia yksitt?isen kehitt?j?n salasanamanagerista pilviasenteisiin holveihin (’vault’). Salaisuuksista tulisi my?s olla varmuuskopio.Ihmisten k?sittelemien salaisuuksien hallintaan on k?ytett?v? luotettavaa salasanamanageria.Salaisuuksien toimittaminen ajettaville konteille on ymp?rist?kohtainen ongelmakentt?, eik? yleisp?tevi? ratkaisuja ole helppo antaa. Yleisesti voidaan sanoa, ett? salaisuuksien vienniss? tuotantoon tulisi mieluiten k?ytt?? holvityyppisi? (’vault’) palveluita tai orkestrointity?kalun tarjoamia mahdollisuuksia. Mik?li n?it? ei ole saatavilla, salaisuudet voidaan laittaa salattuun tiedostoon, joka tallennetaan sopivaan paikkaan, johon kontti p??see k?siksi. Tarvittava salauksenpurkuavain voidaan toimittaa kontille ymp?rist?muuttujassa. K?ytett?ess? ymp?rist?muuttujia salaisuuksien v?litt?miseen ne tulisi nollata niiden lukemisen j?lkeen, koska monissa virhetilanteissa debug-tuloste sis?lt?? ymp?rist?n sis?ll?n.Salaisuuksien hallintaan on olemassa kolmansien osapuolien sovelluksia, kuten HashiCorp Vault. Kubernetesissa ja OpenShiftiss? on ’secret’ -objekteja. Infrastruktuuripilvipalveluilla on kullakin oma avainten ja salaisuuksien hallintapalvelunsa, kuten AWS:n Secrets Manager. Orkestraattorin salaisuuksien hallinta on yleens? paras vaihtoehto. Jos k?ytet??n pilvipalveluntarjoajan salaisuuksienhallintaratkaisua, jatkuvuudenhallintasyist? sen vaihtaminen (ja salaisuuksien uudelleen luonti) on suunniteltava valmiiksi.L?hteet: Ohjelmointirajapinnat (API)Kaikki uudet web-ohjelmointirajapinnat tulisi toteuttaa k?ytt?en JSON-formaattia. T?t? puoltavat yksinkertainen esitystapa ja laaja ohjelmistotuki. Yleisesti k?ytetyiss? JSONP- ja XML-formaateissa on molemmissa ongelmansa.JSONP-muotoisia rajapintoja ei tulisi k?ytt??, koska t?ll?in suoritetaan rajapinnan tarjoamaa dataa suoraan ohjelmakoodina. T?ll?in erotus rajapinnan ja rajapintaa k?ytt?v?n palvelun v?lill? puuttuu t?ysin. Rajapinnan tulisi tarjota ainoastaan dataa, jota palvelu k?sittelee.XML-j?sentimien (parser) on useasti osoitettu toimivan virheellisesti mahdollistaen datan tulkitsemisen usealla eri tavalla. T?m? muodostuu ongelmaksi, jos dataa tulkitaan useassa eri vaiheessa k?ytt?en eri j?sentimi?, jolloin dataa saatetaan tulkita useammalla eri tavalla. XML mahdollistaa my?s tietosis?ll?n esitt?misen usealla eri esitystavalla, jonka j?sennin kuitenkin tulkitsee samalla tavalla. API-turvallisuus yleisestiOhjelmistorajapintojen tulisi varmistua jokaisesta sis??n tulevasta kutsusta alla mainituista asioista. Arkkitehtuurista riippuen API-toteutus saattaa luottaa v?liss? olevaan API-v?lityspalvelimeen tai tehd? n?m? tarkistukset itse.Mik?li jokin tarkistus ei mene l?pi, kutsu kannattaa suoraan hyl?t? ilman, ett? rajapinnan toteuttava osapuoli l?htisi arvailemaan, mit? kutsuja on tarkoittanut. Mik?li todennus-, valtuutus- tai eheystarkistukset ep?onnistuvat, kutsun sis?lt?? ei pit?isi l?hte? lainkaan j?sent?m??n pidemm?lle vaan prosessointi tulisi p??tt?? mahdollisimman tehokkaasti.Istuntotunniste: onko istunto voimassa? Mik? on istunnon valtuutuksen taso? (Ks. t?m?n ohjeen istuntotunnisteisiin liittyv? erityisohje.)Pyynn?n valtuutus. Varmistutaan siit?, ett? kutsujalla on oikeus tehd? kysely t?h?n rajapintaan (esim. API-avain tai istunnon perusteella tehty valtuutus).Jos k?ytet??n pyynt?tunnisteita (Request ID, ks. yll?), onko kutsussa mukana pyynt?tunniste? Jos on, ja teemme itse kutsuja eteenp?in muihin taustapalveluihin, liit?mme pyynt?tunnisteen n?ihin kutsuihin. Jos ei ole, generoimme pyynt?tunnisteen itse (tai jos sen puuttuminen on ep?ilytt?v??, j?t?mme pyynn?n k?sittelem?tt?).Kutsun ja tietojen eheys. Varmistutaan siit?, ett? kutsu on ehe?. Jos k?ytet??n API-avainta tai muuta kutsujan ja rajapinnan v?list? salaisuutta, eheystarkistus voidaan sitoa siihen. Tyypillisi? toteutuksia ovat valtuutusten siirtoon JSON Web Tokens (JWT) ja kokonaisten rajapintakutsujen eheystarkistuksiin AWS Signature v4.Onko sis??n tuleva kutsu oikein muotoiltu? My?s JSON-pohjaisten rajapintojen tapauksessa kutsu tulisi tarkistaa skeemaa vasten, jotta rajapintaan ei esimerkiksi pysty sy?tt?m??n ylim??r?isi? tietokentti?. Ellei skeematarkistusta tehd?, n?m? ylim??r?iset kent?t p??tyv?t erityisesti NoSQL-tapauksissa usein tietokantaan asti ja joka tapauksessa ne indikoivat mahdollista hy?kk?ysyrityst?. Muotoilun tarkastuksessa Domain Driven Design (DDD) saattaa olla hy?dyllinen l?hestymistapa, ks. Secure by Design alla.Valtuutus saada vastauksen tiedot. Joissakin tapauksissa rajapinnan kutsumisen valtuutus ja tietojen saanti rajapinnasta ovat erillisi? valtuutusp??t?ksi?.Onko kutsu tarpeen lokittaa? (Ks. t?m?n ohjeen kappale auditointilokituksesta.)Asetetaanko vastauksessa kaikki tarpeelliset HTTP-otsakkeet, kuten HSTS ja Content-Type? (Ks. t?m?n ohjeen kappale HTTP-otsakkeista.)Mik?li valtuutuksien siirtoon k?ytet??n JWT:t?, sen k?ytt?mien kryptografisten algoritmien ja avainpituuksien valintaan sovelletaan aiempaa TLS 1.2:n ohjetta soveltuvin osin.L?hteet:JSON Web Tokens -teemasivusto Signature v4, joka ei ole AWS-spesifinen by Design: Cross-Origin Resource Sharing (CORS)CORS on tapa, jolla palvelin ilmoittaa selaimelle, ett? se saa ohittaa normaalin nk. same-origin -rajoituksen ja kutsua toisessa domainissa sijaitsevaa APIa. Selaimet tekev?t CORS-tarkistusta varten erillisen nk. preflight-kutsun, jonka perusteella saadaan tieto CORS-otsakkeista. On t?rke?? huomata, ett? hy?kk??j? voi tietenkin aina kutsua rajapintaa ilman selainta riippumatta CORSista. Palvelinp??n p??synhallinta tulee aina toteuttaa k?ytt?en oikeita p??synhallintamekanismeja.Kohdepalvelin ilmoittaa CORS-politiikkansa k?ytt?en Access-Control-Allow-Origin -otsaketta. Access-Control-Allow-Origin m??rittelee ne JavaScript-koodin l?hteet, jotka saavat kyseist? rajapintaa kutsua.Jos esimerkiksi organisaatiolla on web-sovellus osoitteessa ja API osoitteessa api.cloud.example, ja he haluavat ilta toimitetun JavaScriptin pysty? kutsumaan api.cloud.examplea, api.cloud.examplen rajapinnan on palautettava jotakin t?m?nkaltaista HTTP-otsakkeissaan:Access-Control-Allow-Origin: Access-Control-Allow-Methods: GET POST PUT DELETEMik?li rajapinta tarvitsee valtuutuksen (esimerkiksi ev?steiss?), sen tulee my?s antaa selaimelle erityislupa n?iden toimitukseen:Access-Control-Allow-Credentials: trueJos APIa pit?? pysty? kutsumaan mist? tahansa JavaScript-koodista riippumatta sen alkuper?st?, otsakkeen tulee ollaAccess-Control-Allow-Origin: *Mik?li t?m? otsake on n?kyviss? rajapinnan otsakkeissa, mutta rajapinta ei ole tarkoitettu yleisesti kutsuttavaksi, CORS-politiikka on todenn?k?isesti liian lepsu.L?hteet: CSRF-tunnisteCross-Site Request Forgery (CSRF) -hy?kk?yksess? hy?kk??v? sivusto aiheuttaa selaimen kautta pyynn?n jotakin toista sivustoa kohden. Jos selaimella on aktiivinen istunto kohdesivustolla, hy?kk??j? voi tehd? k?ytt?j?n? erilaisia operaatioita.CSRF estet??n antamalla jokaisen HTTP-pyynn?n mukana kryptografisesti vahva ja riitt?v?n pitk? salaisuus. N?m? salaisuudet (nk. CSRF-tokenit) tallennetaan selaimessa niin, ett? hy?kk??j?n sivusto tai silt? per?isin oleva JavaScript ei p??se niihin k?siksi, eik? siten pysty tekem??n tekaistuja pyynt?j?.CSRF on helpointa est?? k?ytt?m?ll? sovelluskehikkoa, joka toteuttaa CSRF-suojauksen automaattisesti. Useimmiten t?m? on paras vaihtoehto.Mik?li t?llaista kehikkotukea ei ole, suositeltava tapa on k?ytt?? nk. ”double submit cookie” -tapaa. T?m? metodi on k?tev?, koska se on tilaton eik? vaadi palvelinp??n tallennustilaa, joten se sopii my?s tilanteisiin, jossa pyynn?t selaimelta tulevat satunnaisesti eri palvelimille kuormantasaajan l?pi. Kuten monissa muissakin tietoturvaominaisuuksissa, t?m?n naiivi toteutus saattaa olla haavoittuva.Sources:(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookie Parametrit ja luottamuksellinen tietoHTTP-rajapintakyselyt tulee muotoilla niin, ettei henkil?tietoja tai muita luottamuksellisia tietoja v?litet? URL-osoitteen osana. URL-osoitteen osana olevat tiedot (ns. GET-parametrit) saattavat j??d? talteen lokeihin, selaimen v?limuistiin ja selaushistoriaan tai v?lityspalvelimen tietoihin tai vuotaa Referrer-otsakkeissa.Kaikki henkil?tiedot tulee t?ten v?litt?? HTTP POST -pyynn?n parametreina.Oikea tapa voisi n?ytt?? esimerkiksi t?lt?:POST /hae/osoite HTTP/1.1hetu=010170-123FV??r? tapa voisi n?ytt?? esimerkiksi t?lt?:GET /hae/010170-123F/osoite HTTP/1.1L?hteet: (erityisesti Mobile App Security Checklist) (ASVS 4.0) Appendix (Appendix 7, instructions) TLS settings of servers Recommendations on TLS in generalWhen using cloud service providers' fronting services such as CDNs (content delivery networks) or load balancers, it may not be possible to fully control the TLS configuration. In these cases, a configuration that most closely matches these requirements must be selected. Depending on the application architecture, it may also be possible to use a TCP/UDP layer load balancer (for example, a Network Load Balancer on AWS) and terminate TLS in the application's own front-end server (for example, an Ingress resource in a Kubernetes cluster). This approach would obviously shift an additional part of the maintenance responsibility to the development team, which may be undesirable for other reasons.The risks posed by a non-compliant TLS configuration and allowing TLS termination close to workloads are different. Non-compliant TLS configuration risks are likely to mainly involve active man-in-the-middle attackers and enablement of wholesale surveillance. Terminating TLS (for example) within a Kubernetes cluster introduces complexity and additional attack surface, which may increase a risk of a server compromise. If the intent is to manage a TLS termination point, a future-proof architecture should consider the imminent adoption of HTTP/3 and TLS 1.3, which is likely to harmonise TLS compliance requirements and introduce new protocol implementations (QUIC) and require the support of UDP for ingress traffic.TLS-related risks are usually smaller as far as a CDN is concerned, as static content is not that often confidential. Integrity of CDN-supplied content would likely be a more pertinent question. For executable JavaScript content, integrity can be further assured through subresource integrity (see later in this document). Protocol versionServices must support TLS version 1.2, and support TLS 1.3 as soon as it is possible. Modern browsers increasingly support TLS 1.3.TLS version 1.1 may only be used in situations where the other endpoint does not support TLS version 1.2. However, an endpoint that would support 1.1 but not 1.2 are very rare. Older TLS or SSL versions (TLS 1.0, SSL) must not be supported.Removing TLS 1.0 support will cause compatibility problems mostly with older mobile browsers, such as Android 4.4 WebView that only supports TLS 1.0, and Java 7 and older.Sources:Compatibility tables –TLS 1.3 support 1.2 support (Traficom) regulation 72A/2018 on Electronic Identification and Trust Services requiring the use of TLS 1.2 : CertificatesFor services that do not have a national security level classification, certificates must use RSA keys, in which case the minimum key length is 2048 bits, or ECDSA keys, in which case the minimum key length is 224 bits. Certificates must use SHA-256 as their hashing algorithm. These key lengths and algorithm choices need to be revised regularly to keep current with cryptanalytic progress. Systems designed for a long lifespan should allow for changes in used algorithms and key lengths.For services which have a national security level classification, key lengths should follow the cryptographic strength requirements from the National Cyber Security Centre (see Sources).When certificates expire, new keys should be generated, and certificates should be created for those new keys. Certificates must not be wildcard certificates that would be accepted for all subdomains.As new certificates are being issued, issuance is noted in Certificate Transparency logs. This allows external parties to follow which certificates have been issued to an organization. Additionally, if certificates are issued for internal service domains, this information may leak.Certificate validity can be checked by the browser by using OCSP (Online Certificate Status Protocol). However, using OCSP causes the browser to send OCSP requests to the certificate issuer and this may leak information about the browsing activity to the certificate issuer. Therefore, TLS endpoints should enable OCSP Stapling, where the server retrieves OCSP responses and proactively provides them to browsers in the TLS handshake. This also speeds up the connection.Sources:National Cyber Security Centre guideline 190/651/2015 (as current): Cryptographic strength requirements for confidentiality protection – national security levels (in Finnish) certificate settings, including OCSP Stapling: Certificate issuersCertificate issuers must have valid trust roots in all of the endpoints that connect to the service, such as most common browsers, operating systems and mobile devices. Users must be educated to understand security implications of certificate error messages, for example, not to accept warning messages on untrusted certificates. Encryption algorithmsThe required TLS 1.3 algorithms are defined in the TLS 1.3 specification and implementations need to be compliant with these, unless a competent authority defines otherwise for a specific application.When using TLS 1.2, the guidance below should be followed.Key agreement (TLS 1.2)For services that do not have a national security level classification, key agreement must use either ECDHE or DHE algorithms. When using ECDHE, the minimum key length is 256 bits, and for DHE, 2048 bits. When using elliptic curve cryptography (ECC), all acceptable curves must be explicitly specified in the protocol configuration. These key lengths and algorithm choices need to be revised regularly to keep current with cryptanalytic progress. Systems designed for a long lifespan should allow for changes in used algorithms and key lengths.For services which have a national security level classification, key lengths should follow the cryptographic strength guideline from the National Cyber Security Centre (see Sources).Recommended elliptic curves are BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, NIST Curve P-224, NIST Curve P-256, NIST Curve P-384 and NIST Curve P-521.Signatures (TLS 1.2)For services that do not have a national security level classification, signatures must use either ECDSA or RSA algorithms. The minimum key length for ECDSA is 256 bits, and for RSA, 2048 bits. These key lengths and algorithm choices need to be revised regularly to keep current with cryptanalytic progress. Systems designed for a long lifespan should allow for changes in used algorithms and key lengths.For services which have a national security level classification, key lengths should follow the cryptographic strength guideline from the National Cyber Security Centre (see Sources).Symmetric encryption (TLS 1.2)The encryption algorithm used must be AES in CBC or GCM mode, either with a 128 or 256 bit key. These key lengths and algorithm choices need to be revised regularly to keep current with cryptanalytic progress. Systems designed for a long lifespan should allow for changes in used algorithms and key lengths.For services which have a national security level classification, key lengths should follow the cryptographic strength guideline from the National Cyber Security Centre (see Sources).Hash functions (TLS 1.2)Hash functions must be either SHA-256, SHA-384, SHA-512 or SHA-3. These algorithm choices need to be revised regularly to keep current with cryptanalytic progress. Systems designed for a long lifespan should allow for changes in used algorithms and key lengths.For services which have a national security level classification, hash function choice should follow the cryptographic strength guideline from the National Cyber Security Centre (see Sources).TLS cipher suites (TLS 1.2)For services that do not have a specified national security level, the following TLS 1.2 cipher suites fulfil the requirements above.DHE-RSA-AES256-GCM-SHA384ECDHE-ECDSA-AES256-GCM-SHA384ECDHE-RSA-AES256-GCM-SHA384DHE-RSA-AES128-GCM-SHA256ECDHE-ECDSA-AES128-GCM-SHA256ECDHE-RSA-AES128-GCM-SHA256DHE-RSA-AES256-SHA256ECDHE-ECDSA-AES256-SHA384ECDHE-RSA-AES256-SHA384DHE-RSA-AES128-SHA256ECDHE-ECDSA-AES128-SHA256ECDHE-RSA-AES128-SHA256Sources:National Cyber Security Centre guideline 190/651/2015 (as current): Cryptographic strength requirements for confidentiality protection – national security levels (in Finnish) 1.3, RFC 8446 - Cryptographic requirements for the Interoperability FrameworkFicora (Traficom) regulation 72A/2018 on Electronic Identification and Trust Services requiring the use of TLS 1.2 settings generator: TLS settings: Other cryptographic implementationsUsing self-made cryptographic implementations is to be avoided. The recommendation is to only use well-known and actively maintained libraries which offer high-level access to cryptographic operations. The use of low-level cryptographic primitives should be avoided.In algorithm and key level choices, the principles laid out for TLS 1.2 (above) should be applied. Creating random identifiers in various programming languagesJavaimport java.util.SecureRandom;SecureRandom random = new SecureRandom();byte bytes[] = new byte[32];random.nextBytes(bytes);Python 3.6 and newerimport secretssecrets.token_urlsafe()Python before version 3.6import randomgenerator = random.SystemRandom()generator.getrandbits(256)JavaScriptvar array = new Uint32Array(8);window.crypto.getRandomValues(array).join(""); HTTPHTTP based services must not depend on browser extensions (plugins), such as Java applets or Adobe Flash. CookiesCookies should be scoped as strictly as possible only for the services that rely on them. This can be done for all browsers using the Path parameter and Secure and HttpOnly attributes.When naming cookies, the cookie name should additionally start with __Secure- if it is set from a HTTPS source. If the cookie can be scoped to a specific host (subdomains do not require the cookie), it should start with __Host- which also implies __Secure-.All cookies should be purged from the users’ browsers when the browser is closed, unless there is an explicit conflicting requirement that has been analysed for its security impact. This can be done by leaving out the Expires parameter of the cookie. HTTP headers towards browsersThese headers must be set for any content provided to web browsers.In general, it is also recommended to set these headers for APIs that are not supposed to be called by browsers, especially if those APIs are visible to the Internet. For further API security considerations, please refer to this guideline’s API security section.Content Security PolicyThere are two levels (1 and 2) of the Content Security Policy header. All modern browsers support CSP Level 2. Notably, Internet Explorer 11 does not support the standard CSP header.A CSP header can be used to restrict the sources from where the browser may load images, scripts or style information.It is recommended to set a CSP level 2 header that is as strict as possible, using a whitelisting approach. If support for Internet Explorer 11 is required, also the legacy headers (below) should be set.Examples of CSP headers:The following header only allows content from the same source, and also restricts framing:Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'; frame-src 'self'; worker-src ‘self’; frame-ancestors 'none'The following header is the same as above, but also reports problems towards a reporting endpoint that may be useful for detecting configuration problems:Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'; frame-src 'self'; worker-src ‘self’; frame-ancestors 'none'; report-uri/some-report-uriThe following header only reports non-compliant requests but does not actually restrict them. This is only meaningful for testing, and not for production.Content-Security-Policy-Report-Only: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'; frame-src 'self'; worker-src ‘self’; frame-ancestors 'none'; report-uri/some-report-uriSources:Browser compatibility tables for CSP header commercial tool for following up on non-compliance reports Strict Transport SecurityThe HTTP Strict Transport Security (HSTS) header forces the browser to use HTTPS for all subsequent requests towards the server. The HSTS header should be set for every response over HTTPS, and because everything should be served over TLS, this means HSTS should be set for every request.The header has an expiration time, specified in seconds, after which unencrypted connections become possible again. A suitable starting point for a HSTS expiration is 6 months (15?552?000 seconds). For services that are visited less often (e.g., once a year), a longer expiration time may be useful. The header may also be specified to include all subdomains using the includeSubDomains parameter.Using a HSTS header may cause a self-inflicted Denial of Service condition in the case that the service’s certificate expires, or a load balancer or a content delivery network is using the same address without a proper certificate.For additional assurance of browsers using HTTPS by default, your site may be submitted to the browser vendors’ ‘preload’ list (see Sources). This requires the header to include the preload directive.An example:Strict-Transport-Security: max-age=15552000Sources: services on the preload list: headersThe following headers have been deprecated and mostly replaced with new browser features and the Content Security Policy header. However, for some browsers (given the TLS 1.2 requirement that also weeds out old browsers, most notably Internet Explorer 11), these would still be useful for some time. At the time of writing, the need for these headers should cease latest in 2025 with the phase-out of Windows 10 support, unless TLS requirements block IE 11 earlier. X-Content-Type-OptionsForbids browsers from guessing the content type. Generally, all responses from the server should always define the content type using the Content-Type header, including the character set, if applicable.An example:X-Content-Type-Options: nosniffSources: X-XSS-ProtectionInstructs the browser to use its internal heuristics against Cross-Site Scripting (XSS) attacks. This is an old header, included only for Internet Explorer 11 that does not support Content Security Policy. A modern option is a Content Security Policy that disallows unsafe-inline.An example:X-XSS-Protection: 1; mode=blockSources: X-Frame-OptionsThe X-Frame-Options header prohibits browsers from embedding the page within another page using frames. This protects against a clickjacking attack, where the user would be clicking on a link that is behind an invisible link that actually gets activated.For modern browsers, Content Security Policy level 2 frame-ancestors directive can be used for the same effect. The Content Security Policy frame-src directive controls the loading of frames within the current page, which is not covered by X-Frame-Options.Examples:X-Frame-Options: DENYX-Frame-Options: SAMEORIGINX-Frame-Options: ALLOW-FROM and ExpiresThe Cache-Control header controls the functionality of the browser cache and caching proxies. The header can be used to specify an expiration time for content, restrict caching on intervening proxies, and provide information for cache refreshes.From the security perspective, it may be useful to restrict caching of confidential data. The following example prohibits storing any information about the HTTP request or response and forces a new request to be made. These headers should likely not be set for static resources due to performance reasons.An example:Cache-Control: no-cache, no-store, must-revalidateThe Expires header specifies a time after which content will be marked stale in a cache. These examples prohibit caching by immediate expiry of content. This type of expiry should be used in conjunction with a Cache-Control header.Examples:Expires: Thu, 01 Jan 1970 00:00:00 GMTExpires: 0Sources: key pinningPublic key pinning means only accepting a specific public key (or certificate) for a server. This security feature was intended to reduce the risk of certificates being issued for attacker’s keys and then used in a spoofing attack.However, support for the public key pinning headers is being phased out in browsers, as it failed to gather momentum and because it introduces a high risk for self-inflicted denial of service. It is still supported in some browsers, but notably was deprecated by Chrome, and never supported by Safari.Public key pinning should still be used in mobile application development, where it is easier to specify the acceptable trust roots, and those can be updated in an emergency through an application update through the app store.Public key pinning in browsers is implemented using a HPKP header, Public-Key-Pins.Instead of HPKP, the organization should actively monitor Certificate Transparency logs and react if they notice unauthorized certificates being issued for their domains.Sources: and noopenerAs a part of hardening the HTTP headers it is useful to ensure that links that open external, potentially untrusted pages into new tabs have set the attribute rel=noopener. The noopener attribute prevents the newly opened tab from redirecting the original tab, for example on a phishing page. If Internet Explorer 11 needs to be supported, an additional rel=noreferrer attribute will have the same (side) effect.External links will also cause a Referrer header to be sent with the requests. These headers may leak information about what the person was doing before following a link on a page. In incorrectly implemented applications, Referrer headers have also been known to leak various identifiers. For these reasons, it is recommended to set a Referrer-Policy header, for exampleReferrer-Policy: same-originThis example will only provide Referrer information if the link points towards the original website. This allows using the Referrer header locally for statistical purposes. On web sites where even the fact that a person is visiting the site may be sensitive, a no-referrer value can be useful.Sources:noopener: : Subresource IntegritySubresource integrity is a method to ensure the integrity of resources (for example, JavaScript libraries) that are loaded from a potentially untrusted source, such as a content delivery network. Subresource integrity can also be used to deter supply chain attacks in some cases; unauthorized changes to JavaScript dependencies would be rejected by subresource integrity unless the integrity checksums would also be changed.Subresource integrity should be used for any JavaScript that is loaded from a location that is under a third-party control.When using subresource integrity, the resources need to be fetched from a source which points to a known and immutable version of the resource. It is not possible to point to a changing ‘latest’ version of a resource when using subresource integrity.As an example, embedding the version of jQuery 3.3.1 while ensuring its integrity using subresource integrity would look like this:<script src=""integrity="sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU="crossorigin="anonymous"></script>The following command can be used to create a base64 encoded SHA-256 hash (assuming the source is trusted at the moment of running the command):curl -s | openssl dgst -sha256 -binary | openssl base64 -ASources: Session identifiersThe HTTP protocol is stateless. The browser must therefore be uniquely identified using an application layer parameter, namely a session identifier. Secure ways of implementing session identifiers include cookies, POST-type form submission parameters, and custom HTTP headers added with JavaScript.If a third-party, trustworthy application framework is available providing session identifiers, that must be used.Session identifiers must be unique and cryptographically random. A recommended length for a random identifier is at least 256 bits.In many contexts, UUIDs are available. In this case, the only acceptable version of UUIDs is UUIDv4, which are random. Even in this case, it needs to be ensured that the UUIDv4 is generated using a cryptographically strong random number generator. Usually this would be explicitly stated in the UUID function documentation.Session identifiers must be recreated every time there is a change in the authentication status or authorization level of the session (for example, an anonymous user logging in, or a user elevating themselves to an admin user, or a user logging out). The previous session identifier must expire when such a change occurs.When JWT (JSON Web Tokens) are used for session management, its cryptographic requirements follow the TLS 1.2 requirements as applicable (see above).Sources:UUIDv4: LoggingApplications should produce audit log records that allow forensic analysis. Log data should be sent in real time to a central log aggregation and analysis system, which would usually be provided by the organization as a common service.In order for log data to be useful for forensics, it is important that log items contain accurate timestamps in UTC. All servers must be synchronized to a common time standard, typically using NTP. Timestamps should be stored using a unified syntax. RFC 3339 syntax is recommended.Additionally, especially in a microservice architecture, log items should have a ‘request ID’ that can be used to correlate log items of different microservices together. For details of this pattern, see below.Services should log all incoming API requests. They should always log the IP address from where a request originated, even when the service would only be visible to an internal network. If the service is behind a load balancer or a proxy, the proxy must be configured to pass the external IP address towards the service using the proxy protocol or in an X-Forwarded-For header.Logs should usually consist of JSON objects. This allows the addition of new and custom data elements, and easy parsing of log items in any modern log analysis software.Especially in a deployment that scales elastically under load, the service should put their unique instance identifier into the log items. The instance identifier should include the name of the running software component augmented with an identifier of the process, virtual machine instance, or a Kubernetes pod.The developer must be able to add free-form contextual information in the log events. This information is intended to provide information on what the application tried to perform at the time. If an application receives a human-readable error message from another service, that message should be included.The actions that should be audit logged include:Reading, changing or deleting personal data. This log event should contain an application-internal identifier of the person whose personal data was targeted, but usually not the personal data itselfConsent for using personal data, withdrawal of consent, approval of terms of service, changing communication preferencesChanges in session authentication or authorization state (log in, change of user privilege level, log out)Failure to verify session identifiersFailure to authenticate or authorize an actionThe following may generate too much log data, but they may be useful for auditing purposes:A failed request towards a back-end server (or another microservice), as this may be an indication of invalid input provided. Returned error messages should be written into log events as freeform information.Failure to validate input (e.g., an API receives a malformed request). Open, Internet-facing APIs may generate too many events of this type. Closed APIs should always log these failures.Sources:RFC 3339: proxy protocol: The request identifier patternFor microservice architectures, a request identifier pattern may help correlating various log items together to reconstruct what happened as a result of an incoming request.The application may be using a distributed request tracing solution. If so, this can be used for tracking request identifiers if it provides a sufficiently permanent log. Unless distributed tracing is in use, this functionality can be built as follows.The request identifier should be a random identifier that is created at first opportunity when there is an incoming request (e.g., in a load balancer). It would be added to the HTTP request headers in a suitable custom header such as X-Request-Id. Note that externally supplied request identifier headers would need to be removed as these are under attacker control.Every service (microservice) that receives an X-Request-Id would copy that value into all outgoing requests towards other services. The service would also store this identifier with all the audit log events that are generated as a result of this request.Paired with timestamps, a request identifier allows forensic reconstruction of the complete microservice call tree, and its correlation with the external IP address from where the original request originated. Docker, Kubernetes and TerraformHardening Docker and orchestration tools (such as Kubernetes) is a more complicated topic. The Center for Internet Security (CIS) has published its own guidelines for hardening these systems. This guideline concentrates on architectural and design level aspects. The hardening of Docker and orchestration tool installation would also have to be done. Docker hostsServers who are running Docker containers (hosts) must be dedicated to hosting containers. These hosts must not be used for other purposes.One server may only run containers that have an identical trust level. As an example, Docker containers supplying externally exposed services should be run on a different host than those running back-end services.When using an orchestration system, the placement of containers on different VMs can sometimes be controlled. For example, Kubernetes has the possibility of node restrictions.Sources:CIS Docker Benchmark: Docker containersAny single Docker container must be built on a trusted base image, and any software built in have to originate from a trusted source. This trustworthiness can be based on verification of cryptographic signatures or the fact that the source is under the organization’s control.The base images must be pinned to a specific version using a SHA-256 hash value, even if the base image would be internal. This means that using a latest base image is not possible.An example of how a base image can be pinned to a specific version:FROM alpine@sha256:3dcdb92d7432d56604d4545cbd324b14e647b313626d99b889d0626de158f73aBuilding containers with Dockerfiles must ensure that any installed software is integrity checked. If the Dockerfile downloads software from an untrusted source, the same Dockerfile should not also obtain the integrity verification keys from a similarly untrusted source.Dependencies should preferably be installed from a local repository. This allows the organization to control which version of the dependency is being used, to exert change control, and to build the Docker image even if the third-party repository would be unavailable.Docker containers should always be run with read-only root filesystems unless there is a serious technical rationale of not to.Docker containers must never be run using the --privileged option or provide access to the docker.sock management interface. Docker containers should be provided with as little host file system and network access as possible. For example, applications within container should not be able to call the cloud service providers' metadata endpoints provided to cloud virtual machines.When using an orchestration system that provides an overlay network, the containers’ network traffic should be restricted to only those destinations that are necessary for the container to work. For example, in Kubernetes, this is known as NetworkPolicy.When performing a security assessment for a system that uses Docker or an orchestration system, a review of Dockerfile and the orchestration system’s configuration files must always be included in the scope of the security assessment.Sources:CIS Docker Benchmark: KubernetesKubernetes clusters have multiple failure modes that stem from insecure cluster configuration. If the development team decides to use a self-managed Kubernetes cluster, they would need to address these potential weaknesses. Hardening Kubernetes is a large topic and maintaining a hardening guide separately would easily fall behind the times. The CIS Benchmark for Kubernetes is a good source for this.In addition, there exist tools which may help in determining whether the cluster has been securely configured. These include kube-bench for checking compliance against the CIS benchmark, and kube-hunter for discovering available resources in the cluster. The use of these tools for self-managed clusters is recommended, however, they are not a full replacement for manual review based on the CIS Benchmark. Of these, kube-hunter can also be run from within the cluster to give a view of what an attacker would see, having compromised a Kubernetes pod.The recommended way to approach Kubernetes clusters is to use a Platform-as-a-Service type Kubernetes deployment. An example of these is AWS Elastic Kubernetes Service (EKS). However, the shared responsibility model on the selected Kubernetes PaaS would have to be understood. For example, some Kubernetes platforms require the users of the platform to upgrade the underlying nodes when necessary. The responsibility split is not necessarily a clean line on the technology stack. If the selected cloud service has a Kubernetes hardening guide, that should be followed.Regardless of which Kubernetes solution is used, the Kubernetes deployment (or its deployment tools) must be CNCF Certified Kubernetes.Kubernetes security inherits many of the Docker security aspects, see above. Things such as running Kubernetes pods from read-only filesystems and not mounting host directories apply. An architectural pattern that should be applied to Kubernetes deployments is forcing a potential attacker to meet a multi-tier defensive architecture. An example of this is pictured below.The underlying idea is to divide Kubernetes pods into separate trust domains depending on their exposed attack surface. In the picture above, the front-end pods are likely to parse and process application layer data flows from the attacker, so they have more exposed attack surface.Databases and backend services are likely to require credentials. In this model, these credentials would only be available to the backend work traffic towards the backend pods would be forced to traverse the front-end pods, and similarly traffic to databases or private backends would only be accepted from the back-end pods. This can be performed using a NetworkPolicy or a service mesh.Unlike virtual machines, there is no hypervisor-governed separation between pods. If the back-end services have specific security needs, it may be useful to consider Kubernetes inter-pod anti-affinity settings. Based on these settings, Kubernetes may be instructed to schedule pods in different trust domains on different virtual machine nodes. Applications with high security requirements might be having to be split into different cloud provider accounts, which naturally splits them into different clusters.In the example above, there are two trust domains, but applications might have several logical trust domains.This type of target architecture is intended to frustrate an attacker, as it is more difficult to pivot towards other networked resources from the front-end pod. On the other hand, even a complete compromise of the front-end pod would not leak credentials to the back-end servers - although, obviously, making requests towards them through back-end pods would become possible. Restricting the network traffic also prevents the attacker from calling cloud service providers' metadata or Kubernetes cluster's control plane endpoints.It should be noted that a load balancing or ingress layer does not necessarily process application layer data, so they may not have that much of an effect hardening the front pods.If the application's original architecture is a monolith, it should not necessarily immediately be refactored into this type of target architecture. Instead, these security targets should be kept in mind when there are other changes done to the application's architecture.Sources:kube-bench: : Certified Kubernetes: 'Pod anti-affinity: : TerraformThe largest security risks of Terraform are related to the highly privileged parts of a deployment pipeline that need to be able to perform the infrastructure changes. When a development team manages their infrastructure as code, the infrastructure cannot be more secure than their deployment process. Terraform saves its state in a state file. Terraform supports a shared state file, for example, using AWS S3 buckets. The access controls of the state files must be verified to protect the integrity of the state files. Secrets managementSecrets, such as passwords, unencrypted private keys or API keys must never be stored in plaintext in version control systems or Dockerfiles. Long-term secrets storage should be done using secrets management software. These range from password managers for individual developers to various ‘vault’ services that can be deployed as cloud services. Secrets should be also backed up.Secrets handled manually by humans should be managed using a trustworthy password manager.Delivering secrets to running containers is a development and delivery pipeline specific problem, and it is not easy to give a solution that would work in all cases. Secrets provisioning should preferably be done using a ‘vault’ type service, or a system provided by the orchestration tools. If these are not available, secrets can be provided through encrypted files made available on a storage location, and the decryption key can be provided to the container in an environmental variable. If using environmental variables, these should be zeroed after the value has been obtained, as in many failure modes, debugging output dumps the environment contents.Third-party software exists for secrets management, such as HashiCorp Vault. Kubernetes and OpenShift have ‘secret’ objects. Infrastructure clouds have their own key and secrets storage systems, such as the AWS Secrets Manager. Using an orchestrator-provided secrets provisioning scheme is usually the best choice. When using a secrets management system provided by the cloud vendor, continuity planning must prepare for eventual change and secrets re-provisioning.Sources: Programming Interfaces (APIs)All new web interfaces should be implemented as JSON. The JSON presentation is simple and readable, and support from software is good. The other common implementations, JSONP and XML, have distinct challenges:?JSONP should not be used as the API responses are executed as program code. This removes the abstraction between an interface and the application using the interface. Interfaces should only provide data which is processed by the calling application.XML parsers have often had errors that have led to data being interpreted incorrectly. This may be a problem if different XML parsers interpret their input differently. XML also allows information to have multiple different structures that in the end are parsed in a similar way. API security in generalFor each incoming request, the API should perform multiple checks, described below. Depending on the architecture, the API implementation may trust an intervening API gateway or proxy or perform these checks itself.Should one of these checks fail, the request should be immediately rejected. The API should not try to handle malformed requests. If there is a problem with authentication, authorization, or integrity of data, the content of the request should not be parsed. Instead, processing should end with minimal overhead.Session identifiers: Is the session valid? What is the level of authorization? (See the session identifier section in this guideline.)Request authorisation. Ensure that the caller has the authority to call the API (for example, an API key or an authorisation based on the session).When using the request ID pattern (see above), does the request include it? If it does, and we perform subsequent calls to other systems, we need to include this identifier. If it doesn't, we need to create it (or if it should be present, we should drop the request).Integrity of the request and the data. Determine the integrity of the request. When using an API key or another shared secret between the caller and the API, integrity protection can build on that secret. Typically, authorization credentials are transferred using JSON Web Tokens (JWT) and complete API call integrity can be attained using AWS Signature v4 scheme.Is the incoming request well formed? Even when using JSON, the request should be validated against a schema. This protects the API against injection of arbitrary data fields. Without schema validation, there is a risk that arbitrary extra data fields may end up even in a database – a typical problem when using schema-less databases. Domain Driven Design (DDD) may be a useful approach, see Secure by Design, below.Authorisation of the returned data. In some cases, calling the API and actually getting specific data in the response are different authorisation decisions.Does the API need to create audit log events for this call? (Please see the section on audit logging in this guideline.)Does the API set all required HTTP headers in the response, such as HSTS and Content-Type? (Please see the section on HTTP headers in this guideline.)When using JWT for authorisation, its choice of cryptographic algorithms and key lengths should follow the TLS 1.2 guideline as applicable (above).Sources:JSON Web Tokens theme pages Signature v4, which is not AWS specific by Design: Cross-Origin Resource Sharing (CORS)CORS is a framework where the server informs the browser that it is allowed to bypass the normal same-origin rules and call an API on another domain. The browser performs a separate initial request, called a preflight request, to determine whether this type of cross-origin access can be allowed. It is important to note that enforcement of CORS happens on the browser side. An attacker can still call an API without a browser irrespective of what its CORS set-up is. Server-side access control must always be implemented using appropriate access credentials.The target server provides their CORS policy using the Access-Control-Allow-Origin header. Access-Control-Allow-Origin specifies the sources of JavaScript code that may call that API (that is, where the JavaScript originated that can call the API).For example, if an organization has a web application at , and an API at api.cloud.example, and they want JavaScript from the web page to be able to call api.cloud.example, the api.cloud.example API must be configured to return something likeAccess-Control-Allow-Origin: Access-Control-Allow-Methods: GET POST PUT DELETEin their HTTP responses. If the API requires credentials (e.g., in cookies), it also has to explicitly grant the browser the possibility to deliver cross-origin credentials withAccess-Control-Allow-Credentials: trueIf an API needs to be callable from whatever JavaScript code, irrespective from where it has been served, the header would readAccess-Control-Allow-Origin: *If the API is not supposed to be generally callable, existence of this header may indicate that the CORS policy is too lax.Sources: CSRF tokensCross Site Request Forgery (CSRF) is an attack where an attacker site performs a HTTP request towards another site using the user’s browser. If the browser has an active session on the target site, the attacker may perform actions on the user’s behalf.CSRF can be mitigated by providing a cryptographically random and sufficiently long value, known as a CSRF token, with each HTTP request. The tokens are stored in the browser in such a way that the attacker site, or JavaScript that originates from the attacker site, cannot access them, and therefore cannot forge the requests.CSRF is easily mitigated by using a proper framework that provides CSRF protection by default. In most cases, this would be preferable.If this type of framework support is not available, a recommended way to mitigate is to use a “double submit cookie”. This method is useful because it is stateless, requiring no server-side storage, and as such it can be used when requests are routed to random servers through a load balancer. As with many other security features, na?ve implementations of this may introduce vulnerabilities.Sources:(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookie Confidential data in parametersAPI calls must be formed in a way that personal data or other confidential data is not provided as a part of a URL. Parameters and path elements of a URL will easily get logged, stored in cache and browser history, be stored by proxies, or leak in Referrer headers.All confidential data should be transferred in the body of a POST request.The correct way could look for example like this:POST /search/address HTTP/1.1SSN=010170-123FThe wrong way could look something like this:GET /search/010170-123F/address HTTP/1.1In these examples, 010170-123F is a Finnish personal identification number. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download