Pentestrapport

Kontornettet og produktet: to forskellige testopgaver

Kontornettet og produktet: to forskellige testopgaver

Et softwarehus har to ting, der kan testes: det produkt, kunderne logger ind i, og den IT, medarbejderne arbejder i hver dag. De to hænger sammen, men de er forskellige testopgaver med forskellige spørgsmål, forskellige ejere og forskellige modtagere af rapporten. Det, der kræver opmærksomhed, er forbindelsen imellem dem: de steder, hvor en svaghed på kontoret kan føre ind i produktet. Hvilken af de to en bestemt kunde efterspørger, afklares for sig. → Produktet eller hele virksomheden

To opgaver, to spørgsmål

Testen af produktet spørger, om en bruger eller en udefrakommende kan nå data eller funktioner, de ikke skulle have. Den ser på webapplikationen, API’et, login, roller og adskillelsen mellem kunder. Rapporten er beregnet til at blive vist, i en eller anden form, til kunderne.

Testen af kontornettet spørger, om en angriber kan komme ind i virksomhedens egen IT og bevæge sig rundt. Den ser på medarbejdernes konti, mail, bærbare, netværket og de systemer, økonomi og administration bruger. Rapporten er i første omgang til jer selv. Den kan også bruges over for en forsikring eller en revisor, men det er ikke den rapport, en kunde af produktet har brug for. Hvordan sådan en test afgrænses og gennemføres, er beskrevet på penetration-test.dk.

Hvad hører til hvilken test

Fordelingen er ikke altid indlysende. Tænk på det sådan:

  • Produktet · alt, hvad kunderne bruger eller kan nå: applikation, API, integrationer, supportfunktioner i produktet. → Scope for et SaaS-produkt
  • Infrastrukturen bag produktet · de servere, cloudkonti og netværk, produktet kører på. Den hører som regel med til produktet, fordi kundernes data ligger der. → Infrastrukturen bag produktet
  • Kontoret · medarbejdernes arbejdspladser, mail, fildeling og interne systemer uden kundedata.
  • Forbindelsen · det, der gør det muligt at komme fra kontoret til produktet.

Det sidste punkt er det, der falder ud, hvis de to opgaver planlægges hver for sig uden at tale sammen. Er I i tvivl om et system, så spørg, om der ligger kundedata i det, eller om det kan ændre produktet. Er svaret ja, hører det til produktets side.

Broen mellem kontoret og produktet

I et softwarehus går der flere veje fra medarbejdernes hverdag ind i produktet. Udviklerne har adgang til kildekoden. Byggesystemet kan udrulle ny kode til produktionen. Driftsfolk har administrative konti i cloudmiljøet. Supporten kan se kundernes data. Hver af dem er en vej, en angriber kan bruge, hvis en medarbejders konto eller computer bliver overtaget. Listen er ikke en opskrift på et angreb, men en påmindelse om, at de personer, der bygger og driver produktet, også arbejder på kontornettet. Lav en kort oversigt over, hvem der har hvilke adgange til produktionen, og hvorfra de bruges. Den oversigt er nyttig for begge testere.

Den britiske NCSC har i sin vejledning om sikker udvikling og udrulning særskilte principper for at sikre udviklingsmiljøet, beskytte kodelageret og sikre bygge- og udrulningskæden. Det understreger, at de dele er en del af produktets sikkerhed, selv om de fysisk står på kontoret.

Beslut, hvilken af de to test der skal dække broen, og skriv det i begge bestillinger. Det kan være produkttesten, der afprøver de administrative adgange, eller kontortesten, der ser på, hvor langt en overtaget udviklerkonto kan nå. Det vigtige er, at den ikke falder ud af begge. → Supportadgang og administrationsmodul

