Forside › Cloud- og SaaS-forensik · Gennemgået oktober 2026 · Af John Nielsen
I et SaaS-system findes der næsten altid flere logs, end kunden kan se. Kunden har typisk adgang til en auditlog, en loginoversigt og måske en historik på de enkelte poster, alt efter abonnement. Eksempler er sidehistorik i wikier og kravdokumenter og adgangslogs i HR- og lønsystemer. Leverandøren har derudover applikationslogs, webserverlogs, databasebackup og logs over egne medarbejderes adgang. Det første tekniske skridt i en sag er derfor at skille de to lag ad og finde ud af, hvad der kan hentes selv, hvad der skal bestilles hos leverandøren, og hvor hurtigt det forsvinder.
Lagene i et typisk SaaS-system
- Auditlog for administratorhandlinger og brugerhandlinger · Kunden, ofte afhængigt af abonnement
- Loginlog med tidspunkt, IP-adresse og resultat · Kunden, ofte med kort opbevaring
- Ændringshistorik på poster eller felter · Kunden, hvis den er slået til pr. felt
- Eksport- og rapporthændelser · Kunden, nogle gange kun med tilkøb
- API- og integrationslog · Kunden delvist, leverandøren fuldt
- Applikations- og fejllogs · Leverandøren
- Webserver- og CDN-logs · Leverandøren eller dennes underleverandør
- Databasebackup og transaktionslogs · Leverandøren
- Log over leverandørens egne supportadgange · Leverandøren, nogle gange synlig for kunden
Tabellen er et udgangspunkt. Mange mindre systemer har kun en del af lagene, og navnene varierer. Pointen er, at fravær i kundens brugerflade ikke betyder, at data ikke findes. Det betyder, at de skal hentes et andet sted.
Abonnementets betydning
Mange leverandører differentierer logning efter abonnement. Det kan betyde, at auditloggen kun findes på de dyreste planer, at opbevaringen er kortere på de billigere, eller at detaljerede hændelser som eksport, rapportkørsler og API-kald kræver et tilkøb. Abonnementet kan også være ændret i perioden. Notér derfor både det nuværende abonnement og det, der gjaldt på tidspunktet for hændelserne, og spørg leverandøren, om logning, der ikke var synlig for kunden, alligevel blev registreret internt.
Eksportveje
- Brugerfladen: Eksport til CSV eller lignende fra en administrationsside. Hurtigt, men ofte begrænset i antal rækker, felter og periode. Felter kan være omformateret, og tidszonen kan være brugerens lokale.
- API: Revisions- og loginhændelser kan ofte hentes via et dokumenteret API med sideinddeling. Det giver normalt de mest komplette data, i JSON og med UTC-tidsstempler. Dokumentér kald, parametre, antal sider og antal poster.
- Streaming: Nogle systemer kan sende hændelser løbende til et SIEM-system eller en lagerkonto. Er det sat op, kan det dække længere tid end systemets egen opbevaring.
- Leverandøreksport: En udtrækning, som leverandøren laver efter anmodning. Den kan indeholde data fra lag, kunden ikke selv har adgang til, men den er sværere at efterprøve.
Den generelle metode for indsamling via API og administratoreksport er beskrevet i Cloud-forensic via API og administratoreksport. Her er det vigtigste, at eksporten tages fra den mest komplette vej, og at du kontrollerer antallet af poster mod det, systemet selv viser.
Spørgsmål til leverandøren
Stil spørgsmålene skriftligt, og bed om skriftlige svar. Svarene indgår i dokumentationen.
- Hvilke logs registrerer systemet for vores konto, og hvilke af dem kan vi selv se?
- Hvor længe gemmes hver log, og gælder det samme for alle abonnementer?
- Registreres eksport, rapportkørsel, masseændringer og API-kald? Med hvilke felter?
- Hvilken tidszone og hvilket tidsformat bruger loggene?
- Kan loggene udleveres i et maskinlæsbart format med alle felter?
- Kan I bevare loggene for en bestemt periode, indtil sagen er afklaret?
- Har jeres egne medarbejdere haft adgang til vores data i perioden, og logges det?
- Er der sket ændringer i systemet eller i logningen i perioden, fx en større opdatering eller en migrering?
- Hvilke underleverandører opbevarer logs, fx hosting eller CDN?
Leverandøren har ingen pligt til at svare hurtigt, medmindre kontrakten siger det. Hvilke krav en kunde kan stille i aftalen, er beskrevet i Cloudtjenester: sikr jer adgang til data og logs. Er leverandøren modpart i en tvist, bliver spørgsmålet om udlevering juridisk; se SaaS-tvister: oppetid, SLA og logdata.
Leverandørens egen adgang
Et lag, der ofte overses, er leverandørens adgang til kundens data. Supportmedarbejdere, udviklere og driftsfolk hos leverandøren kan have teknisk adgang til at se, ændre eller gendanne data, fx når en kunde beder om hjælp. Nogle systemer viser den slags adgang i kundens auditlog, nogle kræver, at kunden godkender den på forhånd, og andre logger den kun internt. I en sag, hvor data er ændret, og ingen af kundens egne brugere ser ud til at stå bag, er spørgsmålet om leverandørens adgang derfor ikke en formalitet. Spørg konkret, og bed om leverandørens log over egne adgange til kontoen i perioden. Er der tale om en ekstern driftspartner eller en MSP mellem kunden og leverandøren, gælder det samme for deres konti.
Fuldstændighed
En log fra et SaaS-system er en eksport fra en database, du ikke kan se. Fuldstændigheden kan derfor ikke kontrolleres direkte. Brug indirekte kontroller:
- Optælling: Antal poster pr. dag i eksporten sammenlignet med en optælling i systemet eller via API.
- Kendte hændelser: Dine egne handlinger, fx et testlogin eller en eksport under sikringen, skal optræde i loggen. Gør det bevidst, og notér tidspunktet.
- Krydskilder: Logins i systemets egen log sammenholdt med identitetsudbyderens log, hvis der bruges SSO. Se Identitetsudbydere og SSO.
- Fortløbende id’er: Har hændelserne fortløbende numre, kan huller ses.
Fejlkilder i fortolkningen
- Hændelsesnavne er leverandørens egne. “Viewed”, “exported” og “downloaded” kan dække andet end det, ordet antyder. Slå betydningen op i dokumentationen, og test den om muligt.
- Systemhandlinger. Automatiseringer, integrationer og planlagte job står ofte med en teknisk bruger eller med den bruger, der oprettede automatiseringen.
- Klienttid og servertid. Nogle felter er skrevet af brugerens enhed, andre af serveren. Se Server-tid og klient-tid.
- Felthistorik slået til sent. Historikken på en post starter først den dag, den blev aktiveret. En post uden historik er ikke uændret.
- Migrering. Ved skift af platform eller version kan ældre logs være flyttet, komprimeret eller udeladt.
Hvad loggene kan og ikke kan bevise
Kundens auditlog kan vise, at en konto udførte en handling i systemet på et tidspunkt, set fra leverandørens server. Den er typisk stærk, fordi kunden ikke kan redigere den. Den kan ikke vise, hvem der brugte kontoen, hvad der skete med en eksporteret fil bagefter, eller noget om de lag, kunden ikke har adgang til. Leverandørens interne logs kan udfylde hullerne, men de er udleveret af en part, der ikke altid er neutral, og det skal fremgå af vurderingen.
Systemer som CRM og ERP har deres egne mønstre for historik og revision. De er behandlet i Feltlog og ændringshistorik i CRM-systemer og ERP-systemers audit trail.
Dokumentation
Notér for hvert system: leverandør, abonnement i perioden, hvilke logs der fandtes, eksportvej, tidspunkt, konto brugt til eksporten, antal poster, tidszone, hashværdier og leverandørens skriftlige svar. Beskriv de lag, der ikke kunne hentes, og hvorfor.
Kilder og versioner
- NIST SP 800-92: Guide to Computer Security Log Management
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
- ISO/IEC 27037: Guidelines for identification, collection, acquisition and preservation of digital evidence
Senest gennemgået: oktober 2026.
Næste skridt
- Danske cloudregnskabsprogrammer: ændringslog og eksport
- MitID og NemLog-in: hvilke logdata findes, og hvem har dem
Del af: Cloud- og SaaS-forensik
Læs også: Identitetsudbydere og SSO: systemlogs som samlet login-spor · ERP-systemers audit trail teknisk
→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
