Fjernindsamling via agent eller netværk

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

Fjernindsamling (remote collection) betyder, at data sikres fra en computer eller server over netværket, uden at nogen sidder ved maskinen. Det sker enten via en agent, der er installeret på forhånd, typisk som del af et EDR- eller administrationsværktøj, eller via en midlertidig forbindelse, hvor indsamlingsværktøjet startes fra en central maskine. Fjernindsamling er forsvarlig, når integriteten kan vises fra kilde til modtager, når agentens egen påvirkning af systemet er kendt og dokumenteret, og når den, der sikrer, har et lovligt grundlag for adgangen.

Hvornår fjernindsamling er det rigtige valg

Fjernindsamling vælges typisk, når:

maskinen står et sted, hvor ingen kan møde frem i tide, fx på en anden adresse eller hos en hjemmearbejdende medarbejder,
mange maskiner skal sikres samtidig under en hændelse,
en server ikke må lukkes ned eller kun kan nås over netværket,
data er flygtige, og transporttiden ville betyde, at de går tabt.

Den er ikke det rigtige valg, når en fuld fysisk kopi af en enkelt computer er nødvendig og kan nås, når netværksforbindelsen er så ustabil, at overførslen ikke kan gennemføres pålideligt, eller når brugeren selv har kontrol over maskinen og kan afbryde eller påvirke indsamlingen. Hvad der skal sikres, og i hvilken rækkefølge, afgøres før metoden. → Identifikation af datakilder

To grundformer

Agentbaseret · Agenten kører allerede med høje rettigheder; indsamling startes fra en konsol; output sendes til en central server. Om RMM-værktøjer, se RMM som sikringsværktøj
Agentløs · Værktøjet kopieres midlertidigt til maskinen via administrativ adgang og fjernes igen; eller disken læses som netværksblok

Agentbaseret indsamling har den fordel, at intet nyt skal installeres under sagen. Agenten efterlader dog sine egne spor: logs, midlertidige filer, tjenester og netværkstrafik. Agentløs indsamling installerer noget nyt og efterlader derfor spor af installationen, oprettelsen af en tjeneste eller en fjernforbindelse i hændelseslogs. Begge former ændrer systemet. Spørgsmålet er, om ændringerne er kendte og beskrevne.

Hvad der kan indsamles

Over netværket kan i princippet alt indsamles, som også kan indsamles lokalt:

målrettede filer og artefakter efter en målliste,
live response-oplysninger som processer, forbindelser og sessioner,
en RAM-kopi,
en fuld kopi af disken som blok-for-blok-læsning.

I praksis begrænses det af båndbredde. En RAM-kopi på 16 GB eller en fuld kopi af en disk på 1 TB over en hjemmeforbindelse kan tage timer eller dage, og jo længere overførslen varer, jo større er risikoen for afbrydelse og for, at systemet ændrer sig undervejs. Derfor er fjernindsamling oftest målrettet. Udvælgelse og dokumentation af filtre er beskrevet i Målrettet indsamling.

Integritet under overførslen

Overførslen er det svage led. Tre forhold skal være på plads:

Hash ved kilden. Hashværdien beregnes på maskinen, før data sendes, og igen ved modtageren. Kun når de to stemmer, er det vist, at overførslen ikke har ændret data. Beregnes hashværdien først på serveren, dokumenterer den kun tilstanden efter overførslen.
Krypteret forbindelse. Data sendes over en krypteret kanal, så de hverken kan læses eller ændres undervejs. Notér protokollen og certifikatet, hvis værktøjet viser det.
Fuldstændighed. Ved afbrudte overførsler skal det kunne vises, at genoptagelsen ikke har givet huller eller dubletter. Værktøjer, der deler data i blokke med hver sin hashværdi, gør det lettere.

Hvis kilden er et kørende system, kan en ny læsning give en anden hashværdi, fordi data har ændret sig. Det er ikke en fejl i overførslen, men det skal forklares. → Hashalgoritmer i forensic

Agentens påvirkning

Før fjernindsamling bruges i en sag, bør du kende svaret på:

Hvilke filer skriver agenten lokalt, og hvor? Midlertidige filer på systemdisken kan overskrive slettede data.
Hvilke hændelser registrerer styresystemet, når indsamlingen startes, fx tjenesteoprettelse, logon af en servicekonto eller en ny proces?
Ændrer agenten tidsstempler på de filer, den læser, fx senest tilgået?
Hvilken version af agenten kørte, og er den afprøvet på et testsystem?

Svarene hører hjemme i dokumentationen, så dine egne spor kan skilles fra de spor, sagen handler om. Afprøvning af værktøjer er beskrevet i Verifikation af værktøjer.

Cloud-administrerede enheder

Mange computere administreres i dag fra en cloudkonsol, fx via MDM eller et EDR-system, uden at de nogensinde er på virksomhedens lokale netværk. Konsollen kan ofte hente filer, køre scripts eller starte en indsamlingspakke på enheden, så snart den er online. Det giver rækkevidde, men også nogle særlige forhold:

Kommandoen udføres først, når enheden næste gang kontakter tjenesten. Tidspunktet for bestilling og tidspunktet for udførelse kan ligge langt fra hinanden, og begge skal noteres.
Resultatet lagres typisk midlertidigt hos tjenesteudbyderen, før det hentes ned. Det led skal med i kæden af ansvar.
Konsollens egen auditlog viser, hvem der bestilte indsamlingen. Eksportér den sammen med resultatet.
Konsollerne har ofte en grænse for, hvor store filer der kan hentes, og for hvor længe en kommando må køre. I Microsoft Defender for Endpoint var grænsen for at hente en fil via live response 3 GB på tidspunktet for gennemgangen (oktober 2026). Store filer kan derfor mangle eller kræve en anden metode, og det skal fremgå af dokumentationen.

Indsamling fra cloudtjenester, der ikke kører på enheden, fx postkasser og fildelingstjenester, er en anden disciplin og beskrevet i Cloud-forensic: sikring via API og administratoreksport.

Adgang og grundlag

Fjernindsamling forudsætter administrativ adgang til maskinen. Adgangen skal være lovlig og knyttet til sagen: virksomhedens egne maskiner under en intern undersøgelse eller hændelse, med det grundlag virksomhedens politikker og aftaler giver. Private enheder, som virksomheden ikke administrerer, eller enheder hos en modpart, kan ikke indsamles fjernt uden samtykke eller en afgørelse. Selve administrationsværktøjet er ikke et grundlag. At adgangen teknisk findes, betyder ikke, at den må bruges til alt.

Hvor IT-leverandøren eller MSP’en har adgangen, bør det overvejes, om leverandøren selv kan være part i sagen. Er det tilfældet, bør indsamlingen udføres eller kontrolleres af en anden. Rollefordelingen mellem virksomhed og leverandør er beskrevet på IT-leverandøren vil ikke udlevere adgange eller data.

Fejlkilder

Tidszoner: Konsollen kan vise tidsstempler i sin egen tidszone, mens maskinen har en anden.
Ufuldstændige resultater: Maskiner, der var slukkede eller offline, giver tomme svar, som kan forveksles med “intet fundet”.
Rettigheder: En agent uden tilstrækkelige rettigheder springer filer over uden at fejle synligt.
Brugerens indgreb: En bruger, der sidder ved maskinen, kan slukke den eller afbryde forbindelsen midt i indsamlingen.
Cache i konsollen: Nogle konsoller viser data fra seneste rapportering, ikke en ny læsning. Notér, hvilket der er tale om.

Hvad fjernindsamlingen kan og ikke kan bevise

Fjernindsamling kan levere data af samme kvalitet som en lokal indsamling, hvis integriteten er dokumenteret fra kilde til modtager. Den kan ikke vise fysiske forhold, fx om der var tilsluttet et USB-medie, der ikke blev monteret, eller hvem der sad ved maskinen. Er den fysiske enhed vigtig, bør den efterfølgende sikres lokalt.

Dokumentation

Notatet bør indeholde: maskinens identifikation, netværksadresse og navn, tidspunkt for start og slut, værktøj eller agent med version, den konto der blev brugt, målliste, hashværdier ved kilde og modtager, afbrydelser og genoptagelser, og de kendte spor, indsamlingen selv har efterladt.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Live response: sikring af en kørende computer eller server · Sluk, isolér eller lad den køre? Beslutningen ved en tændt enhed

→ Forensisk sikring · For IT-sikkerhed og SOC · 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