Penetration-test

Test af MSP’ens egen sikkerhed: når kunderne spørger

Test af MSP'ens egen sikkerhed: når kunderne spørger

Spørgsmålet kommer i et sikkerhedsspørgeskema, på et kundemøde eller i en mail fra en ny IT-chef hos kunden: hvordan ved I, at jeres egen platform holder? Et godt svar hviler på en afgrænset test af det miljø, som I selv ejer og bruger til at levere driften, og på en ærlig beskrivelse af, hvad testen dækkede, hvad den fandt, og hvad I har gjort ved det. Svaret er ikke en påstand om, at alt er sikkert. Det er dokumentation for, at I har fået jeres platform afprøvet udefra og fulgt op.

Kunderne spørger, fordi jeres platform er deres indgang. En svaghed i jeres administrationsmiljø rammer ikke én kunde, men alle, der er koblet på.

Hvorfor kunderne spørger nu

Kundernes eget ansvar for leverandører er blevet tydeligere. Den fælles anbefaling fra NCSC (UK), CISA og flere andre myndigheder til MSP’er og deres kunder opfordrer kunderne til at kræve indsigt i leverandørens tilstedeværelse, aktiviteter og forbindelser til kundens net, og til at få ansvarsfordelingen skrevet ind i kontrakten. En kunde, der følger den anbefaling, vil før eller siden spørge til jeres egen sikkerhed.

Nogle kunder er selv omfattet af lovkrav og sender spørgsmålene videre ned i kæden. Hvordan kravet lyder, og hvad I kan svare juridisk, hører hjemme hos dem, der skriver om NIS2 og leverandørkæden: nis2-pentest.dk. Her handler det om den tekniske del: hvad der skal afprøves hos jer.

Det, der skal med i testen af jeres eget miljø

En test af MSP’ens platform er ikke en test af en kundes netværk. Den handler om de systemer, der giver jer adgang til kunderne. Typiske områder:

  • Administrationskonti · de konti, jeres teknikere bruger på tværs af kunder, og hvordan de er beskyttet. → Fælles administrationskonti hos MSP’en
  • Fjernstyring og overvågning · de værktøjer, der kan nå alle kunders maskiner fra ét sted. → Fjernstyringsværktøjer som testområde
  • Adskillelsen mellem kunder · om en kundes data, konti eller net kan nås fra en anden kundes udgangspunkt. → Adskillelse mellem kunder
  • Partnerrettigheder i skyen · de rettigheder, I har i kundernes Microsoft 365-lejere, og hvem hos jer der kan bruge dem.
  • Jeres egen kontor-IT · teknikernes klienter, jeres eget katalog og jeres internetvendte systemer, fordi de er vejen ind til alt det andet.

Scope skal afspejle det spørgsmål, kunderne stiller. Hvis de spørger til adgangen til deres miljøer, er det den sti, testen skal følge, ikke kun jeres hjemmeside.

Hvem der tester

Jeres egne teknikere kender platformen bedst, men en test, de selv udfører, svarer ikke på kundens spørgsmål. Kunden vil have et billede, der ikke er farvet af den, der har bygget opsætningen. NCSC sammenligner en penetrationstest med en revision af regnskabet: den daglige bogføring er jeres, men kontrollen kommer udefra. → Penetrationstest i MSP’ens ydelser

Vælg en tester, som ikke sælger jer de produkter, der indgår i platformen. Det gør resultatet lettere at forsvare over for kunderne.

Forbered driften, før I tester jer selv

En test af egen platform berører alle kunder på én gang. Det kræver mere forberedelse end en test hos en enkelt kunde.

  • Kundernes data · aftal, hvordan testeren undgår at åbne eller kopiere kundernes oplysninger, selv om adgangen findes.
  • Kundernes miljøer · hvis testen viser en vej ind til en kunde, stopper testeren ved konstateringen. Ingen kunde testes uden sin egen tilladelse.
  • Vagten · jeres egen overvågning skal vide, hvad der er aftalt, så en alarm ikke ender som en hændelsesmelding til alle kunder.
  • Ændringsstop · udskyd større omlægninger af platformen i testperioden.

Når testen finder noget alvorligt

Et alvorligt fund i jeres egen platform er ikke kun jeres problem. Hvis det giver adgang til kundernes miljøer, skal I tage stilling til tre ting med det samme: hvordan vejen lukkes, om der er tegn på, at andre har brugt den, og hvad kunderne skal have at vide. De to første er tekniske opgaver for driften. Den tredje er en beslutning for ledelsen hos jer, og den bør træffes efter de aftaler, I har med kunderne om underretning.

Vent ikke på den endelige rapport, hvis testeren melder et kritisk fund undervejs. Aftal på forhånd, hvem hos jer der modtager sådan en melding, og hvem der kan beslutte en hurtig ændring. Skriv ned, hvad der blev gjort og hvornår. Den notits bliver en del af svaret til kunderne senere.

Det, I kan svare kunderne bagefter

Den fulde rapport beskriver jeres svagheder i detaljer og bør ikke sendes rundt. Kunderne har brug for noget andet: et kort sammendrag med dato, omfang og testform, en oversigt over fundenes alvor og en status på rettelserne. Det svarer på spørgsmålet uden at give en angriber en arbejdsliste.

Skriv svaret, så det kan genbruges. Den samme tekst kan bruges i spørgeskemaer, ved nye kunders opstart og når en eksisterende kunde vil have en opdatering. Husk datoen; en beskrivelse af en test fra en tidligere version af platformen siger mindre, jo mere I har ændret siden. → Fund hos kunden og MSP’ens ord

Det skal I lade være med

  • At svare med et udsagn i stedet for en test · “vi tager sikkerhed alvorligt” besvarer ikke kundens spørgsmål.
  • At teste hjemmesiden og kalde det platformen · kunderne spørger til adgangen til deres miljøer.
  • At lade egne teknikere stå for testen alene · det giver ikke det uafhængige billede, kunden beder om.
  • At teste ind i kundernes miljøer uden deres tilladelse · jeres platform er jeres; kundens lejer er kundens.
  • At sende hele rapporten til alle kunder · et sammendrag og en status er nok.
  • At glemme at følge op · en gammel rapport med åbne alvorlige fund er et dårligere svar end ingen rapport.

Hvad kan og ikke kan konkluderes

En test af jeres platform viser, hvordan de afprøvede dele holdt på testtidspunktet, fra de udgangspunkter testeren fik. Den kan dokumentere, at I har fået platformen afprøvet uafhængigt og fulgt op på fundene. Den kan ikke garantere, at platformen er sikker i dag, og den siger intet om de enkelte kunders egne miljøer. Den erstatter heller ikke kundens egen vurdering af jer som leverandør.

Tjekliste før I tester jeres egen platform

  • ☐ Har I skrevet ned, hvilke kundespørgsmål testen skal besvare?
  • ☐ Omfatter scope administrationskonti, fjernstyring, partnerrettigheder og adskillelse mellem kunder?
  • ☐ Er det aftalt, at kundernes miljøer og data ikke testes eller åbnes?
  • ☐ Er testeren uafhængig af platformens leverandører?
  • ☐ Ved vagten og overvågningen, hvad der er aftalt?
  • ☐ Er der en skabelon til sammendraget, som kunderne kan få?
  • ☐ Er der en ejer og en plan for hvert alvorligt fund?

Kilder

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler til IT-afdelingen

Læs også: MSP og penetrationstest · Delegeret administration i Microsoft 365

→ 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.