Zašto štititi lozinku ako je se možemo odreći?

Problem koji smo navikli smatrati normalnim

Gotovo svaka web-aplikacija ima administratorsko sučelje. A administratorsko sučelje u pravilu ima adresu za prijavu, obrazac za autentifikaciju, korisničko ime i lozinku.

Toliko smo se navikli na takav model da se gotovo više i ne pitamo: mora li sve doista funkcionirati baš tako?

Kada imaš jednu web-stranicu, problem se ne čini značajnim. Stvoriš složenu lozinku, uključiš dvofaktorsku autentifikaciju, postaviš ograničenje broja pokušaja prijave — i nastaviš raditi.

Ali što se događa kada projekata postane deset, dvadeset ili trideset?

U mom je slučaju riječ o ekosustavu DigiMeld, koji objedinjuje više od trideset samostalnih softverskih projekata. Svaki ima vlastitu arhitekturu, poslužiteljsku logiku i administrativno sučelje.

Stoga je svakom potreban mehanizam za administrativni pristup.

Dugo sam se služio sasvim uobičajenim pristupom: zasebnim administratorskim vjerodajnicama, složenim lozinkama i njihovim spremanjem u preglednik.

To je funkcioniralo.

No u jednom sam se trenutku zapitao: zašto uopće moram čuvati toliko administratorskih lozinki? Zašto moram štititi ne samo poslužitelje nego i sama sredstva kojima im pristupam?

I mogu li se odreći te potrebe?

Došao sam do ideje koja je poslije postala temelj mojeg rješenja:

Možda bismo trebali štititi ne stalnu prijavu, nego samo pravo na privremeni pristup.

A što ako uobičajena stranica za prijavu uopće ne postoji?

Odlučio sam u svojim projektima napustiti tradicionalni model administratorske autentifikacije.

Ne samo sakriti obrazac za prijavu.

Ne promijeniti adresu.

Ne zamijeniti lozinku još složenijom lozinkom.

Nego ukloniti samu potrebu za stalno dostupnom prijavom lozinkom.

Naravno, administrativna sučelja nisu nestala. I dalje su nužna za upravljanje aplikacijama.

Promijenio se način na koji im se pristupa.

Za prijavu u administrativna sučelja povezanih projekata više nije potrebno upisivati spremljeno korisničko ime i lozinku.

Umjesto toga koristim vlastiti sustav za identifikaciju i upravljanje pristupom, MeldID.

Ideja je prilično jednostavna: administrativni pristup daje se samo onda kada je doista potreban, određenom korisniku i određenom projektu.

Pritom samo postojanje korisničkog računa još ne znači da korisnik ima pravo otvoriti administrativno sučelje.

To se pravo mora dodijeliti zasebno.

Pristup koji prije minutu nije postojao

To je možda najzanimljiviji dio cijele koncepcije.

U tradicionalnom modelu administrator stalno raspolaže sredstvima za prijavu. Može ih upotrebljavati danas, sutra ili za mjesec dana, sve dok su ta sredstva valjana.

Odlučio sam promijeniti taj princip.

Umjesto trajnih administratorskih vjerodajnica koristi se privremena mogućnost pokretanja prijave.

Ona se na zahtjev stvara putem pouzdanog mobilnog uređaja, sadrži kriptografski snažnu nasumičnu komponentu i vrijedi ograničeno vrijeme.

No čak ni posjedovanje takve privremene poveznice samo po sebi ne znači da je pristup odobren.

To je ključno.

Recimo da je netko nekako došao do poveznice. U uobičajenom sustavu koji se oslanja isključivo na tajnost adrese takvo bi curenje moglo predstavljati ozbiljan problem.

U mojem modelu poveznica služi samo za pokretanje postupka potvrde.

Za nastavak je potrebno zasebno odobrenje putem pouzdanog mobilnog uređaja s aplikacijom MeldID.

Bez odgovarajuće potvrde administratorska se sesija ne stvara.

Zato privremenu poveznicu ne smatram zamjenom za lozinku, nego jednim od elemenata postupka odobravanja pristupa.

Znati kamo se obratiti i imati pravo prijaviti se dvije 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 potvrdu radnji povezanih s administrativnim pristupom.

Kada želim otvoriti administrativno sučelje, sustav traži potvrdu putem MeldID-a.

Odgovarajući zahtjev vidim na pouzdanom uređaju i potvrđujem radnju.

Tek nakon uspješne provjere sustav dopušta nastavak postupka prijave.

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

Biometrija na mobilnom uređaju služi za lokalnu provjeru korisnika, dok poslužiteljska strana provjerava kriptografsku potvrdu registriranog uređaja.

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

Tu se pojavljuje još jedna prednost: pouzdanim uređajima može se upravljati.

Ako se neki uređaj više ne bi trebao upotrebljavati za potvrdu pristupa, može mu se opozvati status pouzdanog uređaja.

Nakon toga više nije valjano sredstvo autorizacije za odgovarajuće radnje.

Jedan sustav — mnogo neovisnih projekata

Kada sam počeo razvijati ovaj mehanizam, jedan od glavnih zadataka bio je sačuvati neovisnost svakog projekta.

Nisam želio objediniti sva administrativna sučelja u jednu golemi aplikaciju.

Svaki servis DigiMeld i dalje treba upravljati vlastitom logikom, postavkama, korisnicima i podacima.

Stoga sam razdvojio dva zadatka.

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

Sam projekt zadužen je za vlastite administrativne funkcije i provjeru važećih ovlasti.

Tako je nastao centralizirani model upravljanja pristupom bez potrebe za centralizacijom samih aplikacija.

Osim toga, prava se dodjeljuju zasebno.

Administrator jednog projekta ne dobiva automatski pristup ostalima samo zato što ima MeldID račun.

Za svaki administrativni sustav može se odrediti vlastiti krug ovlaštenih korisnika.

Pritom su prava običnih korisnika odvojena od administrativnih ovlasti.

To se pokazalo posebno praktičnim za ekosustav s desecima servisa.

Zašto mi se privremeni pristup više sviđa od trajnog

Postoji još jedno načelo koje sam svjesno ugradio u sustav.

Administrativni pristup ne bi smio trajati beskonačno.

Odobrenje vrijedi ograničeno vrijeme i prestaje važiti neovisno o tome nastavlja li korisnik raditi u pregledniku.

Za nastavak rada nakon isteka roka potreban je novi postupak potvrde.

To omogućuje da se već obavljena autentifikacija ne pretvori u trajno važeće pravo.

No samo vremensko ograničenje nije dovoljno.

Važna je mogućnost ranijeg ukidanja već dodijeljenog pristupa.

Zato MeldID omogućuje centralizirani opoziv administrativnih odobrenja.

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

Upravljanje pristupom tako ne završava u trenutku kada se korisnik uspješno prijavi.

Mogućnost opoziva ovlasti za mene je jednako važna kao i mogućnost njihova dodjeljivanja.

Pritom distribuirani sustav mora uzeti u obzir kašnjenja u prijenosu događaja, privremenu nedostupnost pojedinih komponenti i druge okolnosti u radu. Ograničeno trajanje sesija pruža dodatnu zaštitnu granicu.

Što se promijenilo u svakodnevnom radu?

Prije svega, nestala je potreba za stalnim pristupanjem spremljenim administratorskim lozinkama.

Više ne moram u pregledniku čuvati skup vjerodajnica za prijavu u svako povezano administrativno sučelje.

Umjesto toga, dozvolama upravljam putem jedinstvenog mehanizma.

Odaberem željeni projekt, potvrdim pristup i radim.

Kada mi administrativni pristup više nije potreban, mogu ga opozvati.

Posebno je praktično to što se pri dodavanju novog projekta ne mora iznova osmišljavati cijeli sustav administratorske autentifikacije.

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

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

Privremene dozvole, pouzdani uređaji, poslužiteljske sesije i središnja infrastruktura također zahtijevaju zaštitu.

No više ne moram zasebno rješavati isti problem upravljanja administratorskim lozinkama za svaku aplikaciju.

A upravo je to bio jedan od mojih prvotnih ciljeva.

Zar slične tehnologije već ne postoje?

Naravno da postoje.

Autentifikacija bez lozinke, upravljanje privilegiranim pristupom, privremena odobrenja i potvrda putem pouzdanih uređaja odavno su poznati u industriji informacijske sigurnosti.

Takvi se pristupi primjenjuju u sustavima za upravljanje identitetom i pristupom (Identity and Access Management), sustavima za upravljanje privilegiranim pristupom (Privileged Access Management) i konceptima Zero Trust.

Ne tvrdim da sam izmislio te principe.

Moj je zadatak bio drukčiji.

Trebao sam izraditi vlastiti integrirani sustav koji rješava konkretne probleme infrastrukture DigiMeld i omogućuje upravljanje administrativnim pristupom većem broju samostalnih projekata.

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

Smatram da vrijednost inženjerskog rada ne leži nužno u izumu posve nove tehnologije.

Ponekad je riječ o tome da se problem pravilno definira i za njega pronađe odgovarajuće rješenje.

MeldID nije namijenjen samo administrativnim sučeljima

Ovdje valja dodati posebno pojašnjenje.

MeldID nije stvoren isključivo kao alat za moj vlastiti administrativni pristup.

Razvojnim inženjerima nudi i SDK za integraciju mehanizama identifikacije i potvrde prijave u vlastite aplikacije.

Pritom je takav SDK dostupan besplatno.

Primjerice, vanjski razvojni inženjer može upotrijebiti MeldID kao dodatnu razinu potvrde korisničke autentifikacije.

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

Korisniku se šalje zahtjev na pouzdani mobilni uređaj, na kojem može potvrditi ili odbiti pokušaj prijave.

To smanjuje rizik od neovlaštenog pristupa u slučaju kompromitacije vjerodajnica.

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

Temelje se na zajedničkim načelima povjerenja i potvrde radnji, ali rješavaju različite zadatke.

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

Rad na ovom sustavu potaknuo me da drukčije sagledam uobičajene mehanizme autentifikacije.

Često pokušavamo zaštititi ono što postoji iz povijesnih razloga.

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

Ponekad je to doista nužno.

No ponekad je korisnije postaviti drukčije pitanje:

Mora li mehanizam koji štitimo uopće i dalje postojati u dosadašnjem obliku?

U mojem je slučaju odgovor bio niječan.

Nije mi bio potreban stalno dostupan obrazac za administrativnu prijavu.

Trebala mi je mogućnost sigurnog stjecanja administrativnih ovlasti upravo onda kada su potrebne.

To su dva različita zadatka.

Prijelaz s prvog na drugi promijenio je ne samo tehničku arhitekturu nego i svakodnevni rad na projektima.

Ne konačna točka, nego odabrani smjer

Danas je ova arhitektura već u upotrebi u znatnom dijelu ekosustava DigiMeld.

Preostali se projekti postupno prebacuju na novi model administrativnog pristupa.

Migraciju provodim postupno, provjeravajući rad svake aplikacije, a nakon završetka prijelaza planiram dodatnu reviziju cijelog sustava.

Pojedini elementi sučelja i pravila upravljanja sesijama još se mogu mijenjati.

No glavna je ideja već određena.

Ne želim se vratiti modelu u kojem za upravljanje desecima vlastitih projekata moram stalno čuvati i upotrebljavati desetke administratorskih lozinki.

Pritom ne smatram da je moje rješenje univerzalno za sve.

Različite organizacije imaju različite zahtjeve, infrastrukturu, modele prijetnji i načine administriranja.

Ono što je praktično i opravdano za ekosustav DigiMeld ne mora biti optimalno za nekog drugog razvojnog inženjera.

Ipak, načelo privremenog dodjeljivanja ovlasti zaslužuje pozornost.

Umjesto zaključka

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

Niti zato što neku novu platformu želim predstaviti kao potpuno sigurnu.

Apsolutna sigurnost ne postoji.

Jednostavno mi se čini zanimljivim samo postavljanje pitanja.

Umjesto da beskonačno štitimo stalno dostupnu administrativnu prijavu, možemo preispitati treba li ona uopće postojati.

Umjesto čuvanja mnoštva lozinki — koristiti privremena odobrenja.

Umjesto automatskog povjerenja nakon prve autentifikacije — potvrđivati dodjelu konkretnih ovlasti.

Umjesto čekanja da sesija istekne — predvidjeti mogućnost centraliziranog opoziva pristupa.

I naposljetku, umjesto zasebnog mehanizma za prijavu u svakom projektu — izgraditi jedinstven sustav upravljanja administrativnim pristupom, uz očuvanje neovisnosti aplikacija.

Ne tvrdim da ovaj pristup isključuje mogućnost kompromitacije.

On samo preusmjerava pozornost sa zaštite stalno postojećih vjerodajnica na kontrolirano dodjeljivanje i ukidanje ovlasti.

Možda je ponekad najučinkovitiji način smanjenja površine napada taj da ne dodamo još jedan zaštitni mehanizam, nego da se odreknemo nečega bez čega sustav može sasvim dobro funkcionirati.

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