Nogle rettelser efter en penetrationstest sker i serverrummet, og ingen bemærker dem. Andre ændrer brugernes hverdag: et ekstra trin ved login, en ny regel for adgangskoder, et program, der ikke længere kan installeres uden hjælp. Det er de rettelser, der lettest bliver rullet tilbage, hvis indførelsen går dårligt. Svaret på, hvordan IT får dem til at holde, hviler på tre ting: brugerne får besked i god tid, ændringen indføres i trin, som servicedesken kan følge med i, og der er en plan for dem, der falder igennem.
Hvilke rettelser der rammer brugerne
Rapporten kan pege på forhold, hvor rettelsen ikke kan gøres usynlig.
- Tofaktor · login kræver et ekstra trin, og brugeren skal registrere en metode. → Tofaktor med huller
- Adgangskoder · nye krav til længde eller en liste over adgangskoder, der ikke må bruges. → Adgangskodepolitikken i Active Directory
- Lokale rettigheder · brugere mister administratorrettigheder på egen maskine og kan ikke længere installere programmer selv. → Brugere med administratorrettigheder på egen maskine
- Betinget adgang · login fra ukendte enheder eller steder bliver afvist eller kræver mere. → Betinget adgang i Entra ID
- Lukket deling · links til dokumenter, der kunne åbnes af alle, holder op med at virke.
Hver af dem fjerner en svaghed, testen fandt. Hver af dem giver også henvendelser, hvis brugerne ikke ved, hvad der sker. Brugerne har måske allerede mærket testen selv, fx som låste konti eller en advarsel fra IT, og de kan have spørgsmål om, hvad den førte til. → Brugere under testen
Vælg den løsning, der er let at leve med
En skærpelse, der er for besværlig, bliver omgået. Brugere skriver adgangskoder ned, deler konti eller beder om undtagelser, der aldrig bliver lukket. Derfor er det en del af sikkerheden at vælge en løsning, der passer til hverdagen.
NCSC skriver i sin vejledning om adgangskoder, at regelmæssigt tvungne skift af adgangskoder skader sikkerheden frem for at forbedre den, og anbefaler i stedet en liste over almindelige adgangskoder, der ikke må bruges, og tofaktor for vigtige konti. Samme vejledning foretrækker at bremse gentagne loginforsøg frem for at låse konti, fordi låsning kan holde rigtige brugere ude. Rådene viser, at en skærpelse kan gøre det både sikrere og lettere for brugeren.
Ved tofaktor anbefaler Microsoft i sin vejledning om indførelse, at brugerne har mere end én metode registreret, så de har en reserve, hvis den første ikke er tilgængelig. Overvej det, før I vælger metode.
Fortæl det, før det sker
Microsoft fremhæver i samme vejledning, at det er afgørende at informere brugerne om kommende ændringer, krav til registrering og de handlinger, de selv skal foretage. Det gælder alle skærpelser, ikke kun tofaktor.
En god besked svarer på det, brugeren vil spørge om.
- Hvad ændres · med almindelige ord og et eksempel på, hvordan det ser ud.
- Hvornår · datoen, og om det sker for alle på én gang.
- Hvad brugeren skal gøre · fx registrere en metode inden en bestemt dag.
- Hvorfor · kort, uden detaljer om svagheden. Det er nok at sige, at ændringen beskytter konti og data.
- Hvor man får hjælp · servicedeskens kontakt og åbningstid.
Fortæl ikke, at ændringen skyldes et bestemt fund i en sikkerhedstest, med detaljer, der kan bruges af andre. Testens rapport er fortrolig, også når rettelserne er synlige.
Indfør i trin
Microsoft anbefaler, at tofaktor indføres med en pilotgruppe først og derefter i bølger, der passer til den kapacitet, supporten har. Det samme princip kan bruges på andre skærpelser.
- IT-afdelingen selv · den første gruppe kender systemerne og melder præcist tilbage.
- En pilotgruppe fra forretningen · brugere, der arbejder på forskellige måder, og som har sagt ja til at være først.
- Afdelinger i bølger · med et tempo, servicedesken kan følge.
- De sidste · brugere med særlige behov, fx dem, der arbejder på delte maskiner eller uden fast telefon.
Hold øje med henvendelserne efter hver bølge. Hvis de handler om det samme, skal beskeden eller løsningen justeres, før næste bølge begynder. → Rettelser uden at stoppe driften
Servicedesken og dem, der falder igennem
Servicedesken skal kende planen før brugerne. Den skal vide, hvad der ændres hvornår, hvilke spørgsmål der kan komme, og hvordan en bruger hjælpes, der har mistet sin telefon eller ikke kan logge ind. → Servicedesken under testen
Hjælpen må ikke åbne et nyt hul. Hvis en bruger kan få tofaktor fjernet ved at ringe og oplyse sit navn, er skærpelsen svag. Aftal, hvordan servicedesken bekræfter, hvem der ringer, før den nulstiller en metode eller giver midlertidig adgang.
Undtagelser vil blive efterspurgt. Behandl dem som andre undtagelser: med begrundelse, ejer og slutdato. En undtagelse, der gives for at få en travl leder i gang, og som aldrig bliver lukket, er netop den slags hul, testen fandt.
Følg op på, om skærpelsen holder
En skærpelse er ikke færdig, når den er rullet ud. Følg med i de første uger efter hver bølge: hvor mange brugere har registreret en metode, hvor mange henvendelser handler om ændringen, og hvor mange undtagelser er der givet? Microsoft beskriver i sin vejledning rapporter over registrering og brug af metoder, og andre platforme kan have tilsvarende oversigter.
Tallene fortæller, om beskeden virkede, og om løsningen er for besværlig. De fortæller også, hvor der står huller tilbage. En gruppe brugere, der aldrig har registreret sig, eller en servicekonto, der er holdt uden for reglen, er netop det, en retest kan finde. Ryd op, før testeren kommer igen. → Klar til retest
Det skal I lade være med
- At indføre for alle på én dag. Servicedesken kan ikke følge med.
- At forklare med testens detaljer. Brugerne skal vide hvad, ikke hvordan.
- At vælge en løsning, der inviterer til omgåelse. Besvær giver nye svagheder.
- At lade servicedesken nulstille uden kontrol. Hjælpen bliver en ny vej ind.
- At give undtagelser uden slutdato. De bliver permanente.
Hvad kan og ikke kan konkluderes
En skærpelse, der er indført for alle og ikke er blevet rullet tilbage, viser, at rettelsen er på plads og accepteret i hverdagen. Den viser ikke, at alle konti er dækket, fordi undtagelser og gamle loginmetoder kan stå tilbage. Det skal kontrolleres særskilt, før fundet kan betragtes som rettet.
Tjekliste til skærpelser
- ☐ Er det klart, hvilke rettelser brugerne vil mærke?
- ☐ Er løsningen valgt, så den er let at leve med?
- ☐ Har brugerne fået besked med dato, handling og hjælp?
- ☐ Er der en pilotgruppe og en plan for bølger?
- ☐ Kender servicedesken planen og proceduren for nulstilling?
- ☐ Har undtagelser begrundelse, ejer og slutdato?
- ☐ Er det kontrolleret, at ingen konti står uden for skærpelsen?
Kilder
- NCSC: Password policy, updating your approach: regelmæssigt tvungne skift skader sikkerheden, liste over almindelige adgangskoder, tofaktor for vigtige konti og bremsning af loginforsøg frem for låsning.
- Microsoft Learn: Deployment considerations for Microsoft Entra multifactor authentication: informér brugerne om ændringer og registrering, mere end én metode pr. bruger indførelse med pilotgruppe og bølger, der passer til supportens kapacitet, og rapporter over registrering og brug af metoder.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Mindst mulig adgang i praksis · Klar til retest
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
