API-nøglen lå på GitHub: Sletning af committen stopper ikke misbrug

Hvis du har lagt en API-nøgle, et token eller en adgangskode på GitHub, skal du behandle oplysningen som kompromitteret. Find den hos udbyderen, tilbagekald den eller rotér den hurtigst muligt, og giv berørte tjenester en ny adgangsoplysning. GitHubs vejledning om lækkede hemmeligheder fastslår, at det ikke forhindrer misbrug blot at fjerne værdien fra koden, oprette en ny commit eller slette repositoryet.

Er adgangsoplysningen stadig aktiv, offentligt eksponeret eller brugt i produktion, haster spærringen. Holder den samtidig en kritisk tjeneste i gang, skal udskiftningen koordineres hurtigt med tjenestens ejer. Oprydning i Git kan vente, til adgangen hos udbyderen er lukket.

Find nøglen og dens ejer

Fastslå først, hvilken type adgangsoplysning der er lækket, hvem der har udstedt den, og hvem der kan administrere den. Find repository, fil og commit, og undersøg, om repositoryet er offentligt. En advarsel fra secret scanning kan hjælpe med at lokalisere lækken, men kontrollér nøglens gyldighed hos udbyderen, før du lægger en plan.

Find derefter de tjenester, der bruger nøglen, og hvilke rettigheder den giver. En nøgle til et udviklingsmiljø og en nøgle med adgang til produktionsdata kan kræve forskellige driftsmæssige hensyn, men begge skal håndteres. Brug kun den tid på kortlægning, der er nødvendig for at vælge, hvem der spærrer adgangen, og om en erstatning skal være klar først. Hvis du ikke selv har rettighederne, så kontakt straks nøglens ejer eller en administrator uden at kopiere den lækkede værdi ind i en besked.

Spær straks, eller rotér uden driftsstop

Tilbagekald straks, hvis nøglen kan deaktiveres uden et uacceptabelt driftsstop. Opret derefter en erstatning, og genopret de tjenester, der mistede adgang. Det er den hurtigste måde at lukke den konkrete adgang på, især når en aktiv nøgle har ligget i et offentligt repository eller giver omfattende rettigheder.

Rotér hurtigt og kontrolleret, hvis en øjeblikkelig spærring vil afbryde en kritisk produktionstjeneste. Opret en ny adgangsoplysning, få de afhængige tjenester til at bruge den, kontrollér deres vigtigste funktioner, og deaktiver så den gamle. Google Clouds procedure for kompromitterede adgangsoplysninger beskriver denne rækkefølge for at undgå driftsstop; for Google Cloud-API-nøgler skal applikationerne opdateres, før den tidligere nøgle slettes. Følg altid den berørte udbyders fremgangsmåde for netop den type nøgle eller token, der er lækket.

Den kontrollerede overgang er en kort hændelsesopgave, ikke en udsættelse til næste almindelige vedligeholdelsesvindue. Udpeg en ansvarlig for spærringen og en ansvarlig for hver berørt tjeneste, så ingen venter på, at en anden afslutter skiftet. Kan alle afhængigheder ikke findes hurtigt, må sikkerhedsrisikoen ved en fortsat gyldig nøgle vejes mod et muligt driftsstop, og sikkerhedsansvarlige bør inddrages med det samme.

Bekræft, at alle tjenester er skiftet

Gennemgå applikationer, automatiseringer, planlagte job og integrationer, der bruger den gamle adgangsoplysning. Den kan være lagret i et hemmelighedslager, i GitHub Actions-indstillinger, i en deploymentkonfiguration eller hos en ekstern tjeneste, der kalder udbyderens API. Opdatér hver afhængighed, og kontrollér dens vigtigste funktion med den nye nøgle.

En vellykket test af hovedapplikationen viser ikke, at et sjældnere kørt job også er skiftet. Bed derfor ejerne af de berørte tjenester bekræfte deres del, og kontrollér til sidst hos udbyderen, at den gamle nøgle faktisk er deaktiveret eller slettet. Hvis den fortsat er gyldig, er hændelsens vigtigste sikkerhedstrin endnu ikke afsluttet.

Undersøg brugen i eksponeringsperioden

Når adgangen er lukket og driften stabil, skal du gennemgå de tilgængelige hændelses- og revisionslogs fra den første mulige eksponering til spærringen. Se efter kald, tidspunkter, ressourcer og handlinger, der ikke passer med den forventede brug. Er et GitHub-token berørt, kan relevante konto- eller organisationslogs være nyttige; for en nøgle til en anden tjeneste er udbyderens egne logs centrale.

Et usædvanligt kald kræver en nærmere undersøgelse af, hvad der blev læst, ændret eller oprettet. Gem de relevante hændelsesoplysninger, og involvér sikkerhedsansvarlige, hvis loggene peger på uautoriseret aktivitet. Mangler der logs for en del af perioden, så registrér hullet i vurderingen; fravær af fund viser kun, hvad de tilgængelige logs kan belyse.

Ryd op i repositoryet

Fjern den gamle værdi fra den aktuelle kode og fra konfigurationer, hvor den ikke hører hjemme. Søg efter kopier i andre repositories, pull requests, issues og deploymentindstillinger. Læg erstatningen i en egnet løsning til hemmeligheder, så den ikke indgår i en ny commit.

Den eksponerede værdi kan stadig findes i Git-historikken, selv om den seneste version er ren. Vurdér med repositoryets og sikkerhedens ansvarlige, om historikken skal omskrives af hensyn til sikkerheds- eller compliancekrav. Omskrivning kan påvirke andre udvikleres kopier og kræve et koordineret force push. Beslutningen handler om oprydning i de tilbageværende kopier; den kan ikke tilbagekalde en nøgle, som allerede er blevet kopieret.

Forebyg næste læk ved push

Aktivér relevant secret scanning og push protection, og aftal, hvem der må godkende en omgåelse af en blokering. GitHubs beskrivelse af push protection forklarer, at funktionen kan standse et push med en genkendt hemmelighed, før den når repositoryet. Beskyttelsen afhænger af opsætningen og af, om hemmelighedens mønster genkendes; kontrollér derfor både repositoryets indstillinger og håndteringen af undtagelser.

Afslut hændelsen med en kort registrering af, hvilken adgangsoplysning der blev spærret, hvilke tjenester der blev opdateret, og hvad loggennemgangen viste. Registrér også ejeren af eventuelle åbne opgaver, eksempelvis historikoprydning eller en manglende logkilde. Så kan næste ansvarlige se, om den gamle adgang er lukket, og hvilke afhængigheder der stadig kræver kontrol.

Læs også:

• Flyt branch protection til GitHub Rulesets – overlap kan blokere merges
• Jobindsats har slukket API v2 – gamle rapporter svarer ikke længere
• Cursor eller GitHub Copilot? Opgavetypen slår den billigste månedspris