Penetration-test

Overblik over jeres internetvendte systemer, før testeren får listen

Overblik over jeres internetvendte systemer, før testeren får listen

En IT-afdeling kan have en liste over servere og tjenester uden at have en, der svarer præcist til det, internettet kan se. Forskellen opstår, fordi marketing, salg, leverandører og tidligere projekter sætter ting op uden om driften. Et brugbart overblik bygger derfor på flere kilder, der sammenholdes, og på en ejer for hver linje. Det er det arbejde, der skal være gjort, før en ekstern test kan afgrænses meningsfuldt.

Overblikket er ikke en opgave, testeren bør løse for jer. Testeren kan supplere, men kun I kender kontrakterne, abonnementerne og de beslutninger, der ligger bag hvert system.

Hvorfor driftens egen liste ikke slår til

Driftens dokumentation beskriver det, IT selv har bygget eller fået overdraget. Den kan mangle de løsninger, der kom til ad andre veje: en landingsside, som et bureau har lagt hos sin egen hosting, et bookingsystem, som kundeservice har abonnement på, eller en filoverførsel, som en partner har sat op med jeres domænenavn. De kører under jeres navn og kan påvirke jeres omdømme og data, selv om ingen i IT har adgang til dem.

Desuden ændrer billedet sig hele tiden. Nye cloudtjenester kan tages i brug på en eftermiddag, mens nedlukning kan ske halvt. Serveren slukkes, men navnet i DNS bliver stående, eller firewallreglen overlever det system, den var lavet til. → Glemte subdomæner og gamle DNS-poster

Opkøb, fusioner og skift af driftsleverandør gør billedet endnu mere uklart. Et datterselskab bringer sine egne domæner og hostingaftaler med, og en tidligere leverandør kan have oprettet tjenester, som aldrig blev overdraget ordentligt. Det samme gælder, når en afdeling flytter til nye lokaler, og den gamle internetforbindelse fortsat er aktiv med udstyr bag. Gennemgå derfor særligt de steder, hvor ansvaret har skiftet hænder, for det er her, linjerne uden ejer kan gemme sig.

Kilderne, der skal sammenholdes

Ingen enkelt kilde giver det fulde billede. Brug flere, og læg vægt på forskellene.

  • Domæneregistrator · alle domæner registreret i virksomhedens navn, også dem en tidligere medarbejder eller et bureau står som kontakt på.
  • DNS-zoner · de navne, der faktisk peger et sted hen, og hvem der administrerer zonen.
  • Internetforbindelser · de offentlige adresser, udbyderen har tildelt kontorer og datacenter.
  • Firewall og NAT · hvilke tjenester der er åbnet indad, og hvornår reglerne sidst blev gennemgået.
  • Cloudkonti · offentlige adresser, webtjenester og lager i de abonnementer, virksomheden betaler for.
  • Økonomi og indkøb · fakturaer på hosting, SaaS og domæner, som ikke er gået gennem IT.
  • Certifikater · udstedte certifikater kan afsløre navne, ingen havde på listen.

Den sidste kilde er let at glemme. Mange certifikater udstedes automatisk og registreres i offentlige logs, så de er et godt fingerpeg om, hvilke navne der har været i brug. Hvad offentlige oplysninger i øvrigt kan fortælle om jeres IT, er beskrevet i → Offentlige oplysninger om jeres IT.

Hver linje skal have en ejer

Et system uden ejer er et system, ingen opdaterer, og ingen kan give lov til at teste. Når listen er samlet, skal hver linje have to navne: en forretningsejer, der ved, hvad systemet bruges til, og en teknisk ansvarlig, der kan ændre på det. Det kan være jer selv, en driftsleverandør, et hostingfirma eller en SaaS-udbyder.

Hvor ingen melder sig, har I fundet noget vigtigt. Beslut, om systemet skal lukkes, overdrages til en ejer eller tages med i testen som det, det er: et system uden ansvar. → Enheder og systemer uden ejer

Ejerskabet afgør også, om systemet må testes. En tjeneste hos en udbyder kan kræve udbyderens accept, og en adresse, I har opgivet, tilhører måske en anden i dag. → Hostede servere i den eksterne test

Fra rå liste til testgrundlag

Den rå liste er ikke nødvendigvis i en form, testeren kan bruge direkte. Reducer den til det, der er relevant for testens spørgsmål, og beskriv hver linje kort.

  1. Fjern det døde · navne, der ikke svarer, og adresser, I har opgivet, skal ud af listen eller ryddes op, ikke testes.
  2. Gruppér efter formål · kundeløsninger, medarbejderadgang, mail, administration og partnerforbindelser.
  3. Markér følsomhed · hvilke systemer behandler persondata, betalinger eller styrer driften?
  4. Notér særlige hensyn · skrøbelige systemer, tjenester med faste åbningstider og løsninger, der kræver en tredjeparts accept.
  5. Datér listen · så rapporten senere kan henvise til et bestemt øjebliksbillede.

Når listen er klar, er den også et naturligt bilag til arbejdslisten før testen. → Ekstern penetrationstest i praksis

Hold overblikket levende

Det tager tid at lave overblikket første gang, og det er spild, hvis det forældes, før næste test. Gør opdateringen til en del af de processer, der alligevel findes. Når et projekt sætter noget i drift, skal listen opdateres. Når en tjeneste lukkes, skal DNS, firewallregler og certifikater med i nedlukningen. Når økonomi godkender et nyt abonnement på en webtjeneste, skal IT have besked.

Mellem testene kan løbende scanning af jeres egne adresser fange ændringer, så I ikke først opdager dem, når testeren gør. Scanningen erstatter ikke testen, men den holder listen ærlig. → Scanning mellem testene

Har virksomheden flere cloudabonnementer eller flere udbydere, så sørg for, at alle er med. Et glemt abonnement giver et blindt område i overblikket. → Flere cloudmiljøer

Det skal I lade være med

  • At bygge listen på driftsdokumentationen alene · andre afdelingers løsninger kan mangle.
  • At udelade det, I ikke selv driver · systemer under jeres navn hører med, også hos andre.
  • At acceptere linjer uden ejer · de skal lukkes, overdrages eller markeres.
  • At teste opgivne adresser · de kan tilhøre en anden i dag.
  • At lave listen én gang · uden en proces forældes den hurtigt.
  • At overlade hele kortlægningen til testeren · kun I kender kontrakter og beslutninger.

Hvad kan og ikke kan konkluderes

Et samlet overblik gør det muligt at sige, hvilken del af den samlede flade en test har dækket. Det giver ledelse og testere et fælles grundlag og kan afsløre systemer, der bør lukkes, før nogen tester noget.

Overblikket siger derimod intet om, hvor sikre systemerne er. Det er heller aldrig fuldstændigt. Der kan altid være en løsning, ingen har registreret. Skriv derfor i testgrundlaget, hvilke kilder listen bygger på, så læseren af rapporten kan vurdere, hvor meget dækningen er værd.

Tjekliste til overblikket

  • ☐ Er domæner, DNS, adresser, cloudkonti og fakturaer gennemgået?
  • ☐ Er certifikater brugt som kontrol af navne?
  • ☐ Har hver linje en forretningsejer og en teknisk ansvarlig?
  • ☐ Er linjer uden ejer håndteret?
  • ☐ Er døde navne og opgivne adresser fjernet?
  • ☐ Er følsomhed og særlige hensyn markeret?
  • ☐ Er listen dateret og knyttet til testens aftale?
  • ☐ Er det aftalt, hvem der holder listen opdateret?

Kilder

  • NCSC (UK): Penetration testing: teknisk personale definerer grænserne for det, der testes, og testen bruges til at kontrollere virksomhedens eget overblik.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler til IT-afdelingen

Læs også: Offentlige oplysninger om jeres IT · Typiske fund i en ekstern test

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest 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

Skal jeres miljø testes?

Fortæl kort, hvilke dele af jeres miljø der skal testes, og hvornår I skal bruge resultatet. Så vender jeg tilbage. Testen og rådgivningen er uvildige og uafhængige, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.