Miért védjük a jelszót, ha le is mondhatunk róla?

A probléma, amelyet megszoktunk normálisnak tekinteni

Gyakorlatilag minden webalkalmazásnak van adminisztrációs felülete. Az adminisztrációs felülethez pedig rendszerint tartozik egy bejelentkezési cím, egy hitelesítési űrlap, egy felhasználónév és egy jelszó.

Annyira hozzászoktunk ehhez a felépítéshez, hogy szinte már fel sem tesszük a kérdést: valóban mindennek feltétlenül így kell működnie?

Ha csak egy weboldalad van, a probléma nem tűnik jelentősnek. Létrehozol egy erős jelszót, bekapcsolod a kétlépcsős hitelesítést, beállítod a bejelentkezési próbálkozások korlátozását, és dolgozol tovább.

De mi történik, ha már tíz, húsz vagy harminc projekted van?

Az én esetemben a DigiMeld ökoszisztémáról van szó, amely több mint harminc önálló szoftverprojektet fog össze. Mindegyiknek saját architektúrája, szerveroldali logikája és adminisztrációs felülete van.

Ennek megfelelően mindegyikhez szükség van valamilyen adminisztrátori hozzáférési megoldásra.

Sokáig a megszokott megközelítést alkalmaztam: külön adminisztrátori bejelentkezési adatok, erős jelszavak, amelyeket a böngészőben tároltam.

Működött.

Egy ponton azonban elgondolkodtam: miért kell egyáltalán ennyi adminisztrátori jelszót tárolnom? Miért kell nemcsak a szervereket, hanem a hozzájuk való hozzáférés eszközeit is védenem?

És vajon lemondhatok erről a szükségességről?

Arra a gondolatra jutottam, amely később a megoldásom alapjává vált:

Talán nem egy állandó belépési pontot kellene védenünk, hanem magát az ideiglenes hozzáférés megszerzésének jogát.

Mi lenne, ha egyáltalán nem lenne hagyományos bejelentkezési oldal?

Úgy döntöttem, hogy felhagyok a hagyományos adminisztrátori hitelesítési modellel a projektjeimben.

Nem csupán elrejtem a bejelentkezési űrlapot.

Nem nevezem át a címet.

Nem cserélem le a jelszót egy még bonyolultabbra.

Hanem megszüntetem az állandóan elérhető, jelszavas belépés szükségességét.

Természetesen az adminisztrációs felületek nem tűntek el. Továbbra is szükség van rájuk az alkalmazások kezeléséhez.

A hozzáférés megszerzésének módja változott meg.

Mostantól a csatlakoztatott projektek adminisztrációs felületeire való belépéshez nem kell megadni egy elmentett felhasználónevet és jelszót.

Ehelyett a saját MeldID azonosítási és hozzáférés-kezelési rendszeremet használom.

Az alapelv egyszerű: az adminisztrátori hozzáférés csak akkor jár, amikor valóban szükség van rá, egy konkrét felhasználónak és egy konkrét projekthez.

Ráadásul önmagában az, hogy valakinek van felhasználói fiókja, még nem jelenti azt, hogy jogosult megnyitni az adminisztrációs felületet.

Ezt a jogosultságot külön kell megadni.

Olyan hozzáférés, amely egy perccel korábban még nem létezett

Talán ez az egész koncepció legérdekesebb része.

A hagyományos modellben a rendszergazdának folyamatosan rendelkezésére állnak a belépéshez szükséges adatok. Használhatja őket ma, holnap vagy egy hónap múlva, amíg ezek az adatok érvényesek.

Úgy döntöttem, megváltoztatom ezt az elvet.

Az állandó adminisztrátori bejelentkezési adatok helyett egy ideiglenes lehetőség áll rendelkezésre a belépés kezdeményezésére.

Ez egy megbízható mobileszközről indított kérelemre jön létre, kriptográfiailag biztonságos véletlen összetevőt tartalmaz, és korlátozott ideig érvényes.

De még egy ilyen ideiglenes hivatkozás birtoklása sem jelent önmagában hozzáférést.

Ez alapvető fontosságú.

Tegyük fel, hogy valaki valamilyen módon megszerezte a hivatkozást. Egy olyan hagyományos rendszerben, amely kizárólag a cím titkosságára épül, ez a kiszivárgás komoly problémát okozhatna.

