Kam saugoti slaptažodį, jei galima jo atsisakyti?

Problema, kurią įpratome laikyti norma

Beveik kiekviena žiniatinklio programa turi administravimo skydelį. O administravimo skydelis paprastai turi prisijungimo adresą, autentifikavimo formą, prisijungimo vardą ir slaptažodį.

Prie šios tvarkos taip pripratome, kad beveik nebekeliame klausimo: ar tikrai viskas turi veikti būtent taip?

Kai turi vieną svetainę, problema neatrodo didelė. Sukuri sudėtingą slaptažodį, įjungi dviejų veiksnių autentifikavimą, nustatai prisijungimo bandymų ribojimą — ir dirbi toliau.

Bet kas nutinka, kai projektų tampa dešimt, dvidešimt ar trisdešimt?

Mano atveju kalbame apie „DigiMeld“ ekosistemą, jungiančią daugiau nei trisdešimt savarankiškų programinės įrangos projektų. Kiekvienas turi savo architektūrą, serverio logiką ir administravimo sąsają.

Taigi kiekvienam jų reikia administracinės prieigos mechanizmo.

Ilgą laiką taikiau gana įprastą būdą: atskiri administratoriaus prisijungimo duomenys, sudėtingi slaptažodžiai ir jų išsaugojimas naršyklėje.

Tai veikė.

Tačiau vienu metu susimąsčiau: kodėl apskritai turiu saugoti tiek daug administratoriaus slaptažodžių? Kodėl turiu saugoti ne tik serverius, bet ir pačias prieigos prie jų priemones?

Gal galima šio poreikio atsisakyti?

Sudėtingas slaptažodis pačios problemos neišsprendžia

Šiuolaikinės priemonės leidžia kurti labai didelės entropijos slaptažodžius. Tinkamai sugeneruotą ilgą atsitiktinį slaptažodį praktiškai neįmanoma atspėti brutalia jėga.

Tačiau kad ir koks sudėtingas būtų slaptažodis, jį reikia kažkur saugoti, o paskui naudoti.

Galima naudoti slaptažodžių tvarkykles, aparatinius raktus, daugiafaktorį autentifikavimą ir papildomus apribojimus. Visa tai iš tiesų padidina saugumą.

Vis dėlto architektūrinė schema išlieka: egzistuoja tam tikra sąsaja, per kurią naudotojas pateikia savo prisijungimo duomenis.

Į ją galima siųsti užklausas. Ją galima skenuoti. Ji gali tapti automatizuotų atakų taikiniu.

Galima paslėpti administravimo skydelio adresą, standartinį kelią pakeisti ilga atsitiktine simbolių seka arba apriboti prieigą pagal IP adresą.

Tačiau tada kyla naujas klausimas: kur saugoti šį adresą ir kaip juo naudotis?

O svarbiausia — kam palikti nuolatinį prisijungimo tašką, jei administracinės prieigos reikia tik tam tikrais momentais?

Priėjau prie minties, kuri vėliau tapo mano sprendimo pagrindu:

Gal verta saugoti ne nuolatinį prisijungimą, o pačią teisę laikinai gauti prieigą.

O kas, jei įprasto prisijungimo puslapio apskritai nebūtų?

Savo projektuose nusprendžiau atsisakyti tradicinio administracinio autentifikavimo modelio.

Ne tiesiog paslėpti prisijungimo formą.

Ne pervadinti adresą.

Ne pakeisti slaptažodį dar sudėtingesniu.

O panaikinti patį nuolat veikiančio prisijungimo naudojant slaptažodį poreikį.

Žinoma, administravimo sąsajos niekur nedingo. Jos vis dar būtinos programoms valdyti.

Pasikeitė būdas, kuriuo gaunama prieiga prie jų.

Dabar, norint prisijungti prie prijungtų projektų administravimo skydelių, nereikia įvesti išsaugoto prisijungimo vardo ir slaptažodžio.

Vietoj to naudoju savo tapatybės nustatymo ir prieigos valdymo sistemą „MeldID“.

Idėja gana paprasta: administracinė prieiga suteikiama tik tada, kai jos iš tiesų reikia, konkrečiam naudotojui ir konkrečiam projektui.

Be to, vien tai, kad naudotojas turi paskyrą, dar nereiškia, jog jis turi teisę atidaryti administravimo skydelį.

Tokia teisė turi būti suteikta atskirai.

Prieiga, kurios prieš minutę dar nebuvo

