GitHubi lekkinud võti tuleb tühistada — commiti kustutamisest ei piisa

GitHubi lekkinud API-võti või token tuleb väljastaja juures tühistada või teenuse katkestuse vältimiseks kiiresti asendada ja seejärel tühistada: GitHubi käsitlusjuhis selgitab, et saladuse eemaldamine koodist, uus commit ega hoidla kustutamine ei takista kehtiva volituse kasutamist. Käsitle avalikuks saanud võtit kompromiteerituna, kuni väljastaja juures on selle kehtetus kinnitatud.

Esimese tunni tööjärjekord on tuvastada võtme omanik ja õigused, sulgeda vana ligipääs, uuendada sõltuvad teenused ning vaadata üle võimalik kasutus lekke ajal. Alles seejärel otsusta, kas Git-ajalugu on vaja ümber kirjutada. Allpool toodud minutid on soovituslik tööjaotus, mitte põhjus oodata: kui avaliku või tootmises kasutatava võtme saab kohe tühistada, tee seda viivitamata.

0–5 minutit: määra omanik ja mõju ulatus

Selgita välja saladuse liik ja väljastaja ning märgi üles hoidla, fail, lekke toonud commit ja hoidla nähtavus. Leia inimene või meeskond, kellel on õigus volitust hallata; commiti autor ja võtme omanik võivad olla erinevad. Hoidla haldaja saab samal ajal kaardistada, kuhu väärtus jõudis, ning teenuse omanik saab kindlaks teha võtme õigused ja kasutajad.

Kui Secret Scanningu hoiatus on olemas, vaata selle kehtivusolekut ning avaliku või mitmes kohas toimunud lekke märget. Kehtivuskontroll ei kata kõiki saladusetüüpe, seega kinnita otsustav olek väljastaja juures. GitHubi Secret Scanningu kirjeldus ütleb, et kontroll hõlmab kõigi harude kogu Git-ajalugu ning avastatud volitus tuleks kohe roteerida.

Hoiatuse puudumisel kontrolli ligipääsuõigusi järgides ajalugu ja teisi asjakohaseid hoidlaid. Vaata ka, kas väärtus esineb issue’des või pull request’ides. Jaga ülesanded kohe: volituse omanik tegeleb tühistamisega, teenuste eest vastutajad otsivad sõltuvusi ning intsidenti koordineeriv inimene fikseerib võimaliku avalikuks saamise aja. Ära kopeeri võtme täisväärtust avatud vestlusse või intsidendikirjesse.

5–15 minutit: sulge vana ligipääs

Kui võti on aktiivne, avalikult nähtav või tootmises kasutusel, sea selle tühistamine esikohale. Katkestust taluva teenuse puhul tühista vana volitus kohe ja loo vajaduse korral asendus. Kui kohene tühistamine peataks kriitilise töö, loo esmalt uus volitus, vii vajalik teenus sellele üle, kontrolli toimimist ning tühista vana nii kiiresti kui võimalik. Ülemineku ajal jääb lekkinud võti kasutatavaks.

Tühistamine toimub võtme väljastaja juures. Kui sul puudub pääs väljastaja haldusesse, võta kohe ühendust võtme omaniku või administraatoriga ning märgi intsident avatuks kuni kehtetus on kinnitatud. Hoidla või faili muutmine võib takistada sama saladuse edasist kasutamist koodis, kuid ei asenda väljastaja tehtavat tühistamist.

Asendusvõtmele anna vaid tööks vajalikud õigused, kui väljastaja seda võimaldab. Pane piiratud ligipääsuga kirja võtme tunnus, väljastaja, vastutaja ja tühistamise aeg, kuid jäta saladuse väärtus kirjest välja. Kui võtme olek on ebaselge, jätka tegevust eeldusel, et seda saab endiselt kasutada.

15–35 minutit: uuenda kõik sõltuvad teenused

