Identifikation af datakilder: teknisk kortlægning før sikringen

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

Den sikring, der går galt, går oftest galt før den begynder: Den relevante kilde blev ikke identificeret, og da man opdagede den, var loggen rullet over, kontoen slettet eller telefonen nulstillet. Identifikation er derfor første fase i både ISO/IEC 27037 og i almindelig god praksis. Den består i at kortlægge, hvor data om de relevante personer, systemer og tidsrum kan findes, hvem der har adgang, hvor længe data bevares, og hvordan de kan sikres. Resultatet er et teknisk datakort, som sikringsplanen bygges på.

Hvad virksomheden praktisk skal stille til rådighed under en sikring, står på Det skal virksomheden stille til rådighed. Standardernes faser er beskrevet i ISO/IEC 27037 og NIST SP 800-86. Her gennemgås den tekniske kortlægning.

Udgangspunktet: spørgsmålet

Kortlægningen begynder med det, der skal undersøges: hvilke personer eller konti, hvilket tidsrum og hvilke handlinger. Spørgsmålet “har en medarbejder taget kundedata med ved fratræden?” peger på andre kilder end “hvornår blev leverandørens adgang misbrugt?”. Skriv spørgsmålet ned, og brug det til at afgrænse, men vær opmærksom på kilder, der ligger uden for den første afgrænsning, fordi data ofte flyttes mellem systemer.

Kategorier af datakilder

Endpoints · Bærbare og stationære computere, brugerprofiler, lokale synkroniseringsmapper
Mobile enheder · Firmatelefoner, tablets, private enheder med firmadata, MDM-oplysninger
Servere · Filservere, applikationsservere, databaser, virtuelle maskiner, NAS
Identitet · Active Directory, Entra ID, SSO-tjenester, MFA-registreringer
Mail og samarbejde · Microsoft 365, Google Workspace, Teams, Slack, intranet
Forretningssystemer · ERP, CRM, HR, økonomi, ticketsystemer, kildekode
Netværk · Firewall, VPN, DNS, proxy, trådløst net, DHCP
Sikkerhed · EDR, SIEM, DLP, mailfiltre, adgangskontrol
Backup og arkiv · Backupsæt, arkiver, snapshots, tidligere enheder
Eksterne · MSP, hosting, teleoperatør, SaaS-leverandører, banker
Skygge-IT · Private cloudkonti, private mailadresser, beskedapps, ukendte SaaS-tjenester

Listen er en tjekliste, ikke en sikringsplan. Mange kilder vil vise sig at være irrelevante, men det skal være et bevidst fravalg.

Hvad der skal kortlægges for hver kilde

For hver relevant kilde noteres:

Placering og ejer: hvor data ligger fysisk eller hos hvilken tjeneste, og hvem der ejer systemet.
Administrator: hvem har teknisk adgang, internt og hos leverandører.
Indhold og relevans: hvilke spørgsmål kilden kan belyse.
Opbevaring: hvor længe data bevares, og hvornår de slettes eller overskrives automatisk.
Licens og funktioner: særligt i cloud, hvor logning og opbevaring afhænger af abonnement.
Sikringsvej: diskkopi, logisk kopi, eksport, API eller anmodning til leverandør.
Grundlag: hvem kan give adgang, og er der private data, der kræver særlig håndtering.

Opbevaringstiden er ofte det, der afgør prioriteringen. Logs med kort opbevaring og konti, der er sat til sletning, skal sikres først. Rækkefølgen er beskrevet i Flygtighedsorden, og opbevaring af logs i Logfiler og logrotation.

Metoder til at finde kilderne

Interview med IT og ledelse er nødvendigt, men ikke nok. Folk glemmer systemer, og skygge-IT kendes ofte ikke af IT. Tekniske metoder supplerer:

Inventarlister fra MDM, EDR og asset-systemer viser enheder pr. bruger, også dem, der ikke er i brug lige nu.
Loginlogs i identitetsudbyderen viser, hvilke applikationer og enheder en konto har brugt.
Samtykker til apps i Microsoft 365 eller Google Workspace viser tredjepartstjenester med adgang til data.
DNS-, proxy- og firewalllogs viser, hvilke tjenester der er kontaktet fra virksomhedens net, også tjenester, IT ikke kender.
Licensoversigter og fakturaer viser betalte SaaS-tjenester.
Synkroniseringsklienter og browserprofiler på brugerens computer viser cloudkonti, der er logget ind.

Hvilke logs SaaS-tjenester typisk har, er beskrevet i SaaS-logs: hvad findes?.

Datakortet

Resultatet samles i et teknisk datakort, en tabel med en række pr. kilde og kolonner for punkterne ovenfor. Det bruges til at prioritere sikringen, til at aftale med leverandører og til at dokumentere senere, hvad der blev overvejet og hvorfor. En skabelon findes i Skabelon: teknisk datakort, og ledelsens version af samme kort er beskrevet på Datakort: hvor ligger vores data?.

Personer, konti og tidsrum

Kilder knyttes til personer gennem konti, og en person har ofte flere: en domænekonto, en cloudkonto, administratorkonti, servicekonti, delte postkasser, konti i forretningssystemer og eventuelt private konti, der er brugt til arbejde. Kortlæg alle identiteter for hver relevant person, og notér, hvilke kilder der logger på hvilken identitet. En handling udført med en administratorkonto ses ikke, hvis man kun søger på brugerens almindelige konto.

Tidsrummet skal også fastlægges teknisk. Hvis spørgsmålet handler om de sidste tre måneder før en fratræden, skal kilderne kunne dække hele perioden. Er det ikke muligt, fordi en log kun rækker 30 dage tilbage, skal backup eller andre kilder dække resten, eller begrænsningen skal skrives ned.

Private enheder og tredjeparter

Private telefoner og computere, der er brugt til arbejde, er ofte relevante, men de kan kun sikres med ejerens samtykke eller med et retligt grundlag. Kortlægningen skal derfor skelne mellem kilder, virksomheden selv råder over, og kilder, der kræver samtykke, aftale eller en anmodning til en tredjepart. For de sidste er det især vigtigt at kende opbevaringstiden, fordi en anmodning til en leverandør kan tage tid.

Når det haster

I en akut situation er der ikke tid til en fuld kortlægning, før de første kilder sikres. Så laves en hurtig version med de kilder, der har kortest opbevaring, og de enheder, der risikerer at blive nulstillet eller returneret. Resten kortlægges, mens de første sikringer kører. Datakortet opdateres løbende, så det til sidst afspejler hele forløbet, også hvad der blev fundet sent.

Identifikation uden at ændre noget

Kortlægningen må ikke selv ødelægge spor. Nogle forholdsregler:

Brug administratorkonsoller og eksisterende rapporter frem for at logge ind på brugerens enhed.
Lad være med at søge i brugerens postkasse eller filer, før omfang og grundlag er afklaret.
Notér, hvem der har slået hvad op, hvornår og fra hvilken konto, fordi opslagene selv kan fremgå af logs.
Advar ikke den, der undersøges, gennem synlige handlinger, fx ændring af rettigheder, før sikringen er planlagt.

Typiske fejl

Kun den åbenlyse enhed. Computeren sikres, men telefonen, cloudkontoen og den gamle bærbare overses.
Licens antages. Man går ud fra, at en log findes, uden at kontrollere abonnement og opsætning.
Eksterne glemmes. MSP’ens fjernadgangslogs og hostingudbyderens logs har ofte kort opbevaring og skal anmodes om hurtigt.
Backup overses som kilde til data fra før sletningen.
Udskiftede enheder. En computer eller telefon, der er udskiftet i perioden, ligger måske på et lager eller hos en leasingpartner og bliver snart slettet. Spørg efter enhedernes historik, ikke kun de nuværende.

Hvad kortlægningen kan og ikke kan

Kortlægningen sikrer ikke data, men den er grundlaget for at vise, at sikringen er dækkende og proportional. Den kan ikke garantere, at alle kilder er fundet, men den kan dokumentere, at der er ledt systematisk.

I rapporten

Gengiv datakortet eller et uddrag med de relevante kilder, metoderne til at finde dem, fravalgte kilder med begrundelse og kilder, der ikke kunne sikres, med årsag.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Hukommelsessikring (RAM): hvad hukommelsen rummer, og hvordan den sikres · Flygtighedsorden: hvad skal sikres først?

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