हमारे पिछले आर्टिकल, "The Rubyist's Guide To Environment Variables" में, हमने आपको दिखाया कि पर्यावरण चर सिस्टम कैसे काम करता है, और कुछ सामान्य मिथकों का भंडाफोड़ किया। लेकिन जैसा कि एक सहायक पाठक ने बताया, हमने सुरक्षा के बारे में ज्यादा नहीं कहा।
चूंकि गुप्त API कुंजियों और अन्य मूल्यवान जानकारी को संग्रहीत करने के लिए env vars का उपयोग करना आम हो गया है, सुरक्षा निहितार्थ को समझना महत्वपूर्ण है। आइए एक नज़र डालते हैं:
सबसे खराब स्थिति
कल्पना करें कि एक हैकर ने आपके सर्वर तक रूट के रूप में, या उस उपयोगकर्ता के रूप में पहुंच प्राप्त कर ली है जो आपके वेब एप्लिकेशन का मालिक है। उस स्थिति में, आपके पर्यावरण चर से समझौता किया जाएगा, साथ ही बाकी सब कुछ जो अत्यधिक एन्क्रिप्टेड नहीं है।
यहां समाधान लोगों को आपके सर्वर तक रूट पहुंच प्राप्त करने से रोकना है। :)
ट्रोजन हॉर्स
डॉक्स द्वारा गली में मिले किसी लड़के ने आपको imagemagick का एक विशेष सूप्ड-अप संस्करण दिया। वह दावा करता है कि यह स्टॉक imagemagick की तुलना में दोगुना तेज चलेगा।
...तो आप वही करते हैं जो कोई भी करेगा। आप इसे प्रोडक्शन में इंस्टॉल करते हैं। एकमात्र समस्या यह है कि यह आपके पर्यावरण चर चुराने के लिए डिज़ाइन किया गया है।
यहाँ, मैं Ruby से बैक-टिक्स सिंटैक्स का उपयोग करके हमारा "दुर्भावनापूर्ण" mogrify कमांड चला रहा हूँ। Mogrify तब मेरे पर्यावरण चर चुराता है, और एक ताना मारने वाला संदेश प्रिंट करता है।
पर्यावरण चर पैरेंट प्रोसेस (irb) से चाइल्ड प्रोसेस (mogrify) में कॉपी हो जाते हैं
यह वास्तव में एक "हैक" नहीं है। यह सिर्फ पर्यावरण चर के काम करने का तरीका है। वे पैरेंट प्रोसेस से चाइल्ड प्रोसेस में कॉपी हो जाते हैं। यदि आप संयोग से मैलवेयर चला रहे हैं, तो वे किसी अन्य ऐप की तरह पर्यावरण चर इनहेरिट करेंगे।
इसके होने के दो तरीके हैं:
कोई आपको अपने टूलचेन में दुर्भावनापूर्ण सॉफ़्टवेयर का एक टुकड़ा इंस्टॉल करने के लिए मना लेता है
आपके टूलचेन का एक "सदोष" टुकड़ा में भेद्यता है और इसका फायदा उठाकर आपके पर्यावरण चर प्रकट किए जाते हैं।
वास्तविक समाधान उन दोनों को होने से सक्रिय रूप से रोकना है। लेकिन एक एहतियाती कदम है जो आप नुकसान को सीमित करने के लिए उठा सकते हैं यदि कोई ENV चुराने वाला डाकू आपके टूलचेन में घुस जाता है।
पर्यावरण को साफ करना
जब भी आप imagemagick या किसी अन्य प्रोग्राम को चलाने के लिए Ruby से शेल आउट करते हैं, तो वह प्रोग्राम आपके ऐप के ENV की एक कॉपी इनहेरिट करता है। यदि आपके पास ENV में कोई सीक्रेट हैं, तो उसे वे भी मिल जाएंगे। जब तक आप उन्हें हटा नहीं देते।
आप सिस्टम मेथड में एक हैश पास करके नया प्रोसेस बनाते समय विशिष्ट पर्यावरण चर को ओवरराइड कर सकते हैं:
Ruby के सिस्टम मेथड में कस्टम पर्यावरण चर कैसे पास करें
यदि आप शेल कमांड चलाते समय कोई पर्यावरण चर नहीं भेजना चाहते हैं, तो आप नीचे दिए गए उदाहरण की तरह कुछ कर सकते हैं। यहाँ हम एक हैश बनाते हैं जो ENV को प्रतिबिंबित करता है, सिवाय इसके कि इसके सभी मान nil पर सेट किए गए हैं। यह सुंदर नहीं है, लेकिन यह एकमात्र तरीका है जो मैंने शेल कमांड निष्पादित करते समय सभी env vars को हटाने का पाया है।
Ruby से शेल कमांड चलाते समय कोई भी पर्यावरण चर भेजने से कैसे रोकें
बाथवॉटर के साथ बच्चे को बाहर न फेंकें
इनहेरिटेंस ENV चर की सबसे उपयोगी विशेषताओं में से एक है।
मान लीजिए आपको एक कमांड चलाने की आवश्यकता है जो S3 पर लिखता है। पर्यावरण चर इनहेरिटेंस का मतलब है कि कमांड आपके Ruby ऐप से API कुंजियों को एक सहज तरीके से साझा कर सकता है। यदि आप कभी इनहेरिटेंस की अनुमति नहीं देते तो आप उस क्षमता को खो देंगे।
स्थिरता
हर प्रक्रिया के पास पर्यावरण चर का अपना सेट होता है जो प्रक्रिया मरने पर मर जाता है। आप अपने Ruby ऐप में पर्यावरण चर सेट कर सकते हैं, लेकिन वे जैसे ही ऐप बंद होगा गायब हो जाएंगे।
यदि आपको रीबूट के बाद पर्यावरण चर को बनाए रखने की आवश्यकता है, तो इसे कहीं संग्रहीत करने की आवश्यकता है। वह कहीं आमतौर पर फाइल सिस्टम पर होता है।
अपने ऐप के गिट रेपो का उपयोग न करें
मुझे यकीन है कि गिटहब के लोग हम बाकी लोगों की तरह ईमानदार हैं, लेकिन क्या आप वास्तव में चाहते हैं कि जिन सभी के पास आपके सोर्स कोड तक पहुंच है, वे आपकी API कुंजी प्राप्त कर सकें और $10,000 का AWS बिल चला सकें?
सीक्रेट्स के लिए .bashrc या .bash-profile का उपयोग करने से बचें
जब आप .bashrc जैसी फ़ाइलों में सीक्रेट्स स्टोर करते हैं, तो उन्हें उस उपयोगकर्ता के रूप में चलने वाले हर एक प्रोग्राम को पर्यावरण चर के रूप में भेजा जाता है। इनमें से अधिकांश प्रोग्राम को आपके सीक्रेट्स जानने की आवश्यकता नहीं होती। तो उन्हें क्यों दें?
अपने सीक्रेट्स केवल उन प्रक्रियाओं को प्रकट करें जिन्हें उनकी आवश्यकता है
यदि आपका Rails ऐप एकमात्र प्रक्रिया है जिसे आपके HONEYBADGER_API_KEY को जानने की आवश्यकता है, तो इसे केवल उस प्रक्रिया के लिए उपलब्ध कराना एक अच्छा विचार है।
कई जेम्स हैं जो आपको एक फ़ाइल में पर्यावरण चर जोड़ने देते हैं जो Rails शुरू होने पर लोड होती है। ये env vars केवल आपकी Rails प्रक्रिया और इसकी चाइल्ड प्रक्रियाओं के लिए उपलब्ध हैं। The Rubyist's Guide To Environment Variables के नीचे figaro और dotenv जेम्स पर एक सेक्शन है।
अपनी कॉन्फ़िगरेशन फ़ाइलों को सुरक्षित करें
यदि आप कॉन्फ़िगरेशन फ़ाइल से अपना पर्यावरण लोड कर रहे हैं, तो आप यह सुनिश्चित करना चाहेंगे कि इसकी अनुमतियाँ सेट हैं ताकि यह केवल आपके वेब ऐप को चलाने वाले उपयोगकर्ता द्वारा पठनीय हो।
यहाँ, मैं अपनी कॉन्फ़िगरेशन फ़ाइल को केवल उस उपयोगकर्ता द्वारा पठनीय और लिखने योग्य बना रहा हूँ जिसने इसे बनाया है। इस मामले में, यह वही उपयोगकर्ता है जो मेरे Rails एप्लिकेशन का मालिक है:
कॉन्फ़िगरेशन फ़ाइलों को केवल उस उपयोगकर्ता द्वारा पठनीय बनाएं जिसे उन्हें पढ़ने की आवश्यकता है
चूंकि आप इसे गिटहब में चेक नहीं कर रहे हैं, आपको या तो सर्वर में SSH करके इसे मैन्युअल रूप से संपादित करना होगा या Chef जैसे टूल का उपयोग करके इसे अपने लिए प्रबंधित करना होगा।
जहां संभव हो "फायरवॉल" बनाएं
AWS के बारे में वास्तव में महान चीजों में से एक यह है कि यह आपको सुपर ग्रैनुलर एक्सेस कंट्रोल पॉलिसी बनाने देता है। बहुत सारे सर्विस प्रोवाइडर्स में ऐसी सुविधाएं होती हैं।
इसका क्या मतलब है? इसका मतलब है कि आपके पास API कुंजियों का एक सेट हो सकता है जो केवल जिस किसी के पास वे हैं उसे S3 पर एक सिंगल बकेट में अपलोड करने की अनुमति देगा। आपको अलग-अलग गतिविधियों के लिए अलग-अलग कीपेयर बनाने चाहिए। छवियों को अपलोड करने के लिए एक कीपेयर। आपके डेटाबेस बैकअप के लिए दूसरा। और इसी तरह।
इस तरह से संचालन करके आप किसी एक सुरक्षा उल्लंघन के नुकसान को सीमित कर सकते हैं।
