स्थानीय बनाम क्लाउड टीएलएस निरीक्षण: परिनियोजन संबंधी लाभ-हानि

TLS निरीक्षण (जिसे अक्सर SSL निरीक्षण भी कहा जाता है) एक TLS सत्र को इंटरसेप्ट करने, उसे एक विश्वसनीय प्रमाणपत्र से डिक्रिप्ट करने, सामग्री की जांच करने और गंतव्य तक भेजने से पहले उसे पुनः एन्क्रिप्ट करने की प्रक्रिया है। इसके बिना, सुरक्षित वेब गेटवे, DLP इंजन और सैंडबॉक्स केवल गंतव्य मेटाडेटा ही देख पाते हैं। इसके साथ, वे मैलवेयर का पता लगा सकते हैं, डेटा लीक को रोक सकते हैं और एन्क्रिप्टेड सत्रों के भीतर स्वीकार्य उपयोग नीतियों को लागू कर सकते हैं।

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

यह लेख हाइब्रिड क्लाउड सुरक्षा मार्गदर्शिका का एक भाग है।

TLS निरीक्षण कैसे काम करता है

टीएलएस निरीक्षण इस प्रकार काम करता है कि एक विश्वसनीय प्रॉक्सी क्लाइंट के एन्क्रिप्टेड सत्र को समाप्त कर देता है, सामग्री का निरीक्षण करता है और गंतव्य के लिए एक नया एन्क्रिप्टेड सत्र खोलता है।

प्रॉक्सी क्लाइंट के लिए सर्वर और गंतव्य के लिए क्लाइंट के रूप में कार्य करता है:

1. क्लाइंट किसी वेबसाइट या एप्लिकेशन के साथ टीएलएस सेशन शुरू करता है।
2. प्रॉक्सी कनेक्शन को इंटरसेप्ट करता है और गंतव्य के लिए एक प्रमाणपत्र प्रस्तुत करता है, जिस पर एक एंटरप्राइज इंस्पेक्शन सर्टिफिकेट अथॉरिटी (CA) द्वारा हस्ताक्षर किए गए होते हैं, जिस पर क्लाइंट डिवाइस भरोसा करते हैं।
3. प्रॉक्सी वास्तविक गंतव्य के लिए अपना स्वयं का टीएलएस सत्र खोलता है और उस सर्वर के प्रमाणपत्र को मान्य करता है।
4. दोनों सत्रों के बीच ट्रैफिक को डिक्रिप्ट किया जाता है, उसकी जांच की जाती है और फिर से एन्क्रिप्ट किया जाता है।

इसका मतलब है कि प्रॉक्सी एक बेहद शक्तिशाली कुंजी रखता है और हर निरीक्षण सत्र के लिए प्लेनटेक्स्ट को संभालता है। NSA की सलाह " ट्रांसपोर्ट लेयर सिक्योरिटी इंस्पेक्शन से जोखिम का प्रबंधन" में यह सुझाव दिया गया है कि ऐसा होने से बचा जाए: निरीक्षण केवल एक बार, एंटरप्राइज़ नेटवर्क के भीतर ही करें और कई फॉरवर्ड प्रॉक्सी द्वारा अनावश्यक निरीक्षण से बचें। HTTPS अवरोधन पर CISA की पिछली चेतावनी में यह बताया गया था कि खराब तरीके से लागू किए गए निरीक्षण उत्पाद TLS सुरक्षा को कमजोर कर सकते हैं, उदाहरण के लिए अपस्ट्रीम प्रमाणपत्रों को ठीक से मान्य न कर पाने से।

स्थानीय बनाम क्लाउड टीएलएस निरीक्षण एक नज़र में

स्थानीय निरीक्षण आपके बुनियादी ढांचे पर प्लेनटेक्स्ट और कुंजियों को सुरक्षित रखता है, जबकि क्लाउड निरीक्षण उन्हें प्रदाता के उपस्थिति बिंदुओं पर स्थानांतरित करता है।

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

डिक्रिप्शन पथ

प्रत्येक हाइब्रिड डिज़ाइन को प्रत्येक टीएलएस समाप्ति और पुनः एन्क्रिप्शन बिंदु को मैप करना चाहिए और अनावश्यक निरीक्षण से बचना चाहिए।

सामान्य रास्तों में शामिल हैं:

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

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

प्रमाणपत्र संबंधी जिम्मेदारियां

टीएलएस निरीक्षण उतना ही भरोसेमंद होता है जितना कि इसके पीछे के प्रमाणपत्र, इसलिए प्रमाणपत्र जीवनचक्र के प्रत्येक भाग के लिए स्पष्ट स्वामित्व निर्धारित करें:

