Unified Audit Log i Microsoft 365 som bevis

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

Revisionsloggen i Microsoft 365, ofte kaldet Unified Audit Log (UAL), registrerer brugernes og administratorernes handlinger på tværs af tjenesterne: Exchange Online, SharePoint, OneDrive, Teams, Entra ID og flere. I sager om medarbejdere, der har taget data med, er den ofte den vigtigste kilde, fordi den viser handlinger som download, deling og sletning, også når filerne selv ikke er ændret. Den har dog begrænset levetid, og den skal tolkes med kendskab til, hvordan hændelserne opstår.

Det overordnede forløb for virksomheden er beskrevet på hubben i Medarbejderen har taget data med. Her ser vi på loggen som teknisk kilde: hvad den indeholder, hvordan den hentes fuldstændigt, hvor fortolkningen typisk glider, og hvordan resultatet dokumenteres. Artiklen fungerer samtidig som indgang til de mere specialiserede artikler om de enkelte hændelsestyper.

UAL i forhold til de andre logkilder

Revisionsloggen er ikke den eneste log i Microsoft 365, og den erstatter ikke de andre. Flere kilder overlapper delvist, men har hver deres felter, opbevaring og eksportvej. Det er en klassisk fejl at lede efter et svar i den forkerte kilde og konkludere, at sporet mangler.

• Unified Audit Log · Hvad den besvarer bedst: Hvem gjorde hvad med filer, postkasser, deling og administration · Uddybning: Denne artikel
• Entra ID-loginlogs · Hvad den besvarer bedst: Hvem loggede ind, hvorfra, med hvilken klient og hvilket MFA-resultat · Uddybning: Entra ID sign-in logs
• Message trace · Hvad den besvarer bedst: Hvilke mails der blev leveret til og fra hvem · Uddybning: Message trace, indholdssøgning eller auditlog
• Postkassens revision · Hvad den besvarer bedst: Læsning, sletning og afsendelse i den enkelte postkasse · Uddybning: MailItemsAccessed og mailbox-auditloggen
• Defender XDR · Hvad den besvarer bedst: Sikkerhedsalarmer, mailfiltrering og klik på links · Uddybning: Defender XDR som datakilde

Loginhændelser fra Entra ID optræder også i revisionsloggen, men med færre detaljer end i Entra ID’s egne loginlogs. Når spørgsmålet handler om logins, sessioner og MFA, skal Entra ID-loggene sikres for sig; se Eksport af Entra ID-loginlogs. Den samlede oversigt over kilder, eksportveje og opbevaring står i Microsoft 365 og Entra ID: logkilderne.

Hvad kan loggen vise?

• Filer · FileAccessed, FileDownloaded, FileSyncDownloadedFull, FileDeleted
• Deling · SharingSet, AnonymousLinkCreated, SharingInvitationCreated
• Mail · Oprettelse af indbakkeregler, sletning af elementer (afhængigt af postkassens logning)
• Login · Logins, IP-adresser, klientprogrammer og enheder (via Entra ID)
• Teams · Oprettelse af teams, tilføjelse af medlemmer, ændring af indstillinger
• Administration · Ændringer af rettigheder, roller og politikker

Hændelsesnavnene ændres og udvides løbende af Microsoft. Brug Microsofts aktuelle oversigt ved tolkning, og citer den version af dokumentationen, der er brugt.

Hvert område har sin egen dybdeartikel. Fildownload og synkronisering er gennemgået i Download og synkronisering i SharePoint og OneDrive, versioner og delingslinks i Hvem ændrede filen?, Teams i Teams teknisk og Slettede og redigerede Teams-beskeder, og rolletildelinger i Privilegerede roller. Hændelser fra integrationer og automatisering, fx app-samtykker og flows, kræver særlig opmærksomhed, fordi de kan flytte data uden en brugers direkte handling; se OAuth-apps og samtykke-phishing og Power Automate og Logic Apps som skjult dataflow. Brugen af Copilot efterlader også poster; se Copilot-interaktioner i Microsoft 365.

Opbygningen af en hændelse

Hver post har en række faste felter fra Microsofts fællesskema: tidspunkt (CreationTime), et unikt id (Id), hændelsestypen (Operation), posttypen (RecordType), kontoen (UserId) og dens type (UserType), tjenesten (Workload), klientens IP-adresse (ClientIP), objektet, der blev handlet på (ObjectId), og resultatet (ResultStatus). Dertil kommer tjenestespecifikke felter, fx filsti og websted for SharePoint eller oplysninger om postkasse og mappe for Exchange.

I en eksport fra Purview får hver post fire kolonner: CreationDate, UserIds, Operations og AuditData. Alle detaljerne ligger i AuditData, som er et JSON-objekt: filsti og websted, klient-IP, brugeragent, om handlingen skete via browser eller synkroniseringsklient, sessions- og enhedsoplysninger og meget mere.

Udpakning af AuditData

Feltet skal pakkes ud for at blive læsbart. Gør det med et dokumenteret værktøj eller script, og bevar altid den rå eksport ved siden af den bearbejdede version, så pakningen kan efterprøves.

Udpakningen har sine egne faldgruber. Microsoft beskriver selv, at JSON-transformationen i Excels Power Query bygger kolonnerne ud fra egenskaberne i de første 1.000 rækker. Egenskaber, der kun findes i senere poster, kommer derfor ikke med som kolonner, medmindre der filtreres først. Indlejrede lister, fx berørte elementer i en mailhændelse, skal foldes ud særskilt. Et script, der læser hele JSON-objektet for hver post, er mere robust, men skal versioneres og beskrives, så en anden kan køre det igen og få samme resultat.

Brug feltet Id til at fjerne dubletter, når flere delsøgninger overlapper. To poster med samme tidspunkt og hændelse er ikke nødvendigvis dubletter; to poster med samme Id er.

Hvor længe gemmes den?

Opbevaringen afhænger af licensen. På tidspunktet for gennemgangen (oktober 2026) gemmes poster med standardrevision i 180 dage. Med premiumrevision gemmes poster fra Exchange, SharePoint, OneDrive og Entra ID som standard i et år, og opbevaringspolitikker og tilkøb kan forlænge perioden yderligere. Poster, der er dannet før en licensændring, får ikke længere levetid med tilbagevirkende kraft. Tjek altid den aktuelle grænse for den konkrete tenant. Det betyder, at loggen ofte skal eksporteres hurtigt, når en sag opstår, og før en fratrådt medarbejders konto slettes. Se også Hvor længe gemmes data?.

Forskellen mellem licensniveauerne, og hvad den betyder for en sag, der starter sent, er uddybet i Audit Standard eller Premium. Hvad der sker, når opbevaringspolitikker også rammer selve indholdet, står i Purview-opbevaringspolitikker og etiketter.

Er loggen slået til?

I de fleste nyere tenants er revisionslogning slået til som standard, men det bør kontrolleres og dokumenteres, fordi en administrator kan have slået den fra. Er logningen slået fra, findes der ingen data for perioden, og det kan ikke rettes bagudrettet. For Exchange findes der desuden logning pr. postkasse, hvor bestemte handlinger kun registreres, hvis de er slået til.

Indstillingen kan aflæses i Exchange Online PowerShell med Get-AdminAuditLogConfig, hvor egenskaben UnifiedAuditLogIngestionEnabled skal være sand. Microsoft gør opmærksom på, at samme cmdlet også findes i Security & Compliance PowerShell, men at egenskaben dér altid vises som falsk. Notér derfor, hvor kommandoen er kørt. Den, der søger, skal have rollen Audit Logs eller View-Only Audit Logs; en læserolle er at foretrække, når formålet alene er sikring.

Sådan sikres loggen

