Sikkert login i drift: MFA, sessioner og kontogendannelse

Kortlæg hele loginforløbet

Identitetskontrollen bekræfter, hvem brugeren er. Sessionen holder denne identitet aktiv mellem handlinger. Gendannelse giver adgang igen, når en faktor er mistet. De tre dele skal vurderes samlet, fordi en svag session eller supportproces kan omgå et ellers stærkt login.

Brug en moden identitetsløsning

Byg som udgangspunkt ikke egen lagring af adgangskoder, sessionskryptografi og MFA, hvis appens nuværende identitetsudbyder eller et anerkendt kodebibliotek allerede løser opgaven. Medarbejderapps kan ofte bruge virksomhedens Microsoft- eller Google-konti. Kundeapps kan bruge en administreret identitetsplatform som Firebase Authentication eller en tilsvarende tjeneste.

• Virksomhedsejerskab: Produktionens tenant, projekt og administratoradgang skal ejes af virksomheden, ikke af udviklerens private konto.
• Separat adgangskontrol: Login erstatter ikke regler for rolle, kunde og datapost. De kontroller skal stadig håndhæves på serveren eller ved data.
• Aktuel leverandørkonfiguration: MFA-metoder, sessioner og licenskrav varierer. Kontrollér dem i den platform og plan, appen faktisk bruger.

Beskyt risikable konti og handlinger med MFA

MFA kræver mere end én faktor og mindsker afhængigheden af adgangskoden alene. NIST fremhæver kryptografiske, phishing-resistente metoder, når risikoen kræver det. Engangskoder kan stadig narres ud af en bruger, fordi koden ikke i sig selv er bundet til den rigtige tjeneste.

• Kræv MFA eller en stærkere metode for privilegerede konti og følsomme handlinger efter jeres risikovurdering.
• Tilbyd mere end én sikker registreret metode, så tab af en enhed ikke automatisk bliver en supportomgåelse.
• Kræv ny bekræftelse før eksempelvis ændring af MFA, e-mailadresse, betalingsoplysninger, roller eller masseeksport.
• Test en ny politik på kontrollerede brugere, før den rammer alle og risikerer at låse virksomheden ude.

Behandl sessionen som en midlertidig nøgle

Efter login er det sessionens nøgle eller adgangstoken, der normalt åbner appen. Tyveri af den kan derfor have samme praktiske konsekvens som et kompromitteret login. Brug den valgte platforms dokumenterede sessionmodel, og beslut både inaktivitetsgrænse, samlet levetid og hændelser, der kræver ny bekræftelse.

Browsercookie

Ved serverstyrede browsersessioner bør identifikatoren normalt sættes af serveren over HTTPS med Secure og HttpOnly samt en bevidst SameSite-politik. SameSite er kun en del af CSRF-beskyttelsen.

Udløb

Vælg tider efter data, handlinger, enhed og brugergruppe. En intern kiosk, en privat telefon og en administratorportal har ikke nødvendigvis samme risiko.

Tilbagekaldelse

Udlogning, ændring af adgangskode, mistet enhed, mistanke om misbrug og lukning af adgang skal have en dokumenteret virkning på aktive sessioner og fornyelsestokens.

Ny bekræftelse

En gammel, men gyldig session bør ikke alene være nok til at ændre de faktorer eller oplysninger, der kan overtage kontoen.

Logout i brugerfladen er ikke bevis for server-side tilbagekaldelse. Firebase og Microsoft Entra har eksempelvis særskilte administrative muligheder for at tilbagekalde sessioner; den konkrete effekt og forsinkelse skal testes i jeres setup.

Gør kontogendannelse sværere at misbruge end at bruge

Gendannelse er ikke almindeligt login. Når brugeren har mistet sin faktor, er der mindre bevis tilbage, og social engineering bliver en reel risiko. NIST beskriver blandt andet gendannelseskoder, aftalte gendannelseskontakter og fornyet identitetskontrol som mulige metoder og kræver notifikation ved gendannelse i sin assurance-model.

• Planlæg metoden på forhånd: Brug platformens understøttede gendannelsesmuligheder, og dokumentér hvad support må og ikke må gøre.
• Beskyt nulstillingsforløbet: Adgangstokens skal være tilfældige, kortlivede, engangsbrug og holdes ude af logs, analyseværktøjer og supportsager.
• Advar den registrerede bruger: Send en neutral notifikation ved ændring eller gendannelse, så misbrug kan opdages uden at sende aktive adgangsoplysninger.
• Luk gamle veje: Vurder om eksisterende sessioner, gendannelseskoder og gamle faktorer skal tilbagekaldes, når kontoen er gendannet.
• Undgå hasteundtagelser: Navn, telefonnummer, fakturanummer eller kendskab til virksomheden er ikke i sig selv sikkert bevis på kontoens ejerskab.

Afprøv tab, tyveri og fratrædelse

Test med kontrollerede testbrugere og uden rigtige kunders faktorer. Målet er at se, om adgang faktisk forsvinder fra browser, telefon, API og baggrundsintegrationer — ikke kun om en konto skifter status i administrationssiden.

• Log ind på to enheder, tilbagekald sessionerne administrativt, og mål hvornår hver enhed bliver afvist.
• Skift adgangskode eller primær faktor, og kontrollér den dokumenterede virkning på eksisterende sessioner.
• Afprøv mistet MFA-enhed og en brugt, udløbet eller ændret gendannelseskode eller nulstillingslink.
• Deaktivér en testmedarbejder, og kontrollér også gruppemedlemskab, app-roller, invitationer og ejerskab.
• Forsøg en privilegeret handling fra en gammel session og uden den krævede genbekræftelse.
• Kontrollér at logs viser tidspunkt, brugerreference, handling og resultat uden sessionsnøgler, adgangstokens eller nulstillingslinks.

Typiske fejl

• MFA gælder kun Jacob eller udvikleren: Andre privilegerede support- og ejerkonti kan stadig overtage data og brugere.
• Sessionen har ingen samlet levetid: Aktivitet kan holde en stjålet adgang i live uden ny bekræftelse.
• Udlogning sletter kun lokal tilstand: Et fornyelsestoken eller en anden enhed fortsætter med at virke.
• SameSite kaldes fuld CSRF-beskyttelse: Appens forespørgsler og kodebibliotekets anbefalede kontroller bliver ikke vurderet.
• Resetmailen er hele identitetskontrollen: En kompromitteret eller videresendt indbakke overtager også appkontoen.
• Support kan bare skifte e-mailadresse eller MFA: Hjælpsomhed bliver en udokumenteret adgangsvej uden tilstrækkeligt bevis.
• Fratrædelse stopper ved brugerlisten: Aktive sessioner, grupper, personlige tokens eller integrationsejerskab bliver glemt.

Tjekliste før medarbejdere eller kunder logger ind

• ☐ Produktionens identitetsprojekt, tenant og administratorer ejes af virksomheden.
• ☐ Loginmetoder, MFA-muligheder, gendannelsesforløb og supportansvar er kortlagt.
• ☐ Privilegerede konti og handlinger har en risikobaseret MFA- og genbekræftelsespolitik.
• ☐ Brugere kan registrere en sikker reservemetode uden at dele faktor eller gendannelseskode med support.
• ☐ Sessionsmodel, lagring, inaktivitetsgrænse, samlet levetid og fornyelse er dokumenteret.
• ☐ Serverstyrede sessionscookies har relevante Secure-, HttpOnly- og SameSite-indstillinger samt passende CSRF-beskyttelse.
• ☐ Udlogning, mistet enhed, ændring af adgangskode, mistanke om misbrug og lukning af adgang har en testet tilbagekaldelsesvej.
• ☐ Gendannelses- og nulstillingsmuligheder er afgrænsede, udløber og giver notifikation uden at lække adgangsoplysninger.
• ☐ Support kan ikke ændre kontoens e-mailadresse, MFA eller ejer uden en dokumenteret kontrol.
• ☐ Logs kan vise sikkerhedshændelser uden adgangskoder, tokens, cookies eller aktive links.
• ☐ Test dækker gammel session, flere enheder, mistet faktor, afvist gendannelse og fratrådt bruger.

Relaterede guides

Officielle kilder

Identitetsfunktioner, licenser og administrative handlinger ændrer sig mellem platforme. Rådene er kontrolleret mod aktuelle standarder og leverandørdokumentation; kontrollér også den konkrete konfiguration i jeres egen identitetsløsning.

• NIST SP 800-63B-4: Authentication and authenticator management
• NIST SP 800-63B-4: Session management
• MDN: Session management
• MDN: Secure cookie configuration
• Firebase Authentication: Manage user sessions
• Microsoft Entra: Manage user authentication methods and revoke sessions