9.300 lækkede AWS-nøgler virkede stadig – 768 gav fuld kontrol over virksomheders konti

Offentligt eksponerede AWS-legitimationsoplysninger var i mange tilfælde ikke kortvarige fejl, der hurtigt blev lukket. Truffle Securitys undersøgelse fra august 2022 til august 2026 viser, at mange nøgler forblev gyldige i årevis – også nøgler med tilstrækkelige rettigheder til at overtage virksomheders AWS-konti.

Hovedfundet: En lækket nøgle kunne forblive en åben dør

Truffle Security indsamlede 431.875 forekomster af AWS-hemmeligheder fra offentlige kodearkiver, Git-historik, datasæt, Docker-images, containerregistre og logfiler fra continuous integration (CI). Efter dubletter var fjernet, dækkede materialet 64.024 unikke AWS-adgangsnøgler knyttet til 50.654 AWS-konti.

Forskerne kunne verificere 10.616 komplette nøglepar. Da de testede legitimationsoplysningerne igen den 10. august, kunne 88 procent stadig godkende brugeren – det vil sige, at mere end 9.300 offentligt eksponerede nøgler fortsat kunne bruges.

At en nøgle har optrådt i et offentligt kodearkiv, betyder ikke nødvendigvis, at den stadig udgør en aktiv risiko. Risikoen bliver alvorlig, når nøglen ikke er tilbagekaldt, stadig kan godkende brugeren og har betydelige rettigheder. I denne undersøgelse faldt de tre forhold ofte sammen.

768 virksomhedsnøgler gav fuld administrativ kontrol

Af de aktive nøgler, der kunne knyttes til virksomhedskonti, var 817 relateret til virksomheder. Gruppen omfattede:

• 526 nøgler til AWS root-konti
• 242 nøgler til IAM-brugere med AWS-politikken AdministratorAccess
• 768 nøgler i alt, som gav fuld administrativ kontrol over en virksomheds AWS-konto

Root-legitimationsoplysninger er det højeste kontrolniveau, en AWS-kunde har. En IAM-identitet med AdministratorAccess har tilsvarende meget brede rettigheder på tværs af AWS-tjenester. En gyldig nøgle på et af disse niveauer kan derfor åbne for konto-overtagelse, uautoriseret oprettelse af ressourcer, adgang til data eller misbrug af cloud-faktureringen.

Fundene peger dermed på et problem med både rettighedsstyring og nøglernes livscyklus – ikke kun på mangelfuld oprydning i kildekoden. Det beskytter ikke kontoen at fjerne en nøgle fra en synlig fil, hvis nogen allerede har kopieret den. Nøglen skal tilbagekaldes eller udskiftes.

Hugging Face var den største enkeltkilde

Hugging Face stod for 8.482 eksponeringer af AWS-legitimationsoplysninger og var dermed den største enkeltkilde i rapporteringen. Truffle Security oplyste, at 17,9 procent af disse AWS-legitimationsoplysninger var root-legitimationsoplysninger.

Resultatet indgår i en bredere scanning af offentlige data på Hugging Face. Truffle Security undersøgte 7,6 petabyte offentlige datasæt og fandt aktive legitimationsoplysninger i tusindvis af datasæt. Det viser, hvordan hemmeligheder kan overleve uden for traditionelle softwarearkiver og ende i data, der distribueres offentligt.

For sikkerhedsteams er konklusionen klar: Det er ikke nok kun at scanne de aktuelle kildekodearkiver. Git-historik, build-artefakter, container-images, registre, offentliggjorte datasæt og CI-output kan alle bevare legitimationsoplysninger, efter at udviklere tror, de er fjernet.

Mange nøgler var flere år gamle

Den rapporterede medianalder for en legitimationsoplysning var cirka 1.831 dage, altså omkring fem år. Den ældste nøgle var 17,4 år gammel. Kun 13,7 procent af posterne havde en nyere nøgle tilknyttet, hvilket tyder på, at de fleste ikke var blevet udskiftet gennem en normal rotationsproces.

Langlivede adgangsnøgler giver uvedkommende mere tid til at misbruge adgangen og gør det sværere at fastslå, hvem der har ansvaret for dem. De kan også overleve medarbejderskift, migreringer, oprydning i kodearkiver og ændringer i den daglige drift.

Alder bør derfor ses som et risikosignal. En eksponeret nøgle, der er flere år gammel, skal ikke automatisk antages at være udløbet. Den bør kontrolleres, tilbagekaldes og undersøges, medmindre ejeren kan dokumentere, at den ikke længere er gyldig.

Få konti havde budgetadvarsler

Truffle Security kunne aflæse kontooplysninger for 2.754 konti, men kun 262 af dem havde aktiveret AWS-budgetadvarsler.

Budgetadvarsler kan ikke erstatte tilbagekaldelse af legitimationsoplysninger eller egentlig trusselsdetektion. De kan dog give et tidligt signal, hvis eksponerede nøgler bruges til at oprette dyre ressourcer – for eksempel til cryptomining eller andre former for cloudmisbrug. Uden en besked, der når frem til nogen, som kan reagere, kan et unormalt forbrug fortsætte efter et kontobrud.

Hvad AWS’ notifikationer løser – og ikke løser

Rapporteringen beskriver AWS-beskyttelser, der kan opdage offentliggjorte adgangsnøgler, underrette de berørte kunder og indføre begrænsninger eller karantæneforanstaltninger. At så mange af de testede nøgler fortsat var gyldige, tyder imidlertid på, at besked eller detektion ikke konsekvent førte til hurtig tilbagekaldelse og udskiftning hos kunderne.

Detektion er kun første skridt i håndteringen af en lækket legitimationsoplysning. En komplet indsats skal identificere ejeren, fastslå hvilke ressourcer nøglen kan tilgå, undersøge muligt misbrug og ugyldiggøre nøglen.

Truffle Security beskriver sin egen validering som skrivebeskyttet: Forskerne kontrollerede, om legitimationsoplysningerne kunne godkende brugeren, og undersøgte tilladelser eller kontometadata, men ændrede ikke kundernes ressourcer. Denne beskrivelse stammer fra Truffle Security og er ikke uafhængigt underbygget i alle de kilder, der indgår her.

Hvad organisationer bør gøre efter et AWS-læk

1. Tilbagekald eller udskift nøglen med det samme

Slet eller deaktivér alle offentligt eksponerede legitimationsoplysninger, og opret kun en erstatning, hvis adgangen fortsat er nødvendig. At fjerne hemmeligheden fra et kodearkiv, slette en fil eller omskrive Git-historikken gør ikke kopier, der allerede er hentet, ugyldige.

2. Fjern root-adgangsnøgler

AWS root-brugerens adgangsnøgler bør ikke bruges til almindelig programmatisk adgang. Slet root-nøgler, og flyt arbejdsbelastninger over på kontrollerede identiteter med så snævre rettigheder som muligt.

3. Kortlæg rettigheder og ejerskab

Find ud af, hvilken konto, bruger, tjeneste og hvilke ressourcer legitimationsoplysningen var knyttet til. Prioritér nøgler med root-rettigheder, AdministratorAccess, bred dataadgang eller mulighed for at oprette infrastruktur.

4. Undersøg aktiviteten før og efter tilbagekaldelsen

Gennemgå godkendelsesaktivitet, CloudTrail-logfiler, ændringer i IAM, nyoprettede ressourcer og fakturering for mistænkelig adfærd. Tilbagekaldelse stopper yderligere brug af den eksponerede nøgle, men viser ikke, om den allerede er blevet misbrugt.

5. Erstat permanente nøgler med kortlivede identiteter

Brug så vidt muligt kortlivede IAM-roller og workload-identiteter i stedet for permanente adgangsnøgler. Rettigheder efter princippet om mindst mulige privilegier begrænser den skade, en lækket legitimationsoplysning kan forårsage.

6. Aktivér budgetadvarsler og en klar reaktionsvej

Opsæt advarsler i AWS Budgets og overvågning af unormale omkostninger. Send notifikationerne til personer, der rent faktisk kan reagere hurtigt. Økonomisk overvågning er et sikkerhedsnet – ikke en erstatning for scanning efter hemmeligheder, nøgleudskiftning og løbende adgangskontrol.

Den bredere sikkerhedslæring

Undersøgelsens vigtigste fund var ikke alene antallet af hemmeligheder. Det var kombinationen af offentlig eksponering, fortsat gyldighed, høje privilegier, ekstrem alder og begrænset overvågning. Offentlige datalagre kan bevare legitimationsoplysninger længe efter, at en organisation har glemt, hvor de blev brugt, mens en kopieret nøgle kan forblive nyttig, indtil den udtrykkeligt tilbagekaldes.

Den sikreste tommelfingerregel for cloudteams er derfor enkel: Behandl enhver eksponeret AWS-legitimationsoplysning som kompromitteret, undersøg hvad den giver adgang til, tilbagekald eller udskift den straks, og erstat langlivede adgangsnøgler med kortlivede identiteter med mindst mulige privilegier.