Hvorfor beskytte et passord hvis man kan klare seg uten?

Et problem vi har blitt vant til å betrakte som normalt

Nesten alle nettapplikasjoner har et administrasjonspanel. Og et administrasjonspanel har som regel en innloggingsadresse, et autentiseringsskjema, et brukernavn og et passord.

Vi har blitt så vant til denne løsningen at vi nesten har sluttet å spørre oss selv: Må det egentlig fungere akkurat slik?

Når du har ett nettsted, virker ikke problemet særlig stort. Du lager et sterkt passord, aktiverer tofaktorautentisering, begrenser antall innloggingsforsøk – og setter i gang.

Men hva skjer når du har ti, tjue eller tretti prosjekter?

I mitt tilfelle dreier det seg om DigiMeld-økosystemet, som består av mer enn tretti selvstendige programvareprosjekter. Hvert prosjekt har sin egen arkitektur, serverlogikk og administrasjonsgrensesnitt.

Det betyr at hvert prosjekt trenger en mekanisme for administratortilgang.

Jeg brukte lenge en ganske vanlig tilnærming: egne administratorkontoer, sterke passord og lagring av dem i nettleseren.

Det fungerte.

Men på et tidspunkt begynte jeg å lure: Hvorfor må jeg egentlig lagre så mange administratorpassord? Hvorfor må jeg beskytte ikke bare serverne, men også selve måtene å få tilgang til dem på?

Og er det mulig å slippe dette behovet?

Jeg kom fram til en tanke som senere ble grunnlaget for løsningen min:

Kanskje bør man beskytte retten til å få tilgang midlertidig, i stedet for en permanent inngang.

Et sterkt passord løser ikke selve problemet

Moderne verktøy gjør det mulig å lage passord med svært høy entropi. Et langt, tilfeldig passord som er generert på riktig måte, er praktisk talt umulig å gjette ved hjelp av uttømmende søk.

Men uansett hvor sterkt passordet er, må det lagres et sted og brukes senere.

Man kan bruke passordbehandlere, maskinvarenøkler, flerfaktorautentisering og ekstra begrensninger. Alt dette øker faktisk sikkerheten.

Men den samme arkitektoniske løsningen består: Det finnes et bestemt grensesnitt der brukeren oppgir påloggingsinformasjonen sin.

Det kan sendes forespørsler til dette grensesnittet. Det kan skannes. Det kan bli mål for automatiserte angrep.

Man kan skjule adressen til administrasjonspanelet, erstatte standardstien med en lang, tilfeldig tegnsekvens eller begrense tilgangen etter IP-adresse.

Men da dukker et nytt spørsmål opp: Hvor skal adressen lagres, og hvordan skal den brukes?

Og viktigst av alt: Hvorfor beholde et permanent inngangspunkt når man bare trenger administratortilgang fra tid til annen?

Jeg kom fram til en tanke som senere ble grunnlaget for løsningen min:

Kanskje bør man beskytte retten til å få tilgang midlertidig, i stedet for en permanent inngang.

Hva om den vanlige innloggingssiden ikke fantes i det hele tatt?

Jeg bestemte meg for å gå bort fra den tradisjonelle modellen for administrativ autentisering i prosjektene mine.

Ikke bare skjule innloggingsskjemaet.

Ikke endre adressen.

Ikke erstatte passordet med et enda sterkere passord.

Men fjerne behovet for en permanent passordbasert innlogging.

Administrasjonsgrensesnittene forsvant naturligvis ikke. De er fortsatt nødvendige for å administrere applikasjonene.

Det som endret seg, var måten man får tilgang til dem på.

Nå trenger jeg ikke å oppgi et lagret brukernavn og passord for å logge inn i administrasjonspanelene til de tilkoblede prosjektene.

I stedet bruker jeg MeldID, mitt eget system for identifisering og tilgangsstyring.

Prinsippet er ganske enkelt: Administratortilgang gis bare når den faktisk trengs, til en bestemt bruker og for et bestemt prosjekt.

At man har en brukerkonto, betyr ikke i seg selv at man har rett til å åpne administrasjonspanelet.

Den retten må tildeles separat.

