Lækkede API‑nøgler og tokens: dokumentation af misbrug

Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen

En lækket API-nøgle eller et adgangstoken skal dokumenteres med to tidslinjer: eksponeringen, dvs. hvor og hvornår nøglen blev tilgængelig for uvedkommende, og brugen, dvs. hvornår og hvordan nøglen blev brugt af andre end de systemer, den var udstedt til. Eksponeringen findes typisk i kodeplatformens historik og auditlog. Brugen findes i den tjenestes logs, nøglen giver adgang til. Inden nøglen roteres, skal dens id, rettigheder og seneste brug dokumenteres, fordi oplysningerne kan forsvinde, når nøglen slettes.

Haster det? API-logs hos SaaS-tjenester gemmes ofte kort, og oplysninger om seneste brug forsvinder med nøglen, når den roteres. Se akut forensisk sikring; hastesager koster ekstra.

Nøgler, tokens og deres levetid

Typen af hemmelighed afgør, hvor længe et læk har betydning, og hvor brugen kan ses:

Statisk API-nøgle · Gyldig til den roteres; brug logges pr. nøgle-id
Adgangsnøgle til cloudkonto · Gyldig til den deaktiveres; kald logges med nøglens id
Personligt adgangstoken på en kodeplatform · Gyldig til udløb eller tilbagekaldelse; brug ses i platformens auditlog
Delt adgangssignatur til lagring · Gyldig til udløbstidspunktet i signaturen; kan ikke altid tilbagekaldes enkeltvis
Kortlivet token · Udløber typisk inden for minutter eller timer

En statisk nøgle, der har ligget offentligt i måneder, har en lang mulig misbrugsperiode, og hele perioden skal undersøges. Et kortlivet token, der er lækket i en log, kan kun have været brugt i et kort vindue efter udstedelsen. Notér for hver nøgle, hvilken type den er, og hvad det betyder for den periode, der skal dækkes.

Hvor nøgler typisk lækker

Kildekode, særligt i offentlige repositorier, også når nøglen er fjernet i en senere commit, fordi den stadig ligger i historikken,
konfigurationsfiler i containerbilleder, backups eller arkiver, der er delt, fx i en bucket med offentlig adgang, → Eksponeret lagring: hvem tilgik dataene?
klientkode, fx en webapplikation eller app, hvor en nøgle er indlejret og kan læses af enhver,
logs og fejlmeddelelser, der skriver nøglen ud,
byggesystemer, hvor hemmelige variabler skrives i byggeloggen, → CI/CD-logs og testdokumentation
tickets, chats og dokumentation, hvor nøglen er indsat for at hjælpe en kollega.

Eksponeringen: hvornår blev nøglen tilgængelig?

Git-historikken

En commit har to tidsstempler, forfatter- og committertid, og begge sættes af den maskine, der laver commit. De kan derfor være forkerte eller ændret. Commit-historikken viser, hvornår nøglen blev skrevet ind i koden ifølge udviklerens maskine, men ikke hvornår den blev offentlig. → Git og kildekode som bevis

Platformens auditlog

Kodeplatformens auditlog er mere pålidelig, fordi den skrives af platformen. Den kan vise, hvornår en commit blev skubbet til platformen, hvornår et repositorium skiftede fra privat til offentligt, hvornår det blev forket, og hvornår platformens egen hemmelighedsscanning eventuelt fandt nøglen. Eksponeringen begynder ved det tidligste af disse tidspunkter, hvor nøglen var både skubbet og offentlig. → GitHub, GitLab og Azure DevOps: auditlogs

For offentlige repositorier kan platformen normalt ikke vise, hvem der har læst eller klonet indholdet. Antallet af kloner kan i nogle tilfælde ses, men ikke identiteten. På GitHub kan de, der har skriveadgang til repositoriet, se antal kloner og besøg for de seneste 14 dage, og ældre trafikdata skal være gemt løbende for at kunne bruges. Det betyder, at en nøgle i et offentligt repositorium skal betragtes som kompromitteret fra det øjeblik, den blev offentlig, uanset om misbrug kan ses.

Andre kilder

For nøgler i klientkode er eksponeringstidspunktet den dato, hvor versionen med nøglen blev udgivet. For nøgler i logs er det tidspunktet, hvor loggen blev tilgængelig for andre, fx delt med en leverandør. Angiv for hver kilde, hvor sikker dateringen er.

Brugen: hvornår blev nøglen misbrugt?

