IT-chefen i et softwarehus får at vide, at en stor kunde kræver en penetrationstest, og at IT skal sørge for den. Ved nærmere eftersyn handler kravet om det produkt, virksomheden sælger, ikke om kontornettet, katalogsystemet eller medarbejdernes klienter. Det ændrer både scope, ansvar og hvem der skal læse rapporten. IT-afdelingens første opgave er derfor at skelne de to: hvad kunden spørger til, og hvilken del af det IT faktisk ejer.
Svaret afgør, om testen bliver en test af IT-driften, en test af produktet eller begge dele, og hvem der skal rette det, testen finder.
To forskellige test med samme navn
En test af den interne IT handler om de systemer, virksomheden selv bruger: netværk, identitet, Microsoft 365, servere og klienter. En test af produktet handler om det, kunderne bruger: webapplikationen, API’et, adskillelsen mellem kunder og de roller, brugerne har i løsningen. OWASP’s vejledning til test af webapplikationer beskriver den anden type, og den kræver andre forberedelser og en anden modtager af rapporten.
Begge kaldes penetrationstest. Men en rapport om kontornettet besvarer ikke kundens spørgsmål om produktet, og omvendt. Hvis kravet er formuleret upræcist, så bed om at få det præciseret, før noget bestilles.
Hvem ejer hvad
I et softwarehus kan ansvaret være delt. Udviklingen ejer koden og produktets funktioner. IT-afdelingen ejer den interne drift og måske også den platform, produktet kører på. Grænsen er ikke altid tydelig, og testen kan gøre den synlig.
- Produktets funktioner og kode · udviklingens ansvar, også når fundet skal rettes.
- Hostingplatformen · servere, cloudabonnementer og netværk, som produktet kører på, kan ligge hos IT eller hos udviklingen.
- Udviklingsværktøjer · byggeservere, kodelager og udrulning kan være IT’s systemer, selv om udviklerne bruger dem. → Byggeservere som testområde
- Adgangen til kundedata · hvem der kan nå produktionsdata, og hvordan, er et fælles spørgsmål.
Skriv fordelingen ned, før testen begynder. Så er det klart, hvem der modtager hvilke fund.
Hvor kundens krav og IT’s område mødes
Selv når kravet gælder produktet, er der dele, hvor IT-afdelingen er direkte involveret. En angriber, der vil nå produktets data, kan gå gennem produktet, men også gennem de systemer, der administrerer det.
- Administrativ adgang til produktionen · medarbejdere med adgang til produktionsmiljøet bruger IT’s konti og klienter.
- Cloudmiljøet · rettigheder i abonnementer og konti, som både drift og udvikling bruger. → Azure som testområde
- Byggekæden · en svaghed i byggeserveren kan påvirke det, der bliver udrullet til kunderne.
- Infrastruktur som kode · opsætningen af produktionsmiljøet kan være beskrevet i filer, som flere har adgang til. → Infrastruktur som kode
Kunden kan spørge til disse områder, når den vil vide, om produktet er beskyttet. Det kan være relevant at tage dem med i scope, selv om hovedtesten er af selve applikationen.
Det, IT bidrager med til produkttesten
IT-afdelingen har praktiske opgaver, også når testen ejes af udviklingen.
- Testmiljø eller produktion · aftal med udviklingen, hvor testen foregår, og hvad det betyder for data. → Testmiljø til webtest
- Testkonti · flere kunder i løsningen og flere roller, så adskillelsen kan afprøves.
- Cloududbyderens regler · test i Azure eller AWS skal følge udbyderens regler for penetrationstest. Microsoft kræver ikke forudgående godkendelse for test af egne Azure-ressourcer, men henviser til sine regler for test. → AWS’ regler for test
- Overvågning og alarmer · driftens overvågning af produktionen skal vide, hvad der er aftalt.
- Backup · en kontrolleret backup før testen, hvis den sker i produktionen.
Fund, der går på tværs
Nogle fund i en produkttest peger ikke på koden, men på driften omkring den. Det kan være en administrationsflade, der kan nås fra internettet, en cloudkonto med bredere rettigheder end nødvendigt eller en hemmelig nøgle, der ligger et sted, hvor for mange kan læse den. Omvendt kan en test af den interne IT finde en udviklers klient med adgang til produktionen, som er dårligere beskyttet end resten.
Den slags fund skal ikke ende i en diskussion om, hvis test det var. Aftal på forhånd, at fund i grænseområdet fordeles efter, hvem der ejer det berørte system, uanset hvilken test der fandt dem. Giv hvert fund én ejer, også når rettelsen kræver, at både drift og udvikling gør noget. Et fund med to ejere har i praksis ingen.
Brug også fundene til at se på arbejdsdelingen. Hvis flere fund ligger i grænseområdet, kan det være et tegn på, at ansvaret for produktionsmiljøet ikke er beskrevet klart nok.
Rapporten og kunden
En rapport om produktet skal kunne vises til kunder, i hvert fald i form af et sammendrag. En rapport om den interne IT er et internt dokument. Hold dem adskilt, også hvis de bestilles samtidig. Kunden skal have svar på sit spørgsmål, men har ikke brug for at kende detaljerne i kontornettet. Hvis kunden også spørger til den interne IT, kan der laves et særskilt sammendrag af den del, med dato, omfang og status på alvorlige fund.
Hvordan softwarehuse håndterer kundernes krav om rapporter, sikkerhedsspørgeskemaer og test i takt med nye udgivelser, er et selvstændigt emne. Det er beskrevet fra leverandørens side på pentestrapport.dk.
Det skal I lade være med
- At teste kontornettet, når kunden spørger til produktet · rapporten besvarer ikke kundens spørgsmål.
- At overlade hele produkttesten til IT · fund i koden skal rettes af udviklingen.
- At glemme den administrative adgang · vejen til kundedata går også gennem IT’s systemer.
- At teste i skyen uden at kende udbyderens regler · cloudplatformene har egne vilkår for test.
- At teste med én testkunde · adskillelsen mellem kunder kan ikke afprøves uden flere.
- At sende den interne rapport til kunden · kunden skal have svar om produktet, ikke om kontoret.
Hvad kan og ikke kan konkluderes
En test af produktet viser, hvordan det afprøvede produkt holdt i den testede version og det testede miljø. Den siger ikke noget om den interne IT, medmindre den også var med i scope. En test af den interne IT kan på samme måde ikke bruges som svar på et krav om test af produktet. Begge resultater er øjebliksbilleder, og en ny udgivelse kan ændre billedet.
Tjekliste, når kravet kommer fra en kunde
- ☐ Er det afklaret, om kravet gælder produktet, den interne IT eller begge?
- ☐ Er det skrevet ned, hvem der ejer kode, hostingplatform, byggekæde og adgang til kundedata?
- ☐ Er administrativ adgang til produktionen overvejet i scope?
- ☐ Er cloududbyderens regler for test kendt?
- ☐ Er der testkonti med flere kunder og roller?
- ☐ Er det aftalt, hvilken rapport kunden får, og hvilken der er intern?
Kilder
- OWASP Web Security Testing Guide: faglig ramme for test af webapplikationer og deres autorisation.
- Microsoft Learn: Penetration testing (Azure): forudgående godkendelse kræves ikke for test af egne Azure-ressourcer; testen skal følge Microsofts regler for test.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: API’er i driften · Drift af andres webapplikationer · NIS2 set fra IT-driften
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
