VPN पर ईमेल फ़िल्टरिंग: सामग्री नियम वास्तव में कहाँ चलते हैं
VPN कैप्चर संदेश नहीं दिखाता। डीकैप्सुलेशन से SMTP TLS और S/MIME तक मेल पथ पर चलें, और सामग्री नियम वहाँ रखें जहाँ डेटा मौजूद है।
यह अनुरोध नेटवर्क समस्या जैसा लगता है: किसी ख़ास तरह के अटैचमेंट को इमारत से बाहर जाने से रोकें, और VPN तो पहले से है, इसलिए उसका उपयोग करें। यह ढाँचा फ़िल्टर के पहले ही सवाल पर टूट जाता है। सामग्री नियमों को संदेश देखना ज़रूरी है, और संदेश टनल से अलग परत पर दिखाई देता है। मैं पैकेट से बाहर की ओर मेल पथ पर चलता हूँ और वहाँ रुकता हूँ जहाँ ज़रूरी डेटा वास्तव में मौजूद है।
तीन परतें स्वतंत्र हैं: VPN परिवहन, SMTP TLS कनेक्शन और संदेश का अपना एन्क्रिप्शन। हर एक अलग जगह पर समाप्त होती है।
उस परत से शुरू करें जो संदेश देख सकती है
VPN डीकैप्सुलेशन आपको भीतरी नेटवर्क ट्रैफ़िक देता है। अगर मेल क्लाइंट ने सबमिशन सर्वर से TLS कनेक्शन खोला है, तो भीतरी ट्रैफ़िक में अब भी वही TLS स्ट्रीम है, पढ़ने योग्य मेल नहीं।
इसलिए टनल के किनारे लिया गया पैकेट कैप्चर उस सवाल से अलग सवाल का जवाब देता है: «क्या इस संदेश में निषिद्ध अटैचमेंट है»।
SMTP TLS समापन लिफ़ाफ़े पर समाप्त होता है
मेल सर्वर पर SMTP TLS समाप्त करने से संदेश वैसे ही खुल जाता है जैसे वह उस बिंदु पर जमा किया गया था। सर्वर हेडर, लिफ़ाफ़ा और MIME संरचना देखता है। यह कई सामग्री नियमों के लिए पर्याप्त है। लिफ़ाफ़ा आपको प्रेषक और प्राप्तकर्ता वैसे बताता है जैसे सर्वर ने उन्हें समझा।
S/MIME से सुरक्षित संदेश के लिए यह पर्याप्त नहीं है। सर्वर एक सुरक्षित इकाई प्राप्त करता है, और संबंधित कुंजियों के बिना वह उसके भीतर की सामग्री नहीं पढ़ सकता। यही सीमा उस एन्क्रिप्टेड अटैचमेंट पर भी लागू होती है जो सुरक्षित रूप से पहुँचता है।
निष्क्रिय कैप्चर को पढ़ने योग्य बनाने के लिए परिवहन सुरक्षा कमज़ोर न करें। यह नियम को डेटा वाली जगह रखने के बजाय संरचना बदल देता है।
S/MIME वहाँ समाप्त होता है जहाँ कुंजियाँ हैं
S/MIME MIME संदेश के डेटा की रक्षा करता है, इसलिए उसकी सीमा कुंजी सामग्री और अधिकृत डिक्रिप्शन व्यवस्था है। उन कुंजियों के बिना भी फ़िल्टर दिखने वाले मेटाडेटा या किसी सुरक्षित ऑब्जेक्ट की उपस्थिति पर कार्य कर सकता है, लेकिन वह अलग परिणाम है।
अगर संगठन अधिकृत एन्क्रिप्शन गेटवे या प्रबंधित एंडपॉइंट नियंत्रण चलाता है, तो दस्तावेज़ित करें कि स्पष्ट पाठ कहाँ है, कौन सी पहचान उसका निरीक्षण कर सकती है और कुंजियाँ तथा रिकॉर्ड कैसे सुरक्षित रहते हैं। VPN से ट्रैफ़िक भेजने से कोई मास्टर कुंजी नहीं बनती।
किसी के स्पष्ट पाठ वर्गीकरण का वादा करने से पहले यह लिख लें। वादा ही वह हिस्सा है जिसे वापस लेना कठिन है।
नियम को मेल प्लेटफ़ॉर्म में रखें
अगर स्वीकृत मेल सर्वर पढ़ने योग्य संदेश प्राप्त करता है, तो उसका समर्थित सामग्री-फ़िल्टर एकीकरण प्रवर्तन बिंदु है। यह फ़ायरवॉल से SMTP कनेक्शन की अनुमति देने से अलग है। यही अंतर तय करता है कि नियम अस्वीकार कर सकता है, क्वारंटीन कर सकता है या केवल टिप्पणी कर सकता है।
उदाहरण के लिए, Postfix दस्तावेज़ित करता है कतार के बाद सामग्री फ़िल्टरिंग: मेल कतार में जाता है, फ़िल्टर को दिया जाता है और डिलीवरी पथ पर लौटाया जाता है। इसकी कतार-पश्चात व्यवस्था उन कतार-पूर्व प्रॉक्सी और Milter विकल्पों से अलग है जिनका उल्लेख वही मार्गदर्शिका करती है। जिस मेल सेवा को आप वास्तव में चलाते हैं उसके लिए समर्थित एकीकरण और विफलता व्यवहार चुनें।
एक अटैचमेंट नियम संपूर्ण डेटा-हानि कार्यक्रम नहीं है। ब्राउज़र अपलोड, साझा संग्रहण और एंडपॉइंट क्रियाओं को अपने नियंत्रण चाहिए।
कृत्रिम संदेशों के साथ स्वीकृति परीक्षण लिखें
स्वीकृत कृत्रिम उदाहरणों के साथ परीक्षण करें: अनुमत संदेश, निषिद्ध सामग्री क्रिया और संदेश-स्तरीय एन्क्रिप्शन का घोषित प्रबंधन। यह भी शामिल करें कि फ़िल्टर उपलब्ध न होने पर मेल सेवा क्या करती है।
उपयोगी परिणाम क्रिया, प्रवर्तन बिंदु और वहाँ दिखने वाले डेटा का नाम लेता है। «VPN ने इसे डिक्रिप्ट किया» एक परत का जवाब देता है और मेल एप्लिकेशन के सामग्री और प्राधिकरण मॉडल का विकल्प नहीं बन सकता।