Miks kaitsta parooli, kui sellest võib loobuda?

Probleem, mida oleme harjunud normaalseks pidama

Praktiliselt igal veebirakendusel on halduspaneel. Halduspaneelil on aga tavaliselt sisselogimisleht, autentimisvorm, kasutajanimi ja parool.

Oleme selle ülesehitusega nii harjunud, et peaaegu enam ei küsi endalt: kas kõik peab tingimata just nii toimima?

Kui sul on üks veebisait, ei tundu probleem kuigi suur. Lood keeruka parooli, lülitad sisse kaheastmelise autentimise, seadistad sisselogimiskatsete piirangu ja töötad edasi.

Aga mis juhtub siis, kui projekte on kümme, kakskümmend või kolmkümmend?

Minu puhul on tegu DigiMeldi ökosüsteemiga, kuhu kuulub üle kolmekümne iseseisva tarkvaraprojekti. Igal neist on oma arhitektuur, serveriloogika ja haldusliides.

Seega vajab igaüks neist administraatoripääsu mehhanismi.

Pikka aega kasutasin üsna tavalist lähenemist: eraldi administraatori kasutajatunnused, keerukad paroolid ja nende salvestamine brauserisse.

See toimis.

Aga mingil hetkel hakkasin mõtlema: miks ma üldse pean nii palju administraatoriparoole talletama? Miks pean kaitsma mitte ainult servereid, vaid ka vahendeid, millega neile ligi pääseda?

Kas sellest vajadusest ei võiks loobuda?

Jõudsin mõtteni, millest sai hiljem minu lahenduse alus:

Võib-olla tuleks kaitsta mitte püsivat sisselogimisvõimalust, vaid õigust ajutiselt juurdepääs saada.

Aga mis siis, kui harjumuspärast sisselogimislehte polekski?

Otsustasin oma projektides traditsioonilisest administraatori autentimise mudelist loobuda.

Mitte lihtsalt sisselogimisvormi peita.

Mitte aadressi ümber nimetada.

Mitte asendada parooli veel keerukama parooliga.

Vaid loobuda vajadusest pidevalt olemasoleva paroolipõhise sisselogimise järele.

Loomulikult ei kadunud haldusliidesed kuhugi. Rakenduste haldamiseks on neid endiselt vaja.

Muutus viis, kuidas neile juurdepääs saadakse.

Nüüd ei ole ühendatud projektide halduspaneelidesse sisselogimiseks vaja sisestada salvestatud kasutajanime ja parooli.

Selle asemel kasutan enda identifitseerimis- ja juurdepääsuhaldussüsteemi MeldID.

Põhimõte on üsna lihtne: administraatoripääs antakse ainult siis, kui seda tõesti vaja on, konkreetsele kasutajale ja konkreetsele projektile.

See, et kasutajal on konto, ei tähenda veel, et tal on õigus halduspaneeli avada.

See õigus tuleb anda eraldi.

Juurdepääs, mida polnud minut tagasi olemas

See on ilmselt kogu kontseptsiooni kõige huvitavam osa.

Traditsioonilise mudeli puhul on administraatoril pidevalt olemas sisselogimisvahendid. Ta võib neid kasutada täna, homme või kuu aja pärast, kuni need kehtivad.

Otsustasin seda põhimõtet muuta.

Püsivate administraatori kasutajatunnuste asemel kasutatakse ajutist võimalust sisselogimine algatada.

See luuakse usaldatud mobiilseadme kaudu esitatud päringu alusel, sisaldab krüptograafiliselt tugevat juhuslikku komponenti ja kehtib piiratud aja.

Kuid isegi sellise ajutise lingi omamine ei tähenda iseenesest juurdepääsu saamist.

See on põhimõtteline asjaolu.

Oletame, et keegi saab lingi mingil viisil enda kätte. Süsteemis, mis tugineb ainult aadressi saladuses hoidmisele, võiks selline leke tekitada tõsise probleemi.

