परिदृश्य (Scenario)
आप थर्ड-पार्टी डिपेंडेंसी वाले एक कंटेनरयुक्त Node.js API का रखरखाव करते हैं। यह कॉन्फ़िगरेशन पढ़ता है, ऑब्जेक्ट स्टोरेज को एक्सेस करता है, और कभी-कभी इमेज-प्रोसेसिंग चाइल्ड प्रोसेस लॉन्च करता है। सुरक्षा टीम केवल आवश्यक फ़ाइल, नेटवर्क और चाइल्ड-प्रोसेस अनुमतियों के साथ --permission का प्रस्ताव करती है। थ्रेट मॉडल, परमिशन इन्वेंट्री, कम्पैटिबिलिटी टेस्ट, मॉनिटरिंग और रोलबैक की व्याख्या करें।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
- यह समझना कि Permission Model विश्वसनीय कोड के लिए एक सीट बेल्ट है, दुर्भावनापूर्ण (malicious) कोड के लिए सैंडबॉक्स नहीं।
- फ़ाइल, नेटवर्क, चाइल्ड-प्रोसेस, वर्कर और नेटिव-एडऑन क्षमताओं को न्यूनतम विशेषाधिकार में विभाजित करना।
- सिम्लिंक्स, मौजूदा फ़ाइल डिस्क्रिप्टर, इनिशियलाइज़ेशन क्रम और इनहेरिटेंस सीमाओं को पहचानना।
- एक कैनरी, उपयोगी डिनायल टेलीमेट्री और एक व्यवसाय-सुरक्षित रोलबैक डिज़ाइन करना।
स्पष्टीकरण हेतु प्रश्न
Node वर्ज़न, एंट्रीपॉइंट, नेटिव एडऑन्स, वर्कर/FFI/WASI की ज़रूरतों, पाथ और डोमेन की पुष्टि करें, और यह भी जांचें कि क्या एप्लिकेशन को प्रोसेस स्पॉन करने की आवश्यकता है। सेक्कॉम्प (seccomp), यूज़र आइडेंटिटी और रीड-ओनली फ़ाइल सिस्टम जैसे मौजूदा कंटेनर और OS नियंत्रणों की जाँच करें ताकि Node को एकमात्र सुरक्षा उपाय न माना जाए।
30-सेकंड का उत्तर
मैं इसे विश्वसनीय कोड के लिए न्यूनतम-विशेषाधिकार नियंत्रण मानूंगा, न कि दुर्भावनापूर्ण डिपेंडेंसी के खिलाफ एक पूर्ण सुरक्षा। fs.read, fs.write, नेटवर्क, चाइल्ड और वर्कर स्कोप के लिए प्रोडक्शन डिपेंडेंसी और रनटाइम ऑडिट से अनुमतियां तैयार करें। इसे शैडो मोड और 1% ट्रैफ़िक में सक्षम करें, ERR_ACCESS_DENIED और लेटेंसी रिकॉर्ड करें, और नेटिव एडऑन्स, सिम्लिंक्स व मौजूदा डिस्क्रिप्टर्स का परीक्षण करें। कंटेनर आइसोलेशन बनाए रखें। यदि एरर रेट या कोई महत्वपूर्ण डिपेंडेंसी प्रभावित होती है, तो रोलबैक करने के लिए स्टार्टअप फ़्लैग को हटा दें और इन्वेंट्री को परिष्कृत करें।
चरण-दर-चरण तर्क
1. सुरक्षा सीमा परिभाषित करें
Node, Permission Model को प्रोसेस-रिसोर्स प्रतिबंध के रूप में वर्णित करता है और स्पष्ट रूप से कहता है कि यह दुर्भावनापूर्ण कोड से सुरक्षा नहीं करता है; Node उस कोड पर भरोसा करता है जिसे चलाने के लिए कहा जाता है। यह विश्वसनीय एप्लिकेशन द्वारा आकस्मिक एक्सेस को कम करता है, लेकिन कंटेनर, OS यूज़र, सेक्कॉम्प या डिपेंडेंसी-सप्लाई-चेन नियंत्रणों की जगह नहीं ले सकता।
2. परमिशन इन्वेंट्री तैयार करें
डिफ़ॉल्ट डिनाय (default deny) से शुरुआत करें। केवल कॉन्फ़िगरेशन और स्टैटिक पाथ के लिए --allow-fs-read दें, --allow-fs-write को अस्थायी आउटपुट तक सीमित करें, और --allow-net को आवश्यक ऑब्जेक्ट-स्टोरेज डोमेन तक सीमित रखें। केवल दस्तावेजीकृत आवश्यकता होने पर ही --allow-child-process, --allow-worker, या --allow-addons जोड़ें। अनुमतियों का वर्ज़निंग करें और सर्विस-ओनर समीक्षा अनिवार्य करें।
3. रनटाइम व्यवहार सत्यापित करें
स्टार्टअप, हेल्थ चेक, अपलोड, इमेज प्रोसेसिंग, शेड्यूल्ड वर्क और एरर पाथ को कवर करें। process.permission.has() को सत्यापित करें और याद रखें कि permission.drop() अपरिवर्तनीय है और केवल भविष्य के चेक को प्रभावित करता है; यह खुले डिस्क्रिप्टर, सॉकेट्स या वर्कर्स को बंद नहीं करता है। सिम्लिंक्स, नेटिव एडऑन्स, npx और चाइल्ड-प्रोसेस सीमाओं का परीक्षण करें।
4. कैनरी और रोलबैक
इसे पहले स्टेजिंग और एक स्टेटलेस इंस्टेंस में सक्षम करें। संवेदनशील मानों को लॉग किए बिना डिनाइड रिसोर्स क्लास, स्टैक, वर्ज़न और टेनेंट डेटा एकत्र करें। एरर रेट, P95, स्टार्टअप सफलता और पूर्ण किए गए व्यावसायिक कार्यों के आधार पर विस्तार का निर्णय लें। रोलबैक का मतलब --permission या संबंधित --allow-* फ़्लैग्स को हटाना है; कंटेनर लेयर पर रीड-ओनली, नॉन-रूट और नेटवर्क नियंत्रण बनाए रखें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं एक परमिशन मैट्रिक्स तैयार करूंगा: रीड-ओनली कॉन्फ़िगरेशन, एक राइटेबल अस्थायी डायरेक्टरी, आवश्यक ऑब्जेक्ट-स्टोरेज डोमेन, इमेज-रूपांतरण चाइल्ड प्रोसेस, और व्यावसायिक कारण के बिना कोई वर्कर या नेटिव एडऑन नहीं। Permission Model डिफ़ॉल्ट रूप से fs को प्रतिबंधित करता है, इसलिए स्टार्टअप पैरामीटर प्रत्येक क्षमता को स्पष्ट रूप से अनुमति देते हैं। मैं उन पैरामीटरों का वर्ज़निंग करूंगा, न्यूनतम इमेज के साथ CI में इंटीग्रेशन परिदृश्यों को चलाऊंगा, और प्रत्येक रूट व बैकग्राउंड जॉब को सत्यापित करूंगा। कैनरी एक स्टेटलेस क्लास को कवर करता है, ERR_ACCESS_DENIED को एकत्रित करता है, और रिसोर्स पाथ को हैश करता है। मैं विशेष रूप से सिम्लिंक्स, मौजूदा डिस्क्रिप्टर्स और इस तथ्य का परीक्षण करूंगा कि चाइल्ड प्रोसेस और वर्कर्स इस मॉडल को समान रूप से इनहेरिट नहीं करते हैं; दुर्भावनापूर्ण कोड का जोखिम कंटेनर और OS आइसोलेशन के साथ बना रहता है। स्टार्टअप, P95, डिनायल और जॉब-पूर्णता गेट्स पास होने के बाद ही विस्तार करें। यदि किसी महत्वपूर्ण डिपेंडेंसी को डिनाय किया जाता है या एरर बढ़ते हैं, तो व्यवहार को पुनर्स्थापित करने के लिए फ़्लैग को हटा दें, फिर पुन: प्रयास करने से पहले इन्वेंट्री को अपडेट करें।
सामान्य गलतियाँ
- यह दावा करना कि Permission Model दुर्भावनापूर्ण थर्ड-पार्टी पैकेजों को सुरक्षित रूप से चलाता है।
- बिना आवश्यकता के
--allow-fs-read=*और--allow-fs-write=*प्रदान करना। - नेटिव एडऑन्स, वर्कर्स, चाइल्ड प्रोसेस, WASI, FFI, या नेटवर्क प्रतिबंधों की अनदेखी करना।
- यह मान लेना कि
permission.drop()पहले से खुले डिस्क्रिप्टर, सॉकेट्स या वर्कर्स को बंद कर देता है। - केवल स्थानीय स्टार्टअप का परीक्षण करना और npx, सिम्लिंक्स, या वास्तविक बैकग्राउंड जॉब्स को छोड़ देना।
अनुवर्ती प्रश्न और उत्तर
"क्या यह कंटेनर सैंडबॉक्स की जगह ले सकता है?"
नहीं। Node स्पष्ट रूप से कहता है कि यह दुर्भावनापूर्ण कोड से सुरक्षा नहीं करता है। इसे नॉन-रूट निष्पादन, रीड-ओनली फ़ाइल सिस्टम, सेक्कॉम्प, नेटवर्क नीतियों और डिपेंडेंसी-सप्लाई-चेन नियंत्रणों के साथ संयोजित करें।
"सर्विस अभी भी फ़ाइल क्यों नहीं पढ़ पा रही है?"
एंट्रीपॉइंट और कॉन्फ़िगर किए गए पाथ, वाइल्डकार्ड व्यवहार, और क्या मॉडल स्थापित होने के बाद इनिशियलाइज़ेशन रीड होते हैं, इसकी जाँच करें। छूटी हुई अनुमति का पता लगाने के लिए permission.has() और डिनायल इवेंट्स का उपयोग करें।
"आप इमेज प्रोसेसिंग की अनुमति कैसे देते हैं?"
--allow-child-process को अलग से अनुमति दें, निष्पादन योग्य फ़ाइल (executable) और इनपुट/आउटपुट डायरेक्टरी को सीमित करें, और OS व कंटेनर प्रतिबंध बनाए रखें। यदि लाइब्रेरी कॉल चाइल्ड प्रोसेस की जगह ले सकती है, तो इसके बजाय उस अनुमति को हटा दें।