• CA निर्माण और सुरक्षा का निरीक्षण करें। दस्तावेज़ में यह दर्ज करें कि निजी कुंजी कहाँ स्थित है, इसे कौन एक्सेस कर सकता है, और क्या HSM की आवश्यकता है। प्रत्येक स्थानीय गेटवे या क्लाउड सेवा और उसके उत्पाद संस्करण के लिए समर्थित HSM एकीकरण की पुष्टि करें; समर्थन की गारंटी न दें।
• वितरण। प्रबंधित उपकरणों पर ऑपरेटिंग सिस्टम और ब्राउज़र ट्रस्ट स्टोर में सीए कैसे स्थापित होता है, और अप्रबंधित उपकरणों पर क्या होता है।
• रोटेशन। बिना किसी रुकावट के निरीक्षण सीए को बदलने की अनुसूची और प्रक्रिया।
• अपस्ट्रीम सत्यापन। पुष्टि करें कि प्रॉक्सी अमान्य, समाप्त हो चुके या निरस्त गंतव्य प्रमाणपत्रों को उपयोगकर्ताओं से छिपाने के बजाय उन्हें अस्वीकार करता है।
• प्रोटोकॉल समर्थन। TLS 1.3 ( RFC 8446 ) की जाँच मूल रूप से की जानी चाहिए, इसे डाउनग्रेड नहीं किया जाना चाहिए।

ट्रैफ़िक अपवाद

किसी भी संगठन को हर चीज को डिक्रिप्ट नहीं करना चाहिए, इसलिए एक दस्तावेजित, नियमित रूप से समीक्षा की जाने वाली अपवाद सूची बनाए रखें:

अपवादों की समीक्षा त्रैमासिक आधार पर करें। पुराने बाईपास अक्सर अनदेखी का शिकार होते हैं।

एन्क्रिप्टेड क्लाइंट हेलो और इससे होने वाले बदलाव

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

एनक्रिप्टेड क्लाइंट हेलो (ECH) को 2026 में RFC 9849 के रूप में प्रकाशित किया गया था। ECH, TLS हैंडशेक के उस हिस्से को एन्क्रिप्ट करता है जो पहले गंतव्य होस्टनाम (सर्वर नेम इंडिकेशन) और अन्य फ़ील्ड्स को प्रकट करता था। SNI को पढ़कर ट्रैफ़िक को वर्गीकृत करने वाले निष्क्रिय टूल, ECH-सक्षम साइटों के लिए यह दृश्यता खो देते हैं।

स्पष्ट प्रॉक्सी जो टीएलएस को समाप्त करते हैं, उनकी स्थिति अलग होती है, क्योंकि वे गंतव्यों के लिए अपने स्वयं के सत्र स्थापित करते हैं। फिर भी, ईसीएच के परिचालन संबंधी निहितार्थ हैं:

• ब्राउज़र ECH जैसे एक्सटेंशन तब भी भेज सकते हैं जब ECH उपयोग में न हो, इसलिए निरीक्षण उत्पादों को उन्हें सही ढंग से संभालने की आवश्यकता है।
• RFC में यह बताया गया है कि प्रबंधित एंटरप्राइज़ सेटिंग्स में, एक तरीका यह है कि समूह नीति के माध्यम से ECH को अक्षम कर दिया जाए और क्लाइंट द्वारा उस सेटिंग का पालन करने पर भरोसा किया जाए।
• श्रेणी और प्रतिष्ठा संबंधी निर्णय जो बाईपास किए गए ट्रैफ़िक के लिए SNI पर निर्भर थे, उन्हें एक विकल्प की आवश्यकता है, जैसे कि DNS-परत नियंत्रण या स्पष्ट प्रॉक्सी कॉन्फ़िगरेशन।

अपने निरीक्षण विक्रेता के ईसीएच रोडमैप की पुष्टि करें और वर्तमान ब्राउज़र संस्करणों के साथ व्यवहार का परीक्षण करें।

लॉगिंग

निरीक्षण लॉग में यूआरएल, पहचान और डीएलपी साक्ष्य शामिल हो सकते हैं, इसलिए उनकी सामग्री, स्थान और पहुंच के लिए स्पष्ट निर्णय लेने की आवश्यकता है:

• डिक्रिप्टेड और बाईपास किए गए ट्रैफ़िक के लिए कौन से फ़ील्ड लॉग किए जाते हैं?
• लॉग कहाँ संग्रहीत किए जाते हैं, और क्या उन्हें किसी क्षेत्राधिकार से बाहर ले जाया जा सकता है
• प्रतिधारण अवधि, और कौन पूर्ण सामग्री साक्ष्य तक पहुंच सकता है
• कौन-कौन सी घटनाएं SIEM को भेजी जाती हैं?

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

परिचालन संबंधी समझौते

स्थानीय निरीक्षण में नियंत्रण के लिए परिचालन संबंधी प्रयास की आवश्यकता होती है, क्लाउड निरीक्षण में सरलता के लिए नियंत्रण की आवश्यकता होती है, और हाइब्रिड निरीक्षण को कार्य करने के लिए एक ही नीति इंजन की आवश्यकता होती है।

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

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

हाइब्रिड निरीक्षण दोनों को जोड़ता है, लेकिन यह केवल एक पॉलिसी इंजन के साथ ही बेहतर काम करता है। यदि स्थानीय और क्लाउड गेटवे में अलग-अलग अपवाद सूचियाँ और डीएलपी नियम हैं, तो उपयोगकर्ताओं के साथ स्थान के आधार पर अलग-अलग व्यवहार किया जाएगा।

Skyhigh स्थानीय और बादल निरीक्षण के लिए किस प्रकार दृष्टिकोण अपनाता है

Skyhigh एक ही नीति के तहत, जहां अनुपालन की आवश्यकता होती है, वहां स्थानीय रूप से और दूरस्थ उपयोगकर्ताओं के लिए क्लाउड में TLS का निरीक्षण करता है।

Skyhigh Hybrid SSE Mesh, SSL/TLS डिक्रिप्शन और निरीक्षण को संगठन के अपने उपकरणों पर स्थानीय रूप से चलाता है, जहां अनुपालन की आवश्यकता होती है, और दूरस्थ उपयोगकर्ताओं के लिए Skyhigh क्लाउड पॉइंट्स ऑफ प्रेजेंस में, दोनों में एक ही पॉलिसी इंजन के साथ। Secure Web Gateway गेटवे पर ज़ीरो ट्रस्ट एक्सेस को मूल रूप से लागू किया जाता है, जबकि डेटा सुरक्षा नीति गेटवे द्वारा अग्रेषित ट्रैफ़िक पर स्काईहाई क्लाउड में लागू होती है। ऑन-प्रिमाइसेस गेटवे पर डिक्रिप्ट किए गए वेब ट्रैफ़िक का निरीक्षण किया जाता है और स्थानीय वेब नीति को लागू करने के लिए उसे वहीं पुनः एन्क्रिप्ट किया जाता है। यदि कोई नीति डेटा सुरक्षा जैसी क्लाउड-आधारित सेवा का उपयोग करती है, तो गेटवे संबंधित ट्रैफ़िक को स्काईहाई क्लाउड पर अग्रेषित करता है, जहाँ वही नीति लागू होती है। एजेंटलेस सिक्योर ब्राउज़र कंट्रोल्स ब्राउज़र सत्र में AI और मैसेजिंग ट्रैफ़िक का वेबसॉकेट-आधारित निरीक्षण करते हैं।

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

1. एनएसए। ट्रांसपोर्ट लेयर सिक्योरिटी इंस्पेक्शन से उत्पन्न जोखिम का प्रबंधन (नवंबर 2019)। https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
2. CISA. “HTTPS अवरोधन TLS सुरक्षा को कमजोर करता है” (अलर्ट TA17-075A, मार्च 2017). https://www.cisa.gov/news-events/alerts/2017/03/16/https-interception-weakens-tls-security
3. आईईटीएफ. आरएफसी 8446: ट्रांसपोर्ट लेयर सिक्योरिटी (टीएलएस) प्रोटोकॉल संस्करण 1.3. https://www.rfc-editor.org/rfc/rfc8446.html
4. आईईटीएफ. आरएफसी 9849: टीएलएस एन्क्रिप्टेड क्लाइंट हेलो। https://www.rfc-editor.org/rfc/rfc9849.html
5. आईईटीएफ. आरएफसी 9000: क्यूआईसी: एक यूडीपी-आधारित मल्टीप्लेक्स और सुरक्षित परिवहन। https://www.rfc-editor.org/rfc/rfc9000.html
6. Skyhigh Security “स्काईहाई एसएसई प्लेटफॉर्म के साथ हाइब्रिड को अपनाना अब और भी आसान हो गया है” (3 अक्टूबर, 2024)। https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html
7. 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