Server‑tid og klient‑tid i cloud og apps

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

Når en besked, en mail eller en loghændelse har et tidspunkt, er det første spørgsmål ikke hvornår, men hvis ur. Nogle tidsstempler er sat af brugerens enhed, andre af tjenestens server, og andre igen af den logplatform, der modtog hændelsen. De tre kan afvige med sekunder, timer eller dage, og de kan betegne forskellige hændelser: hvornår noget blev skrevet, sendt, modtaget, gemt eller indlæst. En korrekt tidslinje kræver, at man for hvert felt ved, hvilket ur der satte det, og hvilken hændelse det beskriver.

Denne artikel handler om, hvis ur tiden kommer fra. Hvordan tiderne bagefter omregnes til én tidszone og vises i rapporten, står i UTC og sommertid i forensiske rapporter.

Tre slags tid

Klient-tid: sat af enheden efter dens eget ur. Den kan være forkert, hvis uret går forkert, og den kan påvirkes af brugeren. Til gengæld afspejler den, hvornår handlingen skete på enheden, også når enheden var offline.
Server-tid: sat af tjenestens server, når hændelsen nåede den. Brugeren har ingen kontrol over den, og serverens ur er normalt synkroniseret. Den viser, hvornår serveren registrerede noget, ikke nødvendigvis hvornår brugeren gjorde det.
Indlæsningstid: sat af en log- eller SIEM-platform, da hændelsen blev modtaget eller indekseret. Den kan ligge minutter eller timer efter hændelsen og bør ikke forveksles med hændelsens egen tid.

Afvigelser i selve enhedens ur er behandlet i Når enhedens ur går forkert.

Mail

Mail er det klassiske eksempel. Date-headeren sættes af afsenderens mailprogram ud fra klientens ur. Hver Received-header sættes af den server, der modtog mailen, ud fra serverens ur. En mail kan derfor have en Date-header, der ligger før eller efter den første Received-header. Små forskelle er normale. Store forskelle kan skyldes, at mailen lå i udbakken, fordi computeren var offline, at klientens ur gik forkert, eller at headeren er ændret.

I Microsoft 365 og Google Workspace registrerer tjenesten desuden sin egen tid for levering og for handlinger på mailen i auditloggen. Den er uafhængig af både afsenderens og modtagerens enheder. Hvad den slags tidsstempler kan og ikke kan vise om modtagelse, står i Beviser en mail, at den er modtaget?.

Beskeder og chat

Beskedtjenester har typisk flere tidsstempler for samme besked:

tidspunktet, hvor beskeden blev oprettet på afsenderens enhed,
tidspunktet, hvor serveren modtog den,
tidspunktet for levering til og læsning på modtagerens enhed.

Hvilket af dem appen viser, og hvilket der gemmes i den lokale database, varierer mellem apps og versioner. En besked skrevet uden forbindelse kan bære klient-tid fra skrivetidspunktet, men først nå serveren timer senere. En eksport af en chat viser ofte kun ét tidspunkt pr. besked, formateret i enhedens tidszone, uden at sige hvilket. Hvilke felter den konkrete app gemmer, bør derfor aflæses i databasen eller eksporten og ikke antages.

I Teams gemmer tjenesten beskeder med serverens oprettelsestid og eventuelle redigeringstider. Se Teams teknisk.

Dokumenter og filer i cloud

Versionshistorik og auditlogs i cloudtjenester bruger server-tid. Filens egne metadata, fx oprettet og senest gemt i et Office-dokument, er klient-tid fra den computer, hvor filen blev gemt. Synkroniseringsklienter kan overføre den lokale ændringstid til tjenesten, så et felt kaldet “ændret” i en cloudvisning kan være klient-tid, mens versionens tidspunkt er server-tid. Brugerfladen skelner sjældent.

Fotos og andre filer fra telefonen

Billeder er et godt eksempel på, at én fil kan bære flere ure. Optagetiden i EXIF skrives af kameraappen efter telefonens ur og som udgangspunkt i lokal tid uden tidszone. Nyere enheder kan tilføje felter med forskydning fra UTC, men de findes ikke altid. Er positionsdata slået til, indeholder billedet ofte også et GPS-tidsstempel, som EXIF-standarden definerer i UTC. Om værdien kommer fra satellitsignalet, fra telefonens positionstjeneste eller fra telefonens eget ur, afhænger af enhed og app, og den kan høre til en position, der blev bestemt før optagelsen.

