GitHub secret scanning олсон түлхүүрийг устгах нь оройтсон: эхлээд revoke хий

GitHub secret scanning API түлхүүр илрүүлбэл түүнийг эхлээд олгосон үйлчилгээнд нь хүчингүй болго. GitHub-ийн Git түүх цэвэрлэх заавар нууц credential алдагдсан үед эхлээд хүчингүй болгох эсвэл солихыг зөвлөдөг. Одоогийн файлаас мөрийг устгасан ч өмнөх коммитэд байсан утга хандалт олгох чадвараа алдахгүй.

Дараалал нь илэрсэн түлхүүрийг таних, эрхийг нь цуцлах, шинэ түлхүүрээр хэрэглээг сэргээх, өмнөх ашиглалтыг шалгах, шаардлагатай бол Git түүхийг цэвэрлэх, дараагийн алдагдлыг push protection-оор хязгаарлах юм. GitHub дахь alert-ийг хаах нь энэ дарааллын бүртгэлийн алхам; үйлчилгээ олгогч талын түлхүүрийг дангаараа хүчингүй болгохгүй.

Alert ямар эрхийг зааж байгааг тогтоо

Alert-ийг нээгээд түлхүүрийн төрөл, файл, коммит болон илэрсэн бусад байрлалыг тэмдэглэ. GitHub-ийн secret scanning тайлбар энэ функц репозиторын бүх салааны Git түүхээс API түлхүүр, токен, нууц үг зэрэг credential хайдаг гэж тодорхойлдог. Иймээс үндсэн салааны өнөөгийн файлыг хараад л алдагдлын хүрээг тогтоож болохгүй.

Түлхүүрийг ямар үйлчилгээ олгосон, эзэмшигч нь хэн, аль орчин болон автоматжуулалт түүгээр ажилладгийг тогтоо. Alert-д active гэж тэмдэглэгдсэн бол ажиллаж буй эрх гэж үзэн яаралтай цуцал; inactive бол олгогч үйлчилгээний төлөвтэй тулгаж баталгаажуул. Unknown гэсэн тэмдэглэгээ нь аюулгүй гэсэн дүгнэлт биш: GitHub тухайн утгын хүчинтэй эсэхийг тогтоогоогүй байж болно.

Түлхүүртэй төстэй жишээ мөр илэрсэн бол false positive эсэхийг шийдэхээс өмнө бодит үйлчилгээний эрх олгодоггүйг нягтал. Шалгахдаа бүтэн утгыг чат, тасалбар эсвэл логт хуулж дахин тараах шаардлагагүй. Эзэмшигч, төрөл, илэрсэн байрлал болон үйлчилгээний бүртгэл ихэнхдээ шийдвэр гаргахад хангалттай.

Түлхүүрийг олгосон үйлчилгээнд нь хүчингүй болго

Эрхийг GitHub дахь коммитээс бус, түлхүүр гаргасан үйлчилгээний удирдлага эсвэл эрх бүхий API-аас цуцална. Дараа нь хуучин утгын төлөвийг үйлчилгээ олгогч талаас баталгаажуул. GitHub зарим түнш үйлчилгээний илэрсэн нууцыг олгогчид нь мэдээлдэг ч ийм автомат ажиллагаа болсон гэж таамаглалгүй, тухайн түлхүүрийн бодит төлөвийг шалга.

Нөхцөлт жишээ: төлбөрийн үйлчилгээний API түлхүүр тохиргооны файлтай хамт коммит хийгдсэн гэж үзье. Файлаас түлхүүрийг арилгах өөрчлөлт бэлдэхийн зэрэгцээ төлбөрийн үйлчилгээний талд хуучин эрхийг цуцална. Ингэснээр хуучин коммитыг үзсэн хүн тэр түлхүүрээр шинэ хүсэлт явуулах боломжгүй болох ёстой; өмнө нь хүсэлт явуулсан эсэхийг тусад нь шалгана.

Үйлдвэрлэлийн систем хуучин түлхүүрээс хамаардаг бол цуцлалт түр тасалдал үүсгэж болно. Хариуцсан багт нөлөөг нь мэдэгдэж, шинэ түлхүүр болон байршуулалтын өөрчлөлтийг шуурхай бэлд. Үйлчилгээг сэргээх ажлыг зохион байгуулах нь алдагдсан эрхийг удаан хугацаанд идэвхтэй үлдээх шалтгаан болох ёсгүй.

Шинэ түлхүүрээр хэрэглээг сэргээ

Шинэ credential үүсгэхдээ шаардлагатай орчин, үйлдэлд нь тохирсон эрх олго. Түлхүүрийг source файлд буцаан бичихийн оронд байршуулалтын орчны хамгаалагдсан тохиргоо эсвэл нууц мэдээлэл хадгалах хэрэгслээр дамжуул. Аппликейшн, CI ажил, хуваарьт даалгавар зэрэг хуучин утга хэрэглэж байсан хэсгүүдийг шинэчилж, тус бүр хэвийн ажиллаж байгааг шалга.

