HTTP प्रकाशन को एप्लिकेशन निष्पादन और स्थायी डेटा से अलग करें। एक रिवर्स प्रॉक्सी रूटिंग और सीमाओं को व्यवस्थित कर सकता है, लेकिन ओरिजिन पहुँच, एप्लिकेशन प्राधिकरण, अपस्ट्रीम क्षमता और रिकवरी प्रत्येक के लिए अपने स्वयं के नियंत्रण की आवश्यकता होती है।
एक वेब अनुरोध कई जिम्मेदारियों से गुजरता है
एक वेब सर्वर HTTP अनुरोध प्राप्त करता है और स्थिर फ़ाइलें परोस सकता है। एक एप्लिकेशन प्रक्रिया प्रोजेक्ट के गतिशील व्यवहार को निष्पादित करती है, जैसे खाता जाँचना या डेटाबेस क्वेरी करना। एक रिवर्स प्रॉक्सी उस प्रक्रिया की ओर से अनुरोध प्राप्त करता है और उन्हें अपस्ट्रीम पर अग्रेषित करता है। एक प्रोग्राम कई भूमिकाएँ निभा सकता है, लेकिन जिम्मेदारियों को अलग करने से कॉन्फ़िगरेशन और रिकवरी के बारे में तर्क करना आसान हो जाता है।
होस्टनाम रिज़ॉल्यूशन से प्रतिक्रिया तक एक अनुरोध का पता लगाएं। रिकॉर्ड करें कि TLS कहाँ समाप्त होता है, कौन सी प्रक्रिया मार्ग चुनती है और कौन सा घटक एप्लिकेशन डेटा पढ़ सकता है। प्रशासनिक अनुरोध के लिए भी ऐसा ही करें। यह अभ्यास अक्सर एक लिसनर या होस्टनाम को उजागर करता है जो परीक्षण के लिए बनाया गया था और गलती से पहुँच योग्य बना रहा। आरेख को तैनात पथ का वर्णन करना चाहिए, न कि उस आर्किटेक्चर का जिसे आप बनाने की आशा करते थे।
HTTP व्यवहार को व्यवस्थित करने के लिए एज का उपयोग करें
NGINX स्थिर सामग्री परोसने और अनुरोधों को अपस्ट्रीम पर अग्रेषित करने दोनों का दस्तावेज़ीकरण करता है। इसकी वर्कर आर्किटेक्चर और HTTP मॉड्यूल कॉन्फ़िगरेशन तंत्र प्रदान करते हैं, लेकिन एक विशेष कॉन्फ़िगरेशन अभी भी व्यवहार निर्धारित करता है। होस्टनाम, अपस्ट्रीम और फ़ाइलसिस्टम रूट को जानबूझकर परिभाषित करें। परोसी जा सकने वाली फ़ाइलों को प्रतिबंधित करें ताकि कॉन्फ़िगरेशन, क्रेडेंशियल और रिपॉजिटरी मेटाडेटा कभी डाउनलोड करने योग्य न बनें क्योंकि वे संयोग से एप्लिकेशन के पास स्थित हैं।
एप्लिकेशन के अनुसार अनुरोध निकायों, टाइमआउट और कनेक्शन के लिए उपयुक्त सीमाएँ निर्धारित करें। कैश को डेटा निर्णय के रूप में मानें: उपयोगकर्ता या अनुमति से जुड़ी सामग्री समीक्षा के बिना साझा कैशिंग नियम विरासत में नहीं ले सकती। प्रमाणीकरण और कैश व्यवहार का एक साथ परीक्षण करें। एक पुनरुत्पादनीय कॉन्फ़िगरेशन रखें और सेवा को पुनः लोड करने से पहले परिवर्तनों को मान्य करें, पिछले कार्यशील संस्करण पर वापस जाने के ज्ञात मार्ग के साथ।
| परत | उपयोगी जिम्मेदारी | लॉन्च से पहले जाँचें |
|---|---|---|
| सार्वजनिक वेब एज | TLS, होस्टनाम रूटिंग और HTTP सीमाएँ | प्रमाणपत्र, रूट और इच्छित होस्टनाम |
| एप्लिकेशन प्रक्रिया | व्यावसायिक तर्क और प्राधिकरण | प्रमाणीकरण, इनपुट जाँच और निर्भरता विफलता |
| आंतरिक डेटा सेवा | स्थायी एप्लिकेशन स्थिति | प्रतिबंधित पहुँच और परीक्षित पुनर्स्थापन |
| अपस्ट्रीम प्रदाता नेटवर्क | अनुबंधित नेटवर्क सेवा | सुरक्षा दायरा और एस्केलेशन पथ |
रिवर्स प्रॉक्सी ओरिजिन के एक्सपोज़र को समाप्त नहीं करता
यदि ओरिजिन सार्वजनिक रूप से पहुँच योग्य रहता है, तो एक क्लाइंट इच्छित प्रॉक्सी मार्ग का उपयोग किए बिना उस तक पहुँच सकता है। जब तैनाती को उस सीमा की आवश्यकता हो तो नेटवर्क डिज़ाइन और एप्लिकेशन कॉन्फ़िगरेशन के माध्यम से ओरिजिन पहुँच को प्रतिबंधित करें। एक मशीन पर, बैकएंड अक्सर लूपबैक या स्थानीय सॉकेट पर सुन सकता है। मशीनों के बीच, स्पष्ट प्रतिबंधित मार्गों और अपस्ट्रीम कनेक्शन के लिए उपयुक्त सुरक्षा का उपयोग करें।
फ़ॉरवर्ड किए गए हेडर के लिए भी एक विश्वास नियम की आवश्यकता होती है। मूल क्लाइंट के बारे में जानकारी केवल विश्वसनीय मध्यस्थों से स्वीकार करें, और मनमाने कॉलर्स को ऐसे मान प्रदान करने से रोकें जिन्हें एप्लिकेशन आधिकारिक मानता है। तय करें कि एक्सेस लॉग और त्रुटि रिपोर्ट में क्या दिखाई देता है। एक प्रॉक्सी प्रत्येक परत पर उपलब्ध जानकारी को बदल सकता है; यह खाता पहचानकर्ताओं को मिटाता नहीं है या एप्लिकेशन को उसके स्वयं के ऑपरेटर के लिए अनाम नहीं बनाता है।
एप्लिकेशन के भीतर पहुँच निर्णय लागू करें
NIST की Zero Trust आर्किटेक्चर केवल नेटवर्क स्थान पर आधारित निहित विश्वास के बजाय संसाधनों के लिए पहुँच निर्णयों पर केंद्रित है। उस सिद्धांत को ठोस रूप से लागू करें: कॉलर को प्रमाणित करें, अनुरोधित ऑपरेशन को अधिकृत करें और सेवा खातों को केवल उनका आवश्यक दायरा दें। आंतरिक सबनेट से आने वाला अनुरोध स्वचालित रूप से प्रशासक अनुरोध नहीं बन जाना चाहिए।
जहाँ व्यावहारिक हो सार्वजनिक और प्रशासनिक कार्यों को अलग करें। जब कोई उपयोगकर्ता किसी रिकॉर्ड तक पहुँचता है तो केवल प्रारंभिक लॉगिन पर निर्भर रहने के बजाय अनुमति की पुनः जाँच करें। प्रॉक्सी, एप्लिकेशन और डेटाबेस के क्रेडेंशियल अलग रखें। परिवर्तनों को चरणों में पेश करें जिनका परीक्षण किया जा सके, एक संकीर्ण संवेदनशील पथ से शुरू करें। किसी तैनाती को Zero Trust कहना यह प्रदर्शित करने से कम उपयोगी है कि एक निषिद्ध क्रिया वास्तव में उसके लिए जिम्मेदार घटक पर अस्वीकार की जाती है।
एक से अधिक परत पर सेवा-अस्वीकृति की योजना बनाएं
एक संतृप्त नेटवर्क लिंक और एक महंगा एप्लिकेशन अनुरोध अलग-अलग स्थानों पर विफल होते हैं। वेब एज पर दर सीमित करना अनुरोध पैटर्न को सीमित करने में मदद कर सकता है, जबकि एप्लिकेशन सीमाएँ खोज, अपलोड या निर्यात जैसे कार्यों को सीमित कर सकती हैं। NGINX का अनुरोध-सीमा मॉड्यूल एक तंत्र प्रदान करता है; कुंजी और थ्रेसहोल्ड वास्तविक उपयोगकर्ताओं के अनुरूप होने चाहिए और वैध ट्रैफ़िक को अस्वीकार करने से बचने के लिए परीक्षण किए जाने चाहिए।
OWASP का सेवा-अस्वीकृति मार्गदर्शन एप्लिकेशन व्यवहार में संसाधन की कमी को भी संबोधित करता है। महंगे काम के आसपास समय और आकार की सीमाएँ रखें, सीमित कतारों का उपयोग करें और विफलता संकेतों की निगरानी करें। स्थानीय नियंत्रण पहले से संतृप्त अपस्ट्रीम लिंक में क्षमता नहीं बना सकते। चुने गए ऑफ़र में शामिल विशिष्ट नेटवर्क सुरक्षा की पुष्टि करें और एक एस्केलेशन पथ तैयार करें। कभी यह न मानें कि कैटलॉग की Layer 3–4 सुरक्षा हर HTTP वर्कलोड के लिए सुरक्षा भी सिद्ध करती है।
रिकवरी को प्रकाशन का हिस्सा बनाएं
किसी बाहरी क्लाइंट से साइट को उसके इच्छित होस्टनाम का उपयोग करके जाँचें। HTTPS, रीडायरेक्ट, स्थिर संसाधन, लॉगिन और एक प्रतिनिधि एप्लिकेशन लेनदेन को सत्यापित करें। पुष्टि करें कि प्रशासनिक लिसनर और निजी फ़ाइलें अगम्य रहें। एक रुके हुए अपस्ट्रीम का अनुकरण करें और जाँचें कि एज आंतरिक विवरण उजागर करने या बिना सीमा के प्रतीक्षा करने के बजाय एक नियंत्रित विफलता लौटाता है।
Canvas के लिए, होस्टिंग खाते के भीतर उपलब्ध नियंत्रण पढ़ें। VPS के लिए, वेब एज और एप्लिकेशन को अपनी स्वयं की संचालन योजना के हिस्से के रूप में बनाए रखें। एक बड़ा नेटवर्क पोर्ट एक क्षमता विशिष्टता है, यह प्रमाण नहीं कि एप्लिकेशन उस थ्रूपुट को बनाए रख सकता है। निगरानी, पुनर्स्थापन और प्रदाता संपर्कों को रनबुक में रखें। वास्तविक अनुरोध पथ और व्यावहारिक रिकवरी पथ सत्यापित होने के बाद ही प्रकाशित करें।
आपकी व्यावहारिक चेकलिस्ट।
- एक सार्वजनिक और एक प्रशासनिक अनुरोध का पता लगाएं।
- परोसे जाने वाले रूट और अपस्ट्रीम लिसनर परिभाषित करें।
- फ़ॉरवर्ड किए गए हेडर पर केवल अनुमोदित मध्यस्थों से भरोसा करें।
- प्राधिकरण और कैश सीमाओं का परीक्षण करें।
- नेटवर्क और एप्लिकेशन विफलताओं के लिए सीमाएँ और एस्केलेशन तैयार करें।
महत्वपूर्ण विवरण।
क्या एक वेब सर्वर रिवर्स प्रॉक्सी के रूप में भी कार्य कर सकता है?+
हाँ। NGINX एक प्रलेखित उदाहरण है। इसकी भूमिकाएँ कॉन्फ़िगरेशन पर निर्भर करती हैं, और एप्लिकेशन को अभी भी अपने स्वयं के प्राधिकरण और रखरखाव की आवश्यकता होती है।
क्या एक रिवर्स प्रॉक्सी स्वचालित रूप से ओरिजिन को छिपा देता है?+
नहीं। ओरिजिन तब तक पहुँच योग्य रह सकता है जब तक रूटिंग, फ़ायरवॉल और लिसनर सेटिंग्स इच्छित सीमा को लागू नहीं करतीं।
क्या अनुरोध सीमित करना हर DDoS हमले को रोक देगा?+
नहीं। यह चयनित HTTP अनुरोध पैटर्न को संबोधित करता है। नेटवर्क संतृप्ति और अन्य संसाधन विफलताओं के लिए उपयुक्त अपस्ट्रीम और एप्लिकेशन नियंत्रण की आवश्यकता होती है।
स्रोत पर जाएं।
ये संदर्भ इस गाइड में तकनीकी अवधारणाओं का समर्थन करते हैं। उत्पादन प्रणाली बदलने से पहले वर्तमान दस्तावेज़ का पालन करें।
- NGINX: शुरुआती गाइड nginx.org
- NGINX: HTTP अनुरोध सीमित करना nginx.org
- NIST SP 800-207: Zero Trust आर्किटेक्चर nvlpubs.nist.gov
- OWASP: सेवा-अस्वीकृति की रोकथाम cheatsheetseries.owasp.org
SwissOctet द्वारा संपादकीय मार्गदर्शन। उदाहरण केवल दृष्टांत हैं। सेवा विशिष्टताएं, उपलब्ध विकल्प और संविदात्मक शर्तें अलग से सत्यापित की जानी चाहिए।