Nøglehåndtering

Også kendt som: håndtering af kryptografiske nøgler

At passe på kryptografiske nøgler gennem hele deres levetid - at skabe, gemme, udlevere, skifte og til sidst destruere dem.

Kladde - dette opslag er endnu ikke gennemgået.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

Lav en oversigt over alle nøgler og certifikater - krypteringsnøgler, signeringsnøgler, TLS- og SSH-nøgler, API-nøgler og nøgler i HSM eller KMS - med ejer, formål, algoritme, placering og udløbsdato.
Skriv en politik for nøglehåndtering, der fastsætter godkendte algoritmer og nøglelængder, en kryptoperiode for hver nøgletype, hvem der må oprette, bruge og destruere nøgler, og hvor ofte hver nøgle skiftes.
Flyt nøglerne ind i et hardware security module eller en cloud-KMS, generér dem dér fra en stærk tilfældighedskilde, og fjern nøgler fra kildekode, konfigurationsfiler og container-images.
Brug envelope encryption, hvor datanøgler er pakket ind i en hovednøgle, der aldrig forlader KMS eller HSM, og giv kun applikationer ret til at bruge en nøgle, ikke til at eksportere eller slette den.
Kræv dobbeltkontrol eller delt viden for de mest værdifulde nøgler, fx rod-CA- og hovednøgler, og dokumentér hver nøgleceremoni med vidner og log.
Slå automatisk nøgleskift til, hvor platformen understøtter det, og tag backup af dekrypteringsnøgler til arkiverede data et separat, beskyttet sted, mens signeringsnøgler ikke deponeres.
Skriv og afprøv mindst en gang om året en procedure for en lækket nøgle - tilbagekald den, udsted en ny, genkryptér eller gensignér det nødvendige, og underret de berørte.
Log al brug og administration af nøgler, alarmér ved usædvanlig brug og ved nøgler, der snart udløber, og destruér udfasede nøgler på en dokumenteret måde, når ingen data længere afhænger af dem.

Typiske faldgruber

At opbevare nøgler på samme server eller i samme kodearkiv som de data eller den kode, de beskytter.
Ikke at have en liste over nøgler og certifikater, så ingen opdager, at en udløber eller er lækket, før en tjeneste holder op med at virke.
At destruere eller udskifte en nøgle, mens backup eller arkiver stadig afhænger af den, så de data bliver ulæselige for altid.

Gode vejledninger

Overgangen til kvantesikker kryptografi(åbner i en ny fane) · Styrelsen for Samfundssikkerhed
NIST SP 800-57 Part 1 Rev. 5 - Recommendation for Key Management(åbner i en ny fane) · NIST (på engelsk)
Key Management Cheat Sheet(åbner i en ny fane) · OWASP (på engelsk)
Key rotation - Cloud Key Management Service(åbner i en ny fane) · Google (på engelsk)

Teknisk uddybning

Referencerammen er NIST SP 800-57 Part 1 Rev. 5 (maj 2020). Den beskriver en nøgles liv som en række tilstande, fx pre-activation, active, suspended, deactivated, compromised og destroyed, og knytter hver overgang til en autoriseret handling. Centralt står kryptoperioden: det tidsrum, hvor en nøgle må bruges, som for symmetriske nøgler deles i en periode, hvor den må beskytte nye data, og en periode, hvor den stadig må dekryptere eller verificere gamle data. Kryptoperioder vælges ud fra algoritmens styrke, mængden af beskyttede data, nøglens eksponering og omkostningen ved nøgleskift, ikke ud fra en fast kalenderregel.

Arkitektonisk bruger næsten alle større systemer et nøglehierarki med envelope encryption. Data krypteres med datakrypteringsnøgler (DEK), som kun gemmes sammen med data i indpakket form, krypteret under en nøglekrypteringsnøgle (KEK), der aldrig forlader et hardwaresikkerhedsmodul (HSM) eller en cloud-KMS. At skifte KEK betyder så at pakke små DEK'er om i stedet for at genkryptere terabytes, og destruktion af en KEK gør alle data under den uoprettelige, hvilket er grundlaget for crypto-shredding ved sletning. HSM'er valideres efter FIPS 140-3 (sikkerhedsniveau 1 til 4, hvor niveau 3 og 4 tilføjer fysisk reaktion på manipulation og identitetsbaseret autentificering), og applikationer tilgår dem via PKCS#11, KMIP (OASIS) eller en cloududbyders API. I cloud spænder varianterne fra udbyderstyrede nøgler over kundestyrede nøgler til BYOK og hold-your-own-key, og forskellen på, hvem der teknisk kan bruge nøglen, har betydning for vurderinger af overførsler efter databeskyttelsesforordningen og for krav om suverænitet.

Kontroller for særligt værdifulde nøgler omfatter delt viden og dobbeltkontrol (ingen enkeltperson kan genskabe eller bruge nøglen, ofte implementeret som M-af-N-nøgleandele, fx med Shamirs secret sharing), dokumenterede nøgleceremonier med vidner og video for CA-rodnøgler, adskillelse af nøgleforvalterrollen fra systemadministration og manipulationssikre auditlogs over al brug. Backup og deponering skal designes bevidst: en signeringsnøgle bør som regel ikke deponeres, da kopier svækker uafviseligheden, mens en dekrypteringsnøgle til arkiverede data skal kunne genskabes, ellers er data tabt.

Revisioner kobler typisk denne praksis til ISO/IEC 27001:2022 Annex A kontrol 8.24 (brug af kryptografi), som forventer regler for hele nøglens livscyklus, og til PCI DSS krav 3 for kortholderdata. Hyppige fejl i praksis er nøgler hardkodet i kildekode eller containerimages, nøgler lagret på samme vært eller volumen som de data, de beskytter, manglende overblik over hvilke nøgler og certifikater der findes (så ingen opdager, når ét udløber eller lækker), og ingen afprøvet procedure for nødudskiftning. Overgangen til post-kvante-algoritmer har gjort en kryptografisk fortegnelse til en selvstændig nøglehåndteringsopgave. Nøglehåndtering er bredere end håndtering af hemmeligheder: sidstnævnte gemmer og udleverer legitimationsoplysninger til workloads, mens nøglehåndtering styrer generering, styrke, levetid og destruktion.

Hvad du bør lære først

Alt det, dette bygger på - grundlaget først.

Kryptografisk nøgle
→Kryptering
→Nøglehåndtering

Relationer

Forudsætter: Kryptografisk nøgle Kryptering
Afbøder: Databrud
Bruges sammen med: Håndtering af hemmeligheder (secrets management)Offentlig nøgleinfrastruktur (PKI)

Kilder og videre læsning

Standarder og officielle tekster

NIST SP 800-57 Part 1 Rev. 5 - Recommendation for Key Management · NIST

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøen Foreslå en rettelse på GitHub Dette begreb som JSON

Test dig selv

Indlæser…