Hodor: Egyszerű jelszóvédelem webes alkalmazásoknak

Mindnyájan ismerjük a helyzetet. Elkészítettünk egy belső eszközt, staging-környezetet vagy monitorozót, és most hirtelen védelmet kell rá tenni. A klasszikus megoldás viszont rögtön komplikáltvá válik: felhasználói adatbázis, jelszókezelés, OAuth-integráció, session-kezelés. Rövid idő alatt olyan keretrendszerekkel küzdünk, amelyek túl soknak tűnnek egy egyszerű „tartsuk távol az illetékteleneket” feladathoz.

Hodor egy olyan fordított proxy, amely ezt a bonyolultságot egyszerűen elkerüli.

Mikor érdemes az egyszerűséget választani?

Hodor alapötlete nagyon letisztult: bármilyen webes alkalmazást egyetlen közös jelszó mögé lehet rejteni. Ennyi az egész. Nincs felhasználó-kezelés, nincs adatbázis, nincs bonyolult hitelesítés. Csak egy futtatható állomány, egy jelszó és egy bejelentkező oldal.

Természetesen ez nem minden helyzetre való. Egy több ezer felhasználós nyilvános SaaS-termékhez nyilván nem ajánlott. Viszont belső dashboardok, tesztkörnyezetek, proof-of-concept alkalmazások vagy kis csapatoknak szánt eszközök esetében Hodor nagyon praktikus megoldás.

Mi teszi egyszerűvé a felépítését?

Hodor pont abban erős, amije nincs:

• Nincs felhasználói adatbázis – nincs sémakezelés, nincs CRUD-művelet
• Nincs OAuth-integráció – nincs külső szolgáltató, nincs token-áramlás
• Egyszerű cookie-hitelesítés – nincs összetett session-logika
• Egyetlen bináris – mindent egy alkalmazás kezel

A fejlesztőknek, akik unják, hogy minden rétegbe külön autentikációs kódot kell írni, ez nagy megkönnyebbülés. Telepítjük a proxy-t az alkalmazás elé, megadjuk a jelszót, és kész.

Hol hasznos igazán?

• Belső dashboardok és monitorozó eszközök – az üzemeltetők hozzáférnek a metrikákhoz anélkül, hogy külön felhasználói fiókokat kellene létrehozni
• Staging és tesztkörnyezetek – minimális erőfeszítéssel védhető a pre-production környezet
• Gyors prototípusok – bemutatókhoz nem kell teljes hitelesítési rendszert építeni
• Kis csapatok projektjei – ha amúgy is közös jelszót használnak, miért bonyolítsuk?
• Saját infrastruktúrán futó szolgáltatások – extra biztonsági réteg egyszerű módon

Mire kell figyelni?

Mielőtt mindenhol bevetnénk, érdemes tisztában lenni a korlátokkal is:

• Nincs audit napló – közös jelszó esetén nem tudjuk követni, ki mit csinált
• Nincs jogosultság-szint – mindenki ugyanazt látja, nincs finomhangolt hozzáférés
• Jelszóváltás bonyolult – ha valaki kilép a csapatból, az egész csapatnak új jelszót kell kapnia
• Közös titok kockázata – a jelszó könnyen elterjed Slack-en vagy e-mailben

Ezek miatt Hodor leginkább olyan kis, megbízható csapatoknak ideális, ahol a közös jelszó már amúgy is bevett gyakorlat.

Hogyan működik a gyakorlatban?

Hodor az alkalmazás és a látogató közé ékelődik. Amikor valaki megpróbál hozzáférni:

1. Elfogja a kérést
2. Ellenőrzi, van-e érvényes cookie
3. Ha nincs, bejelentkező oldalt mutat
4. Helyes jelszó esetén cookie-t állít be
5. A további kéréseket továbbítja az alkalmazásnak

Nincs szükség session-tárolóra, token-lejáratra vagy OAuth-folyamatra. Csak kérés – ellenőrzés – továbbítás.

Biztonsági megfontolások

Egyetlen jelszó természetesen nem tökéletes megoldás, de sok esetben mégis előrelépés. Ha eddig semmilyen védelem sem volt az eszközön, Hodor máris nagy biztonsági javulást jelent. Ha eddig Slack-en osztották meg a jelszót, akkor Hodor legalább formalizálja ezt a gyakorlatot.

Fontos azonban tudni, hogy Hodor nem véd kifinomult támadások ellen. Inkább a véletlen hozzáférést és a külső szkennelést akadályozza meg. Mintha egy ajtózárat tennénk fel, nem pedig biztonsági őrséget állítanánk.

Telepítési szempontok

Fordított proxy-ként Hodor könnyen beilleszthető a meglévő infrastruktúrába:

• Belső hálózaton vagy privát szerveren is futtatható
• HTTPS/TLS használata kötelező a jelszó védelméhez
• Docker, Kubernetes vagy egyszerű VM mellett is működik
• Több alkalmazás elé is odaállítható

A NameOcean-nál értékeljük azokat az eszközöket, amelyek egy dolgot jól csinálnak. Hodor nem akar teljes identitás-kezelő platform lenni, csak egy könnyű kapuőr, ami egy konkrét problémát old meg elegánsan.

Összefoglaló

Hodor egy filozófiát képvisel, amit érdemes lenne gyakrabban látni: a megoldást igazítsuk a valós problémához. Nem minden alkalmazásnak kell vállalati szintű autentikáció. Néha egy kis, fókuszált eszköz, ami az esetek 80 százalékát tökéletesen kezeli, jobb, mint egy nehézkes keretrendszer, ami a 100 százalékos elméleti esetet is le akarja fedni.

Ha Grafana-dashboardot, belső szolgáltatást vagy személyes projektet szeretnél védeni, Hodor érdemes eszköz lehet. Néha pont az ilyen egyszerű megoldások hiányoznak a fejlesztők eszköztárából.

Kezdés

A GitHubon megtalálod a projektet. A dokumentáció rövid, a telepítés pedig tényleg egyszerű. Ha eddig azért halogattad a védelmet, mert túl bonyolultnak tűnt, Hodor most már nem ad erre kifogást.

Egyszerű eszközök egyszerű problémákra. Néha pont erre van szükség.