Mistä on tietoturvalliset julkipilvet tehty?

Julkiseen pilveen siirtyminen houkuttaa, sillä skaalautuvuus ja vikasietoisuus ovat parempia kuin omassa konesalissa, hinta perustuu käyttöön, uusien palveluiden ja teknologioiden käyttöönotto on nopeaa, ja ylläpitotyötä voi automatisoida. Pilvisiirtymässä korostetaan usein hallintamallien muutostarvetta tai tekniikan modernisointia, mutta tietoturvan ja tietosuojan osuus onnistuneesta siirtymässä jää monesti sivulauseen asemaan. Mistä tietoturvalliset julkipilvet on siis tehty? Tietoturvavaatimuksista, uhkamalleista, tietosuojakontrolleista, pääsynvalvonnasta ja identiteetinhallinnasta, taitavasta tietoturvavalvonnasta, poikkeamanhallinnasta, mietitystä migraatiosta. Niistä on tietoturvalliset julkipilvet tehty.

Tietoturvavaatimuksista

Jos kaikkia suojaustarpeita ei tunnisteta ajoissa, voi tietoturvaominaisuuksien ja suojakerrosten lisääminen jälkikäteen olla työlästä. Viranomaiskäyttöön tarkoitetuissa pilvipalveluissa vaatimusmäärittelyn apuna on pilvipalveluiden turvallisuuden arviointikriteeristö eli PiTuKri. Kriteeristö on suunniteltu kansallisten salassa pidettävien ja suojaustason IV salassa pidettävien aineistojen suojaamista varten, mutta sitä voi soveltaa myös julkiseen viranomaistietoon sekä liikeyritysten pilvijärjestelmiin. PiTuKrin laatimisessa on hyödynnetty mm. Cloud Security Alliancen (CSA) Cloud Controls Matrix -suojausvaatimuksia, joka on myös tutustumisen arvoinen dokumentti. Osa vaatimuksista täytetään pilvipalveluntarjoajan toimenpiteillä; osa on organisaation itsensä vastuulla.

PiTuKrin lisäksi kannattaa tutkia pilvialustan, esimerkiksi AWS:n tai Azuren, omia parhaita käytäntöjä. Uhkamallinnus voi myös tuoda esiin sovelluksen tai käyttöympäristöön liittyviä tietoturvaheikkouksia, joihin tarvitaan joko teknisiä tai prosessisuojauksia. Riippumatta siitä mistä tietoturvavaatimukset ovat peräisin, on tärkeää, että niitä sovelletaan riskien pohjalta. Tietoturvaa ei tarvitse vetää överiksi, jos riski on mitätön.

Riskien arviointi ja vaatimustenmukaisuuden tarkistus ei ole mikään kertaluontoinen juttu, vaan turvallisuuskriteerien täyttymistä pitää valvoa säännöllisesti joko pilviympäristön teknisillä keinoilla tai muilla tarkastuksilla.

Uhkamalleista

Voi olla, että alun perin uhkamallinnuksen osoittamat saatavuusongelmat veivät katseet pilviin. Vaikka osa uhkista voi korjautua pilvisiirtymällä, niitä voi tulla myös lisää. Uhkamalli on syytä päivittää ajan tasalle huomiomaan uudenlainen arkkitehtuuri ja uudet hyökkäysrajapinnat. Jos hypätään järjestelmätoimittajan valmiiseen pöytään, järjestelmäkuvaukset jättävät joskus toivomisen varaa ja arkkitehtuuria esittävän abstraktin laatikkokuvan perusteella ei voi päätellä, millä magialla tietoliikenneyhteydet toimivat. Tutki siis arkkitehtuuria huolella.

Myös hallintavastuiden jakautuminen voi aiheuttaa tietoturva- ja tietosuojauhkia. Ketkä kaikki pääsevät tietoon? Kuka uusia palveluita kehittää? Ison organisaation jokaisella tiimillä saattaa olla omanlaisensa kehitystapa ja työkalut, mutta yhteneväiset tietoturvapolitiikat, asetukset ja hallittavuus puuttuvat. Kellään ei välttämättä ole kokonaiskäsitystä siitä, mitä pilvessä on.

