इम्पर्वा इन्कैप्सुला क्या है?

स्केपलेस स्क्रैपिंग ब्राउज़र अधिकृत डेटा निकालने के लिए प्रबंधित ब्राउज़र सत्रों की आपूर्ति करता है।

इम्पर्वा इन्कैप्सुला इम्पर्वा की क्लाउड-आधारित अनुप्रयोग सुरक्षा और वितरण सेवा से संबंधित ऐतिहासिक नाम है, जिसे अब आमतौर पर इम्पर्वा क्लाउड WAF के रूप में चर्चा की जाती है। यह सेवा सुरक्षित अनुप्रयोगों के सामने बैठती है और आने वाले ट्रैफ़िक पर सुरक्षा नियंत्रण लागू करती है। इसका इतिहास वेब अनुप्रयोग फ़ायरवॉल सुरक्षा, बॉट नियंत्रण, DDoS शमन, और सामग्री-डिलीवरी कार्यों को शामिल करता है।

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

इन्कैप्सुला इम्पर्वा क्लाउड WAF से कैसे संबंधित है

इन्कैप्सुला इम्पर्वा की क्लाउड एप्लिकेशन-सुरक्षा इतिहास में एक पुराना उत्पाद नाम है। वर्तमान अनुसंधान को शामिल करना चाहिए इम्पर्वा क्लाउड WAF उत्पाद परिवार पुरानी इन्कैप्सुला ट्यूटोरियल से यह मानते हुए कि आज के इंटरफेस या क्षमताओं का वर्णन कर रहे हैं।

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

सभी इम्पर्वा उत्पादों को एक समान मानने से बचें। कंपनी की एप्लिकेशन-निगरानी पेशकशों के विभिन्न तैनाती मॉडल हैं। यह लेख इन्कैप्सुला से संबंधित क्लाउड सुरक्षा संदर्भ पर केंद्रित है, न कि इम्पर्वा पोर्टफोलियो में प्रत्येक उत्पाद पर।

अनुरोध पथ में रिवर्स-प्रॉक्सी स्थिति

एक क्लाउड एप्लिकेशन-सुरक्षा सेवा एक आगंतुक के अनुरोध को मूल एप्लिकेशन से पहले प्राप्त कर सकती है और यह तय कर सकती है कि उस अनुरोध को कैसे संभाला जाना चाहिए। यह बीच का स्थान यह बताता है कि किनारे और मूल अवलोकनों में भिन्नता क्यों हो सकती है।

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

एक साइट के मालिक के लिए, किनारे के घटना, मूल अनुरोध, और अनुप्रयोग के परिणाम को सहसंबंधित करें। एक आगंतुक के लिए, आपको वास्तव में प्राप्त प्रतिक्रिया को बनाए रखना चाहिए और सबूत के बिना यह दावा करने से बचना चाहिए कि मूल स्वस्थ या अस्वस्थ है। एक ब्रांडेड त्रुटि पृष्ठ वितरण पथ का एक भाग पहचानता है, न कि अनिवार्य रूप से मूल कारण।

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

WAF, बॉट नियंत्रण, DDoS संरक्षण, और कैशिंग

अनुप्रयोग वितरण कई कार्यों को संयोजित कर सकता है जिनके लक्ष्य ओवरलैप करते हैं, लेकिन समान नहीं होते हैं। उन्हें अलग रखना आपको एक घटना के लिए सही प्रतिक्रिया चुनने में मदद करता है।

इसकी HTTP कैशिंग विनिर्देश परिभाषा देता है कि कब संग्रहित प्रतिक्रियाएं पुन: उपयोग की जा सकती हैं। एक कैश की गई प्रस्तुति और सुरक्षा द्वारा अस्वीकृत प्रस्तुति अलग-अलग चीजें हैं। हर अप्रत्याशित पृष्ठ को बॉट चुनौती के रूप में न मानें, विशेषकर जब मुद्दा पुराना या संदर्भ-निर्भर सामग्री हो सकता है।

इसकी OWASP स्वचालित-खतरा ढांचा अलग-अलग प्रकार के अनुप्रयोग दुरुपयोग को भी अलग करता है। यह बॉट नियंत्रणों की व्याख्या करते समय महत्वपूर्ण है: एक सार्वजनिक पढ़ने-के-लायक संग्रह कार्य और एक स्वचालित खाता हमला अलग-अलग नीतियों की आवश्यकता कर सकते हैं, भले ही दोनों सॉफ्टवेयर क्लाइंट का उपयोग कर रहे हों।

एक इम्पेरवा प्रतिक्रिया आपको क्या बता सकती है और क्या नहीं बता सकती

एक इम्पेरवा-ब्रांडेड प्रतिक्रिया शामिल सेवा की पहचान करने में मदद कर सकती है, लेकिन यह अपने आप में सटीक नियम या पूरे तैनाती को प्रकट नहीं करती। कारण का आरोप लगाने से पहले संदेश को वर्गीकृत करें।

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

यदि विक्रेता की पहचान आपके दल के लिए महत्वपूर्ण है तो आंतरिक निदान में एक अलग आरोप-विश्वास क्षेत्र रखें। “स्वामी कॉन्फ़िगरेशन द्वारा पुष्टि की गई” “पृष्ठ ब्रांडिंग द्वारा सुझाई गई” से अधिक मजबूत है। यह एक सतही प्रतिक्रिया सुराग को बाद की रिपोर्टों में असहाय वास्तुकला के दावे में बदलने से रोकता है।

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

सार्विक डेटा संग्रहकर्ताओं के लिए एक समस्या निवारण कार्यप्रवाह

एक सार्वजनिक-डेटा संग्रहकर्ता को पहले संसाधन और लौटाई गई सामग्री को मान्य करना चाहिए, फिर यह निर्धारित करना चाहिए कि क्या विफलता इसकी अधिकृत नियंत्रण में है। एक प्रबंधित ग्राहक संग्रहकर्ता को गंतव्य की सुरक्षा नीति को बदलने का अधिकार नहीं देता।

1. सटीक सार्वजनिक मार्ग, अनुरोध विधि, और इच्छित फ़ील्ड की पुष्टि करें।
2. पार्स करने से पहले अंतिम यूआरएल, सामग्री प्रकार, और दृश्य प्रतिक्रिया का निरीक्षण करें।
3. स्पष्ट अस्वीकृति, दर सीमित करने, या ऊपरी प्रवाह की विफलता संदेशों की पहचान करें।
4. जांचें कि क्या अनुमत ब्राउज़र चरण या क्षेत्रीय विकल्प आवश्यक हैं।
5. अनुबंधित दायरे के भीतर अनुरोध की मात्रा बनाए रखें और सभी संबंधित कार्यों का निरीक्षण करें।
6. एक संपादित साक्ष्य पैकेट के साथ मालिक-नियंत्रित सुरक्षा निर्णयों को बढ़ाएं।

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

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

एक नीति परिवर्तन के बाद साइट मालिकों को क्या सत्यापित करना चाहिए

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

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

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

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

स्क्रैपलेस और ब्राउज़र संचालन परत

स्क्रैपलेस स्क्रैपिंग ब्राउज़र अधिकृत सार्वजनिक-पृष्ठ कार्यप्रवाहों के लिए प्रबंधित ब्राउज़र संचालन प्रदान करता है। यह गतिशील सामग्री द्वारा आवश्यक रनटाइम प्रदान कर सकता है जबकि पहुँच निर्णय गंतव्य के साथ छोड़ दिए जाते हैं।

का उपयोग करें स्क्रैपलेस स्क्रैपिंग ब्राउज़र प्रलेखन समर्थित ब्राउज़र क्षमताओं को समझने के लिए। वैधता में अनुरोधित पृष्ठ पहचान, मार्केट और आवश्यक फ़ील्ड को स्पष्ट रखें। क्लाउड प्रॉक्सी व्याख्या मध्यवर्ती राउटिंग के बारे में संबंधित संदर्भ प्रदान करती है, जो एप्लिकेशन अनुमति और ब्राउज़र रेंडरिंग से भिन्न रहनी चाहिए।

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

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

निष्कर्ष

इम्पेरवा इंकैप्सुला इम्पेरवा की क्लाउड एप्लिकेशन-सुरक्षा सेवा के इतिहास से संबंधित है। रिवर्स-प्रॉक्सी स्थिति को समझना सुरक्षा निर्णयों, उत्पत्ति की विफलताओं, और सामग्री-डिलिवरी व्यवहार को अलग करने में मदद करता है। संग्रहकर्ताओं को लौटाए गए पृष्ठ को वर्गीकृत करना चाहिए और पहुँच सीमाओं का सम्मान करना चाहिए; मालिकों को घटनाओं को सहसंबंध करना चाहिए और संकीर्ण रूप से निर्दिष्ट नीति सुधार करना चाहिए।