Miksi salasanaa pitäisi suojata, jos siitä voi luopua?

Ongelma, jota olemme tottuneet pitämään normaalina

Käytännössä lähes kaikissa verkkosovelluksissa on hallintapaneeli. Hallintapaneelissa on yleensä kirjautumisosoite, kirjautumislomake, käyttäjätunnus ja salasana.

Olemme tottuneet tähän rakenteeseen niin paljon, että olemme lähes lakanneet kysymästä itseltämme: pitääkö kaiken todella toimia juuri näin?

Kun sinulla on yksi verkkosivusto, ongelma ei tunnu merkittävältä. Luot vahvan salasanan, otat käyttöön kaksivaiheisen todennuksen, määrität kirjautumisyrityksille rajoitukset — ja jatkat työtäsi.

Mutta mitä tapahtuu, kun projekteja onkin kymmenen, kaksikymmentä tai kolmekymmentä?

Omassa tapauksessani kyse on DigiMeld-ekosysteemistä, johon kuuluu yli kolmekymmentä itsenäistä ohjelmistoprojektia. Jokaisella niistä on oma arkkitehtuurinsa, palvelinlogiikkansa ja hallintakäyttöliittymänsä.

Niinpä jokainen tarvitsee hallintakäyttöön tarkoitetun ratkaisun.

Käytin pitkään aivan tavanomaista lähestymistapaa: erillisiä hallintatunnuksia, vahvoja salasanoja ja niiden tallentamista selaimeen.

Se toimi.

Jossain vaiheessa aloin kuitenkin miettiä: miksi minun ylipäätään täytyy säilyttää niin monia hallintasalasanoja? Miksi minun pitää suojata palvelimien lisäksi myös itse välineet, joilla niihin pääsee käsiksi?

Voisiko tästä tarpeesta luopua?

Päädyin ajatukseen, josta myöhemmin tuli ratkaisuni perusta:

Ehkä ei pitäisi suojata jatkuvasti käytettävissä olevaa kirjautumisväylää, vaan itse oikeutta saada käyttöoikeus väliaikaisesti.

Entä jos tuttua kirjautumissivua ei olisikaan?

Päätin luopua projekteissani perinteisestä hallintakäyttöön tarkoitetusta tunnistautumismallista.

En vain piilottaa kirjautumislomaketta.

En vaihtaa osoitetta.

En korvata salasanaa vielä monimutkaisemmalla salasanalla.

Vaan poistaa tarpeen jatkuvasti olemassa olevalle salasanakirjautumiselle.

Hallintakäyttöliittymät eivät tietenkään kadonneet mihinkään. Niitä tarvitaan edelleen sovellusten hallintaan.

Käyttöoikeuden saamisen tapa muuttui.

Nyt yhdistettyjen projektien hallintapaneeleihin ei tarvitse kirjautua tallennetulla käyttäjätunnuksella ja salasanalla.

Sen sijaan käytän omaa MeldID-tunnistus- ja käyttöoikeuksien hallintajärjestelmääni.

Ajatus on yksinkertainen: hallintakäyttöoikeus myönnetään vain silloin, kun sitä todella tarvitaan, tietylle käyttäjälle ja tiettyyn projektiin.

Pelkkä käyttäjätilin olemassaolo ei myöskään tarkoita oikeutta avata hallintapaneelia.

Tämä oikeus on myönnettävä erikseen.

Käyttöoikeus, jota ei ollut olemassa vielä hetki sitten

Tämä on ehkä koko ajatuksen kiinnostavin osa.

Perinteisessä mallissa ylläpitäjällä on jatkuvasti käytössään kirjautumisvälineet. Hän voi käyttää niitä tänään, huomenna tai kuukauden päästä, niin kauan kuin ne ovat voimassa.

Päätin muuttaa tätä periaatetta.

Jatkuvien hallintatunnusten sijaan käytössä on väliaikainen mahdollisuus aloittaa kirjautuminen.

Se luodaan pyynnöstä luotetulla mobiililaitteella, sisältää kryptografisesti vahvan satunnaisen osan ja on voimassa vain rajoitetun ajan.

Pelkkä tällaisen väliaikaisen linkin hallussapito ei kuitenkaan tarkoita, että käyttäjä saisi käyttöoikeuden.

Tämä on olennainen seikka.

Oletetaan, että joku saa linkin haltuunsa jollain tavalla. Tavallisessa järjestelmässä, joka perustuu yksinomaan osoitteen salassa pitämiseen, tällainen vuoto voisi olla vakava ongelma.

