Europæisk cloud

Nøgler i cloud: BYOK, HYOK og HSM

Nøgler i cloud: BYOK, HYOK og HSM

Der er tre hovedmodeller for nøgler til kryptering i cloud. Med BYOK laver I selv nøglen og lægger den ind hos udbyderen. Med HYOK beholder I nøglen uden for udbyderen. Med en HSM ligger nøglen i særlig hardware, enten hos udbyderen eller hos jer. Jo mere kontrol I tager, jo mere drift kræver det, og jo flere af udbyderens tjenester holder op med at kunne læse data.

Nøglekontrol som spørgsmål om suverænitet, og hvad den beskytter mod juridisk, er gennemgået på digital-suveraenitet.dk, hvor egne nøgler ses som suverænitetsspørgsmål. Her står den side, driften mærker: hvad hver model kræver, og hvad den bryder.

Udbyderens egne nøgler

Udgangspunktet hos de fleste udbydere er, at data krypteres med nøgler, som udbyderen laver og styrer. Det kræver intet af jer, og alle tjenester virker. Udbyderen kan dekryptere, fordi den har nøglen. Det er den model, de øvrige skal holdes op imod.

BYOK: egen nøgle hos udbyderen

BYOK står for “bring your own key”. I laver nøglematerialet selv, typisk i egen HSM eller nøgleløsning, og importerer det til udbyderens nøgletjeneste. AWS og Azure beskriver begge import af eget nøglemateriale i deres dokumentation.

Det giver jer kontrol over, hvordan nøglen er lavet, og en kopi uden for udbyderen. Når nøglen er importeret, bruger udbyderens tjenester den som en hvilken som helst anden nøgle, så tjenesterne virker. Udbyderen bruger altså stadig nøglen, når data skal læses.

For driften kræver BYOK en proces for at lave, opbevare og udskifte nøglemateriale, og en kopi, der ikke går tabt. Mister I nøglen og sletter den hos udbyderen, er data tabt.

HSM hos udbyderen

En HSM er et hardwaremodul, der laver og opbevarer nøgler, så de ikke kan trækkes ud i klartekst. Udbyderne tilbyder HSM som tjeneste. Microsoft beskriver fx Azure Key Vault Managed HSM som fuldt administreret og med én lejer pr. HSM, valideret efter FIPS 140-3 niveau 3, og med eget sikkerhedsdomæne pr. instans.

Det giver en stærkere adskillelse af nøglerne fra andre kunder. HSM’en står stadig hos udbyderen og drives af udbyderen. For driften kræver det, at sikkerhedsdomænet og dets nøgler opbevares og genoprettes korrekt, ellers kan HSM’en ikke genskabes.

HYOK: nøglen bliver uden for udbyderen

HYOK står for “hold your own key”. Nøglen ligger i en nøgletjeneste, I selv driver eller køber hos en tredjepart uden for udbyderen. Udbyderen skal spørge den eksterne tjeneste, hver gang data skal krypteres eller dekrypteres.

AWS kalder det External Key Store. AWS skriver, at hvis adgangen til den eksterne nøgle afbrydes, kan data ikke dekrypteres, og hvis den tilbagekaldes permanent, er data uigenkaldeligt tabt, bortset fra kortvarigt mellemlagrede nøgler. AWS skriver også selv, at den øgede risiko for tilgængelighed og svartid for de fleste kunder vil overstige den oplevede sikkerhedsgevinst. Google Cloud beskriver en tilsvarende model, External Key Manager, hvor en begrundelse kan sendes med hver anmodning og godkendes eller afvises hos den eksterne partner.

For driften er HYOK den tungeste model. Den eksterne nøgletjeneste bliver en del af produktionen. Er den nede, er de systemer, der bruger den, også nede. Den skal have høj tilgængelighed, overvågning og en procedure for gendannelse.

Hvad modellerne bryder

Jo mindre udbyderen kan læse data, jo færre af udbyderens tjenester kan bruge dem. Microsoft beskriver det præcist for Double Key Encryption i Microsoft 365, hvor indholdet krypteres med en nøgle, som Microsoft ikke har. Ifølge Microsoft er sådanne data ikke tilgængelige for Microsoft 365-tjenester, heller ikke Copilot. SharePoint og OneDrive kan ikke behandle filerne, og Office på nettet, samtidig redigering, eDiscovery, DLP og søgning virker ikke for dem. Funktionen kan ikke bruges til kalender, Teams-møder og chat.

Eksemplet bruges her for at vise mekanismen. Det gælder generelt: en tjeneste, der skal søge, indeksere, analysere eller vise data, skal kunne læse dem. Hvor nøglen holdes uden for udbyderen, mister I de funktioner, der kræver læsning. Det er et valg, der skal træffes pr. datatype.

Sådan vælger I pr. datatype

En brugbar fremgangsmåde er at sortere data i tre grupper. Data, som udbyderens tjenester skal arbejde med, og hvor udbyderens egne nøgler eller BYOK er nok. Data, der kræver stærkere adskillelse, hvor HSM hos udbyderen er et svar. Og endelig de få data, som udbyderen under ingen omstændigheder må kunne læse, hvor HYOK eller kryptering før upload er svaret. Den sidste mulighed står i kryptering før upload.

Hvad det kræver, og hvad det koster at lade være

BYOK kræver en nøgleproces og sikker opbevaring. HSM kræver opbevaring af sikkerhedsdomænet og en gendannelsesprocedure. HYOK kræver en ekstern nøgletjeneste med høj tilgængelighed, overvågning og vagt. Posterne er nøgletjenesten efter forbrug eller fast betaling, eventuel hardware, licens og egne timer. Overslaget gives i uger til opsætning og timer pr. måned til drift.

At lade være betyder, at udbyderen har nøglerne. Det kan være et lovligt valg. Det koster noget, hvis kunder, tilsyn eller jeres egen vurdering kræver, at bestemte data ikke kan læses af udbyderen, og I ikke kan vise, at de er beskyttet.

Det skal I lade være med

  • At vælge HYOK for alt · den eksterne nøgletjeneste bliver et enkelt fejlpunkt for hele produktionen.
  • At importere egen nøgle uden en kopi uden for udbyderen · mistes den, er data tabt.
  • At slå streng nøglekontrol til uden at liste, hvilke funktioner der forsvinder · brugerne opdager det først.

Det skal valget kunne vise

  • ☐ Nøglemodel pr. datatype, med begrundelse.
  • ☐ Hvem der laver, opbevarer og udskifter nøglerne.
  • ☐ Hvilke tjenester der ikke virker med den valgte model.
  • ☐ En testet procedure for gendannelse af nøgler.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Sortér jeres data i de tre grupper, og skriv ud for hver gruppe, hvilken nøglemodel der bruges i dag.

Læs også: Overvågning og logs · Forbindelsen mellem miljøer

→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Overvejer I at flytte infrastruktur til Europa?

Skriv kort, hvilke systemer eller hvilken platform det drejer sig om, og hvad der sætter spørgsmålet i gang. Så vender jeg tilbage. Rådgivningen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.