Teknisk Audit

Kryptering i hvile og under transport: sådan påvises den pr. system

Kryptering i hvile og under transport: sådan påvises den pr. system

Når nogen spørger, om jeres data er krypteret, er det korte svar sjældent rigtigt. Svaret skal gives pr. system: Er data krypteret på disken, i databasen og i backuppen? Er forbindelserne til og fra systemet krypteret? Og hvor ligger beviset?

Artiklen handler om den faktiske opsætning. Politikken for kryptering og reglerne om persondata er andre emner.

Målestokkene

Udgangspunktet er punkt 9.2 i bilaget til forordning (EU) 2024/2690. Efter litra a fastlægger politikken for kryptografi type, styrke og kvalitet af kryptering, “herunder data i hvile og data under overførsel”, efter klassifikation. Litra c kræver nøgleforvaltning, der dækker generering, opbevaring, ændring, tilbagekaldelse, gendannelse, backup, destruktion, logning og datoer for aktivering og deaktivering. Forordningens artikel 1 afgrænser, hvilke digitale tjenesteudbydere den binder. Uden for den kreds af udbydere bruger vi den som målestok, og det er en tolkning.

De statslige minimumskrav har tre konkrete krav, der rører kryptering. Krav 3 er fuld diskkryptering på fysiske klienter. Krav 9 handler om mail med TLS 1.2. Krav 27 er HTTPS med TLS 1.2 eller højere. Kravene binder staten og er en målestok for private virksomheder.

SAMSIK’s TLS-vejledning fra november 2026 deler opsætninger i “God”, “Tilstrækkelig” og “Utilstrækkelig”. Her får TLS 1.3 niveauet “God” og TLS 1.2 niveauet “Tilstrækkelig”, mens ældre versioner falder under “Utilstrækkelig”.

For tjenester i en offentlig sky har CIS AWS Foundations Benchmark, som AWS gengiver kontrollerne for version 5.0.0, punkter om kryptering i hvile af blandt andet databaser, bloklagring og fillagring.

Tabellen

At svaret gives pr. system med bevis, er praksis. Et brugbart format er en tabel med en række pr. system:

  • (Filserver) · I hvile: (Diskkryptering på volumen) · Under transport: (SMB med kryptering) · Nøgler: (I katalog, adgang for to personer) · Bevis: (Udtræk af volumenstatus, dato)
  • (Database til økonomi) · I hvile: (Kryptering i databasen) · Under transport: (Krævet krypteret forbindelse) · Nøgler: (Hos producentens nøgletjeneste) · Bevis: (Skærmbillede af indstilling, dato)
  • (Backup) · I hvile: (Krypteret på mål) · Under transport: (Krypteret overførsel) · Nøgler: (Separat nøglelager) · Bevis: (Jobindstilling, dato)

Eksemplerne i parentes er tænkte. Tabellen viser tre ting ad gangen: hvor kryptering er slået til, hvor den mangler, og hvor ingen ved det.

Kryptering i hvile

For hvert system skal det være klart, hvilket lag der krypterer: disken, volumenet, databasen, filen eller tjenesten i skyen. Det har betydning, fordi lagene beskytter mod forskellige ting. Diskkryptering beskytter mod en stjålet disk, men ikke mod en administrator med adgang til den kørende server. Den forskel er en tolkning af, hvad lagene gør, ikke en regel.

På Windows viser manage-bde -status krypteringsstatus pr. drev. Hos en skyudbyder slås kryptering i hvile til på selve tjenesten, og indstillingen kan aflæses. For backuppen er det en indstilling i jobbet eller på lagermålet. Kontrollen af bærbare er beskrevet for sig i diskkryptering på bærbare.

Kryptering under transport

For hvert system skal det være klart, hvilke forbindelser der er krypteret: brugere til systemet, systemet til databasen, systemet til andre systemer og backupens overførsel. Det almindelige hul er de interne forbindelser. Trafik fra internettet er ofte krypteret, mens trafikken bag den første server går i klartekst.

TLS-versioner og parametre holdes op mod SAMSIK’s niveauer. Certifikater og TLS gennemgås mere detaljeret i certifikater og TLS.

Nøglerne

Bilagets litra c gør nøglerne til et kontrolpunkt for sig. For hvert system er spørgsmålene: Hvor ligger nøglen? Hvem kan hente den? Er der en kopi, så data kan gendannes, hvis nøglen går tabt? Og bliver brugen af nøglen logget?

Et krypteret system, hvis nøgle ligger ved siden af data med samme adgang, er krypteret på papiret. Et krypteret system uden kopi af nøglen kan ikke gendannes. Begge er fund.

Rækkefølgen for de tomme felter

Når tabellen er lavet, er der typisk tre slags tomme felter. Nogle mangler, fordi ingen har undersøgt det. Andre mangler, fordi kryptering ikke er slået til. Og nogle mangler, fordi systemet ikke kan kryptere. Det er praksis at tage dem i den rækkefølge: Undersøg først, slå til, hvor det kan lade sig gøre, og skriv en begrundelse for resten.

Systemer, der ikke kan kryptere, skal have en anden beskyttelse, fx at de står på et adskilt net. Den beslutning hører til i undtagelseslisten med en dato for, hvornår den tages op igen. Bilagets ord om klassifikation giver en prioritering: Systemer med de mest følsomme data tages først.

Hvem der spørger

Spørgsmålet om kryptering kommer fra kunder, revisorer, forsikring og ledelse. Tabellen kan bruges til dem alle. Den almene vinkel på kryptering i en sikkerhedsaudit, med politik og ledelsens del, er beskrevet under sikkerhedsaudit og NIS2.

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

Det kræver en systemliste og en ejer pr. system, der kan vise indstillingen. Det første udkast til tabellen kan driften lave på kort tid, fordi mange svar er kendte. De tomme felter er dem, der tager tid.

Uden tabellen svarer I ja på spørgsmål, I ikke kan bevise. Og de interne forbindelser og nøglerne, som sjældent er med i et hurtigt svar, er netop dem, der afgør, om krypteringen beskytter noget.

Det skal I lade være med

  • At svare ja for hele miljøet · svar pr. system.
  • At glemme de interne forbindelser · trafik bag den første server skal også med.
  • At lægge nøglen ved siden af data · adskil adgang til nøgler og data.

Det skal gennemgangen kunne vise

  • ☐ En tabel pr. system med kryptering i hvile, under transport og nøgler.
  • ☐ Bevis for hver række med dato.
  • ☐ TLS-versioner holdt op mod SAMSIK’s niveauer.
  • ☐ Hvor nøglerne ligger, og hvem der kan hente dem.
  • ☐ En kopi af nøglerne til gendannelse.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Lav tabellen for jeres fem vigtigste systemer, og marker de felter, ingen kan svare på.

Læs også: Bevis for et konfigurationsfund · Nøgler og hemmeligheder i skyen

→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang 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

Skal jeres opsætning gennemgås?

Skriv kort, hvilke dele af miljøet det drejer sig om, og hvad der sætter det i gang. Så vender jeg tilbage. Gennemgangen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.