Tai, ko gero, įdomiausia visos koncepcijos dalis.

Tradiciniame modelyje administratorius nuolat turi prisijungimo priemones. Jis gali jomis naudotis šiandien, rytoj ar po mėnesio, kol tos priemonės galioja.

Nusprendžiau šį principą pakeisti.

Vietoj nuolatinių administratoriaus prisijungimo duomenų naudojama laikina galimybė inicijuoti prisijungimą.

Ji sukuriama patikimu mobiliuoju įrenginiu pateikus užklausą, turi kriptografiškai stiprų atsitiktinį komponentą ir ribotą galiojimo laiką.

Tačiau net ir turėti tokią laikiną nuorodą savaime nereiškia gauti prieigą.

Tai esminis momentas.

Tarkime, kas nors kokiu nors būdu gavo nuorodą. Įprastoje sistemoje, kuri pagrįsta vien adreso slaptumu, toks nutekėjimas galėtų tapti rimta problema.

Mano modelyje nuoroda tik leidžia pradėti patvirtinimo procedūrą.

Norint ją tęsti, reikia atskiro leidimo per patikimą „MeldID“ mobilųjį įrenginį.

Be atitinkamo patvirtinimo administracinė sesija nesukuriama.

Štai kodėl laikiną nuorodą laikau ne slaptažodžio pakaitalu, o vienu iš prieigos suteikimo procedūros elementų.

Žinoti, kur kreiptis, ir turėti teisę prisijungti — visiškai skirtingi dalykai.

Telefonas tampa prieigos valdymo įrankiu

Šiame modelyje mobilusis įrenginys atlieka gerokai svarbesnį vaidmenį nei įprastas vienkartinių kodų generatorius.

Jis naudojamas administracinę prieigą lemiantiems veiksmams patvirtinti.

Kai noriu atidaryti administravimo skydelį, sistema paprašo patvirtinimo per „MeldID“.

Patikimame įrenginyje matau atitinkamą užklausą ir patvirtinu veiksmą.

Tik sėkmingai patikrinusi sistema leidžia tęsti prisijungimo procedūrą.

Patvirtinimas susiejamas su konkrečiu veiksmu, o ne vien su tuo, kad telefonas buvo atrakintas.

Mobilioji biometrinė patikra užtikrina vietinį naudotojo patvirtinimą, o serverio pusė tikrina kriptografinį patvirtinimą, gautą iš registruoto įrenginio.

Toks būdas leidžia nepasikliauti vien slaptažodžiu ar pranešimu, kad naudotojas neva patvirtino prisijungimą.

Čia atsiranda ir dar vienas privalumas: patikimus įrenginius galima valdyti.

Jei įrenginys nebeturėtų būti naudojamas prieigai patvirtinti, jo patikimo įrenginio statusą galima atšaukti.

Po to jis nebegali būti naudojamas kaip galiojanti atitinkamų veiksmų autorizavimo priemonė.

Viena sistema — daug nepriklausomų projektų

Pradėjęs kurti šį mechanizmą, vienu svarbiausių uždavinių laikiau kiekvieno projekto savarankiškumo išsaugojimą.

Neplanavau visų administravimo skydelių sujungti į vieną didžiulę programą.

Kiekviena „DigiMeld“ paslauga ir toliau turi valdyti savo logiką, nustatymus, naudotojus ir duomenis.

Todėl atskyriau du uždavinius.

„MeldID“ atsako už tapatybės nustatymą ir administracinės prieigos suteikimą.

O pats projektas atsako už savo administravimo funkcijas ir galiojančių įgaliojimų tikrinimą.

Taip gavosi centralizuotas prieigos valdymo modelis, kuriam nereikia centralizuoti pačių programų.

Be to, teisės suteikiamos atskirai.

Vieno projekto administratorius automatiškai negauna prieigos prie kitų vien dėl to, kad turi „MeldID“ paskyrą.

Kiekvienai administravimo sričiai galima nustatyti atskirą naudotojų, kuriems leidžiama ją pasiekti, grupę.

Įprastų naudotojų teisės ir administraciniai įgaliojimai taip pat atskirti.

Dešimčių paslaugų ekosistemoje tai pasirodė ypač patogu.

Kodėl man labiau patinka laikina, o ne nuolatinė prieiga

Sąmoningai įdiegiau sistemoje ir dar vieną principą.

Administracinė prieiga neturi galioti amžinai.

