Kryptering med nøgler, som kunden selv styrer, nævnes ofte som svaret på spørgsmålet om udenlandsk jurisdiktion. Nøglerne kan begrænse, hvad udbyderen kan læse og udlevere, men de afgør ikke, om tjenesten fortsat er tilgængelig.
Artiklen forklarer de mest udbredte modeller for nøglekontrol ud fra udbydernes egen dokumentation og Det Europæiske Databeskyttelsesråds anbefalinger. Den anbefaler ingen bestemt løsning.
Fire modeller med hvert sit niveau af kontrol
Begrebet egne nøgler dækker over flere modeller, som giver meget forskellig kontrol.
- Udbyderstyrede nøgler · Udbyderen krypterer data og administrerer selv nøglerne. Det er standard hos de fleste cloudtjenester.
- Kundestyrede nøgler · Kunden ejer rodnøglen, men nøglen ligger i udbyderens nøgletjeneste, og udbyderen bruger den til at levere tjenesten. Modellen kaldes ofte bring your own key.
- Eksternt opbevarede nøgler · Nøglen ligger i kundens eget nøglesystem uden for udbyderen, og udbyderen skal spørge systemet ved hver dekryptering. Modellen kaldes ofte hold your own key.
- Klientsidekryptering · Data krypteres på brugerens enhed, før de sendes til tjenesten, så tjenesten kun modtager krypterede data.
Hvor meget en model beskytter, afhænger af, om udbyderen på noget tidspunkt har adgang til nøglen eller til data i læsbar form.
Sådan beskriver udbyderne deres løsninger
Microsoft beskriver i sin dokumentation for Customer Key, at kunden kontrollerer rodnøglerne på applikationsniveau. Kunden giver samtidig udtrykkeligt Microsoft 365 lov til at bruge nøglerne til tjenester som eDiscovery, beskyttelse mod malware og spam samt søgeindeksering. Microsoft beskytter desuden en såkaldt availability key. Customer Key krypterer kun data, der lagres i Microsofts cloud, og beskytter ikke data i lokale installationer.
Microsofts Double Key Encryption, senest opdateret 27. oktober 2026, bruger to nøgler. Den ene opbevares i Azure, den anden kontrollerer kunden selv, og begge skal bruges for at læse data. Microsoft skriver, at løsningen er beregnet til de mest følsomme data og ikke til alle data. Som eksempel anslår dokumentationen, at omkring 5 procent af en typisk organisations data hører til i den mest følsomme kategori. For resten peger Microsoft på løsninger med nøgler, Microsoft administrerer, eller på bring your own key.
Google oplyser i sin beskrivelse af klientsidekryptering i Workspace, opdateret 26. oktober 2026, at Googles servere og tredjeparter ikke kan dekryptere indholdet. Funktionen kræver bestemte Workspace-udgaver.
AWS beskriver external key stores, hvor nøglen ligger i kundens eget nøglesystem uden for AWS. Ifølge AWS kan AWS KMS hverken oprette, se, administrere eller slette kundens nøgler.
Hvad nøglekontrol beskytter mod
Når udbyderen ikke har adgang til nøglen, kan den ikke udlevere læsbare data. Det Europæiske Databeskyttelsesråd beskriver i sine anbefalinger 01/2020, version 2.0 af 18. juni 2021, et scenarie med opbevaring, fx backup, hos en udbyder i et tredjeland.
Rådet anser her kryptering for en effektiv supplerende foranstaltning, hvis en række betingelser er opfyldt. Krypteringen skal være stærk og korrekt implementeret, og nøglerne skal forvaltes pålideligt. Nøglerne skal desuden opbevares alene af dataeksportøren eller af en betroet enhed i EØS eller i en jurisdiktion med et tilsvarende beskyttelsesniveau.
Betingelsen om nøglernes placering er central. En nøgle, der opbevares hos udbyderen eller hos en virksomhed under samme jurisdiktion, giver ikke samme beskyttelse.
Når tjenesten skal læse data
Mange tjenester skal kunne læse data for at fungere, fx for at søge, scanne for malware eller lade flere redigere samme dokument. I anbefalingernes scenarie 6 skal en cloududbyder have adgang til data i klartekst.
Her kan Databeskyttelsesrådet ikke pege på en effektiv teknisk foranstaltning, hvis myndighederne i modtagerlandet har beføjelser, der går ud over det nødvendige og forholdsmæssige. Ifølge punkt 95 er kryptering under transport og ved lagring heller ikke tilstrækkelig, når udbyderen har nøglerne.
Det forklarer, hvorfor kundestyrede nøgler giver begrænset beskyttelse mod udlevering. Udbyderen bruger nøglen til at levere tjenesten og har derfor adgang til data i læsbar form, når tjenesten kører. Rækkevidden af udleveringskrav er beskrevet i → Cloud Act.
Prisen er færre funktioner
Stærkere nøglekontrol betyder, at tjenesten kan mindre. Microsoft oplister funktioner, der ikke virker med Double Key Encryption. Blandt dem er eDiscovery, indholdssøgning og indeksering, regler for mailflow, der skal kunne se vedhæftede filer, samtidig redigering i Office på nettet og Copilot.
SharePoint og OneDrive kan ikke behandle filer krypteret på den måde, og de kan ikke åbnes i Office på nettet. Etiketter med Double Key Encryption kan heller ikke bruges til at beskytte Teams-møder og chat.
AWS skriver, at external key stores flytter ansvaret for sikkerhed, tilgængelighed og ydeevne for nøglerne til kunden. For de fleste kunder vil den større risiko for tilgængelighed og forsinkelse ifølge AWS overstige den opfattede sikkerhedsgevinst. Valget af model er derfor en afvejning mellem kontrol og drift. Den afvejning hører med, når alternativer sammenlignes i → trin 7, fordi en løsning med stærk nøglekontrol kan kræve egne kompetencer og eget udstyr til nøglehåndtering.
Hvad nøglerne ikke beskytter mod
Nøglekontrol beskytter indholdet. Den holder ikke en tjeneste kørende, hvis udbyderen lukker en konto eller ophører med at levere. Sanktioner og dekreter kan afbryde levering uanset kryptering, jf. → sanktioner og dekreter og sagen om → ICC og Microsoft.
Nøglen er samtidig et værktøj til at gøre data ulæselige. Microsoft oplyser, at når kunden tilbagekalder adgangen til sine nøgler, slettes availability key, hvilket fører til kryptografisk sletning af data. AWS skriver, at krypterede data bliver umulige at gendanne, hvis kunden permanent fjerner adgangen til sit eksterne nøglesystem.
Nøglekontrol kan altså sikre, at data ikke kan læses efter en exit. Den hjælper ikke med at få data ud.
Nøglerne og selve exitten
AWS skriver, at kunden ikke kan dekryptere data krypteret med en nøgle i et external key store uden for AWS, heller ikke med sit eget nøglemateriale. Det skyldes, at AWS først krypterer med sit eget nøglemateriale, og at kundens nøgle lægger endnu et lag udenpå.
Konsekvensen for en exit er, at data skal trækkes ud, mens tjenesten fungerer og nøglerne er tilgængelige. Mister kunden adgangen til tjenesten, har nøglen alene ingen værdi for at genskabe data. Udtræk og formater skal derfor planlægges særskilt, jf. → trin 8 om dataudlevering og overgang.
En backup uden for tjenesten, krypteret med nøgler organisationen selv har, er det, der sikrer adgangen til data, hvis tjenesten forsvinder, jf. → backup hos samme udbyder.
Spørgsmål til udbyderen
Stil de samme spørgsmål til alle udbydere, og notér svarene med dato. Svarene skal kunne findes i udbyderens dokumentation eller kontrakt.
- Model · Hvilken nøglemodel tilbydes, og for hvilke datatyper og tjenester gælder den?
- Adgang i klartekst · Hvornår har udbyderen adgang til data i læsbar form, fx ved søgning, indeksering eller support?
- Nøglens placering · Hvor opbevares nøglen, og hvilken juridisk enhed driver nøglesystemet?
- Mistede funktioner · Hvilke funktioner virker ikke med den valgte model?
- Tilbagekaldelse · Hvad sker der med data, når adgangen til nøglen tilbagekaldes midlertidigt eller permanent?
- Udtræk · Kan data eksporteres i læsbar form, og kan de dekrypteres uden for tjenesten?
Hvad nøglekontrol kan og ikke kan
Nøglekontrol kan begrænse, hvad en udbyder kan læse og udlevere, når udbyderen ikke har adgang til nøglen eller til data i klartekst. Den kan også sikre, at data kan gøres ulæselige efter en opsigelse.
Den kan ikke holde en tjeneste kørende ved lukning, og den giver ikke adgang til data, hvis tjenesten bliver utilgængelig. Den beskytter heller ikke data, der behandles i læsbar form for at levere tjenesten. Om en konkret løsning opfylder kravene ved overførsel af personoplysninger, er en juridisk vurdering.
Betydningen for exit-planen
Nøglekontrol hører til i vurderingen af, hvem der kan se data, men den erstatter ikke planen for at komme ud. Opdel systemerne efter, om de skal kunne læse data for at fungere.
- Vurder i → trin 4, hvem der kan lukke, se og ændre, og notér nøglemodellen for hvert system.
- Placer nøglekontrol i den operationelle del af → de tre lag, og vurder jurisdiktionen for sig.
- Planlæg udtræk og backup uafhængigt af nøglerne.
En uvildig vurdering kan betale sig, når nøglekontrol skal indgå som argument over for kunder, tilsyn eller i et udbud. Nielco IT’s jurisdiktions- og afhængighedsvurdering vurderer for hvert system, hvem der kan lukke, se og ændre, og med hvilket varsel.
Kilder
- Microsoft Learn: Overview of Customer Key, Microsoft Purview, opdateret 1.6.2026. https://learn.microsoft.com/en-us/purview/customer-key-overview
- Microsoft Learn: Double Key Encryption (DKE), Microsoft Purview, opdateret 27.10.2026. https://learn.microsoft.com/en-us/purview/double-key-encryption
- Google Workspace: About client-side encryption, opdateret 26.10.2026. https://knowledge.workspace.google.com/admin/security/about-client-side-encryption
- Amazon Web Services: External key stores, AWS Key Management Service Developer Guide, set 30.10.2026. https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html
- Det Europæiske Databeskyttelsesråd (EDPB): Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data, version 2.0, 18.6.2021, punkt 84 til 95. https://www.edpb.europa.eu/system/files/2021-06/edpb_recommendations_202001vo.2.0_supplementarymeasurestransferstools_en.pdf