Tietosuojauhkiakin on syytä käsitellä. Osa ongelmista voi jäädä huomioimatta, jos asiaa lähestytään vain tietosuojavaikutusten arviointilomakkeen kautta tai uhkamallinnuksessa mietitään vain tiedon vuotamisen mahdollisuutta. Siksi tietoturvaa ja tietosuojaa tulee tuoda lähemmäs toisiaan ja käsitellä kattavammin uhkatyöpajoissa.

Tietosuojakontrolleista

Tiedon luottamuksellisuus tuo rajat siihen, mitä pilvessä voi tehdä. Henkilötiedon luottamuksellisuus voi vaihdella esimerkiksi julkisesta erittäin arkaluontoiseen. Henkilötietojen käsittely pilvipalvelussa on sallittua, mutta käsittelyn riskit tulee arvioida henkilötietojen luonteen perusteella. Myös tiedon kasautumisvaikutus tulee huomioida: vaikka yksittäiset tiedot eivät olisikaan erityisen luottamuksellisia, tiedoista koostuva tietomassa on kokonaisuutena luottamuksellisempi ja tietoturva- ja tietosuojavaatimukset voivat tiukentua. Tällöin on huomioitava, missä tieto fyysisesti sijaitsee. Järjestelmäkokonaisuuden, olipa kyseessä julkinen, yksityinen tai hybridipilvi, tulee täyttää tietosuojalainsäädäntö ja henkilötietoihin liittyvä erityislainsäädäntö. Jotkin pilvipalvelun tarjoamat lisäpalvelut tai toiminnallisuudet voivat aiheuttaa tietosuojauhkan, jos niissä käsitellään tietoa EU-alueen ulkopuolella.

Tietosuojakontrollien riittävyyden varmistamiseksi on hyvä tiedostaa, että ylimääräistä henkilötietoa voi muodostua myös eri tietolähteitä yhdistelemällä tai jos anonymisointi on puutteellista. On myös ongelmallista, jos pilvipalvelu ei tuota henkilötietojen käsittelystä riittävää lokijälkeä. Henkilötietojen turvallisuutta kannattaa tarkastella koko tiedon elinkaaren ajalta keräämisestä poistamiseen.

Pääsynvalvonnasta ja identiteetinhallinnasta

Käyttäjien identiteetinhallinta, pääsynvalvonta ja käyttäjän tunnistusmenetelmän luotettavuus ovat oleellisessa osassa, kun halutaan estää kriittisen tiedon valuminen väärään paikkaan ja varmistua siitä, että vain tarvittavilla henkilöillä on pääsy tietoihin ja käsittely-ympäristöihin.

Pilvessä käyttöoikeuksien ajan tasalla pitämisen tärkeys korostuu. Organisaation jo olemassa olevan identiteetinhallinratkaisun integrointi federoimalla pilvipalveluun on yleensä kätevin tapa, kunhan tunnistuspalvelu on riittävän vahva ja tunnistamistiedon välitys on tehty turvallisesti.

Toimenkuvan tai työroolin lisäksi oikeus luottamukselliseen tietoon pääsyyn voi liittyä myös tiettyyn organisaatioon. Tällöin identiteetinhallintaratkaisun olisi hyvä tukea tätä mallia mahdollisimman hyvin.

Mitä isompi hallintaorganisaatio tai mitä kriittisempää tietoa käsitellään, sitä hyödyllisempiä ovat ratkaisut, joilla ylläpitoyhteydet suojataan ja joilla mm. ylläpitosalasanoja ja muita tärkeitä käyttäjätunnuksia voidaan hallita joustavasti. Privileged Access Management -ratkaisut (PAM) mahdollistavat esimerkiksi hallintasalasanan vaihtamisen jokaisen käyttökerran jälkeen tai jopa ylläpitäjän käyttöoikeuden antamisen yhdelle käyttäjälle kerrallaan tiettyä toimintoa varten ilman, että käyttäjä missään vaiheessa saa selville varsinaista salasanaa.

