GitHub push protection-ը միացրեք մինչև առաջին արտահոսքը

21 հոկտեմբերի, 2026 թ., 06:00|Հեղինակ: QUASA-ի խմբագրական թիմ|5 րոպե ընթերցանություն

Պահոցում GitHub push protection-ը միացնելու համար բացեք Settings → Advanced Security․ պահոցի կարգավորման քայլերով նախ միացրեք Secret Protection-ը, եթե այն անջատված է, ապա Push protection-ը։ Անձնական հաշվի կարգավորումն առանձին ստուգեք հանրային պահոցների համար, իսկ կազմակերպության դեպքում նույն պաշտպանությունը կիրառեք անհրաժեշտ պահոցների վրա անվտանգության կազմաձևման միջոցով։

Պաշտպանությունն արգելափակում է աջակցվող գաղտնիքներ պարունակող փոփոխությունը՝ մինչև այն հայտնվի պահոցում։ Եթե commit-ը կամ push-ը կանգ է առել, հեռացրեք գաղտնիքը ուղարկվող փոփոխությունից․ շրջանցման հարցում ներկայացրեք միայն այն դեպքում, երբ արժեքի հրապարակումն իսկապես անվտանգ է և ձեր կազմակերպության կանոնները դա թույլ են տալիս։

Ստուգեք անձնական հաշվի կարգավորումը

Անձնական push protection-ը լռելյայն միացված է հանրային պահոցների համար։ Այն ստուգելու համար սեղմեք GitHub-ի ձեր պրոֆիլի նկարը, անցեք Settings → Code security և User բաժնում գտեք Push protection for yourself-ը։ Եթե կարգավորումն անջատված է, միացրեք այն․ սա ձեր հաշվից հանրային պահոցներ ուղարկվող փոփոխությունների համար լրացուցիչ պաշտպանություն է։

Այդ ընտրանքը չի փոխարինում թիմային պահոցի կարգավորմանը։ Երբ նախագծի անվտանգությունը կախված է պահոցի մակարդակում սահմանված կանոնից, պահոցի պատասխանատուն պետք է ստուգի նաև Secret Protection-ը և Push protection-ը՝ անկախ մասնակիցների անձնական կարգավորումներից։ Այս տարբերությունը կարևոր է հատկապես այն թիմերում, որտեղ նույն պահոցում աշխատում են մի քանի հաշիվներ։

Միացրեք պաշտպանությունը պահոցում

Պահոցի գլխավոր էջից բացեք Settings-ը, ապա Security and quality բաժնի Advanced Security էջը։ Secret Protection-ի կողքին սեղմեք Enable, եթե այն դեռ ակտիվ չէ, և նույն էջի Secret Protection բաժնում միացրեք Push protection-ը։ Եթե Settings ներդիրը չի երևում, այն կարող է լինել լրացուցիչ ընտրացանկում․ կարգավորումը փոխելու համար անհրաժեշտ են համապատասխան կառավարման իրավունքներ։

Միացնելուց հետո դիտեք շրջանցման ընտրանքները հենց այդ պահոցի համար։ Միայն Push protection-ը միացնելը դեռ չի որոշում, թե ով կարող է թույլ տալ արգելափակված գաղտնիքի հրապարակումը․ առանց delegated bypass-ի՝ մասնակիցը կարող է ինքնուրույն շրջանցել արգելքը։ Եթե պահոցը կազմակերպությանն է պատկանում, շրջանցման կանոնը սահմանեք այն մակարդակում, որտեղ թիմը կառավարում է իր անվտանգության քաղաքականությունը։

Կիրառեք կանոնը կազմակերպությունում և նշանակեք վերանայողներին

Կազմակերպության Settings → Advanced Security → Configurations էջում ստեղծեք կամ խմբագրեք custom security configuration-ը։ Secret scanning բաժնում Push protection-ը դրեք Enabled, պահպանեք կազմաձևումը և կիրառեք այն ընտրված պահոցների նկատմամբ։ Պահպանված, բայց պահոցների վրա չկիրառված կազմաձևումը դրանց պաշտպանությունը չի փոխում։

Շրջանցման հաստատում պահանջելու համար delegated bypass-ի կարգավորման քայլերով Push protection բաժնի Bypass privileges ընտրանքում նշեք Specific actors և ընտրեք իրավասու դերերը կամ թիմերը։ Այդ խմբի անդամները կարող են վերանայել մյուս մասնակիցների հարցումները․ անհրաժեշտության դեպքում կազմակերպության առանձին անդամներին կարելի է տալ նաև հարցումները կառավարելու հատուկ իրավունք։ Ընտրեք մարդկանց, որոնք կարող են գնահատել ներկայացված արժեքի նշանակությունն ու հրապարակման հետևանքը։

Exempt ընտրանքը տվյալ մասնակցին ամբողջությամբ ազատում է push protection-ի ստուգումից և նախատեսված է հատուկ վստահելի ավտոմատացման համար։ Սովորական բացառությունների դեպքում հաստատման հարցումը պահպանում է վերանայման քայլը։ Եթե շրջանցման քաղաքականությունն արդեն սահմանված է կազմակերպության մակարդակում, պահոցի համապատասխան ընտրանքները կարող են անջատված լինել․ այդ դեպքում փոփոխությունը կատարեք վերադաս կազմաձևման մեջ։

