Tredjepartsbackup af Microsoft 365 som kilde

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

En backup af Microsoft 365 fra en tredjepartsleverandør kan indeholde mails, filer og chats, som for længst er slettet i selve tenanten. Den kan derfor være den eneste kilde, når opbevaring og papirkurve er udløbet. Men en backup er et sæt øjebliksbilleder, ikke en kontinuerlig optagelse, og den måde, data hentes ud på, afgør, hvor meget af den oprindelige metadata der overlever. Den vigtigste regel er, at data ikke gendannes tilbage i den aktive postkasse eller det aktive bibliotek, men eksporteres til et separat sted, så hverken kilden eller beviset ændres.

Hvorfor Microsoft 365 ikke i sig selv er en backup, er forklaret for ledelsen på bevissikring-digitalt.dk i Microsoft 365 og Google er ikke backup. Her ser vi på backuppen som teknisk kilde. Den generelle metode for forensisk gendannelse står i Gendannelse fra backup til forensisk brug.

Hvordan en backup af Microsoft 365 virker

De fleste løsninger henter data via Microsofts API’er, typisk Microsoft Graph og Exchange-grænseflader, med en app-registrering, der har læseadgang til postkasser, OneDrive, SharePoint og Teams. Data hentes med faste mellemrum, ofte en eller flere gange i døgnet, og gemmes hos backupleverandøren eller i organisationens eget lager. Microsoft har også en egen backuptjeneste til Microsoft 365, som arbejder anderledes: Den tager gendannelsespunkter af Exchange Online, OneDrive og SharePoint inden for Microsofts egen platform og gendanner til tenanten, enten på det oprindelige sted eller et nyt sted, men den er ikke et værktøj til eksport af data ud af tenanten.

Det har tre konsekvenser for en undersøgelse:

Øjebliksbilleder: En mail, der blev modtaget og slettet mellem to kørsler, findes ikke i backuppen. En fil, der blev ændret flere gange mellem to kørsler, findes kun i den version, der var aktuel ved kørslen.
Udvalg: Ikke alt er nødvendigvis medtaget. Teams-chats, versionshistorik, delingsoplysninger og bestemte mapper kan være fravalgt eller ikke understøttet.
Egen opbevaring: Backuppen har sin egen opbevaringsperiode og sine egne sletteregler, som kan være kortere end forventet.

Hvad der går tabt ved gendannelse

Gendannelse er at skrive data tilbage til Microsoft 365. Det er en skrivning, og den efterlader spor:

Mail · Ny modtagelses- eller oprettelsestid kan blive sat; elementet får nyt id
Filer i SharePoint og OneDrive · “Ændret af” kan blive servicekontoen; oprettet og ændret kan blive gendannelsestidspunktet
Versionshistorik · Ofte kun den gendannede version, ikke hele historikken
Delinger og rettigheder · Gendannes ikke nødvendigvis
Teams · Gendannes ofte som filer eller HTML, ikke som beskeder i chatten
Auditloggen · Gendannelsen giver nye hændelser, som kan forveksles med brugerhandlinger

Hvor meget der bevares, afhænger af løsningen og af, hvilke felter Microsofts API’er tillader at skrive tilbage, og det kan ændre sig mellem versioner. Tabellen viser derfor mulige effekter, ikke en fast regel. Selve mailindholdet, inklusive den fulde header, bevares ofte, hvis mailen er gemt i MIME-format, men det skal kontrolleres for den konkrete løsning.

Gendannelse i den aktive postkasse blander desuden gendannede elementer med brugerens egne og kan udløse regler, synkronisering og notifikationer. Det kan ændre den tilstand, sagen handler om.

Den forsvarlige fremgangsmåde

Dokumentér løsningen: produkt, version, hvem der driver den, hvilke tjenester og brugere der er omfattet, kørselsfrekvens og opbevaring.
Sikr backupløsningens egne logs for kørsler, fejl, ændringer i opsætningen og sletning af data. De viser, hvilke øjebliksbilleder der findes, og om nogen er fjernet.
Stop sletning i backuppen for de relevante brugere, fx ved at sætte opbevaringen op eller låse de relevante punkter, hvis løsningen kan.
Vælg eksport frem for gendannelse: til fil, fx PST for mail og originalfiler for dokumenter, eller til et isoleret miljø, fx en separat tenant, der kun bruges til sagen. Se Gendannelse fra backup til forensisk brug.
Notér øjebliksbilledets id og tidspunkt for hvert udtræk, så det kan vises, hvilken tilstand der er gendannet.
Hash eksportfilerne straks, og gem eventuelle manifester fra løsningen.
Sammenlign med tenanten, hvor data stadig findes, for at kontrollere, at eksporten er tro mod kilden.

Fejlkilder i fortolkningen

Tidspunkter i eksporten: Filsystemets tidsstempler på de eksporterede filer er eksporttidspunktet. Brug elementets egne metadata og backupløsningens oplysninger om øjebliksbilledet.
Fravær: At en mail mangler i backuppen, betyder ikke, at den aldrig fandtes. Den kan være modtaget og slettet mellem to kørsler, eller mappen kan være udeladt.
Fejlede kørsler: En kørsel, der fejlede for en bruger, efterlader et hul. Backupløsningens log viser det; se Backup-logs og sletning som bevis.
Konverteringer: Teams-beskeder og visse elementtyper gemmes i et andet format end originalen. Notér formatet og konsekvensen.
Dubletter: Elementer, der er flyttet mellem mapper, kan forekomme flere gange på tværs af øjebliksbilleder.

Integriteten af selve backuppen

Før backuppen bruges som kilde, skal det kunne sandsynliggøres, at dens indhold ikke er ændret siden kørslen. Undersøg derfor, hvordan løsningen beskytter data:

Uforanderligt lager. Mange løsninger kan gemme data i et lager, hvor de ikke kan ændres eller slettes i en periode. Er det slået til, styrker det integriteten væsentligt.
Egne kontrolsummer. Nogle løsninger beregner kontrolsummer pr. element eller pr. blok og kan kontrollere dem igen ved udtræk. Notér, om det sker, og om resultatet kan eksporteres.
Adgangslog. Hvem har haft adgang til løsningen, og er der foretaget gendannelser, eksporter eller sletninger i perioden?
Kryptering og nøgler. Hvem har nøglerne, og kræver eksporten medvirken fra leverandøren?

Kan integriteten ikke dokumenteres, er backuppen stadig brugbar, men usikkerheden skal beskrives, og de vigtigste elementer bør sammenholdes med andre kilder, fx kopier hos modtagere eller i andre systemer.

Backup som bevis på sletning

En backup kan også være kilde til at vise, at noget er slettet, og hvornår: Fandtes elementet i øjebliksbilledet den ene dag og ikke den næste, er det fjernet i mellemtiden. Det giver et tidsrum, ikke et præcist tidspunkt. Jo hyppigere kørslerne er, desto snævrere bliver tidsrummet. Notér derfor de præcise tidspunkter for de to øjebliksbilleder, der afgrænser sletningen, og tag forbehold for, at kørslen kan have strakt sig over længere tid for en stor postkasse eller et stort websted. Kombineret med auditloggen, hvis den stadig dækker perioden, kan tidspunktet indsnævres.

Hvem har adgang?

Backupløsningen har ofte bred adgang til alle brugeres data, og dens administratorer kan gendanne og eksportere uden at være administratorer i Microsoft 365. I en sag, hvor IT-leverandøren eller en intern administrator er involveret, bør adgang og handlinger i backupløsningen gennemgås. Når backuppen ligger hos modparten, kan den være genstand for en anmodning om edition; se Edition af backup hos modparten.

Hvad backuppen kan og ikke kan bevise

En dokumenteret eksport fra backup kan vise, at et element fandtes med et bestemt indhold på tidspunktet for et bestemt øjebliksbillede. Den kan ikke vise, hvad der skete mellem to øjebliksbilleder, og den kan ikke alene vise, hvem der ændrede eller slettede noget.

Dokumentation til rapporten

Angiv løsning, version, dækning, øjebliksbilleder med id og tidspunkt, eksportmetode, eventuelt isoleret miljø, formatkonverteringer, hashværdier og backupløsningens logs for perioden. Beskriv eksplicit, hvorfor gendannelse i den aktive tenant er fravalgt, eller hvis den har været nødvendig, hvilke ændringer den har medført.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Microsoft 365 og Entra ID: logkilderne

Læs også: Copilot-interaktioner i Microsoft 365 som datakilde · Power Automate og Logic Apps som skjult dataflow

→ 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