Hvorfor beskytte en adgangskode, hvis man kan undvære den?

Et problem, vi er vant til at betragte som normalt

Stort set alle webapplikationer har et administrationspanel. Og et administrationspanel har som regel en loginadresse, en loginformular, et brugernavn og en adgangskode.

Vi er blevet så vant til denne konstruktion, at vi næsten er holdt op med at spørge os selv: Skal det absolut fungere sådan?

Når man har ét website, virker problemet ikke særligt stort. Man opretter en stærk adgangskode, aktiverer tofaktorgodkendelse, begrænser antallet af loginforsøg – og så er man i gang.

Men hvad sker der, når man får ti, tyve eller tredive projekter?

I mit tilfælde drejer det sig om DigiMeld-økosystemet, der samler mere end tredive selvstændige softwareprojekter. Hvert projekt har sin egen arkitektur, serverlogik og administrationsgrænseflade.

Derfor har hvert projekt brug for en mekanisme til administrativ adgang.

I lang tid brugte jeg en helt almindelig metode: separate administrative loginoplysninger, stærke adgangskoder og lagring af dem i browseren.

Det fungerede.

Men på et tidspunkt begyndte jeg at tænke over det: Hvorfor skal jeg egentlig opbevare så mange administrative adgangskoder? Hvorfor skal jeg beskytte ikke kun serverne, men også selve midlerne til at få adgang til dem?

Og kan jeg undgå det?

Jeg nåede frem til en tanke, der senere blev grundlaget for min løsning:

Måske bør man beskytte retten til at få midlertidig adgang i stedet for en permanent indgang.

En stærk adgangskode fjerner ikke selve problemet

Moderne værktøjer gør det muligt at oprette adgangskoder med meget høj entropi. En korrekt genereret, lang og tilfældig adgangskode er praktisk talt umulig at gætte ved hjælp af brute force.

Men uanset hvor stærk adgangskoden er, skal den opbevares et sted og derefter bruges.

Man kan bruge adgangskodeadministratorer, hardware-nøgler, multifaktorgodkendelse og yderligere begrænsninger. Alt dette øger reelt sikkerheden.

Men selve arkitekturen består stadig: Der findes en bestemt grænseflade, hvor brugeren angiver sine loginoplysninger.

Der kan sendes forespørgsler til den. Den kan scannes. Den kan blive mål for automatiserede angreb.

Man kan skjule adressen til administrationspanelet, erstatte standardstien med en lang, tilfældig tegnsekvens eller begrænse adgangen efter IP-adresse.

Men så opstår et nyt spørgsmål: Hvor skal adressen opbevares, og hvordan skal man bruge den?

Og vigtigst af alt: Hvorfor bevare en permanent indgang, når der kun er brug for administrativ adgang på bestemte tidspunkter?

Jeg nåede frem til en tanke, der senere blev grundlaget for min løsning:

Måske bør man beskytte retten til at få midlertidig adgang i stedet for en permanent indgang.

Hvad nu, hvis den velkendte login-side slet ikke findes?

Jeg besluttede at droppe den traditionelle model for administrativ godkendelse i mine projekter.

Ikke bare skjule loginformularen.

Ikke omdøbe adressen.

Ikke erstatte adgangskoden med en endnu stærkere adgangskode.

Men fjerne behovet for et permanent login med adgangskode.

Administrationsgrænsefladerne forsvandt naturligvis ikke. De er stadig nødvendige for at administrere applikationerne.

Det var måden at få adgang til dem på, der ændrede sig.

Nu behøver jeg ikke indtaste et gemt brugernavn og en gemt adgangskode for at logge ind på administrationspanelerne i de tilknyttede projekter.

I stedet bruger jeg mit eget system til identifikation og adgangsstyring, MeldID.

Grundideen er enkel: Administrativ adgang gives kun, når der faktisk er brug for den, til en bestemt bruger og til et bestemt projekt.

Det forhold, at man har en konto, giver ikke i sig selv ret til at åbne administrationspanelet.

Den ret skal tildeles særskilt.

