Haasta pilvikumppaniasi kysymällä näistä tietoturvan kompastuskivistä

Skaalautuvuus, valmiit komponentit ja ylläpidon mutkattomuus ovat selviä etuja, kun ohjelmistokehitystä tehdään pilviympäristöissä. Suuret palveluntarjoajat, kuten AWS ja Azure, tunnetaan vakaina toimijoina, ja joskus ajatukseen niiden tietoturvallisuudesta on liiankin helppo tuudittautua. 

Datan turvaamisessa kovapintaisinkaan säiliö ei riitä, jos säiliön luukku on asennettu huolimattomasti. Toisaalta tietojen pitää olla oikeiden henkilöiden saatavilla heti, kun niitä tarvitaan.

Tässä artikkelissa Cinian ohjelmistoarkkitehdit Eveliina Pakarinen ja Vili Lipo nostavat esiin hyviä kysymyksiä, joita sovelluskehitystä luotsaavan pitäisi kysyä pilviympäristöjä rakentavalta tiimiltään.

Arvioi seuraavaksi, millaisia vastauksia saisit, jos puntaroisit omaa ohjelmistohankettasi näiden kysymysten valossa:

Toimiiko lokitus lainsäädännön vaatimalla tasolla?

“Kun järjestelmän käyttäjät ovat EU-maiden kansalaisia, GDPR-lainsäädäntö pitää huomioida kaikessa ohjelmistokehityksessä”, Lipo aloittaa. “Lisäksi organisaation toimintaa saattaa ohjata joukko muita vaatimuksia, kuten NIS2-lainsäädäntö, julkisen sektorin KATAKRI-kriteeristö tai tiukka ISO27001-standardi.”

Vaatimukset ohjaavat esimerkiksi AWS-sovellusten kehittäjien työtä käytännön tasolla.

“Ilmeisin GDPR-kysymys lienee, missä data sijaitsee fyysisesti. Sen lisäksi pitää kuitenkin pystyä kertomaan aina tarvittaessa, kuka on käsitellyt henkilötietoja ja milloin. Lokitus pitää suunnitella ja toteuttaa kaikkiin pilvialustan palveluihin niin aukottomasti, että voit raportoida tarkasti ylläpitäjien liikkeistä järjestelmässä. Samalla pitää kiinnittää huomiota lokitietokannan maantieteelliseen sijaintiin sekä sinne vietävien henkilötietojen turvaamiseen tai salaamiseen”, Lipo selittää.

Lokitiedot ovat kullanarvoisia myös silloin, kun herää epäily tietoturvaloukkauksesta. 

"AWS:n palveluista voidaan kerätä CloudTrail-palveluun audit-lokitusta, mutta esimerkiksi S3-palvelussa täysi lokitus esimerkiksi dataan kohdistuville tapahtumille on kytkettävä manuaalisesti päälle", Pakarinen havainnollistaa. "Yksi pilven tietoturvaan liittyvä uhka onkin, että audit-lokitus jää vajaaksi, jolloin tietoturvapoikkeamien selvittäminen jälkikäteen hankaloituu."

Onko pääsynhallinta toteutettu vähimpien oikeuksien periaatteella?

Tietoturvallisessa pilviympäristössä pääsynhallinnan toteutus nojaa kolmen A:n kulmakiviin: authentication eli käyttäjän tunnistautuminen, authorization eli käyttöoikeuksien valtuutus sekä accounting eli edellä kuvattu kirjanpito käyttäjän liikkeistä. 

Vähimpien oikeuksien periaate tarkoittaa, että tunnistetulle käyttäjälle konfiguroidaan järjestelmään vain ne oikeudet, jotka ovat tälle välttämättömiä tehtävän suorittamiseen – ei yhtään enempää. 

Valtuutuksen pitää perustua tiukkaan tarvearvioon, sillä käyttäjän tunnukset voivat päätyä kyberrikollisen kaappaamiksi. Ja mitä vähemmän dataa on silloin näkyvillä, sen parempi.

“Myös ylläpitäjän vastuita ja oikeuksia pitäisi turvallisuuden näkökulmasta jakaa eri henkilöille”, Lipo muistuttaa. “Näin ehkäistään väärinkäyttötapauksia, joissa samoilla oikeuksilla pääsisi sekä hallinnoimaan järjestelmää että siivoamaan jälkensä lokeilta.”

Pakarinen nostaa riskeinä esiin myös palomuurikonfiguraatioihin epähuomiossa jääneet konfiguraatiot, jotka voivat sallia liian avoimen pääsyn esimerkiksi palvelimille.

“Tai jos AWS:n S3-tietovarantoon jää vahingossa konfiguraatio, joka sallii varantoon pääsyn julkisesta verkosta, voivat väärät henkilöt konfiguraatiosta riippuen saada näkyvyyden tai jopa muokkausoikeudet tietovarannon dataan”, hän antaa toisen esimerkin.

Viime vuonna jopa 800 000 Volkswagen-autoilijan sijaintitiedot hakkeroitiin tietomurrossa, joka johtui juuri puutteellisesti tehdyistä S3-konfiguraatioista AWS-ympäristössä. Kaikkiaan yli 15 miljoonan autoilijan arkaluontoinen data oli uhattuna.

