GitHub ने गुप्त कुंजी रोकी? ‘बाद में ठीक करूँगा’ उसे उजागर छोड़ सकता है

GitHub की Push Protection व्यवस्था समर्थित गुप्त कुंजी वाला पुश रोक सकती है; रिपॉजिटरी स्तर पर ‘I'll fix it later’ चुनकर रोक पार करने से खुली सुरक्षा चेतावनी बनती है। यदि चेतावनी में असली API कुंजी या टोकन दिखे, तो उसे हर प्रभावित कमिट से हटाकर पुश दोहराएँ। बाईपास से पुश पूरा हो सकता है, लेकिन कुंजी भी रिपॉजिटरी तक पहुँच सकती है।

यदि वही कुंजी पहले किसी दूरस्थ रिपॉजिटरी या दूसरी साझा जगह पहुँच चुकी है, तो उसे जारी करने वाली सेवा में अमान्य करें और ज़रूरत हो तो नई कुंजी जारी करें। OWASP का गुप्त मान प्रबंधन मार्गदर्शन लीक हो चुके पहचान मान को समझौता-ग्रस्त मानकर अमान्य करने की सलाह देता है: बाद में कोड से हटाने पर पहले मिली पहुँच समाप्त नहीं होती। केवल स्थानीय कमिट में मौजूद, सफलतापूर्वक रोकी गई कुंजी के बारे में पहले जाँचें कि वह कहीं और साझा तो नहीं हुई थी।

पहले तय करें: असली कुंजी है या गलत पहचान

चेतावनी में बताए कुंजी के प्रकार, फ़ाइल के रास्ते और प्रभावित कमिट को देखें। संबंधित सेवा के कुंजी प्रबंधन पृष्ठ या अपनी टीम के रिकॉर्ड से पता करें कि दिखाया गया मान सक्रिय पहचान मान है, निष्क्रिय परीक्षण मान है या केवल कुंजी जैसी दिखने वाली अक्षर शृंखला। जाँच के लिए पूरा मान सार्वजनिक टिकट, टिप्पणी या किसी अनजान ऑनलाइन सेवा में न चिपकाएँ; ऐसा करना जाँच के दौरान ही उसे साझा कर देगा।

मान वास्तव में कुंजी नहीं है तो ‘It's a false positive’ वाला बाईपास कारण चुनें। ‘It's used in tests’ तभी उचित है जब परीक्षण मान निष्क्रिय हो और उससे किसी वास्तविक संसाधन तक पहुँच न मिले। यदि उसकी स्थिति स्पष्ट नहीं है, उसे असली कुंजी मानकर कमिट से हटाना अधिक सुरक्षित निर्णय है। कारण चुनने भर से सक्रिय कुंजी निष्क्रिय नहीं होती और वह कोड में मौजूद रहती है।

कुछ रिपॉजिटरी में बाईपास के लिए अलग अनुमति माँगनी पड़ सकती है। विकल्प न दिखने पर चेतावनी में दिए रास्ते से अनुमति का अनुरोध किया जा सकता है, पर वास्तविक कुंजी के मामले में उसे हटाकर पुश करना सीधे समस्या सुलझाता है। यदि आपने ‘I'll fix it later’ चुना था, तो खुले अलर्ट को लंबित सुधार समझें। व्यक्तिगत खाते की सुरक्षा के तहत सार्वजनिक रिपॉजिटरी में किया गया बाईपास अलग स्थिति है: रिपॉजिटरी स्तर की Push Protection चालू न हो तो उससे अलर्ट बनना आवश्यक नहीं है।

रोके गए कमिट से कुंजी कैसे निकालें

मौजूदा फ़ाइल साफ़ करके नया कमिट जोड़ना पर्याप्त नहीं हो सकता, क्योंकि पहले वाला कमिट भी पुश का हिस्सा रहता है। GitHub की कमांड लाइन हिदायत के अनुसार, रोक हटाने के लिए गुप्त मान उन सभी कमिट से निकालना होता है जिनमें वह दिखाई देता है। त्रुटि संदेश में कमिट और फ़ाइल का रास्ता देखें; उसी मान की कई जगह मौजूदगी हो तो हर स्थान सुधारें।

यदि कुंजी सबसे नए स्थानीय कमिट में आई थी, तो फ़ाइल से मान हटाकर उसी कमिट को संशोधित करें। इसके लिए git commit --amend --all के बाद पुश दोहराया जा सकता है। अलग सफ़ाई कमिट बनाने से पुराना, कुंजी वाला कमिट इतिहास में बना रहेगा। बदलाव दर्ज करने से पहले यह भी देख लें कि हटाई गई कुंजी किसी दूसरी फ़ाइल या कमिट संदेश में तो नहीं गई थी।

