Azure: Activity Log, Monitor og Log Analytics som bevis

Forside › Cloud- og SaaS-forensik · Gennemgået oktober 2026 · Af John Nielsen

Azure registrerer automatisk handlinger på selve ressourcerne i et abonnement, fx oprettelse, ændring og sletning af virtuelle maskiner, lagerkonti og netværksregler. Det er Activity Log. Alt det, der sker inde i ressourcerne, som læsning af blobs, adgang til nøgler eller logins på en virtuel maskine, logges derimod kun, hvis nogen på forhånd har slået det til. Den forskel afgør, hvad en undersøgelse kan svare på, og den bør være det første, du afklarer, når en sag rammer et Azure-miljø.

Haster det? Activity Log opbevares kun i 90 dage af platformen, og et nyt Log Analytics-arbejdsområde har som standard kort interaktiv opbevaring. Se akut forensisk sikring, og bemærk, at hastesager koster ekstra.

Tre lag af logning

Azure Monitor samler flere typer data, som ofte blandes sammen:

• Activity Log · Handlinger på kontrolplanet: hvem oprettede, ændrede eller slettede en ressource, eller startede en handling som at stoppe en maskine
• Ressourcelogs · Hændelser i selve tjenesten, fx læsning og skrivning i lager, adgang til Key Vault eller forespørgsler mod en database
• Gæstelogs · Logs inde i en virtuel maskine, fx Windows-hændelseslogs eller syslog, indsamlet af en agent

Activity Log er slået til fra start og kan ikke slås fra for abonnementet. Den opbevares af platformen i 90 dage og kan i den periode ses og eksporteres fra portalen. Skal den gemmes længere, skal den sendes videre med en diagnostikindstilling. Ressourcelogs og gæstelogs skal derimod sendes et sted hen via diagnostikindstillinger eller dataindsamlingsregler: til et Log Analytics-arbejdsområde, en lagerkonto eller en Event Hub. Findes der ingen sådan indstilling for den relevante ressource i den relevante periode, findes loggen typisk ikke.

Loginhændelser for brugere og tjenesteprincipaler ligger ikke i Activity Log, men i Entra ID. De behandles i Entra ID-loginlogs.

Felterne i Activity Log

En post i Activity Log har blandt andet disse felter:

• caller: den konto, tjenesteprincipal eller administrerede identitet, der udførte handlingen.
• operationName: handlingen, fx en skrivning eller sletning på en bestemt ressourcetype.
• status og subStatus: fx Started, Accepted, Succeeded eller Failed.
• eventTimestamp og submissionTimestamp: hvornår hændelsen skete, og hvornår den blev registreret i loggen.
• correlationId: et id, der binder flere poster for samme handling sammen.
• resourceId: den fulde sti til ressourcen med abonnement og ressourcegruppe.
• claims og httpRequest: oplysninger fra adgangstokenet og ofte klientens IP-adresse.

Én handling giver normalt flere poster. En sletning kan optræde som Started og derefter Succeeded, og længerevarende handlinger kan have flere mellemtrin. Tæl derfor ikke poster som handlinger. Gruppér på correlationId, og brug den afsluttende status.

Log Analytics og KQL

Sendes Activity Log og ressourcelogs til et Log Analytics-arbejdsområde, ligger de i tabeller, der kan forespørges med KQL. Activity Log havner typisk i tabellen AzureActivity, mens ressourcelogs ligger i tjenestespecifikke tabeller, fx StorageBlobLogs for Blob Storage, eller i den fælles tabel AzureDiagnostics, afhængigt af ressourcetypen og af, hvordan diagnostikindstillingen er sat op. Microsofts oversigt over tabeller pr. ressourcetype viser, hvor en given log lander.

Opbevaringstiden styres pr. arbejdsområde og evt. pr. tabel, og den kan være forskellig for interaktiv opbevaring og langtidsopbevaring. På tidspunktet for gennemgangen (oktober 2026) er standarden for et nyt arbejdsområde 30 dages interaktiv opbevaring, mens visse tabeller og arbejdsområder med Microsoft Sentinel har 90 dage; interaktiv opbevaring kan forlænges til to år og samlet opbevaring til tolv år. Notér den faktiske indstilling på sikringstidspunktet, for den forklarer, hvorfor data før en bestemt dato mangler.

KQL er et stærkt analyseværktøj, men en forespørgsel er en fortolkning. Gem derfor både den rå eksport og selve forespørgslen med tidsinterval, så resultatet kan genskabes.

Sikring