Et tænkt eksempel: Et softwarehus med et system til tidsregistrering får testet produktet hvert forår og kontornettet hvert efterår. Ved en gennemgang opdager den sikkerhedsansvarlige, at ingen af de to bestillinger nævner de administrative konti i cloudmiljøet, som tre udviklere bruger fra deres bærbare. Næste produkttest får de administrative adgange med i omfanget, og kontortesten får til opgave at vurdere, hvor godt udviklernes bærbare og konti er beskyttet. Begge bestillinger henviser nu til hinanden.

Forskellige ejere og forskellig rytme

Produkttesten følger produktet: releases, nye funktioner og kundernes behov for en aktuel rapport. Den ejes af den, der ejer kundekravene, i samarbejde med produktejeren. → Hvem ejer kundekravet?

Kontortesten følger virksomhedens egen IT: nye systemer, flytninger, skift af leverandør. Den ejes af den, der har ansvaret for den interne IT, som i et mindre softwarehus kan være den samme person, men med en anden kalender.

Lad være med at tvinge de to ind i samme tidspunkt, hvis det ikke passer. Det giver én stor opgave, der er svær at planlægge, og en rapport, hvor kunderne skal have én del og ikke den anden. Det kan dog give mening at lægge dem tæt på hinanden, så forbindelsen kan vurderes med begge resultater for øje. Overvej også, om det skal være den samme tester. Det kan gøre det lettere at se forbindelsen, men det er ikke et krav, så længe begge bestillinger beskriver grænsen.

Sådan beskriver I de to over for kunderne

Kundens spørgeskema kan spørge til begge dele i samme afsnit. Svar på hver for sig: hvad blev testet, hvornår, og hvad dækkede testen. Skriv ikke, at virksomheden er testet, hvis det kun er produktet, og omvendt. → Pentest-spørgsmålet i skemaet

Rapporten fra kontortesten bør som udgangspunkt ikke udleveres til kunder. Den beskriver jeres interne netværk og medarbejdernes udstyr, og kunderne har ikke brug for de detaljer for at vurdere produktet. Har en kunde et krav om test af jeres interne IT, kan et resumé eller en erklæring om, at testen er gennemført, være nok. → Hel rapport, resumé eller erklæring

Det skal I lade være med

  • Blande de to i én rapport · kunderne skal kunne få produktets del uden kontorets.
  • Lade broen falde ud af begge test · beslut, hvem der dækker den.
  • Bruge en kontortest som svar på et produktkrav · eller omvendt.
  • Udlevere kontorrapporten i detaljer · den beskriver jeres interne IT.
  • Glemme kildekode og byggesystem · de er en del af produktets sikkerhed.

Hvad kan og ikke kan konkluderes

En produkttest siger noget om det, kunderne bruger. En kontortest siger noget om virksomhedens egen IT. Ingen af dem siger alene noget om den anden, og forbindelsen mellem dem er kun dækket, hvis en af testene har haft den med i omfanget. En god rapport fra produkttesten udelukker derfor ikke, at en overtaget medarbejderkonto kunne give adgang til produktionen. Og en god rapport fra kontortesten siger intet om, hvorvidt adskillelsen mellem kunderne holder. Når I svarer kunder eller ledelse, skal svaret pege på den test, der faktisk dækker spørgsmålet.

Tjekliste til de to opgaver

  • ☐ Er det klart, hvad der hører til produktet, og hvad der hører til kontoret?
  • ☐ Er det besluttet, hvilken test der dækker forbindelsen?
  • ☐ Har hver test sin ejer og sin rytme?
  • ☐ Kan produktets rapport udleveres uden kontorets?
  • ☐ Svarer I på hver test for sig i kundernes skemaer?
  • ☐ Er kodelager, byggesystem og administrative adgange vurderet?

Kilder

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om pentestrapporten

Læs også: Hvad skal med i en penetrationstest af et SaaS-produkt? · Supportadgang og administrationsmodul

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Kræver kunden en pentestrapport?

Skriv kort, hvilket krav kunden har stillet, og hvornår dokumentationen skal ligge klar. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.