Et softwareprodukt lever af hemmeligheder: API-nøgler, databaseadgange, certifikater og adgangskoder til cloudkontoen. I mange små teams ligger de spredt i koden, i pipelinen, på udviklernes maskiner og i gamle beskeder. Det virker fint, indtil en udvikler stopper, et repository bliver delt med en ny leverandør, eller en nøgle slipper ud. Løsningen er overskuelig. Find hemmelighederne, flyt dem til ét sted, giv dem en ejer, og øv jer i at udskifte dem. Rækkefølgen betyder noget, for en nøgle, der først er lækket, skal skiftes, uanset hvor I flytter den hen.
Hvor nøglerne typisk ligger
Bed lead developeren gennemgå disse steder. Regn med at finde noget.
- I koden og i historikken. Filer med konfiguration, testscripts og eksempler. Sletter I en nøgle i dag, ligger den stadig i versionshistorikken.
- I pipelinen. Variabler i byggeværktøjet, logs fra gamle kørsler og scripts, der skriver værdier ud.
- I frontend og mobilapps. Alt, der sendes til brugerens browser eller telefon, kan læses af brugeren. En nøgle dér er offentlig. Eftersyn af AI-genereret kode beskriver netop den svaghed.
- På udviklernes maskiner. Lokale filer med produktionsadgang og delte adgangskoder.
- I chat, mail og wiki. Beskeder som “her er adgangen til databasen” lever længere, end nogen tror.
- I logs og fejlrapporter. Værdier, der uforvarende skrives ud, og som ender hos en overvågningstjeneste.
- Hos leverandører. Tidligere freelancere og udviklingshuse, der stadig har kopier.
Sådan flyttes de ud
Lav først en oversigt. Hvilke hemmeligheder findes, hvad åbner de, hvem ejer dem, hvem kender dem, og hvornår blev de sidst skiftet? Selve værdierne hører aldrig hjemme i oversigten. Den er en del af det tekniske ejerskab, som er beskrevet i ejerskab af kode og konti.
Vælg ét sted. En hemmelighedsboks, på engelsk secrets manager, er et system, der opbevarer nøgler krypteret, styrer adgangen og logger brugen. Cloududbyderne har en, og der findes selvstændige produkter. Valget betyder mindre, end at der er ét sted. Produktet henter nøglerne, når det kører, og de ligger aldrig i koden.
Giv hvert miljø sine egne nøgler. Test og produktion må ikke dele hemmeligheder. Ellers kan en lækage i et testmiljø åbne for kundernes data, og en udvikler kan ved en fejl ramme produktionen.
Sæt en automatisk kontrol ind. Værktøjer kan scanne koden, før den kommer ind i repository, og pipelinen kan stoppe, hvis der dukker noget op. Scan også historikken en gang, så I ved, hvad der allerede ligger dér.
Skær rettighederne ned. En nøgle skal kunne det, den skal bruges til, og intet andet. Den nøgle, pipelinen bruger, behøver næsten aldrig fuld adgang til hele cloudkontoen. Hvor det kan lade sig gøre, er kortlivede nøgler, der udstedes til den enkelte kørsel, bedre end faste. OWASP’s vejledning om håndtering af hemmeligheder gennemgår de tekniske muligheder.
Når en nøgle er lækket
Behandl den som brugt af andre. At slette den fra koden eller historikken hjælper ikke, for den kan være kopieret. Arbejdet foregår i denne rækkefølge:
- Udsted en ny nøgle.
- Skift den i produktet, og bekræft, at alt virker.
- Luk den gamle.
- Læs loggen for at se, om nøglen er brugt af nogen, den ikke burde bruges af.
- Vurder, om det er en hændelse, som andre skal have besked om, og hvem der tager den beslutning. Sikkerhedshændelser på virksomhedsniveau hører til dem, der ejer sikkerhedsledelsen, se de første timer efter en hændelse.
Skift dem, før I skal
Den svære del viser sig først, når nøglen skal skiftes. Er den brugt mange steder, ved ingen, hvad der går i stykker. Derfor er en planlagt udskiftning den bedste test. Vælg en vigtig nøgle, skift den i et aftalt vindue, og mål, hvor lang tid det tager. Tager det en hel dag, ved I, hvad der skal forbedres.
Nøgler i personers navne er en særlig risiko. En automatik, der kører på den tidligere CTO’s konto, stopper den dag, kontoen lukkes. Brug servicekonti, der tilhører virksomheden. Skal nogen stoppe brat, står rækkefølgen i CTO’en skal stoppe med det samme.
Spørgsmål, ledelsen kan stille
- Ville vi kunne skifte alle produktionsnøgler i løbet af en dag?
- Hvem har stadig adgang, som ikke længere arbejder her?
- Hvor mange personer kan nå produktionsdatabasen?
- Står nogen vigtig automatik i en enkelt medarbejders navn?
- Ved vi, hvornår de vigtigste nøgler sidst blev skiftet?
Det skal I lade være med
- At dele nøgler i chat eller mail · brug hemmelighedsboksen, også når det haster.
- At tro, at et privat repository er et sikkert sted · alle med adgang nu og tidligere har set indholdet.
- At nøjes med at slette en lækket nøgle fra koden · den skal udskiftes.
- At bruge samme nøgle i test og produktion · det binder to risici sammen.
Det skal I kræve af den eksterne
- ☐ En oversigt over hemmeligheder uden værdierne, med ejer og dato for sidste skift.
- ☐ Ét godkendt sted til opbevaring.
- ☐ Automatisk scanning, før kode kommer ind i repository.
- ☐ Adskilte nøgler for test og produktion.
- ☐ En prøvet fremgangsmåde for udskiftning.
Kilder
- OWASP Secrets Management Cheat Sheet: praksis for opbevaring, udskiftning og pipeline.
Senest gennemgået: november 2026.
Næste skridt
Læs også: CTO’en har sagt op: de første 30 dage · Sikker softwareudvikling i et lille team
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