1. Kortlæg abonnementer og arbejdsområder. Find alle abonnementer i tenanten, og notér for hvert abonnement, hvor diagnostikindstillingerne sender data hen.
2. Eksportér Activity Log for hele den relevante periode og gerne lidt bredere, via portalen, kommandolinjen eller API’et. Gem i JSON, så alle felter bevares. CSV fra portalen kan udelade indlejrede felter.
3. Eksportér fra Log Analytics de relevante tabeller i rå form. Del store perioder op, hvis der er grænser for antal rækker pr. forespørgsel, og kontrollér, at antallet af rækker stemmer med en optælling i samme forespørgsel.
4. Kopiér arkiverede logs fra lagerkonti. De ligger ofte som JSON-filer i en mappestruktur efter dato og time.
5. Gem konfigurationen: diagnostikindstillinger, dataindsamlingsregler, opbevaringsindstillinger og rolletildelinger. Det er den, der viser, hvad der kunne være logget.
6. Beregn hashværdier straks efter eksport, se Hashalgoritmer i forensic.

Overvej at forlænge opbevaringen eller sende Activity Log til en lagerkonto med uforanderlighedspolitik, hvis sagen kan trække ud. Det er en ændring af miljøet og skal dokumenteres med tidspunkt og person. Den generelle fremgangsmåde for cloud-eksport er beskrevet i Cloud-forensic via API og administratoreksport.

Egne handlinger under sikringen, fx et snapshot af en disk, bliver også logget i Activity Log. Det er en fordel: Loggen dokumenterer selv sikringen. Se Snapshots af cloud-diske som forensisk kopi.

Integritet og uafhængighed

Kunden kan ikke redigere poster i Activity Log. Men en konto med tilstrækkelige rettigheder kan slette eller ændre diagnostikindstillinger, sænke opbevaringen i et arbejdsområde eller slette en lagerkonto med arkiverede logs. Selve ændringen af en diagnostikindstilling registreres som en handling i Activity Log, og det er ofte netop den post, der viser, hvornår logningen holdt op.

Er det en administrator selv, der undersøges, vejer platformens egen log tungere end data i et arbejdsområde, som samme person havde skriveadgang til. Notér, hvem der havde rollerne Owner, Contributor og rettigheder til Log Analytics i perioden, og hent rolletildelingernes historik fra Activity Log, så det kan ses, om nogen fik eller mistede rettigheder undervejs.

Typiske fejlkilder

• Kontrolplan er ikke dataplan. Activity Log viser, at en lagerkonto fik ændret sin adgangsregel, ikke at nogen hentede filer derfra.
• Platformen handler selv. Automatisk skalering, sikkerhedsopdateringer og politikker udfører handlinger, der står med en systemidentitet som caller. De ligner ikke brugerhandlinger, men kan forveksles, hvis identiteten ikke slås op.
• Tjenesteprincipaler og administrerede identiteter. En caller kan være en app-registrering, som flere personer eller pipelines har brugt. Koblingen til en person kræver Entra ID-logs og evt. logs fra CI/CD.
• Tidszoner. Data gemmes i UTC, men portalen kan vise lokal tid. Angiv altid, hvilken tid en tabel i rapporten bruger. Se Tidsstempler og tidszoner.
• Forsinkelse. submissionTimestamp kan ligge efter eventTimestamp. Brug eventTimestamp til tidslinjen, og notér, hvis forskellen er stor.
• IP-adressen i httpRequest kan være en Azure-intern adresse eller en adresse fra en anden tjeneste, der kalder på brugerens vegne.

Hvad loggen kan og ikke kan bevise

Activity Log kan vise, at en bestemt identitet udførte en bestemt handling på en bestemt ressource på et bestemt tidspunkt, og om handlingen lykkedes. Den kan understøtte en tidslinje over oprettelse og sletning af maskiner, ændrede netværksregler eller nye rolletildelinger. Den kan ikke vise, hvad der skete med data inde i ressourcerne, medmindre ressourcelogs var slået til, og den kan ikke alene vise, hvilken person der stod bag en tjenesteprincipal.

Fravær af en post i et Log Analytics-arbejdsområde er kun meningsfuldt, hvis konfigurationen viser, at hændelsen ville være blevet logget. Sammenlign med AWS, hvor CloudTrail har en tilsvarende opdeling mellem administrationshændelser og datahændelser: AWS CloudTrail i undersøgelser.

Dokumentation i rapporten

Rapporten bør for hver kilde angive tenant-id, abonnement, arbejdsområde, tabel, forespørgsel, tidsinterval i UTC, antal poster, eksportmetode, værktøj og version samt hashværdier. Vedlæg diagnostikindstillingerne som de så ud ved sikringen, og beskriv huller i dækningen: hvilke ressourcer der ikke sendte logs, og fra hvilken dato data mangler på grund af opbevaringstid. Den grundlæggende pointe om, at sådanne data forsvinder, er beskrevet i Data, der forsvinder dag for dag.

Kilder og versioner

• Microsoft Learn: Azure Monitor activity log
• Microsoft Learn: Manage data retention in a Log Analytics workspace
• Microsoft Learn: Resource logs, tabeller pr. ressourcetype

Senest gennemgået: oktober 2026.

Næste skridt

• MitID og NemLog-in: hvilke logdata findes, og hvem har dem

Del af: Cloud- og SaaS-forensik

Læs også: AWS CloudTrail i undersøgelser: sikring og fortolkning · Google Cloud Audit Logs i undersøgelser

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT