DigitalForensics

70 13 63 23

Download og synkronisering i SharePoint og OneDrive: filaktivitet i auditloggen

Download og synkronisering i SharePoint og OneDrive: filaktivitet i auditloggen

Forside › Microsoft 365 og Entra ID: logkilderne · Gennemgået oktober 2026 · Af John Nielsen

Auditloggen i Microsoft 365 kan vise, hvilken konto der har hentet filer fra SharePoint og OneDrive, hvornår, fra hvilken IP-adresse og med hvilken klient. Det afgørende for fortolkningen er at skelne mellem en download i browseren og en synkronisering med OneDrive-klienten. De to registreres som forskellige hændelser, og de betyder noget forskelligt: En download er typisk en bevidst handling på bestemte filer, mens en synkronisering kan omfatte hele biblioteker, uden at brugeren har valgt hver fil.

Loggens opbygning, opbevaring og eksport er gennemgået i Unified Audit Log i Microsoft 365. Her går vi i dybden med filhændelserne.

De relevante hændelser

  • FileDownloaded · Fil hentet via browser, app eller API
  • FileSyncDownloadedFull · Hele filen hentet af synkroniseringsklienten
  • FileSyncDownloadedPartial · Del af en fil hentet af synkroniseringsklienten
  • FileAccessed · Fil læst, herunder af programmer og forhåndsvisning
  • FilePreviewed · Fil vist i forhåndsvisning
  • FileSyncUploadedFull · Fil sendt op fra en synkroniseret mappe
  • FileCopied, FileMoved · Fil kopieret eller flyttet i tjenesten
  • FileDeleted, FileRecycled · Fil slettet eller lagt i papirkurven

Microsoft tilføjer og omdøber hændelser løbende. Brug den aktuelle dokumentation, og angiv i rapporten, hvilken version der er lagt til grund. Alle hændelser i tabellen stod i Microsofts liste over revisionsaktiviteter ved gennemgangen.

Felterne, der bærer konklusionen

Det meste af værdien ligger i AuditData-feltet. For filhændelser er især disse oplysninger relevante:

  • ObjectId, SiteUrl og SourceRelativeUrl: filens fulde adresse og placering på hændelsestidspunktet.
  • ListItemUniqueId: filens unikke id, som er stabilt, selvom filen omdøbes eller flyttes.
  • ClientIP: den IP-adresse, Microsoft så forespørgslen fra.
  • UserAgent: klientens identifikation, som afslører browser, Office-app eller synkroniseringsklient.
  • ApplicationDisplayName og ApplicationId: den app, der udførte handlingen, fx en Office-app, en integration eller et tredjepartsværktøj.
  • Oplysninger om enheden: hvor de findes, fx om enheden er administreret, og hvilket enhedsnavn der er registreret for synkroniseringsklienten. Disse felter er ikke en del af Microsofts dokumenterede fællesskema og er ikke altid udfyldt, så de bruges som støtte, ikke som eneste grundlag.

Fortolk aldrig ud fra hændelsesnavnet alene. Det er kombinationen af hændelse, klient og app, der viser, om der var tale om et menneske i en browser, en synkroniseringsklient eller en baggrundstjeneste.

Synkronisering eller download

Synkroniseringsklienten henter filer, når et bibliotek eller en mappe sættes op til synkronisering, og når filer ændres i skyen. Med filer efter behov (Files On-Demand) hentes indholdet først, når filen åbnes, eller når brugeren vælger, at den altid skal ligge lokalt. Det betyder, at mønstret i loggen afhænger af klientens indstillinger:

  • Mange FileSyncDownloadedFull-hændelser inden for få minutter kan skyldes, at et bibliotek er sat op til synkronisering på en ny enhed, eller at “behold altid på denne enhed” er valgt for en mappe. Begge dele er brugerhandlinger, men af en anden karakter end at udvælge filer.
  • Enkelte FileSyncDownloadedFull-hændelser spredt over tid ligner snarere åbning af filer, der kun lå som pladsholdere.
  • En synkronisering efter en ændring foretaget af en kollega giver hændelser på alle de enheder, der synkroniserer biblioteket.

Download af flere filer eller en mappe i browseren pakkes som zip-fil. Om hver fil registreres som en selvstændig hændelse, og hvordan mappen fremgår, skal kontrolleres i den konkrete tenant, fx ved at gentage en kendt download i en testmappe. Microsofts dokumentation beskriver ikke registreringen af zip-download i detaljer.

Hvad der skete lokalt bagefter, viser auditloggen ikke. Den lokale side af synkroniseringen er beskrevet i OneDrive-klienten på Windows: lokale spor af synkronisering.

Tærskler, aggregering og forsinkelse