Leidimas galioja ribotą laiką ir nustoja galioti nepriklausomai nuo to, ar naudotojas toliau dirba naršyklėje.

Norint tęsti darbą pasibaigus šiam laikui, reikia iš naujo atlikti patvirtinimo procedūrą.

Tai neleidžia vieną kartą atlikto autentifikavimo paversti nuolatine teise.

Tačiau vien apriboti galiojimo laiką nepakanka.

Taip pat svarbu turėti galimybę anksčiau laiko nutraukti jau suteiktą prieigą.

Todėl „MeldID“ numatyta centralizuota administracinių leidimų atšaukimo funkcija.

Atšaukus leidimą, prijungti projektai gauna atitinkamą įvykį ir panaikina susijusias administracines sesijas.

Taigi prieigos valdymas nesibaigia naudotojui sėkmingai prisijungus.

Galimybė atšaukti įgaliojimus man ne mažiau svarbi nei galimybė juos suteikti.

Be to, paskirstytoje sistemoje reikia atsižvelgti į įvykių perdavimo vėlavimą, laikiną atskirų komponentų nepasiekiamumą ir kitas eksploatavimo aplinkybes. Sesijų galiojimo laiko apribojimas yra papildoma apsaugos riba.

O kas pasikeitė kasdieniame darbe?

Pirmiausia nebereikia nuolat naudotis išsaugotais administratoriaus slaptažodžiais.

Man nebereikia laikyti naršyklėje prisijungimo duomenų rinkinio, kad galėčiau prisijungti prie kiekvieno prijungto administravimo skydelio.

Vietoj to leidimus valdau vienu mechanizmu.

Pasirenku reikiamą projektą, patvirtinu prieigą ir dirbu.

Kai administracinės prieigos nebereikia, ją galima atšaukti.

Ypač patogu tai, kad atsiradus naujam projektui nereikia iš naujo kurti visos administracinio autentifikavimo sistemos.

Pakanka prijungti jį prie esamo modelio ir nustatyti reikiamus leidimus.

Žinoma, tai nereiškia, kad išnyko visos saugumo rizikos.

Laikini leidimai, patikimi įrenginiai, serverio sesijos ir centrinė infrastruktūra taip pat turi būti apsaugoti.

Tačiau man nebereikia atskirai spręsti tos pačios administratoriaus slaptažodžių valdymo problemos kiekvienoje programoje.

Būtent tai ir buvo vienas iš mano pradinių tikslų.

Argi tokios technologijos jau neegzistuoja?

Žinoma, egzistuoja.

Autentifikavimas be slaptažodžio, privilegijuotos prieigos valdymas, laikini leidimai ir patvirtinimas patikimais įrenginiais informacijos saugumo srityje žinomi jau seniai.

Tokie būdai taikomi tapatybės ir prieigos valdymo (Identity and Access Management), privilegijuotos prieigos valdymo (Privileged Access Management) sistemose ir „Zero Trust“ koncepcijose.

Neapsimetu, kad šiuos principus išradau.

Mano užduotis buvo kita.

Man reikėjo sukurti savo integruotą sistemą, kuri spręstų konkrečias „DigiMeld“ infrastruktūros problemas ir leistų valdyti administracinę prieigą prie daugybės savarankiškų projektų.

Galiausiai sujungiau kelis žinomus būdus į vieną architektūrą, atitinkančią mano reikalavimus.

Manau, kad inžinerinio darbo vertė nebūtinai slypi visiškai naujos technologijos išradime.

Kartais ji slypi gebėjime tinkamai suformuluoti problemą ir rasti jai tinkamą sprendimą.

„MeldID“ skirtas ne tik administravimo skydeliams

Čia verta atskirai patikslinti vieną dalyką.

„MeldID“ buvo kuriamas ne vien kaip įrankis mano paties administracinei prieigai valdyti.

Jis taip pat suteikia kūrėjams SDK, skirtą tapatybės nustatymo ir prisijungimo patvirtinimo mechanizmams integruoti į jų pačių programas.

Be to, šį SDK galima naudoti nemokamai.

Pavyzdžiui, išorinis kūrėjas gali naudoti „MeldID“ kaip papildomą naudotojų autentifikavimo patvirtinimo lygmenį.

Net jei programoje išlieka tradicinis prisijungimas naudojant prisijungimo vardą ir slaptažodį, sėkmingai įvestų duomenų gali nepakakti autentifikavimui užbaigti.

