Nutekintas „GitHub“ prieigos raktas: ištrinti jį iš kodo nepakanka

Jei „GitHub“ saugykloje paviešintas prieigos raktas, nustatykite jo tipą, savininką ir nuo jo priklausomas paslaugas. Tada atšaukite raktą pas jį išdavusį teikėją. Jei neatidėliotinas atšaukimas sustabdytų svarbią paslaugą, paruoškite pakaitinį raktą, perjunkite paslaugą ir iškart atšaukite senąjį.

Po to patikrinkite, ar senasis raktas nebegalioja, atnaujinkite visas jį naudojusias sistemas ir ieškokite galimo neteisėto naudojimo požymių. Tik tada šalinkite rakto reikšmę iš kodo ir spręskite dėl „Git“ istorijos valymo. Naujas kodo įrašas be paslapties nepanaikina ankstesnių įrašų ir pats savaime nesustabdo nutekinto rakto veikimo.

Nustatykite, kieno tai raktas ir ką jis pasiekia

Pirmiausia atskirkite „GitHub“ asmeninį prieigos raktą nuo kitos paslaugos API rakto, SSH privataus rakto ar kito prisijungimo duomens. Užfiksuokite saugyklą, failą ir įrašą, kuriame paslaptis pasirodė, bei žmogų ar komandą, atsakingą už jos naudojimą. Jei savininkas neaiškus, gali padėti saugyklos atsakomybių aprašas ir įrašų istorija; viešai matomos rakto reikšmės neperkelkite į naujus pranešimus.

Įvertinkite, ar raktas tebėra aktyvus, ar saugykla vieša ir ar raktas naudojamas gamybinėje aplinkoje. Jei įjungtas „secret scanning“, įspėjime gali būti nurodytas paslapties tipas, galiojimo būsena, o „GitHub“ asmeninio rakto atveju – prieigos apimtis ar paskutinio naudojimo duomenys. Galiojimo patikra prieinama ne visų tipų paslaptims, todėl galutinę būseną tikrinkite pas raktą išdavusį teikėją.

Atšaukite iškart arba surenkite trumpą perjungimą

Aktyvaus, viešai paviešinto arba gamybinėje aplinkoje naudojamo rakto atšaukimas yra skubiausias veiksmas. „GitHub“ nutekėjusių paslapčių šalinimo gairėse atšaukimą pas teikėją vadina svarbiausiu veiksmu; jose taip pat nurodyta, kad viešose saugyklose nutekėjusius savo asmeninius prieigos raktus „GitHub“ atšaukia automatiškai. Vis tiek patikrinkite konkretaus rakto būseną, ypač jei nežinote, kada ir kur jis buvo paviešintas.

Jei rakto išjungimas nesustabdys paslaugos, nelaukite naujos konfigūracijos ar istorijos valymo: atšaukite jį ir tada kurkite pakaitinį. Jei nuo rakto priklauso veikianti integracija, paskirkite atsakingą žmogų, sukurkite naują raktą, perjunkite integraciją ir patikrinkite jos veikimą prieš atšaukdami senąjį. Šis perjungimas turi trukti kuo trumpiau, nes iki atšaukimo nutekintas raktas tebėra naudojamas.

Atšaukimo vietą lemia išdavėjas. Kitos paslaugos API rakto „GitHub“ paskyros nustatymuose neišjungsite – kreipkitės į tos paslaugos valdymo aplinką arba rakto savininką. Jei neturite teisės atšaukti svetimo rakto, nedelsdami įtraukite jo savininką ar administratorių ir perduokite jiems informaciją apie nutekėjimo vietą bei galimai paveiktas sistemas.

„GitHub“ asmeninį raktą pakeiskite pagal jo tipą

Jei nutekėjo jūsų „GitHub“ asmeninis prieigos raktas, paskyroje atverkite Settings, tada Developer settings ir Personal access tokens. Pasirinkite Fine-grained tokens arba Tokens (classic) pagal rakto tipą ir ištrinkite atitinkamą įrašą. „GitHub“ asmeninių prieigos raktų valdymo instrukcija pateikia šį kelią ir nurodo, kad ištrynus raktą, kuriuo buvo sukurtas diegimo raktas, pašalinamas ir tas diegimo raktas.

Pakaitiniam smulkių teisių raktui parinkite tik reikalingą išteklių savininką, saugyklas ir leidimus, taip pat galiojimo laiką. Tokio rakto galimybes gali riboti organizacijos patvirtinimo taisyklės, o kai kuriems darbams vis dar reikia „classic“ tipo rakto, todėl prieš perjungdami patikrinkite konkrečios integracijos reikalavimus. Jei diegimo rakto netekimas paveiktų automatizavimą, įtraukite jį į pakeitimo planą kartu su asmeniniu raktu.

Suraskite kopijas ir perjunkite visas priklausomas sistemas

Paiešką pradėkite nuo saugyklos kodo, ankstesnių įrašų, pakeitimų užklausų ir problemų aprašų. Toliau tikrinkite kitus organizacijos projektus, „Secrets and variables“, diegimo raktus bei įdiegtas integracijas. Atskirai peržiūrėkite programų konfigūraciją ir paslapčių saugyklas: tas pats raktas gali būti naudojamas keliose vietose, nors nutekėjimas pastebėtas tik viename faile.

Kiekvienoje priklausomoje sistemoje įrašykite pakaitinį raktą ir patikrinkite būtent tą veiksmą, kuriam jis skirtas. Jei raktas suteikė prieigą prie saugyklos automatizuotai užduočiai, patikrinkite tos užduoties prieigą; jei buvo naudojamas diegimui, patikrinkite diegimo veiksmą. Vienos veikiančios integracijos neužtenka laikyti įrodymu, kad atnaujintos visos rakto kopijos.

Peržiūrėkite naudojimą ir tik tada tvarkykite istoriją

Atšaukę senąjį raktą ir atkūrę paslaugų veikimą, peržiūrėkite laikotarpį, kuriuo paslaptis galėjo būti pasiekiama. Asmeninės paskyros saugos žurnalas, organizacijos audito įrašai ir rakto teikėjo žurnalai gali padėti pastebėti neįprastą naudojimą; prieigai prie organizacijos įrašų gali reikėti administratoriaus. Jei aptinkate įtartinų veiksmų, tikrinkite ir jų paliestus išteklius.

Iš dabartinio kodo pašalinkite rakto reikšmę ir perduokite naują paslaptį per tam skirtą saugojimo priemonę. Tada spręskite, ar reikia perrašyti „Git“ istoriją: „GitHub“ jautrių duomenų šalinimo gairėse nurodo pirmiausia atšaukti arba pakeisti prisijungimo duomenį ir įspėja, kad istorijos perrašymas pakeičia įrašų identifikatorius, gali sutrikdyti bendradarbių darbą bei leisti senoms kopijoms grąžinti paslaptį.

Jei istorijos valymas būtinas, suderinkite jį su saugyklos administratoriais ir žmonėmis, turinčiais jos kopijas. Patikrinkite šakas bei pakeitimų užklausas, kad senoji reikšmė vėl nepatektų į saugyklą. Incidentą užbaikite įsitikinę, kad nutekintas raktas nebegalioja, priklausomos paslaugos veikia su pakaitiniu, o galimo neteisėto naudojimo požymiai peržiūrėti.

Taip pat skaitykite:

• Ar jūsų DI sistema didelės rizikos? Vien Annex III sąrašo nepakanka
• ShinyHunters grįžo prie PeopleSoft: vien WAF taisyklių nepakanka
• Claude Code ar GitHub Copilot: 7 156 užduotys paneigia vieną nugalėtoją