Tietomurtojen ehkäisy Googlen pilvessä VPC Service Controls Perimeter -ominaisuudella

”The cake is a lie!”

Kuvitellaan, että maailma on täydellinen. Olet rakentanut pilvipalvelun johon tallennetaan kakkureseptejä, eikä vain mitä tahansa reseptejä, vaan erittäin salaisia kakkureseptejä. Palvelu on rakennettu oletukselle, että tarkoin varjellut reseptit ovat koskemattomia ja, että ne ovat nähtävissä vain rakentamasi tietojärjestelmän kautta. Jokaista vuosikymmenen aikana opittua neuvoa noudattaen järjestelmä on suojattu palomuurein, pääsynhallintalistoin ja salasanoin, joita hallinnoidaan parhaiden mahdollisten prosessien mukaan.

Oletetaan myös, että kyseessä on perinteinen edusta-, tausta- ja tietokantapalvelin web-sovellus, joka pyörii Googlen julkisen pilven alustalla, eli Google Cloud Platformilla. Sovellusta ajetaan selaimessa ja taustajärjestelmä pyörii Docker konttina Kubernetes Engine -ryppäässä. Tietokantana käytetään tekstitiedostoja, jotka sisältävät reseptin ohjeineen ja ne on tallennettu Storage ämpäriin. Sovellus huolehtii siitä, että käyttäjä on tunnistettu ja että käyttäjällä on riittävät oikeudet yksittäiseen reseptiin. Harjoituksen vuoksi tätä pinoa ja toimintalogiikkaa on yksinkertaistettu ja esimerkiksi käyttöoikeuksien tallentamiseen tarvittavaa tietokantaa ei ole huomioitu esimerkkiarkkitehtuurissa. Oletetaan kuitenkin, että se on niin täydellinen kuin ihminen vain kykenee sellaisen rakentamaan.

Kaikki toimii hyvin ja – kiitos pilven sisäänrakennetun skaalautuvuuden – aina luotettavasti myös ruuhkapiikkien kuten juhlapyhien aikaan, jolloin ihmiset himoitsevat eritoten salaisia kakkureseptejä.

Eräänä päivänä kuitenkin kaikki palvelusi reseptit löytyvät ulkopuolisesta tiedostojenjakopalvelusta. Miten tässä näin oikein kävi?

Kaikki ei ole aina niin herkullista

Kuten kaikki ohjelmakoodi, myös kakkureseptejä tallentavan palvelumme ohjelmakoodi on ihmisen kirjoittamaa. Sinne on jäänyt reikä joko suoraan tai välillisesti. Joko ohjelmoija on unohtanut tarkistaa jonkin reunatapauksen virheidenhallinnassaan, hänen käyttämänsä kirjasto on vanhentunut tai se sisältää haavoittuvuuden, jota ei ole vielä havaittu. Aina aktiivinen paikkauskaan ei auta, sillä niin kutsuttuihin nollapäivähaavoittuvuuksiin ei vielä nimensä mukaisesti ole saatavilla korjauksia. Tällaista reikää hyödyntäen kakkuhimoissaan toiminut rikollinen on ohittanut vaivoin rakennetun, oikein ylläpidetyn ja suunnitellun ympäristön tietoturvan ja luikkinut takaisin Internetin syövereihin mukanaan kaikki palveluun tallennetut reseptit. Nopeasti reagoiva tietoturvapoikkeamienhallintaprosessi paljastaa vian ja keinon jota rikollinen käytti datan varastamiseen.

Koska sovelluksemme tarvitsee pääsyn Google Cloud Storage -ämpäriin, jossa reseptimme on tallennettu, on sillä myös luonnollisesti käyttöoikeudet siihen. Google Cloud asettaa Compute Engine palvelulle (jossa Kubernetes Enginen palvelimet pyörivät) oletus ”service account” -tunnuksen, jota käytetään antamaan käyttöoikeuksia muihin projektin resursseihin. Tämä tunnus on palvelun toiminnan kannalta välttämätön ja sille annetaan ämpärissä sijaitseville objekteille, joko suoraan tai ”bucket policy” käyttöoikeuslistan kautta oikeuksia. On kuitenkin virhe olettaa, että applikaatiomme pääsee vain tähän ämpäriin, sillä oikeudet hallitaan kohteessa (ämpäri) eikä lähteessä (ohjelmakoodi ajossa Docker -kontissa). Pystyttämällä ämpärin joka on ns. ”world writable” (eli johon voidaan tallentaa tietoa ilman minkäänlaista autentikaatiota) pääsee kakkureseptisovelluksemme taustajärjestelmä (backend) myös tähän ”väärään” datasiiloon olettaen, että jokin virhe koodissa mahdollistaa sovelluksemme toiminnan muuttamisen. Tässä tapauksessa siis väärän tietosiilon (ämpärin) käyttämisen. Rikollinen onnistui tässä esimerkkitapauksessa suorittamaan sovelluksessa koodia, joka luki oman ämpärin sisältämät reseptit ja kopioi ne rikollisen omaan ämpäriin toisessa Google Cloud Platform projektissa. Tämä on mahdollista, koska vaikka kakkureseptivaras ei tiennyt millä käyttäjätunnuksella sovellus pyöri, hän yksinkertaisesti antoi vain kaikkien kirjoittaa omaan ämpäriinsä, jolloin käyttäjätunnuksella ei ollut merkitystä.

Lisää vain kermavaahto ja saat aina parempaa

