Hvers vegna að verja lykilorð ef hægt er að sleppa því?

Vandamál sem við höfum vanist að líta á sem eðlilegt

Næstum öll vefforrit eru með stjórnborð. Og stjórnborð hefur yfirleitt innskráningarslóð, auðkenningareyðublað, notandanafn og lykilorð.

Við erum svo vön þessu fyrirkomulagi að við erum nánast hætt að spyrja okkur hvort allt þurfi endilega að virka svona.

Þegar maður er með eina vefsíðu virðist vandamálið ekki mikið. Maður býr til sterkt lykilorð, virkjar tveggja þátta auðkenningu, setur takmörk á innskráningartilraunir — og heldur áfram.

En hvað gerist þegar verkefnin verða tíu, tuttugu eða þrjátíu?

Í mínu tilviki er um að ræða DigiMeld-vistkerfið, sem sameinar meira en þrjátíu sjálfstæð hugbúnaðarverkefni. Hvert þeirra hefur sinn eigin arkitektúr, miðlararökfræði og stjórnviðmót.

Því þarf hvert verkefni fyrirkomulag fyrir stjórnandaaðgang.

Lengst af notaði ég hefðbundna aðferð: sérstök stjórnandaaðgangsgögn, sterk lykilorð og vistun þeirra í vafranum.

Það virkaði.

En á einhverjum tímapunkti fór ég að velta fyrir mér: hvers vegna ætti ég yfirhöfuð að geyma svona mörg stjórnandal lykilorð? Hvers vegna þarf ég ekki aðeins að verja miðlarana heldur líka leiðirnar til að fá aðgang að þeim?

Og er ekki hægt að sleppa þessari þörf?

Ég komst að þeirri niðurstöðu sem síðar varð grundvöllur lausnar minnar:

Kannski ætti að verja ekki stöðugan innskráningarpunkt, heldur réttinn til að fá tímabundinn aðgang.

Hvað ef hefðbundin innskráningarsíða væri alls ekki til?

Ég ákvað að hætta að nota hefðbundið fyrirkomulag stjórnandastaðfestingar í verkefnum mínum.

Ekki bara fela innskráningareyðublaðið.

Ekki endurnefna slóðina.

Ekki skipta lykilorðinu út fyrir enn flóknara lykilorð.

Heldur fjarlægja þörfina fyrir stöðuga innskráningu með lykilorði.

Stjórnviðmótin hurfu að sjálfsögðu ekki. Þau eru enn nauðsynleg til að stýra forritunum.

Aðferðin við að fá aðgang að þeim breyttist.

Nú þarf ekki að slá inn vistað notandanafn og lykilorð til að skrá sig inn á stjórnborð tengdra verkefna.

Í staðinn nota ég mitt eigið kerfi til auðkenningar og aðgangsstýringar, MeldID.

Hugmyndin er einföld: stjórnandaaðgangur er aðeins veittur þegar hans er raunverulega þörf, tilteknum notanda og að tilteknu verkefni.

Það eitt að vera með notandaaðgang veitir ekki sjálfkrafa rétt til að opna stjórnborðið.

Slíkur réttur þarf að vera veittur sérstaklega.

Aðgangur sem var ekki til mínútu fyrr

Þetta er líklega áhugaverðasti hluti hugmyndarinnar.

Í hefðbundnu fyrirkomulagi hefur stjórnandi stöðugt aðgangsheimildir. Hann getur notað þær í dag, á morgun eða eftir mánuð, svo lengi sem þær eru gildar.

Ég ákvað að breyta þessari meginreglu.

Í stað varanlegra stjórnandaaðgangsgagna er notuð tímabundin leið til að hefja innskráningu.

Hún er búin til að beiðni í gegnum traust farsímatæki, inniheldur dulritunarlega sterkan handahófsþátt og gildir í takmarkaðan tíma.

En það eitt að hafa þessa tímabundnu slóð veitir ekki aðgang.

Þetta er grundvallaratriði.

Segjum að einhver hafi með einhverjum hætti komist yfir slóðina. Í hefðbundnu kerfi sem byggir eingöngu á því að halda slóðinni leyndri gæti slíkur leki orðið alvarlegt vandamál.

