En virksomhed i transport og logistik lever af at udveksle oplysninger med andre: ordrer fra kunder, opgaver til vognmænd, status til modtagere og data til lager og fakturering. En penetrationstest kan belyse, om de forbindelser kun giver den adgang, der er tiltænkt. Svaret hviler på et overblik over, hvem virksomheden er forbundet med, og hvilke forbindelser den selv ejer.
Netop antallet af forbindelser gør opgaven særlig. Hver partner, hver kundeportal og hver integration er en indgang, og grænsen mellem virksomhedens egne systemer og partnernes kan være uklar. Testen begynder derfor med en kortlægning og ikke med en adresse.
Kortlæg forbindelserne først
En liste over forbindelser er grundlaget for at vælge, hvad testen skal omfatte. Den bør beskrive, hvem forbindelsen går til, hvilke oplysninger der udveksles, og hvem der har bygget og driver den.
- Kunder · ordreindgang, bookinger og adgang til egne forsendelser.
- Vognmænd og underleverandører · opgaver, ruter og kvitteringer for levering.
- Modtagere · sporing og meddelelser om levering.
- Lager · forbindelse mellem lagerstyring, ERP-systemet og håndtering af gods.
- Myndigheder og platforme · indberetninger og udveksling via fælles løsninger.
- Økonomi · fakturering, afregning og betaling.
Listen viser, at nogle forbindelser er virksomhedens egne, mens andre ejes af partnere eller platforme. Det er den skelnen, der afgør, hvad testen kan omfatte.
Notér også, hvem der er kontaktperson for hver forbindelse. Under testen kan en partner opleve fejl eller afviste forespørgsler, og så skal det være klart, hvem der svarer. Efter testen skal fund i en forbindelse sendes til den, der kan rette den, og det er ikke altid virksomheden selv. → Integrationer i en penetrationstest
Kundeportal og sporing
En logistikløsning kan give kunderne mulighed for at booke, følge forsendelser og hente dokumenter i en portal. Hvis virksomheden har en sådan portal, er adskillelsen mellem kunder det centrale spørgsmål. En kunde må kun se sine egne forsendelser, adresser og dokumenter.
Sporing for modtagere er et særligt forhold. En side, hvor alle med et forsendelsesnummer kan se status, kan være et bevidst valg, men det bør være overvejet, hvilke oplysninger der vises, og om de kan nås af andre end dem, der har fået nummeret. En test kan belyse, om siden viser mere, end virksomheden har besluttet. → Kunders data holdt adskilt
Testen skal bruge testkunder og testforsendelser, der ikke kan forveksles med rigtige. Ellers kan en testbooking ende med at blive sendt ud til en vognmand.
API og partnerforbindelser
Forbindelser til kunder og partnere kan være bygget som API’er, filoverførsler eller udveksling via en fælles platform. Når en kunde eller vognmand får adgang til et API, er det vigtigt, at adgangen er begrænset til deres egne oplysninger og handlinger.
En test kan afprøve virksomhedens egne API’er med de nøgler eller konti, en partner får. Den kan ikke afprøve partnerens systemer uden partnerens tilladelse. Hvis en forbindelse er åbnet for nylig, eller hvis flere partnere er kommet til, er det en naturlig anledning til at se på den. → Når et API åbnes for partnere
Overvej også, hvad en partner kan gøre, ikke kun hvad den kan se. En vognmand, der kan kvittere for levering, eller en kunde, der kan ændre en leveringsadresse, udfører handlinger med betydning for virksomheden og for modtagerne. Sådanne handlinger bør være med i beskrivelsen af de roller, testen skal bruge.
Gamle forbindelser er værd at gennemgå. En partner, der ikke længere bruges, kan stadig have en aktiv nøgle eller en åben overførsel. At rydde op i dem kræver ikke en test, men en test kan pege på dem, hvis de er med i scope.
Leverandører og fjernadgang
Lagerautomatik, terminaler og andre systemer kan have service fra leverandører, som har adgang udefra. Det samme kan gælde den virksomhed, der driver transportstyringssystemet. Adgangen skal være kendt, begrænset og lukket, når den ikke bruges.
For testen er spørgsmålet, hvordan virksomhedens side af fjernadgangen er sat op, og hvem der skal give tilladelse. Leverandørernes egne systemer ligger uden for, medmindre de selv har givet lov. → Leverandørers adgang
Døgndrift og flere lokationer
Transport og lager kan køre hele døgnet. Et testvindue, der passer kontoret, kan falde midt i den travleste tid på terminalen. Planlæg derfor med dem, der kender driften, og aftal, hvem der kan stoppe testen, hvis forsendelser eller lager påvirkes. → Testvinduet
Virksomheder med flere terminaler eller lagre kan have net, der er bygget op over tid og på forskellige måder. Det kan være relevant at vælge én lokation som udgangspunkt og vurdere, om resultatet kan overføres til de andre, eller om de skal have hver sin vurdering.
Håndholdte enheder og terminaler på lager og i biler kan være forbundet til virksomhedens systemer. Testen kan belyse, hvordan de logger på, og hvad de giver adgang til fra nettet, mens selve programmerne på enhederne kræver en særskilt afgrænsning.
Krav fra kunder og regler
Kunder kan stille krav om dokumentation for sikkerhed, også krav, der stammer fra deres egne forpligtelser. NIS2-direktivet nævner transport blandt sektorerne i bilag I. Om en virksomhed er omfattet, afhænger af blandt andet aktivitet og størrelse og af den danske gennemførelse. Det er et spørgsmål, virksomheden selv må afklare, gerne med hjælp fra en jurist. Teksten er ikke juridisk rådgivning.
Når et krav kommer fra en kunde, er det første skridt at få præciseret, hvad der skal dokumenteres, for hvilke dele af leverancen, og i hvilken form kunden vil modtage svaret. → NIS2 i leverandørkæden
Det skal I lade være med
- At teste uden et overblik over forbindelserne · Det er dem, der gør opgaven særlig.
- At afprøve partneres systemer uden tilladelse · Testen kan kun omfatte det, I selv råder over.
- At bruge rigtige forsendelser som testdata · En testbooking kan ende hos en vognmand.
- At lægge testen i den travleste tid · Terminal og lager kan køre hele døgnet.
- At lade gamle partnernøgler blive liggende · Ophørte samarbejder bør også ophøre teknisk.
Hvad kan og ikke kan konkluderes
En test kan vise, hvordan virksomhedens egne portaler, API’er og forbindelser holdt under testen, og om adgangen for kunder og partnere var begrænset som tiltænkt.
Den kan ikke dokumentere sikkerheden hos partnere, platforme eller leverandører, der ikke indgik. Den kan heller ikke afgøre, om virksomheden er omfattet af regler eller overholder dem.
Tjekliste før testen
- ☐ Er alle forbindelser til kunder, partnere og leverandører opført?
- ☐ Er det klart, hvilke forbindelser virksomheden selv ejer?
- ☐ Er der testkunder og testforsendelser, der ikke kan forveksles med rigtige?
- ☐ Er partnere og leverandører, der berøres, informeret og har givet tilladelse?
- ☐ Er testvinduet planlagt med driften på terminal og lager?
- ☐ Er det besluttet, hvilke lokationer der indgår?
Kilder
- NIS2-direktivet (EU) 2022/2555, bilag I: transport som en af de nævnte sektorer.
- OWASP API Security: oversigt over risici ved API’er.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Kunden beder om en pentestrapport · Nyt kontor på netværket · Byggeri og ejendomme · Rederier og søfart
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