Minu mudelis võimaldab link üksnes kinnitamisprotsessi alustada.

Jätkamiseks on vaja eraldi luba MeldID usaldatud mobiilseadme kaudu.

Ilma vastava kinnituseta administraatoriseanssi ei looda.

Seepärast ei käsitle ma ajutist linki parooli asendusena, vaid ühe juurdepääsu andmise protseduuri osana.

Teadmine, kuhu pöörduda, ja õigus sisse pääseda on täiesti erinevad asjad.

Telefonist saab juurdepääsu haldamise tööriist

Selles mudelis on mobiilseadmel palju olulisem roll kui tavalisel ühekordsete koodide generaatoril.

Seda kasutatakse administraatoripääsuga seotud toimingute kinnitamiseks.

Kui soovin halduspaneeli avada, küsib süsteem MeldID kaudu kinnitust.

Näen usaldatud seadmes vastavat päringut ja kinnitan toimingu.

Alles pärast edukat kontrolli lubab süsteem sisselogimisprotsessiga jätkata.

Kinnitus on seotud konkreetse toiminguga, mitte lihtsalt sellega, et telefon on lukust lahti tehtud.

Mobiilne biomeetria kontrollib kasutajat seadmes kohapeal ning serveripool kontrollib registreeritud seadmelt saadud krüptograafilist kinnitust.

Selline lähenemine võimaldab mitte tugineda ainult paroolile või teatele, et kasutaja justkui kinnitas sisselogimise.

Siin ilmneb veel üks eelis: usaldatud seadmeid saab hallata.

Kui seadet ei tohiks enam juurdepääsu kinnitamiseks kasutada, saab selle usaldatud oleku tühistada.

Pärast seda ei saa seda enam vastavate toimingute autoriseerimiseks kasutada.

Üks süsteem, palju sõltumatuid projekte

Seda mehhanismi arendama asudes oli üks peamisi ülesandeid säilitada iga projekti iseseisvus.

Ma ei tahtnud kõiki halduspaneele üheks hiiglaslikuks rakenduseks liita.

Iga DigiMeldi teenus peab endiselt ise haldama oma loogikat, seadeid, kasutajaid ja andmeid.

Seepärast jagasin need kaks ülesannet lahku.

MeldID vastutab identifitseerimise ja administraatoripääsu andmise eest.

Projekt ise aga vastutab oma haldusfunktsioonide ja kehtivate õiguste kontrollimise eest.

Tulemuseks on tsentraliseeritud juurdepääsuhalduse mudel, ilma et rakendusi endid oleks vaja tsentraliseerida.

Lisaks antakse õigused eraldi.

Ühe projekti administraator ei saa automaatselt juurdepääsu teistele projektidele pelgalt seetõttu, et tal on MeldID konto.

Iga haldussuuna jaoks saab määrata eraldi kasutajad, kellele juurdepääs on lubatud.

Tavakasutajate õigused ja administraatori volitused on seejuures lahus.

Kümnetest teenustest koosneva ökosüsteemi puhul osutus see eriti mugavaks.

Miks eelistan ajutist juurdepääsu püsivale

Olen süsteemi teadlikult sisse ehitanud veel ühe põhimõtte.

Administraatoripääs ei tohiks jääda kehtima lõputult.

Luba kehtib piiratud aja ja aegub sõltumata sellest, kas kasutaja jätkab brauseris töötamist.

Töö jätkamiseks pärast loa kehtivusaja lõppu tuleb läbida uus kinnitamisprotsess.

Nii ei muutu kord tehtud autentimine püsivalt kehtivaks õiguseks.

Ainuüksi ajalimiidist aga ei piisa.

Tähtis on võimalus juba antud juurdepääs ennetähtaegselt lõpetada.

Seepärast on MeldID-s ette nähtud administraatoriõiguste tsentraliseeritud tühistamine.

Kui luba tühistatakse, saavad ühendatud projektid vastava sündmuse ja tühistavad sellega seotud administraatoriseansid.

Seega ei lõpe juurdepääsu haldamine hetkel, mil kasutaja edukalt sisse logib.

Võimalus volitused tühistada on minu jaoks vähemalt sama tähtis kui võimalus neid anda.

Hajussüsteem peab arvestama ka sündmuste edastamise viivituste, üksikute komponentide ajutise kättesaamatuse ja muude käitamisega seotud asjaoludega. Seansside kehtivusaja piirang on täiendav kaitsepiir.

Mis muutus igapäevatöös?

Eelkõige kadus vajadus salvestatud administraatoriparoolide poole pidevalt pöörduda.

Mul pole enam vaja hoida brauseris iga ühendatud halduspaneeli sisselogimisandmeid.

Selle asemel haldan õigusi ühe mehhanismi kaudu.

Valin vajaliku projekti, kinnitan juurdepääsu ja töötan.

Kui administraatoripääsu enam vaja pole, saab selle tühistada.

Eriti mugav on see, et uue projekti lisamisel pole vaja kogu administraatori autentimise süsteemi uuesti kavandada.

Piisab selle ühendamisest olemasoleva mudeliga ja vajalike õiguste määramisest.

Loomulikult ei tähenda see, et kõik turvariskid oleksid kadunud.

Ka ajutised load, usaldatud seadmed, serveriseansid ja keskne taristu vajavad kaitset.

Ent mul pole enam vaja lahendada iga rakenduse puhul eraldi sama ülesannet ehk hallata administraatoriparoole.

Ja see oligi üks minu algseid eesmärke.

Kas selliseid tehnoloogiaid pole juba olemas?

Muidugi on.

Paroolivaba autentimine, privilegeeritud juurdepääsu haldamine, ajutised load ja usaldatud seadme kaudu kinnitamine on infoturbe valdkonnas ammu tuntud.

Selliseid lähenemisi kasutatakse identiteedi- ja juurdepääsuhalduse (Identity and Access Management), privilegeeritud juurdepääsu halduse (Privileged Access Management) süsteemides ning Zero Trusti kontseptsioonis.

Ma ei väida, et olen need põhimõtted leiutanud.

Minu ülesanne oli teistsugune.

Mul oli vaja luua oma integreeritud süsteem, mis lahendaks DigiMeldi taristu konkreetsed probleemid ja võimaldaks hallata administraatoripääsu paljudele iseseisvatele projektidele.

Tulemusena ühendasin mitu tuntud lähenemist üheks minu nõuetele vastavaks arhitektuuriks.

Usun, et inseneritöö väärtus ei seisne tingimata täiesti uue tehnoloogia leiutamises.

Mõnikord seisneb see probleemi õiges sõnastamises ja sellele sobiva lahenduse leidmises.

MeldID pole mõeldud ainult halduspaneelide jaoks

Siinkohal on vaja teha üks eraldi täpsustus.

MeldID-d ei loodud ainult minu enda administraatoripääsu haldamiseks.

See pakub arendajatele ka SDK-d identifitseerimis- ja sisselogimise kinnitamise mehhanismide integreerimiseks nende enda rakendustesse.

Pealegi on selline SDK tasuta saadaval.

Näiteks saab kolmanda osapoole arendaja kasutada MeldID-d kasutaja autentimise täiendava kinnituskihina.

Isegi kui rakenduses säilib tavapärane kasutajanime ja parooliga sisselogimine, ei pruugi nende andmete edukast sisestamisest autentimise lõpetamiseks piisata.

Kasutaja usaldatud mobiilseadmesse saadetakse päring, mille kaudu saab ta sisselogimiskatse kinnitada või tagasi lükata.

See aitab vähendada volitamata juurdepääsu ohtu juhul, kui kasutaja andmed satuvad ohtu.