Adgang, der ikke fandtes for et minut siden

Det er nok den mest interessante del af hele konceptet.

I den traditionelle model har administratoren altid adgangsmidlerne. De kan bruges i dag, i morgen eller om en måned, så længe de stadig er gyldige.

Jeg besluttede at ændre dette princip.

I stedet for permanente administrative loginoplysninger bruges en midlertidig mulighed for at starte et login.

Den oprettes på anmodning via en betroet mobilenhed, indeholder en kryptografisk stærk tilfældig komponent og har en begrænset gyldighedsperiode.

Men selv det at have et sådant midlertidigt link giver ikke i sig selv adgang.

Det er et afgørende punkt.

Antag, at nogen på en eller anden måde får fat i linket. I et almindeligt system, der udelukkende bygger på, at adressen er hemmelig, kunne et sådant læk blive et alvorligt problem.

I min model giver linket kun mulighed for at starte en bekræftelsesproces.

For at fortsætte kræves der en separat godkendelse via en betroet mobilenhed med MeldID.

Uden den nødvendige bekræftelse oprettes der ingen administrativ session.

Derfor betragter jeg ikke det midlertidige link som en erstatning for adgangskoden, men som et af elementerne i processen for at tildele adgang.

At vide, hvor man skal henvende sig, og at have ret til at logge ind er to helt forskellige ting.

Telefonen bliver et værktøj til adgangsstyring

I denne model spiller mobilenheden en langt vigtigere rolle end en almindelig generator af engangskoder.

Den bruges til at bekræfte handlinger, der vedrører administrativ adgang.

Når jeg vil åbne administrationspanelet, anmoder systemet om en bekræftelse via MeldID.

Jeg ser den relevante anmodning på den betroede enhed og bekræfter handlingen.

Først efter en vellykket kontrol tillader systemet, at loginprocessen fortsætter.

Bekræftelsen er knyttet til en bestemt handling og ikke blot til, at telefonen er blevet låst op.

Mobilens biometriske funktioner kontrollerer brugeren lokalt, mens serversiden kontrollerer den kryptografiske bekræftelse fra den registrerede enhed.

Med denne tilgang behøver man ikke udelukkende at stole på en adgangskode eller på en meddelelse om, at brugeren angiveligt har bekræftet login.

Og her opstår endnu en fordel: Man kan administrere de betroede enheder.

Hvis en enhed ikke længere skal bruges til at bekræfte adgang, kan dens status som betroet tilbagekaldes.

Derefter kan den ikke længere bruges til at godkende de relevante handlinger.

Ét system – mange uafhængige projekter

Da jeg begyndte at udvikle denne mekanisme, var det en af de vigtigste opgaver at bevare hvert projekts selvstændighed.

Jeg ønskede ikke at samle alle administrationspanelerne i én stor applikation.

Hver DigiMeld-tjeneste skal fortsat administrere sin egen logik, sine egne indstillinger, brugere og data.

Derfor adskilte jeg de to opgaver.

MeldID står for identifikation og tildeling af administrativ adgang.

Selve projektet står for sine egne administrative funktioner og kontrollen af de gældende tilladelser.

Resultatet blev en centraliseret model for adgangsstyring uden at centralisere selve applikationerne.

Desuden tildeles rettigheder særskilt.

En administrator for ét projekt får ikke automatisk adgang til de andre, blot fordi vedkommende har en MeldID-konto.

Man kan fastlægge en særskilt gruppe af autoriserede brugere for hvert administrativt område.

Almindelige brugerrettigheder og administrative beføjelser holdes adskilt.

Det viste sig at være særligt praktisk for et økosystem med snesevis af tjenester.

Hvorfor jeg foretrækker midlertidig adgang frem for permanent adgang

Der er endnu et princip, som jeg bevidst har indbygget i systemet.

Administrativ adgang bør ikke vare evigt.

Tilladelsen gælder i en begrænset periode og udløber, uanset om brugeren fortsat arbejder i browseren.

