गिटहब कृतींसाठी व्यावहारिक सुरक्षा कडक करणे

होम पेज » python ला » गिटहब कृतींसाठी व्यावहारिक सुरक्षा कडक करणे

गिटहब अ‍ॅक्शन्स हे गिटहबवर होस्ट केलेल्या रिपॉझिटरीजसाठी डी-फॅक्टो सीआय/सीडी इंजिन बनले आहे., युनिट चाचण्यांपासून ते उत्पादन तैनाती आणि पायाभूत सुविधांमध्ये बदल करण्यापर्यंत सर्वकाही सक्षम करते. ही सोय गंभीर व्यापार-बंदसह येते: वर्कफ्लो बहुतेकदा व्यापक विशेषाधिकारांसह चालतात, शक्तिशाली टोकन आणि गुपिते हाताळतात आणि थेट उत्पादन प्रणालींपर्यंत पोहोचू शकतात. जर तुम्ही त्यांना जाणूनबुजून कठोर केले नाही, तर तुम्ही प्रभावीपणे प्रत्येक चुकीची कॉन्फिगरेशन, अवलंबित्व बग किंवा तडजोड केलेल्या खात्याला तुमच्या पाइपलाइन आणि क्लाउड खात्यांमध्ये जलद मार्ग देत आहात.

हे मार्गदर्शक गिटहब अ‍ॅक्शन्स एंड टू एंड सुरक्षित करण्यासाठी विस्तृत, मतप्रणालीबद्ध चेकलिस्टमधून जाते.: गुपिते योग्यरित्या कशी हाताळायची, स्क्रिप्ट इंजेक्शन टाळायचे, टोकन आणि ट्रिगर्स लॉक कसे करायचे, तृतीय-पक्ष कृतींचे मूल्यांकन कसे करायचे, धावपटूंचे व्यवस्थापन कसे करायचे आणि कोड स्कॅनिंग, OIDC, Dependabot आणि ऑडिट लॉग सारख्या अंगभूत सुरक्षा वैशिष्ट्यांचा फायदा कसा घ्यायचा. विखुरलेल्या सर्वोत्तम पद्धती, अलीकडील घटनांमधून मिळवलेले धडे आणि GitHub चे स्वतःचे कठोर मार्गदर्शन एकाच, व्यावहारिक संदर्भात एकत्र आणणे हे ध्येय आहे जे तुम्ही वास्तविक प्रकल्पांमध्ये लागू करू शकता.

गिटहब अ‍ॅक्शन्सचे खरे जोखीम प्रोफाइल

उच्च पातळीवर, GitHub Actions वर्कफ्लो ही फक्त एक YAML फाइल आहे .github/workflows जे एक किंवा अधिक जॉब्स परिभाषित करते, प्रत्येक जॉब्स स्टेप्सने बनलेले असतात. स्टेप्स शेल कमांड चालवू शकतात किंवा गिटहब किंवा कम्युनिटीद्वारे प्रकाशित केलेल्या पुन्हा वापरता येण्याजोग्या कृतींना आवाहन करू शकतात. वर्कफ्लो पुश, पुल रिक्वेस्ट, इश्यू अ‍ॅक्टिव्हिटी, शेड्यूल किंवा मॅन्युअल डिस्पॅच सारख्या इव्हेंट्सद्वारे ट्रिगर केले जातात.

सुरक्षेच्या दृष्टिकोनातून, ते कार्यप्रवाह तुमच्या सॉफ्टवेअर पुरवठा साखळीच्या अगदी वर असतात.. ते रिलीज आर्टिफॅक्ट्स तयार करतात आणि त्यावर स्वाक्षरी करतात, डॉकर इमेजेस पुश करतात, क्लाउड एन्व्हायर्नमेंट्समध्ये तैनात करतात, पायाभूत सुविधांची तरतूद करतात, मायग्रेशन चालवतात आणि बरेच काही करतात. जर एखादा आक्रमणकर्ता विशेषाधिकारित वर्कफ्लो चालणारा कोड, कॉन्फिगरेशन किंवा वातावरण नियंत्रित करू शकतो, तर ते अनेकदा हे करू शकतात:

• बॅकडोअरने संकलित केलेल्या कलाकृती (बायनरी, कंटेनर, पॅकेजेस) जे तुम्ही नंतर ग्राहकांना पाठवता.
• शक्तिशाली दीर्घायुषी चिन्हे आणि गुपिते बाहेर काढा मेमरी, लॉग, कॅशे किंवा कलाकृतींमधून.
• विशेषाधिकारप्राप्त क्लाउड भूमिकांचा गैरवापर करा CI ला अतिरिक्त सेवा तैनात करण्यासाठी, नेटवर्किंगमध्ये बदल करण्यासाठी किंवा डेटा अॅक्सेस करण्यासाठी परवानगी दिली आहे.
• पॉयझन डाउनस्ट्रीम प्रकल्प ओपन-सोर्स रिलीज पाइपलाइनशी तडजोड करून आणि ट्रोजनाइज्ड रिलीझ वितरित करून.

अलीकडील वास्तविक जगातील घटनांनी अधोरेखित केले आहे की गिटहब अॅक्शन्स आक्रमण पृष्ठभाग म्हणून किती आकर्षक आहे.. हल्लेखोरांनी प्रकाशित पॅकेजेसमध्ये क्रिप्टोमायनर्स इंजेक्ट करण्यासाठी असुरक्षित वर्कफ्लोचा गैरवापर केला आहे आणि लोकप्रिय tj-actions/changed-files कॉइनबेसपर्यंत पोहोचण्याचा प्रयत्न करणाऱ्या एका बहु-स्तरीय हल्ल्यात कारवाई धोक्यात आली. दुर्भावनापूर्ण कोडने वर्कफ्लोमधून गुपिते काढली आणि ती बिल्ड लॉगमध्ये लिहिली, ज्यामुळे फॉलो-ऑन पुरवठा साखळी तडजोडींचा संभाव्य कॅस्केड तयार झाला.

लक्षात ठेवण्याची मुख्य कल्पना म्हणजे बहुतेक गिटहब अॅक्शन हल्ले "संभाव्यता × परिणाम" बद्दल असतात.. तुम्हाला दुर्भावनापूर्ण किंवा बग्गी घटक (तृतीय-पक्ष कृती, असुरक्षित धावपटू, धोकादायक ट्रिगर्स) वापरण्याची शक्यता कमी करायची आहे, आणि त्याच वेळी जर कोणताही एक घटक धोक्यात आला तर ब्लास्ट रेडियस नाटकीयरित्या मर्यादित करायचा आहे.

गिटहब अ‍ॅक्शन्समध्ये गुपिते लॉक करणे

कोणत्याही CI/CD सिस्टीममध्ये गुपिते हे सहसा सर्वात आकर्षक लक्ष्य असते.. GitHub Actions मध्ये ते रिपॉझिटरी, ऑर्गनायझेशन किंवा एन्व्हायर्नमेंटल सिक्रेट्स म्हणून दिसतात आणि अॅड-हॉक व्हॅल्यूज म्हणून तुम्ही चुकून कॉन्फिग, लॉग, कॅशे किंवा आर्टिफॅक्ट्समध्ये टाकू शकता.

पहिली गोष्ट जी आपण आत्मसात करायची आहे ती म्हणजे अ‍ॅक्सेस मॉडेल: रिपॉझिटरीमध्ये लेखन अ‍ॅक्सेस असलेला कोणीही रिपॉझिटरी-स्तरीय सर्व गुपिते प्रभावीपणे वाचू शकतो.. ते फक्त संरक्षित नसलेल्या शाखेवरील विद्यमान वर्कफ्लोमध्ये बदल करू शकतात, लॉगिंग किंवा एक्सफिल्टरेशन कोड इंजेक्ट करू शकतात आणि गुपिते प्रिंट करण्यासाठी किंवा लीक करण्यासाठी तो वर्कफ्लो चालवू शकतात. गिटहबचे लॉगमध्ये मास्किंग करणे ही सर्वोत्तम प्रयत्नांची सुरक्षा आहे, अचूक हमी नाही.

त्या मॉडेल अंतर्गत गुपिते टिकवून ठेवण्यासाठी, या मूलभूत नियमांचे पालन करा:

• किमान विशेषाधिकाराचे तत्व लागू करा: वर्कफ्लोमध्ये वापरल्या जाणाऱ्या कोणत्याही क्रेडेन्शियलमध्ये त्याला आवश्यक असलेल्या किमान परवानग्या असणे आवश्यक आहे. सामान्य उद्देशाचे अ‍ॅडमिन टोकन वर्कफ्लो सिक्रेट्स म्हणून शेअर करणे टाळा.
• संवेदनशील मूल्यांसाठी भांडार किंवा संस्थेच्या गुपित्यांपेक्षा पर्यावरणीय गुपिते पसंत करा.. पर्यावरणीय गुपिते फक्त त्या नोकऱ्यांसाठी उपलब्ध आहेत जी त्या पर्यावरणाची घोषणा करतात आणि तुम्ही त्यांना आवश्यक पुनरावलोकनकर्ते आणि शाखा निर्बंध यासारख्या अतिरिक्त संरक्षणांमध्ये गुंडाळू शकता.
• वर्कफ्लो YAML फायलींमध्ये कधीही साध्या मजकूरात गुपिते साठवू नका. किंवा रेपोमध्ये तपासलेल्या कोडमध्ये. संवेदनशील प्रत्येक गोष्ट GitHub Secrets यंत्रणेतून किंवा बाह्य गुप्त व्यवस्थापकातून गेली पाहिजे.
• संरचित ब्लॉब्स (JSON, YAML, XML) एकाच गुप्त मूल्याप्रमाणे वापरणे टाळा.. मास्किंग मुख्यत्वे अचूक स्ट्रिंग जुळणीवर अवलंबून असते; मल्टी-फील्ड ब्लॉब विश्वसनीयरित्या संपादित करणे खूप कठीण असते. त्याऐवजी, संवेदनशील डेटा अनेक समर्पित गुप्त नोंदींमध्ये विभाजित करा.
• सर्व साधित गुपिते स्पष्टपणे नोंदवा.. जर तुम्ही एखादे गुपित (बेस६४, URL-एनकोड, JWT साइनिंग, इ.) रूपांतरित केले आणि ते परिणाम कधीही लॉगवर येऊ शकले, तर रूपांतरित मूल्य त्याचे स्वतःचे गुपित म्हणून नोंदवा जेणेकरून GitHub ते लपवण्याचा प्रयत्न करू शकेल.

रोटेशन आणि स्वच्छता हे सुरुवातीच्या कॉन्फिगरेशनइतकेच महत्त्वाचे आहे.. कोणती गुपिते अस्तित्वात आहेत, कोणाला आणि कशाला त्यांची प्रत्यक्षात आवश्यकता आहे याचे वेळोवेळी पुनरावलोकन करा आणि जुने असलेले कोणतेही गुपिते काढून टाका किंवा फिरवा. कोणत्याही संशयास्पद उघडकीस आल्यानंतर (उदाहरणार्थ, लॉगमध्ये न छापलेले किंवा तडजोड केलेल्या कृतीत वापरलेले गुपिते), प्रभावित लॉग त्वरित हटवा, क्रेडेन्शियल्स रद्द करा आणि नवीन लॉग तयार करा.

