Testmiljøer giver fund, fordi de ofte har produktionens data og en lavere grad af opsyn end produktion. De bliver sat op hurtigt, åbnet for en leverandør og glemt, når projektet er slut. Gennemgangen skal derfor have dem med, men den behøver ikke gennemgå dem lige så grundigt som produktion.
Kontrollen af testmiljøer har tre spørgsmål. Er de adskilt fra produktion? Hvilke data ligger der i dem? Og kan de nås udefra?
Målestokken
Bilaget til gennemførelsesforordning (EU) 2024/2690 er usædvanligt konkret her. Punkt 6.8.2, litra h, kræver at “adskille systemerne i produktionsmiljøet for de relevante enheders tjenester fra systemer, der anvendes til udvikling og test, herunder sikkerhedskopier”. Punkt 6.2.2, litra e og f, kræver, at data til sikkerhedstest udvælges, beskyttes og forvaltes passende, og at testdata renses og anonymiseres efter risikovurderingen.
Forordningen gælder for de udbydere af digitale tjenester, der står i artikel 1, fx cloudtjenester, datacentre og administrerede tjenester. Andre virksomheder kan låne bilaget som målestok. Det er vores tolkning. Artikel 2, stk. 2, siger desuden, at kravene anvendes i forhold til risiciene.
Vejledningen til de statslige minimumskrav siger, at internetvendte tjenester også omfatter systemer til egne medarbejdere, hvis de kan tilgås direkte fra internettet. Kravene binder statslige myndigheder. At et testmiljø, der kan nås fra internettet, derfor hører med i en gennemgang af internetvendte tjenester, er vores tolkning.
Adskillelse
Adskillelse kan læses på tre niveauer.
Det første er netværket. Står testmiljøet på samme net som produktion, eller er der en zonegrænse med regler imellem? Kan en server i test tale direkte med en database i produktion?
Det andet er identiteterne. Bruger test og produktion samme administratorkonti og samme servicekonti? Er det tilfældet, giver en svag konto i test adgang til produktion. Kontrollen er at sammenligne listerne over privilegerede konti i de to miljøer.
Det tredje er backuppen. Bilaget nævner udtrykkeligt sikkerhedskopier. Ligger backup af test og produktion samme sted med samme adgang, er adskillelsen ufuldstændig.
Data i test
Det andet spørgsmål er, hvilke data der ligger i testmiljøet. Det er almindeligt at kopiere produktionsdatabasen til test, fordi det er hurtigt. Bilagets krav om at rense og anonymisere testdata efter risikovurderingen gør det til et kontrolpunkt.
Gennemgangen kan bede om en liste over testmiljøer med svar på tre spørgsmål: Hvor kommer data fra? Hvornår blev de sidst kopieret? Og er de renset eller anonymiseret, og hvordan? Svaret “kopi af produktion uden ændringer” betyder, at testmiljøet skal beskyttes som produktion. Det er et fund, hvis det ikke er sket.
Adgang udefra
Det tredje spørgsmål er, om testmiljøet kan nås fra internettet. Ofte er det sket for at give en leverandør adgang eller for at lade en kunde afprøve en ny version. Kontrollen er den samme som for produktionens internetvendte tjenester: Hvilke adresser og porte er åbne, og hvem har brug for dem?
Hvordan alle åbninger udefra opgøres, er beskrevet i opgørelsen indefra og udefra. Testmiljøer bør stå i den opgørelse med navn, så de ikke forveksles med produktion.
Uden at fordoble omfanget
En fuld gennemgang af hvert testmiljø vil fordoble arbejdet. Fremgangsmåden nedenfor er praksis, som kilderne ikke beskriver. Det kan være nok med:
- en liste over alle udviklings- og testmiljøer med ejer og formål,
- netadgang fra internettet og til produktion for hvert,
- en sammenligning af privilegerede konti med produktion,
- oplysningen om, hvor data kommer fra, og om de er renset.
Viser listen, at et testmiljø har produktionsdata og kan nås udefra, kan det komme med i den fulde gennemgang. De andre klares med de fire punkter. Hvordan omfanget i øvrigt afgrænses, står i afgrænsning efter eksponering.
Udviklernes egne maskiner
Udviklingsmiljøer er ikke altid servere. Ofte ligger en del af dem på udviklernes egne maskiner, med lokale databaser og kopier af data. De maskiner hører med i opgørelsen af klienter, men kontrollen af data hører hjemme her. Spørgsmålet er, om der ligger produktionsdata på dem, og om maskinerne er krypteret.
Miljøer, der ikke bruges længere
Testmiljøer overlever ofte de projekter, de blev bygget til. Listen bør derfor have en dato for seneste brug. Miljøer, der ikke er brugt længe, kan lukkes, og lukningen skal følges af oprydning i konti, regler og DNS-poster. Oprydningen har sit eget kontrolpunkt med en tjekliste i når et system lukkes, hvor felterne står.
Hvad det kræver, og hvad det koster at lade være
Det kræver en liste over miljøerne, som ofte ikke findes i forvejen, og en person i udviklingen eller driften, der kan svare for hvert. Når listen er lavet, er kontrollen kort.
Uden kontrollen kan testmiljøet være den nemmeste vej til produktionens data. Data er de samme, adgangen er bredere, og ingen ser efter.
Det skal I lade være med
- At kopiere produktionsdata til test uden at beslutte det · rens eller anonymisér, eller beskyt test som produktion.
- At bruge de samme administratorkonti i test og produktion · giv hvert miljø sine egne.
- At åbne test mod internettet uden slutdato · skriv, hvem der har brug for adgangen, og hvornår den lukkes.
Det skal gennemgangen kunne vise
- ☐ En liste over udviklings- og testmiljøer med ejer, formål og seneste brug.
- ☐ Netadgang fra internettet og til produktion for hvert miljø.
- ☐ En sammenligning af privilegerede konti i test og produktion.
- ☐ Kilden til data i hvert miljø, og om de er renset.
- ☐ Om backup af test og produktion er adskilt.
Kilder
- Gennemførelsesforordning (EU) 2024/2690, artikel 1 og 2 og bilaget, punkt 6.2.2 og 6.8.2, læst 13. november 2026.
- Vejledning til de tekniske minimumskrav (september 2025), afsnit 2 og 3.9, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Lav en liste over jeres test- og udviklingsmiljøer, og skriv ved hvert, hvor data kommer fra.
Læs også: Kildekodeplatform og udrulningskæde · Segmentering på papiret og i regelsættet
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
