Pentestrapport

Et staging‑miljø til testen: hvad skal ligne produktionen?

Et staging-miljø til testen: hvad skal ligne produktionen?

Mange softwarehuse vil helst have pentesten lagt i et staging-miljø, så testen ikke forstyrrer kunderne eller rører deres data. Kunderne bruger derimod produktionen, og når de læser rapporten, vil de vide, om resultatet gælder den. Svaret afhænger af, hvor tæt staging ligner produktionen på de punkter, testen undersøger: koden, opsætningen, login, roller og forbindelserne til andre systemer. Data og størrelse må gerne være anderledes. Det, der afgør sikkerheden, skal være det samme, og rapporten skal sige det.

Et staging-miljø er derfor ikke et problem i sig selv. Det bliver et problem, når ingen kan forklare forskellen. Det er jer, der kender begge miljøer, og det er derfor også jer, der skal levere forklaringen, både til testeren før start og til kunderne bagefter.

Kunden læser rapporten om produktionen

En kunde, der modtager jeres rapport, går som udgangspunkt ud fra, at den handler om det produkt, kunden selv logger ind på. Står der i omfangsafsnittet, at testen foregik i et staging-miljø, uden yderligere forklaring, kommer spørgsmålet med det samme: gælder fundene og fraværet af fund også for os?

Den generelle afvejning mellem produktion og testmiljø, set fra den virksomhed der køber testen, er beskrevet på penetrationtest.dk. For et softwarehus er afvejningen mere konkret, fordi rapporten skal udleveres og forsvares over for kunder, der ikke kender jeres miljøer. → Omfangsafsnittet

Det, der skal være ens

De forhold, der afgør, hvad testeren kan nå, skal være de samme i staging og produktion:

  • Versionen · den samme kode, eller en version, hvor forskellen til produktionen er kendt og beskrevet. → Den testede version
  • Login · samme måde at logge ind på, samme krav til totrinsbekræftelse og samme kobling til kundernes egne login, hvis produktet tilbyder det.
  • Roller og rettigheder · de samme roller med de samme rettigheder som hos kunderne.
  • Adskillelsen mellem kunder · flere testkunder, sat op på samme måde som rigtige kunder deler produktionen. → Testlejere
  • Opsætningen af platformen · de samme regler for adgang, de samme indstillinger for lager og de samme administrative adgange.
  • Grænseflader · de samme API’er og versioner, som kunderne bruger.

Afviger et af punkterne, skal afvigelsen stå i rapporten med en vurdering af, om den kan have betydning for resultatet. Vurderingen kan komme fra testeren, men oplysningen om afvigelsen skal komme fra jer, for testeren ser kun det ene miljø.

Det, der må være anderledes

Nogle forskelle er både forventelige og fornuftige:

  • Data · opdigtede testdata i stedet for rigtige kundeoplysninger. → Rigtige kundedata i testen
  • Størrelse · færre servere og mindre kapacitet, så længe opsætningen er den samme.
  • Eksterne forbindelser · integrationer, der peger på testudgaver af andre systemer, fx betalingsudbyderens testtilstand.
  • Overvågning · alarmer kan være slået fra eller sendt til et andet sted, hvis det er aftalt med jeres driftsfolk.

Forskellene skal stadig skrives ned. En integration, der er erstattet af en testudgave, er ikke afprøvet i den form, kunderne bruger. Det samme gælder beskyttelse, der kun er slået til i produktionen. Den kan gøre testen sværere der, men den kan også skjule svagheder i applikationen, som stadig findes bagved. Testeren skal vide, hvilken situation testen gælder.

Når staging ikke ligner nok

Det sker, at staging over tid er drevet fra produktionen. Nogle indstillinger er ændret direkte i produktionen og aldrig ført tilbage; nogle funktioner findes kun det ene sted. Gå forskellene igennem, før testen begynder, ikke efter. En simpel liste med punkterne ovenfor, udfyldt af en udvikler og en fra driften i fællesskab, er ofte nok. Listen kan vedlægges som bilag eller indgå i omfangsafsnittet, så kunderne kan se, at sammenligningen er gjort, og hvad den viste.

Hvis staging ikke kan bringes til at ligne produktionen nok, er der to muligheder. Den ene er at teste i produktionen med testkunder og klare aftaler om, hvad testeren må. Den anden er at kombinere: hovedparten af testen i staging og en afgrænset del i produktionen, fx de dele af produktet og platformen, som er synlige udefra. Begge kræver, at rapporten beskriver præcist, hvad der blev testet hvor. → Infrastrukturen bag produktet

Miljøet efter testen

Staging-miljøet har også en rolle, når testen er slut. Rettelserne skal afprøves, før de når kunderne, og en retest giver mest mening i et miljø, der ligner det, fundene blev gjort i. Bevar derfor opsætningen og testkunderne, til retesten er gennemført, og notér, hvis miljøet ændres i mellemtiden.

Gør det klart, hvem der har ansvaret for, at staging og produktion holdes ens. Det kan være uklart, fordi udviklerne ejer koden, og driften ejer platformen. Uden en ansvarlig vokser forskellene igen frem til næste test, og arbejdet med at sammenligne miljøerne begynder forfra. → Retest i en ny release

Et tænkt eksempel

Et softwarehus med et produkt til projektstyring lader testen foregå i staging. Før start sammenligner udviklerne de to miljøer og finder tre forskelle: login via kundernes egen identitetsløsning er ikke sat op i staging, en ældre version af API’et findes kun i produktionen, og staging har én testkunde i stedet for flere.

Softwarehuset retter de to sidste og beder testeren om en kort ekstra afprøvning af login i produktionen med en testkunde. Rapporten nævner forskellene og hvordan de blev håndteret. Når en kunde senere spørger, om testen gælder produktionen, kan svaret pege på et konkret afsnit.

Det skal I lade være med

  • At vælge staging uden at sammenligne miljøerne · forskellene opdages ellers først af kunden.
  • At teste med én testkunde i staging · adskillelsen mellem kunder kan så ikke afprøves.
  • At skrive testet i et miljø svarende til produktionen uden at nævne forskelle · kunden vil spørge, hvilke forskelle.
  • At kopiere rigtige kundedata til staging for at gøre det realistisk · det flytter kundernes oplysninger til et miljø, de ikke har sagt ja til.
  • At glemme funktioner, der kun findes i produktionen · de er ikke dækket.

Hvad kan og ikke kan konkluderes

En test i staging kan vise, hvordan produktet holder i den version og opsætning, staging havde på testdagen. Hvis miljøerne er ens på de afgørende punkter, og forskellene er beskrevet, kan kunderne bruge resultatet om produktionen med de forbehold, rapporten tager. Testen siger intet om forskelle, som ingen kendte til, eller om ændringer i produktionen efter testen.

Tjekliste før testen i staging

  • ☐ Er staging sammenlignet med produktionen før start?
  • ☐ Er version, login, roller og opsætning af platformen ens?
  • ☐ Er der flere testkunder i staging?
  • ☐ Er forskellene i data, størrelse og integrationer skrevet ned?
  • ☐ Er det besluttet, om dele af testen skal ske i produktionen?
  • ☐ Beskriver rapporten miljøet og forskellene?

Kilder

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om pentestrapporten

Læs også: Testlejere · Kodefrys under testen

→ 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.