Ուղղեք արգելափակված commit-ը կամ push-ը

GitHub-ի վեբ միջերեսում արգելափակված commit-ի պատուհանը ցույց է տալիս հայտնաբերված գաղտնիքի տեղը։ Հեռացրեք արժեքը ֆայլից և նորից կատարեք commit-ը։ Եթե նույն արժեքը կոդին անհրաժեշտ է աշխատանքի համար, այն տեղափոխեք գաղտնիքների պահպանման համապատասխան համակարգ և կոդում թողեք միայն դրա անվտանգ հղումը կամ օգտագործման ձևը։

Հրամանային տողից արգելափակված push-ի դեպքում գաղտնիքը հեռացրեք ուղարկվող բոլոր commit-ներից, որտեղ այն հանդիպում է։ Եթե արժեքը միայն վերջին commit-ում է, փոխեք ֆայլը, գործարկեք git commit --amend --all և կրկնեք git push-ը։ Եթե այն ավելի վաղ commit-ում է, գտեք առաջին հայտնվելը և խմբագրեք պատմությունը interactive rebase-ով․ պարզապես նոր մաքուր commit ավելացնելը չի վերացնում գաղտնիքը հին commit-ից։

Պատմության փոփոխությունը փոխում է commit-ների նույնացուցիչները։ Եթե ճյուղն արդեն օգտագործվում է ուրիշների կողմից, նախ համաձայնեցրեք վերագրումը թիմի հետ, որպեսզի նրանց տեղական ճյուղերն ու ընթացիկ աշխատանքը չխաթարվեն։ Եթե արգելափակման հաղորդագրությունը շրջանցման հղում է տալիս, բացեք այն նույն GitHub հաշվով, որով կատարել եք push-ը։

Տարբերակեք սխալ հայտնաբերումը, փորձարկումը և շրջանցման հարցումը

Երբ հայտնաբերված տողը գաղտնիք չէ, շրջանցման պատճառներից ընտրեք It’s a false positive։ It’s used in tests-ը հարմար է միայն այն արժեքի համար, որն օգտագործվում է փորձարկման մեջ և իրական մուտք չի տալիս։ Գործող փորձարկման բանալին նույնպես գաղտնիք է․ դրա համար անվտանգ անվանում ընտրելը չի վերացնում արտահոսքի վտանգը։

Եթե կազմակերպությունը պահանջում է հաստատում, արգելափակման պատուհանից սեղմեք Start request, մեկնաբանության մեջ բացատրեք արժեքի նշանակությունը և ուղարկեք հարցումը։ GitHub-ի արգելափակված commit-ի ընթացակարգով հարցումը փոխանցվում է նշանակված վերանայողներին և սպառվում է յոթ օրից։ Հաստատումից հետո կարող եք շարունակել փոփոխությունը, իսկ մերժման դեպքում պետք է հեռացնեք գաղտնիքը։

Շրջանցման արդյունքում ստեղծվում է անվտանգության alert։ GitHub-ը փակում է այն, երբ որպես պատճառ նշվել է սխալ հայտնաբերումը կամ միայն անվնաս փորձարկումը, իսկ իրական գաղտնիքը հետագայում ուղղելու ընտրության դեպքում alert-ը մնում է բաց։ Այդ վերջին տարբերակը հրապարակման թույլտվություն է տալիս, բայց գործող բանալու խնդիրը չի լուծում։

Արձագանքեք արդեն արտահոսած գաղտնիքին

Եթե գործող գաղտնիքն արդեն հասել է պահոց, նախ պարզեք դրա տեսակը, սեփականատիրոջը, հասանելիության շրջանակը և այն օգտագործող ծառայությունները։ Այն չեղարկեք մատակարարի մոտ, ստեղծեք փոխարինող արժեք, եթե անհրաժեշտ է, և թարմացրեք կախված ծառայությունները։ Բարձր ռիսկի բանալու դեպքում չեղարկումն առաջնահերթ է․ եթե դա կարող է ընդհատել ծառայությունը, նոր բանալու ներդրումն ու հնի անջատումը համակարգեք պատասխանատու թիմի հետ։

Այնուհետև ստուգեք մատակարարի ու հասանելի GitHub մատյանները՝ հնարավոր չարտոնված օգտագործումը գնահատելու համար։ Փնտրեք գաղտնիքի մյուս օրինակները կոդում, ճյուղերում և commit-ների պատմության մեջ։ Պատմության մաքրումը կարող է պահանջել համակարգված վերագրում, իսկ ուրիշների պատճեններում կամ pull request-ներում արժեքը կարող է պահպանվել նաև դրանից հետո։ Անվտանգության alert-ը փակեք որպես չեղարկված միայն այն ժամանակ, երբ հին գաղտնիքն անգործուն է, և դրանից կախված ծառայությունները տեղափոխված են նոր արժեքի։

Կարդացեք նաև:

Կիսվել: