En adgangskodepolitik skal regulere hele adgangen til en konto: oprettelse, login, ekstra faktorer, gendannelse og lukning. En længderegel alene beskytter ikke mod en svag nulstillingsprocedure eller en gammel administratorkonto. Den praktiske opgave er at beslutte en sammenhængende politik og kontrollere, hvilke systemer der faktisk følger den.
Guiden bruger NIST SP 800-63B-4 som en tydeligt angivet teknisk reference og viser et udfyldt eksempel for en dansk virksomheds interne systemer. NIST’s krav gælder i standardens eget anvendelsesområde. De angivne tal bliver ikke dermed generelle danske lovkrav, og en lokal oplåsningskode er ikke nødvendigvis den samme type hemmelighed som en adgangskode sendt til en central loginserver.
Hvilke regler kommer fra hvilken kilde?
Datatilsynets vejledning om risikovurdering beskriver den risikobaserede sikkerhedstilgang. Virksomheden skal vurdere, hvilke personoplysninger og personer et kompromitteret login kan berøre. Et system med omfattende kundeadgang eller administratorfunktioner kræver en anden vurdering end en afgrænset tjeneste med få oplysninger.
NIST SP 800-63B-4, afsnittet om adgangskoder, angiver mindst 15 tegn ved brug som eneste faktor. En adgangskode, der kun anvendes som del af MFA, kan være kortere, men mindst otte tegn. Referencen udelukker påtvungne blandinger af tegntyper og rutinemæssige periodiske skift, men kræver skift ved tegn på kompromittering. Den kræver også kontrol mod almindelige, forventelige eller kompromitterede adgangskoder.
Skriv kilde, version og anvendelsesområde i beslutningen. Hvis en kontrakt eller et sektorkrav stiller andre krav, skal konflikten håndteres udtrykkeligt. Sæt ikke flere forskellige kilders tal sammen og kald resultatet den obligatoriske danske standard. En organisations interne politik kan være konkret uden at tillægge dens valg en opdigtet lovstatus.
Kortlæg de konti, politikken skal omfatte
Start med identitetstjenesten og de tilsluttede applikationer, men undersøg også lokale konti. Et program kan bruge fælles login til medarbejdere og stadig have en særskilt administratorkonto hos leverandøren. Et servicejob kan benytte en teknisk konto, der ikke følger en medarbejders ændringer eller fratrædelse.
I kortlægningen af it-systemer noteres systemejer, brugergrupper, loginmetode, lokale undtagelser og muligheder for gendannelse. Markér også adgang via mobilapp eller integration, hvis den vej kan omgå den almindelige browseradgang. Det er ofte dér, en tilsyneladende fuldt indført politik har et hul.
Gruppér konti efter opgave: almindelige brugere, privilegerede brugere, eksterne konsulenter, tekniske konti og nødadgange. Grupperingen bruges til at vælge beskyttelse, godkendelse og opfølgning. Den bør ikke ende med, at alle vanskelige konti placeres i en permanent undtagelseskategori.
Et udfyldt eksempel på en intern politik
Den fiktive virksomhed Fjordservice anvender et kundesystem og et lønsystem. Virksomheden vælger nedenstående regler efter sin risikovurdering. Tabellen er et eksempel på interne beslutninger, ikke en erklæring om, at netop disse indstillinger passer til alle virksomheder.
| Område | Fjordservices beslutning | Begrundelse og ejer |
|---|---|---|
| Almindelige medarbejdere | Central login med MFA; adgangskoder mindst 15 tegn | Enkel fælles længderegel; it ejer opsætningen |
| Administratorer | Særskilt konto og phishingresistent faktor, hvor løsningen understøtter det | Begrænse risikoen ved omfattende rettigheder; sikkerhedsansvarlig godkender |
| Oprettelse og ændring | Spær almindelige og kendt kompromitterede adgangskoder | Undgå lette gæt; identitetstjenestens ejer følger funktionen |
| Mistet faktor | Kontrolleret gendannelse gennem support med særskilt identitetskontrol | Undgå at et telefonopkald bliver en genvej til kontoen |
| Mistanke om kompromittering | Begræns adgang, skift berørt hemmelighed og vurder sessioner | Hændelsesansvarlig koordinerer undersøgelsen |
| Ældre applikation | Tidsbegrænset undtagelse med godkendte kompenserende foranstaltninger | Systemejer fremlægger en løsning og dato for genvurdering |
Virksomheden bruger 15 tegn som fælles adgangskoderegel, også hvor MFA anvendes. Det er et bevidst internt valg, der er strengere end NIST’s nævnte minimum for adgangskoder, som kun indgår i MFA. Dokumentationen skal vise denne forskel, så support ikke forklarer den interne længde som en ordret lovregel.
Lange adgangskoder skal også kunne bruges
Et langt, forudsigeligt mønster kan stadig være let at gætte. Årstal, virksomhedsnavn og en kendt standardfrase bliver ikke stærke alene ved at blive sat sammen. En godkendt adgangskodeadministrator kan hjælpe brugeren med forskellige genererede hemmeligheder til forskellige tjenester. Organisér også adgang til arbejdsrelaterede hemmeligheder ved fravær og fratrædelse.
Indfør politikken i alle relevante skærmbilleder. Kontroller oprettelse, ændring, login og gendannelse. Hvis oprettelsen accepterer en længere adgangskode, men en ældre mobilapp afviser den ved login, kan brugerne blive presset til en svagere løsning. Et sådant kompatibilitetsproblem skal registreres og løses med systemejeren.
Brug syntetiske konti til kontrollen. Skriv aldrig de rigtige adgangskoder i en rapport eller et supportsystem. Dokumenter i stedet, hvilken type krav der blev afprøvet, og om det blev accepteret eller afvist som forventet. Eksempelvis kan rapporten anføre, at en for kort adgangskode blev afvist, uden at gengive dens værdi.
MFA og gendannelse skal vurderes sammen
MFA kombinerer forskellige typer faktorer. To videnbaserede hemmeligheder er ikke automatisk to uafhængige faktorer. Den valgte løsning skal passe til truslerne, brugerens udstyr og systemets muligheder. Phishingresistens er særlig relevant ved privilegeret adgang, men organisationen skal også kunne håndtere tab eller defekt udstyr.
En svag gendannelse kan undergrave et stærkt normalt login. I eksemplet må support ikke registrere en ny faktor alene på baggrund af et indgående telefonopkald og kendskab til medarbejderens navn. Support bruger den vedtagne kontrolprocedure og involverer en anden godkendt person ved særligt privilegerede konti. Kan identiteten ikke afklares, må sagen eskaleres.
Beslut også, hvad der skal ske med den tidligere faktor og aktive sessioner. En faktor, der er meldt tabt, bør ikke fortsat kunne bruges uden en begrundet beslutning. Hvis en angriber allerede har en session, løser en ny adgangskode ikke nødvendigvis hele hændelsen. Support skal kende den praktiske forskel mellem at gendanne legitim adgang og at håndtere mistænkt misbrug.
Privilegerede, tekniske og fælles konti
Administratorrettigheder bør være knyttet til en konkret opgave og en godkendt bruger. I Fjordservice anvender administratoren en almindelig konto til mail og en særskilt konto til administration. Det gør det muligt at begrænse den privilegerede kontos anvendelse og følge de relevante handlinger i sikkerhedslogningen.
Tekniske hemmeligheder kræver deres egen livscyklus. En integration kan stoppe, hvis en nøgle udskiftes uden at opdatere de tjenester, der bruger den. Registrer derfor ejer, rettigheder, forbrugende systemer og fremgangsmåden ved udskiftning. En regel om adgangskoder, som medarbejdere husker, er ikke tilstrækkelig styring af alle API-nøgler og tjenestekonti.
Hvis en fælles konto ikke umiddelbart kan fjernes, skal systemejeren forklare hvorfor og begrænse brugen. Undersøg muligheden for personlige konti eller en kontrolleret adgang, der stadig gør brugerens handlinger sporbare. Et delt regneark med administratorhemmeligheder er ikke en hensigtsmæssig løsning på et manglende kontodesign.
Lagring og beskyttelse af hemmeligheder
Når virksomheden selv udvikler login, skal adgangskoder beskyttes mod offlineangreb ved et egnet saltet adgangskodehash. Dette er en anden opgave end at kryptere en fil, som senere skal kunne dekrypteres. Valg af mekanisme og parametre hører til et aktuelt teknisk design, som skal følge relevante primære specifikationer og vedligeholdes.
Indkøberen kan stille konkrete spørgsmål til leverandøren: Er adgangskoder tilgængelige i klartekst for support? Hvordan begrænses mislykkede loginforsøg? Hvordan godkendes gendannelse? Hvilke hændelser kan kunden få dokumenteret? Svarene skal beskrive det tilbudte produkt og dets faktiske indstillinger, ikke alene leverandørens generelle sikkerhedspolitik.
Sammenhold oplysningerne med databehandleraftalens sikkerhedsdel. Aftalen dokumenterer pligter, mens systemets funktioner og den aftalte kontrol viser, hvordan de udføres. Hvis kunden ikke selv kan ændre en væsentlig indstilling, skal det fremgå, hvem der gør det.
Afprøv indførelsen på én samlet arbejdsgang
Fjordservice begynder med en demonstrationsbruger i kundesystemet. Brugeren oprettes med godkendt rolle, logger ind med MFA og gennemfører derefter den aftalte øvelse med en mistet faktor. Support følger gendannelsesproceduren. Efterfølgende afsluttes brugerens adgang, og både browser og mobilapp kontrolleres.
Resultatet viser, at browseradgangen er lukket, men mobilappen stadig har en aktiv session. Systemejeren registrerer afvigelsen og får afklaret sessionens håndtering med leverandøren. Politikken betragtes ikke som fuldt indført, før den valgte løsning er gennemført og afprøvet. Rapporten indeholder hændelsesreferencer, ansvar og resultat; den indeholder ikke sessionstokens.
Udvid først derefter forløbet til de andre systemer. Brug resultatet til at rette instruktionen til support og it-reglerne for medarbejdere. En bruger, som ved hvordan tab meldes, behøver ikke improvisere en genvej for at komme videre med dagens opgaver.
Når identitetstjenesten selv er utilgængelig
Den forretningsmæssige beredskabsplan skal tage højde for, at almindelig login kan være nede. Afklar hvilke nødadgange der faktisk er nødvendige, hvem der kan anvende dem, og hvor instruktionen er tilgængelig. Hemmelighederne skal være beskyttet, selv om den normale tjeneste ikke virker.
Efter anvendelse gennemgås nødadgangen og de udførte handlinger. Undersøg, om hemmeligheder eller rettigheder skal ændres, og om en midlertidig løsning stadig er aktiv. Et nødforløb bør ende med en kontrolleret tilbagevenden til normal adgang, ellers kan den exceptionelle konto blive den nemmeste adgangsvej i hverdagen.
Politikken forankres i informationssikkerhedspolitikken med en ejer og klare ændringsudløsere. Nye applikationer, faktorskift, kompromittering og væsentlige ændringer hos leverandøren kan kræve genvurdering før næste planlagte gennemgang. Referencerne i denne guide er kontrolleret 8. september 2026.