Hvis arbejdet skal fortsætte, efter perioden er udløbet, kræves der en ny bekræftelsesproces.

Det forhindrer, at en gennemført godkendelse bliver til en permanent gældende tilladelse.

Men en tidsbegrænsning er ikke nok i sig selv.

Det er vigtigt at kunne afslutte adgangen før tid.

Derfor giver MeldID mulighed for centralt at tilbagekalde administrative tilladelser.

Når en tilladelse tilbagekaldes, modtager de tilknyttede projekter den tilsvarende hændelse og annullerer de tilhørende administrative sessioner.

Dermed slutter adgangsstyringen ikke, i det øjeblik brugeren er logget ind.

For mig er muligheden for at tilbagekalde beføjelser lige så vigtig som muligheden for at tildele dem.

Et distribueret system skal samtidig tage højde for forsinkelser i overførslen af hændelser, midlertidig utilgængelighed af enkelte komponenter og andre driftsmæssige forhold. Begrænsningen af sessionernes gyldighedsperiode udgør en ekstra sikkerhedsgrænse.

Hvad har ændret sig i det daglige arbejde?

Først og fremmest er behovet for hele tiden at bruge gemte administrative adgangskoder forsvundet.

Jeg behøver ikke længere at opbevare et sæt loginoplysninger i browseren til hvert tilknyttet administrationspanel.

I stedet administrerer jeg tilladelserne gennem én samlet mekanisme.

Jeg vælger det nødvendige projekt, bekræfter adgangen og går i gang.

Når der ikke længere er brug for administrativ adgang, kan den tilbagekaldes.

Det er især praktisk, at man ikke behøver at gentænke hele systemet til administrativ godkendelse, hver gang der kommer et nyt projekt.

Det er nok at tilknytte det til den eksisterende model og fastlægge de nødvendige tilladelser.

Det betyder naturligvis ikke, at alle sikkerhedsrisici er forsvundet.

Midlertidige tilladelser, betroede enheder, serversessioner og central infrastruktur skal også beskyttes.

Men jeg behøver ikke længere løse den samme opgave med administration af adgangskoder separat for hver applikation.

Og det var netop et af mine oprindelige mål.

Findes den slags teknologier ikke allerede?

Jo, det gør de.

Adgangskodefri godkendelse, administration af privilegeret adgang, midlertidige tilladelser og bekræftelse via betroede enheder har længe været kendt i informationssikkerhedsbranchen.

Man møder disse tilgange i systemer til Identity and Access Management, Privileged Access Management og Zero Trust-koncepter.

Jeg gør ikke krav på at have opfundet disse principper.

Min opgave var en anden.

Jeg havde brug for at skabe et integreret system, der løser konkrete problemer i DigiMeld-infrastrukturen og gør det muligt at administrere adgang til flere selvstændige projekter.

Resultatet blev, at jeg samlede flere kendte tilgange i én arkitektur, der opfylder mine krav.

Og jeg mener, at værdien af ingeniørarbejde ikke nødvendigvis ligger i at opfinde en helt ny teknologi.

Nogle gange ligger den i at formulere problemet korrekt og finde en passende løsning.

MeldID er ikke kun til administrationspaneler

Her er det værd at præcisere én ting.

MeldID blev ikke skabt udelukkende som et værktøj til min egen administrative adgang.

Det giver også udviklere et SDK til at integrere mekanismer til identifikation og bekræftelse af login i deres egne applikationer.

Og dette SDK er gratis tilgængeligt.

En ekstern udvikler kan for eksempel bruge MeldID som et ekstra lag til bekræftelse af brugergodkendelse.

Selv hvis applikationen stadig bruger traditionelt login med brugernavn og adgangskode, er det måske ikke nok at indtaste disse oplysninger korrekt for at fuldføre godkendelsen.

Brugeren modtager en anmodning på sin betroede mobilenhed, hvor vedkommende kan bekræfte eller afvise loginforsøget.

Det mindsker risikoen for uautoriseret adgang, hvis loginoplysningerne bliver kompromitteret.

Det er vigtigt at skelne mellem denne offentligt tilgængelige funktion i MeldID og den model for administrativ adgang til DigiMeld-projekterne, som jeg har udviklet.

De bygger på fælles principper om tillid og bekræftelse af handlinger, men løser forskellige opgaver.

Sikkerhed handler ikke kun om at beskytte det, der allerede findes

Arbejdet med dette system fik mig til at se anderledes på de velkendte godkendelsesmekanismer.

Vi forsøger ofte at beskytte noget, der findes af historiske årsager.

Vi tilføjer nye kontroller, begrænsninger, ekstra adgangskoder og sikkerhedslag.

Nogle gange er det virkelig nødvendigt.

Men nogle gange er det mere nyttigt at stille et andet spørgsmål:

Er det nødvendigt, at den mekanisme, vi beskytter, stadig findes i sin nuværende form?

I mit tilfælde var svaret nej.

Jeg havde ikke brug for en administrativ loginformular, der altid var tilgængelig.

Jeg havde brug for en sikker måde at få administrative beføjelser på, præcis når der var behov for dem.

Det er to forskellige opgaver.

Overgangen fra den første til den anden ændrede ikke kun den tekniske arkitektur, men også det daglige arbejde med projekterne.

Ikke et endeligt punktum, men en valgt retning

I dag er denne arkitektur allerede i brug i en stor del af DigiMeld-økosystemet.

De resterende projekter overgår gradvist til den nye model for administrativ adgang.

Jeg gennemfører migreringen trinvist, kontrollerer hvert enkelt programs funktion og planlægger en ekstra gennemgang af hele systemet, når overgangen er afsluttet.

Enkelte elementer i brugergrænsefladen og reglerne for sessionsstyring kan stadig ændre sig.

Men grundideen ligger allerede fast.

Jeg ønsker ikke at vende tilbage til en model, hvor jeg er nødt til hele tiden at opbevare og bruge snesevis af administrative adgangskoder for at administrere snesevis af mine egne projekter.

Samtidig mener jeg ikke, at min egen implementering er en universalløsning for alle.

Forskellige organisationer har forskellige krav, infrastrukturer, trusselsmodeller og administrationsmetoder.

Det, der er praktisk og hensigtsmæssigt for DigiMeld-økosystemet, er ikke nødvendigvis det bedste valg for en anden udvikler.

Men selve princippet om at tildele beføjelser midlertidigt fortjener opmærksomhed.

Afslutningsvis

Jeg besluttede at dele mine erfaringer, ikke fordi jeg betragter mig selv som opfinderen af en ny godkendelsesmetode.

Og heller ikke fordi jeg vil præsentere endnu et system som fuldstændig sikkert.

Absolut sikkerhed findes ikke.

Jeg synes ganske enkelt, at selve måden at stille spørgsmålet på er interessant.

I stedet for i det uendelige at beskytte en permanent administrativ indgang kan man gentænke, om den overhovedet behøver at eksistere.

I stedet for at opbevare en masse adgangskoder kan man bruge midlertidige tilladelser.

I stedet for automatisk at stole på en bruger efter den første godkendelse kan man bekræfte tildelingen af konkrete beføjelser.

I stedet for at vente på, at en session udløber, kan man sørge for muligheden for centralt at tilbagekalde adgangen.

Og endelig kan man i stedet for at have en separat loginmekanisme i hvert projekt bygge ét samlet system til administration af adgangstilladelser og samtidig bevare applikationernes selvstændighed.

Jeg påstår ikke, at denne tilgang fjerner risikoen for kompromittering.

Den flytter blot fokus fra beskyttelsen af loginoplysninger, der altid er tilgængelige, til kontrolleret tildeling og tilbagekaldelse af beføjelser.

Måske er den mest effektive måde at mindske angrebsfladen på nogle gange ikke at tilføje endnu en sikkerhedsmekanisme, men at give afkald på noget, som systemet sagtens kan fungere uden.

Det var netop denne tanke, der blev begyndelsen på historien om MeldID Admin Gateway for mig.