Brugen findes i den tjeneste, nøglen giver adgang til. De fleste cloud- og SaaS-tjenester logger API-kald med den nøgle eller identitet, der blev brugt:

Cloudplatforme logger kald med nøglens id, tidspunkt, kilde-IP, brugeragent, region og handling. → AWS CloudTrail i undersøgelser
SaaS-tjenester som betalings-, mail- og kommunikationsplatforme har ofte en API-log eller en oversigt over seneste brug pr. nøgle, med kortere opbevaring.
Egne API’er logger i webserverens og applikationens logs, hvis nøglen er en, virksomheden selv har udstedt.

Misbrug ses typisk som:

kald fra IP-adresser og brugeragenter, der ikke passer med de systemer, nøglen er udstedt til,
kald, der kortlægger, hvilke rettigheder nøglen har, kort efter eksponeringen,
brug af nye regioner eller tjenester, fx oprettelse af maskiner eller hentning af data i store mængder,
kald på tidspunkter, hvor de legitime systemer ikke kører.

Sammenhold det første fremmede kald med eksponeringstidspunktet. Et kort tidsrum mellem de to er typisk for automatiseret søgning efter lækkede nøgler. Har nøglen givet adgang til lagring, skal adgang til objekterne undersøges særskilt. → Objektlager: adgangslogs og versionering

Sikring før rotation

Rotation er nødvendig og haster, men den bør ske i en rækkefølge, der bevarer sporene:

Notér nøglens id eller fingeraftryk, aldrig selve hemmeligheden, sammen med oprettelsestidspunkt, ejer, rettigheder og oplysning om seneste brug.
Eksportér tjenestens logs for nøglen for hele perioden fra eksponering til i dag.
Eksportér kodeplatformens auditlog og den relevante historik.
Rotér eller tilbagekald nøglen, og notér tidspunktet.
Eksportér logs igen efter rotationen for at vise, at nøglen ikke længere virker, og for at fange forsøg på at bruge den.

Fjern også nøglen fra historikken, hvor det er muligt, men først efter sikringen, fordi omskrivning af historikken ændrer commits og hashværdier. Notér, hvad der er omskrevet.

Hemmeligheder i rapporten

Rapporten må ikke indeholde selve nøglen. Brug nøglens id, de første og sidste få tegn eller en hashværdi af nøglen, så den kan genkendes uden at blive genbrugt. Det samme gælder bilag: Skærmbilleder og logudtræk, der viser nøglen, skal maskeres i en kopi, mens den umaskerede original opbevares med begrænset adgang.

Tidslinjen

Saml de to tidslinjer i én: tidspunktet, hvor nøglen blev skrevet ind, skubbet og blev offentlig; tidspunktet for hemmelighedsscanningens eller en tredjeparts advarsel; det første fremmede kald og de efterfølgende handlinger; tidspunktet for rotation; og eventuelle forsøg efter rotation. Angiv for hver post kilden og om tidspunktet er sat af platformen eller af en brugers maskine. Tidslinjen viser, hvor længe nøglen var udsat, og hvor hurtigt den blev brugt, og det er ofte det, der får betydning i en tvist om ansvar.

Fejlkilder

Fælles nøgler: En nøgle, der bruges af flere systemer, gør det svært at skelne legitim fra fremmed brug.
Udgående adresser hos cloudtjenester: Legitime systemer kan skifte adresse, når de kører i skyen.
Logopbevaring: API-logs hos SaaS-tjenester gemmes ofte kort.
Kopierede nøgler: Den samme nøgle kan være lækket flere steder, og den første eksponering er ikke nødvendigvis den, der blev opdaget.

Hvad dokumentationen kan og ikke kan vise

Dokumentationen kan vise, hvornår nøglen blev tilgængelig, hvornår og hvordan den blev brugt af fremmede, og hvad den gav adgang til. Den kan ikke identificere, hvem der brugte den. En økonomisk konsekvens, fx en cloudregning, er beskrevet i Misbrug af cloudkontoen og regningen bagefter.

Dokumentation

Rapporten bør angive nøglens type, id og rettigheder, kilderne til eksponering og brug med periode og tidszone, hashværdier af eksporterne og tidspunktet for rotation. Beskriv, hvilke handlinger der kan føres til fremmed brug, og hvilke der ikke kan skelnes fra legitim brug.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Skimming på betalingssiden: spor efter injiceret JavaScript · Eksponeret lagring: hvem tilgik dataene?

→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik