Kirjoittaja: Veli-Pekka Vähälummukka, Trivoren Program Director
Montako kertaa olet miettinyt, mitä tapahtuu, jos Microsoft Entra ID tai Google Workspace päättää ottaa päiväunet? Ei siis käyttäjävirhe, ei väärä salasana, vaan tilanne, jossa koko julkipilvi-IdP on yksinkertaisesti poissa käytöstä.
Vastauksena on yleensä hiljainen myöntyminen: “No silloin ei töitä tehdä.”
Ja se on ongelma.
Ei siksi, etteivätkö nuo palvelut olisi hyviä. Ovat. Mutta kun koko yrityksen IT-ekosysteemi nojaa yhden identiteettipalvelun varaan, on rakennettu moderni toimistotalo, jonka ainoa sisäänkäynti on se yksi pääovi. Ja oven avain on jonkun muun taskussa.
Nämä tilanteet eivät ole teoreettisia. Microsoft Entra ID:llä on ollut useita merkittäviä käyttökatkoja viime vuosina, ja jokaisella kerralla tuhannet organisaatiot ovat jääneet odottamaan kädet taskussa. Heinäkuussa 2024 CrowdStrike-päivitys kaatoi 8,5 miljoonaa Windows-laitetta maailmanlaajuisesti ja osoitti, miten riippuvuus yhdestä toimijasta voi lamauttaa kokonaisia toimialoja. Kysymys ei siis ole jos, vaan milloin.
Eli mitä pitäisi tehdä?
Ehkä ajatus monella on, että luotetaan tuuriin ja paikataan vikaa kun se tulee. Sama logiikka, jolla ei hankita varavoimaa ennen kuin konesali sammuu ensimmäisen kerran.
Fiksumpi tapa on rakentaa kerroksellisuutta jo etukäteen. Kyllä, se tarkoittaa ylimääräistä työtä ja investointia. Mutta varajärjestelmän ylläpidon kustannus on ennakoitavissa. Täyden käyttökatkon kustannus ei ole, etenkin kun laskuun lisätään menetetty työaika, asiakaspalvelun pysähtyminen ja maineriski.
Paikallinen identiteettijärjestelmä rinnalle
Käytännössä tämä tarkoittaa, että et luota ainoastaan yhteen pilvi-IdP:hen. Rinnalle kannattaa nostaa paikallinen järjestelmä, joka pyörii omalla raudalla tai omassa yksityisessä pilviympäristössä.
Trivore ID on rakennettu juuri tähän tarpeeseen. Se tukee OIDC- ja SAML-protokollia, joten se toimii nykyisten sovellustesi kanssa sellaisenaan. Tarvittaessa se voi toimia ensisijaisena IdP:nä, jos pilvitoimittajan palvelu on nurin. Ja koska se pyörii omassa ympäristössäsi, päätösvalta pysyy sinulla, ei pilvitoimittajan tukijonossa.
Sen ei tarvitse olla kaiken kattava. Mutta kriittisimpien järjestelmien autentikointi pitää pystyä hoitamaan ilman, että soitetaan Microsoftille ja kysytään milloin palvelu palaa.
Break-glass -tunnukset kuntoon
Toinen konkreettinen asia on niin sanotut break-glass -tunnukset. Kuulostaa dramaattiselta, mutta on käytännössä yksinkertainen idea: tiukasti hallitut hätäkäyttäjät, jotka on tallennettu fyysisesti turvalliseen paikkaan, ja joilla pääsee ylläpitojärjestelmiin silloinkin, kun pilvi-MFA ei vastaa. Ei päivittäiseen käyttöön, mutta kriisitilanteessa arvokkaampi kuin Kari Mattssonin puhelinnumero.
Standardit ratkaisevat liikkumavaran
Jos sovelluksesi tukevat OIDC- tai SAML-protokollia oikein, sinulla on mahdollisuus vaihtaa IdP-toimittajaa ilman, että jokainen sovellus pitää konfiguroida alusta asti uusiksi. Se ei ole helppoa, mutta se on mahdollista. Ilman standardeja et edes teoriassa pysty vaihtamaan.
Tässä kohtaa kannattaa myös arvioida, tukevatko nykyiset järjestelmäsi näitä standardeja riittävän hyvin. Jos eivät, sekin on hyvä tietää ennen kriisiä, eikä sen jälkeen.
Prosessi paperille ennen kuin se tarvitaan
Tekninen ratkaisu ei kuitenkaan yksin riitä. Tarvitaan prosessi. Kirjallinen suunnitelma siitä, kuka tekee mitä ja millä tunnuksilla, kun normaalit autentikointiputket ovat poikki. Kuka ottaa vastuun, kuka viestii käyttäjille, missä järjestyksessä palvelut palautetaan?
Testaa skenaariota suljetussa ympäristössä ennen kuin saat opetella sen tuotannossa paineen alla. Harjoitus paljastaa aukot nopeammin kuin mikään dokumentti.
Suvereniteetti ei tarkoita eristäytymistä
Suvereniteetti ei tarkoita, että pitäisi rakentaa oma pilvi kellariin ja irti kaikesta. Se tarkoittaa kykyä operoida silloin, kun yhteys isoon pilveen on poikki. Sekin voi olla väliaikaisesti, mutta “väliaikaisesti” ei auta, jos kaikki pysähtyy heti ensimmäisellä sekunnilla.
Mieti siis: minkä tyyppiset järjestelmät teillä olisivat kriittisimpiä – ylläpitoyhteydet konesaliin vai loppukäyttäjien sovelluspääsy? Siitä se priorisointi kannattaa aloittaa.
Ja jos se pääovi joskus lukittuu, on hyvä tietää, että varasisäänkäynti on jo olemassa. Ja avain on omassa taskussa.
Haluatko arvioida oman organisaatiosi identiteetin varautumistason? Ota yhteyttä – katsotaan tilanne yhdessä.