Miten varmistat, ettei Infrastructure as Code -ympäristöihin unohdu oletusasetuksia?

Jokainen tehokasta pilvikehitystä havitteleva arvostaa ketteriä tapoja skaalata tekemistä.

Infrastructure as Code (IaC) on vastaus toiveeseen. Se tarkoittaa, että sovellusten vaatimia infra- ja alustaympäristöjä rakennetaan ja hallitaan koodin avulla, ei manuaalisina prosesseina.

“Uuden ympäristön rakentaminen joka kerta alusta, vaihe vaiheelta klikkaillen, on kuin vuolisit aina uuden lusikan puukolla laudanpätkästä. IaC-mallipohjan rakentaminen taas on kuin ohjelmoisit koneellisen sorvin jyrsimään lusikan samasta laudasta. Aluksi ohjelmoinnin vaiva on suurempi, mutta investointi kannattaa, sillä seuraavat lusikat syntyvät nopeasti”, Lipo vertaa.

Koska jo yksi sovellus vaatii useita eri ympäristöjä – kehitykseen, testaukseen ja tuotantoon – Lipo ja Pakarinen suosittelevat IaC-lähestymistapaa. Korkeintaan matalan kynnyksen proof of concept -kokeiluissa voi olla ketterämpää tehdä rakennustyöt alusta asti itse.

“Mutta tarvitset paljon taitoa, jotta saat ohjelmoitua jyrsimen oikein, siinä missä uniikin lusikan veistäminen on suhteellisen helppoa”, Pakarinen muistuttaa. “Koodiin voi tulla virheitä, ja koodia täytyy ylläpitää. Jokaisessa ympäristössä on omat erityispiirteensä ja ulkoiset uhkat muuttuvat, joten IaC-asennus vaatii konfigurointia, oletusasetusten tarkistamista ja niiden muuttamista tarvittaessa.”

Jos ylläpidosta ei huolehdita riittävän hyvin, ympäristöön voi jäädä bugeja tai edellä kerrotun S3-tapauksen tyyppisiä haavoittuvuuksia.

Kokeneilla pilvitiimeillä on taskussaan hyviksi hiottuja IaC-malleja, jotka voivat sopia yleisimpiin sovellusympäristöihin lähes sellaisenaan. Mutta mitä enemmän mukautusta sovellus vaatii, sitä enemmän tarkkuutta tarvitaan myös infran konfiguroinnissa. Näin on varsinkin vaativan ammattikäytön ohjelmistoissa, joissa käsitellään arkaluontoista dataa.

Ovatko tietoturvakontrollit yhtenäiset tuotanto-, testaus- ja kehitysympäristöissä?

Pilviympäristön tietoturvakontrollit ovat konkreettisia keinoja yltää organisaatiossa määriteltyyn tietoturvan tavoitetasoon. Ne ovat toimenpiteitä ja mekanismeja, joilla pyritään suojaamaan järjestelmiä, verkkoja ja dataa. 

Tässä artikkelissa jo mainittujen audit-lokituksen, palomuurikonfiguraatioiden ja tietovarantojen pääsyoikeuksien hallinnan lisäksi kontrollit ja niiden konfiguraatiot voivat liittyä esimerkiksi:

• oletussalasanojen käytön estämiseen
• pääsyn sallimiseen vain määritellyistä verkoista tai
• datan salaamiseen.

Tietoturvan sudenkuoppa voi olla edessä, jos kontrollit ovat kehitys- tai testausympäristössä löyhemmät kuin loppukäyttäjille julkaistussa versiossa eli tuotantoympäristössä.

“Ympäristöjen kontrollien pitäisi olla keskenään samat, jotta tietoturva ei jää kiinni siitä, muistaako yksittäinen kehittäjä käydä painamassa tiettyä nappulaa aina kun tehdään uusi tuotantopäivitys”, Lipo kuvailee.

“Kun hyviin Infrastructure as Code -käytäntöihin, toistettavuuteen ja mukautettavuuteen yhdistää vielä versionhallinnan ja hyvät koodauskäytännöt, pystytään vääriksi huomatut konfiguraatiot myös peruuttamaan hallitusti eri ympäristöissä”, hän jatkaa.

Pakarinen ja Lipo suosittelevat CloudWatchin käyttöönottoa ja konfigurointia AWS-ympäristön jatkuvaan mittaamiseen ja seurantaan. Sen avulla voidaan muun muassa seurata järjestelmän suorituskykyä ja havaita poikkeamia, jotka voivat viitata tietoturvauhkiin.

Kuka kantaa vastuun?

AWS:n Shared Responsibility Model kuvaa pilven tietoturvan vastuunjaon pienellä, mutta tärkeällä erolla:

• Alustan tarjoaja vastaa pilven tietoturvasta (responsibility for security ‘of’ the cloud)
• Asiakas vastaa tietoturvasta pilvessä (responsibility for security ‘in’ the cloud)

Tutustu ohjelmistoratkaisuihin