Definition og hvad “multifaktor” betyder
Multifaktorgodkendelse (MFA) betyder, at en login- eller godkendelseshandling kræver mindst to uafhængige “faktorer” for at gennemføre. En faktor kan typisk være noget du kender (fx en adgangskode), noget du har (fx en godkendelsesenhed eller sikkerhedsnøgle), eller noget du er (fx biometrisk verifikation). Pointen er ikke kun at have flere skærme eller flere felter, men at de nødvendige bekræftelser skal give mening som separate beviser.
En vigtig afgrænsning: “MFA” løser ikke automatisk alle adgangsproblemer. Hvis en angriber kan omgå hele flowet via kontogendannelse, kompromitterede enheder eller samme logiske afhængighed for alle faktorer, vil gevinsten være mindre end forventet.
Et enkelt model: hvem bekræfter hvad, og hvornår
Tænk på MFA som en godkendelseskæde med tre centrale trin:
- Identifikation: brugeren angiver fx brugernavn.
- Første faktor: en adgangskode eller tilsvarende “kend”-bevis.
- Anden faktor: en ekstra bekræftelse, som skal være uafhængig af første faktor.
Når anden faktor indgår, bør systemet kontrollere, at den anden faktor leverer et svar, som kan verificeres af tjenesten. Herefter gives adgang eller afvises forsøget.
Praktisk konsekvens: Hvis din løsning kun “spænder et ekstra felt ovenpå” uden reelle kontroller (eller hvis de to faktorer kan forsvare sig mod samme angrebsvej), får du ikke den forventede styrkelse.
Vælg faktorer og design flowet uden at skabe nye svagheder
Der findes flere typer anden faktor. Den mest robuste løsning i mange sammenhænge er typisk baseret på en styrket verifikationsmekanisme, der er svær at overføre eller efterligne. Samtidig kan du ikke ignorere brugernes hverdag: MFA skal fungere ved normale loginmønstre, uden at du tvinger til workarounds, som undergraver sikkerheden.
Overvej især:
- Uafhængighed i praksis: Hvis både “første” og “anden” faktor i realiteten afhænger af samme kompromitterede enhed, kan en angriber få to “hits” fra samme rod.
- Kontogendannelse som undtagelse: Giver jeres nulstilling af adgang adgang til at omgå MFA? Hvis kontogendannelse kan gennemføres uden tilstrækkelig ekstra verifikation, kan MFA blive svækket.
- Styring af fallback: Tving ikke altid fallback til den mindst sikre metode. Overvej i stedet, hvordan du håndterer nødsituationer uden at skabe et standardspor, der misbruges.
- Beskyttelse mod tyveri af sessions: MFA hjælper ved login, men hvis en aktiv session kan flyttes, ændres eller hentes uden beskyttelse, kan det stadig give adgang.
En nyttig tommelfingerregel er at spørge: “Hvilken del af login-flowet kan en angriber stadig nå uden at bestå anden faktoren?” Hvis svaret er “kontogendannelse” eller “en normal fejlvej”, skal du arbejde med netop den undtagelse.
Undtagelser og grænser: hvor MFA ofte fejler
Selv når MFA er korrekt konfigureret, er der typiske steder, hvor organisationer rammer skæve kompromiser.
1) Servicekonti og automatiserede jobs Maskin-til-maskine-adgange kræver ofte andre mønstre end menneske-login. Hvis du bruger samme MFA-krav uden at planlægge, kan det enten gøre drift umulig eller føre til “lange leve”-tokens, svage gendannelser eller manuelle omgåelser.
2) Overgangsperioder Når MFA rulles ud, kan der være perioder med blandede politikker. Hvis gamle konti eller bestemte grupper ikke får samme krav, opstår et ujævnt beskyttelsesniveau. Overvej en plan for, hvornår politikker er ensartede.
3) Tab af enhed Hvis brugeren mister telefon eller anden MFA-bærende enhed, skal der findes en nødproces. Men nødprocessen er en risikokanal: den skal være streng nok til ikke at blive et “hurtigt bypass”.
4) For høj lempelse ved mange forsøg Hvis systemet tillader ubegrænset prøvning, kan angribere udføre mange forsøg uden at stoppe. Ratebegrænsning, låsning/step-up og tydelig logning er derfor en del af “implementering”, ikke kun en indstilling.
Praktisk kontrol: sådan tjekker du om MFA virkelig virker
Du kan validere kvaliteten af MFA uden at gætte. Brug en tjekliste, der passer til jeres egne flows:
- Test normale login-scenarier: Kan brugeren gennemføre login uden omveje, og bliver anden faktor korrekt verificeret?
- Test fejlsituationer: Hvad sker der, når anden faktor udløber, bliver afvist, eller brugeren skriver forkert? Bliver forsøget stoppet på en sikker måde?
- Tjek kontogendannelse: Kan en bruger få adgang tilbage uden at gennemgå de samme MFA-kontroller? Hvis ja, er det en central begrænsning.
- Gennemgå fallback: Er fallback en undtagelse med tydelige kriterier, eller ender den som standard, når noget går galt?
- Kontrollér politikker for undtagelser: Er der undtagelser for bestemte brugere, netværk eller integrationer? Dokumentér hvorfor og hvornår de udløber.
- Logning og sporbarhed: Kan I identificere, hvor i flowet der opstod afvisning, og kan I se gentagne forsøg?
Hvis du gennemfører disse tests, får du et realistisk billede af, om MFA forbedrer sikkerheden i jeres konkrete opsætning—og om der findes en vej uden om anden faktor, som bør lukkes.
Hvilken begrænsning skal du acceptere på forhånd
MFA reducerer sandsynligheden for kompromittering ved login, men den fjerner ikke risikoen for alle angrebsformer. Det vigtigste kompromis du bør acceptere og planlægge for er forskellen mellem:
- MFA ved login (hvor den typisk hjælper), og
- Andre adgangsveje som kontogendannelse, token-håndtering, sessioner og brugeradfærd i miljøet.
Derfor bør implementeringen ikke kun handle om at “aktivere MFA”, men om at sikre, at de relevante undtagelser og driftsscenarier stadig kræver meningsfuld ekstra verifikation.