MSP’ens egen rolle: adskillelse af drift og undersøgelse

Forside › Sikring: metoderne samlet · Gennemgået oktober 2026 · Af John Nielsen

Når en hændelse hos en kunde kan hænge sammen med MSP’ens egne konti, værktøjer eller opgaver, skal MSP’en gøre tre ting: fastfryse egne ændringer i kundens miljø, eksportere og bevare sine egne logs uændret, og lade en uvildig sikre de kilder hos kunden, der skal bedømme MSP’ens rolle. MSP’en fortsætter med at drive og genoprette, men undersøger ikke sig selv. Det beskytter både kunden og MSP’en, fordi resultatet så kan stå, uanset hvilken retning det peger.

Afsnittet om MSP’ens egen rolle i tjeklisten til MSP’er giver de første punkter. Her er den tekniske uddybning.

Hvornår rollen er berørt

MSP’ens rolle er berørt, når en af disse situationer foreligger:

angrebet er kommet ind via en teknikerkonto, partneradgang, RMM-platformen eller et andet MSP-værktøj,
en sårbarhed blev udnyttet på et system, som MSP’en havde ansvaret for at opdatere,
backuppen, som MSP’en overvågede, viste sig ikke at virke,
MSP’en ændrede konfigurationen kort før hændelsen,
en af MSP’ens medarbejdere er selv under mistanke.

Det betyder ikke, at MSP’en har gjort noget forkert. Det betyder, at MSP’ens handlinger bliver en del af det, der skal undersøges.

Tre spor, der holdes adskilt

Drift · Formål: Inddæmning, genopretning, fortsat drift · Hvem: MSP’ens driftsteknikere
Undersøgelse · Formål: Sikring og analyse af hændelsen · Hvem: Uvildig sagkyndig med kundens mandat
Egen dokumentation · Formål: MSP’ens egne logs og redegørelse · Hvem: MSP’ens ledelse, adskilt fra driften

Adskillelsen er både organisatorisk og teknisk. De teknikere, der har arbejdet hos kunden i den relevante periode, bør ikke stå for eksporten af MSP’ens egne logs, og de bør ikke have adgang til den uvildiges materiale.

Fastfrys egne ændringer

Alt, hvad MSP’en ændrer efter hændelsen, kan blive set som forsøg på at rette op på egne fejl. Derfor:

Ændringsstop: kun ændringer, der er nødvendige for inddæmning og drift, og hver ændring registreres i en indgrebslog med tidspunkt og begrundelse.
Ingen oprydning i egne spor: gamle teknikerkonti, gemte scripts, RMM-politikker og planlagte opgaver bliver, hvor de er, indtil de er sikret. Skal en konto lukkes af sikkerhedshensyn, deaktiveres den i stedet for at blive slettet.
Dokumentation låses: kundens driftsdokumentation, wiki-sider og konfigurationsbeskrivelser eksporteres, som de ser ud nu, før nogen redigerer dem. Redigeringshistorikken skal bevares.
Tickets redigeres ikke: eksisterende tickets lukkes ikke om og omformuleres ikke. Nye oplysninger tilføjes som nye noter.

Eksportér egne logs

MSP’ens egne systemer er MSP’ens data, men de rummer svaret på mange af sagens spørgsmål. Eksportér dem tidligt, i rå form, med hashværdi:

RMM-konsollens revisionslog og sessionslog for kunden. Indholdet er beskrevet i IT-leverandørens adgang: RMM-logs.
Loginlog fra MSP’ens identitetsudbyder for de teknikerkonti, der har adgang til kunden.
Ticket- og PSA-historik for kunden, inklusive ændringshistorik på de enkelte tickets.
Rapporter fra patchværktøjet med status pr. enhed og tidspunkt.
Jobhistorik og alarmer fra backupkonsollen.
Alarmhistorik fra overvågningen, også alarmer, der blev kvitteret uden handling.
Revisionsloggen fra adgangskodeboksen for kundens mappe.

