VPN नियम किसी एक फ़ाइल को अपलोड होने से क्यों नहीं रोक सकता
किसी सेवा तक पहुँचना और यह नियंत्रित करना कि उससे कौन-सी फ़ाइलें बाहर जाती हैं, दो अलग आवश्यकताएँ हैं। नियम वहाँ रखें जहाँ फ़ाइल दिखाई देती है: मेल, एप्लिकेशन या एंडपॉइंट एजेंट।
एक छोटी टीम अपने कार्य सिस्टम तक दूरस्थ पहुँच माँगती है और उसी साँस में माँगती है कि कुछ अटैचमेंट कंपनी छोड़ना बंद करें। दोनों अनुरोध एक ही VPN बदलाव जैसे लगते हैं। ये अलग-अलग प्रवर्तन बिंदुओं वाली दो आवश्यकताएँ हैं, और पहली को पूरा करने वाला नियम दूसरी के लिए कुछ नहीं करता। पहले क्रिया और डेटा का नाम लें, फिर वह घटक चुनें जो वास्तव में उन्हें देख सकता है।
एक अनुरोध, दो आवश्यकताएँ
पहली आवश्यकता पहुँच के बारे में है: कौन-से उपयोगकर्ता और उपकरण किस सेवा से कनेक्शन खोल सकते हैं। दूसरी उस कनेक्शन के बनने के बाद के व्यवहार के बारे में है: कौन-से दस्तावेज़ अटैच, पेस्ट या अपलोड किए जा सकते हैं। एक टनल पहली पर काम करता है और डिज़ाइन से दूसरी के प्रति अंधा है।
IP स्तर का नियंत्रण पैकेट आगे भेजता है। यह बहु-भाग अपलोड का विश्लेषण नहीं करता, PDF नहीं जाँचता और यह तय नहीं करता कि किसी स्प्रेडशीट में खाता संख्याएँ हैं या नहीं। इससे ऐसी अपेक्षा करना कॉन्फ़िगरेशन की गलती नहीं है; यह श्रेणी की गलती है।
उत्पाद खोजने से पहले आवश्यकता को उसी रूप में ज़ोर से कहें। «उपयोगकर्ता फ़ाइल पोर्टल तक पहुँच सकते हैं» और «उपयोगकर्ता ग्राहक सूचियाँ फ़ाइल पोर्टल पर अपलोड नहीं कर सकते» अलग वाक्य हैं, और केवल दूसरा ही सामग्री नीति का वर्णन करता है।
वह घटक चुनें जो फ़ाइल देख सकता है
प्रवर्तन वहाँ होना चाहिए जहाँ फ़ाइल पठनीय हो। ईमेल के लिए यह आमतौर पर मेल प्लेटफ़ॉर्म या गेटवे होता है, जो पहले से अटैचमेंट संभालता है और डिलीवरी से पहले उनका मूल्यांकन कर सकता है। किसी स्वीकृत सेवा में ब्राउज़र अपलोड के लिए एप्लिकेशन ही एकमात्र पक्ष हो सकता है जो सामग्री देखता है। प्रबंधित लैपटॉप द्वारा फ़ाइलों को हटाए जा सकने वाले मीडिया पर कॉपी करने पर एंडपॉइंट एजेंट वह क्रिया देखता है।
| Where the file moves | Component that can see it |
|---|---|
| Email attachment | Mail gateway or mail platform policy |
| Upload to a web application | The application, or an inspection proxy that terminates TLS |
| Copy to USB or local folder | Endpoint agent on the device |
| Anything inside the tunnel | Nothing, unless one of the above is present |
कुछ वाणिज्यिक दूरस्थ-पहुँच सुइट्स एंडपॉइंट एजेंट, वेब नियंत्रण और डेटा-हानि रोकथाम मॉड्यूल को एक साथ बंडल करते हैं। वे घटक सामग्री नीति लागू कर सकते हैं, पर क्षमता टनलिंग की नहीं, मॉड्यूल की है। परिणाम का वादा करने से पहले पढ़ें कि सुइट में वास्तव में क्या है।
Microsoft का Purview डेटा-हानि रोकथाम का अवलोकन तुलना के लिए एक उपयोगी मॉडल है: यह नीतियों को संवेदनशील सूचना प्रकारों, स्थानों और गतिविधियों के रूप में वर्णित करता है। वह शब्दावली सामग्री और क्रियाओं के बारे में है, IP उपसर्गों के बारे में नहीं।
TLS टनल से पार होकर बचता है, इसलिए उसकी योजना बनाएँ
एप्लिकेशन एन्क्रिप्शन क्लाइंट और सेवा के बीच तय होता है, और VPN टनल उन बाइट्स को बिना खोले ले जाता है। इसलिए रास्ते का गेटवे अपने आप अटैचमेंट वर्गीकृत करने की क्षमता नहीं पाता, चाहे मार्ग का कितना भी हिस्सा उसका हो।
मार्ग में सामग्री जाँचने के लिए ऐसा घटक चाहिए जो विश्वसनीय प्रमाणपत्र के साथ TLS समाप्त करे, और यह अपने स्वयं के गोपनीयता और संचालन परिणामों वाला बड़ा स्थापत्य निर्णय है। यह VPN प्रोफ़ाइल का चेकबॉक्स नहीं है। क्लाइंट को जाँच प्रमाणपत्र पर भरोसा करना होगा, प्रमाणपत्र पिन करने वाले एप्लिकेशन टूट जाएँगे, और ऑपरेटर को वह ट्रैफ़िक पढ़ने की क्षमता मिलती है जो पहले नहीं पढ़ सकता था। यही कारण हैं कि यह निर्णय टनल चलाने वाले का नहीं, सुरक्षा स्वामी का है।
इसलिए «क्या VPN यह अपलोड रोक सकता है» का ईमानदार उत्तर आमतौर पर नहीं है, और उसके बाद एक ठोस विकल्प आता है। विकल्प एप्लिकेशन-स्तरीय प्रतिबंध, मेल नियम या एंडपॉइंट नीति हो सकता है, और हर एक का एक स्वामी है जो उसे बदल सकता है।
नियम से पहले स्वीकृति परीक्षण लिखें
सामग्री नियम को एक नहीं, दो उदाहरण चाहिए: एक अनुमत क्रिया जो चलती रहनी चाहिए, और एक प्रतिबंधित क्रिया जो रोकी जानी चाहिए। दायरे के एप्लिकेशन और उपकरणों से दोनों का परीक्षण करें, क्योंकि केवल एक ब्राउज़र में चलने वाली नीति वह नीति नहीं है जो किसी ने माँगी थी।
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/uploadपहला अनुरोध उस घटक द्वारा अस्वीकार होना चाहिए जो नियम रखता है, और दूसरा सफल होना चाहिए। यदि दोनों सफल हों, तो नियंत्रण रास्ते में नहीं है। यदि दोनों विफल हों, तो आपने सेवा की रक्षा नहीं, उसे तोड़ा है, जो अनुमत उदाहरण के बिना लिखे नियम का अधिक सामान्य परिणाम है।
पहले से तय करें कि उपयोगकर्ता क्या देखता है, कौन अपवाद दे सकता है और व्यवस्थापक बाद में कहाँ निर्णय की पुष्टि करता है। बिना संदेश के अवरुद्ध अपलोड सहायता टिकट बनाता है, और जिस नियम का कोई ऑडिट नहीं कर सकता वह विवाद बनाता है। नीति लागू होने से पहले लिखे गए एक वाक्य के दस्तावेज़ीकरण से दोनों टाले जा सकते हैं।
अंत में, दोनों आवश्यकताओं को अलग-अलग स्वामियों के साथ अलग-अलग टिकटों में रखें। उन्हें «VPN» के अंतर्गत एक साथ रखना यह सुनिश्चित करता है कि नेटवर्क टीम से सामग्री समस्या हल करने को कहा जाएगा, और टनल उठते ही सामग्री समस्या को हल घोषित कर दिया जाएगा।