Når billedet derefter uploades til en cloudtjeneste eller sendes i en beskedapp, får det en server-tid for upload eller afsendelse. Metadata kan blive fjernet undervejs, så modtagerens kopi kun har server-tiden. Forskelle mellem EXIF-tid, GPS-tid og uploadtid kan derfor have naturlige forklaringer: tidszone, forsinket upload eller en ældre position. Billedmetadata er beskrevet i EXIF, XMP og IPTC.

Auditlogs og SIEM

En auditlog som Unified Audit Log i Microsoft 365 har et tidsstempel for hændelsen, sat af tjenesten i UTC. Logposten kan blive tilgængelig til søgning noget senere, men det ændrer ikke hændelsestiden. Metoden til at læse og sammenstille logs er beskrevet i Loganalyse og logundersøgelse.

I SIEM og logplatforme er forskellen mellem hændelsestid og indlæsningstid afgørende. Hændelsestiden udtrækkes fra logposten selv, og hvis udtrækket fejler, eller tidszonen er forkert konfigureret, bruger platformen ofte indlæsningstiden i stedet. Så kan hændelser fra en forsinket kilde se ud til at være sket senere, end de gjorde. Se SIEM-data som bevis.

Brugerflade, eksport og API

Samme tidsstempel kan vises på tre måder:

I webbrugerfladen omregnet til den tidszone, der er indstillet i brugerens profil eller browser.
I en eksport som tekst, ofte i UTC, men nogle gange i den eksporterende brugers tidszone, og ikke altid med angivelse af hvilken.
Via API typisk i ISO 8601-format med UTC-markering.

Skærmbilleder fra brugerfladen og eksporter fra samme tjeneste kan derfor vise forskellige klokkeslæt for samme hændelse. Brug den rå eksport eller API-data som grundlag, og notér den eksporterende kontos tidszoneindstilling. Indsamlingsvejene er beskrevet i Cloud-forensic via API og administratoreksport.

Afstemning i praksis

Lav en feltoversigt for hver kilde: feltnavn, hvilket ur der satte det, hvilken hændelse det beskriver, og hvilken tidszone det er i.
Find fælles hændelser på tværs af kilder, fx en sendt mail, der også ses i modtagerens postkasse og i auditloggen.
Mål forskellen mellem klient-tid og server-tid for de fælles hændelser. En konstant forskel peger på urafvigelse, en varierende forskel på forsinkelse.
Normalisér til én tidszone, og bevar de rå værdier. Se Sommertid og tidszoner i rapporten.
Beskriv tidslinjen med begge tider, hvor de afviger mærkbart, og forklar afvigelsen.

Afstemningen bør gentages, hvis der kommer nye kilder til. En ny kilde kan bekræfte eller anfægte den forskel, der er målt.

Typiske fejlkilder

At behandle “sendt” i en chateksport som serverens modtagelsestid.
At sammenligne klient-tid fra én enhed med klient-tid fra en anden og antage, at urene var ens.
At bruge SIEM’ens indlæsningstid som hændelsestid.
At tage et skærmbillede fra en brugerflade uden at notere visningens tidszone.
At overse, at en offline enhed kan have sendt med stor forsinkelse.

Hvad det kan og ikke kan bevise

Server-tid er normalt det stærkeste grundlag for, hvornår en tjeneste registrerede en hændelse, fordi brugeren ikke styrer uret. Den beviser ikke, hvornår handlingen blev udført på enheden, hvis der var forsinkelse. Klient-tid kan vise, hvornår noget skete på enheden, men kun så præcist, som enhedens ur var.

Dokumentation

Angiv i rapporten for hvert centralt tidspunkt, om det er klient-, server- eller indlæsningstid, hvilken kilde det stammer fra, og hvordan eventuelle forskelle mellem kilderne er forklaret.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Når enhedens ur går forkert: urafvigelse og korrektion · Oprettet, ændret, åbnet: hvad fildatoerne betyder

→ Forensisk sikring · For sagkyndige · 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