Zašto štititi lozinku ako možemo da je se odreknemo?

Problem koji smo navikli da smatramo normalnim

Praktično svaka veb-aplikacija ima administratorski panel. A administratorski panel po pravilu ima adresu za prijavu, obrazac za autentifikaciju, korisničko ime i lozinku.

Toliko smo se navikli na takvu postavku da smo praktično prestali da se pitamo: da li sve zaista mora da funkcioniše baš tako?

Kada imate jedan sajt, problem ne deluje naročito značajno. Napravite složenu lozinku, uključite dvofaktorsku autentifikaciju, podesite ograničenje broja pokušaja prijave — i nastavite sa radom.

Ali šta se dešava kada projekata postane deset, dvadeset ili trideset?

U mom slučaju reč je o ekosistemu DigiMeld, koji objedinjuje više od trideset samostalnih softverskih projekata. Svaki ima sopstvenu arhitekturu, serversku logiku i administrativni interfejs.

Shodno tome, svakom je potreban mehanizam za administrativni pristup.

Dugo sam koristio sasvim uobičajen pristup: zasebne administratorske naloge, složene lozinke i njihovo čuvanje u pregledaču.

To je funkcionisalo.

Ali u jednom trenutku sam se zapitao: zašto uopšte moram da čuvam toliko administratorskih lozinki? Zašto moram da štitim ne samo servere već i sama sredstva za pristup njima?

I da li mogu da se odreknem te potrebe?

Došao sam do ideje koja je kasnije postala osnova mog rešenja:

Možda treba štititi ne stalnu prijavu, već samo pravo na privremeni pristup.

A šta ako uobičajena stranica za prijavu uopšte ne postoji?

Odlučio sam da u svojim projektima napustim tradicionalni model administrativne autentifikacije.

Ne samo da sakrijem obrazac za prijavu.

Ne da promenim adresu.

Ne da zamenim lozinku još složenijom lozinkom.

Već da uklonim samu potrebu za stalno dostupnom prijavom putem lozinke.

Naravno, administrativni interfejsi nisu nestali. I dalje su neophodni za upravljanje aplikacijama.

Promenio se način na koji im se pristupa.

Sada za prijavu na administrativne panele povezanih projekata nije potrebno unositi sačuvano korisničko ime i lozinku.

Umesto toga koristim sopstveni sistem za identifikaciju i upravljanje pristupom, MeldID.

Suština je prilično jednostavna: administrativni pristup se odobrava samo kada je zaista potreban, konkretnom korisniku i za konkretan projekat.

Štaviše, samo postojanje korisničkog naloga još ne znači i pravo na otvaranje administrativnog panela.

To pravo mora da se dodeli zasebno.

Pristup koji nije postojao pre minut

To je, verovatno, najzanimljiviji deo čitavog koncepta.

U tradicionalnom modelu administrator stalno ima sredstva za prijavu. Može da ih koristi danas, sutra ili za mesec dana, sve dok ta sredstva važe.

Odlučio sam da promenim taj princip.

Umesto trajnih administratorskih podataka za prijavu koristi se privremena mogućnost pokretanja prijave.

Ona se kreira na zahtev preko pouzdanog mobilnog uređaja, sadrži kriptografski bezbednu nasumičnu komponentu i ima ograničeno vreme važenja.

Ali čak ni posedovanje takve privremene veze samo po sebi ne znači da je pristup odobren.

To je suštinski važno.

Recimo da je neko nekako došao do veze. U običnom sistemu zasnovanom isključivo na tajnosti adrese, takvo curenje moglo bi da predstavlja ozbiljan problem.

U mom modelu veza samo omogućava da se započne postupak potvrde.

Za nastavak je potrebno zasebno odobrenje preko pouzdanog mobilnog uređaja MeldID.

Bez odgovarajuće potvrde ne kreira se administrativna sesija.

Zato privremenu vezu ne smatram zamenom za lozinku, već jednim od elemenata postupka odobravanja pristupa.

Znati gde se obratiti i imati pravo na prijavu dve su sasvim različite stvari.

Telefon postaje alat za upravljanje pristupom

U ovom modelu mobilni uređaj ima mnogo važniju ulogu od običnog generatora jednokratnih kodova.

Koristi se za potvrđivanje radnji povezanih s administrativnim pristupom.

Kada želim da otvorim administrativni panel, sistem traži potvrdu preko MeldID-a.

Na pouzdanom uređaju vidim odgovarajući zahtev i potvrđujem radnju.

Tek nakon uspešne provere sistem dozvoljava da se nastavi postupak prijave.

Pri tome je potvrda povezana s konkretnom radnjom, a ne samo s činjenicom da je telefon otključan.

Mobilna biometrija omogućava lokalnu proveru korisnika, dok serverska strana proverava kriptografsku potvrdu registrovanog uređaja.