Kannattaa tarkistaa myös, mitä pilvialustojen omilla hallintaratkaisuilla on tarjota. Niissäkin on usein erittäin hienojakoista käyttäjien roolitusta mahdollistavia ominaisuuksia ja ne voivat hyvinkin riittää organisaatiosi tarpeisiin.

Taitavasta tietoturvavalvonnasta ja poikkeamanhallinnasta

Pilven tietoturvavalvonta on erilaista kuin konesaliympäristön. Skaalautuvissa pilviympäristöissä uusia palvelimia käynnistetään ja sammutetaan tarpeen mukaan ja muutkin resurssit tulevat ja menevät, joten perinteinen agenttipohjainen valvonta ei toimi. Pilvipalveluntarjoajien omat työkalut yleensä tarjoavat tietoa tietoturvatapahtumista, mutta työkalut pitää ottaa käyttöön, ymmärtää niiden tuottama tieto ja korreloida muiden järjestelmien, esimerkiksi työasemien tai hybridiratkaisussa konesalissa olevien palveluiden tuottamiin lokitietoihin. Näkyvyyskin vaihtelee: Infrastructure as a Service -malli, jossa asiakkaan vastuulla on kaikki käyttöjärjestelmästä rajapintoihin, mahdollistaa pääsyn aivan erilaisiin lokilähteisiin kuin esimerkiksi Platform as a Service. Palveluna tarjottavissa sovelluksissa (SaaS, Sofware as a Service) palvelinresurssien jakaminen voi vaikeuttaa asiakaskohtaisten lokien saamista reaaliaikaisesti.

Tietoturvapoikkeamien hallintaa kannattaa harjoitella, jotta ympäristö on tuttu ja jotta tiedonkulku eri osapuolien kanssa olisi sujuvaa: osa havaintodatasta tulee pilvipalveluntarjoajalta ja tietoturvaloukkausta tutkimassa voi olla organisaation ulkopuolisia apuvoimia. Harjoittelemalla voidaan kokeilla, miten tietoturvaloukkausta tutkivalle tiimille voidaan tarjota automatisoidusti pääsy tarvittaviin ympäristöihin, testata löytyykö kaikki tarvittava tieto ja harjoitella viestintää.

Mietitystä migraatiosta

Jos olemassa olevaa tietoa tarvitsee siirtää konesalitoteutuksesta pilveen, kannattaa käyttää hetki aikaa sen pohtimiseen, voiko jokin mennä pieleen migraatiossa. Miten varmistutaan, että tietoa käsitellään turvallisesti myös siirron aikana välitallennuspaikossa ja siirtotiellä? Säilyväthän käyttöoikeudet ennallaan vai voiko tapahtua virhe?

Siirron yhteydessä voi olla kiinnostavaa – ja myös järkevää – modernisoida toteutustekniikkaa, jotta pilven ominaisuuksista saadaan kaikki tehot irti. Ennen kuin laitetaan kaikki konttiin tai tehdään toteutuksesta serverless, on hyvä pohtia, osataanko uudet teknologiat koventaa tarpeeksi hyvin? Siirtymä ei lopu siihen, että on päästy pilveen. Kaikkea legacya ei ole pakko pudottaa kelkasta heti, vaan modernisointia voi tehdä vaiheittain.

Tekniikan lisäksi vaiheistusta kannattaa suunnitella myös liiketoiminnan, henkilöstön, operoinnin ja tietoturvan kannalta. Millaisia liiketoimintatavoitteita, kustannuksia ja riskejä pilveen siirtymiseen ja kehitykseen liittyy? Millaista osaamista tarvitaan? Tarvitseeko henkilöstöä kouluttaa? Onko pilveen siirtymisen yhteydessä mielekästä ulkoistaa esimerkiksi valvontaa? Lisää näkökantoja ja parhaita käytöntöjä voi hakea esimerkiksi AWS:n, Azuren ja Google Cloudin pilven käyttöönotto-ohjeista.

Haluatko tietää lisää pilven tietoturvasta? Lataa artikkelimme, 5 askelta turvalliseen pilveen, ja katso tehtävälista, jonka avulla sinäkin voit tehdä pilviympäristöstäsi turvallisemman.