1.
Verkkoliikenteen 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. Toteutuksessa voi käyttää Mutual TLS (mTLS) -todennusta.
Verkon eriyttäminen tapahtuu pääsääntöisesti siten, että sovellusalueella on omat Kubernetes-klusterinsa. Jos ei käytetä Kubernetes-klusteria tai halutaan käyttää jaettua klusteria, tulee näissä tapauksissa verkon eriyttäminen arvioida erikseen.
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.
Lisätietoa: Cloudflare: What is mTLS? https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/
2.
Sovellukset viedään tuotantoon aina konteissa
Sovellukset viedään aina tuotantoon kontitettuna, jotta niiden riippuvuudet ovat selkeitä ja on selvää, mikä koodi kulloinkin on ajossa.
Konteissa käytetään organisaation yhdessä sovittuja pohjakuvia keskitetyn haavoittuvuuksien hallinnan mahdollistamiseksi.
Konteissa pitää olla mahdollisimman vähän toiminnallisuutta hyökkäyspinnan minimoiseksi.
Pohjakuvista pitää aina build-vaiheessa käyttää uusimpia minor-versiota haavoittuvuuksien minimoimiseksi.
Kontin ajonaikainen konfiguraatio pitää koventaa organisaation ohjeiden mukaisesti.
Jos sovelluksen toteutuksen kannalta on tarvetta konttien sijaan esimerkiksi serverless-ratkaisuihin, niiden toteutusmahdollisuus tulee aina arvioida tapauskohtaisesti.
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. Jos koodilla ei ole ulkoisia riippuvuuksia eikä se ole jatkuvuussuunnittelun kannalta kriittinen osa palvelua, voidaan päättää, että kontittoman Lambdan käytön riski on hyväksyttävissä.
3.
Pilvipalveluntarjoajan tilejä käytetään erottelemaan sovellukset ja niiden eri ympäristöt toisistaan
Jokaiselle sovellukselle ja saman sovelluksen eri ympäristöille (kehitys-, testaus- ja tuotantoympäristöt) pitää luoda oma tilinsä, elleivät sovellukset tai ympäristöt jaa samaa luottamusaluetta. Jos sovellukset ovat pieniä eivätkä ne ole tietoturvakriittisiä, niille voidaan tarjota keskitettyä ajoympäristöä.
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.
4.
Identiteetin- ja pääsynhallinnassa käytetään minimioikeuksin varustettuja rooleja
Pilvipalvelun rajapintojen oikeudet jaetaan roolien kautta. Käyttäjät saavat käyttöönsä roolin, jolla on minimimäärä tarvittavia oikeuksia. Roolit ja oikeudet tulee säännöllisesti katselmoida ja korjata minimioikeusvaatimuksen mukaiseksi.
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.
5.
Pilvessä ajettavien sovellusten verkkoliikenteen kohteet minimoidaan
Kun pilvessä ajetaan sovelluksia, 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.
6.
Pilvessä ajettavien sovellusten eheys varmistetaan
Pilvessä ajettavien sovellusten/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.
7.
Pilvessä ajettavien sovellusten elinkaari pitää olla auditoitavissa
Pilvessä ajettavien sovellusten elinkaaresta pitää jäädä auditoitavia todisteita, joiden avulla voidaan jälkikäteen selvittää, mitä koodia milloinkin oli ajossa.
Esimerkki: Kaikista tuotantoon viedyistä Docker-konteista tehdään erillinen arkistokopio. Lisäksi Kubernetes-podien poistamisesta ja luomisesta jää auditoitava lokimerkintä.
8.
Pilvipalveluntarjoajan palvelut on rajattu vain tarpeellisiin
Pilvipalveluiden tarjoajien palvelut rajataan niin, että vain tarpeellisia palveluita ja maantieteellisiä alueita voidaan käyttää.
Esimerkki: Sovelluksiin liittyvät AWS-tilit luodaan AWS-organisaation alle, jolle on määritelty asianmukaiset palvelupolitiikat (service control policies). Näillä estetään esimerkiksi EU:n ja Euroopan talousalueen (ETA) ulkopuolisten alueiden (region) käyttö.
9.
Pilvipalveluntarjoajan tallennetun tiedon salausratkaisut ovat käytössä
Pilvipalvelut tarjoavat yleensä tavan salata niihin tallennetun tiedon siten, että salaus on palvelun käyttäjälle läpinäkyvää.
Vaikka tämä ei suojaakaan tietoa sovelluksen haavoittuvuuksilta, tallennetun tiedon salausta tulee kuitenkin käyttää siksi, että tieto on tallennettu pilvipalveluntarjoajan muistivälineille salattuna ja näin ollen suojaa tietoa.
Esimerkki: AWS:n S3-ämpäreiden (S3 Bucket) oletusarvoinen salaus otetaan käyttöön.
10.
Tietoturvamonitorointi on vastuutettu
Tuotetiimi määrittelee tuotteen uhkamalliin perustuen, mitä tietoturvaan liittyviä tapahtumia on seurattava. Tapahtumien seurannan vastuutus on määritelty.
Esimerkki: Jos käytetään erillistä SOC:a, tuotetiimi kertoo SOC:lle ne tietoturvatapahtumat, joiden seuranta tuotteen osalta on tärkeää. Tuotetiimi huolehtii siitä, että nämä tapahtumat luodaan lokitapahtumavirtaan.
11.
Pilvipalveluiden resurssit hallitaan versionhallinnassa säilytettävän konfiguraation kautta
Pilvipalvelun 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.
Jos pilvipalvelun tarjoaja antaa käyttöön inventaariorajapinnan, sitä käytetään apuna ylimääräisten pilviresurssien havaitsemisessa.