1. Søg i Microsoft Purview under Revision (Audit) med brugere, perioder og hændelsestyper.
2. Eller brug PowerShell via Exchange Online-modulets cmdlet til søgning i revisionsloggen. Det giver mere kontrol over store mængder og kan scriptes, så forløbet kan gentages.
3. Eksportér resultatet til CSV med det fulde AuditData-felt.
4. Beregn hashværdier for eksportfilerne straks; se Hashværdier forklaret.
5. Dokumentér søgekriterier, tidspunkt og den bruger, der har udført søgningen.

Purview-portalen

Søgninger i portalen kører som job, der fortsætter, selvom browservinduet lukkes, og færdige job gemmes i 30 dage. Datointervallet i én søgning kan højst være 180 dage, og tiderne angives og vises i UTC. Ved eksport til CSV gælder på tidspunktet for gennemgangen (oktober 2026) en grænse på 50.000 rækker med standardrevision og 1.000.000 rækker med premiumrevision. Rammer en søgning grænsen, mangler der poster i filen, uden at det nødvendigvis er tydeligt. Feltet til nøgleordssøgning søger kun i fællesskemaets indekserede felter, ikke i hele AuditData, så en fritekstsøgning på et filnavn kan overse poster.

PowerShell

Search-UnifiedAuditLog returnerer som udgangspunkt kun 100 poster. Med -SessionCommand ReturnLargeSet og et fast -SessionId kan søgningen pagineres op til 50.000 poster, men resultatet er da usorteret. ReturnNextPreviewPage sorterer efter dato, men stopper ved 5.000 poster, og blandes de to værdier i samme session, falder grænsen til 10.000. Tidspunkter i -StartDate og -EndDate tolkes som UTC, når der ikke angives tidszone. Parametre som -UserIds, -Operations, -RecordType, -ObjectIds og -IPAddresses afgrænser søgningen. Den eksakte kommandolinje er en del af dokumentationen; se Eksport via Microsoft Graph og PowerShell.

API’er

Til løbende opsamling anbefaler Microsoft Office 365 Management Activity API frem for scriptede søgninger. API’et kræver et abonnement, der er startet, og indhold kan kun hentes i syv dage efter, at det er gjort tilgængeligt. Det egner sig derfor til at bygge et logarkiv før en hændelse, ikke til at hente historik bagefter. Microsoft Graph har desuden et API til auditlogsøgninger, som kører søgninger asynkront; status og versionsniveau ændrer sig, så kontrollér dokumentationen ved brug.

• Purview-søgning · Styrke: Enkel, rollebaseret, job gemmes · Svaghed: Eksportgrænse pr. søgning, nøgleord kun i fællesfelter
• Search-UnifiedAuditLog · Styrke: Scriptbar og gentagelig · Svaghed: Lofter pr. session, usorteret ved store mængder
• Management Activity API · Styrke: Velegnet til løbende arkiv · Svaghed: Kun nyere indhold, kræver forudgående opsætning

Opdeling og fuldstændighed

Søgninger har grænser for antallet af resultater pr. søgning. Store perioder og mange brugere skal deles op, fx pr. dag, så intet falder ud, og antallet pr. delsøgning skal noteres. Hvis en delsøgning rammer et loft, deles den igen. En bred søgning på alle hændelser for en bruger er ofte bedre end en snæver søgning på udvalgte hændelsestyper, fordi relevante handlinger kan være registreret under uventede navne.

Microsoft garanterer ikke, hvornår en post kan findes. For kernetjenesterne er posterne typisk tilgængelige 60 til 90 minutter efter handlingen, for andre tjenester kan det tage længere. En sikring, der foretages kort efter en hændelse, bør derfor gentages for den seneste periode, og begge kørsler dokumenteres.

Tolkning: faldgruber