Tilgang som ikke fantes for et minutt siden

Dette er kanskje den mest interessante delen av hele konseptet.

I den tradisjonelle modellen har administratoren alltid tilgangsinformasjonen tilgjengelig. Den kan brukes i dag, i morgen eller om en måned, så lenge den fortsatt er gyldig.

Jeg bestemte meg for å endre dette prinsippet.

I stedet for permanente administratoropplysninger brukes en midlertidig mulighet til å starte en innlogging.

Den opprettes på forespørsel via en betrodd mobilenhet, inneholder en kryptografisk sterk tilfeldig komponent og har begrenset gyldighetstid.

Men selv det å ha denne midlertidige lenken gir ikke i seg selv tilgang.

Dette er et grunnleggende poeng.

La oss si at noen på en eller annen måte får tak i lenken. I et vanlig system som utelukkende bygger på at adressen holdes hemmelig, kan en slik lekkasje bli et alvorlig problem.

I modellen min gjør lenken det bare mulig å starte en bekreftelsesprosess.

For å fortsette kreves en separat godkjenning via en betrodd mobilenhet med MeldID.

Uten den aktuelle bekreftelsen opprettes det ingen administratørøkt.

Derfor ser jeg ikke på den midlertidige lenken som en erstatning for passordet, men som ett av elementene i prosessen for å gi tilgang.

Å vite hvor man skal henvende seg, og å ha rett til å logge inn, er to helt forskjellige ting.

Telefonen blir et verktøy for tilgangsstyring

I denne modellen spiller mobilenheten en langt viktigere rolle enn en vanlig generator for engangskoder.

Den brukes til å bekrefte handlinger knyttet til administratortilgang.

Når jeg vil åpne administrasjonspanelet, ber systemet om bekreftelse via MeldID.

Jeg ser den aktuelle forespørselen på den betrodde enheten og bekrefter handlingen.

Først etter en vellykket kontroll lar systemet meg fortsette innloggingsprosessen.

Bekreftelsen er knyttet til en bestemt handling, ikke bare til at telefonen er låst opp.

Biometrisk autentisering på mobilenheten bekrefter brukeren lokalt, mens serversiden kontrollerer den kryptografiske bekreftelsen fra den registrerte enheten.

Denne tilnærmingen gjør det mulig å unngå å stole utelukkende på et passord eller en melding om at brukeren angivelig har bekreftet innloggingen.

Og her dukker det opp enda en fordel: Man kan administrere betrodde enheter.

Hvis en enhet ikke lenger skal brukes til å bekrefte tilgang, kan den betrodde statusen trekkes tilbake.

Da slutter den å være et gyldig autentiseringsmiddel for de aktuelle handlingene.

Én løsning – mange uavhengige prosjekter

Da jeg begynte å utvikle denne mekanismen, var det en av de viktigste oppgavene å bevare hvert enkelt prosjekts selvstendighet.

Jeg ville ikke samle alle administrasjonspanelene i én stor applikasjon.

Hver DigiMeld-tjeneste skal fortsatt administrere sin egen logikk, sine egne innstillinger, brukere og data.

Derfor skilte jeg mellom to oppgaver.

MeldID håndterer identifisering og tildeling av administrativ tilgang.

Selve prosjektet håndterer sine egne administrative funksjoner og kontrollerer gjeldende rettigheter.

Resultatet ble en sentralisert modell for tilgangsstyring uten at selve applikasjonene måtte sentraliseres.

I tillegg tildeles rettighetene separat.

En administrator for ett prosjekt får ikke automatisk tilgang til de andre bare fordi vedkommende har en MeldID-konto.

Man kan definere en egen gruppe godkjente brukere for hvert administrasjonsområde.

Samtidig holdes vanlige brukerrettigheter og administrative fullmakter adskilt.

Dette viste seg å være spesielt praktisk for et økosystem med flere titalls tjenester.

Hvorfor jeg foretrekker midlertidig tilgang framfor permanent tilgang

Det er enda et prinsipp jeg bevisst bygde inn i systemet.

Administratortilgang skal ikke vare på ubestemt tid.

Tillatelsen gjelder i en begrenset periode og utløper uavhengig av om brukeren fortsatt arbeider i nettleseren.

Hvis man vil fortsette etter at tillatelsen har utløpt, må man gjennom en ny bekreftelsesprosess.

Dermed unngår man at en gjennomført autentisering én gang blir til en permanent gyldig rettighet.

Men tidsbegrensning alene er ikke nok.

Det er viktig å kunne avslutte tilgang som allerede er gitt, før tiden er ute.

Derfor har MeldID en sentralisert funksjon for å trekke tilbake administratortillatelser.

Når en tillatelse trekkes tilbake, mottar de tilkoblede prosjektene den aktuelle hendelsen og ugyldiggjør tilknyttede administratørøkter.

Dermed slutter ikke tilgangsstyringen i det øyeblikket brukeren har logget inn.

Muligheten til å trekke tilbake fullmakter er ikke mindre viktig for meg enn muligheten til å gi dem.

Samtidig må et distribuert system ta høyde for forsinkelser i overføringen av hendelser, midlertidig utilgjengelighet for enkelte komponenter og andre driftsforhold. Begrenset gyldighetstid for øktene utgjør en ekstra sikkerhetsgrense.

Hva har endret seg i det daglige arbeidet?

Først og fremst trenger jeg ikke lenger å hente fram lagrede administratorpassord hele tiden.

Jeg trenger ikke lenger å lagre et sett med påloggingsopplysninger i nettleseren for hvert tilkoblede administrasjonspanel.

I stedet styrer jeg tillatelsene gjennom én felles mekanisme.

Jeg velger prosjektet jeg trenger, bekrefter tilgangen og setter i gang.

Når jeg ikke lenger trenger administratortilgang, kan den trekkes tilbake.

Det er spesielt praktisk at jeg ikke trenger å utforme hele systemet for administrativ autentisering på nytt hver gang et nytt prosjekt kommer til.

Det holder å koble prosjektet til den eksisterende modellen og definere de nødvendige tillatelsene.

Dette betyr naturligvis ikke at alle sikkerhetsrisikoer har forsvunnet.

Midlertidige tillatelser, betrodde enheter, serverøkter og den sentrale infrastrukturen må også beskyttes.

Men jeg trenger ikke lenger å løse det samme problemet med administrasjon av administratorpassord separat for hver applikasjon.

Og nettopp dette var et av de opprinnelige målene mine.

Finnes ikke lignende teknologier allerede?

Jo, det gjør de.

Passordfri autentisering, styring av privilegert tilgang, midlertidige tillatelser og bekreftelse via betrodde enheter har vært kjent i informasjonssikkerhetsbransjen lenge.

Slike tilnærminger brukes i systemer for Identity and Access Management, Privileged Access Management og Zero Trust-konsepter.

Jeg gjør ikke krav på å ha funnet opp disse prinsippene.

Oppgaven min var en annen.

Jeg trengte å lage et eget, integrert system som løser konkrete problemer i DigiMeld-infrastrukturen og gjør det mulig å styre administratortilgang på tvers av mange selvstendige prosjekter.

Resultatet ble at jeg samlet flere kjente tilnærminger i én arkitektur som oppfyller kravene mine.

Jeg mener at verdien av ingeniørarbeid ikke nødvendigvis ligger i å finne opp en helt ny teknologi.

Noen ganger ligger den i å formulere problemet riktig og finne en løsning som passer.

MeldID er ikke bare for administrasjonspaneler

Her er det verdt å presisere én ting.

MeldID ble ikke utviklet utelukkende som et verktøy for min egen administratortilgang.

Det tilbyr også utviklere et SDK for å integrere mekanismer for identifisering og bekreftelse av innlogging i sine egne applikasjoner.

SDK-et er dessuten tilgjengelig gratis.

En tredjepartsutvikler kan for eksempel bruke MeldID som et ekstra lag for å bekrefte brukerautentisering.

Selv om applikasjonen fortsatt bruker tradisjonell innlogging med brukernavn og passord, er det ikke sikkert at det er nok å oppgi disse opplysningene for å fullføre autentiseringen.