Az én modellemben a hivatkozás csupán a megerősítési folyamat elindítását teszi lehetővé.

A folytatáshoz a MeldID megbízható mobileszközén keresztül külön engedélyezés szükséges.

A megfelelő jóváhagyás nélkül nem jön létre adminisztrátori munkamenet.

Éppen ezért nem a jelszó helyettesítőjeként tekintek az ideiglenes hivatkozásra, hanem a hozzáférés megadására irányuló eljárás egyik elemeként.

Tudni, hová kell fordulni, és jogosultnak lenni a belépésre két teljesen különböző dolog.

A telefon a hozzáférés-kezelés eszközévé válik

Ebben a modellben a mobileszköz sokkal fontosabb szerepet játszik, mint egy egyszerű, egyszer használatos kódokat generáló eszköz.

Az adminisztrátori hozzáféréssel kapcsolatos műveletek megerősítésére szolgál.

Amikor meg akarom nyitni az adminisztrációs felületet, a rendszer MeldID-n keresztüli megerősítést kér.

A megfelelő kérelem megjelenik a megbízható eszközön, én pedig jóváhagyom a műveletet.

A rendszer csak a sikeres ellenőrzés után engedi folytatni a belépési folyamatot.

A megerősítés egy konkrét művelethez kapcsolódik, nem csupán ahhoz, hogy feloldottuk a telefont.

A mobilos biometria helyben ellenőrzi a felhasználót, a szerveroldal pedig ellenőrzi a regisztrált eszköztől származó kriptográfiai megerősítést.

Ez a megközelítés lehetővé teszi, hogy ne kizárólag a jelszóra vagy arra az üzenetre támaszkodjunk, hogy a felhasználó állítólag megerősítette a belépést.

És ezzel egy újabb előny is jár: a megbízható eszközök kezelhetők.

Ha egy eszközt a továbbiakban nem szabad a hozzáférés megerősítésére használni, visszavonható a megbízható státusza.

Ezt követően az eszköz már nem használható az érintett műveletek engedélyezésére.

Egy rendszer — számos független projekt

Amikor elkezdtem kidolgozni ezt a megoldást, az egyik legfontosabb feladat az volt, hogy megőrizzem az egyes projektek önállóságát.

Nem akartam az összes adminisztrációs felületet egyetlen hatalmas alkalmazásba összevonni.

Minden DigiMeld-szolgáltatásnak továbbra is a saját logikáját, beállításait, felhasználóit és adatait kell kezelnie.

Ezért különválasztottam a két feladatot.

A MeldID felel az azonosításért és az adminisztrátori hozzáférés megadásáért.

Maga a projekt pedig a saját adminisztrációs funkcióiért és az érvényes jogosultságok ellenőrzéséért felel.

Így központosított hozzáférés-kezelési modell jött létre anélkül, hogy magukat az alkalmazásokat is központosítani kellett volna.

Emellett a jogosultságokat külön adjuk meg.

Egy projekt adminisztrátora nem kap automatikusan hozzáférést a többi projekthez csak azért, mert van MeldID-fiókja.

Minden adminisztrációs területhez külön meg lehet határozni az arra jogosult felhasználók körét.

A hagyományos felhasználói jogosultságok és az adminisztrátori jogosultságok pedig egymástól elkülönülnek.

Több tucat szolgáltatásból álló ökoszisztémánál ez különösen hasznosnak bizonyult.

Miért kedvelem jobban az ideiglenes hozzáférést az állandónál?

Van még egy elv, amelyet tudatosan beépítettem a rendszerbe.

Az adminisztrátori hozzáférés nem maradhat érvényben a végtelenségig.

A jogosultság korlátozott ideig érvényes, és akkor is megszűnik, ha a felhasználó továbbra is a böngészőben dolgozik.

A lejárat után a munka folytatásához új megerősítési folyamatra van szükség.

Így elkerülhető, hogy egy egyszer elvégzett hitelesítésből állandóan érvényes jogosultság legyen.

Az időkorlát azonban önmagában nem elegendő.

Fontos, hogy a már megadott hozzáférést idő előtt is meg lehessen szüntetni.

Ezért a MeldID lehetővé teszi az adminisztrátori jogosultságok központi visszavonását.