Í mínu fyrirkomulagi gerir slóðin aðeins kleift að hefja staðfestingarferli.

Til að halda áfram þarf sérstakt samþykki í gegnum traust farsímatæki með MeldID.

Án viðeigandi staðfestingar verður stjórnandaseta ekki stofnuð.

Þess vegna lít ég á tímabundna slóð ekki sem staðgengil lykilorðs, heldur sem einn þátt í ferlinu við að veita aðgang.

Það er gjörólíkt að vita hvert á að leita og að hafa rétt til að skrá sig inn.

Síminn verður að verkfæri til að stýra aðgangi

Í þessu fyrirkomulagi gegnir farsímatækið mun mikilvægara hlutverki en að vera einfaldur rafall einnota kóða.

Það er notað til að staðfesta aðgerðir sem tengjast stjórnandaaðgangi.

Þegar ég vil opna stjórnborðið biður kerfið um staðfestingu í gegnum MeldID.

Ég sé viðkomandi beiðni í trausta tækinu mínu og samþykki aðgerðina.

Aðeins eftir að staðfestingin hefur tekist leyfir kerfið mér að halda innskráningarferlinu áfram.

Staðfestingin tengist tiltekinni aðgerð, en ekki einfaldlega því að síminn hafi verið opnaður.

Líffræðileg auðkenning í farsímanum staðfestir notandann í tækinu sjálfu en miðlarahliðin sannreynir dulritunarlega staðfestingu frá skráða tækinu.

Þessi aðferð gerir það að verkum að ekki er eingöngu treyst á lykilorð eða skilaboð um að notandinn hafi að sögn staðfest innskráninguna.

Þá kemur einnig fram annar kostur: hægt er að stýra traustum tækjum.

Ef tæki á ekki lengur að vera notað til að staðfesta aðgang er hægt að afturkalla traustsstöðu þess.

Eftir það er ekki lengur hægt að nota það til að heimila viðkomandi aðgerðir.

Eitt kerfi — mörg sjálfstæð verkefni

Þegar ég hóf þróun þessa fyrirkomulags var eitt helsta markmiðið að halda hverju verkefni sjálfstæðu.

Ég vildi ekki sameina öll stjórnborðin í eitt risastórt forrit.

Hver DigiMeld-þjónusta átti áfram að sjá sjálf um eigin rökfræði, stillingar, notendur og gögn.

Þess vegna aðgreindi ég þessi tvö verkefni.

MeldID sér um auðkenningu og veitingu heimilda til stjórnandaaðgangs.

Verkefnið sjálft sér um eigin stjórnandaaðgerðir og sannprófun á gildum heimildum.

Útkoman varð miðlægt fyrirkomulag aðgangsstýringar án þess að þurfa að miðstýra forritunum sjálfum.

Auk þess eru heimildir veittar sérstaklega.

Stjórnandi eins verkefnis fær ekki sjálfkrafa aðgang að hinum verkefnunum einungis vegna þess að hann er með MeldID-aðgang.

Hægt er að skilgreina sérstakan hóp heimilaðra notenda fyrir hvert stjórnandasvið.

Jafnframt eru réttindi almennra notenda aðskilin frá stjórnendaheimildum.

Þetta reyndist sérstaklega hentugt fyrir vistkerfi með tugi þjónusta.

Hvers vegna mér líkar tímabundinn aðgangur betur en varanlegur

Það er önnur meginregla sem ég byggði meðvitað inn í kerfið.

Stjórnandaaðgangur ætti ekki að vera til staðar endalaust.

Heimildin gildir í takmarkaðan tíma og fellur úr gildi óháð því hvort notandinn heldur áfram að vinna í vafranum.

Til að halda áfram eftir að gildistíminn rennur út þarf að fara í gegnum nýtt staðfestingarferli.

Þannig verður heimild sem var veitt einu sinni ekki að varanlegum rétti.

En tímamörk ein og sér duga ekki.

Það skiptir máli að geta bundið enda á aðgang sem þegar hefur verið veittur.

Þess vegna er miðlæg afturköllun stjórnandaheimilda í MeldID.

Þegar heimild er afturkölluð fá tengd verkefni tilkynningu um það og ógilda tilheyrandi stjórnandasetur.

Þannig lýkur aðgangsstýringunni ekki um leið og notandinn hefur skráð sig inn.

Mér finnst möguleikinn á að afturkalla heimildir ekki síður mikilvægur en möguleikinn á að veita þær.

Dreift kerfi þarf þó að taka mið af töfum á miðlun atburða, tímabundnu aðgengisleysi einstakra íhluta og öðrum rekstrarlegum aðstæðum. Tímamörk á gildistíma setna mynda viðbótarvörn.

Hvað breyttist í daglegu starfi?

Fyrst og fremst hvarf þörfin á að sækja sífellt í vistuð stjórnandal lykilorð.

Ég þarf ekki lengur að geyma safn aðgangsgagna í vafranum til að skrá mig inn á hvert tengt stjórnborð.

Í staðinn stýri ég heimildum með sameiginlegu kerfi.

Ég vel verkefnið sem ég þarf, staðfesti aðganginn og vinn áfram.

Þegar stjórnandaaðgangsins er ekki lengur þörf er hægt að afturkalla hann.

Það er sérstaklega þægilegt að þegar nýtt verkefni bætist við þarf ekki að endurhanna allt kerfið fyrir stjórnandastaðfestingu.

Nóg er að tengja það við núverandi fyrirkomulag og skilgreina nauðsynlegar heimildir.

Þetta þýðir auðvitað ekki að öll öryggisáhætta sé horfin.

Tímabundnar heimildir, traust tæki, setur á miðlarahlið og miðlægir innviðir þurfa líka vernd.

En ég þarf ekki lengur að leysa sama vandamálið við stjórnun stjórnandal lykilorða sérstaklega fyrir hvert forrit.

Og það var eitt af upphaflegu markmiðum mínum.

Eru slíkar tæknilausnir ekki þegar til?

Jú, þær eru til.

Lykilorðslaus auðkenning, stjórnun forréttindaaðgangs, tímabundnar heimildir og staðfesting í gegnum traust tæki hafa lengi verið þekkt í upplýsingaöryggisgeiranum.

Slíkar aðferðir finnast í kerfum fyrir auðkennis- og aðgangsstjórnun (Identity and Access Management), stjórnun forréttindaaðgangs (Privileged Access Management) og hugmyndafræði Zero Trust.

Ég geri ekki tilkall til þess að hafa fundið upp þessar meginreglur.

Verkefni mitt var annað.

Ég þurfti að búa til mitt eigið samþætta kerfi sem leysir tiltekin vandamál í innviðum DigiMeld og gerir kleift að stýra stjórnandaaðgangi að mörgum sjálfstæðum verkefnum.

Útkoman varð sú að ég sameinaði nokkrar þekktar aðferðir í einn arkitektúr sem uppfyllir kröfur mínar.

Og ég tel að gildi verkfræðilegrar vinnu felist ekki endilega í því að finna upp alveg nýja tækni.

Stundum felst það í því að skilgreina vandamálið rétt og finna lausn sem hentar því.

MeldID er ekki aðeins fyrir stjórnborð

Hér er rétt að taka eitt sérstaklega fram.

MeldID var ekki búið til eingöngu sem verkfæri fyrir minn eigin stjórnandaaðgang.

Það býður einnig þróunaraðilum upp á SDK til að samþætta auðkenningu og staðfestingu innskráningar í eigin forrit.

Þetta SDK er að auki ókeypis.

Til dæmis getur utanaðkomandi þróunaraðili notað MeldID sem viðbótarstaðfestingu á auðkenningu notenda.

Jafnvel þótt forritið haldi hefðbundinni innskráningu með notandanafni og lykilorði, þarf ekki að nægja að slá þau rétt inn til að ljúka auðkenningunni.

Notandinn fær beiðni í traust farsímatæki þar sem hann getur samþykkt eða hafnað innskráningartilrauninni.

Þetta getur dregið úr hættunni á óheimilum aðgangi ef aðgangsgögn komast í rangar hendur.

Mikilvægt er að greina á milli þessa aðgengilega möguleika MeldID og þess fyrirkomulags stjórnandaaðgangs sem ég þróaði fyrir DigiMeld-verkefnin.