Brukeren får en forespørsel på en betrodd mobilenhet, der vedkommende kan bekrefte eller avvise innloggingsforsøket.

Dette kan redusere risikoen for uautorisert tilgang dersom påloggingsopplysningene kommer på avveie.

Det er viktig å skille mellom denne allment tilgjengelige funksjonen i MeldID og modellen for administratortilgang til DigiMeld-prosjektene som jeg har utviklet.

De bygger på de samme prinsippene om tillit og bekreftelse av handlinger, men løser ulike oppgaver.

Sikkerhet handler ikke bare om å beskytte det som allerede finnes

Arbeidet med dette systemet fikk meg til å se annerledes på de vanlige autentiseringsmekanismene.

Vi prøver ofte å beskytte noe som eksisterer av historiske årsaker.

Vi legger til nye kontroller, begrensninger, ekstra passord og sikkerhetslag.

Noen ganger er det virkelig nødvendig.

Men noen ganger er det mer nyttig å stille et annet spørsmål:

Må mekanismen vi beskytter, egentlig eksistere i sin nåværende form?

I mitt tilfelle var svaret nei.

Jeg trengte ikke et administrativt innloggingsskjema som alltid var tilgjengelig.

Jeg trengte muligheten til å få administrativ tilgang på en sikker måte akkurat når jeg hadde behov for den.

Dette er to forskjellige oppgaver.

Overgangen fra den første til den andre endret ikke bare den tekniske arkitekturen, men også det daglige arbeidet med prosjektene.

Ikke en endelig konklusjon, men en valgt retning

I dag er denne arkitekturen allerede i bruk i en betydelig del av DigiMeld-økosystemet.

De gjenværende prosjektene flyttes gradvis over til den nye modellen for administratortilgang.

Jeg gjennomfører migreringen trinnvis, kontrollerer hvert enkelt program og planlegger en ekstra gjennomgang av hele systemet når overgangen er fullført.

Enkelte deler av grensesnittet og reglene for øktstyring kan fortsatt endres.

Men hovedideen er allerede fastlagt.

Jeg vil ikke tilbake til en modell der jeg må lagre og bruke dusinvis av administratorpassord for å administrere dusinvis av egne prosjekter.

Samtidig mener jeg ikke at min løsning er universell for alle.

Ulike organisasjoner har ulike krav, infrastrukturer, trusselmodeller og administrasjonsmetoder.

Det som er praktisk og hensiktsmessig for DigiMeld-økosystemet, er ikke nødvendigvis det beste valget for en annen utvikler.

Likevel er prinsippet om å tildele fullmakter midlertidig verdt å merke seg.

Til slutt

Jeg bestemte meg for å dele denne erfaringen, ikke fordi jeg ser på meg selv som oppfinneren av en ny autentiseringsmetode.

Og heller ikke fordi jeg vil presentere enda et system som fullstendig sikkert.

Absolutt sikkerhet finnes ikke.

Jeg synes ganske enkelt selve måten å stille spørsmålet på er interessant.

I stedet for å beskytte en permanent administrativ innlogging i det uendelige kan man revurdere om den trenger å finnes.

I stedet for å lagre mange passord kan man bruke midlertidige tillatelser.

I stedet for automatisk tillit etter den første autentiseringen kan man bekrefte at bestemte fullmakter blir gitt.

I stedet for å vente på at økten utløper kan man legge til rette for å trekke tilbake tilgangen sentralt.

Og til slutt: I stedet for en egen innloggingsmekanisme i hvert prosjekt kan man bygge ett felles system for å styre administrativ tilgang, samtidig som applikasjonene beholder sin selvstendighet.

Jeg påstår ikke at denne tilnærmingen utelukker muligheten for kompromittering.

Den flytter bare fokuset fra å beskytte påloggingsopplysninger som alltid finnes, til kontrollert tildeling og tilbakekalling av fullmakter.

Kanskje er den mest effektive måten å redusere angrepsflaten på noen ganger ikke å legge til enda et sikkerhetstiltak, men å fjerne noe systemet fint kan fungere uten.

Det var nettopp denne tanken som ble starten på historien om MeldID Admin Gateway for meg.