Auditloggen er ikke en fuldstændig optagelse af hver læsning. Gentagne læsninger af samme fil fra samme konto kan blive samlet, og visse hændelser kan være begrænset af licens. Microsoft beskriver hændelsen FileAccessedExtended, der logges i stedet for mange FileAccessed, når samme person bruger en fil vedvarende i op til tre timer. Hændelser kan desuden optræde i loggen med forsinkelse, så en søgning kort efter en handling kan være ufuldstændig.

Advarselspolitikker for usædvanligt mange downloads har deres egne tærskler. En advarsel er nyttig som pejlemærke, men den er ikke et bevis i sig selv. Det er de underliggende hændelser, der skal sikres og forklares.

Sådan sikres filaktiviteten

  1. Afgræns konti, websteder og periode, men søg bredt på hændelsestyper. En søgning kun på FileDownloaded overser synkronisering.
  2. Del søgningen op i tidsintervaller, så ingen delsøgning rammer resultatgrænsen, og notér antallet pr. delsøgning.
  3. Eksportér med det fulde AuditData-felt, og bevar den rå fil.
  4. Hash eksportfilerne straks.
  5. Pak AuditData ud med et dokumenteret værktøj eller script; se Eksport via Microsoft Graph og PowerShell.
  6. Sikr de berørte filer og deres versioner, så indholdet af det hentede kan vises.

Typiske fejlslutninger

  • “Mange hændelser betyder masseudtræk.” Det kan være en ny enhed, der synkroniserer, eller en sikkerhedskopi, der læser filer via API.
  • “FileAccessed betyder åbnet af en person.” Forhåndsvisning, indeksering, Copilot og integrationer kan give samme hændelse.
  • “Ingen hændelse betyder ingen handling.” Det kræver, at logningen dækkede perioden og hændelsestypen.
  • “IP-adressen viser, hvor personen var.” Mobilnet, VPN og proxyer giver andre adresser; se IP-adresser som bevis.
  • “Enheden var privat.” En ukendt enhed i loggen kan være en ny firmacomputer. Sammenhold med enhedsregistreringer og MDM, før der konkluderes.

Koblingen til login og session

En filhændelse står sjældent alene. Hændelsen bærer en konto og ofte en IP-adresse og en klient, men spørgsmålet om, hvem der stod bag, kræver, at hændelsen kobles til den session, den tilhører. Sammenhold derfor filhændelserne med loginloggen i Entra ID for samme periode: Hvornår blev der logget ind, fra hvilken enhed og app, og med hvilken form for godkendelse? En række downloads fra en IP-adresse og en browser, som ikke optræder i nogen login-hændelse for kontoen, kan pege på et genbrugt token frem for et almindeligt login. Omvendt styrker det billedet, hvis login, filhændelser og enhedens lokale spor følger samme forløb. Fremgangsmåden er beskrevet i Sessioner, tokens og loginlogs.

Vær også opmærksom på delte konti og servicekonti. Hændelser fra en konto, som flere har adgangskoden til, kan ikke henføres til én person ud fra loggen alene.

Verifikation

Kontrollér konklusionen fra flere sider. Findes filerne på den enhed, der står i loggen? Passer tidspunkterne med lokale artefakter som synkroniseringsklientens databaser, LNK-filer og jump lists? Optræder samme mønster hos kolleger, der synkroniserer samme bibliotek? Er der tvivl om, hvordan en hændelse opstår, kan den afprøves i en testkonto med samme klientversion, og afprøvningen beskrives i rapporten.

Hvad loggen kan og ikke kan bevise

Loggen kan vise, at en konto via en bestemt klient hentede en bestemt fil til en enhed på et bestemt tidspunkt. Den kan ikke vise, om filen blev åbnet lokalt, kopieret videre eller slettet igen, og den viser ikke, hvem der betjente kontoen. Sammen med enhedens spor og loginloggen kan den indgå i et samlet billede. Grundlaget for ikke-teknikere findes på hubben i Bevissikring af OneDrive, SharePoint og Teams.

Dokumentation til rapporten

Angiv søgekriterier, delsøgninger med antal, eksportfiler med hashværdier, udpakningsmetode, UTC som tidszone og en forklaring af hver hændelsestype, der indgår. Gengiv de afgørende poster med fil-id, klient, app og IP-adresse, og skriv eksplicit, hvilke alternative forklaringer der er undersøgt og afvist.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Microsoft 365 og Entra ID: logkilderne

Læs også: Hvem ændrede filen? Versioner og delingslinks i SharePoint · Teams teknisk: hvor chats, filer og optagelser gemmes, og hvordan de eksporteres

→ Microsoft 365-forensik · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · 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

John Nielsen, IT-sagkyndig

Brug for en forensisk undersøgelse?

Skriv kort, hvilke systemer eller enheder det drejer sig om, og om noget haster, så vender jeg tilbage. Kun civile sager.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.