Technológie
Prečo chrániť heslo, keď sa ho možno vzdať?
Ako som prehodnotil zaužívaný model administratívneho prístupu a prečo som sa rozhodol podeliť o túto skúsenosť
Problém, ktorý sme si zvykli považovať za normálny
Prakticky každá webová aplikácia má administrátorský panel. A administrátorský panel má spravidla prihlasovaciu adresu, prihlasovací formulár, používateľské meno a heslo.
Na túto konštrukciu sme si zvykli natoľko, že sme sa takmer prestali pýtať: musí to naozaj fungovať práve takto?
Keď máte jednu stránku, problém sa nezdá podstatný. Vytvoríte si zložité heslo, zapnete dvojfaktorové overovanie, nastavíte obmedzenie počtu pokusov o prihlásenie — a pracujete.
Ale čo sa stane, keď máte desať, dvadsať alebo tridsať projektov?
V mojom prípade ide o ekosystém DigiMeld, ktorý združuje viac ako tridsať samostatných softvérových projektov. Každý má vlastnú architektúru, logiku na strane servera a administrátorské rozhranie.
Každý z nich teda potrebuje mechanizmus administrátorského prístupu.
Dlhý čas som používal celkom bežný prístup: samostatné administrátorské prihlasovacie údaje, zložité heslá a ich ukladanie v prehliadači.
Fungovalo to.
V istom momente som sa však zamyslel: prečo vlastne musím uchovávať toľko administrátorských hesiel? Prečo musím chrániť nielen servery, ale aj samotné prostriedky na získanie prístupu k nim?
A nedá sa tejto povinnosti zbaviť?
Dospel som k myšlienke, ktorá sa neskôr stala základom môjho riešenia:
Možno by sme nemali chrániť trvalý vstup, ale samotné právo dočasne získať prístup.
Čo ak tradičná prihlasovacia stránka vôbec nebude existovať?
Vo svojich projektoch som sa rozhodol opustiť tradičný model administrátorského overovania totožnosti.
Nielen skryť prihlasovací formulár.
Nepremenovať adresu.
Nenahradiť heslo ešte zložitejším heslom.
Ale odstrániť samotnú potrebu trvalo dostupného prihlasovania pomocou hesla.
Samozrejme, administrátorské rozhrania nikam nezmizli. Na správu aplikácií sú stále nevyhnutné.
Zmenil sa spôsob získavania prístupu k nim.
Na prihlásenie do administrátorských panelov pripojených projektov už netreba zadávať uložené používateľské meno a heslo.
Namiesto toho používam vlastný systém identifikácie a správy prístupu MeldID.
Princíp je pomerne jednoduchý: administrátorský prístup sa poskytne len vtedy, keď je skutočne potrebný, konkrétnemu používateľovi a ku konkrétnemu projektu.
Samotná existencia používateľského účtu pritom ešte neznamená právo otvoriť administrátorský panel.
Toto právo sa musí udeliť samostatne.
Prístup, ktorý pred minútou neexistoval
Toto je azda najzaujímavejšia časť celého konceptu.
V tradičnom modeli má administrátor prihlasovacie prostriedky k dispozícii neustále. Môže ich používať dnes, zajtra alebo o mesiac, pokiaľ zostávajú platné.
Rozhodol som sa tento princíp zmeniť.
Namiesto trvalých administrátorských prihlasovacích údajov sa používa dočasná možnosť iniciovať prihlásenie.
Vytvorí sa na požiadanie prostredníctvom dôveryhodného mobilného zariadenia, obsahuje kryptograficky bezpečnú náhodnú zložku a má obmedzenú dobu platnosti.
Ani samotné vlastnenie takéhoto dočasného odkazu však neznamená získanie prístupu.
To je zásadný moment.
Predstavme si, že niekto odkaz nejako získal. V bežnom systéme založenom výlučne na utajení adresy by takýto únik mohol predstavovať vážny problém.
V mojom modeli odkaz iba umožňuje začať proces potvrdenia.
Na pokračovanie je potrebné samostatné povolenie prostredníctvom dôveryhodného mobilného zariadenia MeldID.
Bez príslušného potvrdenia sa administrátorská relácia nevytvorí.
Preto dočasný odkaz nepovažujem za náhradu hesla, ale za jeden z prvkov procesu udeľovania prístupu.
Vedieť, kam sa obrátiť, a mať právo vstúpiť sú dve úplne rozdielne veci.
Telefón sa stáva nástrojom na správu prístupu
V tomto modeli hrá mobilné zariadenie oveľa dôležitejšiu úlohu než bežný generátor jednorazových kódov.
Používa sa na potvrdzovanie úkonov súvisiacich s administrátorským prístupom.
Keď chcem otvoriť administrátorský panel, systém požiada o potvrdenie cez MeldID.
Na dôveryhodnom zariadení sa mi zobrazí príslušná požiadavka a ja úkon potvrdím.
Až po úspešnom overení systém povolí pokračovať v procese prihlásenia.
Potvrdenie sa pritom viaže na konkrétny úkon, nielen na samotné odomknutie telefónu.
Mobilná biometria zabezpečuje lokálne overenie používateľa a serverová strana overuje kryptografické potvrdenie zaregistrovaného zariadenia.
Vďaka tomuto prístupu sa netreba spoliehať výlučne na heslo ani na oznámenie, že používateľ údajne potvrdil prihlásenie.
Prináša to aj ďalšiu výhodu: dôveryhodné zariadenia možno spravovať.
Ak sa zariadenie už nemá používať na potvrdzovanie prístupu, možno mu odobrať dôveryhodný status.
Potom už nebude platným prostriedkom na autorizáciu príslušných operácií.
Jeden systém — množstvo nezávislých projektov
Keď som začal vyvíjať tento mechanizmus, jednou z hlavných úloh bolo zachovať samostatnosť každého projektu.
Nechcel som zlúčiť všetky administrátorské panely do jednej obrovskej aplikácie.
Každá služba DigiMeld má naďalej spravovať vlastnú logiku, nastavenia, používateľov a údaje.
Preto som tieto dve úlohy oddelil.
MeldID zodpovedá za identifikáciu a udelenie administrátorského oprávnenia.
Samotný projekt zodpovedá za svoje administrátorské funkcie a overovanie aktuálnych oprávnení.
Vznikol tak centralizovaný model správy prístupu bez potreby centralizovať samotné aplikácie.
Okrem toho sa oprávnenia udeľujú samostatne.
Administrátor jedného projektu automaticky nezíska prístup k ostatným len preto, že má účet MeldID.
Pre každú administrátorskú oblasť možno určiť vlastný okruh oprávnených používateľov.
Oprávnenia bežných používateľov a administrátorské právomoci sú pritom oddelené.
Pri ekosystéme s desiatkami služieb sa to ukázalo ako mimoriadne praktické.
Prečo mi dočasný prístup vyhovuje viac než trvalý
Do systému som zámerne zakomponoval ešte jeden princíp.
Administrátorský prístup by nemal trvať donekonečna.
Oprávnenie platí obmedzený čas a zanikne bez ohľadu na to, či používateľ naďalej pracuje v prehliadači.
Ak chce používateľ pokračovať v práci aj po uplynutí tejto doby, musí absolvovať nový proces potvrdenia.
Vďaka tomu sa raz vykonaná autentifikácia nepremení na trvalo platné oprávnenie.
Samotné časové obmedzenie však nestačí.
Dôležitá je možnosť predčasne ukončiť už udelený prístup.
Preto MeldID umožňuje centrálne odvolávať administrátorské oprávnenia.
Keď sa oprávnenie odvolá, pripojené projekty dostanú príslušnú udalosť a zrušia súvisiace administrátorské relácie.
Správa prístupu sa teda nekončí vo chvíli, keď sa používateľ úspešne prihlási.
Možnosť odobrať oprávnenia je pre mňa rovnako dôležitá ako možnosť ich udeliť.
Distribuovaný systém pritom musí počítať s oneskorením pri doručovaní udalostí, dočasnou nedostupnosťou jednotlivých komponentov a ďalšími prevádzkovými okolnosťami. Obmedzená doba platnosti relácií predstavuje ďalšiu ochrannú hranicu.
Čo sa zmenilo v každodennej práci?
Predovšetkým odpadla potreba neustále siahať po uložených administrátorských heslách.
Už nemusím mať v prehliadači uloženú sadu prihlasovacích údajov pre každý pripojený administrátorský panel.
Namiesto toho spravujem oprávnenia prostredníctvom jednotného mechanizmu.
Vyberiem potrebný projekt, potvrdím prístup a pracujem.
Keď administrátorský prístup už nepotrebujem, môžem ho odvolať.
Veľmi praktické je aj to, že pri vzniku nového projektu netreba nanovo navrhovať celý systém administrátorského overovania totožnosti.
Stačí ho pripojiť k existujúcemu modelu a určiť potrebné oprávnenia.
Samozrejme, neznamená to, že zmizli všetky bezpečnostné riziká.
Aj dočasné oprávnenia, dôveryhodné zariadenia, serverové relácie a centrálna infraštruktúra si vyžadujú ochranu.
Už však nemusím riešiť tú istú úlohu správy administrátorských hesiel osobitne pre každú aplikáciu.
A práve to bolo jedným z mojich pôvodných cieľov.
Neexistujú už podobné technológie?
Samozrejme, že existujú.
Bezheslové overovanie totožnosti, správa privilegovaného prístupu, dočasné oprávnenia a potvrdzovanie prostredníctvom dôveryhodných zariadení sú v odvetví informačnej bezpečnosti známe už dlho.
S podobnými prístupmi sa stretávame v systémoch Identity and Access Management, Privileged Access Management a v konceptoch Zero Trust.
Netvrdím, že som tieto princípy vynašiel.
Moja úloha bola iná.
Potreboval som vytvoriť vlastný integrovaný systém, ktorý rieši konkrétne problémy infraštruktúry DigiMeld a umožňuje spravovať administrátorský prístup k množstvu samostatných projektov.
Výsledkom je spojenie niekoľkých známych prístupov do jednej architektúry, ktorá spĺňa moje požiadavky.
Myslím si, že hodnota inžinierskej práce nemusí spočívať vo vynájdení úplne novej technológie.
Niekedy spočíva v tom, že problém správne sformulujeme a nájdeme preň vhodné riešenie.
MeldID nie je určený len pre administrátorské panely
Tu je vhodné osobitne niečo objasniť.
MeldID nevznikol výlučne ako nástroj na môj vlastný administrátorský prístup.
Vývojárom poskytuje aj SDK na integráciu mechanizmov identifikácie a potvrdzovania prihlásenia do ich vlastných aplikácií.
Toto SDK je navyše dostupné bezplatne.
Napríklad externý vývojár môže MeldID použiť ako dodatočnú vrstvu na potvrdenie používateľskej autentifikácie.
Aj keď aplikácia naďalej umožňuje tradičné prihlásenie pomocou používateľského mena a hesla, úspešné zadanie týchto údajov nemusí na dokončenie autentifikácie stačiť.
Používateľ dostane požiadavku na dôveryhodné mobilné zariadenie, kde pokus o prihlásenie potvrdí alebo odmietne.
Vďaka tomu možno znížiť riziko neoprávneného prístupu v prípade kompromitácie prihlasovacích údajov.
Je dôležité rozlišovať túto verejne dostupnú funkciu MeldID od modelu administrátorského prístupu pre projekty DigiMeld, ktorý som vytvoril.
Vychádzajú zo spoločných princípov dôvery a potvrdzovania úkonov, ale riešia odlišné úlohy.
Bezpečnosť neznamená len chrániť to, čo už existuje
Práca na tomto systéme ma prinútila pozrieť sa na zaužívané mechanizmy autentifikácie inak.
Často sa snažíme chrániť to, čo existuje z historických dôvodov.
Pridávame nové kontroly, obmedzenia, ďalšie heslá a ochranné vrstvy.
Niekedy je to naozaj potrebné.
Niekedy je však užitočnejšie položiť si inú otázku:
Musí samotný mechanizmus, ktorý chránime, aj naďalej existovať v pôvodnej podobe?
V mojom prípade bola odpoveď záporná.
Nepotreboval som neustále dostupný formulár na administrátorské prihlásenie.
Potreboval som možnosť bezpečne získať administrátorské oprávnenia presne vtedy, keď sú potrebné.
Sú to dve rozdielne úlohy.
Prechod od prvej k druhej zmenil nielen technickú architektúru, ale aj každodennú prácu s projektmi.
Nie konečný bod, ale zvolený smer
Dnes táto architektúra funguje vo veľkej časti ekosystému DigiMeld.
Zvyšné projekty postupne prechádzajú na nový model administrátorského prístupu.
Migráciu realizujem postupne a kontrolujem fungovanie každej aplikácie. Po dokončení prechodu plánujem vykonať dodatočný audit celého systému.
Niektoré prvky rozhrania a pravidlá správy relácií sa ešte môžu zmeniť.
Základná myšlienka je však už jasná.
Nechcem sa vrátiť k modelu, v ktorom musím na správu desiatok vlastných projektov neustále uchovávať a používať desiatky administrátorských hesiel.
Zároveň nepovažujem vlastnú implementáciu za univerzálne riešenie pre každého.
Rôzne organizácie majú rôzne požiadavky, infraštruktúru, modely hrozieb aj spôsoby správy.
To, čo je praktické a opodstatnené pre ekosystém DigiMeld, nemusí byť optimálne pre iného vývojára.
Samotný princíp dočasného udeľovania oprávnení si však zaslúži pozornosť.
Namiesto záveru
Rozhodol som sa podeliť o túto skúsenosť nie preto, že sa považujem za vynálezcu nového spôsobu autentifikácie.
Ani preto, že chcem predstaviť ďalší systém ako úplne bezpečný.
Absolútna bezpečnosť neexistuje.
Samotný spôsob, akým je táto otázka položená, mi jednoducho pripadá zaujímavý.
Namiesto toho, aby sme donekonečna chránili trvalý administrátorský vstup, môžeme prehodnotiť, či je vôbec potrebné, aby existoval.
Namiesto uchovávania množstva hesiel môžeme používať dočasné oprávnenia.
Namiesto automatickej dôvery po prvom overení môžeme potvrdiť udelenie konkrétnych oprávnení.
Namiesto čakania na skončenie relácie môžeme počítať s možnosťou centrálne odvolať prístup.
A napokon, namiesto samostatného prihlasovacieho mechanizmu v každom projekte môžeme vytvoriť jednotný systém správy administrátorských oprávnení a pritom zachovať samostatnosť aplikácií.
Netvrdím, že takýto prístup vylučuje možnosť kompromitácie.
Jednoducho presúva dôraz z ochrany trvalo existujúcich prihlasovacích údajov na kontrolované udeľovanie a odoberanie oprávnení.
Možno je niekedy najúčinnejším spôsobom, ako zmenšiť plochu útoku, nepridávať ďalší ochranný mechanizmus, ale vzdať sa niečoho, bez čoho systém dokáže fungovať.
Práve touto myšlienkou sa pre mňa začal príbeh MeldID Admin Gateway.