• Automatiske handlinger: Synkronisering, antivirus, indeksering, forhåndsvisning og tredjepartsapps kan give hændelser, som ligner brugerhandlinger.
• FileAccessed er ikke altid “åbnet”: Det kan skyldes forhåndsvisning i Outlook, en miniature i et bibliotek eller en app, der læser filen.
• Synkronisering: Når OneDrive-klienten synkroniserer et helt bibliotek, registreres det anderledes end enkelte downloads, og mange hændelser på kort tid kan være et teknisk forløb frem for en bevidst masseoverførsel.
• Forsinkelse: Hændelser kan optræde i loggen med forsinkelse. Fraværet af en hændelse lige efter den skete, siger ikke meget.
• Tidszone: Loggen er i UTC. Omregn konsekvent; se Tidslinjeanalyse.
• IP-adresser: Mobilnet, VPN og Microsofts egne tjenester giver IP-adresser, der ikke nødvendigvis peger på brugerens fysiske placering.
• Kontotype: UserType og UserId kan vise en tjenestekonto, en app eller et systemforløb. En handling udført af en app med delegerede rettigheder er ikke det samme som en handling i brugerens browser.
• Administrative enheder: En administrator, der er begrænset til bestemte administrative enheder, ser kun en del af posterne. Notér søgerens rettigheder, så et tomt resultat ikke fejltolkes.

Mønstre, der ofte er relevante

• Mange downloads eller synkroniseringer kort før fratrædelse
• Deling af filer med eksterne eller private adresser
• Oprettelse af indbakkeregler, der videresender til en ekstern adresse
• Logins fra nye enheder, klienter eller IP-adresser
• Sletning af store mængder filer eller mails

Ét mønster er ikke et bevis i sig selv. Det skal sammenholdes med andre kilder, fx computerens artefakter; se Windows-artefakter. Loginsiden af loggen hænger tæt sammen med Entra ID’s egne logs, som er gennemgået i Sessioner, tokens og loginlogs.

Ved fratrædelsessager er tidslinjen for de sidste dage central; se Tidslinje for de sidste dage før fratræden og Mail til privat adresse. Ved en overtaget konto handler det om indgangsvej, regler og læste mails; se BEC-undersøgelse i Microsoft 365 trin for trin, AiTM-phishing og Indbakkeregler og videresendelse.

Et neutralt eksempel på læsning

Antag, at en eksport for en konto viser en lang række FileSyncDownloadedFull fra ét bibliotek inden for få minutter, efterfulgt af enkelte FileDownloaded fra et andet websted. Den første række peger på, at synkroniseringsklienten har hentet biblioteket, fx fordi det er blevet tilknyttet en ny computer. Brugeragent og enhedsfelter i AuditData kan vise, hvilken klient og enhed der var tale om. De enkelte downloads fra browseren er mere udtryk for et valg af bestemte filer. Ingen af delene viser dog, hvor filerne endte bagefter. Det kræver spor fra den enhed, der modtog dem, eller fra andre tjenester.

Mailhændelser kræver ekstra omhu

Handlinger i postkasser er en særlig kategori. Oprettelse og ændring af indbakkeregler registreres som administrative hændelser, og de er ofte centrale, fordi en regel kan videresende mails automatisk i lang tid uden yderligere handlinger. Reglens indhold, fx betingelser og modtageradresse, ligger i AuditData og skal læses derfra.

Hvilke handlinger i selve postkassen der registreres, fx læsning af elementer, flytning og sletning, afhænger af postkassens logningsindstillinger og licens. Postkasserevision er som standard slået til, og Microsoft vedligeholder en standardliste over handlinger pr. logintype (ejer, stedfortræder, administrator). Flytning af en mail mellem mapper er fx ikke med på standardlisten, og en administrator kan have ændret listen for den enkelte postkasse. Fraværet af en hændelse kan derfor skyldes, at handlingen ikke logges, ikke at den ikke fandt sted. Notér de gældende indstillinger på sikringstidspunktet, og vær forsigtig med at konkludere ud fra manglende poster.

Adgang til andres postkasser via FullAccess, SendAs og delegering har sine egne spor; se Adgang til andres postkasser. Hvad der reelt er tilbage af slettede elementer, står i Exchange Online: Recoverable Items.

Kan loggen ændres?

