En penetrationstest skal besvare et afgrænset sikkerhedsspørgsmål og føre til rettelser, som efterprøves. Testens værdi afhænger derfor af scope, tilladelser, realistiske brugerroller og en rapport, der kan omsættes til konkrete handlinger. En scanning eller et pænt certifikat uden denne sammenhæng giver et begrænset beslutningsgrundlag.
For netbaserede tjenester bør den løbende drift også omfatte kontrol af TLS og certifikater. Et fund i en penetrationstest kan lukkes, mens certifikatfornyelse og ændrede forbindelser fortsat kræver en ansvarlig kontrol.
Guiden viser, hvordan en virksomhed kan bestille og følge op på en test af en kundeportal. Eksemplet er fiktivt og handler om planlægning, sikker gennemførelse og dokumentation. Der gives ikke en generel garanti for, at en bestemt testtype eller frekvens opfylder alle krav for enhver organisation.
Hvilket spørgsmål skal testen besvare?
Den fiktive virksomhed Stranddata udvider sin kundeportal med dokumentdeling mellem flere kundekonti. Det væsentlige spørgsmål er, om en bruger kan få adgang til en anden kundes dokumenter eller udføre handlinger uden de nødvendige rettigheder. En ren kontrol af forsiden vil ikke besvare det.
Systemejeren beskriver derfor tre relevante perspektiver: en person uden login, en almindelig kundebruger og en kundeadministrator. Supportrollen undersøges særskilt, fordi den kan have adgang på tværs af kunder. Testeren skal have tilstrækkelige testkonti til at undersøge de aftalte adskillelser.
Tag udgangspunkt i virksomhedens cyberrisikoanalyse. Hvis den væsentlige risiko er fejl i kundeadskillelsen, bør opgaven ikke bruge hele budgettet på automatiseret scanning af kendte softwareversioner. Almindelig vedligeholdelse og en målrettet manuel undersøgelse har forskellige funktioner.
Skeln mellem scanning, penetrationstest og beredskabsøvelse
En sårbarhedsscanning kan identificere bestemte kendte fejl og konfigurationsproblemer. En penetrationstest kan undersøge, om svagheder kan udnyttes eller kombineres i den aftalte sammenhæng. Begge kan være nyttige, men et værktøjs automatiske rapport er ikke nødvendigvis en fuld penetrationstest.
En beredskabsøvelse undersøger typisk også organisationens opdagelse, kommunikation og reaktion. Det er et andet mål end at gennemgå adgangskontroller i et API. Undgå at bestille flere forskellige opgaver under én uklar overskrift og derefter antage, at rapporten dækker dem alle.
Datatilsynets beskrivelse af softwaretest med fokus på sikkerhed omtaler flere typer af test og betydningen af dokumentation. NCSC’s vejledning om penetrationstest placerer testen som en del af en bredere sikkerhedspraksis. Den britiske vejledning bruges her som metodisk støtte, ikke som dansk lovgivning.
Scope skal navngive systemer og handlinger
Et scope bør identificere de præcise tjenester, miljøer og roller. Angiv også undtagelser og deres betydning for rapportens konklusion. Hvis mobilappen er uden for opgaven, må ledelsen ikke efterfølgende læse rapporten som en godkendelse af mobilappen.
Stranddata bruger et testmiljø med samme relevante adgangsmodel som den planlagte produktionsversion. Der oprettes konstruerede dokumenter hos to fiktive kunder. Miljøforskelle registreres, fordi en test af en anden konfiguration kan give falsk tryghed om produktionen.
| Scopefelt | Udfyldt aftale i eksemplet |
|---|---|
| Formål | Undersøge adgang mellem kundekonti og roller i dokumentportalen |
| Omfattet | Portalens aftalte testmiljø, tilhørende API og tre brugerroller |
| Data | Konstruerede dokumenter og testkonti hos to fiktive kunder |
| Uden for opgaven | Betalingsudbyder, medarbejdermail og social engineering |
| Tilladte handlinger | Aftalt undersøgelse af login, sessioner og adgang til testobjekter |
| Ikke tilladt | Belastningsangreb, sletning af produktionsdata og adgang til uvedkommende systemer |
| Stopkriterium | Uventet påvirkning af drift eller adgang til reelle personoplysninger |
| Kontakt | Navngiven systemejer og teknisk vagtfunktion med aftalt kanal |
Tabellen er en udfyldt model, som i en virkelig aftale suppleres med eksakte adresser, tidsrum og ansvarlige. Formuleringen »alle vores systemer« er normalt for upræcis, især når en leverandør ejer dele af infrastrukturen.
Tilladelsen skal komme fra den rette part
Sørg for, at organisationen kan give tilladelse til de aftalte aktiviteter. Et abonnement på en cloudtjeneste giver ikke nødvendigvis ret til enhver form for sikkerhedstest mod leverandørens fælles infrastruktur. Kontrollér leverandørens betingelser og eventuelle krav til anmeldelse eller godkendelse.
I Stranddatas eksempel er virksomhedens egen applikation omfattet, mens en ekstern betalingsfunktion er undtaget. Hvis testeren finder en relevant afhængighed uden for scope, rapporteres den til kontaktpersonen. Opgaven udvides ikke alene, fordi en teknisk mulighed bliver synlig.
Dokumentér tilladelsen skriftligt sammen med fortrolighed, datahåndtering og de aftalte metoder. Vurder desuden leverandørens rolle som dataansvarlig eller databehandler for den konkrete behandling. En fortrolighedsaftale og en databehandleraftale besvarer ikke præcis de samme spørgsmål.
Forbered data og drift før teststart
Testkonti skal have de rettigheder, som opgaven kræver, men ikke unødvendig adgang. Registrér deres oprettelse og planlagte lukning. Konstruerede testdata bør være tydeligt adskilt fra faktiske kundesager, så et fund kan dokumenteres uden at kopiere private oplysninger.
Hvis produktionstesten er nødvendig, skal risiko, tilladelser og begrænsninger være særligt klare. Det kan være relevant at aftale, at testeren stopper ved det mindste tilstrækkelige bevis frem for at hente flere dokumenter. En sikkerhedstest skal ikke skabe en større eksponering end nødvendigt for at påvise problemet.
Afklar, om driftsorganisationen kender testen, og hvordan aktiviteterne genkendes. Loggene skal fortsat kunne bruges til at opdage reelle hændelser. Guiden om sikkerhedslogning kan hjælpe med at forbinde testaktivitet, alarmer og opfølgning uden at slå beskyttelsen generelt fra.
Et fund skal kunne forstås og genskabes kontrolleret
Rapporten bør angive berørt funktion, forudsætninger, observeret resultat og konsekvens. Den skal også beskrive testens begrænsninger. En alvorlighedsscore kan understøtte prioritering, men bør ledsages af forklaring om, hvad en person kan blive udsat for i netop systemet.
Fiktivt rapportuddrag: »En almindelig bruger hos testkunde A kunne hente et konstrueret dokument tilhørende testkunde B. Adgangen krævede login, men dokumentets kundetilhørsforhold blev ikke kontrolleret korrekt ved udleveringen. To aftalte testobjekter blev undersøgt; ingen reelle kundedokumenter blev anvendt.«
Uddraget giver udvikleren og systemejeren et klart problem. Den tekniske dokumentation opbevares med passende adgang og tilstrækkelige detaljer til en kontrolleret gentagelse. Den almindelige ledelsesrapport behøver ikke gengive alle oplysninger, der kan bruges til at udnytte fejlen.
Fra fund til rettelse og ny prøve
Stranddata giver fundet en ejer og standser frigivelsen af den berørte funktion. Udviklingsteamet ændrer adgangskontrollen og undersøger andre funktioner med samme mønster. Det er vigtigt, fordi en rettelse af det enkelte demonstrerede dokument ikke nødvendigvis løser den bagvedliggende fejl.
Den nye prøve omfatter både den tidligere uønskede adgang og legitim brug. Testkunde A må ikke kunne hente B’s dokument, mens A fortsat skal kunne hente sit eget. Rapporten registrerer den konkrete version og det miljø, hvor kontrollen er udført.
Et afslutningsnotat lyder: »Den tidligere adgang mellem kunder kunne ikke gentages i den rettede testversion. Kontrol af egen kundes dokument lykkedes. Produktion anvender endnu den tidligere version, så fundet lukkes først efter udrulning og aftalt kontrol af den relevante konfiguration.« Det holder testresultat og faktisk drift adskilt.
Prioritér uden at skjule resterende problemer
Ikke alle fund kræver samme handling. Vurder adgangsforudsætninger, eksponering, datatyper og mulighed for udnyttelse. En teknisk middelvurdering kan stadig være vigtig, hvis den giver adgang til meget fortrolige oplysninger. Omvendt kan en scannerindikator kræve nærmere bekræftelse, før den behandles som et konstateret brud.
Hvis en rettelse udsættes, skal beslutningen beskrive begrundelse, midlertidige foranstaltninger og genvurdering. Den bør ikke blot ændre status til accepteret uden en ansvarlig. Brug skabelonen for sikkerhedsforanstaltninger efter artikel 32 til at knytte fundet til den kontrol, der skal forbedres.
Et fund er heller ikke automatisk et konstateret brud på persondatasikkerheden. Hvis undersøgelsen viser faktisk uvedkommende adgang eller anden hændelse, skal den håndteres efter virksomhedens brudprocedure. Hold den vurdering adskilt fra testens tekniske karaktergivning.
Hvad rapporten kan bevise
En penetrationstest er et udsnit af et system på et bestemt tidspunkt med bestemte metoder. Et resultat uden alvorlige fund beviser ikke, at systemet er uden sårbarheder. Omfang, tid og testerens adgang påvirker, hvad der kunne undersøges.
Artikel 32 kræver regelmæssig vurdering af foranstaltningernes effektivitet, men angiver ikke et universelt antal årlige penetrationstests for alle virksomheder. Planlæg gentagelse efter risiko og væsentlige ændringer, og vurder eventuelle sektorspecifikke krav særskilt.
Stranddata gemmer scope, tilladelser, rapport, rettelser og resultater af den nye prøve som ét forløb. Testkonti lukkes, og testmateriale håndteres efter den aftalte sletteregel. Dermed kan organisationen se både, hvad den har undersøgt, og hvilke spørgsmål der fortsat står åbne.
Myndigheds- og metodekilder er kontrolleret den 8. september 2026. Eksemplet og alle rapportresultater er fiktive.