Zakaj varovati geslo, če se mu lahko odpovemo?

Težava, ki smo jo navajeni imeti za nekaj običajnega

Skoraj vsaka spletna aplikacija ima skrbniško ploščo. Ta ima praviloma prijavni naslov, obrazec za prijavo, uporabniško ime in geslo.

Na to ureditev smo se tako navadili, da se skoraj ne sprašujemo več: ali mora vse res delovati prav tako?

Če imaš eno spletno mesto, se težava ne zdi bistvena. Ustvariš zapleteno geslo, vklopiš dvostopenjsko preverjanje pristnosti, nastaviš omejitev števila poskusov prijave — in delaš naprej.

A kaj se zgodi, ko imaš deset, dvajset ali trideset projektov?

V mojem primeru gre za ekosistem DigiMeld, ki združuje več kot trideset samostojnih programskih projektov. Vsak ima svojo arhitekturo, strežniško logiko in skrbniški vmesnik.

Vsak od njih torej potrebuje mehanizem za skrbniški dostop.

Dolgo sem uporabljal povsem običajen pristop: ločene skrbniške prijavne podatke, zapletena gesla in shranjevanje teh podatkov v brskalniku.

Delovalo je.

A v nekem trenutku sem se vprašal: zakaj moram sploh shranjevati toliko skrbniških gesel? Zakaj moram varovati ne le strežnikov, temveč tudi sama sredstva za dostop do njih?

Ali se tej potrebi ne bi bilo mogoče odpovedati?

Prišel sem do zamisli, ki je pozneje postala osnova moje rešitve:

Morda ne bi smeli varovati stalne vstopne točke, temveč samo pravico do začasnega dostopa.

Kakšno težavo odpravi zapleteno geslo?

Sodobna orodja omogočajo ustvarjanje gesel z zelo visoko entropijo. Pravilno ustvarjeno dolgo naključno geslo je praktično nemogoče uganiti z neposrednim preizkušanjem vseh možnosti.

A ne glede na to, kako zapleteno je geslo, ga je treba nekje shraniti in ga nato uporabiti.

Uporabljamo lahko upravljalnike gesel, strojne ključe, večfaktorsko preverjanje pristnosti in dodatne omejitve. Vse to res izboljša varnost.

A arhitekturna zasnova ostaja enaka: obstaja vmesnik, prek katerega uporabnik posreduje svoje prijavne podatke.

Nanj je mogoče pošiljati zahteve. Mogoče ga je pregledovati. Lahko postane tarča avtomatiziranih napadov.

Skrbniško ploščo lahko skrijemo, privzeto pot zamenjamo z dolgim naključnim zaporedjem znakov ali omejimo dostop na določene naslove IP.

A tedaj se pojavi novo vprašanje: kje shraniti ta naslov in kako ga uporabljati?

In predvsem: zakaj ohranjati stalno vstopno točko, če je skrbniški dostop potreben le občasno?

Prišel sem do zamisli, ki je pozneje postala osnova moje rešitve:

Morda bi morali varovati ne stalno vstopno točko, temveč samo pravico do začasnega dostopa.

Kaj pa, če običajne prijavne strani sploh ne bi bilo?

V svojih projektih sem se odločil opustiti tradicionalni model skrbniškega preverjanja pristnosti.

Ne zgolj skriti prijavnega obrazca.

Ne preimenovati naslova.

Ne zamenjati gesla z še bolj zapletenim geslom.

Odpraviti samo potrebo po stalnem prijavljanju z geslom.

Seveda skrbniški vmesniki niso izginili. Še vedno so potrebni za upravljanje aplikacij.

Spremenil pa se je način pridobitve dostopa do njih.

Za prijavo v skrbniške plošče povezanih projektov zdaj ni treba vnesti shranjenega uporabniškega imena in gesla.

Namesto tega uporabljam lasten sistem za identifikacijo in upravljanje dostopa MeldID.

Načelo je precej preprosto: skrbniški dostop se dodeli samo takrat, ko je res potreben, določenemu uporabniku in za določen projekt.