Almindelige brugere kan ikke slette eller ændre poster i revisionsloggen. En global administrator kan derimod ændre logningsindstillinger og opbevaringspolitikker, og sådanne ændringer registreres selv som hændelser. Hvis en administrator er part i sagen eller har haft adgang til det relevante, bør administrative hændelser i perioden gennemgås, og det bør overvejes, om eksporten skal foretages af en uafhængig part. Fremgangsmåden, når den undersøgte selv har administratorrettigheder, er beskrevet i Undersøgelse af en administrator, der kan slette loggen.

Kombination med eDiscovery

Revisionsloggen viser handlinger. eDiscovery viser indholdet. Sammen kan de vise både, at en fil er downloadet, og hvad filen indeholdt, eller både, at en mail er slettet, og hvad den sagde, hvis et hold har bevaret den. Fremgangsmåden er beskrevet i Microsoft Purview eDiscovery. Hvis organisationen har tredjepartsbackup, kan den supplere med indhold, men typisk ikke med auditposter; se Tredjepartsbackup af Microsoft 365 som kilde.

Hvad loggen kan og ikke kan bevise

Loggen kan vise, at en konto udførte en handling på et bestemt tidspunkt fra en bestemt klient. Den viser ikke, hvem der sad ved tastaturet, og den viser ikke, hvad der skete med en fil efter download. Den viser heller ikke indholdet af filen; det kræver eDiscovery eller en kopi af filen. Konklusioner om en persons handlinger bygger derfor på et samlet billede af flere kilder.

Tjekliste ved sikring af revisionsloggen

• ☐ UnifiedAuditLogIngestionEnabled aflæst i Exchange Online PowerShell og noteret
• ☐ Licens og opbevaring for hver relevant konto fastlagt for hele perioden
• ☐ Postkassernes revisionsindstillinger noteret for de relevante postkasser
• ☐ Søgerens rolle og eventuelle begrænsning til administrative enheder noteret
• ☐ Perioden delt op, så ingen delsøgning rammer et loft
• ☐ Antal poster pr. delsøgning registreret
• ☐ Rå eksport gemt urørt, og hashværdier beregnet straks
• ☐ Dubletter fjernet på Id i en arbejdskopi, ikke i den rå eksport
• ☐ Seneste periode søgt igen, når forsinkelsen er overstået
• ☐ Udpakningsmetode for AuditData beskrevet og versioneret

En bredere liste over de logs, der skal sikres samtidig, findes i Tjekliste: logs at sikre i Microsoft 365 ved en hændelse.

Dokumentation til rapporten

Angiv søgekriterier og perioder, antal resultater pr. søgning, eksportfiler med hashværdier, tidszone for alle tidspunkter, metode til udpakning af AuditData samt en forklaring af de hændelsestyper, der indgår i konklusionerne. Gengiv de afgørende poster i et bilag med de relevante felter fra AuditData, så læseren kan se det grundlag, konklusionen bygger på, og så en anden sagkyndig kan finde de samme poster i den rå eksport. Angiv også, hvilke begrænsninger der gjaldt: licensniveau, postkassernes logningsindstillinger og eventuelle perioder, hvor logningen ikke var aktiv.

Kilder og versioner

• Microsoft Learn: opbevaringspolitikker for revisionsloggen
• Microsoft Learn: postkasserevision og handlinger, der logges som standard
• Microsoft Learn: revisionsløsninger i Microsoft Purview
• Microsoft Learn: søgning i revisionsloggen (job, roller, eksportgrænser, forsinkelse)
• Microsoft Learn: eksport og udpakning af AuditData
• Microsoft Learn: Search-UnifiedAuditLog

Senest gennemgået: oktober 2026.

Næste skridt

• MFA-ændringer og betinget adgang i Entra ID-loggene

Del af: Microsoft 365 og Entra ID: logkilderne

Læs også: Microsoft Purview eDiscovery: hold, søgning og eksport · Exchange Online: Recoverable Items, hold og hvad der reelt er tilbage

→ Microsoft 365-forensik · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT