Proč chránit heslo, když se ho lze vzdát?

Problém, který jsme si zvykli považovat za normální

Prakticky každá webová aplikace má administrační panel. A ten má zpravidla adresu pro přihlášení, přihlašovací formulář, uživatelské jméno a heslo.

Na tuto konstrukci jsme si zvykli natolik, že jsme se prakticky přestali ptát: musí všechno nutně fungovat právě takto?

Když máte jeden web, problém se nezdá nijak zásadní. Vytvoříte složité heslo, zapnete dvoufaktorové ověřování, nastavíte omezení počtu pokusů o přihlášení — a pracujete.

Ale co se stane, když projektů začne být deset, dvacet nebo třicet?

V mém případě jde o ekosystém DigiMeld, který sdružuje více než třicet samostatných softwarových projektů. Každý z nich má vlastní architekturu, serverovou logiku a administrační rozhraní.

Každý proto potřebuje mechanismus administrátorského přístupu.

Dlouhou dobu jsem používal celkem běžný přístup: samostatné administrátorské přihlašovací údaje, složitá hesla a jejich ukládání v prohlížeči.

Fungovalo to.

Ale v určité chvíli jsem se zamyslel: proč vlastně musím uchovávat tolik administrátorských hesel? Proč musím chránit nejen servery, ale i samotné prostředky, které mi umožňují získat k nim přístup?

A nešlo by se této nutnosti zbavit?

Dospěl jsem k myšlence, která se později stala základem mého řešení:

Možná bychom neměli chránit trvalý vstup, ale samotné právo získat dočasný přístup.

Co když žádná obvyklá přihlašovací stránka vůbec nebude?

Rozhodl jsem se ve svých projektech opustit tradiční model administrátorského ověřování.

Ne jen skrýt přihlašovací formulář.

Ne přejmenovat adresu.

Ne nahradit heslo ještě složitějším heslem.

Ale odstranit samotnou potřebu trvale existujícího přihlášení pomocí hesla.

Administrační rozhraní samozřejmě nikam nezmizela. Pro správu aplikací jsou stále nezbytná.

Změnil se způsob, jak k nim získat přístup.

Pro přihlášení do administračních panelů připojených projektů už není potřeba zadávat uložené uživatelské jméno a heslo.

Místo toho používám vlastní systém identifikace a správy přístupu MeldID.

Princip je poměrně jednoduchý: administrátorský přístup se uděluje pouze tehdy, když je skutečně potřeba, konkrétnímu uživateli a ke konkrétnímu projektu.

Samotná existence uživatelského účtu přitom ještě neznamená právo otevřít administrační panel.

Toto právo je nutné udělit zvlášť.

Přístup, který před minutou ještě neexistoval

To je asi nejzajímavější část celé koncepce.

V tradičním modelu má administrátor prostředky k přihlášení k dispozici neustále. Může je používat dnes, zítra nebo za měsíc, dokud zůstávají platné.

Rozhodl jsem se tento princip změnit.

Místo trvalých administrátorských přihlašovacích údajů se používá dočasná možnost zahájit přihlášení.

Vytváří se na vyžádání prostřednictvím důvěryhodného mobilního zařízení, obsahuje kryptograficky bezpečnou náhodnou složku a má omezenou dobu platnosti.

Ale ani samotné vlastnictví takového dočasného odkazu ještě neznamená, že člověk získá přístup.

To je zásadní moment.

Představme si, že někdo nějakým způsobem odkaz získal. V běžném systému postaveném výhradně na utajení adresy by takový únik mohl představovat vážný problém.

V mém modelu odkaz pouze umožňuje zahájit proces potvrzení.

Pro jeho pokračování je potřeba samostatné schválení prostřednictvím důvěryhodného mobilního zařízení MeldID.

Bez příslušného potvrzení se administrátorská relace nevytvoří.

Proto dočasný odkaz nepovažuji za náhradu hesla, ale za jeden z prvků procesu udělování přístupu.

Vědět, kam se obrátit, a mít právo vstoupit jsou dvě úplně odlišné věci.

Telefon se stává nástrojem pro správu přístupu

V tomto modelu hraje mobilní zařízení mnohem důležitější roli než běžný generátor jednorázových kódů.

Používá se k potvrzování úkonů souvisejících s administrátorským přístupem.

Když chci otevřít administrační panel, systém vyžádá potvrzení prostřednictvím MeldID.

Příslušný požadavek se zobrazí na důvěryhodném zařízení a já úkon potvrdím.

Teprve po úspěšném ověření systém dovolí pokračovat v procesu přihlášení.

Potvrzení se přitom vztahuje ke konkrétní akci, nikoli jen k tomu, že byl telefon odemčen.

Mobilní biometrie ověřuje uživatele lokálně a serverová strana ověřuje kryptografické potvrzení od registrovaného zařízení.

Tento přístup umožňuje nespoléhat se výhradně na heslo ani na zprávu, že uživatel údajně přihlášení potvrdil.

Objevuje se tu i další výhoda: důvěryhodná zařízení lze spravovat.

Pokud se nějaké zařízení už nemá používat k potvrzování přístupu, lze mu odebrat status důvěryhodného zařízení.

Poté přestane být platným prostředkem k autorizaci příslušných úkonů.

Jeden systém — mnoho nezávislých projektů

Když jsem začal tento mechanismus vyvíjet, jedním z hlavních úkolů bylo zachovat samostatnost jednotlivých projektů.

Nechtěl jsem všechny administrační panely sloučit do jedné obrovské aplikace.

Každá služba DigiMeld měla i nadále spravovat vlastní logiku, nastavení, uživatele a data.

Rozdělil jsem proto dva úkoly.

MeldID zajišťuje identifikaci a udělování administrátorského přístupu.

Samotný projekt pak zajišťuje vlastní administrátorské funkce a ověřování aktuálních oprávnění.

Vznikl tak centralizovaný model správy přístupu, aniž by bylo nutné centralizovat samotné aplikace.

Oprávnění se navíc udělují samostatně.

Administrátor jednoho projektu automaticky nezíská přístup k ostatním jen proto, že má účet MeldID.

Pro každou oblast správy lze určit vlastní okruh oprávněných uživatelů.

Oprávnění běžných uživatelů a administrátorská oprávnění jsou přitom oddělena.

V ekosystému s desítkami služeb se to ukázalo jako obzvlášť praktické.

Proč mám raději dočasný než trvalý přístup

Do systému jsem vědomě zakomponoval ještě jeden princip.

Administrátorský přístup by neměl zůstávat aktivní napořád.

Oprávnění platí po omezenou dobu a jeho platnost skončí bez ohledu na to, zda uživatel dál pracuje v prohlížeči.

Chce-li uživatel pokračovat v práci po uplynutí této doby, musí znovu projít procesem potvrzení.

Díky tomu se jednou provedené ověření nezmění v trvale platné oprávnění.

Samotné omezení doby platnosti ale nestačí.

Důležitá je i možnost již udělený přístup předčasně ukončit.

MeldID proto umožňuje centrálně odvolávat administrátorská oprávnění.

Když je oprávnění odvoláno, připojené projekty obdrží příslušnou událost a zneplatní související administrátorské relace.

Správa přístupu tedy nekončí ve chvíli, kdy se uživatel úspěšně přihlásí.

Možnost odvolat oprávnění je pro mě neméně důležitá než možnost je udělit.

Distribuovaný systém musí zároveň počítat se zpožděním doručování událostí, dočasnou nedostupností jednotlivých komponent a dalšími provozními okolnostmi. Omezená doba platnosti relací představuje další bezpečnostní hranici.

Co se změnilo v každodenní práci?

Především odpadla potřeba neustále používat uložená administrátorská hesla.

Už nemusím mít v prohlížeči uloženou sadu přihlašovacích údajů pro každý připojený administrační panel.

Místo toho spravuji oprávnění prostřednictvím jediného mechanismu.

Vyberu potřebný projekt, potvrdím přístup a pracuji.

Když už administrátorský přístup není potřeba, lze ho odvolat.

Obzvlášť praktické je, že při přidání nového projektu není nutné znovu navrhovat celý systém administrátorského ověřování.

Stačí ho připojit ke stávajícímu modelu a určit potřebná oprávnění.

To samozřejmě neznamená, že zmizela všechna bezpečnostní rizika.

Dočasná oprávnění, důvěryhodná zařízení, serverové relace i centrální infrastruktura rovněž vyžadují ochranu.

Už ale nemusím pro každou aplikaci zvlášť řešit stejný problém správy administrátorských hesel.

A to byl jeden z mých původních cílů.

Neexistují už podobné technologie?

Samozřejmě že existují.

Bezheslové ověřování, správa privilegovaného přístupu, dočasná oprávnění a potvrzování prostřednictvím důvěryhodných zařízení jsou v oboru informační bezpečnosti známé už dlouho.

S podobnými přístupy se setkáme v systémech Identity and Access Management, Privileged Access Management i v koncepcích Zero Trust.

Nepřisuzuji si autorství těchto principů.

Můj úkol byl jiný.

Potřeboval jsem vytvořit vlastní integrovaný systém, který řeší konkrétní problémy infrastruktury DigiMeld a umožňuje spravovat administrátorský přístup k mnoha samostatným projektům.

Výsledkem bylo spojení několika známých přístupů do jedné architektury, která odpovídá mým požadavkům.

Domnívám se, že hodnota inženýrské práce nemusí spočívat ve vynálezu zcela nové technologie.

Někdy spočívá v tom, že správně formulujeme problém a najdeme vhodné řešení.

MeldID není jen pro administrační panely

Zde je třeba doplnit jedno upřesnění.

MeldID nebyl vytvořen výhradně jako nástroj pro můj vlastní administrátorský přístup.

Vývojářům nabízí také SDK pro integraci mechanismů identifikace a potvrzování přihlášení do jejich vlastních aplikací.

Toto SDK je navíc k dispozici zdarma.

Vývojář třetí strany může například použít MeldID jako další úroveň potvrzení ověření uživatele.

I když aplikace zachová tradiční přihlášení pomocí uživatelského jména a hesla, správné zadání těchto údajů nemusí k dokončení ověření stačit.

Uživateli přijde požadavek na důvěryhodné mobilní zařízení, kde se může pokus o přihlášení potvrdit nebo zamítnout.

To pomáhá snížit riziko neoprávněného přístupu v případě kompromitace přihlašovacích údajů.

Je důležité rozlišovat tuto veřejně dostupnou možnost MeldID od modelu administrátorského přístupu, který jsem vytvořil pro projekty DigiMeld.

Vycházejí ze společných principů důvěry a potvrzování úkonů, ale řeší odlišné úkoly.

Bezpečnost neznamená jen chránit to, co už existuje

Práce na tomto systému mě přiměla podívat se jinak na zavedené mechanismy ověřování.

Často se snažíme chránit něco, co existuje z historických důvodů.

Přidáváme nová ověření, omezení, další hesla a vrstvy ochrany.

Někdy je to skutečně nutné.

Někdy je ale užitečnější položit si jinou otázku:

Musí samotný mechanismus, který chráníme, nutně existovat ve své dosavadní podobě?

V mém případě byla odpověď záporná.

Nepotřeboval jsem trvale dostupný formulář pro administrátorské přihlášení.

Potřeboval jsem možnost bezpečně získat administrátorská oprávnění právě tehdy, když jsou potřeba.

To jsou dva různé úkoly.

A přechod od prvního ke druhému změnil nejen technickou architekturu, ale i každodenní práci s projekty.

Nikoli konečná tečka, ale zvolený směr

Dnes už tato architektura funguje ve značné části ekosystému DigiMeld.

Zbývající projekty se na nový model administrátorského přístupu převádějí postupně.

Migraci provádím krok za krokem, ověřuji fungování každé aplikace a po dokončení přechodu plánuji dodatečný audit celého systému.

Některé prvky rozhraní a pravidla správy relací se ještě mohou měnit.

Základní myšlenka je ale už jasná.

Nechci se vracet k modelu, v němž musím pro správu desítek vlastních projektů neustále uchovávat a používat desítky administrátorských hesel.

Zároveň svou implementaci nepovažuji za univerzální řešení pro každého.

Různé organizace mají různé požadavky, infrastrukturu, modely hrozeb i způsoby správy.

To, co je praktické a odůvodněné pro ekosystém DigiMeld, nemusí být optimální pro jiného vývojáře.

Samotný princip dočasného udělování oprávnění si však zaslouží pozornost.

Závěrem

Rozhodl jsem se podělit o své zkušenosti ne proto, že bych se považoval za vynálezce nového způsobu ověřování.

Ani proto, že bych chtěl představit další systém jako naprosto bezpečný.

Absolutní bezpečnost neexistuje.

Za zajímavý považuji samotný způsob, jakým je problém položen.

Místo nekonečné ochrany trvalého administrátorského přístupu můžeme přehodnotit, zda je vůbec nutné, aby existoval.

Místo uchovávání mnoha hesel můžeme používat dočasná oprávnění.

Místo automatické důvěry po prvním ověření můžeme potvrzovat udělení konkrétních oprávnění.

Místo čekání na konec relace můžeme umožnit centrální odvolání přístupu.

A konečně, místo samostatného mechanismu přihlášení v každém projektu můžeme vytvořit jednotný systém správy administrátorského přístupu a přitom zachovat samostatnost aplikací.

Netvrdím, že tento přístup vylučuje možnost kompromitace.

Pouze přesouvá důraz z ochrany trvale existujících přihlašovacích údajů na kontrolované udělování a odebírání oprávnění.

Možná je někdy nejúčinnějším způsobem, jak zmenšit prostor pro útok, nepřidávat další ochranný mechanismus, ale vzdát se něčeho, bez čeho systém může bez problémů fungovat.

Právě touto myšlenkou pro mě začal příběh MeldID Admin Gateway.