Takav pristup omogućava da se ne oslanjamo isključivo na lozinku ili poruku da je korisnik navodno potvrdio prijavu.

Ovde se javlja još jedna prednost: pouzdanim uređajima može da se upravlja.

Ako neki uređaj više ne treba koristiti za potvrđivanje pristupa, njegov status pouzdanog uređaja može da se opozove.

Nakon toga on prestaje da bude važeće sredstvo za autorizaciju odgovarajućih operacija.

Jedan sistem — mnoštvo nezavisnih projekata

Kada sam počeo da razvijam ovaj mehanizam, jedan od glavnih zadataka bio je da se očuva samostalnost svakog projekta.

Nisam želeo da objedinim sve administrativne panele u jednu ogromnu aplikaciju.

Svaki servis DigiMeld i dalje treba da upravlja sopstvenom logikom, podešavanjima, korisnicima i podacima.

Zato sam razdvojio ta dva zadatka.

MeldID je zadužen za identifikaciju i odobravanje administrativnog pristupa.

A sam projekat je zadužen za sopstvene administrativne funkcije i proveru važećih ovlašćenja.

Tako je nastao centralizovan model upravljanja pristupom, bez potrebe da se centralizuju same aplikacije.

Pored toga, prava se dodeljuju zasebno.

Administrator jednog projekta ne dobija automatski pristup ostalim projektima samo zato što ima MeldID nalog.

Za svaki administrativni domen može da se odredi poseban krug ovlašćenih korisnika.

Pritom prava običnih korisnika i administrativna ovlašćenja ostaju razdvojena.

To se pokazalo posebno praktičnim za ekosistem sa desetinama servisa.

Zašto mi se privremeni pristup dopada više od trajnog

Postoji još jedan princip koji sam svesno ugradio u sistem.

Administrativni pristup ne treba da traje beskonačno.

Odobrenje važi ograničeno vreme i prestaje da važi bez obzira na to da li korisnik i dalje radi u pregledaču.

Da bi se rad nastavio nakon isteka tog roka, potreban je novi postupak potvrde.

Time se sprečava da jednom obavljena autentifikacija postane trajno važeće pravo.

Međutim, vremensko ograničenje samo po sebi nije dovoljno.

Važna je mogućnost da se već odobreni pristup prekine pre isteka.

Zato MeldID omogućava centralizovano opozivanje administrativnih odobrenja.

Kada se odobrenje opozove, povezani projekti dobijaju odgovarajući događaj i poništavaju povezane administrativne sesije.

Na taj način se upravljanje pristupom ne završava u trenutku kada se korisnik uspešno prijavi.

Mogućnost opozivanja ovlašćenja za mene je podjednako važna kao i mogućnost njihovog dodeljivanja.

Pritom distribuirani sistem mora da uzme u obzir kašnjenja u prenosu događaja, privremenu nedostupnost pojedinih komponenti i druge operativne okolnosti. Ograničenje trajanja sesija predstavlja dodatnu zaštitnu granicu.

Šta se promenilo u svakodnevnom radu?

Pre svega, više nema potrebe da stalno koristim sačuvane administratorske lozinke.

Više ne moram da čuvam u pregledaču skup podataka za prijavu na svaki povezani administrativni panel.

Umesto toga, dozvolama upravljam pomoću jedinstvenog mehanizma.

Izaberem željeni projekat, potvrdim pristup i radim.

Kada administrativni pristup više nije potreban, mogu da ga opozovem.

Posebno je praktično to što se, kada se pojavi novi projekat, ne mora iznova osmišljavati čitav sistem administrativne autentifikacije.

Dovoljno je povezati ga s postojećim modelom i odrediti potrebne dozvole.

Naravno, to ne znači da su svi bezbednosni rizici nestali.

Privremena odobrenja, pouzdani uređaji, serverske sesije i centralna infrastruktura takođe zahtevaju zaštitu.

Ali više ne moram da rešavam isti problem upravljanja administratorskim lozinkama zasebno za svaku aplikaciju.

I upravo je to bio jedan od mojih prvobitnih ciljeva.

Zar slične tehnologije već ne postoje?

Naravno da postoje.

Autentifikacija bez lozinke, upravljanje privilegovanim pristupom, privremena odobrenja i potvrđivanje preko pouzdanih uređaja odavno su poznati u industriji informacione bezbednosti.

Takvi pristupi se sreću u sistemima Identity and Access Management, Privileged Access Management i konceptima Zero Trust.

Ne tvrdim da sam izmislio te principe.

Moj zadatak je bio drugačiji.

Bilo mi je potrebno da napravim sopstveni integrisani sistem koji rešava konkretne probleme infrastrukture DigiMeld i omogućava upravljanje administrativnim pristupom mnoštvu samostalnih projekata.

Na kraju sam objedinio nekoliko poznatih pristupa u jednu arhitekturu koja odgovara mojim zahtevima.

Smatram da vrednost inženjerskog rada ne mora nužno da leži u izmišljanju potpuno nove tehnologije.

Ponekad se ogleda u tome da se problem pravilno definiše i pronađe odgovarajuće rešenje.

MeldID nije namenjen samo administratorskim panelima

Ovde treba dodati posebno pojašnjenje.

MeldID nije napravljen isključivo kao alat za moj lični administratorski pristup.

On programerima pruža i SDK za integraciju mehanizama identifikacije i potvrđivanja prijave u njihove aplikacije.

Štaviše, takav SDK je dostupan besplatno.

Na primer, drugi programer može da koristi MeldID kao dodatni nivo potvrde korisničke autentifikacije.

Čak i ako aplikacija zadrži tradicionalnu prijavu korisničkim imenom i lozinkom, uspešan unos tih podataka možda neće biti dovoljan za dovršetak autentifikacije.

Korisniku stiže zahtev na pouzdan mobilni uređaj, gde može da potvrdi ili odbije pokušaj prijave.

To omogućava smanjenje rizika od neovlašćenog pristupa u slučaju kompromitovanja podataka za prijavu.

Važno je razlikovati ovu javno dostupnu mogućnost MeldID-a od modela administrativnog pristupa za projekte DigiMeld koji sam razvio.

Oni koriste zajedničke principe poverenja i potvrđivanja radnji, ali rešavaju različite zadatke.

Bezbednost nije samo zaštita onoga što već postoji

Rad na ovom sistemu naterao me je da drugačije sagledam uobičajene mehanizme autentifikacije.

Često pokušavamo da zaštitimo ono što postoji iz istorijskih razloga.

Dodajemo nove provere, ograničenja, dodatne lozinke i slojeve zaštite.

Ponekad je to zaista neophodno.

Ali ponekad je korisnije postaviti drugo pitanje:

Da li mehanizam koji štitimo zaista mora da postoji u dosadašnjem obliku?

U mom slučaju odgovor je bio odričan.

Nije mi bio potreban stalno dostupan obrazac za administrativnu prijavu.

Bila mi je potrebna mogućnost da bezbedno dobijem administrativna ovlašćenja upravo onda kada su potrebna.

To su dva različita zadatka.

Prelazak s prvog na drugi promenio je ne samo tehničku arhitekturu već i svakodnevni rad na projektima.

Ne konačna tačka, već pravac koji sam izabrao

Danas ova arhitektura već funkcioniše u značajnom delu ekosistema DigiMeld.

Preostali projekti se postepeno prebacuju na novi model administrativnog pristupa.

Migraciju sprovodim postepeno, proveravajući rad svake aplikacije, a nakon završetka prelaska planiram dodatnu reviziju čitavog sistema.

Pojedini elementi interfejsa i pravila za upravljanje sesijama još mogu da se menjaju.

Ali osnovna ideja je već definisana.

Ne želim da se vratim modelu u kojem moram stalno da čuvam i koristim desetine administratorskih lozinki da bih upravljao desetinama sopstvenih projekata.

Pritom ne smatram da je moje rešenje univerzalno za svakoga.

Različite organizacije imaju različite zahteve, infrastrukturu, modele pretnji i načine administriranja.

Ono što je praktično i opravdano za ekosistem DigiMeld ne mora nužno biti optimalno za drugog programera.

Ipak, princip privremenog dodeljivanja ovlašćenja zaslužuje pažnju.

Umesto zaključka

Odlučio sam da podelim ovo iskustvo ne zato što sebe smatram izumiteljem novog načina autentifikacije.

Niti zato što želim da predstavim još jedan sistem kao apsolutno bezbedan.

Apsolutna bezbednost ne postoji.

Jednostavno mi je zanimljivo samo postavljanje pitanja.

Umesto da beskonačno štitimo stalni administrativni pristup, možemo da preispitamo potrebu za njegovim postojanjem.

Umesto čuvanja mnoštva lozinki — koristimo privremena odobrenja.

Umesto automatskog poverenja nakon prve autentifikacije — potvrđujemo dodelu konkretnih ovlašćenja.

Umesto čekanja da sesija istekne — predviđamo mogućnost centralizovanog opozivanja pristupa.

I, konačno, umesto zasebnog mehanizma za prijavu u svakom projektu — gradimo jedinstven sistem za upravljanje administrativnim pristupom, a aplikacije zadržavaju samostalnost.

Ne tvrdim da takav pristup isključuje mogućnost kompromitovanja.

On samo premešta težište sa zaštite stalno postojećih podataka za prijavu na kontrolisano dodeljivanje i ukidanje ovlašćenja.

Možda je ponekad najefikasniji način da se smanji površina za napad ne dodavanje još jednog zaštitnog mehanizma, već odustajanje od onoga bez čega sistem sasvim može da funkcioniše.

Upravo tom mišlju za mene je počela priča o MeldID Admin Gateway-u.