Secure Web Gateway माइग्रेशन: कटओवर और रोलबैक चेकलिस्ट

ए secure web gateway माइग्रेशन वेब ट्रैफ़िक निरीक्षण और नीति को एक प्रॉक्सी प्लेटफ़ॉर्म से दूसरे पर स्थानांतरित करता है, चाहे वह ऑन-प्रिमाइसेस उपकरण से नए उपकरण पर हो, क्लाउड सेवा पर हो या हाइब्रिड मॉडल पर। यह चेकलिस्ट संपूर्ण प्रक्रिया को कवर करती है: इन्वेंट्री, लक्ष्य डिज़ाइन, नीति अनुवाद, रोलबैक तैयारी, पायलट, परीक्षण, चरणबद्ध कटओवर और स्वीकृति।

यह लेख हाइब्रिड क्लाउड सुरक्षा मार्गदर्शिका का हिस्सा है। Blue Coat ProxySG और Symantec Edge SWG की विशिष्टताओं के लिए, Blue Coat और ProxySG End of Life: Migration Planning देखें।

चरण 1: सूची

डिजाइन का काम शुरू करने से पहले, चरण 1 में मौजूदा गेटवे एस्टेट, ट्रैफिक स्टीयरिंग, पहचान, टीएलएस निरीक्षण, नीति और एकीकरण का दस्तावेजीकरण किया जाता है।

आधारभूत संरचना

• प्रत्येक गेटवे: मॉडल, सॉफ्टवेयर संस्करण, स्थान, भूमिका और जीवन-समाप्ति तिथियां (ProxySG और Edge SWG के लिए, ब्रॉडकॉम के जीवन-चक्र लेख को देखें)
• प्रत्येक साइट पर ट्रैफ़िक की मात्रा और अधिकतम थ्रूपुट, साथ ही TLS डिक्रिप्शन शेयर
• प्रति साइट और रिमोट एक्सेस के लिए उपयोगकर्ताओं की संख्या
• अपस्ट्रीम और डाउनस्ट्रीम प्रॉक्सी चेनिंग, लोड बैलेंसर और फेलओवर डिज़ाइन

ट्रैफ़िक स्टीयरिंग

• स्पष्ट प्रॉक्सी सेटिंग्स, PAC फ़ाइलें और WPAD
• पारदर्शी अवरोधन बिंदु (WCCP, नीति-आधारित रूटिंग)
• शाखाओं से सुरंगें (IPsec, GRE)
• एंडपॉइंट पर एजेंट
• डायरेक्ट-टू-इंटरनेट अपवाद

पहचान

• प्रमाणीकरण क्षेत्र (SAML, Kerberos/IWA, LDAP, क्लाइंट प्रमाणपत्र)
• नीति में प्रयुक्त समूह मैपिंग
• अनधिकृत ट्रैफ़िक (सर्वर, IoT, OT) और इसे कैसे संभाला जाता है

टीएलएस निरीक्षण

• निरीक्षण सीए, प्रमुख स्थान, समाप्ति तिथि और वितरण विधि
• कारणों और उनके मालिकों सहित डिक्रिप्शन बाईपास की सूची

नीति

• नियम क्रम, श्रेणियां, कस्टम सूचियां और अपवादों सहित संपूर्ण नीति निर्यात
• पिछले 90 दिनों में कोई हिट न होने वाले नियम (सेवानिवृत्ति के उम्मीदवार)

एकीकरण

• ICAP का DLP, एंटीवायरस और सैंडबॉक्सिंग से कनेक्शन
• लॉग को SIEM और रिपोर्टिंग टूल में अग्रेषित करना
• निगरानी और चेतावनी

चरण 2: लक्ष्य डिजाइन

दूसरे चरण में यह तय किया जाता है कि प्रत्येक साइट और उपयोगकर्ता समूह का निरीक्षण कहाँ किया जाएगा और ट्रैफ़िक, प्रमाणपत्र और लॉग को कैसे संभाला जाएगा।

