Krypterede data i en undersøgelse: de lovlige adgangsveje

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

Kryptering er i dag slået til som standard på de fleste computere, telefoner og cloudtjenester. I en civil sag eller intern undersøgelse er spørgsmålet derfor sjældent, om data er krypteret, men hvilken lovlig vej der er til nøglen. De lovlige veje er få og velkendte: nøgler, som organisationen har deponeret, administratoradgang til systemer, organisationen selv ejer, en kørende og oplåst enhed, brugerens samtykke og medvirken, og en afgørelse fra retten. Denne artikel giver overblikket på tværs af platforme. Den beskriver ikke, og dette site beskriver ikke, metoder til at omgå kryptering eller gætte adgangskoder.

Hvor krypteringen findes

Hele disken · BitLocker på Windows, FileVault på Mac, LUKS på Linux
Telefonen · Indbygget kryptering af brugerdata på iPhone og Android
Backup · Krypteret iPhone-backup, krypterede backupsæt
Filer og containere · Krypterede arkiver, containerfiler, krypterede USB-nøgler
Dokumenter og mails · Følsomhedsetiketter, dokumentbeskyttelse og mailkryptering
Tjenester · Cloudlagre og beskedtjenester med kryptering

Hvert lag har sine egne nøgler, og adgang til ét lag giver ikke nødvendigvis adgang til de andre. En oplåst computer kan indeholde en krypteret container, og en åben postkasse kan indeholde beskyttede dokumenter.

Vej 1: Deponerede nøgler

I organisationer er gendannelsesnøgler ofte deponeret centralt:

BitLocker-gendannelsesnøgler i Entra ID, Active Directory eller et MDM-system, eller for privatkonti i brugerens Microsoft-konto.
FileVault-gendannelsesnøgler i et MDM-system, hvis organisationen har sat det op.
Nøgler til tredjepartskryptering i leverandørens administrationskonsol.

Det første spørgsmål i enhver sag med en krypteret computer er derfor, hvor organisationen opbevarer nøglerne, og hvem der har ret til at hente dem. Svaret bør findes, før der er en sag. Mangler deponeringen for nogle enheder, fx fordi de er sat op uden for den normale proces, er det en svaghed, der først viser sig, når nøglen skal bruges. En periodisk kontrol af, at alle krypterede enheder har en deponeret nøgle, er derfor en del af beredskabet. Udlevering af en nøgle bør logges, så det kan dokumenteres, hvem der hentede den og hvornår. De platformsspecifikke detaljer står i BitLocker og FileVault i bevissikring.

Vej 2: Administratoradgang til egne systemer

For cloudtjenester og servere, som organisationen selv ejer, går adgangen typisk gennem administratorrettigheder frem for brugerens adgangskode. Data i Microsoft 365 eller Google Workspace kan indsamles med administrative værktøjer, uden at brugerens adgangskode kendes eller nulstilles. Dokumenter beskyttet med organisationens egne etiketter kan dekrypteres af personer, som organisationen har tildelt særlige rettigheder til formålet. I Microsoft Purview hedder det superbrugerfunktionen (super user feature). Den er som standard ikke slået til, og ingen er tildelt rollen, før en administrator aktiverer funktionen og udpeger superbrugerne.

Det er vigtigt at skelne: Administratoradgang til organisationens systemer er noget andet end at logge ind som brugeren. At nulstille en adgangskode for at logge ind på en konto ændrer data, kan udløse varsler og efterlader spor, som senere skal forklares.

Vej 3: Den kørende og oplåste enhed

Er computeren tændt og logget på, er data tilgængelige i dekrypteret form. Det kan være den eneste mulighed, hvis ingen nøgle er deponeret. Valget mellem at sikre live og at slukke er behandlet i Sluk, isolér eller lad den køre?, og sikring af hukommelsen, som kan indeholde nøglemateriale, i Hukommelsessikring (RAM). Også her kræves et lovligt grundlag for at undersøge enheden. At den er låst op, giver ikke i sig selv ret til adgang.

Vej 4: Samtykke og medvirken

Brugeren kan oplyse sin kode eller selv låse enheden op. Ved private enheder og private konti er det ofte den eneste vej. Samtykket bør:

være skriftligt og konkret, med angivelse af enhed, konto og formål,
afgrænse, hvad der må sikres og undersøges,
være givet frivilligt og kunne dokumenteres.

Det er ofte bedst, at brugeren selv indtaster koden i overværelse af den, der sikrer, så koden ikke skal noteres. Notér tidspunkt, hvem der var til stede, og hvad der skete. Ved telefoner afgør koden ofte også, hvilken udtrækstype der er mulig. Se Udtræk fra mobiltelefoner.

Situationen, hvor en medarbejder ikke vil oplyse koden til en arbejdscomputer, er beskrevet fra virksomhedens side i Medarbejderen vil ikke oplyse adgangskoden.

Vej 5: Rettens afgørelse

Kan data ikke tilgås på andre måder, og er de afgørende, kan spørgsmålet om udlevering af koder eller data indgå i sagen. Den juridiske side er beskrevet på Kan modparten pålægges at udlevere en adgangskode?. Teknisk set er opgaven at være klar: at have en sikret, krypteret kopi, så nøglen kan bruges, når den foreligger, og at kunne beskrive præcist, hvad der kræves for at åbne den.

Andre kilder til de samme data

Når en enhed ikke kan låses op, findes de samme data ofte et andet sted, hvor adgangen er enklere og lovligt grundlag lettere at etablere:

Organisationens cloudtjenester: Mails, filer og chat fra en arbejdscomputer ligger typisk også i Microsoft 365 eller Google Workspace, hvor organisationen har administratoradgang.
Backup: Organisationens backup af servere og arbejdsstationer kan være krypteret med nøgler, som organisationen selv har.
Modtagernes kopier: En besked eller mail findes også hos modtageren, som kan medvirke.
Synkroniserede enheder: En telefon, der ikke kan låses op, kan dele data med en computer eller tablet, som kan.

Beskedtjenester med end-to-end-kryptering er et særligt tilfælde. Tjenestens servere har normalt ikke adgang til indholdet, så indholdet findes kun på deltagernes enheder og i eventuelle backups. Adgangen går derfor gennem en af deltagernes enheder med samtykke eller på andet lovligt grundlag. Tjenesten kan i visse tilfælde have metadata som kontooplysninger, men ikke beskederne selv. Backups er ikke nødvendigvis end-to-end-krypterede: WhatsApp tilbyder krypteret backup som et tilvalg, brugeren selv skal slå til, og en iCloud-backup af en iPhone, inklusive beskeder, er kun end-to-end-krypteret, når Avanceret databeskyttelse er slået til. Uden den har Apple nøglen til backuppen.

En samlet plan, der ser på alle kilder, er ofte mere effektiv end at fokusere på den ene enhed, der er låst.

Hvad der ikke gøres

Gentagne gæt på koder på telefoner og hardwarekrypterede medier kan udløse forsinkelser eller sletning af data. Koder prøves derfor ikke ud fra formodninger, og koder, der er fundet tilfældigt under en undersøgelse, fx på en seddel, bruges kun, hvis grundlaget for det er afklaret. Anvendelsen skal i så fald dokumenteres. Omgåelse af sikkerhedsmekanismer ligger uden for, hvad der beskrives her.

Sikr den krypterede kopi alligevel

Selv om nøglen ikke foreligger, bør det krypterede medie sikres som en fuld kopi med hashværdi. Nøglen kan komme senere, via en deponering, der først findes efter sikringen, via samtykke eller via retten. Uden kopien er muligheden måske væk, fordi enheden er genbrugt, nulstillet eller returneret.

Hvad adgangen kan og ikke kan bevise

At data er krypteret, er normalt ikke i sig selv et tegn på noget usædvanligt. Kryptering er standard. Fund af krypterede containere eller ekstra krypteringslag kan dog være relevante og bør dokumenteres. Se Krypterede containere og arkiver.

Dokumentation

Angiv krypteringsløsning og tilstand ved sikringen, hvilken adgangsvej der er brugt og på hvilket grundlag, hvem der udleverede nøgle eller kode, uden at gengive selve nøglen, og hvilke data der forblev utilgængelige.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Tidligere versioner i cloud: versionshistorik, papirkurv og opbevaring · Krypterede containere og arkiver: identifikation og dokumentation

→ Forensisk undersøgelse af en computer · 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