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;

ती अनुप्रयोगाच्या स्वतःच्या कनेक्शनने चालवा, त्याच सर्व्हरवरील प्रशासक सत्राने नाही. एन्क्रिप्टेड प्रशासक कनेक्शन दुसऱ्या क्लायंट लायब्ररीच्या सत्राबद्दल काहीही सांगत नाही, आणि चलला समर्थन न देणारे जुने बिल्ड एन्क्रिप्शन बंद आहे याचा पुरावा नाही.

क्लायंट लायब्ररीची आवृत्ती, सर्व्हर बिल्ड आणि निकाल एकत्र नोंदवा, कारण यापैकी कोणतेही एकटे वाचनीय नाही.

परवानग्या आणि अपग्रेड मार्ग

स्रोत मर्यादित करणे आणि वाहतूक एन्क्रिप्ट करणे प्रमाणीकरण किंवा किमान-विशेषाधिकार परवानग्यांची जागा घेत नाही. सामान्य डेटाबेस वापरकर्त्याच्या ज्या वस्तूंना तो खरोखर स्पर्श करतो त्यावरील परवानग्या तपासा.

शेवटी, दीर्घकालीन तैनातीकडे देखभालीचा प्रश्न म्हणून पाहा. बोगदा जुन्या क्लायंट लायब्ररीला अनिश्चित काळासाठी सुरक्षित करत नाही, आणि समर्थित अपग्रेड मार्ग त्याला आवश्यक असलेले प्लगइन काढून टाकले गेले हे शोधण्यापेक्षा स्वस्त आहे.