Naudotojas gauna užklausą į patikimą mobilųjį įrenginį, kuriame gali patvirtinti arba atmesti bandymą prisijungti.

Tai leidžia sumažinti neteisėtos prieigos riziką, jei prisijungimo duomenys būtų kompromituoti.

Svarbu atskirti šią visiems prieinamą „MeldID“ galimybę nuo mano sukurtos „DigiMeld“ projektų administracinės prieigos sistemos.

Jos vadovaujasi bendrais pasitikėjimo ir veiksmų patvirtinimo principais, tačiau sprendžia skirtingus uždavinius.

Saugumas — tai ne tik esamo apsauga

Darbas su šia sistema paskatino mane kitaip pažvelgti į įprastus autentifikavimo mechanizmus.

Dažnai bandome apsaugoti tai, kas egzistuoja dėl istorinių priežasčių.

Pridedame naujų patikrų, apribojimų, papildomų slaptažodžių ir apsaugos sluoksnių.

Kartais tai iš tiesų būtina.

Tačiau kartais naudingiau užduoti kitą klausimą:

Ar tikrai pats saugomas mechanizmas turi likti toks, koks buvo?

Mano atveju atsakymas buvo neigiamas.

Man nereikėjo nuolat prieinamos administracinio prisijungimo formos.

Man reikėjo galimybės saugiai gauti administracinius įgaliojimus būtent tada, kai jų reikia.

Tai du skirtingi uždaviniai.

Pereidamas nuo pirmojo prie antrojo pakeičiau ne tik techninę architektūrą, bet ir kasdienį darbą su projektais.

Ne galutinis taškas, o pasirinkta kryptis

Šiandien ši architektūra jau veikia didelėje „DigiMeld“ ekosistemos dalyje.

Likę projektai palaipsniui perkeliami prie naujo administracinės prieigos modelio.

Migraciją vykdau etapais, tikrindamas kiekvienos programos veikimą, o jai pasibaigus planuoju atlikti papildomą visos sistemos auditą.

Atskiri sąsajos elementai ir sesijų valdymo taisyklės dar gali keistis.

Tačiau pagrindinė idėja jau aiški.

Nenoriu grįžti prie modelio, kuriame norėdamas valdyti dešimtis savo projektų turiu nuolat saugoti ir naudoti dešimtis administratoriaus slaptažodžių.

Vis dėlto nelaikau savo įgyvendinimo universaliu sprendimu visiems.

Skirtingos organizacijos turi skirtingus reikalavimus, infrastruktūrą, grėsmių modelius ir administravimo būdus.

Tai, kas patogu ir pagrįsta „DigiMeld“ ekosistemoje, nebūtinai bus geriausias pasirinkimas kitam kūrėjui.

Tačiau pats laikino įgaliojimų suteikimo principas vertas dėmesio.

Pabaigai

Nusprendžiau pasidalyti šia patirtimi ne todėl, kad laikau save naujo autentifikavimo būdo išradėju.

Ir ne todėl, kad noriu pristatyti dar vieną sistemą kaip visiškai saugią.

Absoliutaus saugumo nėra.

Man tiesiog atrodo įdomus pats klausimo formulavimas.

Užuot be galo saugoję nuolatinį administracinį prisijungimą, galime iš naujo įvertinti, ar jis apskritai turi egzistuoti.

Užuot saugoję daugybę slaptažodžių, galime naudoti laikinus leidimus.

Užuot automatiškai pasitikėję po pirmojo autentifikavimo, galime patvirtinti konkrečių įgaliojimų suteikimą.

Užuot laukę, kol baigsis sesija, galime numatyti galimybę centralizuotai atšaukti prieigą.

Ir galiausiai, užuot kiekviename projekte kūrę atskirą prisijungimo mechanizmą, galime sukurti vieningą administracinės prieigos valdymo sistemą ir kartu išsaugoti programų savarankiškumą.

Netvirtinu, kad toks būdas visiškai pašalina kompromitavimo galimybę.

Jis tiesiog perkelia dėmesį nuo nuolat egzistuojančių prisijungimo duomenų apsaugos prie kontroliuojamo įgaliojimų suteikimo ir atšaukimo.

Galbūt kartais veiksmingiausias būdas sumažinti atakos paviršių yra ne pridėti dar vieną apsaugos mechanizmą, o atsisakyti to, be ko sistema gali puikiai veikti.

Būtent nuo šios minties man prasidėjo „MeldID Admin Gateway“ istorija.