Efter en penetrationstest kan det virke som det sikre valg at bede alle om at skifte adgangskode. Det er sjældent det rigtige svar. Vejledninger fra både britiske og amerikanske myndigheder siger, at adgangskoder skal skiftes, når der er viden om eller mistanke om, at de er kompromitteret, og ikke som rutine. Svaret er derfor: nulstil de adgangskoder, nøgler og koder, som testeren kendte, fandt eller kunne have set, og ret de svagheder, der gjorde det muligt. Resten af organisationen skal ikke have et skift, fordi der har været en test.
Hvorfor ikke bare nulstille alle
En generel nulstilling ser handlekraftig ud, men den har en pris og en begrænset effekt.
- Den rammer ikke årsagen · hvis testeren fandt adgangskoder, fordi de lå i et script eller en delt mappe, ligger de nye der måske også om en måned.
- Den skaber svagere koder · den britiske myndighed NCSC skriver, at regelmæssige skift skader mere, end de gavner, fordi brugerne vælger nye adgangskoder, der kun er små variationer af de gamle.
- Den giver arbejde · servicedesken får henvendelser, og servicekonti kan stoppe systemer, hvis de skiftes uden plan.
- Den skjuler, hvad der var galt · når alt er skiftet, er det sværere at se, hvilke konti der faktisk var udsat.
Den amerikanske standardorganisation NIST skriver i sin vejledning om autentifikation, at adgangskoder ikke må kræves skiftet periodisk, men at et skift skal gennemtvinges, hvis der er tegn på, at de er kompromitteret. Det princip passer direkte på situationen efter en test.
Hvilke adgangskoder skal nulstilles
Gennemgå rapporten og testerens liste over spor og data, og find de adgangsoplysninger, testeren havde eller kunne have haft. → Spor efter testeren
- Adgangskoder, I udleverede · til testkonti, fjernadgang eller udstyr. Testkonti slettes helt. Andre konti, hvis adgangskode testeren fik, skiftes.
- Adgangskoder, testeren fandt · i filer, scripts, opsætninger eller dokumentation. → Adgangskoder i scripts
- Adgangskoder, testeren kunne gætte · konti med svage koder, som rapporten nævner.
- Adgangskoder, testeren kunne læse · fx fordi testeren fik adgang til et system, hvor de var gemt på en måde, der kunne aflæses.
- Fælles adgangskoder · koder til fælles konti, udstyr eller systemer, som testeren har set, også selv om de ikke blev brugt.
Rapporten bør angive, hvilke konti det drejer sig om. Hvis den ikke gør, så spørg testeren direkte. Det er en oplysning, I har brug for, og den skal behandles fortroligt.
Når listen er lavet, så sæt rækkefølgen efter, hvad kontoen giver adgang til. Konti med administrative rettigheder, konti til systemer med følsomme data og konti, der kan bruges udefra, kommer først. Konti med begrænset adgang til et enkelt internt system kan vente lidt, men ikke længe. Notér for hver konto, hvem der skifter, og hvornår det er sket, så skiftet kan kontrolleres som en del af oprydningen.
Ikke kun adgangskoder
Adgangskoder er kun én type adgangsoplysninger. Det samme princip gælder for andre.
- Nøgler til API’er og cloudtjenester · skal udskiftes, hvis testeren har set dem. → API-nøgler
- Certifikater og private nøgler · der blev fundet uden tilstrækkelig beskyttelse.
- Adgangstokens og sessioner · der kan være udstedt til testkonti eller fundet i systemer.
- Gendannelseskoder og koder til tofaktor · som testeren fik udleveret eller så.
En udskiftning af nøgler og certifikater kan påvirke integrationer og forbindelser til andre systemer. Planlæg den på samme måde som andre ændringer.
Servicekonti og systemkonti kræver en plan
Konti, som systemer bruger til at tale med hinanden, kan ikke nulstilles uden forberedelse. Hvis adgangskoden ændres ét sted, men ikke alle de steder, den bruges, stopper noget. → Tjenestekonti
- Find alle steder, kontoen bruges · før skiftet.
- Aftal et tidspunkt · hvor et stop gør mindst skade.
- Hav en vej tilbage · hvis noget ikke virker efter skiftet. → Rettelser uden at stoppe driften
- Overvej at erstatte kontoen · med en løsning, hvor adgangskoden ikke skal gemmes i systemet.
Er en servicekonto med høje rettigheder udsat, er den en høj prioritet, selv om skiftet er besværligt. Det er netop den slags konto, en angriber vil gå efter.
Administratorer og nødkonti
Konti med administrative rettigheder kræver særlig opmærksomhed. Hvis testeren har fået adgang til en sådan konto eller set dens adgangskode, skal den skiftes hurtigt, og det skal kontrolleres, om kontoen er brugt til noget uventet i perioden.
Se i logningen, om kontoen er brugt fra steder eller på tidspunkter, der ikke passer med testen. Et skift lukker for fremtidig brug, men det fortæller ikke, om nogen andre end testeren nåede at bruge koden i perioden.
Nødadgangskonti, der kun bruges i krisesituationer, skal også med, hvis testeren har set deres oplysninger. De er lette at glemme, fordi de ikke bruges i hverdagen. → Nødadgangskonti
Ret det, der gjorde koderne tilgængelige
Et skift af adgangskoder løser kun det akutte. Hvis testen viste, at koder lå i scripts, at mange konti havde svage koder, eller at koder kunne aflæses i et system, er det disse forhold, der skal rettes. Ellers vil den næste test finde de nye koder samme sted.
Svage adgangskoder i stor stil er et tegn på, at reglerne for adgangskoder eller kravene til tofaktor skal ses efter. Det er et emne for sig. → Adgangskodepolitik i AD
Husk konti, som en driftsleverandør administrerer. Hvis testeren har set adgangsoplysninger til leverandørens administrationskonti i jeres miljø, er det leverandøren, der skal skifte dem, men det er jer, der skal sikre, at det sker, og få det bekræftet.
Det skal I lade være med
- At nulstille alle brugeres adgangskoder som standard. Det rammer ikke årsagen.
- At glemme nøgler, certifikater og tokens. De er også adgangsoplysninger.
- At skifte servicekonti uden plan. Det kan stoppe systemer.
- At lade nødkonti stå uændrede. De er også udsat, hvis testeren har set dem.
- At nøjes med skiftet. Ret det, der gjorde koderne tilgængelige.
Hvad kan og ikke kan konkluderes
En målrettet nulstilling, baseret på rapporten og testerens liste, lukker de adgangsoplysninger, testen kom i berøring med. Den sikrer ikke, at andre adgangskoder i organisationen er stærke, og den siger ikke noget om koder, testen ikke nåede. Hvis rapporten ikke er præcis om, hvilke konti der var udsat, er nulstillingen kun så god som jeres egen vurdering. Er I i tvivl om en konto, er det bedre at skifte koden én gang for meget end at lade en mulig udsat konto stå.
Tjekliste til nulstillingen
- ☐ Er det klarlagt, hvilke konti og koder testeren havde eller kunne have?
- ☐ Er testkonti slettet, og er udleverede koder skiftet?
- ☐ Er nøgler, certifikater og tokens vurderet?
- ☐ Er der en plan for servicekonti?
- ☐ Er administratorer og nødkonti håndteret?
- ☐ Er årsagerne til, at koderne var tilgængelige, sat på listen over rettelser?
Kilder
- NCSC: Updating your approach: regelmæssige skift af adgangskoder skader mere, end de gavner; adgangskoder skal skiftes, når de vides eller mistænkes at være kompromitteret.
- NIST SP 800-63B-4: adgangskoder må ikke kræves skiftet periodisk, men et skift skal gennemtvinges ved tegn på kompromittering (afsnit 3.1.1.2).
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Adgangskoder i scripts · Spor efter testeren
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
