Identitetsudbydere og SSO: systemlogs som samlet login‑spor

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

Når en virksomhed bruger single sign-on, går brugernes login til mange SaaS-systemer gennem én identitetsudbyder, fx Entra ID, Okta, Google eller en tilsvarende tjeneste. For offentlige selvbetjeningsløsninger spiller MitID og NemLog-in en tilsvarende rolle; se MitID og NemLog-in: hvilke logdata findes. Identitetsudbyderens systemlog bliver derfor et samlet spor: Den viser, hvornår en konto blev godkendt, med hvilke faktorer, fra hvilken IP-adresse og enhed, og til hvilket system der blev udstedt adgang. Den viser til gengæld ikke, hvad brugeren gjorde i systemet bagefter. Det står kun i systemets egen log, og derfor skal de to kilder næsten altid bruges sammen.

Haster det? Identitetsudbydernes systemlogs har en begrænset opbevaringstid, der afhænger af udbyder og abonnement, og bliver ikke længere, fordi sagen opstår. Kontakt os via akut forensisk sikring; hastesager koster ekstra.

Hvordan SSO virker, set fra loggen

Ved SSO med SAML eller OpenID Connect sker der typisk dette:

Brugeren åbner et SaaS-system, som sender brugeren videre til identitetsudbyderen.
Identitetsudbyderen godkender brugeren eller genbruger en eksisterende session hos sig selv.
Identitetsudbyderen udsteder en signeret erklæring eller et token til SaaS-systemet.
SaaS-systemet opretter sin egen session for brugeren.

Identitetsudbyderen logger trin 2 og 3. Trin 4 og alt efter det, som at åbne poster, eksportere data eller ændre indstillinger, ligger i SaaS-systemet. Systemets session kan desuden leve videre i timer eller dage uden ny kontakt til identitetsudbyderen. En spærring af kontoen hos identitetsudbyderen afbryder derfor ikke nødvendigvis en session, der allerede er åben i et SaaS-system. Mekanismen er beskrevet i Sessioner og tokens i loginlogs.

Felter i systemloggen

De konkrete navne varierer mellem udbydere, men en loginhændelse indeholder typisk:

konto og evt. brugerens unikke id,
tidspunkt,
resultat: godkendt, afvist, afbrudt eller udfordret,
hvilke faktorer der blev brugt: adgangskode, app-godkendelse, nøgle eller certifikat,
kilde-IP, brugeragent og evt. enhedsoplysninger,
det system eller den app, adgangen blev givet til,
sessions- eller korrelations-id,
risikovurdering eller politik, der blev anvendt.

Hertil kommer administrative hændelser: oprettelse og spærring af konti, ændringer af gruppemedlemskab, tildeling af apps, ændring af faktorer og nulstilling af adgangskoder. De er ofte lige så vigtige som selve logins. For Entra ID er felterne gennemgået i Entra ID-loginlogs.

Provisionering

Mange identitetsudbydere opretter og nedlægger konti i SaaS-systemerne automatisk via SCIM eller lignende. Provisioneringsloggen viser, hvornår en konto blev oprettet, ændret eller deaktiveret i det enkelte system, og om det lykkedes. Ved en fratræden kan den vise, om adgangen faktisk blev lukket i alle systemer, eller om et system fejlede og lod kontoen være aktiv.

Huller i det samlede spor

Identitetsudbyderen ser kun det, der går gennem den. Disse veje går uden om:

Lokale konti i SaaS-systemet med egen adgangskode, fx nødkonti, ældre konti fra før SSO eller konti oprettet af en systemadministrator.
API-nøgler og personlige adgangstokens udstedt direkte i systemet.
Integrationer med egne legitimationsoplysninger.
Langlivede sessioner og opdateringstokens i systemet selv.
Mobilapps, der gemmer et token og fornyer det mod systemet uden ny godkendelse hos identitetsudbyderen.

Kortlæg derfor i hvert relevant system, om SSO var påkrævet for alle konti, og om lokale logins var mulige. Svaret afgør, om identitetsudbyderens log kan bruges som et fuldstændigt billede af adgangen. Hvordan sådanne logs findes i de enkelte SaaS-systemer, er beskrevet i SaaS-systemer som datakilde.

Typiske spørgsmål, loggen kan hjælpe med

