Firebird 3 का वायर एन्क्रिप्शन और VPN दो अलग सीमाएँ हैं

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

दो सीमाएँ, और वे एक-दूसरे पर नहीं चढ़तीं

VPN सीमा क्लाइंट और गेटवे के बीच पैकेट की रक्षा करती है। Firebird का वायर एन्क्रिप्शन क्लाइंट लाइब्रेरी और सर्वर प्रक्रिया के बीच डेटाबेस प्रोटोकॉल की रक्षा करता है। दोनों मौजूद हो सकते हैं, और कोई भी दूसरे का स्थान नहीं लेता।

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

पहली सीमा: लिसनर कौन खोल सकता है

असली सर्वर पता और कॉन्फ़िगर किया गया पोर्ट पहचानें, जो बदला न गया हो तो 3050 है, फिर होस्ट और नेटवर्क फ़ायरवॉल पर केवल अनुमोदित VPN स्रोतों को अनुमति दें। VPN गेटवे पर किसी भी पता अनुवाद को ध्यान में रखें, और गेटवे अलग हो तो डेटाबेस होस्ट को क्लाइंट पूल तक वापसी मार्ग दें।

फिर निषेध सिद्ध करें। जिस बाहरी मार्ग को अस्वीकार होना चाहिए, वह अस्वीकृत ही रहना चाहिए, क्योंकि सुरंग खोलने से Firebird लिसनर अपने आप सीमित नहीं होता।

दूसरी सीमा: Firebird किस पर बातचीत करता है

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

Firebird 3 के रिलीज़ नोट्स में Arc4 को उस रिलीज़ के लिए डिफ़ॉल्ट वायर-एन्क्रिप्शन प्लगइन के रूप में सूचीबद्ध किया गया है। Arc4 एक ऐतिहासिक डिफ़ॉल्ट है, आधुनिक सिफ़र की सिफ़ारिश नहीं, और यह बाहरी VPN सुरक्षा के समान नहीं है।

प्रमाणीकरण उसी बातचीत में तीसरा चर है। सर्वर प्रमाणीकरण प्लगइन का एक समूह स्वीकार करता है, क्लाइंट लाइब्रेरी उसका कोई उपसमूह प्रस्तावित करती है, और दोनों को ओवरलैप करना होता है।

Legacy_Auth का जाल

Legacy_Auth का समर्थन करने के लिए सर्वर की डिफ़ॉल्ट अनिवार्य-एन्क्रिप्शन नीति को ढीला करना पड़ता है। यही प्रलेखित संगतता लागत है, और इसीलिए कनेक्शन त्रुटि को शांत करने के लिए नीति घटाना सुधार नहीं, सुरक्षा परिवर्तन है।

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

उस कनेक्शन की जाँच करें जो मायने रखता है

जिस बिल्ड में संदर्भ चर उपलब्ध है, वहाँ यह क्वेरी वर्तमान कनेक्शन की एन्क्रिप्शन स्थिति बताती है:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

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

क्लाइंट लाइब्रेरी का संस्करण, सर्वर बिल्ड और परिणाम एक साथ दर्ज करें, क्योंकि इनमें से कोई भी अकेला पढ़ने योग्य नहीं है।

अनुमतियाँ और अपग्रेड पथ

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

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