Minun mallissani linkki ainoastaan mahdollistaa vahvistusmenettelyn aloittamisen.

Jatkaminen edellyttää erillistä hyväksyntää MeldID:n kautta luotetulla mobiililaitteella.

Ilman asianmukaista vahvistusta hallintaistuntoa ei luoda.

Siksi en pidä väliaikaista linkkiä salasanan korvikkeena, vaan yhtenä osana käyttöoikeuden myöntämismenettelyä.

Se, että tietää, mistä kirjautumista voi yrittää, ja se, että on oikeus kirjautua sisään, ovat aivan eri asioita.

Puhelimesta tulee käyttöoikeuksien hallintaväline

Tässä mallissa mobiililaitteella on huomattavasti tärkeämpi rooli kuin tavallisella kertakäyttöisten koodien generaattorilla.

Sitä käytetään hallintakäyttöoikeuteen liittyvien toimien vahvistamiseen.

Kun haluan avata hallintapaneelin, järjestelmä pyytää vahvistusta MeldID:n kautta.

Näen asianmukaisen pyynnön luotetulla laitteellani ja vahvistan toiminnon.

Vasta onnistuneen tarkistuksen jälkeen järjestelmä antaa luvan jatkaa kirjautumista.

Vahvistus liittyy tällöin tiettyyn toimintoon, ei vain siihen, että puhelimen lukitus on avattu.

Mobiilibiometria varmistaa käyttäjän paikallisesti, ja palvelinpuoli tarkistaa rekisteröidyltä laitteelta saadun kryptografisen vahvistuksen.

Tämän ansiosta ei tarvitse luottaa yksinomaan salasanaan tai ilmoitukseen siitä, että käyttäjä muka vahvisti kirjautumisen.

Tässä on vielä yksi etu: luotettuja laitteita voidaan hallita.

Jos laitetta ei enää pidä käyttää käyttöoikeuksien vahvistamiseen, sen luotettu asema voidaan peruuttaa.

Tämän jälkeen se ei enää toimi kyseisten toimien tunnistautumisvälineenä.

Yksi järjestelmä — monta itsenäistä projektia

Kun aloin kehittää tätä mekanismia, yksi tärkeimmistä tavoitteista oli säilyttää kunkin projektin itsenäisyys.

En halunnut yhdistää kaikkia hallintapaneeleita yhdeksi valtavaksi sovellukseksi.

Jokaisen DigiMeld-palvelun pitää edelleen hallita omaa logiikkaansa, asetuksiaan, käyttäjiään ja tietojaan.

Siksi erotin kaksi tehtävää toisistaan.

MeldID vastaa tunnistamisesta ja hallintakäyttöoikeuden myöntämisestä.

Itse projekti puolestaan vastaa omista hallintatoiminnoistaan ja voimassa olevien käyttöoikeuksien tarkistamisesta.

Näin syntyi keskitetty käyttöoikeuksien hallintamalli ilman, että itse sovelluksia tarvitsee keskittää.

Lisäksi oikeudet myönnetään erikseen.

Yhden projektin ylläpitäjä ei saa automaattisesti käyttöoikeutta muihin projekteihin vain siksi, että hänellä on MeldID-tili.

Kullekin hallintakokonaisuudelle voidaan määrittää oma hyväksyttyjen käyttäjien joukko.

Tavallisten käyttäjien oikeudet ja hallintavaltuudet pidetään erillään.

Tämä osoittautui erityisen käteväksi kymmenistä palveluista koostuvassa ekosysteemissä.

Miksi pidän väliaikaisesta käyttöoikeudesta pysyvää enemmän

Järjestelmään sisältyy myös yksi periaate, jonka otin siihen tietoisesti.

Hallintakäyttöoikeuden ei pidä säilyä loputtomiin.

Käyttöoikeus on voimassa rajoitetun ajan ja päättyy riippumatta siitä, jatkaako käyttäjä työskentelyä selaimessa.

Työn jatkaminen käyttöoikeuden umpeuduttua edellyttää uutta vahvistusmenettelyä.

Näin kerran tehty todennus ei muutu jatkuvasti voimassa olevaksi oikeudeksi.

Pelkkä aikaraja ei kuitenkaan riitä.

On tärkeää voida myös päättää jo myönnetty käyttöoikeus ennen sen määräajan päättymistä.

Siksi MeldID sisältää hallintaoikeuksien keskitetyn peruutustoiminnon.

Kun käyttöoikeus peruutetaan, yhdistetyt projektit saavat siitä tapahtuman ja mitätöivät siihen liittyvät hallintaistunnot.

Käyttöoikeuksien hallinta ei siis pääty siihen, kun käyttäjä on onnistuneesti kirjautunut sisään.

Mahdollisuus peruuttaa valtuudet on minulle vähintään yhtä tärkeä kuin mahdollisuus myöntää niitä.

Hajautetussa järjestelmässä on kuitenkin otettava huomioon tapahtumien välittymisviiveet, yksittäisten komponenttien tilapäinen käytettävyyskatko ja muut käytännön toimintaan liittyvät olosuhteet. Istuntojen voimassaolon rajoittaminen muodostaa lisärajan.

Mikä muuttui päivittäisessä työssä?

Ensinnäkin tallennettuihin hallintasalasanoihin ei enää tarvitse jatkuvasti turvautua.

Minun ei enää tarvitse säilyttää selaimessa tunnuksia jokaiseen yhdistettyyn hallintapaneeliin kirjautumista varten.

Sen sijaan hallitsen käyttöoikeuksia yhden mekanismin kautta.

Valitsen tarvittavan projektin, vahvistan käyttöoikeuden ja aloitan työskentelyn.

Kun hallintakäyttöoikeutta ei enää tarvita, sen voi peruuttaa.

Erityisen kätevää on se, ettei uuden projektin lisääminen edellytä koko hallintatodennusjärjestelmän suunnittelua uudelleen.

Riittää, että projekti yhdistetään olemassa olevaan malliin ja sille määritetään tarvittavat käyttöoikeudet.

Tämä ei tietenkään tarkoita, että kaikki tietoturvariskit olisivat kadonneet.

Myös väliaikaiset käyttöoikeudet, luotetut laitteet, palvelinistunnot ja keskitetty infrastruktuuri on suojattava.

Minun ei kuitenkaan enää tarvitse ratkaista samaa hallintasalasanojen hallintaan liittyvää ongelmaa erikseen jokaisessa sovelluksessa.

Ja juuri tämä oli yksi alkuperäisistä tavoitteistani.

Eikö tällaisia teknologioita ole jo olemassa?

Tietenkin on.

Salasanaton todennus, etuoikeutettujen käyttöoikeuksien hallinta, väliaikaiset oikeudet ja vahvistaminen luotetuilla laitteilla ovat olleet tietoturva-alalla tunnettuja jo pitkään.

Tällaisia lähestymistapoja käytetään Identity and Access Management- ja Privileged Access Management -järjestelmissä sekä Zero Trust -ajattelumalleissa.

En väitä keksineeni näitä periaatteita.

Tavoitteeni oli toinen.

Minun piti luoda oma, integroitu järjestelmä, joka ratkaisee DigiMeld-infrastruktuurin erityisiä ongelmia ja mahdollistaa hallintakäyttöoikeuksien hallinnan monissa itsenäisissä projekteissa.

Lopputuloksena yhdistin useita tunnettuja lähestymistapoja yhdeksi arkkitehtuuriksi, joka vastaa omia vaatimuksiani.

Uskon, ettei insinöörityön arvo välttämättä perustu täysin uuden teknologian keksimiseen.

Joskus kyse on siitä, että ongelma osataan muotoilla oikein ja siihen löydetään sopiva ratkaisu.

MeldID ei ole tarkoitettu vain hallintapaneeleihin

Tässä on syytä tehdä yksi erillinen täsmennys.

MeldID:tä ei luotu ainoastaan omaksi hallintakäyttövälineekseni.

Se tarjoaa kehittäjille myös SDK:n, jonka avulla tunnistus- ja kirjautumisen vahvistusmekanismit voi integroida omiin sovelluksiin.

SDK on saatavilla maksutta.

Esimerkiksi ulkopuolinen kehittäjä voi käyttää MeldID:tä käyttäjän tunnistautumisen lisävahvistuksena.

Vaikka sovelluksessa säilytettäisiin perinteinen käyttäjätunnukseen ja salasanaan perustuva kirjautuminen, näiden tietojen syöttäminen oikein ei välttämättä yksin riitä kirjautumisen viimeistelemiseen.

Käyttäjän luotettuun mobiililaitteeseen lähetetään pyyntö, jonka hän voi hyväksyä tai hylätä.

Tämä auttaa vähentämään luvattoman käytön riskiä, jos käyttäjätunnukset joutuvat vääriin käsiin.

On tärkeää erottaa tämä MeldID:n kaikille avoin ominaisuus DigiMeld-projekteihin kehittämästäni hallintakäyttömallista.

Ne perustuvat yhteisiin luottamuksen ja toimintojen vahvistamisen periaatteisiin, mutta ratkaisevat eri ongelmia.

Tietoturva ei tarkoita vain olemassa olevan suojaamista

Tämän järjestelmän kehittäminen sai minut tarkastelemaan tuttuja todennusmekanismeja uudesta näkökulmasta.

Yritämme usein suojata asioita, jotka ovat olemassa historiallisista syistä.

Lisäämme uusia tarkistuksia, rajoituksia, salasanoja ja suojakerroksia.

Joskus se on todella tarpeen.

Joskus on kuitenkin hyödyllisempää kysyä jotain muuta:

Onko suojattavan mekanismin todella oltava olemassa entisellään?

Omassa tapauksessani vastaus oli ei.

En tarvinnut jatkuvasti käytettävissä olevaa hallintakirjautumislomaketta.

Tarvitsin mahdollisuuden saada hallintavaltuudet turvallisesti juuri silloin, kun niitä tarvitaan.

Nämä ovat kaksi eri asiaa.

Siirtyminen ensimmäisestä jälkimmäiseen muutti paitsi teknistä arkkitehtuuria myös päivittäistä työskentelyäni projektien parissa.

Ei lopullinen päätepiste vaan valittu suunta

Tämä arkkitehtuuri on jo käytössä merkittävässä osassa DigiMeld-ekosysteemiä.

Loput projektit siirretään vähitellen uuteen hallintakäyttömalliin.

Toteutan siirtymän vaiheittain ja tarkistan jokaisen sovelluksen toiminnan. Kun siirtymä on valmis, suunnittelen järjestelmälle vielä lisäauditointia.

Käyttöliittymän yksittäiset osat ja istuntojen hallintaa koskevat säännöt voivat vielä muuttua.

Perusajatus on kuitenkin jo selvä.

En halua palata malliin, jossa minun on säilytettävä ja käytettävä jatkuvasti kymmeniä hallintasalasanoja kymmenien omien projektieni hallintaan.

En kuitenkaan pidä omaa toteutustani kaikille sopivana ratkaisuna.

Eri organisaatioilla on erilaiset vaatimukset, infrastruktuurit, uhkamallit ja hallintatavat.

Se, mikä on kätevää ja tarkoituksenmukaista DigiMeld-ekosysteemissä, ei välttämättä ole paras ratkaisu toiselle kehittäjälle.

Väliaikaisen käyttöoikeuden myöntämisen periaate ansaitsee silti huomiota.

Lopuksi

Päätin jakaa tämän kokemuksen, en siksi, että pitäisin itseäni uuden todennustavan keksijänä.

En myöskään siksi, että haluaisin esitellä jonkin järjestelmän täysin suojattuna.

Täydellistä tietoturvaa ei ole olemassa.

Minusta itse kysymyksenasettelu on vain kiinnostava.

Sen sijaan, että jatkuvasti suojaisimme pysyvää hallintakirjautumista, voimme arvioida uudelleen, onko sen oltava olemassa.

Monien salasanojen säilyttämisen sijaan voimme käyttää väliaikaisia käyttöoikeuksia.

Automaattisen luottamuksen sijaan ensimmäisen kirjautumisen jälkeen voimme vahvistaa tiettyjen valtuuksien myöntämisen erikseen.

Istunnon päättymisen odottamisen sijaan voimme ottaa käyttöön mahdollisuuden peruuttaa käyttöoikeus keskitetysti.

Ja lopuksi: jokaisen projektin erillisen kirjautumismekanismin sijaan voimme rakentaa yhtenäisen hallintakäyttöoikeuksien hallintajärjestelmän ja säilyttää sovellusten itsenäisyyden.

En väitä, että tällainen lähestymistapa poistaisi tietomurron mahdollisuuden.

Se vain siirtää painopisteen jatkuvasti olemassa olevien tunnistetietojen suojaamisesta valtuuksien hallittuun myöntämiseen ja peruuttamiseen.

Ehkä joskus tehokkain tapa pienentää hyökkäyspinta-alaa ei ole lisätä uutta suojamekanismia, vaan luopua jostakin, jota ilman järjestelmä pystyy aivan hyvin toimimaan.

Juuri tästä ajatuksesta MeldID Admin Gatewayn tarina alkoi minun kohdallani.