Samo dejstvo, da ima nekdo uporabniški račun, še ne pomeni, da lahko odpre skrbniško ploščo.

To pravico je treba dodeliti posebej.

Dostop, ki ga še minuto prej ni bilo

To je verjetno najzanimivejši del celotne zamisli.

V tradicionalnem modelu ima skrbnik sredstva za prijavo na voljo ves čas. Uporablja jih lahko danes, jutri ali čez mesec dni, dokler so ta sredstva veljavna.

Odločil sem se spremeniti to načelo.

Namesto stalnih skrbniških prijavnih podatkov se uporablja začasna možnost začetka postopka prijave.

Ustvari se na zahtevo prek zaupanja vredne mobilne naprave, vsebuje kriptografsko varno naključno komponento in je veljavna le omejen čas.

A tudi sama začasna povezava še ne pomeni, da je dostop odobren.

To je bistveno.

Recimo, da nekdo nekako pridobi povezavo. V običajnem sistemu, ki temelji izključno na skrivnosti naslova, bi lahko takšno razkritje pomenilo resno težavo.

V mojem modelu povezava omogoča le začetek postopka potrditve.

Za nadaljevanje je potrebno ločeno dovoljenje prek zaupanja vredne mobilne naprave MeldID.

Brez ustrezne potrditve se skrbniška seja ne ustvari.

Zato začasne povezave ne obravnavam kot nadomestila za geslo, temveč kot enega od elementov postopka dodelitve dostopa.

Vedeti, kam se obrniti, in imeti pravico do prijave sta dve povsem različni stvari.

Telefon postane orodje za upravljanje dostopa

V tem modelu ima mobilna naprava precej pomembnejšo vlogo kot običajni generator enkratnih kod.

Uporablja se za potrjevanje dejanj, povezanih s skrbniškim dostopom.

Ko želim odpreti skrbniško ploščo, sistem zahteva potrditev prek MeldID.

Na zaupanja vredni napravi vidim ustrezno zahtevo in potrdim dejanje.

Šele po uspešnem preverjanju sistem dovoli nadaljevanje postopka prijave.

Potrditev je povezana s konkretnim dejanjem, ne zgolj z dejstvom, da je bil telefon odklenjen.

Biometrično preverjanje na mobilni napravi lokalno preveri uporabnika, strežniška stran pa preveri kriptografsko potrditev registrirane naprave.

Tak pristop omogoča, da se ne zanašamo izključno na geslo ali na sporočilo, da naj bi uporabnik potrdil prijavo.

Tu se pokaže še ena prednost: zaupanja vredne naprave je mogoče upravljati.

Če naprave ne bi smeli več uporabljati za potrjevanje dostopa, ji lahko prekličemo status zaupanja vredne naprave.

Nato ne more več služiti kot veljavno sredstvo za preverjanje pristnosti pri zadevnih dejanjih.

En sistem — številni neodvisni projekti

Ko sem začel razvijati ta mehanizem, je bila ena glavnih nalog ohraniti samostojnost vsakega projekta.

Nisem želel združiti vseh skrbniških plošč v eno ogromno aplikacijo.

Vsaka storitev DigiMeld bi morala še naprej upravljati lastno logiko, nastavitve, uporabnike in podatke.

Zato sem ločil dve nalogi.

MeldID skrbi za identifikacijo in dodeljevanje skrbniških pooblastil.

Sam projekt pa skrbi za lastne skrbniške funkcije in preverjanje veljavnih pooblastil.

Tako je nastal centraliziran model upravljanja dostopa, ne da bi bilo treba centralizirati same aplikacije.

Poleg tega se pravice dodeljujejo ločeno.

Skrbnik enega projekta ne pridobi samodejno dostopa do drugih projektov zgolj zato, ker ima račun MeldID.

Za vsako skrbniško področje je mogoče določiti svoj krog pooblaščenih uporabnikov.

Pravice običajnih uporabnikov in skrbniška pooblastila so pri tem ločeni.

To se je izkazalo za posebej priročno pri ekosistemu z več deset storitvami.

Zakaj mi je začasni dostop ljubši od stalnega

V sistem sem namenoma vključil še eno načelo.

Skrbniški dostop ne bi smel ostati veljaven v nedogled.

Dovoljenje velja omejen čas in preneha veljati ne glede na to, ali uporabnik še naprej uporablja brskalnik.

Za nadaljevanje dela po izteku veljavnosti je potreben nov postopek potrditve.

Tako enkrat opravljena prijava ne postane pravica, ki velja za vedno.

A časovna omejitev sama po sebi ni dovolj.

Pomembno je, da je mogoče že dodeljeni dostop prekiniti predčasno.

Zato MeldID omogoča centraliziran preklic skrbniških dovoljenj.

Ko dovoljenje prekličemo, povezani projekti prejmejo ustrezen dogodek in razveljavijo povezane skrbniške seje.

Upravljanje dostopa se torej ne konča v trenutku, ko se uporabnik uspešno prijavi.

Možnost preklica pooblastil se mi zdi enako pomembna kot možnost njihove dodelitve.

Porazdeljeni sistem mora pri tem upoštevati zamude pri prenosu dogodkov, začasno nedosegljivost posameznih komponent in druge okoliščine delovanja. Omejena veljavnost sej predstavlja dodatno varovalko.

Kaj se je spremenilo pri vsakdanjem delu?

Predvsem mi ni več treba posegati po shranjenih skrbniških geslih.

V brskalniku mi ni več treba hraniti zbirke prijavnih podatkov za vsako povezano skrbniško ploščo posebej.

Namesto tega dovoljenja upravljam prek enotnega mehanizma.

Izberem želeni projekt, potrdim dostop in delam.

Ko skrbniškega dostopa ne potrebujem več, ga lahko prekličem.

Posebej priročno je, da ob pojavu novega projekta ni treba znova načrtovati celotnega sistema skrbniškega preverjanja pristnosti.

Dovolj je, da ga povežem z obstoječim modelom in določim potrebna dovoljenja.

Seveda to ne pomeni, da so izginila vsa varnostna tveganja.

Začasna dovoljenja, zaupanja vredne naprave, strežniške seje in centralna infrastruktura prav tako potrebujejo zaščito.

A ni mi več treba za vsako aplikacijo posebej reševati iste težave z upravljanjem skrbniških gesel.

To je bil eden od mojih prvotnih ciljev.

Ali takšne tehnologije že ne obstajajo?

Seveda obstajajo.

Preverjanje pristnosti brez gesla, upravljanje privilegiranega dostopa, začasna dovoljenja in potrjevanje prek zaupanja vrednih naprav so v panogi informacijske varnosti znani že dolgo.

Takšne pristope najdemo v sistemih za upravljanje identitet in dostopa (Identity and Access Management), upravljanje privilegiranega dostopa (Privileged Access Management) ter v konceptih Zero Trust.

Ne trdim, da sem si izmislil ta načela.

Moja naloga je bila drugačna.

Ustvariti sem moral lasten integriran sistem, ki rešuje konkretne težave infrastrukture DigiMeld in omogoča upravljanje skrbniškega dostopa do številnih samostojnih projektov.

Na koncu sem združil več znanih pristopov v eno arhitekturo, prilagojeno mojim zahtevam.

Menim, da vrednost inženirskega dela ni nujno v izumu povsem nove tehnologije.

Včasih je v tem, da pravilno opredelimo težavo in zanjo poiščemo ustrezno rešitev.

MeldID ni namenjen samo skrbniškim ploščam

Tu velja dodati še posebno pojasnilo.

MeldID ni bil ustvarjen izključno kot orodje za moj lastni skrbniški dostop.

Razvijalcem ponuja tudi SDK za vključitev mehanizmov identifikacije in potrjevanja prijave v njihove aplikacije.

Ta SDK je na voljo brezplačno.

Zunanji razvijalec lahko na primer uporabi MeldID kot dodatno raven potrditve uporabniške prijave.

Tudi če aplikacija ohrani tradicionalno prijavo z uporabniškim imenom in geslom, za dokončanje prijave morda ne bo dovolj, da uporabnik te podatke vnese pravilno.

Na zaupanja vredno mobilno napravo prejme zahtevo, kjer poskus prijave potrdi ali zavrne.

To pomaga zmanjšati tveganje nepooblaščenega dostopa v primeru kompromitacije prijavnih podatkov.

Pomembno je razlikovati med to javno dostopno možnostjo MeldID in modelom skrbniškega dostopa za projekte DigiMeld, ki sem ga razvil sam.

Temeljita na skupnih načelih zaupanja in potrjevanja dejanj, vendar rešujeta različne naloge.

Varnost ne pomeni le zaščite obstoječega

Delo na tem sistemu me je spodbudilo, da sem na uveljavljene mehanizme preverjanja pristnosti pogledal drugače.

Pogosto poskušamo zavarovati nekaj, kar obstaja iz zgodovinskih razlogov.

Dodajamo nova preverjanja, omejitve, dodatna gesla in varnostne plasti.

Včasih je to res potrebno.

A včasih si je koristneje zastaviti drugo vprašanje:

Ali mora mehanizem, ki ga varujemo, nujno še naprej obstajati v svoji dosedanji obliki?

V mojem primeru je bil odgovor ne.

Nisem potreboval stalno dostopnega obrazca za skrbniško prijavo.

Potreboval sem možnost varne pridobitve skrbniških pooblastil natanko takrat, ko jih potrebujem.

To sta dve različni nalogi.

Prehod od prve k drugi je spremenil ne le tehnično arhitekturo, temveč tudi vsakodnevno delo s projekti.

Ne končna točka, temveč izbrana smer

Ta arhitektura danes že deluje v precejšnjem delu ekosistema DigiMeld.

Preostale projekte postopoma prenašam na novi model skrbniškega dostopa.

Migracijo izvajam po korakih, preverjam delovanje vsake aplikacije, po končanem prehodu pa načrtujem še dodatno revizijo celotnega sistema.

Posamezni elementi vmesnika in pravila za upravljanje sej se lahko še spremenijo.

Osnovna zamisel pa je že določena.

Ne želim se vrniti k modelu, v katerem moram za upravljanje več deset lastnih projektov stalno hraniti in uporabljati več deset skrbniških gesel.

Ob tem lastne izvedbe ne štejem za univerzalno rešitev za vsakogar.

Različne organizacije imajo različne zahteve, infrastrukturo, modele groženj in načine upravljanja.

Kar je priročno in smiselno za ekosistem DigiMeld, ni nujno najboljša izbira za drugega razvijalca.

Vseeno pa si načelo začasnega dodeljevanja pooblastil zasluži pozornost.

Namesto zaključka

Odločil sem se, da to izkušnjo delim ne zato, ker bi se imel za izumitelja novega načina preverjanja pristnosti.

Prav tako ne zato, ker bi želel predstaviti še en sistem kot povsem varen.

Absolutna varnost ne obstaja.

Zanimiv se mi zdi že sam način zastavitve vprašanja.

Namesto da nenehno varujemo stalni skrbniški dostop, lahko premislimo, ali mora sploh obstajati.

Namesto shranjevanja številnih gesel lahko uporabljamo začasna dovoljenja.

Namesto samodejnega zaupanja po prvi prijavi lahko potrjujemo dodelitev konkretnih pooblastil.

Namesto čakanja na konec seje lahko omogočimo centraliziran preklic dostopa.

In namesto ločenega mehanizma za prijavo v vsakem projektu lahko vzpostavimo enoten sistem za upravljanje skrbniških pooblastil, pri tem pa ohranimo samostojnost aplikacij.

Ne trdim, da tak pristop izključuje možnost kompromitacije.

Težišče preprosto premakne z varovanja stalno obstoječih prijavnih podatkov na nadzorovano dodeljevanje in preklic pooblastil.

Morda je včasih najučinkovitejši način za zmanjšanje napadalne površine ta, da ne dodamo še enega varnostnega mehanizma, temveč opustimo nekaj, brez česar lahko sistem povsem dobro deluje.

S to mislijo se je zame začela zgodba MeldID Admin Gateway.