• यह तय करें कि प्रत्येक साइट और उपयोगकर्ता समूह का निरीक्षण कहाँ किया जाएगा: परिसर में, क्लाउड पर, या हाइब्रिड में।
• प्रत्येक के लिए ट्रैफ़िक स्टीयरिंग विधि को परिभाषित करें: प्रबंधित नेटवर्क के लिए स्पष्ट प्रॉक्सी या पीएसी, रोमिंग उपयोगकर्ताओं के लिए एजेंट या ब्राउज़र नियंत्रण, शाखाओं के लिए टनल।
• TLS निरीक्षण की स्थिति की पुष्टि करें ताकि प्रत्येक प्रवाह को केवल एक बार डिक्रिप्ट किया जा सके। NSA के दिशानिर्देशों के अनुसार, एंटरप्राइज़ नेटवर्क के भीतर केवल एक बार निरीक्षण करना चाहिए और चेन प्रॉक्सी द्वारा अनावश्यक निरीक्षण से बचना चाहिए ( NSA )।
• डिक्रिप्टेड पीक थ्रूपुट और वृद्धि के लिए आकार क्षमता
• उच्च उपलब्धता और विफलता व्यवहार को डिज़ाइन करें
• यह तय करें कि लॉग और डीएलपी साक्ष्य कहाँ संग्रहीत किए जाएंगे।
• नए निरीक्षण सीए की योजना बनाएं या मौजूदा सीए को स्थानांतरित करें, और समर्थित कुंजी संग्रहण और किसी भी आवश्यक एचएसएम एकीकरण की पुष्टि करें।

चरण 3: नीति अनुवाद

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

• प्रत्येक स्रोत नियम को उसके लक्ष्य समकक्ष से मैप करें, या उसे निरस्त करने के लिए चिह्नित करें।
• विक्रेताओं के बीच URL श्रेणियों का मानचित्रण करें और उच्च-प्रभाव वाली श्रेणियों के लिए अंतरों की समीक्षा करें।
• कस्टम सूचियाँ, अनुमति सूचियाँ और अवरोध सूचियाँ पुनः बनाएँ
• प्रमाणीकरण-निर्भर नियमों का अनुवाद करें और समूह मैपिंग की पुष्टि करें
• डिक्रिप्शन बाईपास को पुनः बनाएं और प्रत्येक की निरंतर आवश्यकता की समीक्षा करें।
• जहां संभव हो, ICAP-आधारित DLP हैंडऑफ़ को प्लेटफ़ॉर्म की अपनी डेटा सुरक्षा सेवा से बदलें, यह पुष्टि करते हुए कि निरीक्षण कहाँ होता है, या एकीकरण को पुनः स्थापित करें।
• अपने कॉन्फ़िगरेशन परिवर्तन नियंत्रण प्रक्रिया का पालन करते हुए, प्रत्येक परिवर्तन और प्रत्येक निरस्त नियम को कारण सहित रिकॉर्ड करें (NIST SP 800-128 सुरक्षा-केंद्रित कॉन्फ़िगरेशन प्रबंधन प्रथाओं का वर्णन करता है)।

कुछ प्लेटफ़ॉर्म मौजूदा पॉलिसी को आयात करने में सहायता प्रदान करते हैं। किसी भी आयात को एक प्रारंभिक बिंदु के रूप में लें, जिसकी समीक्षा और परीक्षण अभी बाकी है।

चरण 4: रोलबैक की तैयारी

चरण 4 में पायलट प्रोजेक्ट से पहले रोलबैक ट्रिगर्स और कार्यप्रणाली को परिभाषित किया गया है। पायलट प्रोजेक्ट के दौरान रोलबैक का परीक्षण करें और प्रत्येक उत्पादन चरण से पहले तैयारी की पुष्टि करें।

रोलबैक ट्रिगर (उदाहरण)

• एक निर्धारित सीमा से अधिक प्रमाणीकरण विफलताएँ
• एक व्यावसायिक रूप से महत्वपूर्ण एप्लिकेशन निर्धारित समय से अधिक समय तक अनुपलब्ध रहेगा।
• हेल्पडेस्क टिकट जो बेसलाइन के एक निर्धारित गुणक से ऊपर हैं
• सुरक्षा नियंत्रणों को लागू नहीं किया जा रहा है, इसकी पुष्टि हो चुकी है।

रोलबैक तंत्र

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

चरण 5: पायलट

चरण 5 में, कम से कम एक व्यावसायिक चक्र के लिए, पुराने गेटवे के समानांतर, नए गेटवे पर एक प्रतिनिधि पायलट समूह का संचालन किया जाता है।

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

चरण 6: परीक्षण

चरण 6 में प्रमाणीकरण से लेकर प्रदर्शन और फेलओवर तक, उन सभी क्षेत्रों का परीक्षण किया जाता है जहां उपयोगकर्ताओं को अंतर महसूस होगा।

चरण 7: चरणबद्ध बदलाव

चरण 7 में उपयोगकर्ताओं और साइटों को नए गेटवे पर चरणबद्ध तरीके से स्थानांतरित किया जाएगा, जिसकी शुरुआत सबसे कम जोखिम वाली साइटों से होगी।

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

चरण 8: स्वीकृति और सेवामुक्ति

चरण 8 स्वीकृति मानदंडों की पूर्ति की पुष्टि करता है, फिर पुराने गेटवे, प्रमाणपत्र और अनुबंधों को हटा देता है।

स्वीकृति मानदंड (उदाहरण)

• सभी उपयोगकर्ता और साइटें स्थानांतरित हो गईं
• हेल्पडेस्क पर आने वाले लोगों की संख्या दो सप्ताह से सामान्य स्तर पर वापस आ गई है।
• उत्पादन में सभी परीक्षण सफल रहे
• सुरक्षा संचालन और अनुपालन द्वारा सत्यापित लॉग और रिपोर्ट
• अपवाद सूची की समीक्षा की गई और उसे अनुमोदित किया गया।

सेवामुक्त करना

• PAC फ़ाइलों, राउटिंग और DNS से ​​पुराने गेटवे हटाएँ
• यदि उपकरणों को बदला गया है, तो पुराने निरीक्षण सीए को रद्द करें और उपकरणों से हटा दें।
• प्रतिधारण नीति के अनुसार पुराने लॉग को संग्रहित करें
• हार्डवेयर को सुरक्षित रूप से पोंछकर उसका निपटान करें।
• लाइसेंस और समर्थन अनुबंधों को समाप्त करें

सामान्य समयरेखा

समयसीमा संपत्ति के आकार और पॉलिसी की जटिलता पर निर्भर करती है।

एक ही स्थान पर स्थित संगठन कुछ ही हफ्तों में माइग्रेशन पूरा कर सकता है। Skyhigh Security के अनुसार, बड़े, कई स्थानों पर स्थित उद्यम अक्सर छह से बारह महीनों में समानांतर तैनाती और चरणबद्ध तरीके से इसे अपनाते हैं।

Skyhigh किस प्रकार SWG माइग्रेशन का समर्थन करता है

Skyhigh समानांतर परिनियोजन, मान्य CPL नीति आयात और लचीले परिनियोजन मॉडल के साथ SWG माइग्रेशन का समर्थन करता है।

Skyhigh Hybrid SSE Mesh मौजूदा गेटवे के साथ तैनात होता है ताकि किसी भी बदलाव से पहले समानांतर ट्रैफ़िक के साथ नीति का सत्यापन किया जा सके। Skyhigh मौजूदा Blue Coat CPL नीति को एक मान्य आयात प्रक्रिया के माध्यम से एकीकृत नीति कंसोल में शामिल किया जाता है, और नीति Skyhigh क्लाउड कंसोल में तैयार की जाती है। वेब और निजी एप्लिकेशन नीति को ऑन-प्रिमाइसेस गेटवे पर लागू किया जा सकता है, जबकि क्लाउड-आधारित डेटा सुरक्षा की आवश्यकता वाले ट्रैफ़िक को Skyhigh क्लाउड पर अग्रेषित किया जाता है। दूरस्थ उपयोगकर्ताओं को क्लाउड पॉइंट ऑफ़ प्रेजेंस के माध्यम से सेवा प्रदान की जाती है। Skyhigh SWG ऑन-प्रिमाइसेस, हाइब्रिड या क्लाउड पर चलता है, इसलिए माइग्रेशन से परिनियोजन मॉडल में कोई बदलाव नहीं होता है। Blue Coat आधुनिकीकरण कार्यक्रम पात्र ग्राहकों के लिए सेवा समर्थन और वाणिज्यिक छूट प्रदान करता है।

सूत्रों का कहना है

1. एनएसए। ट्रांसपोर्ट लेयर सिक्योरिटी इंस्पेक्शन से उत्पन्न जोखिम का प्रबंधन (नवंबर 2019)। https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
2. एनआईएसटी. एसपी 800-128: सूचना प्रणालियों के सुरक्षा-केंद्रित विन्यास प्रबंधन के लिए मार्गदर्शिका। https://csrc.nist.gov/pubs/sp/800/128/upd1/final
3. ब्रॉडकॉम। एज एसडब्ल्यूजी (प्रॉक्सीएसजी) और एडवांस्ड सिक्योर गेटवे के लिए उत्पाद जीवनचक्र और समाप्ति (केबी 151102)। https://knowledge.broadcom.com/external/article/151102/end-of-life-and-product-lifecycle-for-pr.html
4. Skyhigh Security “अपने सिमेंटेक एज को आधुनिक बनाना” Secure Web Gateway "Skyhigh Hybrid SSE Mesh के साथ" (15 जुलाई, 2026)। https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
5. Skyhigh Security “स्काईहाई एसएसई प्लेटफॉर्म के साथ हाइब्रिड को अपनाना अब और भी आसान हो गया है” (3 अक्टूबर, 2024)। https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html