Testkonti og testdata: hvad testeren skal have udleveret

Testkonti, der mangler, ikke virker eller har de forkerte rettigheder, kan få en test med login til at komme skævt fra start. Hvad testeren skal have, afhænger af de roller og funktioner, testen skal undersøge, og af hvilke data systemet må indeholde under testen.

Kort sagt skal testeren have konti, der svarer til de brugertyper, opgaven omfatter, data nok til at funktionerne kan bruges realistisk, og en klar aftale om, hvordan det hele lukkes og slettes bagefter. Den øvrige praktiske forberedelse er beskrevet særskilt. → Før penetrationstesten

Konti til de roller, der skal undersøges

Start med en liste over brugertyperne i systemet. For kundeportalen kan det være almindelig kunde, erhvervskunde med flere brugere, medarbejder i kundeservice og administrator. For ERP-systemet kan det være bogholder, lagermedarbejder, afdelingsleder og systemadministrator. Vælg derefter, hvilke af rollerne testen skal dække.

Hvis testen skal undersøge, om én kunde kan se en anden kundes oplysninger, skal testeren som regel have mindst to konti i samme rolle, tilhørende hver sin kunde. Med én konto kan adskillelsen mellem kunder ikke afprøves. Det samme gælder adskillelse mellem afdelinger eller selskaber i ERP-systemet. → Adskillelse af kundedata

Rollerne skal være de rigtige, ikke bare konti med fuld adgang. En konto med administratorrettigheder kan ikke vise, hvad en almindelig bruger kan nå, som brugeren ikke burde. Beskriv for hver konto, hvilken rolle den har, og hvad den forventes at kunne. → Test med og uden login

Konti, der virker på dag ét

Opret kontiene i god tid, og afprøv dem, før testen begynder. En konto, der kræver aktivering, venter på godkendelse eller er låst efter for mange forsøg, koster testtid. Hvis login kræver tofaktor, skal det være afklaret, hvordan testeren får den anden faktor, uden at den er knyttet til en medarbejders telefon. → Tofaktor og pentest

Kontiene bør være oprettet til formålet og navngivet, så de kan genkendes som testkonti. Brug ikke rigtige medarbejderes konti. Det gør det svært at skelne testaktivitet fra almindelig brug og kan give problemer med ansvar og persondata.

Tænk også på adgangsveje. Hvis kundeportalen kun kan nås fra bestemte netværk, eller hvis ERP-systemet kræver fjernadgang, skal testeren have den nødvendige adgang. Det kræver ofte driftsleverandørens medvirken. → Driftsleverandøren og testen

Udlevering af adgang

Adgangsoplysninger skal udleveres på en måde, der passer til, hvad de giver adgang til. Undgå at sende brugernavne og adgangskoder i samme mail eller i en bred mailtråd. Aftal en kanal med testeren, og send gerne oplysningerne i to dele. Registrér, hvilke konti der er udleveret til hvem. Den registrering bruges igen ved oprydningen, så ingen konto bliver overset, når testen er afsluttet.

Testeren bør behandle adgangen fortroligt og kun bruge den inden for opgaven. Det er en naturlig del af fortrolighedsaftalen og af aftalen om testen. → Fortrolighedsaftale før penetrationstesten

Testdata eller rigtige data?

Hvis testen foregår i et testmiljø, kan det fyldes med opdigtede data, der ligner de rigtige i form og mængde. Det giver testeren noget at arbejde med uden at udsætte rigtige personoplysninger. Data bør være realistiske nok til, at funktionerne kan bruges som normalt: ordrer i webshoppen, fakturaer i ERP-systemet, sager i kundeportalen.

Hvis testen foregår i produktion, kan testeren komme i kontakt med rigtige data. Det kan ikke altid undgås, men det kan begrænses. Testkonti kan oprettes uden adgang til rigtige kunders oplysninger, og testeren kan aftale ikke at gemme mere end nødvendigt for at dokumentere et fund. Den, der har ansvaret for databeskyttelse hos jer, bør være inddraget. Datatilsynet har vejledning om behandling af personoplysninger. → Penetrationstest i produktion eller testmiljø

Hvis testeren opretter data under testen, for eksempel ordrer, beskeder eller brugere, skal det aftales, hvordan de mærkes, så de kan findes og fjernes bagefter.

Oprydning efter testen

Når testen er slut, skal testkontiene lukkes eller slettes. Adgangskoder, der er udleveret, bør ændres, hvis kontiene skal bruges igen, for eksempel til en senere kontrol af rettelser. Midlertidig fjernadgang og undtagelser for testeren skal også fjernes.

Data, testeren har oprettet, skal ryddes op i systemerne. Testerens eget materiale, som skærmbilleder og noter, skal håndteres efter aftalen om opbevaring og sletning. Skriv det ind i planen med en ansvarlig og en dato, så oprydningen ikke bliver glemt i glæden over at have modtaget rapporten.

Oplysninger ud over kontiene

Konti er ikke altid nok. Afhængigt af den viden, testeren skal have, kan det være nyttigt at udlevere en kort beskrivelse af systemets vigtigste funktioner, en oversigt over rollerne og deres forventede rettigheder, og eventuel dokumentation af grænseflader til andre systemer. Hvor meget testeren skal vide på forhånd, er et valg, der hænger sammen med testens form.

En oversigt over de forventede rettigheder er særlig nyttig. Den gør det muligt for testeren at se, om en rolle kan mere end tilsigtet, og den gør det lettere for jer at vurdere fundene bagefter. Uden oversigten må testeren gætte på, hvad der er meningen, og det kan føre til fund, der viser sig at være tilsigtet, eller til at reelle problemer bliver overset.

Saml oplysningerne i én pakke sammen med kontiene, så testeren har det hele ved start. Det sparer spørgsmål undervejs og gør det tydeligt, hvilket grundlag testen bygger på.

Det skal I lade være med

At give én konto med fuld adgang · den kan ikke vise, hvad almindelige brugere kan nå.
At oprette kontiene samme morgen · afprøv dem, før testen begynder.
At bruge rigtige medarbejderes konti · testaktivitet bliver svær at skelne fra almindelig brug.
At sende adgang i en bred mailtråd · udlever oplysningerne gennem en aftalt kanal.
At bruge rigtige personoplysninger uden overvejelse · testdata eller begrænset adgang er ofte muligt.
At glemme oprydningen · testkonti og testdata, der bliver liggende, er en unødig risiko.

Hvad kan og ikke kan konkluderes

Gode testkonti gør det muligt at undersøge de roller og funktioner, der var med. Rapporten kan kun sige noget om de roller, testeren havde adgang til. Hvis en rolle manglede, er funktionerne for den rolle ikke undersøgt fra en brugers side, og det skal fremgå.

Testdata, der afviger meget fra virkeligheden, kan betyde, at nogle problemer ikke viser sig. Det er en begrænsning, rapporten bør nævne, når den har betydning.

Tjekliste til testkonti og testdata

☐ Er de roller, der skal undersøges, valgt og beskrevet?
☐ Er der flere konti i samme rolle, hvor adskillelse skal afprøves?
☐ Er kontiene oprettet, afprøvet og navngivet som testkonti?
☐ Er tofaktor og adgangsveje afklaret?
☐ Er adgangsoplysninger udleveret gennem en aftalt kanal?
☐ Er valget mellem testdata og rigtige data afklaret med databeskyttelse?
☐ Er oprydning planlagt med ansvarlig og dato?

Kilder

OWASP Web Security Testing Guide: faglig ramme for test af identitet, adgang og roller i webapplikationer.
Datatilsynet: vejledning om behandling af personoplysninger.

Senest gennemgået: oktober 2026.