Perinteisin keinon tällaisen hyökkäyksen ehkäiseminen on hyvin hankalaa. Vanhoissa omien konesalien ratkaisussa datan varastaminen (data exfiltration) on jatkuva huoli ja yleensä applikaation taustapalvelun ohjelmakoodia on estetty palomuurein keskustelemasta Internettiin, jotta dataa ei voida varastaa kopioimalla sitä ulos palvelinsalin lähiverkosta. Tällöin riski siirtyy edustajärjestelmien (frontend) ohjelmakoodiin, mutta se ei oikeastaan koskaan poistu. Moderneissa pilvipalveluissa samaan uhkaan voidaan vastata modernein keinoin.

Google Cloud Platformilla teknologia jolla voimme estää datan varastamisen edellä kuvatulla tavoin liittyy Virtual Private Cloud ominaisuuden Service Controls asetuksiin.

Tämä vähän tunnettu ominaisuus on ehdottomasti jotain joka erottaa Googlen pilven muista toimijoista, koska se mahdollistaa hienojakoisen pääsynhallinnan sovelluksemme ja Googlen pilven rajapintojen välillä. Voimme esimerkiksi rajoittaa pääsyn vain projektin sisältämiin resursseihin (perimeter) tai myös toisiin organisaatioden projekteihin käyttämällä silta (bridge) tyyppistä Service Control asetusta.

Pähkinänkuoressa VPC Service Controls Perimeter rakentaa pilvessä sijaitsevan virtuaalisen konesalin ympärille kehyksen (jonka sisältä tulevat API -kutsut jotka suunnataan tuettuihin Googlen rajapintoihin) käsitellään tavallaan omassa virtuaalisessa kehyskohtaisessa API-reitittimessä. Tällöin kutsuihin voidaan asettaa lisärajoitus (perimeter), joka sallii API -kutsun suorittamisen vain mikäli kutsu suuntautuu kohti resurssia, jonka kohde sijaitsee projektin sisällä, esimerkiksi Storage ämpäriin. Tällaisia kehyksiä erimuotoisin asetuksin voidaan rakentaa saman organisaation sisälle useita ja ne voidaan myös yhdistää siltaamalla (bridge). Tällöin API kutsut sallitaan vain näiden projektien sisältämiin resursseihin, mutta niiden ulkopuoliset resurssit ovat käyttökiellossa.

Yksi osa kermaa ja toinen sokeria

Mikäli tietoturvaa halutaan lisätä, voidaan VPC verkkoon kytkeä päälle myös Private Google Access ominaisuus, jolloin verkon reitittimeen luodaan reitit Googlen omiin palveluihin konesalin lähiverkon, ei Internetin kautta. Lisäksi tarvitaan myös muutos Cloud DNS -palveluun jokaisessa projektissa, jossa lähiverkon kautta halutaan suorittaa kutsuja Googlen API -rajapintoihin. Cloud DNS:llä ylikirjoitamme googleapis.com DNS-vyöhykkeen (zone) ja palautamme API-rajapintapalveluiden IP -osoitteita tiedusteleville resursseille julkisten IP -osoitteiden sijaan sisäverkon IP -osoitteet.

Riippuen siitä miten kakkureseptipalvelun edusta- ja taustajärjestelmien (frontend, backend) ohjelmakoodi on rakennettu, ne voitaisiin myös erotella omiin GCP projekteihinsa ja Service Control kehyksiinsä (perimeter). Tällöin näiden kehysten välille voidaan rakentaa silta (bridge) tai projektit voidaan riippuen halutusta suojaustasosta asettaa myös samaan kehykseen jolloin siltaa näiden välillä ei tarvita.

Taustajärjestelmän kehyksen sisäiset resurssit voidaan suojata vielä siten, että kaikki Internettiin päin kulkeva liikenne on estetty. Tällöin vain edustajärjestelmät kykenevät keskustelemaan taustajärjestelmään ja vikakoodin suoritus siten, että tallennettu tieto voidaan varastaa alussa mainitulla tavalla ei enää onnistu.

Googlen avattua datakeskuksensa Haminaan voidaan myös käyttämällä aluekohtaisia (region) resursseja tallentaa tieto vain Suomen maaperälle mikäli lain kirjain sitä jonkin tiedon osalta vaatii.

Käytettävissä on myös Google Cloud KMS avaintenhallintapalvelu, jonka avulla voidaan suojata myös salassa pidettävää materiaalia ja silti tallentaa sen pilveen.

Jälkiruoka tee ja after eight

VPC Service Control Perimeter -on hyvin tuore lisäys Googlen pilven tarjoamiin tietoturvaominaisuuksiin ja se sisältää joitakin kummallisuuksia kuten APIen rajoittamiseen liittyviä käyttökokemus haasteita. Google kuitenkin työskentelee aktiivisesti ominaisuuden parissa ja tähänkin on odotettavissa parannuksia. Ominaisuuden dokumentaatiokin on laajentunut täyteen mittaansa sitten alkuperäisen ominaisuuden julkaisun tämän vuoden keväällä.

VPC Service Control Perimeter -ominaisuus on tärkeä mikäli ympäristössä käsitellään arkaluonteisia asioita, kuten henkilö- tai terveystietoja. Etenkin siirryttäessä perinteisestä konesalista pilvinatiiviin alustaan. Esimerkiksi julkishallinnon tai turvallisuussektorin puolella hyödyntämällä tätä ja muita GCPn tarjoamia tietoturvaominaisuuksia voidaan ratkaista monia huolia, joita yleensä esitetään pilviratkaisuja vastaan.

Kaikkia näitä tekniikoita yhdistelemällä GCP ympäristössä voidaan toteuttaa hyvin rajattu ympäristö tiedon käsittelyyn. Solita on mm. aktiivisesti mukana kehittämässä suomalaisia julkisen sektorin ja lääketeollisuuden hanketta, jossa hyödynnetään GCPn tarjoamia teknologioita mm. yksityisyydensuojan ja GDPR:n alaisten tietojen suojaamiseksi.