GitHub ने सीक्रेट रोका: हटाएँ या सुरक्षित बायपास लें

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

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

चेतावनी को तीन स्थितियों में बाँटें

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

असली सीक्रेट: सक्रिय API कुंजी, टोकन, पासवर्ड, निजी कुंजी या दूसरी साख, जिसका उपयोग प्रमाणीकरण अथवा संसाधन तक पहुँच के लिए हो सकता है।
परीक्षण मान: जानबूझकर रखा गया ऐसा निष्क्रिय मान जो किसी वास्तविक खाते, उत्पादन संसाधन या संवेदनशील डेटा तक पहुँच नहीं देता।
गलत पहचान: सामान्य पाठ या पहचानकर्ता जो समर्थित सीक्रेट के प्रारूप से मिलता है, लेकिन किसी प्रदाता की जारी साख नहीं है।

स्थिति स्पष्ट न हो तो बायपास न करें और सेवा के स्वामी या सुरक्षा दल से पुष्टि लें। जाँच के दौरान पूरा मान चैट, टिकट या बायपास टिप्पणी में न दोहराएँ; संदर्भ देने के लिए फ़ाइल पथ, कमिट पहचान और साख का प्रकार पर्याप्त हो सकता है।

असली सीक्रेट मिले तो पहुँच और कमिट दोनों सुधारें

सबसे पहले संबंधित सेवा में पुरानी साख निरस्त या परिवर्तित करें। फिर कोड में सीधे लिखा मान हटाकर पर्यावरण चर, स्वीकृत सीक्रेट प्रबंधक या परिनियोजन व्यवस्था से उपलब्ध कराएँ। उसी फ़ाइल में नया टोकन लिखना केवल पुरानी समस्या को नई साख के साथ दोहराएगा।

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

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

परीक्षण मान के लिए निष्क्रियता साबित करें

फ़ाइल या निर्देशिका के नाम में “परीक्षण” होना पर्याप्त प्रमाण नहीं है। बायपास से पहले पुष्टि करें कि मान वास्तविक खाते से नहीं जुड़ा, उत्पादन सेवा में स्वीकार नहीं होता और संवेदनशील डेटा नहीं खोल सकता। यदि परीक्षण को काम करने वाली साख चाहिए, तो उसे भंडार में रखने के बजाय परीक्षण वातावरण के सुरक्षित सीक्रेट भंडार से दें।

टिप्पणी में पूरा मान लिखे बिना जाँचने योग्य संदर्भ दें: यह किस परीक्षण ढाँचे का स्थिर नमूना है, सार्वजनिक दस्तावेज़ में कहाँ परिभाषित है, या वास्तविक जारीकर्ता इसे स्वीकार क्यों नहीं कर सकता। जहाँ संभव हो, सीक्रेट जैसा लंबा नमूना स्पष्ट काल्पनिक मान से बदलना बायपास की जरूरत और भविष्य की अस्पष्ट चेतावनियाँ दोनों घटाता है।

गलत पहचान का तकनीकी कारण दर्ज करें

गलत पहचान तभी चुनें जब मिला पाठ किसी प्रदाता की वैध साख नहीं है। उदाहरण के लिए, किसी अनुप्रयोग का यादृच्छिक पहचानकर्ता टोकन के प्रारूप जैसा दिख सकता है; टिप्पणी में उस पहचानकर्ता का निर्माता, उपयोग और प्रमाणीकरण न कर पाने का कारण लिखें।

“यह सुरक्षित है” जैसी टिप्पणी समीक्षक को निर्णय का आधार नहीं देती। फ़ाइल का उद्देश्य, संबंधित विनिर्देश या सार्वजनिक नमूना बताना अधिक उपयोगी है। यदि मान का प्रारूप बदला जा सकता है, तो उसे स्पष्ट पहचानकर्ता में बदलना बार-बार बायपास लेने से बेहतर स्थायी सुधार हो सकता है।

प्रत्यायोजित बायपास की सीमा समझें

हर योगदानकर्ता स्वयं बायपास नहीं कर सकता। प्रत्यायोजित बायपास सक्षम होने पर अधिकार-विहीन योगदानकर्ता का अनुरोध नामित समीक्षकों के पास जाता है; GitHub की बायपास अनुरोध व्यवस्था के अनुसार वे उसे मंजूर या अस्वीकार करते हैं और अनुरोध सात दिन में समाप्त हो जाता है। अस्वीकृति के बाद सफल पुश के लिए सीक्रेट कमिट से हटाना पड़ता है।

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

दोबारा पुश से पहले पाँच जाँच

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

निर्णय का नियम सीधा है: वास्तविक पहुँच देने वाला मान हटाएँ और बदलें, प्रमाणित निष्क्रिय परीक्षण मान के लिए सीमित अपवाद लें, और गलत पहचान में उसका तकनीकी कारण दर्ज करें। श्रेणी तय किए बिना बायपास अवरोध हटा सकता है, सीक्रेट से पैदा हुआ जोखिम नहीं।

यह भी पढ़ें:

GitHub ने सीक्रेट रोका? बायपास से पहले उसे हटाने की सही राह