कोई नया डेवलपर टीम में आता है या कोई कॉन्ट्रैक्टर काम शुरू करता है, तो उसे सबसे पहले वह .env चाहिए होती है जिससे प्रोजेक्ट चलता है। इस फ़ाइल में आमतौर पर बिना जोखिम वाली सेटिंग्स के साथ टीम की सबसे संवेदनशील वैल्यू भी होती हैं। इसीलिए यह इतनी बार किसी डायरेक्ट मैसेज में या “config” नाम वाले ईमेल अटैचमेंट में पहुंच जाती है।
डेवलपर तक कॉन्फ़िग फ़ाइल सुरक्षित तरीके से पहुंचाने के लिए उसे दो हिस्सों में देखें: सेटिंग्स, जो किसी भी रास्ते से जा सकती हैं, और सीक्रेट, जो सिर्फ़ एक बार ऐसे चैनल से जाते हैं जो कोई कॉपी नहीं रखता। यह गाइड बताती है कि दोनों को अलग कैसे करें, सीक्रेट वाला हिस्सा कैसे भेजें, और डेवलपर को क्या बताएं ताकि फ़ाइल पहुंचने के बाद भी सुरक्षित रहे।
फ़ाइल ऐसे पढ़ें जैसे हर लाइन सबके सामने हो
फ़ाइल खोलें और हर लाइन को दो में से एक समूह में रखें।
- सेटिंग्स: लॉग लेवल, पोर्ट, फ़ीचर फ़्लैग, नॉन-प्रोडक्शन एंडपॉइंट, पब्लिक क्लाइंट ID। ये रिपॉज़िटरी में एक example फ़ाइल के रूप में रहनी चाहिए और किसी भी तरीके से भेजी जा सकती हैं।
- सीक्रेट: डेटाबेस पासवर्ड, API keys, साइनिंग सीक्रेट, प्राइवेट कुंजियां, OAuth क्लाइंट सीक्रेट, और ऐसी हर चीज़ जिससे एक्सेस मिलती हो।
PASSWORD,SECRET,TOKEN,KEYऔरPRIVATEखोजें, फिर बाकी फ़ाइल भी पढ़ें, क्योंकि जिस कनेक्शन स्ट्रिंग में पासवर्ड जुड़ा हो, वह खुद को अलग से नहीं दिखाती।
फिर पूछें कि डेवलपर करने क्या जा रहा है। staging के साथ लोकल डेवलपमेंट के लिए staging की वैल्यू चाहिए। उसके लिए प्रोडक्शन keys नहीं चाहिए, और पेमेंट प्रोवाइडर की लाइव key भी सिर्फ़ इसलिए नहीं चाहिए कि वह संयोग से फ़ाइल में मौजूद है।
कमिट की जाने वाली फ़ाइल में सीक्रेट न रखें
कमिट की गई .env.example हर वेरिएबल को एक प्लेसहोल्डर के साथ दर्ज करती है। असली वैल्यू रनटाइम पर एनवायरनमेंट, किसी सीक्रेट मैनेजर या प्लेटफ़ॉर्म के अपने सीक्रेट स्टोर से आती हैं। इस तरीके में आपको सिर्फ़ सीक्रेट वैल्यू भेजनी होती हैं, और ये सब एक साथ सिर्फ़ डेवलपर की लोकल कॉपी में होती हैं।
# .env.example (committed)
DATABASE_URL=postgres://app:CHANGE_ME@staging-db.internal:5432/app
STRIPE_SECRET_KEY=sk_test_CHANGE_ME
SESSION_SECRET=CHANGE_ME
LOG_LEVEL=debug
किसी के पास असली फ़ाइल आने से पहले ही .env को .gitignore में जोड़ दें, और gitleaks जैसा कोई pre-commit hook लगाने पर विचार करें, ताकि गलती से हुआ कमिट तुरंत फ़ेल हो जाए।
जहां हो सके, डेवलपर को उसकी अपनी लॉगिन की जानकारी दें
हैंडओवर साझा लॉगिन बंद करने का भी मौका है। अगर डेटाबेस अलग-अलग यूज़र बनाने देता है, तो डेवलपर के लिए एक यूज़र बनाएं, जिसमें सिर्फ़ उसके काम की अनुमतियां हों और एक्सपायरी की तारीख तय हो। अगर API सीमित keys देता है, तो उसके नाम पर एक key जारी करें। कॉन्ट्रैक्टर को डेटाबेस लॉगिन भेजने वाली गाइड में यही तरीका बताया गया है। जो लॉगिन की जानकारी एक व्यक्ति के लिए बनी है, उसे सिर्फ़ उसी एक व्यक्ति के लिए हटाया भी जा सकता है।
सीक्रेट वैल्यू कैसे भेजें
दो रास्ते काम करते हैं, और दोनों में फ़ाइल किसी मैसेज में पड़ी नहीं रहती।
सीक्रेट वाली लाइनें वन-टाइम लिंक (एक बार खुलने वाले लिंक) में पेस्ट करें। सीक्रेट लिंक टूल खोलें, सिर्फ़ वे लाइनें पेस्ट करें जिनमें सीक्रेट हैं, और लिंक बनाएं। टेक्स्ट स्टोर होने से पहले आपके ब्राउज़र में ही एन्क्रिप्ट होता है, लिंक पहली बार खुलते ही स्टोर की गई कॉपी मिट जाती है, और कोई न खोले तो लिंक एक घंटे, 24 घंटे या सात दिन में एक्सपायर हो जाता है। बिना अकाउंट के 10,000 अक्षर तक आ जाते हैं, जिसमें ज़्यादातर .env फ़ाइलें कई बार समा जाती हैं।
पूरी फ़ाइल सीक्रेट लिंक के साथ अटैच करें। साइन इन किए हुए LinkPilot अकाउंट से आप किसी सीक्रेट के साथ तीन फ़ाइलें तक अटैच कर सकते हैं, हर एक 9 MB तक की। हर फ़ाइल आपके ब्राउज़र में ही ऐसी कुंजी से एन्क्रिप्ट होती है जो उस सीक्रेट की अपनी कुंजी से बनाई जाती है। इसलिए सर्वर के पास कभी सादी फ़ाइल नहीं होती, और इकलौते डाउनलोड के बाद अटैचमेंट मिटा दिया जाता है। जब फ़ाइल को बाइट-दर-बाइट वैसी ही पहुंचना हो, जैसे कोई JSON सर्विस अकाउंट फ़ाइल या keystore, तब यही रास्ता बेहतर है।
दोनों में से जो भी चुनें:
- डेवलपर की पुष्टि करें भर्ती या कॉन्ट्रैक्ट वाले चैनल से, उस पते से नहीं जिसने फ़ाइल मांगी है।
- एक्सपायरी उतनी रखें जितने समय में डेवलपर सच में इसे खोलेगा। डेवलपर इंतज़ार कर रहा हो तो एक घंटा, किसी दूसरे टाइम ज़ोन में हो तो एक दिन।
- व्यू लिमिट एक पर रखें।
- प्रोडक्शन वैल्यू के लिए Pro अकाउंट पर पासफ़्रेज़ जोड़ें, और उसे किसी दूसरे चैनल से भेजें।
- लिंक के साथ एक लाइन का नोट भेजें कि इसमें क्या है और फ़ाइल कहां रखनी है। गैर-सीक्रेट सेटिंग्स अलग से भेजें, या रिपो में example फ़ाइल की तरफ़ इशारा कर दें।
अगर डेवलपर स्थायी कर्मचारी है और आपकी टीम पहले से हर डेवलपर की अलग एक्सेस वाला सीक्रेट मैनेजर चलाती है, तो वॉल्ट का इनविटेशन बेहतर रास्ता है। वन-टाइम लिंक का इस्तेमाल उसके सेटअप होने तक के बीच के समय के लिए करें, और उन लोगों के लिए जो कभी वॉल्ट में नहीं होंगे।
डेवलपर को बताएं कि फ़ाइल कहां रखनी है
ठीक से पहुंचाई गई फ़ाइल भी किसी साझा फ़ोल्डर में चली जाए, तो नतीजा बुरा हो सकता है। कनेक्शन की जानकारी के साथ ये बातें भी भेजें:
- इसे प्रोजेक्ट रूट में
.envनाम से सेव करें, कहीं और नहीं। पहले कमिट से पहले जांच लें कि यह.gitignoreमें शामिल है। - वैल्यू सही हैं या नहीं, यह पूछने के लिए उन्हें टिकट या चैट में पेस्ट न करें। कोई वेरिएबल गायब या गलत हो, तो सिर्फ़ उसका नाम बताएं, भेजने वाला नई वैल्यू जारी कर देगा।
- जाते समय सब बदला जाएगा। काम खत्म होने पर उस फ़ाइल की वैल्यू रोटेट की जाएंगी। यह पहले ही बता दें, ताकि किसी को हैरानी न हो।
पुष्टि करें, फिर सफ़ाई करें
डेवलपर से फ़ाइल का नाम, एनवायरनमेंट और कोई गैर-सीक्रेट निशान, जैसे पहली लाइन में वर्ज़न वाला कमेंट, कन्फ़र्म करने को कहें। अगर वन-टाइम लिंक बताए कि वह डेवलपर के पहुंचने से पहले ही खुल चुका था, तो उसकी हर वैल्यू को उजागर मानें और रोटेट करें।
हैंडओवर पूरा होने पर हर वह लिंक वापस लें जो कभी खुला नहीं, अपनी बनाई कोई भी अस्थायी कॉपी हटाएं, और दर्ज करें कि किसे किस एनवायरनमेंट की वैल्यू कब मिलीं। यही रिकॉर्ड ऑडिट ट्रेल है। फ़ाइल खुद सिर्फ़ उसी मशीन पर होनी चाहिए जिसे उसकी ज़रूरत है।