Et vigtigt punkt: en patchrapport, der dannes i dag, viser i dag. Har MSP’en patchet efter hændelsen, viser rapporten ikke tilstanden på hændelsestidspunktet. Det er den historiske status pr. enhed, der skal sikres, og hvis værktøjet ikke gemmer den, skal det stå klart.

Én kopi af eksporten overdrages til kunden eller den uvildige med hashliste. MSP’en beholder selv en forseglet kopi som grundlag for sin egen redegørelse.

Det, en tredjepart skal sikre

De kilder hos kunden, hvor MSP’ens handlinger kan ses, bør sikres af en, der ikke er MSP’en: kundens Entra ID-logs og revisionslog, domænecontrollere, berørte servere og endpoints, firewall og VPN. MSP’en stiller adgang til rådighed og forklarer miljøet, men tager ikke selv kopierne. Hvordan adgangen gives med navngivne konti og passende roller, er beskrevet i adgang for en ekstern sagkyndig. Notér, hvornår adgangen blev givet og fjernet.

Ligger MSP’ens flygtige spor hos kunden, fx en loginlog med kort opbevaring, og er der ikke tid til at vente, kan MSP’en sikre den med det samme, men så med to personer til stede, en log over hvert trin og en hashværdi, der straks sendes til kunden.

Når der er begået fejl

Mange MSP’er tøver med at hente en uvildig ind, fordi de frygter kritik. Teknisk set er det omvendt. En fejl, der er noteret med tidspunkt og forklaring, kan forklares. En ændring uden forklaring, foretaget efter hændelsen, kan ligne et forsøg på at skjule noget, også hvis den var helt uskyldig. Har MSP’en allerede rørt systemerne, er det beskrevet i vi har allerede rørt maskinen, hvad der stadig kan reddes. Det vigtigste er at skrive ned, hvad der er sket, og at stoppe yderligere ændringer.

Juridisk set er det MSP’ens egen dokumentation, når MSP’en er part, og hvordan advokaten ser på den, er beskrevet på digital-bevissikring.dk.

Kommunikation mens undersøgelsen står på

Driften kræver tæt kontakt med kunden, og undersøgelsen kræver afstand. Løs det ved at holde to kanaler adskilt. Driftsteknikerne taler med kunden om genopretning, adgange og status. Spørgsmål om årsag, ansvar og MSP’ens rolle går via MSP’ens ledelse og, hvor det er relevant, via advokater. Skriv i driftskanalen kun fakta med tidspunkter, og undlad forklaringer på, hvorfor noget gik galt, før analysen foreligger. Gem chat og mails med kunden i perioden uændret, også interne beskeder mellem MSP’ens teknikere om sagen. De kan blive relevante, og en slettet intern tråd vil blive bemærket, hvis den dukker op hos modtageren. Har MSP’en en ansvarsforsikring, kan den have egne krav til anmeldelse og dokumentation, som bør afklares tidligt.

Typiske faldgruber

Teknikeren, der lavede ændringen, eksporterer selv loggen over den.
Dokumentationen opdateres “så den passer”, før den er eksporteret.
Konti og scripts slettes som led i oprydningen.
Patchrapporter dannes efter patching og fremlægges som tilstanden før.
MSP’en og kunden deler samme sagkyndige, selv om kunden retter krav mod MSP’en.

Hvad adskillelsen giver

Adskillelsen kan ikke ændre, hvad der skete. Den gør det muligt at vise det. Med låste ændringer, uændrede egne logs og en uvildig sikring af kundens kilder kan MSP’ens handlinger beskrives præcist, og en eventuel uenighed kan handle om vurderingen i stedet for om, hvorvidt data er til at stole på. Det er også den bedste forudsætning for, at kunderelationen kan fortsætte bagefter, fordi begge parter har set det samme grundlag og ikke kun hinandens forklaringer. Viser undersøgelsen, at MSP’en ikke var indgangen, står den konklusion stærkere, når MSP’en ikke selv har lavet den.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: RMM-værktøjet som sikringsværktøj · Fælles sikring med modpartens sagkyndige: protokol

→ Forensisk sikring · For MSP’er · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik