Hodor – kevyin tapa suojata web-sovellus

Jokainen kehittäjä on törmännyt samaan pulmaan. On rakennettu kätevä sisäinen työkalu, staging-ympäristö tai monitorointipalvelu, mutta se pitäisi saada suojattua edes perusloginilla. Perinteinen reitti vie nopeasti syvään päätyyn: käyttäjätietokanta, salauskirjastot, OAuth-integraatiot ja sessioiden hallinta. Yksinkertainen suojauksen tarve paisuu hetkessä monimutkaiseksi projektiksi.

Hodor ratkaisee tilanteen toisin. Se on kevyt käänteinen välityspalvelin, jonka ainoa tehtävä on pyytää yksi yhteinen salasana ennen kuin käyttäjä pääsee varsinaiseen sovellukseen.

Milloin yksinkertainen ratkaisu riittää

Hodor ei yritä korvata täysimittaista kirjautumisjärjestelmää. Se sopii tilanteisiin, joissa riittää, että ulkopuoliset eivät pääse sisään. Ei käyttäjien hallintaa, ei tietokantaa, ei monimutkaista istuntojen käsittelyä. Yksi binääri, yksi salasana ja yksi kirjautumissivu.

Tämä lähestymistapa ei sovi julkisiin SaaS-palveluihin, mutta se toimii mainiosti sisäisissä työkaluissa, esittelyympäristöissä ja pienen tiimin dashboardeissa. Kun tiimi on pieni ja luottamus korkea, ylimääräinen monimutkaisuus on usein turhaa.

Arkkitehtuuri, joka jättää pois turhan

Hodorin vahvuus on siinä, mitä se ei sisällä:

• Ei käyttäjätietokantaa eikä CRUD-toimintoja
• Ei OAuth-integraatioita tai tokenien hallintaa
• Ei monimutkaista istuntojen tallennusta – vain yksinkertainen eväste
• Yksi binääri hoitaa kaiken

Asennus on suoraviivaista: aseta Hodor sovelluksen eteen reverse proxyksi, määritä salasana ja olet valmis.

Käyttökohteet, joissa Hodor loistaa

• Sisäiset dashboardit ja valvontatyökalut, joissa ei tarvita henkilökohtaista käyttäjähallintaa
• Staging- ja testausympäristöt, joihin halutaan nopea suojaus
• Proof-of-concept-sovellukset, joita esitellään sidosryhmille
• Pienet tiimiprojektit, joissa jaettu salasana on jo arkipäivää
• Itse ylläpidetyt palvelut, joihin halutaan kevyt suojauskerros

Mitä menetät – rehellinen katsaus

Yhteisellä salasanalla on selkeät rajoituksensa:

• Ei yksilöllistä audit trailia – kaikki näkyvät samana käyttäjänä
• Ei roolikohtaista pääsyoikeuksien rajoittamista
• Salasanan vaihto koskee kaikkia kerralla
• Salasana voi levitä sähköpostissa tai Slackissä

Nämä rajoitukset tekevät Hodorista sopivan lähinnä luotetuille ympäristöille, joissa jaettu salasana on jo totuttua käytäntöä.

Miten Hodor toimii käytännössä

Hodor istuu asiakkaan ja sovelluksen välissä. Kun käyttäjä yrittää avata sivua:

1. Hodor sieppaa pyynnön
2. Tarkistaa, onko eväste jo olemassa
3. Jos ei, näyttää kirjautumissivun
4. Oikealla salasanalla asetetaan eväste
5. Seuraavat pyynnöt välitetään suoraan sovellukselle

Prosessi on tarkoituksella yksinkertainen: ei monimutkaista token-logiikkaa, ei istuntojen tallennusta.

Turvallisuusnäkökulma

Yksi yhteinen salasana herättää ymmärrettävästi epäilyksiä. Hodor ei ole tarkoitettu tilanteisiin, joissa vaaditaan yksilöllistä pääsynhallintaa ja lokitusta. Se suojaa satunnaista pääsyä ja automaattista skannausta vastaan – ei kehittyneitä hyökkäyksiä.

Jos sovelluksessasi ei ole tällä hetkellä mitään suojausta, Hodor on selvä parannus. Jos jaat salasanoja jo Slackissä, Hodor ainakin formalisoi käytännön.

Käyttöönotto

Hodor asennetaan reverse proxyksi olemassa olevaan infrastruktuuriin. Se toimii Dockerissa, Kubernetesissa tai tavallisessa virtuaalikoneessa. HTTPS on käytännössä pakollinen, jotta salasana ei kulje selkokielisenä.

NameOceanin kaltaiset toimijat arvostavat työkaluja, jotka tekevät yhden asian hyvin. Hodor ei yritä olla kattava identiteetinhallintaratkaisu – se on kevyt portinvartija, joka ratkaisee rajatun ongelman tyylikkäästi.

Yhteenveto

Hodor edustaa filosofiaa, jota kehitystyökaluissa näkee liian harvoin: ratkaise todellinen ongelma ilman ylimääräistä painolastia. Kaikki sovellukset eivät tarvitse enterprise-tason autentikointia. Joskus yksi binääri ja yksi salasana riittävät.

Jos olet suunnitellut suojaavasi sisäistä työkalua mutta epäröinyt monimutkaisuuden takia, Hodor poistaa esteen. Yksinkertaiset työkalut yksinkertaisiin ongelmiin – juuri sellaista kehittäminen parhaimmillaan on.

Lähde: GitHub – michidk/hodor