Når en webløsning skal testes uden for produktionen, er det IT-afdelingen, der skal bygge eller klargøre det miljø, testeren arbejder i. Et miljø, der afviger meget fra produktionen, giver fund, der ikke gælder der, og overser fund, der gør. Svaret på, hvad IT skal stille op, hviler derfor på ét krav: miljøet skal ligne produktionen i alt det, der har betydning for sikkerheden, og adskille sig fra den i alt det, der handler om rigtige data og rigtige brugere.
Selve valget mellem test i produktion og test i et testmiljø er en beslutning, der træffes ved bestillingen, og den er forklaret for køberen på penetrationtest.dk. Når valget er truffet, bliver opstillingen driftens opgave.
Ligheden, der tæller
Et testmiljø behøver ikke have samme størrelse som produktionen. Det skal have samme opbygning. Det, der skal være ens, er:
- Programudgaven · samme version af løsningen og af de moduler, der er slået til.
- Webserver og platform · samme styresystem, webserver og opdateringsniveau, så fund i omgivelserne også gælder produktionen. → Webserverens opsætning
- Login og roller · samme måde at logge ind på og samme rolleopdeling, fx enkeltlogon via Entra ID og tofaktor.
- Beskyttelse foran løsningen · samme proxy, samme filtre og samme regler, eller en klar aftale om, at de er slået fra. → Webapplikationsfirewall og testen
- Indstillinger · samme sikkerhedsrelevante opsætning, fx hvor længe en session varer, og hvilke filtyper der kan uploades.
Forskelle er ikke forbudte, men de skal skrives ned, før testen starter. En forskel, testeren kender, kan tages med i vurderingen. En forskel, ingen har noteret, gør rapporten svær at bruge.
Data: realistiske, ikke rigtige
Testeren skal kunne arbejde med data, der ligner det, løsningen normalt håndterer: kunder, ordrer, sager og dokumenter. Uden data kan adgangskontrollen ikke afprøves, for der er ikke noget at have eller ikke have adgang til.
Rigtige persondata hører ikke hjemme i et testmiljø, hvis det kan undgås. PCI DSS, som Microsoft gengiver i sin vejledning om kravene, siger fx, at rigtige kortnumre ikke bruges uden for produktionen, medmindre miljøet er beskyttet som produktionen. Samme tankegang er en god rettesnor for andre følsomme data. Brug derfor:
- Opdigtede data · lavet til formålet, med samme felter og samme mængde, som rollerne skal kunne skelne imellem.
- Flere kunder eller afdelinger · så testeren kan undersøge, om den ene kan se den andens data.
- Filer og vedhæftninger · uden reelt indhold, men af de typer brugerne arbejder med.
Er en kopi af produktionens data den eneste mulighed, så er testmiljøet i praksis en del af produktionen og skal beskyttes som den. Det skal ejeren af løsningen og den dataansvarlige tage stilling til, før kopien laves.
Konti og roller til testeren
Det er IT, der opretter testkontiene. De skal dække de roller, løsningen har:
- Almindelige brugere · mindst to pr. rolle, så adskillelsen mellem brugere med samme rolle kan afprøves.
- Administratorer i løsningen · hvis administrationsdelen er omfattet.
- Eksterne roller · fx kunde, leverandør eller partner, hvis løsningen har dem.
Kontiene skal oprettes på samme måde som rigtige konti og have tydelige navne, så de kan genkendes i logs og fjernes bagefter. → Testkonti under opsyn
Integrationer og afhængigheder
En webløsning kan tale med andre systemer: betaling, e-mail, ERP, dokumentarkiv. I et testmiljø kan det være her, ligheden brister. Afklar for hver integration, om den:
- Kører mod et testsystem hos modparten · den bedste løsning, hvis modparten har et.
- Er erstattet af en simulering · så testen ikke rammer rigtige systemer, men heller ikke afprøver den rigtige forbindelse.
- Er slået fra · så funktionen ikke kan testes og skal noteres som uden for testen.
Det må ikke ske, at testmiljøet ved en fejl sender ordrer, mails eller betalinger til rigtige modtagere. Kontrollér det, før testeren får adgang.
Adskillelse fra produktionen
Et testmiljø skal være adskilt fra produktionen, så adgang til det ene ikke giver adgang til det andet. PCI DSS formulerer det som et krav om, at miljøer før produktion holdes adskilt fra produktionen, og at adskillelsen håndhæves med adgangskontrol. For IT-afdelingen betyder det i praksis:
- Egne konti og adgangskoder · ingen delte administratorkonti mellem miljøerne.
- Egne hemmeligheder · testmiljøet må ikke bruge produktionens nøgler til databaser eller integrationer. → API-nøgler og integrationskonti
- Adskilt netværk · så testmiljøet ikke kan nå produktionens servere.
Hvis testeren finder en vej fra testmiljøet til produktionen, er det et fund i sig selv, og måske et vigtigt.
Tid og ansvar for opstillingen
Et testmiljø bliver sjældent klar på en eftermiddag. Opstillingen kan involvere flere parter: IT, som drifter servere og netværk, leverandøren af løsningen, som kender udgaven og modulerne, og ejeren i forretningen, som skal godkende brugen af data. Læg derfor arbejdet ind i planen i god tid før første testdag, og giv hver opgave en navngiven ansvarlig.
Aftal også, hvem der må ændre i miljøet, mens testen står på. Hvis en udvikler lægger en ny udgave på midt i testen, kan testeren ikke vide, om et fund stadig gælder, eller om et manglende fund skyldes ændringen. Lås miljøet i testperioden, eller aftal faste tidspunkter for ændringer, som testeren får besked om. Notér den udgave, der blev testet, så rapporten kan holdes op mod produktionen bagefter. → Driftslog over testperioden
Det skal I lade være med
- At bruge en gammel kopi. Et testmiljø, der er tre udgaver bagud, tester noget, I ikke kører.
- At kopiere produktionens data uden at beskytte dem. Så har I et ekstra produktionsmiljø med svagere sikring.
- At genbruge produktionens nøgler. De bliver kendt af flere, end der er brug for.
- At glemme miljøet bagefter. Glemte testmiljøer på internettet er en fundtype for sig. → Oprydning efter testen
- At tie om forskellene. Uden en liste kan ingen afgøre, om fundene også gælder produktionen.
Hvad kan og ikke kan konkluderes
En test i et testmiljø viser, hvordan løsningen opførte sig i det miljø med den opsætning og de data, der var. Fund i koden gælder også produktionen, når udgaven er den samme. Fund i opsætning og omgivelser gælder kun, hvis opsætningen er ens. Testen siger intet om forskelle, der ikke var kendt, og ikke noget om produktionens drift, overvågning og logning.
Tjekliste før testeren får adgang
- ☐ Kører testmiljøet samme udgave som produktionen?
- ☐ Er forskellene mellem miljøerne skrevet ned?
- ☐ Er data opdigtede, eller er kopien beskyttet som produktion?
- ☐ Er testkonti oprettet for alle roller?
- ☐ Er hver integration afklaret: testsystem, simulering eller slået fra?
- ☐ Er miljøet adskilt fra produktionen i konti, nøgler og netværk?
- ☐ Er det aftalt, hvem der lukker miljøet eller rydder det op bagefter?
Kilder
- Microsoft Learn: Microsoft Entra ID and PCI-DSS Requirement 6: PCI DSS 6.5.3 om adskillelse af miljøer før produktion med adgangskontrol, 6.5.5 om rigtige kortnumre uden for produktionen og 6.5.6 om fjernelse af testdata og testkonti.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Overblik over API’er i driften · Testkonti under opsyn
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
