En stor del af det, virksomheden viser på internettet, står ikke i eget serverrum, men hos et hostingfirma eller i en cloudplatform. Før de systemer kan komme med i en ekstern test, skal IT-afdelingen kunne svare på, hvem der råder over hver adresse, og om den, der ejer platformen, accepterer testen. Svaret afhænger af hostingformen: en dedikeret server, en virtuel server, et delt webhotel og en tjeneste i Azure eller AWS giver hver sin situation.
Hvad hosting dækker af sikkerhed i det hele taget, er forklaret for køberen på penetrationtest.dk. Her handler det om IT-afdelingens arbejde med at gøre de hostede systemer klar til testen.
Hostingformen afgør spørgsmålet
Begynd med at sortere de hostede systemer efter, hvordan de er sat op. Det afgør både, hvem der skal spørges, og hvad testen kan omfatte.
- Dedikeret server · maskinen er lejet til jer alene. Adressen er typisk tildelt jer, men hostingfirmaets vilkår gælder stadig.
- Virtuel server · I har en maskine for jer selv, men den deler fysisk platform med andre kunder. Testen må kun ramme jeres maskine.
- Delt webhotel · mange kunder deler samme server og ofte samme adresse. Adressen alene kan ikke bruges som afgrænsning, og testen skal holde sig til jeres domæne og løsning.
- Platformtjenester i cloud · I råder over en tjeneste, men ikke over den underliggende infrastruktur. Cloududbyderens regler bestemmer rammerne.
- Løsning drevet af en leverandør · systemet kører under jeres navn, men en leverandør har både platform og drift. Leverandøren skal give lov.
Sorteringen behøver ikke tage lang tid, men den fjerner mange misforståelser, før de når testeren.
Adressen skal være jeres på testdagen
Ejerskab af en adresse er ikke en fast egenskab. I cloud kan en offentlig adresse blive frigivet, når en tjeneste slukkes, og senere blive tildelt en helt anden kunde. Hos hostingfirmaer kan en adresse flytte, når en server bliver udskiftet eller flyttet til et andet datacenter.
Kontrollér derfor hver adresse tæt på testens start, ikke kun da listen blev lavet. Notér, hvilken tjeneste adressen tilhører, og om den er fast tildelt eller kan skifte. Det samme gælder domæner, der peger på adresser hos andre: et navn, der stadig peger på en adresse, I har opgivet, er et fund for sig og ikke noget, der skal testes. → Glemte subdomæner og gamle DNS-poster
Hostingfirmaets vilkår og tilladelse
Læs aftalen og de generelle vilkår for, hvad der står om sikkerhedstest. Nogle hostingfirmaer kræver forudgående besked, andre en skriftlig tilladelse, og nogle tillader slet ikke test på delte platforme. Står der intet, så spørg skriftligt.
Bed om tre ting i svaret: at testen må gennemføres på de nævnte servere eller domæner, hvem testeren skal kontakte, hvis noget bliver blokeret, og om firmaets egen overvågning bliver informeret. Det sidste er vigtigt i praksis. Hostingfirmaets systemer kan opfatte testen som et angreb og lukke for trafikken fra testeren, og så går testtid tabt. → Alarmer under testen
Gem tilladelsen sammen med opgavebeskrivelsen. Testeren skal kunne henvise til den, og I skal kunne vise den, hvis der kommer spørgsmål bagefter.
Cloudplatformene har egne regler
De store cloudplatforme beskriver selv, hvad kunder må teste. Microsoft oplyser i sin vejledning om penetrationstest i Azure, at forudgående godkendelse ikke kræves, men at Microsofts regler for penetrationstest skal følges. Reglerne begrænser testen til ressourcer, som kunden ejer eller har udtrykkelig tilladelse til at teste.
AWS har en liste over tjenester, der kan testes uden forudgående godkendelse, og beder kunder om at kontakte AWS for tjenester uden for listen. Reglerne ændres fra tid til anden, så læs dem i forbindelse med hver test. → AWS’ politik for penetrationstest
For en tredjepart, der tester på jeres vegne, er det jeres skriftlige tilladelse, der giver adgangen. Den skal nævne de abonnementer, konti eller ressourcer, testen omfatter.
Når tilladelsen ikke kommer
Det sker, at et hostingfirma ikke svarer eller siger nej. Så har I nogle valg, og de bør træffes bevidst.
- Afgræns til det, I råder over. Test jeres egen løsning på domæneniveau, hvis vilkårene tillader det, og udelad platformen.
- Udskyd den del af testen. Gennemfør resten, og tag de hostede systemer med, når tilladelsen er på plads.
- Overvej hostingformen. Et firma, der ikke vil lade jer teste jeres egen løsning, giver jer et svar, der er værd at tage med i næste valg af leverandør.
Uanset valget skal udeladelsen fremgå af rapporten, så ingen læser den som en vurdering af alle virksomhedens systemer.
Hvem retter fundene på hostede systemer?
Når rapporten kommer, skal hvert fund på et hostet system have en ejer. Er fundet i jeres løsning eller opsætning, er det typisk jeres opgave eller jeres webbureaus. Ligger det i den platform, hostingfirmaet driver, skal firmaet have besked, og I skal have et svar på, hvornår det rettes. Uklare tilfælde afgøres af aftalen.
Send fundene til hostingfirmaet i en form, firmaet kan handle på: hvilket system, hvad der blev konstateret, og hvilken alvorlighed testeren har givet det. Hele rapporten skal sjældent videre, og den kan indeholde oplysninger om andre systemer, som firmaet ikke har brug for. Aftal også, hvordan I får bekræftet, at rettelsen er sket, så I kan lukke opgaven på et grundlag og ikke på en antagelse. Hvis en MSP står mellem jer og hostingfirmaet, skal det være klart, hvem af de to der bærer sagen videre, og hvem der følger op. → Typiske fund i en ekstern test
Det skal I lade være med
- At bruge en delt adresse som afgrænsning. Den kan ramme andre kunder.
- At gå ud fra, at stilhed er accept. Få tilladelsen skriftligt.
- At glemme at kontrollere adresserne tæt på start. Ejerskab i cloud kan skifte.
- At lade hostingfirmaets overvågning være uvidende. En blokering midt i testen koster tid.
- At skjule udeladelser. Systemer, der ikke blev testet, skal stå i rapporten.
Hvad kan og ikke kan konkluderes
En ekstern test af hostede systemer siger noget om jeres løsning og den del af opsætningen, I råder over, på testtidspunktet. Den siger normalt intet om hostingfirmaets eller cloududbyderens egen platform, og den kan ikke bruges som dokumentation for, at leverandøren har styr på sin del. Der skal I spørge leverandøren direkte. → Ekstern penetrationstest i praksis
Tjekliste til de hostede systemer
- ☐ Er hvert hostet system sorteret efter hostingform?
- ☐ Er adresser og domæner kontrolleret tæt på testens start?
- ☐ Foreligger hostingfirmaets tilladelse skriftligt?
- ☐ Er firmaets overvågning og kontaktperson oplyst til testeren?
- ☐ Er cloudplatformenes regler læst for de berørte tjenester?
- ☐ Er udeladte systemer noteret, så de fremgår af rapporten?
Kilder
- Microsoft Learn: Penetration testing (Azure): ingen forudgående godkendelse, men reglerne skal følges.
- Microsoft Cloud Penetration Testing Rules of Engagement: test kun af egne ressourcer eller med udtrykkelig tilladelse.
- AWS: Penetration Testing: tjenester, der kan testes uden forudgående godkendelse.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Glemte subdomæner og gamle DNS-poster · Alarmer under testen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