Шинэ түлхүүр үүссэн нь шилжүүлэлт дууссан гэсэн үг биш. Хуучин утга өөр орчны хувьсагч, автоматжуулалтын тохиргоо эсвэл өөр репозиторт үлдвэл дараагийн байршуулалт доголдож болно. Ямар хэрэглээ шинэ утга руу шилжсэнийг үйлчилгээ тус бүрээр нь тулгах нь зөвхөн код нийлснийг харахаас илүү тодорхой баталгаа өгнө.

Ашиглалтыг шалгаж, alert-ийг бодит үр дүнгээр хаа

Түлхүүр олгосон үйлчилгээний боломжтой хүсэлтийн, хандалтын болон аюулгүй байдлын бүртгэлээс түлхүүр коммитэд орсноос цуцлагдах хүртэлх хугацааг шалга. Танихгүй хүсэлт, ердийн бус эрх ашиглалт эсвэл төлбөрийн үйлчилгээний жишээнд тайлбарлах боломжгүй зардал илэрвэл байгууллагын ослын журмаар хүрээг тогтоо. Энэ шалгалтыг цуцлалтын өмнөх саад болгож болохгүй: эрхийг хаасны дараа өмнөх хэрэглээг тодруулах ажил юм.

GitHub-ийн secret scanning REST API alert-ийн байрлалыг авах, active, inactive, unknown төлөвөөр шүүх, шийдвэрлэлтийг revoked эсвэл false_positive гэж тэмдэглэх боломжтой. API-аар alert-ийн төлөв солих нь түлхүүр олгосон үйлчилгээнд эрх цуцлах хүсэлт явуулж буй хэрэг биш. API ашиглан alert татах үед бүтэн нууц утга шаардлагагүй бол түүнийг нуух тохиргоог хэрэглэ.

Хуучин эрх цуцлагдсаныг баталгаажуулсны дараа revoked гэсэн шалтгаанаар alert-ийг хаа. False_positive нь бодит хандалтын эрх олгодоггүй мөрөнд тохирно; ажиллаж байсан түлхүүрийг ийм ангилалд оруулах нь ослын бүртгэлийг буруу болгоно. Мөрийг файлаас арилгасан төдийд alert автоматаар зөв шийдэгдсэн гэж үзэхгүй.

Git түүхийг цэвэрлэх шаардлагыг үнэл

Хүчингүй болсон түлхүүрийг өнөөгийн кодоос авч хаях нь зөв боловч өмнөх коммитыг арилгахгүй. Эрх нь үнэхээр цуцлагдсан, өөр эмзэг мэдээлэл хамт ороогүй бол түүхийг бүхэлд нь дахин бичих шаардлагагүй байж болно. Харин цуцалж болдоггүй мэдээлэл, өөр нууц эсвэл бодлогоор арилгах ёстой өгөгдөл хамт орсон бол түүх цэвэрлэх ажлыг тусад нь төлөвлө.

Түүх дахин бичихээр шийдвэл нөлөөлөх салаа, tag, pull request болон багийн хуулбаруудыг тогтоо. git-filter-repo зэрэг зориулалтын хэрэгслээр шаардлагатай түүхийг өөрчилсний дараа үр дүнг шалгаж, GitHub дахь холбогдох лавлагааг цэгцлэх болон хамтран ажиллагчдын хуучин clone-ыг шинэчлэх ажлыг зохицуул. Коммитын таних утга өөрчлөгдөх тул нээлттэй pull request, автоматжуулалт, гарын үсэгтэй коммитод нөлөөлж болно.

Force push хийсэн ч хуучин утга fork, бусдын clone эсвэл pull request-ийн лавлагаанд үлдэж болно. Хуучин clone-оос дахин push хийвэл арилгасан мэдээлэл буцаж орж ирэх эрсдэлтэй. Иймээс түүх цэвэрлэхийг нэг хүний Git команд бус, хуулбар эзэмшигчидтэй зохицуулах ажил гэж үз.

Дараагийн алдагдлыг push protection-оор хязгаарла

Репозиторт secret scanning болон боломжтой бол push protection идэвхтэй эсэхийг шалга. Push protection нь дэмждэг нууцын хэв маяг илэрсэн push-ийг репозиторт хүрэхээс өмнө зогсоож, утгыг авч хаяад дахин илгээх боломж өгдөг. Байгууллагад хэрэглэдэг түлхүүр стандарт хэв маягт багтахгүй бол тохирох custom pattern шаардлагатай эсэхийг үнэл.

Хамгаалалтын тохиргоо нь өмнө алдагдсан түлхүүрийн эрхийг цуцлахгүй. Мөн зөвшөөрсөн тойруулалт болон илрүүлэлтэд багтаагүй нууц байж болох тул төлбөрийн үйлчилгээний нөхцөлт жишээнд хуучин эрхийн цуцлалт, шинэ түлхүүрээр сэргэсэн хэрэглээ, өмнөх хүсэлтийн шалгалт тус тусдаа хийгдсэн байх ёстой.

Мөн уншаарай:

• GitHub Actions эсвэл GitLab CI: ижил pipeline 91 секундээр зөржээ