Vana võtme tühistamine võib katkestada iga rakenduse või töövoo, mis seda veel kasutab. Kaardista käivituskeskkonnad, juurutused, ajastatud tööd, integratsioonid ja GitHub Actionsi töövood. Kontrolli hoidla salvestatud saladusi ja muutujaid ning vajaduse korral paigaldatud GitHub Appide või muude integratsioonide seadistusi. Ühe faili parandamine ei näita, et kõik sõltuvused on üle viidud.

Uuenda iga kasutuskoht tavapärases saladuste halduskohas; ära kirjuta asendusvõtit lähtekoodi. Teenuse omanik peaks kinnitama, et rakendus teeb uue volitusega vajaliku toimingu, ning jälgima pärast vana võtme tühistamist autentimistõrkeid. Pane kontrollimata sõltuvused eraldi kirja koos vastutajaga, sest ühe eduka juurutuse põhjal ei saa järeldada, et kõik vana võtme kasutajad töötavad.

Kui sama saladus oli mitmes hoidlas või töövoos, käsitle neid ühe tühistatava volituse sõltuvustena. Nii ei teki olukorda, kus ühe hoidla parandamine loetakse intsidendi lõpuks, kuigi mõni teine rakendus vajab endiselt asendusvõtit. Vajaduse korral hoia teenuste taastamise ja logide läbivaatamise ülesanded paralleelselt töös.

35–60 minutit: kontrolli lekke ajal toimunut

Kui teenused töötavad uue võtmega, vaata läbi väljastaja kasutus- ja auditilogid alates varaseimast teadaolevast kokkupuutest kuni vana võtme tühistamiseni. Võrdle toiminguid tavapärase kasutusega: ootamatud päringud, õiguste muutused või tegevus, mida oma süsteemid ei selgita, vajavad uurimist. GitHubi pääsutokeni puhul kontrolli ka asjakohase konto, organisatsiooni või ettevõtte turbe- ja auditilogi; juurdepääs neile sõltub rollist.

Fikseeri, millist ajavahemikku ja milliseid logisid kontrolliti ning millal vana võti tegelikult kehtetuks muutus. Kui näed võimalikku loata kasutust, uuri mõjutatud õigusi ja andmeid eraldi ligipääsuintsidendina. Kui logid puuduvad või katavad vaid osa perioodist, märgi see järelduse piiranguna. Logikirjete puudumine üksi ei tõenda, et lekkinud võtit ei kasutatud.

Pärast ligipääsu sulgemist: otsusta ajaloo puhastamine

Eemalda saladus aktiivsest koodist ja hinda koos hoidla haldaja ning turbevastutajaga, kas see tuleb ka Git-ajaloost eemaldada. GitHubi ajaloo puhastamise juhend kirjeldab, kuidas ümberkirjutamine muudab commit’ide räsisid, võib häirida pull request’e ning jätab lekkega versiooni võimalikuks vanades kloonides, fork’ides ja viidetes. Kehtetu võtme korral ei pruugi see häiriv töö ligipääsuriski enam vähendada.

Kui ajalugu on siiski vaja puhastada, kooskõlasta ümberkirjutamine enne jõuga üleslaadimist kõigi hoidla kasutajatega. Selgita välja mõjutatud harud, sildid ja pull request’id ning lepi kokku, kuidas kaastöötajad oma vanad kloonid puhastavad: vana ajalugu võib muidu hoidlasse tagasi jõuda. Arvesta eraldi koopiatega, mida sinu hoidla jõuga üleslaadimine ei muuda.

Kui vana võtme kehtetus, sõltuvate teenuste töö ja tehtud kontrollid on dokumenteeritud, saab Secret Scanningu hoiatuse sulgeda tühistatuna. Ajaloo võimaliku ümberkirjutamise ulatus ja vastutaja jäävad intsidendikirjesse eraldi otsusena, et ligipääsu sulgemine ei sõltuks pikemast hoidla puhastustööst.

Loe ka:

• DMARC ilma katkestuseta: „reject“ tuleb alles pärast aruannete kontrolli
• GitHub Actions või GitLab CI: tasuta minutid ei näita meeskonna kogukulu
• Cursor või GitHub Copilot: odavam plaan ei tähenda odavamat agenti