ChaosDB: Uhkaava repeämä pilvessä

ChaosDB:ksi nimetyn haavoittuvuuden perusajatus on yksinkertainen: Azuren Cosmos DB -tietokannan yhteyteen taannoin lisätty uusi ominaisuus, datavisualisoinnin Jupyter Notebooks -käyttöliittymä, sisälsi haavoittuvuuden, jonka kautta oli murtautua myös toisten asiakkaiden Cosmos-tileille.

Microsoftin reaktio oli nopea: Vuotava ominaisuus kytkettiin pois käytöstä alle kahdessa vuorokaudessa sen jälkeen, kun löytäjät olivat raportoineet haavoittuvuudesta Microsoftille. Kun ongelmasta kerrottiin julkisesti vajaa kaksi viikkoa myöhemmin, Microsoft suositteli tuhansille Cosmos DB:n käyttäjille pääsyavainten kierrätystä – toimenpidettä, jossa tietokannan käyttöön tarvittavat salasanat vaihdetaan uusiin. Suositus koski niitä asiakkaita, joiden pääsyavaimet olisivat potentiaalisesti voineet olla vaarassa.

Elokuun lopussa elettiin Devisioonassakin muutamia hikisiä hetkiä, kun värkkäsimme koordinoituja avaintenkierrätyksiä Cosmosta käyttäville asiakkaillemme. Tämän operaation yhteydessä esiin nousi koko joukko ajatuksia ja huolia tulevasta. Vaikka Microsoft sittemmin vahvistikin, ettei aukkoa ollut käytetty, mitä olisikaan voinut aivan yhtä helposti käydä, jos löytäjä ei olisi sattunut olemaan tietoturvatutkijaryhmä? Tai jos tutkijaryhmä olisi päättänyt Microsoftin 40 000 dollarin bugipalkinnon sijaan rahastaa löytönsä pimeillä markkinoilla?

Lisätietoja: Wiz-yrityksen tutkijaryhmän blogikirjoitus haavoittuvuudesta

Eikö julkipilven pitänyt olla turvallinen?

Lähtökohtainen oletus on, että pilvi on turvallisempi kuin on-premises-ympäristö: pilvessä oleva kunnolla konfiguroitu virtuaalikone on lähtökohtaisesti paremmassa turvassa kuin paikallisessa konesalissa oleva vastaava viritys. PaaS- ja SaaS-palveluilta odotetaan suorastaan vieläkin korkeampaa tietoturvan tasoa, ja jos haavoittuvuuksia esiintyykin, ne pystytään yleensä korjaamaan nopeammin kuin on-premises-ympäristössä.

Sinänsä nämä odotukset täyttyivät nytkin. ChaosDB korjattiin erittäin nopeasti löydöksen jälkeen, ja Microsoftin tietoturvavaste oli esimerkillinen. Jos vastaava ongelma olisi löytynyt jostain paikallisesti asennettavasta sovelluksesta, korjaussykli olisi toki ollut paljon hitaampi ja hankalampi. Tästä huolimatta koko afääristä jäi hieman nihkeä maku suuhun: Miten saattoi käydä niin, että kokonainen palvelu avautui näin perustavanlaatuisella haavoittuvuudella lähes koko maailmalle? Miten huolehtia siitä, ettei näin käy uudelleen?

Vaikka toimisikin Microsoftin ohjeiden mukaisesti, epävarmuus jää kaivamaan. Lopulta kyse onkin siitä, että turvallisuus julkisessa pilvessä vaatii jatkuvaa suunnittelua ja hallinnointia, mahdollisesti myös uusien palveluiden käyttöönottoa. Aloitettavissa projekteissa nämä menettelyt on helpompi huomioida, mutta esimerkiksi vuosia vanhoissa järjestelmissä kaikkia Azuren uusia ominaisuuksia ei välttämättä ole huomioitu.

Pilvievoluution päänsäryt

Jälkiviisaasti tekee mieli sanoa, että Microsoftin Azure-tiimi teki virheen kytkiessään Jupyter Notebooks -ominaisuuden päälle oletuksena uusille Cosmos-kannoille. Paikallisissa palvelintuotteissa minimaalisen hyökkäyspinnan varjeleminen on todella pitkällä, ja esimerkiksi Windows Serverin oletusasennus on jo riivitty turhauttavankin kevyeksi. Tässä valossa tuntuu jopa hieman hurjalta, että kriittiseen tietokantaympäristöön asennetaan oletuksena mukaan datan selailuun ja visualisointiin tarkoitettu monimutkainen käyttöliittymäsovellus. Turvamielessä ideaalista olisi, että Azuressakin voisi paremmin valita kussakin resurssissa tarvittavat ominaisuudet – ani harva käyttää edes Storage Accountin tai App Servicen kaltaisesta peruspalvelustakaan kaikkia sen vipstaakeja. Jokainen päällekytketty ominaisuus voi aina sisältää sen kriittisen bugin, joten parasta olisi ajaa vain mahdollisimman vähän koodia.

Asia ei kuitenkaan ole yksioikoinen. Azuren tuotevalikoiman monimutkaisuus aiheuttaa jo nykyisellään Microsoftille viestintävaikeuksia, ja jokainen Azurea käyttänyt myös tietää, miten haastavaa ominaisuusvalikoimassa navigointi on. Jos jokainen asennusskripti ja ohjevideo pitäisi varustaa ”Huolehdi että tämäkin ominaisuus on otettu käyttöön”-varmistuksilla, käyttökokemus olisi entistäkin sekavampi. Näin erityisesti, kun parhaaseen as-a-service-henkeen uusia ominaisuuksia lisätään jatkuvasti ja joka paikkaan. Kuinka pieninä tai isoina palasina näistä pitäisi voida valita?

Jatkuva muutos on haaste niin Microsoftille kuin asiakkaille ja ylläpitopalvelua tarjoaville toimittajillekin. Jos Cosmos DB on napattu käyttöön JSON-dokumenttien tietovarastoksi 2018, tiesikö järjestelmän ylläpitäjäkään edes koko Jupyter Notebooksista? Azure-palveluiden evoluutioon on monesti voinut suhtautua ”tarpeen mukaan”-tekijänä: opetellaan uusia ominaisuuksia silloin, kun niitä jossain projektissa tarvitaan.

ChaosDB muistuttaa laajemminkin siitä, että vaikka pilvipalvelut eivät yleensä vaadi päivityksiä, vuosien takainen parhaiden käytäntöjen mukainen arkkitehtuuri ei välttämättä enää ole paras. Tietoturvakinkereissä ei riitä säilyä vanhalla tasolla, hyökkääjät kun laukkaavat joka tapauksessa eteenpäin. Microsoft ja muut julkipilven tarjoajat tekevät kaikkensa suojellakseen asiakkaitaan tietoturvahaavoittuvuuksilta, mutta palvelut monimutkaistuvat jatkuvasti, ja virheitä voi sattua ihan kaikille.

Jatkuvalla kokonaisarkkitehturoinnilla on arvoa

Keskustelun oikeasta arkkitehtuurista ja riittävistä ylläpitokäytännöistä on oltava jatkuvaa, ei vain projektivaiheen kertaluontoinen analyysi. Pilvi-infrastruktuurin helppo pystytettävyys kannustaa aloittamaan Hello World -tasoisesta minimistä ja rakentamaan lisää vähitellen. Ketteryys on hyvästä, mutta palanen kerrallaan väkertäessä päädytään usein ottamaan käyttöön uusia palveluita juuri kyseisen palvelun demoja ja ohjeita seuraten. Tällöin laajemmat palveluiden väliset yhteydet ja mahdollisuudet jäävät helposti ajattelematta – tai ainakin projektipaineessa toteuttamatta.

Esimerkki usein puuttuvasta arkkitehtuurista liittyy virtuaaliverkkojen käyttöön. ChaosDB-haavoittuvuuttakin olisi voinut torjua käyttämällä virtuaaliverkkoja ja palomuurisääntöjä, esimerkiksi Azure Private Link -palvelua. Se mahdollistaa Azuren PaaS-palveluiden suojaamisen siten, että niihin on pääsy vain rajatuista aliverkoista. Vaikka Jupyter Notebook -toiminto olisikin paljastanut hyökkääjälle pääsyavaimet, kantaa olisi päässyt lukemaan vain murtautumalla lisäksi sopivaan verkkoon. Oletuksena monet Azuren PaaS-palvelut ovat kuitenkin auki koko maailmalle.

Kerroksittaisella sipulitietoturvalla on siis paikkansa Azuressakin, mutta käytännössä Private Linkiä ja virtuaaliverkkoja ei ole viritetty läheskään kaikkiin pilvessä pyöriviin PaaS-toteutuksiin. Syyttävää sormea voi osoittaa Microsoftin suuntaankin: esimerkiksi Cosmos DB:n oletustietoturva-asetukset sallivat liikenteen avoimesti kaikkialta, mikä toki onkin helpompaa. Lisäksi Private Link julkaistiin vasta keväällä 2020, ja kaikki Azuren PaaS-palvelut eivät tue sitä vieläkään. Parhaiden menettelyjen käyttöönotto ei siis aina ole myöskään niin yksinkertaista kuin voisi toivoa.

Ongelmaa olisi voinut lähestyä myös käyttämällä pääsyavainten sijaan Azure AD:hen perustuvaa tunnistautumista, jolloin keskitettyjen avainten vuotaminen ei olisi haitannut. Tämäkin on loistava ratkaisu, mutta tuli saataville vasta toukokuussa 2021, ja sen tuki on vielä jossain määrin rajoitettu. Azure AD -pohjaiset Managed Identity -ratkaisut ovat oikea suunta, mutta tuessa on vielä kehittämistä, sillä läheskään kaikki palvelut eivät sitä tue. Ja niin kauan kun eivät tue, käyttöönottoon liittyvät ylimääräiset jumpat voivat tuntua aikapaineessa haastavilta – eihän ratkaisusta saada edes kattavaa.

Toisaalta vikaa voi etsiä myös toimittajista ja asiakkaista: Kerran käyttöönotetun palvelukokonaisuuden uudelleenjärjestelyä verkkotasolla ei välttämättä tule tehdyksi, koska asia ei ole kenenkään pöydällä – tai vaihtoehtoisesti sopalle olisi liiankin monta kokkia. Monet parhaista käytännöistä ovat suhteellisen uusia, ja siten mahdollista remontointia tarvitsevia vanhempia palveluita olisi jo melkoinen joukko. Harvassa organisaatiossa on kuitenkaan selkeää mallia, jolla Azuren uusia ominaisuuksia otettaisiin vanhoissa sovelluksissa harkintaan huolellisen kustannus/hyöty-analyysin kautta.

Tietoturva on ikuinen murheemme

Tätä blogipostausta kirjoitettaessa nousi julkisuuteen Azure Container Instancesia koskeva haavoittuvuus, joka nimettiin AzureScapeksi. Lisäksi eräs ChaosDB:n löytäneistä tutkijoista kertoi Twitterissä, että tiimi oli löytänyt heti perään toisen Azure-haavoittuvuuden, josta ei ole vielä tarkempia tietoja. Nämä käänteetkään eivät tarkoita sitä, etteikö pilveen voisi luottaa, mutta poikkeuksellisen haavoittuvuuksien tiivistymän pitäisi terävöittää katseita tietoturvan hallintaan.

Konkreettisten tietoturvauhkien kehittymisen lisäksi meitä vie eteenpäin sääntelynäkökulma. Esimerkiksi GDPR:n 32 artiklassa mainittujen henkilötietojen turvaamisen kannalta ”asianmukaisten teknisten ja organisatoristen toimenpiteiden” ei ole mitenkään yleisesti katsottu edellyttävän virtuaaliverkkorajauksia PaaS-palveluihin, mutta missä vaiheessa tilanne muuttuu? Tietoturvan hyväksyttävä perustaso vuonna 2021 on kovin erilainen kuin vaikkapa Azuren alkumetreillä 10 vuotta sitten.

Perusoletus PaaS-ympäristön turvallisuudesta pitää tietysti edelleen hyvin paikkansa – keskimäärin. Mutta vaikka esimerkiksi Azure SQL Database tai Cosmos DB ovat erittäin turvallisia korvikkeita itse ajetulle tietokantapalvelimelle, voi kysyä, riittääkö turvallinen tietokanta enää kokonaisratkaisun turvaksi. Azuren tietoturvaominaisuudet ovat kehittyneet huimin loikkauksin viimeisen viiden vuoden aikana. Puhutaan sitten salaisuuksien hallinnasta, sovellusidentiteeteistä, verkkosovelluksen palomuureista, Private Linkistä tai Sentinelin kaltaisista varsinaisista tietoturvatuotteista, lisäturvaa tarjoavia mahdollisuuksia on todella paljon. Mitkä niistä pitäisi ottaa käyttöön, ja mitkä näistä ovat kriittisiä juuri sen seuraavan haavoittuvuuden torjumisessa?

Keskeisin haaste yhtälössä on riittävän monipuolisen osaamisen ylläpitäminen ja tuominen käytännön tasolle. Pilvi on tehnyt ratkaisukehityksestä aiempaakin devaajavetoisempaa, ja infraosaaminen näyttäytyy monissa hankkeissa lähinnä keskus-IT:n rajoittavien linjausten kautta. Tietoturvan perusopit kuuluvat kaikille, mutta uhkamallinnuksen ja riskianalyysin kaltaiset erityislajit vaativat lujaa otetta erityisesti hankkeiden omistajilta. Pitää olla rohkeutta miettiä, mitkä ratkaisut ovat oikeasti valmiita tuotantoon vietäviksi – ja myös sitä, miten niiden turvallisuutta ylläpidetään pitkällä tähtäimellä.

Haluatko jutella pilviajan digiratkaisujen kehittämisestä – turvallisuusseikat huomioiden? Ota yhteyttä!