Fratræden: Hvilke systemer loggede kontoen ind i i de sidste uger, og kom der logins efter fratrædelsesdatoen? Et mønster med logins i systemer, kontoen sjældent brugte før, kan pege på, hvor en senere analyse bør begynde.
Overtaget konto: Blev der registreret en ny faktor, og blev den brugt til at godkende logins fra en ny kilde? Hvilke systemer fik adgang efter ændringen?
Administrator: Ændrede en administrator politikker, app-tildelinger eller egne rettigheder, og hvornår?
Leverandør: Har en ekstern konto, fx en konsulent eller MSP, haft adgang til flere systemer end aftalt?

Loggen svarer på, hvor kontoen kom ind. Den peger dermed på, hvilke SaaS-systemers egne logs der skal hentes for at svare på, hvad der skete. I en sag med mange systemer er den derfor ofte det første, der sikres, fordi den afgrænser resten af arbejdet og forhindrer, at tid bruges på systemer, kontoen slet ikke var i. Omvendt kan et system, der ikke optræder i loggen, stadig være brugt via en lokal konto eller en nøgle. Det skal afklares særskilt.

Sikring

Eksportér systemloggen for den relevante periode og konto eller gruppe af konti, i det mest komplette format, udbyderen tilbyder, typisk JSON via API.
Eksportér administrative hændelser for samme periode, også ændringer af politikker og app-tildelinger.
Hent provisioneringsloggen for de relevante systemer.
Gem konfigurationen: hvilke apps der var koblet på SSO, hvilke politikker der krævede hvilke faktorer, og om lokale logins var tilladt.
Notér opbevaringen, som ofte afhænger af abonnementet. På tidspunktet for gennemgangen (oktober 2026) gemmer Entra ID loginlogs i 30 dage med et betalt abonnement og 7 dage uden, og Okta gemmer sin systemlog i 90 dage. Hos Google Workspace og andre udbydere slås perioden op for den konkrete udgave.
Beregn hashværdier for eksporterne, og notér værktøj, forespørgsel og tidsinterval.

Hvis loggen også sendes til et SIEM-system, så sikr begge. SIEM-kopien kan dække længere tid, men felter kan være omdøbt eller udeladt ved indlæsningen.

Korrelation med SaaS-systemets egen log

Koblingen mellem en hændelse hos identitetsudbyderen og en handling i SaaS-systemet laves typisk på:

tid: et login hos identitetsudbyderen kort før den første handling i systemet,
konto: samme bruger-id eller den identitet, der blev sendt i erklæringen,
IP-adresse og brugeragent: samme kilde i begge logs,
sessions-id: hvis systemet logger det id, identitetsudbyderen udstedte.

Uden et fælles id er koblingen en sandsynlighedsvurdering, og det skal fremgå af rapporten. Fremgangsmåden er beskrevet i Logkorrelation.

Fejlkilder i fortolkningen

Genbrugt session. Når identitetsudbyderen allerede har en session, kan et nyt SaaS-login ske uden adgangskode eller ny faktor. Det ligner et let login, men er normal adfærd.
Afbrudte forløb. En hændelse, hvor brugeren blev bedt om en faktor og ikke gennemførte, er ikke et vellykket login.
IP-adresser kan tilhøre en proxy, en VPN eller udbyderens egen infrastruktur. Se IP-adresser som bevis.
Delte konti og fælles postkasser gør, at kontoen ikke peger på én person.
Tidszoner i administrationskonsollen kan være lokale, mens eksporten er i UTC.

Hvad loggen kan og ikke kan bevise

Identitetsudbyderens log kan vise, at en konto blev godkendt til et bestemt system på et bestemt tidspunkt med bestemte faktorer og fra en bestemt kilde. Den kan understøtte, at en tidligere medarbejder fortsat fik adgang efter fratræden, eller at en angriber registrerede en ny faktor. Den kan ikke vise, hvem der fysisk brugte kontoen, og den kan ikke vise, hvad der skete inde i systemerne. Hvordan en virksomhed skal reagere, når en tidligere medarbejder fortsat logger ind, er beskrevet i En tidligere medarbejder logger stadig ind.

Dokumentation

Angiv udbyder, tenant, abonnementsniveau, eksportmetode, tidsinterval i UTC, antal hændelser, konfiguration af SSO og lokale logins, hashværdier og de systemer, hvor SSO ikke var eneste adgangsvej. Beskriv også, hvordan koblingen til de enkelte SaaS-systemers logs er foretaget.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Cloud- og SaaS-forensik

Læs også: Objektlager (S3, Blob): adgangslogs og versionering · SaaS-systemer som datakilde: hvilke logs findes, og hvem har dem

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · 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