Kun luottamus kääntyykin riskiksi: Case LastPass

Salaisuuksien hallinta on yksi IT-turvallisuuden kulmakivistä, ja samalla myös melkoinen kipupiste. Perusviesti on selvä: Nojaa mahdollisimman paljon hyvin hallittuun keskitettyyn identiteettiin, luo kaikille palveluille erilliset ja vaikeat salasanat, ja säilytä ne turvallisesti. Kelpo neuvoja, mutta toteuttaminen vaatii käytännössä jonkinlaisen keskitetyn salasanojen muistamiseen tarkoitetun sovelluksen.

Yhdysvaltalainen LastPass on ollut yksi pitkäikäisimmistä salaisuuksien hallintaan tarkoitetuista sovelluksista. Se on tarjonnut jo 15 vuoden ajan salaisuuksien hallintaa niin yksityisille kuin yrityksillekin, sekä työpöydälle että mobiililaitteisiin. Tuotteen imago on saanut viime aikoina säröjä tietoturvakysymysten takia, ja joulun alle piilotettu tiedote datavuodosta loi suorastaan paniikkia: Onko salasanojen turvaholvi murrettu, ja ovatko kaikki vaikeaksi generoidut salasanat nyt helposti hyökkääjien saatavilla?

Epäselvä vuoto lisää ahdistusta

Syyskesällä 2022 LastPassilta varastettiin dataa. Tämä on ollut koko ajan tiedossa, mutta salakähmäisesti jouluaatonaattona paljastui, että varastetun datan joukossa on ollut myös itse holveja – siis niitä salattuja tiedostoja, joissa salasanat sijaitsevat. Periaatteessa salatun tiedoston katoaminen ei ole kovin suuri riski, koska salauksen voi avata vain pääsalasanan avulla, ja hyvän salasanan murtaminen vaatii jopa miljardeja vuosia koneaikaa.

Mutta entä jos salasana ei ole hyvä? Tai entä jos tiedostojen salauksesta paljastuukin jokin haavoittuvuus, joka nopeuttaa murtamista? Riski ehkä silti koskee lähinnä määrätietoista hyökkääjää – mutta kuinka todennäköistä on, että joku haluaisi käyttää koneresursseja ja rahaa korkkaamaan juuri minun salaisuuteni?

Devisioona luopui LastPassin käytöstä jo aiemmin, mutta koska tietomurron täsmällinen ajankohta ja laajuus ei ole selvillä, emme voineet tietää, vaarantuiko jotain meidän tietoamme vai ei. Kansainvälinen tietoturvayhteisö päätyi kuitenkin joulunpyhinä yksioikoiseen johtopäätökseen: Parasta olettaa, että kaikki LastPassiin ikinä tallennetut salaisuudet saattavat olla nyt väärissä käsissä.

Hieman ahdistava johtopäätös, koska tämähän tarkoittaa melkoista salasanojen vaihtorumbaa. Mikä pahinta, ongelma ei koskettanut pelkästään joululomailevia devisioonalaisia, vaan myös asiakkaitamme: tiimikohtaisesti jaetuissa holveissa saattoi olla myös asiakasympäristöjen salaisuuksia.

Hetkinen, mitäs salasanoja siellä edes on?

Henkilötasolla tarve on selkeä: Moniin palveluihin kirjautumiseen tarvitaan salasana. Se pitää tallentaa johonkin, ja holvisovellus on hyvä paikka sellaiseen. Osaan palveluista voi kirjautua some-identiteeteillä (Facebook, Google jne.) tai työtunnisteilla (esim. Azure AD), mikä vähentää salasanojen määrää, mutta ei niin paljoa, etteikö salasanoja olisi silti vähintään pienen ruutulehtiön verran.

Asiakasympäristö- ja järjestelmätasolla tilanne on moninaisempi. Microsoft-ekosysteemissä tietenkin jokainen kehittäjä tunnistautuu MFA-vahvistetulla Azure AD -identiteetillään – meidän tapauksessamme devisioona.fi-tunnuksilla – ja nämä tunnukset eivät tässä hyökkäyksessä olleetkaan uhattuna. Mutta käytännön elämä on osoittanut, että asiakasympäristöihin liittyy myös kaikenlaisia muita tunnuksia ja salasanoja, joita ympäristöihin luodaan ja joita asiakkaat lähettelevät meille tiimin yhteiskäyttöön.

Joskus kyseessä on helpdesk-sovelluksen jaettu käyttäjätunnus, välillä DNS-hallintaan käytetty sertifikaatti, joskus ulkoisen API-palvelun tunnistautumisavain. Sovelluksia varten nämä salaisuudet säilötään tietenkin Azuren Key Vaultiin tai vastaavaan palveluun, mutta osa salaisuuksista on tarkoitettukin kehittäjille, ei sovelluksille.

Salaisuuksien kierrättämisenhän piti olla helppoa, eikö?

IT-alan kirkasotsainen suositus on ollut se, että kaikki tunnistautumissalaisuudet – API-avaimet, SQL-kantojen salasanat, pääsyavaimet jne. – pitäisi aina vaihtaa esimerkiksi puolen vuoden välein. Käsi ylös, kuka näin tekee? Aika harva viittaa rehellisesti. Ja kun kaikki salasanat sitten vaihtaa kiireellä joulun välipäivinä, muistuu kyllä mieleen, miksei sitä tehdä niin usein.

Monissa järjestelmissä voimassa on vain yksi salaisuus kerrallaan: kun vaihdat sen, kaikki käyttöpaikat hajoavat, paitsi jos vaihdat salaisuuden niissä juuri samaan aikaan. Toisinaan taas samoja avaimia on voitu antaa useille toimijoille, jolloin vaihtaminen vaatii usean organisaation välistä yhteistyötä, tai vähintään laajaa viestintää vaihdetuista salaisuuksista. Aina ei ole edes selvää se, missä kaikkialla jotain tiettyä salaisuutta käytetään. Kun se vaihdetaan, mitä yllättävää menee rikki?

Ei kehtaa väittää, että Devisioonakaan olisi hoitanut kaikkea täydellisesti – mekin yllätyimme parista ”Ai tätä käytettiin tuollakin”-tyyppisestä tilanteesta, varsinkin silloin kun oltiin Azure AD:n luoman mukavuuskuplan ulkopuolella. Kaikki-vaihdetaan-kerralla-harjoitus osoitti kuitenkin sen, että harva asiakkaistammekaan hallitsi – tai edes tunsi – luovuttamiaan salaisuuksia täsmällisesti. Tämä on syytä nähdä ennen muuta kannustimena toimittajien ja asiakkaiden yhteiseen keskusteluun, sillä useimmissa tilanteissa kumpikaan ei tätä saa yksin hoidettua.

Tulevaisuus on salasanoista luopumisessa, niin käyttäjien kuin sovellustenkin osalta. Käyttäjien osalta tämä tarkoittaa passwordless-tunnistautumista ja MFA-ratkaisujen vahventumista, sovellusten osalta taas Azuren Managed Identity -tyyppisten tunnistautumisten käyttöönottoa. Varsinkin iäkkäämmissä ratkaisuissa tämä on kuitenkin vielä monesti aika kaukana todellisuudesta, sillä Managed Identitykin on kaikessa loistokkuudessaan varsin tuore tulokas, eikä vieläkään vastaa kaikkiin tarpeisiin.

Loppu hyvin, kaikki hyvin?

Joulun tilanne oli hyvä muistutus siitä, miten tämän päivän tietoturvasuositukset ovat kehittyneet. Toimintatavat, jotka olivat vielä 10 vuotta sitten aivan OK, ovat tämän päivän uhkien edessä yhä riittämättömämpiä. Nopeassa reagoinnissa dokumentaation ja hallintavälineiden taso on aivan kriittistä. Varsinkin integraatioprojekteissa liitännäisjärjestelmiä voi olla jopa kymmeniä, ja oikeiden ylläpitokontaktien tavoittaminen nopeasti – jopa loma-aikaan – on vaativa harjoitus, joka mittaa näppärästi organisaatioiden kriisivalmiutta, tällä kertaa onneksi kuitenkin melko turvallisessa tilanteessa.

Lähetimme asiasta tiedotteen asiakkaillemme tapaninpäivänä, ja paria ulkopuolista riippuvuutta lukuun ottamatta tilanne oli hoidettu ennen vuodenvaihdetta. Vaativa tehtävä, mutta myös hyvin opettavainen – niin sovellusten suunnitteluperiaatteiden (jaettujen salaisuuksien välttäminen, riippuvuuksien minimointi jne.) kuin operointikäytäntöjenkin (ajantasaiset kontaktiluettelot, dokumentoidut prosessit, selkeät vastuusuhteet) kannalta.

On äärimmäisen todennäköistä, että mitään vahinkoa ei kenellekään ehtinyt tapahtua. On toisaalta melko todennäköistä, että mitään vahinkoa ei olisi tapahtunut, vaikka mitään ei olisi tehtykään. Kannattiko urakka siis? Menetelmäharjoituksena kyllä. Toisaalta näyttää siltä, että valtaosa LastPassia käyttäneistä yrityksistä ei ole tähän vaihtourakkaan ruvennut, joten väkisin jää miettimään, olimmeko me tässä vain turhan varovaisia? Mutta tätähän tietoturva on: ikuista tanssia vainoharhaisuuden ja tuotannollisen tehokkuuden välillä.

Kiitokset kuvista: iMattSmart, ja tietysti Dall-E!