Når en MSP overtager driften hos en ny kunde, overtager den et miljø, som andre har bygget, ændret og måske glemt dele af. En test tidligt i forløbet giver jer et dokumenteret udgangspunkt: hvad der var svagt, da I kom, og hvad der er jeres ansvar fra nu af. Det hviler på en enkel tanke. Uden et udgangspunkt kan ingen bagefter skelne mellem det, I arvede, og det, I selv har skabt.
Kunden ser skiftet som en ny start. For jer er det første gang, I står med ansvaret for noget, I ikke kender til bunds.
Det, I arver ved overtagelsen
En ny kunde kommer med en historik, som ikke nødvendigvis står fuldt beskrevet. Noget af dette kan følge med:
- Konti fra den tidligere leverandør · administrative adgange, som ingen længere bruger, men som stadig virker.
- Undtagelser uden ejer · regler i firewall eller tofaktor, som blev lavet til et formål, ingen husker.
- Systemer uden for listen · servere, webløsninger eller testmiljøer, der ikke står i overdragelsesmaterialet.
- Gamle tredjepartsforbindelser · adgange for leverandører af forretningssystemer, der ikke længere er aftaler med.
Overdragelsesmaterialet beskriver det tilsigtede. Testen viser det faktiske. → Når dokumentationen ikke passer
Hvornår testen skal ligge
Der er to gode tidspunkter. Det første er lige efter, at I har fået adgang og overblik, men før I har nået at bygge om. Så beskriver testen det miljø, I overtog. Det andet er, når jeres standardopsætning er rullet ud. Så viser testen, om jeres egen opsætning holder.
Begge tidspunkter giver mening, men de svarer på forskellige spørgsmål. Bliv enige med kunden om, hvilket spørgsmål der er vigtigst, før testen bestilles. En test midt i omlægningen beskriver en tilstand, som hverken I eller kunden skal leve med. Køberens overvejelser om test før og efter et leverandørskifte er beskrevet på penetrationtest.dk.
Hvem bestiller og betaler
Testen handler om kundens miljø, og kunden skal give tilladelsen. Det gælder også, når initiativet kommer fra jer. I kan foreslå testen, beskrive behovet og hjælpe med scope, men det er kunden, der underskriver, og som ejer rapporten.
I kan lægge testen ind i opstartsforløbet eller foreslå den som en særskilt opgave. Uanset hvad skal kunden vide, hvem testeren er, og at testeren arbejder uafhængigt af jer. Ellers kan kunden med rette spørge, om I bedømmer jer selv.
Hvad der påvirker omfanget af sådan en test, er det samme som ved andre test: antallet af systemer, adresser og lejere, testform og de krav, kunden stiller til rapporten. Kunden kan få et konkret overslag ved at bede om pris og tilbud ud fra et beskrevet scope.
Testens omfang ved en overtagelse
Scope skal ramme det, der kan gå tabt ved et skifte: det gamle og det glemte, mere end den nyeste server.
- Internetvendte systemer · alt, hvad kunden har på nettet, også det, I ikke har fået oplyst. → Overblik over internetvendte systemer
- Identitet · konti, grupper og administratorrettigheder i katalog og cloud.
- Fjernadgang · alle veje ind udefra, herunder dem, den tidligere leverandør brugte.
- Kritiske servere · især dem, der kører forretningssystemer, som en anden leverandør passer.
Den fælles vejledning fra NCSC (UK), CISA og andre myndigheder om MSP’er anbefaler at gennemgå infrastrukturen med særlig opmærksomhed på grænsen mellem leverandør og kunde, og at deaktivere konti, som en tidligere leverandør ikke længere bruger. En test ved overtagelsen er en måde at få den gennemgang bekræftet.
Forbered testen i et miljø, I ikke kender endnu
En test hos en ny kunde stiller større krav til forberedelsen end en test i et miljø, I har drevet i årevis. I ved ikke med sikkerhed, hvilke systemer der er skrøbelige, hvem der bliver berørt, eller hvordan backuppen virker i praksis.
- Gendannelse · kontrollér, at der findes en backup, I selv har set virke, før testen begynder.
- Skrøbelige systemer · spørg kunden og den tidligere leverandør, hvilke systemer der ikke tåler forstyrrelser, og skriv dem ind i aftalen med testeren. → Skrøbelige systemer
- Kontaktpersoner · både jeres tekniker og en person hos kunden, der kender forretningen, skal kunne nås.
- Brugerne · aftal med kunden, hvad medarbejderne får at vide, så servicedesken ikke modtager henvendelser, den ikke kan forklare.
Brug også testens forberedelse til jeres egen indlæring. Testerens spørgsmål om net, konti og systemer er de samme, som I selv skal kunne svare på som driftsleverandør.
Fra fund til driftsopgaver
Fund i en overtagelsestest falder i tre grupper, og det er en fordel at sortere dem med kunden med det samme.
- Arvede fund, I retter som en del af opstarten · konti, der skal lukkes, og undtagelser, der skal fjernes.
- Arvede fund, der kræver et projekt · forældede systemer, en flad netværksopbygning eller manglende adskillelse, som kunden skal tage stilling til og betale for.
- Fund i systemer, I ikke drifter · de hører hos en anden leverandør og skal sendes videre. → Fund i systemer, MSP’en ikke drifter
Skriv fordelingen ned og få kunden til at godkende den. Den bliver jeres reference, når næste test kommer. → Rettelser efter kundens test
Det skal I lade være med
- At teste uden kundens tilladelse · I har adgang, men det er kundens miljø.
- At rette alt i stilhed, før testen · så mister I udgangspunktet og muligheden for at vise, hvad I fik lukket.
- At bruge rapporten mod den tidligere leverandør · den er et udgangspunkt, ikke et regnskab.
- At love kunden en ren rapport · overtagelsestesten skal finde det, der er glemt, og det er formålet.
- At glemme de gamle adgange · en konto fra den forrige leverandør, der stadig virker, er et fund og en risiko.
- At lade testen ligge midt i omlægningen · resultatet beskriver en tilstand, ingen skal drive.
Hvad kan og ikke kan konkluderes
En test ved overtagelsen viser, hvad der kunne findes i det afgrænsede miljø på testtidspunktet. Den giver jer og kunden et fælles billede af udgangspunktet og et grundlag for at fordele ansvaret. Den fanger ikke alt, der er gemt i miljøet, og den siger ikke, om den tidligere leverandør har gjort sit arbejde dårligt. Et senere testresultat kan holdes op mod udgangspunktet, men kun hvis omfang og testform er sammenlignelige.
Tjekliste ved en ny kunde
- ☐ Har kunden givet skriftlig tilladelse til testen?
- ☐ Er det aftalt, om testen skal beskrive det overtagne miljø eller jeres opsætning?
- ☐ Omfatter scope internetvendte systemer, identitet og fjernadgang?
- ☐ Er alle kendte adgange fra den tidligere leverandør registreret?
- ☐ Er det klart, hvilke systemer andre leverandører passer?
- ☐ Er der en aftalt fordeling af fund mellem opstart, projekter og andre leverandører?
- ☐ Er rapporten gemt, så den kan bruges ved næste test?
Kilder
- NCSC (UK), CISA, NSA, FBI m.fl.: Protecting Against Cyber Threats to Managed Service Providers and their Customers (AA22-131A): gennemgang af infrastrukturen med vægt på grænsen mellem leverandør og kunde, og deaktivering af konti, som leverandøren ikke længere bruger.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: MSP og penetrationstest · Inaktive konti i Active Directory · Ny IT-chef
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