Amikor visszavonnak egy jogosultságot, a csatlakoztatott projektek megkapják az erről szóló eseményt, és érvénytelenítik a hozzá tartozó adminisztrátori munkameneteket.

Így a hozzáférés kezelése nem ér véget abban a pillanatban, amikor a felhasználó sikeresen belép.

A jogosultság visszavonásának lehetősége számomra legalább olyan fontos, mint a megadásáé.

Egy elosztott rendszernek ugyanakkor figyelembe kell vennie az események továbbításának késéseit, egyes összetevők átmeneti elérhetetlenségét és más üzemeltetési körülményeket is. A munkamenetek érvényességi idejének korlátozása további védelmi határt jelent.

Mi változott a mindennapi munkában?

Mindenekelőtt megszűnt az, hogy folyamatosan az elmentett adminisztrátori jelszavakhoz kelljen nyúlnom.

Nem kell többé minden csatlakoztatott adminisztrációs felülethez külön bejelentkezési adatokat tárolnom a böngészőben.

Ehelyett egyetlen mechanizmuson keresztül kezelem a jogosultságokat.

Kiválasztom a szükséges projektet, megerősítem a hozzáférést, és dolgozom.

Ha már nincs szükségem adminisztrátori hozzáférésre, visszavonhatom.

Különösen kényelmes, hogy egy új projekt hozzáadásakor nem kell újratervezni a teljes adminisztrátori hitelesítési rendszert.

Elég csatlakoztatni a meglévő modellhez, és meghatározni a szükséges jogosultságokat.

Ez természetesen nem jelenti azt, hogy minden biztonsági kockázat megszűnt.

Az ideiglenes jogosultságok, a megbízható eszközök, a szerveroldali munkamenetek és a központi infrastruktúra is védelmet igényelnek.

De többé nem kell minden egyes alkalmazásban külön megoldanom ugyanazt az adminisztrátori jelszavak kezelésével kapcsolatos feladatot.

És ez volt az egyik eredeti célom.

Nem léteznek már ilyen technológiák?

De igen, léteznek.

A jelszó nélküli hitelesítés, a kiemelt hozzáférések kezelése, az ideiglenes jogosultságok és a megbízható eszközökön keresztüli megerősítés régóta ismert az információbiztonsági iparágban.

Ezek a megközelítések az Identity and Access Management és Privileged Access Management rendszerekben, valamint a Zero Trust koncepciókban is megjelennek.

Nem állítom, hogy én találtam fel ezeket az alapelveket.

Más volt a feladatom.

Olyan saját, integrált rendszert kellett létrehoznom, amely megoldja a DigiMeld infrastruktúrájának konkrét problémáit, és lehetővé teszi számos önálló projekt adminisztrátori hozzáférésének kezelését.

Ennek eredményeként több ismert megközelítést egyetlen, az igényeimnek megfelelő architektúrában egyesítettem.

Úgy gondolom, hogy a mérnöki munka értéke nem feltétlenül abban rejlik, hogy egy teljesen új technológiát találunk fel.

Néha abban rejlik, hogy helyesen fogalmazzuk meg a problémát, és megtaláljuk rá a megfelelő megoldást.

A MeldID nem csak adminisztrációs felületekhez használható

Itt érdemes külön pontosítást tenni.

A MeldID-t nem kizárólag a saját adminisztrátori hozzáférésem eszközeként hoztam létre.

A fejlesztők számára SDK-t is biztosít, amellyel saját alkalmazásaikba integrálhatják az azonosítási és a bejelentkezést megerősítő mechanizmusokat.

Ráadásul ez az SDK ingyenesen elérhető.

Például egy külső fejlesztő a MeldID-t a felhasználói hitelesítés további megerősítési szintjeként használhatja.

Még ha az alkalmazásban megmarad is a hagyományos, felhasználónévvel és jelszóval történő belépés, ezek sikeres megadása önmagában nem feltétlenül elegendő a hitelesítés befejezéséhez.

A felhasználó megbízható mobileszközére kérelem érkezik, ahol jóváhagyhatja vagy elutasíthatja a belépési kísérletet.

Ez csökkentheti a jogosulatlan hozzáférés kockázatát, ha a bejelentkezési adatok illetéktelenek kezébe kerülnek.