Oluline on eristada MeldID kõigile kättesaadavat võimalust DigiMeldi projektide jaoks loodud administraatoripääsu mudelist.

Need kasutavad samu usalduse ja toimingute kinnitamise põhimõtteid, kuid lahendavad erinevaid ülesandeid.

Turvalisus ei tähenda ainult olemasoleva kaitsmist

Töö selle süsteemiga pani mind harjumuspärastele autentimismehhanismidele teise pilguga vaatama.

Püüame sageli kaitsta midagi, mis on olemas ajaloolistel põhjustel.

Lisame uusi kontrolle, piiranguid, täiendavaid paroole ja kaitsekihte.

Mõnikord on see tõesti vajalik.

Aga mõnikord on kasulikum küsida hoopis midagi muud:

Kas kaitstav mehhanism peab tingimata endisel kujul olemas olema?

Minu puhul oli vastus eitav.

Mul polnud vaja pidevalt kättesaadavat administraatori sisselogimisvormi.

Mul oli vaja võimalust saada administraatoriõigused turvaliselt just siis, kui neid vaja on.

Need on kaks eri ülesannet.

Üleminek esimeselt teisele muutis nii tehnilist arhitektuuri kui ka igapäevast tööd projektidega.

Mitte lõplik punkt, vaid valitud suund

Tänaseks töötab see arhitektuur juba märkimisväärses osas DigiMeldi ökosüsteemist.

Ülejäänud projekte viiakse järk-järgult üle uuele administraatoripääsu mudelile.

Teen üleminekut järjest, kontrollides iga rakenduse tööd, ning pärast ülemineku lõppu kavatsen kogu süsteemi täiendavalt auditeerida.

Mõned kasutajaliidese elemendid ja seansihalduse reeglid võivad veel muutuda.

Kuid põhiidee on juba paigas.

Ma ei taha naasta mudeli juurde, kus kümnete enda projektide haldamiseks pean pidevalt talletama ja kasutama kümneid administraatoriparoole.

Samas ei pea ma enda lahendust kõigile sobivaks universaalseks lahenduseks.

Organisatsioonidel on erinevad nõuded, taristud, ohumudelid ja haldusviisid.

See, mis on DigiMeldi ökosüsteemi jaoks mugav ja põhjendatud, ei pruugi teisele arendajale kõige paremini sobida.

Ajutise volituste andmise põhimõte väärib aga tähelepanu.

Kokkuvõtteks

Otsustasin seda kogemust jagada mitte sellepärast, et peaksin end uue autentimisviisi leiutajaks.

Ja mitte sellepärast, et tahaksin esitleda mõnd süsteemi täiesti turvalisena.

Absoluutset turvalisust pole olemas.

Mulle tundub lihtsalt huvitav juba probleemi püstitus ise.

Pideva administraatori sisselogimisvõimaluse lõputu kaitsmise asemel võib selle olemasolu vajaduse uuesti läbi mõelda.

Paljude paroolide talletamise asemel saab kasutada ajutisi lube.

Pärast esimest autentimist automaatselt usaldamise asemel saab konkreetsete volituste andmise kinnitada.

Seansi lõppemise ootamise asemel saab ette näha võimaluse juurdepääs tsentraalselt tühistada.

Ja lõpuks: igas projektis eraldi sisselogimismehhanismi asemel saab luua ühtse administraatoripääsu haldussüsteemi, säilitades samal ajal rakenduste iseseisvuse.

Ma ei väida, et selline lähenemine välistaks kompromiteerimise võimaluse.

See lihtsalt suunab tähelepanu pidevalt olemasolevate kasutajaandmete kaitsmiselt volituste kontrollitud andmisele ja lõpetamisele.

Võib-olla on mõnikord kõige tõhusam viis ründepinda vähendada mitte järjekordse kaitsemehhanismi lisamine, vaid loobumine millestki, milleta süsteem saab suurepäraselt toimida.

Just sellest mõttest sai alguse MeldID Admin Gateway lugu.