Gå til indhold
atlas

Håndtering af hemmeligheder (secrets management)

Også kendt som: secrets management

At holde de adgangskoder, nøgler og tokens, som programmer bruger, i ét bevogtet lager i stedet for spredt i kode og filer.

Kladde - dette opslag er endnu ikke gennemgået.

Formelt

Praksis og værktøjer til at opbevare, udlevere, udskifte og tilbagekalde maskiners loginoplysninger - fx adgangskoder, kryptografiske nøgler og adgangstokens - fra et centralt, krypteret lager med adgangskontrol og en log over al brug.

Forklaret enkelt

Som en hotelreception, der kun udleverer værelsesnøgler til de rette gæster, noterer, hvem der tog hvilken nøgle, og straks kan spærre en mistet - i stedet for nøgler gemt under dørmåtten.

I praksis

I en pensionskasse holder udviklerne op med at skrive databasens adgangskode ind i programmets kode og lægger den i et centralt lager til hemmeligheder; programmet henter den ved opstart, og lageret skifter den automatisk hver måned.

Hvorfor det betyder noget

Adgangskoder og nøgler, der ligger i kode eller delte filer, er lette for angribere at finde og svære at skifte, når de er lækket; et bevogtet lager begrænser og registrerer, hvem der kan bruge dem.

Teknisk uddybning

Området dækker maskiners loginoplysninger: databaseadgangskoder, API-nøgler, OAuth client secrets, private TLS-nøgler, SSH-nøgler, signeringsnøgler og adgangsnøgler til cloud. Det overlapper med, men er forskelligt fra, nøglehåndtering, hvor en KMS eller HSM udfører de kryptografiske operationer, og nøglen aldrig forlader grænsen, og fra password managers til mennesker. Udbredte værktøjer er HashiCorp Vault (omlicenseret under Business Source License i 2023, hvilket førte til forken OpenBao), AWS Secrets Manager, Azure Key Vault og Google Secret Manager. Kubernetes Secrets er kun base64-kodede og gemmes ukrypteret i etcd, medmindre kryptering af hvilende data er sat op via en EncryptionConfiguration, helst med en KMS-provider.

Lagrene beskytter hemmelighederne med envelope encryption: en datanøgle pr. hemmelighed eller pr. lager, pakket ind af en nøglekrypteringsnøgle i en KMS eller HSM. Vault krypterer sin storage barrier med en rodnøgle, som selv er beskyttet af unseal-nøgler delt med Shamirs metode eller af auto-unseal via en cloud-KMS. Klienter autentificerer sig med en platformsidentitet (et Kubernetes service account-token, en AWS IAM-rolle, et OIDC-JWT fra en CI-pipeline) og får et token knyttet til politikker; hemmelighederne udleveres med lease og TTL. Dynamiske hemmeligheder går videre: Vaults database secrets engine opretter en unik databasebruger pr. forespørgsel og sletter den, når leasen udløber, så en lækket loginoplysning dør af sig selv, og hver brug kan spores. Statiske hemmeligheder skal i stedet roteres; AWS Secrets Manager bruger en rotationsfunktion og staging-labels AWSPENDING, AWSCURRENT og AWSPREVIOUS, så gamle og nye loginoplysninger overlapper under skiftet.

Fejlene handler mest om hemmeligheder, der slipper ud af lageret: hardkodede loginoplysninger (CWE-798), hemmeligheder committet til Git (sletning i et senere commit efterlader dem i historikken), bagt ind i lag i container-images, skrevet ud i CI-logs, dumpet med miljøvariabler i crash-rapporter eller gemt i klartekst i Terraform-state. Scannere som gitleaks og TruffleHog samt GitHubs secret scanning med push protection fanger mange af dem. Den rigtige reaktion på et læk er først at tilbagekalde og rotere og først derefter rense historikken. Alle løsninger står desuden over for secret zero-problemet: den første loginoplysning, der bruges til at nå lageret, skal komme et troværdigt sted fra.

Retningen i dag er helt at fjerne statiske hemmeligheder via workload identity federation, hvor et CI-job veksler sit OIDC-token til kortlivede cloud-loginoplysninger (fx AWS STS AssumeRoleWithWebIdentity), SPIFFE/SPIRE-workload-identiteter og kortlivede certifikater. Relevante referencer er NIST SP 800-57 del 1 om nøglers livscyklus og kryptoperioder, ISO/IEC 27001:2022 bilag A 5.17 (autentifikationsinformation) og 8.24 (brug af kryptografi) samt OWASP Secrets Management Cheat Sheet.

Hvad du bør lære først

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

  1. Kryptografisk nøgle
  2. →Digital identitet
  3. →Tjeneste (service)
  4. →Loginoplysning (credential)
  5. →Servicekonto
  6. →Håndtering af hemmeligheder (secrets management)

Relationer

Implementerer
Mindste privilegium
Afbøder
Databrud

Kilder og videre læsning

Standarder og officielle tekster

  • NIST SP 800-190 - Application Container Security Guide · NIST

Opslagsværker

  • CSA Cloud Controls Matrix (CCM) · Cloud Security Alliance

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øenForeslå en rettelse på GitHubDette begreb som JSON

Test dig selv

Indlæser…

Atlas er i beta.