Fontos különbséget tenni a MeldID nyilvánosan elérhető funkciója és a DigiMeld-projektekhez általam kidolgozott adminisztrátori hozzáférési modell között.

Közös bizalmi és megerősítési alapelveket használnak, de különböző feladatokat látnak el.

A biztonság nem csupán a meglévő dolgok védelmét jelenti

A rendszer fejlesztése arra késztetett, hogy másképp tekintsek a megszokott hitelesítési mechanizmusokra.

Gyakran olyan dolgokat próbálunk megvédeni, amelyek történelmi okokból léteznek.

Új ellenőrzéseket, korlátozásokat, további jelszavakat és védelmi rétegeket adunk hozzájuk.

Ez néha valóban szükséges.

De néha hasznosabb egy másik kérdést feltenni:

Feltétlenül a megszokott formájában kell léteznie annak a mechanizmusnak, amelyet védeni próbálunk?

Az én esetemben a válasz nem volt.

Nem volt szükségem folyamatosan elérhető adminisztrátori bejelentkezési űrlapra.

Arra volt szükségem, hogy biztonságosan akkor szerezzek adminisztrátori jogosultságot, amikor arra valóban szükség van.

Ez két különböző feladat.

Az elsőről a másodikra való áttérés pedig nemcsak a technikai architektúrát változtatta meg, hanem a projektekkel végzett mindennapi munkát is.

Nem végleges állapot, hanem választott irány

Ma ez az architektúra már a DigiMeld ökoszisztéma jelentős részében működik.

A fennmaradó projektek fokozatosan állnak át az új adminisztrátori hozzáférési modellre.

Az átállást fokozatosan végzem, minden alkalmazás működését ellenőrzöm, majd a folyamat befejezése után az egész rendszert további auditnak tervezem alávetni.

A felület egyes elemei és a munkamenetek kezelésére vonatkozó szabályok még változhatnak.

Az alapötlet azonban már megszületett.

Nem szeretnék visszatérni ahhoz a modellhez, amelyben több tucat saját projektem kezeléséhez folyamatosan több tucat adminisztrátori jelszót kell tárolnom és használnom.

Ugyanakkor nem gondolom, hogy a saját megoldásom mindenki számára univerzális lenne.

A különböző szervezeteknek eltérő követelményeik, infrastruktúrájuk, fenyegetési modelljeik és adminisztrációs módszereik vannak.

Ami a DigiMeld ökoszisztémája számára kényelmes és indokolt, nem feltétlenül lesz optimális egy másik fejlesztő számára.

Az ideiglenes jogosultságadás alapelve azonban figyelmet érdemel.

Zárszó helyett

Azért döntöttem úgy, hogy megosztom ezt a tapasztalatot, mert nem tartom magam egy új hitelesítési módszer feltalálójának.

És nem azért, mert egy újabb rendszert szeretnék teljesen biztonságosként bemutatni.

Abszolút biztonság nem létezik.

Egyszerűen érdekesnek tartom magát a kérdésfelvetést.

Ahelyett, hogy a folyamatosan elérhető adminisztrátori belépést próbálnánk újra és újra megvédeni, felülvizsgálhatjuk, hogy egyáltalán szükség van-e a létezésére.

Több jelszó tárolása helyett használhatunk ideiglenes jogosultságokat.

Az első hitelesítést követő automatikus bizalom helyett megerősíthetjük az egyes konkrét jogosultságok megadását.

A munkamenet lejártára való várakozás helyett lehetőséget teremthetünk a hozzáférés központi visszavonására.

Végül pedig minden projekthez külön belépési mechanizmus helyett kiépíthetünk egy egységes adminisztrátori hozzáférés-kezelő rendszert úgy, hogy közben megőrizzük az alkalmazások önállóságát.

Nem állítom, hogy ez a megközelítés kizárja a kompromittálódás lehetőségét.

Egyszerűen az állandóan létező bejelentkezési adatok védelméről a jogosultságok ellenőrzött megadására és megszüntetésére helyezi át a hangsúlyt.

Talán néha a támadási felület csökkentésének leghatékonyabb módja nem egy újabb védelmi mechanizmus bevezetése, hanem annak elhagyása, ami nélkül a rendszer is képes működni.

Számomra ezzel a gondolattal kezdődött a MeldID Admin Gateway története.