स्क्रिप्ट इंजेक्शन आणि असुरक्षित इंटरपोलेशन टाळणे

गिटहब अ‍ॅक्शन्स बग्सच्या सर्वात सामान्य, तरीही सूक्ष्म वर्गांपैकी एक म्हणजे एक्सप्रेशन्सद्वारे स्क्रिप्ट इंजेक्शन.. गिटहब समृद्ध "संदर्भ" प्रदान करते जसे की github, env, secrets आणि इव्हेंट पेलोड्स, ज्याचा तुम्ही वर्कफ्लोमध्ये वापर करून संदर्भ देता ${{ ... }} वाक्यरचना. त्या अभिव्यक्तींचे मूल्यांकन GitHub द्वारे केले जाते आधी तुमचे शेल स्टेप धावते.

जेव्हा तुम्ही अविश्वसनीय संदर्भ थेट शेल कमांडमध्ये एम्बेड करता, तेव्हा तुम्ही कमांड इंजेक्शनला आमंत्रित करता. उदाहरणार्थ, जर तुम्ही असे केले तर:

run: echo "new issue ${{ github.event.issue.title }} created"

आणि आक्रमणकर्ता समस्येचे शीर्षक नियंत्रित करू शकतो, ते असे शीर्षक सबमिट करू शकतात $(id). अभिव्यक्ती मूल्यांकनानंतर पायरी अशी होते:

echo "new issue $(id) created"

जे कार्यान्वित करते id धावपटूवर. शेलमध्ये कितीही कोट्समध्ये बदल केले किंवा साधे व्हॅलिडेशन जोडले तरी तुम्हाला या पॅटर्नपासून वाचवता येणार नाही.

GitHub ने शिफारस केलेला सुरक्षित पॅटर्न म्हणजे इंटरमीडिएट एन्व्हायर्नमेंट व्हेरिअबल वापरणे.:

env:
TITLE: ${{ github.event.issue.title }}
run: |
echo "new issue \"$TITLE\" created"

येथे संभाव्य प्रतिकूल मूल्य पर्यावरण चल म्हणून मेमरीमध्ये राहते., आणि कवच फक्त पाहतो $TITLE, गतिमानपणे बांधलेली कमांड लाइन नाही. तुम्हाला अजूनही सामान्य शेल हायजीनची आवश्यकता आहे (व्हेरिएबल्स उद्धृत करणे, अनावश्यक eval टाळणे इ.), परंतु धोकादायक इंटरपोलेशन पायरी काढून टाकली आहे.

जेव्हा जेव्हा तुम्हाला एम्बेड करण्याचा मोह होईल तेव्हा ${{ github.* }} किंवा इतर वापरकर्ता-नियंत्रित डेटा थेट मध्ये run: अडवा, थांबवा आणि पुढे ढकला env: त्याऐवजी. ही एक सवय तुमच्या वर्कफ्लोमधील स्क्रिप्ट-इंजेक्शन समस्यांचा एक संपूर्ण वर्ग दूर करते.

परवानग्या आणि टोकन सुरक्षितपणे कॉन्फिगर करणे

The GITHUB_TOKEN जर डीफॉल्टवर सोडले तर गिटहब प्रत्येक वर्कफ्लो रनमध्ये इंजेक्ट करतो ते अविश्वसनीयपणे शक्तिशाली आहे.. ते मजकूर वाचू आणि लिहू शकते, पुल रिक्वेस्ट उघडू आणि अपडेट करू शकते आणि रेपोशी अनेक प्रकारे संवाद साधू शकते. ऐतिहासिकदृष्ट्या, अनेक संस्थांना ते लक्षात न येता वाचन-लेखनासाठी डीफॉल्ट केले गेले होते.

तुमचा पहिला कडकपणाचा टप्पा म्हणजे डीफॉल्ट वर्कफ्लो टोकन परवानग्या फक्त वाचनीय वर सेट करणे. संघटना आणि/किंवा रिपॉझिटरी पातळीवर. यासाठी अ‍ॅक्शन कॉन्फिगरेशनमध्ये एक समर्पित सेटिंग आहे. तिथून, तुम्ही निवडकपणे प्रति-वर्कफ्लो किंवा प्रति-जॉब आधारावर अतिरिक्त परवानग्या देता, उदाहरणार्थ:

permissions:
contents: read
pull-requests: write

"डिफॉल्टनुसार नकार द्या, गरज पडल्यास परवानगी द्या" हे मॉडेल हल्लेखोर खराब झालेल्या वर्कफ्लोसह काय करू शकतो ते नाटकीयरित्या कमी करते.. हे लेखकांना कॅच-ऑल टोकन वारशाने मिळण्याऐवजी त्यांच्या कामासाठी प्रत्यक्षात कोणत्या क्षमतांची आवश्यकता आहे याचा विचार करण्यास भाग पाडते.

जर तुमची संस्था २०२३ च्या सुरुवातीपूर्वी तयार केली गेली असेल, तर तुम्ही या डीफॉल्ट्सचे स्पष्टपणे ऑडिट करावे.. अनेक जुन्या संस्थांकडे अजूनही लेखन-सक्षम वर्कफ्लो टोकन आहेत कारण ते सुरक्षित डीफॉल्टच्या आधीपासून आहेत आणि कधीही बदल निवडले नाहीत.