कुंजी किसी पुराने स्थानीय कमिट में आई हो तो शाखा का इतिहास देखकर उसे सबसे पहले जोड़ने वाला कमिट पहचानें। फिर इंटरैक्टिव रीबेस से उस कमिट को सुधारें और आगे के कमिट पूरे होने दें। रीबेस के बाद प्रभावित शृंखला दोबारा जाँचें; अगला पुश फिर रुकता है तो नई चेतावनी में दिखे कमिट और रास्ते पर ध्यान दें। साझा शाखा का इतिहास बदलने से सहयोगियों के काम पर असर पड़ सकता है, इसलिए पहले उनसे समन्वय करें।

वेब पर फ़ाइल बनाते या बदलते समय रोक मिली हो तो बदलाव जमा करने से पहले वहीं से कुंजी हटाएँ। उसकी जगह कोई नई सक्रिय कुंजी लिखना समाधान नहीं है: वह भी कोड में चली जाएगी। अनुप्रयोग को नई कुंजी चाहिए तो उसे उपयुक्त गुप्त मान प्रबंधक या परिनियोजन व्यवस्था से दें। रिपॉजिटरी में केवल ऐसा विन्यास नमूना रखें जिसमें काम करने वाली कुंजी मौजूद न हो।

पहले साझा हुई कुंजी बदलने का क्रम

पहले भेजी गई कुंजी के लिए प्राथमिक काम उसकी पहुँच समाप्त करना है। उसे जारी करने वाली सेवा के प्रबंधन पृष्ठ पर पुराना मान अमान्य करें और जिस अनुप्रयोग को उसकी ज़रूरत है, उसके लिए नया मान जारी करें। यदि सेवा चलती रहनी चाहिए, तो नई कुंजी सुरक्षित भंडार में रखने, अनुप्रयोग का विन्यास बदलने और पुरानी कुंजी रद्द करने का क्रम तय करें। बदलाव के दौरान पुरानी कुंजी को आवश्यकता से अधिक समय सक्रिय न छोड़ें।

कुंजी केवल GitHub पर पहुँची थी या कहीं और भी गई थी, इसका जवाब हमेशा चेतावनी से नहीं मिलता। संबंधित शाखाओं, पहले भेजी गई प्रतियों और साझा किए गए विन्यास को देखें। पहुँच का दायरा तय न हो पा रहा हो तो कुंजी बदलना सावधान निर्णय है; किसी रोके गए स्थानीय पुश को अपने आप सार्वजनिक लीक मानना भी सही नहीं होगा। यह अंतर इसलिए मायने रखता है कि स्थानीय कमिट सुधारने और पहले से साझा पहचान मान रद्द करने के काम अलग हैं।

इतिहास जाँचें, फिर सफ़ाई का दायरा तय करें

नई कुंजी सुरक्षित रखने के बाद देखें कि पुराना मान किसी दूसरी शाखा, पुराने कमिट, पुल अनुरोध या साझा प्रति में बचा है या नहीं। GitHub की इतिहास सफ़ाई संबंधी हिदायत बताती है कि इतिहास दोबारा लिखने के बाद भी संवेदनशील सामग्री क्लोन, फ़ोर्क या पुल अनुरोधों के संदर्भ में उपलब्ध रह सकती है। इसलिए प्रकाशित इतिहास बदलना हो तो प्रभावित प्रतियों के मालिकों और सहयोगियों के साथ काम करना पड़ता है।

इतिहास दोबारा लिखने से कमिट की पहचान बदलती है; पुरानी प्रतियाँ रखने वाले सहयोगी वही सामग्री फिर पुश कर सकते हैं। पुल अनुरोधों की टिप्पणियों और शाखाओं पर भी असर पड़ सकता है। यदि पहचान मान अमान्य हो चुका है, तो उससे मिलने वाली पहुँच समाप्त हो जाती है; इसके बाद इतिहास की सफ़ाई का निर्णय बची सामग्री और साझा प्रतियों के आधार पर लें। खुले बाईपास अलर्ट का निपटारा करते समय दर्ज करें कि पुरानी कुंजी रद्द हुई, प्रभावित स्थान देखे गए और नई कुंजी कोड के बाहर रखी गई है।

यह भी पढ़ें:

• GitHub CLI अपडेट रुक गया? पुरानी Linux कुंजी बदलना जरूरी
• भारत में गिग काम 6 मिलियन पार, पर 90% इसे अंशकालिक क्यों रखते हैं
• Shorts में संगीत लगाएँ या नहीं: 45% हिस्सा फिर भी समान क्यों है