Grundidé: kryptering er et valg mellem flere behov
Når man vælger krypteringstype, handler det sjældent om at finde “den bedste” algoritme for alle situationer. Det handler i stedet om at matche krypteringen til:
- Hvad der skal beskyttes (netværkstrafik, filer, database, beskeder, nøgler)
- Hvordan data flyder (mens den sendes, mens den lagres, eller begge dele)
- Hvor længe beskyttelsen skal gælde
- Hvilken trussel man primært vil reducere (fx aflytning, manipulation, adgang uden autorisation)
Derudover afhænger resultatet af, hvordan løsningen implementeres. Selv stærk kryptografi kan underperform derfor, hvis nøgler, opsætning eller adgangsrettigheder håndteres forkert.
En enkel model: vælg efter “beskyttelsessted” og “sikkerhedskrav”
Start med at kategorisere data og krav. En enkel måde at tænke på er at skelne mellem tre hyppige mål:
- Kryptering i transit Bruges når data sendes mellem systemer (fx over et netværk). Her vælger man typisk en kryptering, der kombinerer:
- hemmeligholdelse (andre kan ikke læse indholdet)
- integritet og ofte også beskyttelse mod manipulation
-
Kryptering i hvile Bruges når data ligger gemt (fx filer eller databaser). Her er fokus ofte på at begrænse skade ved uautoriseret adgang til lagring—og på at gøre det praktisk at rotere og beskytte nøgler.
-
Kryptering med separat formål: identitet, signatur eller databeskyttelse Nogle behov handler mindre om at skjule indhold og mere om at sikre, at en besked eller et dokument kommer fra den rigtige afsender (autenticitet) og ikke er ændret (integritet). I praksis kan dette kræve andre kryptografiske byggesten end “ren” kryptering.
Hvad du skal kigge efter i algoritmer og opsætning
Uanset om du vælger til transit eller hvile, er der nogle kontrolpunkter, der typisk betyder mere end at vælge et navn på en algoritme:
- Nøglehåndtering: Hvor ligger nøglerne? Hvordan beskyttes de? Hvordan roteres de?
- Parametre og tilstande: Er der valgt robuste standardparametre, eller er der brugt gamle/deaktivérbare indstillinger?
- Implementeringskvalitet: Er løsningen konfigureret korrekt, og er der kendte fejl i den konkrete version?
- Integritetsbeskyttelse: Beskytter løsningen kun mod læsning, eller også mod ændring?
- Kompatibilitet og fallback: Kan systemet falde tilbage til svagere metoder ved problemer? Det kan ændre risikobilledet.
Vigtige undtagelser: Hvis en løsning virker “krypteret” i navnet, men den faktiske nøgle- og konfigurationsstyring er svag, kan sikkerheden være begrænset. Derfor bør du altid vurdere hele kæden fra nøgle til brug.
Forskelle og begrænsninger: hvornår valget kan ændre sig
Dit valg kan ændre sig, når forhold som følgende gør sig gældende:
- Dataernes levetid: Hvis data skal beskyttes i lang tid, skal du vurdere, om kryptografiske valg kan holde til tidens udvikling.
- Trusselens type: Hvis du primært frygter aflytning, vægtes hemmeligholdelse. Hvis du frygter manipulation, vægtes integritet og autentificering højere.
- Adgangsmodeller: Hvis der er mange brugerroller eller systemer, påvirker nøgle- og politikstyring, hvor realistisk beskyttelsen er.
En vigtig begrænsning er, at kryptering ikke fjerner alle risici. Fejl i brugeradfærd, kompromitterede konti, malware, forkert adgangsstyring eller mangelfuld logik kan stadig gøre skade mulig, selv om data er krypteret.
Praktisk brug: sådan kan du selv teste din beslutning
Når du skal vælge type kryptering til en løsning, kan du bruge en hurtig “kontrolliste” før du låser noget fast:
- Hvilken datakategori er det (i transit, i hvile, eller begge)?
- Hvilken sikkerhedsmål er vigtigst (hemmeligholdelse, integritet, autentificering)?
- Hvordan håndteres nøgler (beskyttelse, adgang, rotation)?
- Hvilke konfigurationsvalg kan introducere svagheder (gamle parametre, fallback)?
- Hvad er konsekvensen, hvis noget går galt—og hvor længe skal beskyttelsen gælde?
Hvis du kan svare klart på disse punkter, har du et solidt grundlag for at vælge en krypteringstype, der passer til dit faktiske behov. Hvis du ikke kan, er det et tegn på, at “hvilken algoritme”-spørgsmålet er for snævert, og at nøgle- og sikkerhedskrav bør afklares først.