टोकन स्कोप व्यतिरिक्त, GitHub Actions ला पुल रिक्वेस्ट मंजूर करू देणाऱ्या किंवा तयार करू देणाऱ्या सेटिंग्जबद्दल खूप सावधगिरी बाळगा.. रबर-स्टॅम्प पीआरला वर्कफ्लोला परवानगी दिल्याने तुम्हाला अशा मार्गांचा गैरवापर करण्याची संधी मिळते जिथे तडजोड केलेल्या नोकऱ्या मानवी पुनरावलोकनाशिवाय दुर्भावनापूर्ण कोड विलीन करतात. जोपर्यंत तुमच्याकडे मजबूत वापर केस आणि कडक रेलिंग नाहीत, तोपर्यंत ते वैशिष्ट्य अक्षम ठेवा.

तृतीय-पक्ष कृती निवडणे आणि पिन करणे

तुम्ही वापरत असलेली प्रत्येक बाह्य क्रिया ही रिमोट कोडचा एक भाग असते जी तुमच्या उर्वरित कामांसारख्याच विशेषाधिकारांसह चालते.. जर ती कृती दुर्भावनापूर्ण झाली, तडजोड केली गेली किंवा असुरक्षित अवलंबित्वांसह सोडून दिली गेली, तर ती तुमच्या पाइपलाइनमध्ये एक तयार पाया बनते.

तृतीय-पक्ष कृती वापरताना तुम्ही संरक्षणाचे अनेक स्तर लागू करू शकता.:

• एका लहान, विश्वसनीय अनुमती यादीपासून सुरुवात करा. GitHub-देखभाल केलेल्या कृती (जसे की actions/checkout, actions/setup-node) आणि सत्यापित निर्मात्यांकडून मार्केटप्लेस कृती सहसा रँडम रिपोपेक्षा सुरक्षित बेसलाइन असतात. अनेक संस्था संघटना स्तरावर "निर्दिष्ट कृती आणि पुन्हा वापरता येण्याजोग्या वर्कफ्लोला परवानगी द्या" द्वारे हे लागू करतात.
• लोकप्रिय, सक्रियपणे राखलेल्या कृतींना प्राधान्य द्या. संशोधनातून असे दिसून आले आहे की अनेक मार्केटप्लेस कृतींमध्ये कमी ओपनएसएसएफ स्कोअरकार्ड स्कोअर, एकल देखभाल करणारे आणि अल्पकालीन किंवा खूप तरुण मालक खाती असतात. मोठ्या प्रमाणावर वापरल्या जाणाऱ्या कृतींमध्ये अधिक छाननी आणि जलद निराकरणे जमा होतात.
• अ‍ॅक्शनच्या रेपोमध्ये मोठ्या संख्येने ओपन डिपेंडबॉट पीआर पहा.. हे बहुतेकदा असे लक्षण असते की देखभालकर्ता सुरक्षा अद्यतने लागू करत नाही, ज्यामुळे संक्रमणात्मक भेद्यता अनपॅच राहते.
• एकापेक्षा जास्त देखभालकर्ता आणि संग्रहित नसलेला, सक्रिय कोडबेस असलेल्या कृतींना प्राधान्य द्या.. मार्केटप्लेसमधील शेकडो कृती संग्रहित केल्या जातात, याचा अर्थ असा की कोणतेही नवीन दुरुस्त्या किंवा सुसंगतता अद्यतने नाहीत आणि कालांतराने वाढत जाणारा धोका नाही.

आवृत्ती पिनिंग हा आणखी एक महत्त्वाचा विषय आहे.. जर तुम्ही फक्त टॅगद्वारे कृती निर्दिष्ट केली तर, जसे की some-org/some-action@v2, तुम्हाला विश्वास आहे की टॅग कधीही दुर्भावनापूर्ण कोडमध्ये जात नाही. जर देखभालकर्ता खाते किंवा रिपॉझिटरी धोक्यात आली असेल तर टॅग्ज पुन्हा लक्ष्यित केले जाऊ शकतात.

आजचा सर्वात बचावात्मक दृष्टिकोन म्हणजे पूर्ण कमिट SHA वर पिन करणे.:

uses: some-org/some-action@247835779184621ab13782ac328988703583285a

SHA वर पिन केल्याने कोड तुमच्या दृष्टिकोनातून प्रभावीपणे अपरिवर्तनीय बनतो. (Git ऑब्जेक्ट्सवर SHA-1 टक्कर हल्ल्यापेक्षा कमी). तोटा हा कार्यरत आहे: जेव्हा तुम्हाला नवीन वैशिष्ट्ये किंवा निराकरणे हवी असतील तेव्हा तुम्हाला SHA अपडेट करावे लागेल आणि जर तुम्ही काळजी घेतली नाही तर वेगवेगळे वर्कफ्लो वेगवेगळ्या SHA मध्ये जाऊ शकतात.

ती वेदना कमी करण्यासाठी, काही संघ तृतीय-पक्ष कृती वापर सामायिक किंवा संमिश्र कार्यप्रवाहांमध्ये केंद्रीकृत करतात.. वैयक्तिक रिपोज त्या शेअर केलेल्या वर्कफ्लोजना टॅगद्वारे संदर्भित करतात, तर शेअर केलेले वर्कफ्लोज अंतर्निहित कृतींना पडताळलेल्या SHAs वर पिन करतात आणि नियंत्रित कॅडेन्सवर अपडेट केले जातात, कधीकधी नवीन SHAs साठी PR उघडणाऱ्या टूलिंगसह.

तुम्ही कोणतीही रणनीती निवडा, लक्षात ठेवा की पिनिंग ही जादूची फायरवॉल नाही.. एखादी क्रिया रनटाइमवरही गतिमानपणे कोड आणू शकते (उदाहरणार्थ curl | bash पॅटर्न) आणि तुमचा पिन बायपास करा. गुप्त किंवा लेखन-सक्षम टोकन असलेल्या कृतीवर विश्वास ठेवण्यापूर्वी तुम्हाला स्पष्टपणे असुरक्षित पॅटर्नसाठी स्रोत स्किम करणे आवश्यक आहे.

सुरक्षित कार्यप्रवाह आणि नोकऱ्या डिझाइन करणे

तुम्ही वर्कफ्लो आणि जॉब्सची रचना कशी करता याचा तडजोडीच्या ब्लास्ट रेडियसवर जोरदार परिणाम होतो.. एक सामान्य अँटी-पॅटर्न म्हणजे एकच महाकाय काम जे कोड तपासते, बिल्ड करते, चाचण्या करते, पॅकेजेस आणि डिप्लॉय करते, सर्व काही व्यापक परवानग्या आणि उत्पादन गुपिते मिळवतानाच.

कामाचे वेगवेगळ्या कामांमध्ये आणि अगदी वेगळ्या वर्कफ्लोमध्ये विभाजन केल्याने वेगळेपणा आणि स्पष्टता दोन्ही मिळते.. उदाहरणार्थ, तुमच्याकडे असू शकते:

• A बांधणी आणि चाचणीचे काम जे कमीत कमी परवानग्यांसह चालते आणि कोणत्याही तैनाती गुपितेशिवाय.
• A पॅकेज जॉब जे स्वाक्षरी केलेल्या कलाकृती तयार करते पण तरीही उत्पादनाशी बोलत नाही.
• A काम तैनात करा जे इतरांवर अवलंबून असते आणि पर्यावरणीय गुपिते मिळविण्यास आणि ढगांची भूमिका स्वीकारण्यास परवानगी असलेला एकमेव आहे.

GitHub-होस्ट केलेल्या रनर्सवर, वर्कफ्लोमधील प्रत्येक जॉब एका नवीन VM मध्ये चालतो., जे तुम्हाला नोकऱ्यांमध्ये काही प्रमाणात वेगळेपणा देते. हे कठोर सँडबॉक्ससारखे नाही आणि तेथे ज्ञात क्रॉस-जॉब व्हेक्टर आहेत (जसे की शेअर्ड ब्रांच कॅशे), परंतु जॉब्स विभाजित केल्याने हल्लेखोरांना अजूनही अधिक कठोर परिश्रम करावे लागतात आणि असंबंधित चरणांमध्ये गुपिते अपघाती गळती कमी होते.

संवेदनशील पावले संरक्षणाशी जोडण्यासाठी वातावरणाचा वापर करा. तैनाती नोकरी घोषित करू शकते:

environment: production

आणि ते production त्यानंतर वातावरण केवळ संरक्षित शाखेतून तैनाती स्वीकारण्यासाठी कॉन्फिगर केले जाऊ शकते, कदाचित अनिवार्य मॅन्युअल मंजुरीसह. हे कठोर शाखा संरक्षण नियमांसह (आवश्यक पुनरावलोकने, जलद-पुढे पुश नाही, जुनी मंजुरी रद्द करणे) एकत्रित केल्याने तुम्हाला उत्पादन बदलांसाठी चार-डोळ्यांच्या तत्त्वाच्या जवळ पोहोचवता येते.

शेवटी, कलाकृती, कॅशे आणि नोंदींबाबत काळजी घ्या.. ते नोकऱ्या आणि वर्कफ्लो दरम्यान डेटा शेअर करण्याचे सोयीस्कर मार्ग आहेत, परंतु:

• गुपिते कॅशेमध्ये जमा करू नका., विशेषतः ज्या ठिकाणी फारशी माहिती नाही अशा ठिकाणी जसे की ~/.docker/config.json ज्यामध्ये साधे डॉकर क्रेडेन्शियल्स असू शकतात.
• गुपिते लॉग करणे किंवा संपूर्ण संदर्भ लॉगमध्ये टाकणे टाळा., कारण हे मास्किंगला पराभूत करू शकते किंवा GitHub ला संपादित करायला माहित नसलेली व्युत्पन्न मूल्ये उघड करू शकते.
• लक्षात ठेवा की रेपोमध्ये वाचन प्रवेश असलेले कोणीही सहसा कलाकृती डाउनलोड करू शकते आणि लॉग ब्राउझ करू शकते., जर तुम्ही त्यांना प्रवेश दिला तर बाहेरील सहयोगींचा समावेश करा.

ओआयडीसी आणि अल्पकालीन क्लाउड क्रेडेन्शियल्स

तुम्ही करू शकता अशा सर्वात प्रभावी बदलांपैकी एक म्हणजे दीर्घकाळ टिकणारे क्लाउड प्रोव्हायडर क्रेडेन्शियल्स गिटहब सिक्रेट्स म्हणून पूर्णपणे संग्रहित करणे थांबवणे.. त्याऐवजी, एका विशिष्ट वर्कफ्लो ओळखीशी जोडलेले अल्पकालीन, चांगल्या प्रकारे व्यापलेले टोकन मिळविण्यासाठी OpenID Connect (OIDC) वापरा.

उच्च-स्तरीय प्रवाह सोपा आहे:

• तुमचा क्लाउड प्रोव्हायडर (AWS, Azure, GCP, इ.) GitHub च्या OIDC प्रोव्हायडरवर विश्वास ठेवण्यासाठी कॉन्फिगर केलेला आहे.
• तुम्ही एक ओळख धोरण परिभाषित करता जे म्हणते की "फक्त या संस्थेकडून/रेपो/शाखा किंवा वातावरणातून टोकन स्वीकारा".
• कामाच्या दरम्यान, GitHub OIDC टोकनची विनंती करू शकते आणि तुमचा वर्कफ्लो क्लाउड-विशिष्ट कृती वापरतो (उदाहरणार्थ aws-actions/configure-aws-credentials) अल्पकालीन भूमिका किंवा सेवा खाते टोकनसाठी ते बदलण्यासाठी.

विश्वासाची स्थिती अशी आहे जिथे तुम्हाला खूप बारीक मिळू शकते. AWS साठी, एका सामान्य धोरणात हे समाविष्ट असू शकते:

"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:Org/Repo:ref:refs/heads/main"
}

हे सुनिश्चित करते की केवळ विशिष्ट रेपो आणि शाखेतील कार्यप्रवाह ही भूमिका घेऊ शकतात.. जर तुम्हाला आणखी कडक स्कोपिंग हवे असेल, तर तुम्ही ही भूमिका शाखेऐवजी एका विशिष्ट वातावरणाशी जोडू शकता आणि नंतर फक्त तैनातीच्या कामासाठी ते वातावरण आवश्यक करू शकता. नॉन-डिप्लॉय जॉबमध्ये तडजोड केलेल्या तृतीय-पक्षाच्या कृतीमुळे OIDC कॉल्स फक्त अयशस्वी होतील.

OIDC वापरल्याने क्लाउडमध्ये कमीत कमी विशेषाधिकार भूमिका धोरणांची आवश्यकता दूर होत नाही., परंतु ते GitHub Secrets मध्ये बसलेल्या स्टॅटिक अॅक्सेस की काढून टाकते, जिथे त्या चोरीला जाऊ शकतात आणि GitHub च्या बाहेरून अनिश्चित काळासाठी पुन्हा वापरल्या जाऊ शकतात.

शाखा संरक्षण, नियम आणि वातावरण एकत्र काम करणे

गिटहब अ‍ॅक्शन्समधील अनेक भयानक हल्ल्याचे मार्ग "हल्लेखोर संरक्षित शाखेत दुर्भावनापूर्ण बदल इंजेक्ट करतो" असे उलगडतात.. शाखा संरक्षण आणि नियम हे तुमचे संरक्षणाचे मुख्य मार्ग आहेत.

सारख्या फांद्यांवर main or production, तुम्हाला सहसा किमान हवे असते:

• विलीन करण्यापूर्वी पुल रिक्वेस्ट आवश्यक आहे - थेट धक्का देण्यास मनाई करा.
• किमान एक (बहुतेकदा अधिक) मंजुरी देणारा आढावा आवश्यक आहे शेवटच्या धक्का देणाऱ्या व्यक्तीशिवाय दुसऱ्या कोणाकडून तरी.
• नवीन कमिट जोडल्यावर जुन्या मंजुरी रद्द करा. - जेणेकरून पुनरावलोकनानंतर हल्लेखोर कोडमध्ये घुसू शकणार नाहीत.
• सर्वात अलीकडील पुनरावलोकन करण्यायोग्य पुशची मंजुरी आवश्यक आहे - हल्लेखोराला दुसऱ्याचा जनसंपर्क हायजॅक करण्यापासून, चुकीचा कोड पुढे ढकलण्यापासून आणि स्वतःला मान्यता देण्यापासून रोखते.

त्यानंतर तुम्ही हे संरक्षण वातावरणाशी जोडू शकता. उदाहरणार्थ, ए production वातावरण फक्त कडून तैनाती स्वीकारू शकते main शाखा, आणि कदाचित पुनरावलोकनकर्त्यांच्या एका लहान संचाकडून मॅन्युअल मान्यता देखील आवश्यक असेल ("स्वयं-पुनरावलोकन प्रतिबंधित करा" सक्षम करून). अशा प्रकारे, एकल तडजोड केलेले योगदानकर्ता खाते दुसऱ्याच्या स्पष्ट सहभागाशिवाय उत्पादनात अनियंत्रित कोड पाठवू शकत नाही.

तैनातींवर अवलंबून असलेल्या पर्यावरणीय नियमांबद्दल सावधगिरी बाळगा. (उदाहरणार्थ, "टॅग अपडेट्सना परवानगी देण्यापूर्वी यशस्वी होण्यासाठी तैनाती आवश्यक आहे"). जर रचना खराब असेल, तर तुम्ही वर्तुळाकार अवलंबित्वे किंवा छद्म-नियंत्रणे तयार करू शकता ज्यांना सहयोगी वर्कफ्लो संपादित करून बायपास करू शकतो. सर्वात सुरक्षित नमुना अजूनही आहे: मजबूत शाखा संरक्षण → घट्ट व्याप्ती असलेले वातावरण → त्या वातावरणांचा स्पष्ट वापर फक्त अशा किमान कामांमध्ये ज्यांना त्यांची खरोखर गरज आहे.

धावपटूंचे व्यवस्थापन: गिटहब-होस्टेड विरुद्ध सेल्फ-होस्टेड

धावपटू ही अशी मशीन आहेत जी प्रत्यक्षात तुमचे कार्यप्रवाह चालवतात.. गिटहब-होस्टेड रनर्स हे गिटहबद्वारे व्यवस्थापित केलेले तात्पुरते व्हीएम आहेत; सेल्फ-होस्टेड रनर्स हे मशीन किंवा कंटेनर आहेत जे तुम्ही पुरवता आणि नियंत्रित करता.

गिटहब-होस्ट केलेले रनर्स सामान्यतः डीफॉल्टनुसार बरेच सुरक्षित असतात.:

• ते क्षणभंगुर आहेत आणि प्रत्येक कामासाठी रीसेट केले जातात., त्यामुळे धावांमध्ये कोणतीही सतत तडजोड होत नाही.
• गिटहब मानक प्रतिमांसाठी एसबीओएम प्रकाशित करते (उबंटू, विंडोज, मॅकओएस), तुम्हाला पूर्व-स्थापित सॉफ्टवेअरच्या भेद्यतेचे विश्लेषण करण्याची परवानगी देते.
• काही दुर्भावनापूर्ण होस्ट बॉक्सच्या बाहेर ब्लॉक केले जातात. (उदाहरणार्थ, ज्ञात क्रिप्टोमायनिंग पूल) द्वारे /etc/hosts कॉन्फिगरेशन

स्वतःहून धावणारे धावपटू शक्तिशाली असतात पण धोकादायक असतात. जर तुम्ही त्यांना प्रोडक्शन सर्व्हरसारखे वागवले नाही तर:

• जोपर्यंत तुम्ही ते स्वतः तयार करत नाही तोपर्यंत ते सहसा क्षणभंगुर नसतात., त्यामुळे कोणताही दुर्भावनापूर्ण कार्यप्रवाह सतत, बाजूकडील हालचाल किंवा डेटा चोरीचा प्रयत्न करू शकतो.
• त्यांच्याकडे अनेकदा व्यापक नेटवर्क अॅक्सेस आणि स्थानिक गुपिते असतात. (SSH की, क्लाउड CLI, मेटाडेटा सेवा), जे कोणत्याही तडजोडीचे दावे वाढवतात.
• सार्वजनिक भांडारांनी जवळजवळ कधीही स्व-होस्टेड धावपटू वापरू नयेत., कारण कोणीही पुल रिक्वेस्ट उघडू शकते ज्यामुळे तुमच्या इन्फ्रास्ट्रक्चरवर कोड कार्यान्वित होतो.

जर तुम्हाला स्व-होस्टेड धावपटू वापरायचे असतील तर त्यांना विश्वासाच्या सीमांनी कोरून टाका.. धावपटू गट आणि निर्बंध वापरा जेणेकरून:

• सार्वजनिक आणि खाजगी प्रकल्पांमध्ये कधीही समान धावपटूंचा समूह नसतो.
• उच्च-संवेदनशीलता रेपो (उदाहरणार्थ उत्पादन पायाभूत सुविधा) चे स्वतःचे कडक नियंत्रित रनर्स असतात.
• केवळ विशिष्ट रिपॉझिटरीज किंवा संस्था दिलेल्या गटाला नोकऱ्या पाठवू शकतात.

REST API द्वारे प्रदान केलेल्या जस्ट-इन-टाइम (JIT) रनर्ससह तुम्ही जोखीम आणखी कमी करू शकता.. हे रनर्स गतिमानपणे नोंदणी करतात, जास्तीत जास्त एक जॉब चालवतात आणि नंतर आपोआप काढून टाकले जातात. तुम्हाला अजूनही अंतर्निहित होस्ट साफ किंवा नष्ट झाला आहे याची खात्री करावी लागेल, परंतु ते त्या विंडोला अरुंद करते ज्यामध्ये तडजोड केलेले जॉब पुढील जॉबवर परिणाम करू शकते.

इतर कोणत्याही उत्पादन प्रणालीप्रमाणे स्व-होस्ट केलेल्या धावपटूंना वागणूक द्या.: प्रक्रिया क्रियाकलापांचे निरीक्षण करणे, आउटबाउंड नेटवर्क मार्ग लॉक करणे, OS आणि टूल्स पॅच केलेले ठेवणे आणि वर्कफ्लो ट्रिगर करण्याची परवानगी असलेल्या कोणत्याही वापरकर्त्याने त्या मशीनवर प्रभावीपणे कोड एक्झिक्युशन केले आहे असे गृहीत धरणे.

अंगभूत सुरक्षा वैशिष्ट्ये: कोड स्कॅनिंग, स्कोअरकार्ड आणि डिपेंडबॉट

गिटहब वर्कफ्लो आणि अवलंबित्वाच्या जोखमीवर लक्ष केंद्रित करण्यासाठी विशेषतः अनेक प्रथम श्रेणीची वैशिष्ट्ये पाठवते., आणि ते कमी सेटअप खर्चाच्या लायक आहेत.

कोड स्कॅनिंग (उदाहरणार्थ CodeQL सह) आता GitHub Actions वर्कफ्लोचे स्वतः विश्लेषण करू शकते., फक्त तुमचा अॅप्लिकेशन सोर्स नाही. "अतिरिक्त रहस्ये एक्सपोजर" सारखे नियम असे नमुने शोधू शकतात जिथे GitHub कोणते रहस्य आवश्यक आहेत हे ठरवू शकत नाही (उदाहरणार्थ डायनॅमिक secrets[myKey] मॅट्रिक्स बिल्डमध्ये वापर), ज्यामुळे ते जॉब मेमरीमध्ये आवश्यकतेपेक्षा जास्त गुपिते लोड करते.

ओपनएसएसएफ स्कोअरकार्ड्स आणि स्कोअरकार्ड्स अॅक्शन तुमच्या डिपेंडेंशन्सच्या सुरक्षा पोझिशनला ग्रेडिंग देऊन आणखी एक स्तर जोडतात.. बाजारपेठेतील कृतींसाठी, स्कोअरकार्ड असुरक्षित पुरवठा साखळी पद्धतींना ध्वजांकित करू शकतात जसे की:

• अवलंबित्वे पिन करत नाही.
• शाखा संरक्षण किंवा कोड पुनरावलोकन आवश्यकता गहाळ आहेत.
• सुरक्षा धोरण किंवा भेद्यता प्रतिसाद प्रक्रियांचा अभाव.

डिपेंडबॉट येथे दोन भूमिका बजावते.:

• डिपेंडबॉट अलर्ट GitHub अ‍ॅडव्हायझरी डेटाबेसवर आधारित, तुमच्या कृती किंवा वर्कफ्लोवर अवलंबून असलेल्या व्यक्तीमध्ये ज्ञात भेद्यता असल्यास तुम्हाला चेतावणी देते.
• डिपेंडबॉट आवृत्ती आणि सुरक्षा अद्यतने अ‍ॅक्शन व्हर्जन बंप करण्यासाठी आणि असुरक्षित रिलीझ पॅच करण्यासाठी स्वयंचलितपणे पीआर उघडू शकतात.

वर्कफ्लोसाठी अवलंबित्व आलेख हे आणखी एक कमी दर्जाचे वैशिष्ट्य आहे.. GitHub तुमच्या वर्कफ्लो फाइल्सना मॅनिफेस्ट म्हणून हाताळते आणि तुम्हाला दाखवू शकते:

• तुम्ही कोणत्या कृती आणि पुन्हा वापरता येण्याजोग्या कार्यप्रवाहांवर अवलंबून आहात.
• कोणत्या खात्यांकडे किंवा संस्थांकडे त्यांची मालकी आहे.
• तुम्ही कोणत्या आवृत्त्या किंवा SHA पिन केल्या आहेत.

यामुळे "आपण ही तडजोड केलेली कृती कुठे वापरत आहोत?" यासारख्या प्रश्नांची उत्तरे देणे सोपे होते. जेव्हा नवीन सूचना कमी होतात आणि मोठ्या प्रमाणात उपाययोजनांची योजना आखली जाते.

देखरेख, लेखापरीक्षण आणि प्रशासन

सुरक्षा ही कॉन्फिगरेशनवर संपत नाही; कालांतराने काय घडत आहे याची दृश्यमानता देखील तुम्हाला आवश्यक आहे.. गिटहब वापरकर्ता आणि संस्था पातळीवर ऑडिट लॉग आणि सुरक्षा लॉग प्रदान करते.

कृतींच्या दृष्टिकोनातून, ट्रॅक करण्यासारख्या अनेक गोष्टी आहेत:

• गुपितांशी संबंधित घटना, जसे की org.update_actions_secret किंवा रिपॉझिटरी गुप्त बदल. हे संवेदनशील क्रेडेन्शियल्सची निर्मिती, अद्यतन किंवा हटवणे दर्शवितात.
• कार्यप्रवाह आणि नियमांमध्ये बदल: संरक्षण नियम कोणी बदलले, तैनाती कार्यप्रवाह कोणी संपादित केले, पर्यावरण संरक्षण कोणी बदलले.
• नवीन किंवा सुधारित मार्केटप्लेस कृती आणि गिटहब अॅप्स org मध्ये स्थापित केलेले, विशेषतः ज्यांना ब्रॉड रिपॉझिटरी किंवा org स्कोप दिले जातात.

तुम्ही GitHub च्या स्वतःच्या नियंत्रणांना OpenSSF मधील Allstar सारख्या धोरण अंमलबजावणी अॅप्ससह पूरक करू शकता., जे सतत तपासते की रिपॉझिटरीज तुमच्या संस्थेच्या सुरक्षा बेसलाइनचे पालन करतात (शाखा संरक्षण, कोड स्कॅनिंग सक्षम, आवश्यक पुनरावलोकने इ.).

"चालू कार्यप्रवाह" बाजूला, गैरवापर सूचित करू शकणाऱ्या नमुन्यांवर लक्ष ठेवा.: जॉब रनटाइममध्ये असामान्य वाढ, रनर्सकडून अनपेक्षित आउटबाउंड ट्रॅफिक, किंवा गुपिते किंवा OIDC टोकन हाताळणाऱ्या पायऱ्यांमध्ये वारंवार अयशस्वी होणारे जॉब. हे नेहमीच दुर्भावनापूर्ण नसतात, परंतु तपास सुरू करण्यासाठी ते चांगले ठिकाण आहेत.

हे सर्व एकत्र करणे म्हणजे तुमच्या मुख्य उत्पादन पृष्ठभागाचा भाग म्हणून गिटहब अॅक्शनचा विचार करणे., फक्त "ग्लू स्क्रिप्ट्स" नाही. काळजीपूर्वक व्याप्ती असलेले रहस्ये आणि टोकन, कठोर शाखा आणि पर्यावरण संरक्षण, तृतीय-पक्ष कृतींचा संयमी वापर, कठोर धावपटू आणि CodeQL, Scorecards आणि Dependabot सारख्या साधनांसह सतत देखरेख, तुम्ही तुमच्या संस्थेला CI/CD आणि पुरवठा साखळी हल्ल्यांच्या वाढत्या वर्गाविरुद्ध लढण्याची संधी देता जे स्पष्टपणे GitHub वर्कफ्लोला लक्ष्य करतात.