Teknisk Audit

Nøgler og hemmeligheder i skyen: opbevaring, udløb og hvem der kan hente dem

Nøgler og hemmeligheder i skyen: opbevaring, udløb og hvem der kan hente dem

Langlivede nøgler findes med et udtræk over alle adgangsnøgler med oprettelsesdato og seneste brug. De holdes op mod benchmarkens frister: rotation hver 90. dag eller oftere og at oplysninger til login, som har ligget ubrugt i 45 dage, fjernes. Derefter ser gennemgangen på, hvor nøglerne opbevares, og hvem der kan hente dem.

En adgangsnøgle er en adgangskode, som et program bruger. Den sidder i en konfigurationsfil, et script eller en udrulningskæde, og den bliver sjældent skiftet, fordi ingen ved, hvad der går i stykker, hvis den skiftes. Jo ældre nøglen er, desto flere steder kan den være kopieret hen.

Frister med tal på

De læste tal stammer fra AWS’ gengivelse af CIS’ benchmark for AWS, version 5.0.0. Selve CIS-dokumentet er ikke læst. Andre platformes nøgle- og hemmelighedstjenester har deres egne indstillinger, som ikke er gengivet her.

  • IAM.3 · Krav i CIS v5.0.0: 1.13 · Hvad den måler: Rotation af adgangsnøgler senest hver 90. dag
  • IAM.22 · Krav i CIS v5.0.0: 1.11 · Hvad den måler: Fjernelse af legitimationsoplysninger efter 45 dage uden brug
  • IAM.4 · Krav i CIS v5.0.0: 1.3 · Hvad den måler: Rodbrugeren har ingen adgangsnøgle
  • KMS.4 · Krav i CIS v5.0.0: 3.6 · Hvad den måler: Rotation af nøgler i KMS er slået til
  • IAM.26 · Krav i CIS v5.0.0: 1.18 · Hvad den måler: Udløbne SSL/TLS-certifikater i IAM fjernes

Fristerne er benchmarkens, ikke lovens. Bruger I en anden platform, kan de samme to tal stadig bruges som en målestok, I vælger. Valget skrives i rapporten.

Udtrækket

Første skridt er en liste over alle adgangsnøgler med fire oplysninger: hvilken bruger eller rolle nøglen hører til, hvornår den blev oprettet, hvornår den sidst blev brugt, og om den er aktiv. Det er almindelig praksis at trække listen med platformens egne rapporter over legitimationsoplysninger og gemme den med dato.

Listen sorteres efter alder. De nøgler, der er ældre end 90 dage, er fund efter benchmarken. De nøgler, der ikke er brugt i 45 dage, er fund efter det andet punkt. En nøgle kan være begge dele, og det er de nøgler, der bør tages først.

Hvor nøglerne opbevares

Udtrækket viser, at nøglen findes. Det viser ikke, hvor den ligger. Her bygger gennemgangen på samtaler med udviklere og drift og på en gennemlæsning af de steder, nøgler typisk havner: konfigurationsfiler, udrulningskæder, delte drev og dokumentation. Kontrolpunktet er, at hver nøgle har ét sted, hvor den opbevares, og at det sted har adgangskontrol og log.

Forordning 2024/2690 har en ramme for det, i bilagets punkt 9.2, litra c. Nøgleforvaltningen skal blandt andet omfatte, hvordan nøgler opbevares, og hvordan autoriserede brugere får adgang til dem, regler for hvornår nøgler ændres, håndtering af kompromitterede nøgler, tilbagekaldelse, logning og datoer for aktivering og deaktivering. Bilaget gælder kun de enheder, der står i forordningens artikel 1, fx udbydere af cloud- og datacentertjenester og administrerede tjenester. For andre er det en målestok, man kan vælge. Det er en tolkning, og rapporten bør markere den.

Artikel 7 i den delegerede forordning 2024/1774, som gælder finansielle enheder under DORA, fastslår, at krypteringsnøgler forvaltes gennem hele livscyklussen, og at der skal være metoder til at udskifte dem ved tab eller kompromittering. Andre kan bruge kravet som målestok.

Hvem kan hente nøglerne

Det tredje spørgsmål er adgangen. Ligger nøglerne i en tjeneste til hemmeligheder, gennemgås rettighederne til tjenesten på samme måde som andre privilegerede roller: hvem kan læse, hvem kan ændre, og logges det, når en hemmelighed hentes? Ligger de i en udrulningskæde, gennemgås, hvem der kan se kædens variabler. Udrulningskæden har sin egen artikel: kildekodeplatform og udrulningskæde.

Når en nøgle skal skiftes

En nøgle, der skal skiftes, er ofte en nøgle, ingen tør røre. Den sikre vej er almindelig praksis: opret en ny nøgle, sæt den ind de steder, den bruges, deaktivér den gamle, vent, se om noget fejler, og slet den gamle til sidst. Fejler et job, når den gamle er deaktiveret, har I fundet et sted, nøglen blev brugt, som ingen kendte. Det fund er i sig selv en vigtig oplysning til listen.

Rotation af nøgler i KMS er en anden sag. Den slås til som en indstilling, og KMS.4 måler, om den er det.

Certifikater i IAM

IAM.26 handler om udløbne SSL/TLS-certifikater, der er lagt i IAM. Kontrolpunktet er enkelt: findes der udløbne certifikater, og hvem ejer dem? Et udløbet certifikat, der bliver liggende, viser, at ingen har opgaven med at rydde op. Listen trækkes sammen med nøglerne og gemmes med dato, så næste gennemgang kan se, om oprydningen er sket.

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

Udtrækket tager kort tid. At finde ud af, hvor hver nøgle bruges, tager længere, fordi det kræver samtaler med dem, der har bygget løsningerne. Planlæg skiftet af de ældste nøgler som små ændringer med en vej tilbage.

Uden gennemgangen lever nøgler, så længe kontoen lever. En nøgle, der blev lagt i et script for fem år siden, kan stadig give adgang, og ingen kan sige, hvem der har en kopi.

Det skal I lade være med

  • At slette en gammel nøgle uden at deaktivere den først · et ukendt job kan stoppe uden varsel.
  • At lægge nøgler i konfigurationsfiler, der ligger i kildekoden · brug ét sted med adgangskontrol og log.
  • At skrive benchmarkens 90 dage som et lovkrav · tallet er CIS’, som AWS gengiver det.

Det skal gennemgangen kunne vise

  • ☐ En liste over alle adgangsnøgler med oprettelse, seneste brug og status.
  • ☐ Nøgler over 90 dage gamle og oplysninger, der har ligget ubrugt i over 45 dage.
  • ☐ Hvor hver nøgle opbevares, og hvem der kan hente den.
  • ☐ Status for nøglerotation i KMS og for udløbne certifikater.
  • ☐ En plan for skift af de ældste nøgler med ejer og dato.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Træk listen over adgangsnøgler, sortér den efter alder, og find ejeren af de fem ældste.

Læs også: Gennemgang af et AWS-miljø · Servicekonti

→ 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.