Þau byggja á sameiginlegum meginreglum um traust og staðfestingu aðgerða, en leysa ólík verkefni.

Öryggi snýst ekki aðeins um að verja það sem þegar er til

Vinnan við þetta kerfi fékk mig til að líta öðrum augum á hefðbundnar aðferðir við auðkenningu.

Við reynum oft að verja það sem er til af sögulegum ástæðum.

Við bætum við nýjum sannprófunum, takmörkunum, viðbótarlykilorðum og öryggislögum.

Stundum er það sannarlega nauðsynlegt.

En stundum er gagnlegra að spyrja annarrar spurningar:

Þarf fyrirkomulagið sem við erum að verja endilega að vera til í sinni gömlu mynd?

Í mínu tilviki var svarið nei.

Ég þurfti ekki innskráningareyðublað stjórnanda sem væri alltaf aðgengilegt.

Ég þurfti að geta fengið stjórnandaheimildir á öruggan hátt einmitt þegar þeirra væri þörf.

Þetta eru tvö ólík verkefni.

Og breytingin frá því fyrra yfir í það síðara breytti ekki aðeins tæknilegum arkitektúr heldur líka daglegri vinnu með verkefnin.

Ekki endanleg niðurstaða heldur stefna sem ég hef valið

Í dag er þessi arkitektúr þegar í notkun í stórum hluta DigiMeld-vistkerfisins.

Verið er að færa þau verkefni sem eftir standa smám saman yfir í nýja fyrirkomulagið fyrir stjórnandaaðgang.

Ég framkvæmi yfirfærsluna í áföngum, prófa hvert forrit og hyggst gera viðbótarúttekt á öllu kerfinu þegar yfirfærslunni lýkur.

Einstök viðmótsatriði og reglur um setustjórnun geta enn breyst.

En meginhugmyndin er þegar mótuð.

Ég vil ekki snúa aftur að fyrirkomulagi þar sem ég þarf stöðugt að geyma og nota tugi stjórnandal lykilorða til að stýra tugum eigin verkefna.

Jafnframt tel ég ekki mína eigin útfærslu vera algilda lausn fyrir alla.

Mismunandi fyrirtæki hafa ólíkar kröfur, innviði, ógnarlíkön og aðferðir við kerfisstjórnun.

Það sem er hentugt og réttlætanlegt fyrir DigiMeld-vistkerfið reynist ekki endilega besti kosturinn fyrir annan þróunaraðila.

Hins vegar er meginreglan um tímabundna veitingu heimilda þess virði að gefa gaum.

Að lokum

Ég ákvað að deila þessari reynslu ekki vegna þess að ég telji mig hafa fundið upp nýja auðkenningaraðferð.

Og ekki vegna þess að ég vilji kynna enn eitt kerfið sem fullkomlega öruggt.

Algert öryggi er ekki til.

Mér finnst einfaldlega áhugavert hvernig spurningin er sett fram.

Í stað þess að verja stöðugan stjórnandaaðgang endalaust er hægt að endurskoða hvort hann þurfi yfirhöfuð að vera til.

Í stað þess að geyma fjölda lykilorða er hægt að nota tímabundnar heimildir.

Í stað þess að veita sjálfvirkt traust eftir fyrstu auðkenningu er hægt að staðfesta veitingu tiltekinna heimilda.

Í stað þess að bíða eftir að setu ljúki er hægt að gera ráð fyrir miðlægri afturköllun aðgangs.

Og að lokum, í stað þess að hafa sérstakt innskráningarkerfi í hverju verkefni er hægt að byggja sameiginlegt kerfi til að stýra heimildum til stjórnandaaðgangs, án þess að skerða sjálfstæði forritanna.

Ég fullyrði ekki að þessi aðferð útiloki möguleikann á að kerfið verði brotist inn í.

Hún færir einfaldlega áhersluna frá því að verja aðgangsgögn sem eru stöðugt til staðar yfir í stýrða veitingu og afturköllun heimilda.

Kannski er skilvirkasta leiðin til að minnka árásarflötinn stundum ekki að bæta við enn einu öryggisúrræði, heldur að sleppa því sem kerfið getur vel starfað án.

Það var þessi hugmynd sem markaði upphaf sögunnar um MeldID Admin Gateway fyrir mér.