Cloudmiljøer kører på hemmeligheder. Integrationer har adgangsnøgler, programmer har forbindelsesstrenge til databaser, og automatisering har legitimationsoplysninger til at hente og skrive data. Når en test i Azure eller AWS når et resultat, der ser alvorligt ud, kan vejen gå gennem en hemmelighed, der lå et sted, hvor flere kunne læse den. Svaret på, hvad I gør, hviler på to spørgsmål, som både Microsoft og AWS bygger deres anbefalinger op omkring: kan hemmeligheden undgås helt, og hvis ikke, ligger den så et sted, der er bygget til at beskytte den?
Hvad en hemmelighed er i cloud
I cloud er en hemmelighed alt, der giver adgang uden at nogen skal logge ind: adgangsnøgler til lagerkonti, nøgler til programmeringsgrænseflader, adgangskoder til databaser, certifikater med private nøgler og legitimationsoplysninger til tjenestekonti. Hemmeligheden virker for den, der har den, uanset hvem det er.
Det adskiller hemmeligheder fra almindelige brugerkonti. En medarbejder har tofaktor og logger ind fra en kendt enhed. En nøgle i en konfigurationsfil har ingen af delene. Derfor er spørgsmålet ikke kun, om nøglen er stærk, men hvem der kan læse den.
Samme fundtype findes i det lokale miljø, hvor adgangskoder ligger i scripts og filer. → Adgangskoder i scripts og konfigurationsfiler
Hvor testen finder dem
En test i cloud kan finde hemmeligheder disse steder:
- Programindstillinger · forbindelsesstrenge og nøgler skrevet direkte ind i indstillingerne for webapps og funktioner, hvor alle med læseadgang til ressourcen kan se dem.
- Skabeloner og udrulningsfiler · værdier, der blev brugt ved oprettelsen og stadig står i filerne.
- Virtuelle maskiner · filer og scripts på maskinerne med nøgler til andre tjenester.
- Automatiseringskonti og planlagte job · tjenestekonti med legitimationsoplysninger, der aldrig udløber.
- Nøglebokse med brede rettigheder · central opbevaring, men hvor for mange kan læse indholdet.
Det sidste punkt er værd at bemærke. At bruge en nøgleboks er ikke nok i sig selv. Spørgsmålet er, hvem der kan læse den. En nøgleboks, hvor alle udviklere og en håndfuld leverandører kan læse produktionens hemmeligheder, flytter blot problemet fra en fil til en tjeneste.
Første princip: undgå hemmeligheden
Microsoft beskriver administrerede identiteter som en måde at fjerne behovet for, at nogen skal håndtere legitimationsoplysninger. En tjeneste i Azure får sin egen identitet i Entra ID, og den identitet får rettigheder til de ressourcer, tjenesten skal bruge. Der er ingen nøgle at lække, fordi der ingen nøgle er. Microsoft skriver selv, at manuel håndtering af hemmeligheder og certifikater er en kendt kilde til sikkerhedsproblemer og nedbrud.
I AWS er tankegangen den samme. AWS anbefaler selv, at adgang til AWS-tjenester styres med rettighedssystemet IAM, og at Secrets Manager bruges til de hemmeligheder, der ikke kan undgås. Detaljerne hører til i en AWS-test. → Rettigheder i AWS
For IT-afdelingen er det første spørgsmål efter et fund derfor ikke “hvor skal nøglen ligge?”, men “kan tjenesten bruge sin egen identitet i stedet?”. Svaret kan være ja for nyere tjenester og nej for ældre integrationer og tredjepartsprodukter. Hvor svaret er nej, kan det være et krav at stille til leverandøren ved næste opdatering eller fornyelse af aftalen.
Andet princip: opbevar dem centralt og snævert
Hvor en hemmelighed ikke kan undgås, skal den ligge i en tjeneste, der er bygget til formålet. I Azure er det Key Vault, i AWS fx Secrets Manager. AWS beskriver, at faste legitimationsoplysninger i programkode kan erstattes af et opslag i tjenesten, når de skal bruges, og at hemmeligheder kan udskiftes automatisk efter en tidsplan.
Microsofts anbefalinger for Key Vault kan sammenfattes på begrebsniveau:
- Én nøgleboks pr. program og miljø · så produktion, test og udvikling er adskilt, og et brud ikke rækker på tværs.
- Rollebaseret adgang · frem for de ældre adgangspolitikker, som Microsoft fraråder til kritiske data.
- Mindst mulig adgang · få administratorer og tidsbegrænsede administrative rettigheder.
- Begrænset netværksadgang · så nøgleboksen ikke kan nås fra hele internettet.
- Logning og alarmer · så det kan ses, hvem der hentede hvad.
- Beskyttelse mod sletning · så hemmeligheder kan genskabes, hvis de slettes ved en fejl eller med vilje.
- Automatisk udskiftning · så nøgler ikke lever for evigt.
Når testen har fundet en hemmelighed
En hemmelighed, testeren har kunnet læse, skal betragtes som kendt af andre. Det gælder også, selvom ingen tegn tyder på misbrug. Rækkefølgen er:
- Find brugerne · hvilke systemer bruger hemmeligheden? Uden svaret stopper noget, når den skiftes.
- Skift hemmeligheden · og opdater brugerne. Microsoft fremhæver, at en mistænkt nøgle bør udskiftes, og afhængige tjenester flyttes, før den gamle slås fra.
- Flyt den eller fjern den · til en nøgleboks eller over på en identitet.
- Tjek logs · se, om hemmeligheden er brugt fra uventede steder, i den periode logningen dækker.
- Stram adgangen · så færre kan læse indstillinger og nøglebokse. → Roller i Azure
Læg hvert trin i opgavesystemet med en ejer. Skift af hemmeligheder kan kræve koordinering med leverandører og projekter. → Fra fund til opgave
Det, testen skal have med
- Udgangspunkt · fx en konto med en udviklers læseadgang eller en tjenesteidentitet, så testen viser, hvad en realistisk rolle kan se.
- Oversigt over nøglebokse · med ejer og hvilke programmer de betjener.
- Kendte integrationer · leverandører og systemer, der bruger faste nøgler i dag.
- Aftale om fund · hvem testeren straks skal kontakte, hvis en hemmelighed til et produktionssystem bliver fundet, så den kan skiftes, mens testen står på.
Den sidste aftale er vigtig. En hemmelighed, der giver adgang til betalingsdata eller kundedata, bør ikke vente på den endelige rapport.
Det skal I lade være med
- At flytte nøglen til en nøgleboks uden at skifte den. Den har allerede været synlig.
- At give alle udviklere læseadgang til produktionens nøgleboks. Adskil miljøerne.
- At bruge én nøgleboks til alt. Et brud rækker så til alle programmer.
- At gemme hemmeligheder i skabeloner. De lever videre i versionshistorikken.
- At skifte en nøgle uden at kende afhængighederne. Integrationer stopper uden varsel. → Rettelser uden nedetid
Hvad kan og ikke kan konkluderes
Testen viser, hvilke hemmeligheder testeren kunne finde og læse fra udgangspunktet, og hvad de gav adgang til, på testtidspunktet. Den kan ikke garantere, at der ikke findes andre hemmeligheder andre steder, fx i kode hos en leverandør eller på medarbejderes egne maskiner. Og den kan ikke vise, om en fundet hemmelighed tidligere er misbrugt, uden en særskilt undersøgelse af logs.
Tjekliste efter fund om hemmeligheder
- ☐ Er fundne hemmeligheder skiftet?
- ☐ Er det undersøgt, om tjenesterne kan bruge egne identiteter?
- ☐ Ligger de resterende hemmeligheder i en nøgleboks?
- ☐ Er nøglebokse adskilt pr. program og miljø?
- ☐ Er læseadgangen til nøgleboksene begrænset?
- ☐ Er logning og beskyttelse mod sletning slået til?
Kilder
- Microsoft Learn: Secure your Azure Key Vault: én nøgleboks pr. program og miljø, rollebaseret adgang frem for adgangspolitikker, administrerede identiteter, netværksbegrænsning, logning, beskyttelse mod sletning, automatisk udskiftning og udskiftning af mistænkte nøgler.
- Microsoft Learn: Managed identities for Azure resources: administrerede identiteter fjerner behovet for at håndtere legitimationsoplysninger, manuel håndtering som kendt kilde til problemer.
- AWS: What is AWS Secrets Manager?: erstatning af faste legitimationsoplysninger i kode og automatisk udskiftning efter tidsplan.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: API-nøgler og integrationskonti · Lagerkonti og databaser i Azure
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
