हाल ही में, Microsoft ने SQL सर्वर के लिए दो नए ड्राइवर जारी किए, एक प्रमुख अपग्रेड:
SQL सर्वर के लिए ODBC 18 ड्राइवर
OLEDB 19 SQL सर्वर के लिए ड्राइवर
ये तो अच्छी खबर है! हालाँकि, एक बड़ा ब्रेकिंग परिवर्तन है जिस पर आपका ध्यान देने की आवश्यकता है। विशेष रूप से, उन्होंने बदल दिया कि एन्क्रिप्शन के लिए डिफ़ॉल्ट सेटिंग्स कैसे काम करती हैं। ड्राइवरों के सभी पूर्व संस्करणों में, डिफ़ॉल्ट को एन्क्रिप्शन की आवश्यकता नहीं थी। हमारे पास सर्वर साइड से एन्क्रिप्शन को बाध्य करने या क्लाइंट साइड पर कनेक्शन स्ट्रिंग के भीतर अनुरोध करने के विकल्प थे। जाहिर है, सर्वर व्यवस्थापक के लिए, सर्वर से एन्क्रिप्शन को बाध्य करना आमतौर पर अधिक वांछनीय था, ताकि कोई फर्क नहीं पड़ता कि कुछ पुराने एप्लिकेशन ने इसके लिए अनुरोध नहीं किया है, लेकिन सर्वर के साथ इसके संचार को एन्क्रिप्ट करने की गारंटी होगी।
2 कनेक्शन स्ट्रिंग कीवर्ड और एक सर्वर सेटिंग है जो यह प्रभावित करती है कि ड्राइवर को कैसा व्यवहार करना चाहिए:
क्लाइंट साइड से कनेक्शन स्ट्रिंग के भीतर:
Encrypt:इंगित करता है कि संचार एन्क्रिप्ट किया जाना चाहिए या नहीं।TrustServerCertificate:इंगित करता है कि क्लाइंट को प्रमाण पत्र की प्रामाणिकता की जांच किए बिना सर्वर के प्रमाणपत्र पर भरोसा करना चाहिए या नहीं।
सर्वर साइड से सेटिंग के भीतर:
Force Encryption:सर्वर से कनेक्ट होने वाला कोई भी क्लाइंट क्लाइंट के कनेक्शन स्ट्रिंग की परवाह किए बिना संचार को एन्क्रिप्ट करने के लिए कहता है।
3 गुणों का संयोजन प्रभावित करता है कि कनेक्शन कैसे बनाया जाएगा। उनकी गणना करने वाला एक आसान चार्ट है, जो यहां पाया जा सकता है..
हालांकि, सबसे आम परिदृश्य यह है कि हम सर्वर से एन्क्रिप्शन को बाध्य करते हैं और कनेक्शन स्ट्रिंग में कुछ और निर्दिष्ट नहीं करते हैं। पिछले संस्करणों और नए संस्करण व्यवहार दोनों का निकाला गया संस्करण यहां दिया गया है:
संस्करण | एन्क्रिप्ट करें | ट्रस्ट सर्वर सर्टिफिकेट | सर्वर बल एन्क्रिप्शन | परिणाम |
|---|---|---|---|---|
| ODBC 17 और पूर्व OLEDB 18 और पूर्व | नहीं | नहीं | हां | सर्वर प्रमाणपत्र चेक नहीं किया गया है। क्लाइंट और सर्वर के बीच भेजा गया डेटा एन्क्रिप्ट किया गया है। |
| ODBC 18 OLEDB 19 | नहीं | नहीं | हां | सर्वर प्रमाणपत्र चेक किया गया है। क्लाइंट और सर्वर के बीच भेजा गया डेटा एन्क्रिप्ट किया गया है। |
मुझे लगता है कि यह आम तौर पर एक अच्छी बात है, विशेष रूप से Azure SQL डेटाबेस के अधिक सामान्य होने के साथ, लेकिन SQL सर्वर प्रमाणपत्र की जाँच में परिवर्तन एक बदलाव का परिचय देता है, विशेष रूप से उन सर्वरों के लिए जिनके पास प्रमाणपत्र सेट नहीं हो सकते हैं। डिफ़ॉल्ट रूप से, यह एक स्व-हस्ताक्षरित प्रमाणपत्र का उपयोग करेगा, जो उतना सुरक्षित नहीं है जितना कि विश्वसनीय है। उन सर्वरों के लिए जहां इंटरनेट पर कनेक्शन किए जाते हैं, अतिरिक्त एहतियात प्रयास के लायक है।
पिछले संस्करण और अब-वर्तमान संस्करण के बीच SQL सर्वर परिवर्तनों के साथ Microsoft Access के लिए ODBC कनेक्शन स्ट्रिंग की तुलना यहां दी गई है:
ओडीबीसी 17 बनाम ओडीबीसी 18
17:DRIVER=ODBC Driver 17 for SQL Server;SERVER= ;DATABASE= ;
18:DRIVER=ODBC Driver 18 for SQL Server;SERVER= ;DATABASE= ;
SQL सर्वर के साथ Microsoft Access के लिए OLEDB 18 बनाम OLEDB 19 कनेक्शन स्ट्रिंग्स
18:Provider= ;Data Source= ;Initial Catalog= ;
19:Provider= ;Data Source= ;Initial Catalog=
ध्यान दें कि पिछले संस्करणों में, आपको Encrypt=yes . निर्दिष्ट करना था लेकिन यह अब वर्तमान संस्करणों में निहित है।
ठीक है, लेकिन मेरे पास ऑन-प्रिमाइसेस सर्वर है लेकिन यह नए ड्राइवरों के साथ काम नहीं कर रहा है?
सेटिंग में बदलाव के कारण, अब आपको यह त्रुटि दिखाई दे सकती है:
परिदृश्य और आवश्यकताओं के आधार पर, यहां संभावित समाधान दिए गए हैं:
- सर्वर पर एक विश्वसनीय प्रमाणपत्र स्थापित और कॉन्फ़िगर करें।
- एप्लिकेशन की कनेक्शन स्ट्रिंग को
TrustServerCertificate=Yesशामिल करने के लिए संशोधित करें . सावधानी से उपयोग करें - एप्लिकेशन की कनेक्शन स्ट्रिंग को
Encrypt=Noशामिल करने के लिए संशोधित करें औरForce Encryptionसर्वर पर। अनुशंसित नहीं - ड्राइवरों को अपडेट न करें।
समस्या को हल करने के चरण संबंधित अनुभागों में विस्तृत हैं।
संकल्प
सर्वर पर एक विश्वसनीय प्रमाणपत्र स्थापित और कॉन्फ़िगर करें
यह नोट करना बहुत महत्वपूर्ण है कि सिर्फ इसलिए कि आपके पास एक सर्वर है जिसमें एक वैध एसएसएल प्रमाणपत्र स्थापित है और सक्रिय उपयोग में वास्तव में इसका मतलब यह नहीं है कि SQL सर्वर उसी प्रमाणपत्र का उपयोग कर रहा है। इसके अलावा, यह पता चला है कि SQL सर्वर कॉन्फ़िगरेशन प्रबंधक प्रमाणपत्रों को संभालने में भयानक है। आप पा सकते हैं कि यह आपके उपयोग के लिए किसी भी प्रमाणपत्र की सूची नहीं देगा:
संक्षिप्त संस्करण यह है कि SQL सर्वर कॉन्फ़िगरेशन प्रबंधक अत्यधिक प्रतिबंधात्मक है कि वह किन प्रमाणपत्रों को सूचीबद्ध करेगा, जो विशेष रूप से काफी निराशाजनक हो सकता है क्योंकि यह एक UI समस्या है, न कि SQL सर्वर द्वारा एक वास्तविक आवश्यकता। सौभाग्य से, हम सीधे रजिस्ट्री को संपादित करके इस मूर्खतापूर्ण UI सीमा को दरकिनार कर सकते हैं। यह रजिस्ट्री कुंजी से मेल खाती है:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<name of your instance>\MSSQLServer\SuperSocketNetLib
उस कुंजी के भीतर, एक मान होता है Certificate जो प्रमाणपत्र के अंगूठे के निशान की अपेक्षा करता है।
आप उपयोग किए जाने वाले एसएसएल प्रमाणपत्र के थंबप्रिंट में मैन्युअल रूप से पेस्ट कर सकते हैं, लेकिन मैं ऐसा करने के लिए एक स्क्रिप्ट का उपयोग करने की सलाह दूंगा क्योंकि हमें यह सुनिश्चित करने की भी आवश्यकता है कि सर्वर खाते में प्रमाणपत्र तक पहुंचने की अनुमति है। मैंने इस ब्लॉग आलेख का उपयोग प्रमाणपत्र का चयन करने और इसे SQL सर्वर की रजिस्ट्री कुंजी में लोड करने और सेवा को पुनरारंभ करने के लिए PowerShell स्क्रिप्ट को सेट करने के लिए एक मार्गदर्शिका के रूप में किया था। आपका एसएसएल प्रमाणपत्र और कार्यप्रवाह कौन प्रदान करता है, इस पर निर्भर करते हुए, आप इसे कुछ अन्य अनुसूचित कार्यों में एकीकृत करना चाह सकते हैं ताकि जब एसएसएल प्रमाणपत्र का नवीनीकरण किया जाए, तो रजिस्ट्री कुंजी और अनुमतियों को तदनुसार अपडेट किया जाएगा।
यदि सब कुछ सही तरीके से सेट किया गया है, तो आपका सर्वर एप्लिकेशन के कनेक्शन स्ट्रिंग में बिना किसी संशोधन के नए ड्राइवरों का उपयोग करने में सक्षम होना चाहिए। एक अतिरिक्त सत्यापन के रूप में, आप अपने SQL सर्वर के त्रुटि लॉग की जांच कर सकते हैं और इस तरह की एक पंक्ति की तलाश कर सकते हैं:
<timestamp> spid11s The certificate [Cert Hash(sha1) "<certificate thumbprint>"] was successfully loaded for encryption.
यदि अंगूठे का निशान उस से मेल खाता है जिसका आप उपयोग करना चाहते हैं, तो आप जानते हैं कि आपने इसे सही तरीके से लोड किया है और इस प्रकार अब विश्वास की श्रृंखला स्थापित हो गई है।
TrustServerCertificate=Yes शामिल करने के लिए एप्लिकेशन के कनेक्शन स्ट्रिंग को संशोधित करें
हालाँकि, यदि आपका सर्वर इंटरनेट का सामना नहीं कर रहा है और SSL प्रमाणपत्र सेट करना बहुत दर्दनाक है, तो TrustServerCertificate को चालू करना स्वीकार्य हो सकता है। . इसके लिए आपके एप्लिकेशन की कनेक्शन स्ट्रिंग में बदलाव की आवश्यकता है। यह एप्लिकेशन को सर्वर के प्रमाणपत्र को सत्यापित किए बिना सर्वर से कनेक्ट करने की अनुमति देता है। यदि आप अपने एप्लिकेशन को आत्मविश्वास से नियंत्रित करने में सक्षम हैं ताकि यह आपके नेटवर्क से बाहर न जाए, तो यह ठीक होना चाहिए। ध्यान रखें कि अगर कोई नेटवर्क के भीतर सर्वर के नाम या आईपी को खराब करने में सक्षम है, तो क्लाइंट एप्लिकेशन उस कंप्यूटर से आँख बंद करके कनेक्ट हो जाएंगे। इस कारण से, यदि कनेक्शन में इंटरनेट शामिल है तो हम इसकी अनुशंसा नहीं कर सकते। हम वास्तव में जोखिम नहीं लेना चाहेंगे।
एप्लिकेशन की कनेक्शन स्ट्रिंग को Encrypt=No . शामिल करने के लिए संशोधित करें और Force Encryption सर्वर पर।
यह उन लोगों के लिए है जो एक विशाल नियॉन साइन के साथ इंटरनेट पर स्ट्रीकिंग पसंद करते हैं "मेरा डेटा चुराओ! अब मुझे हाईजैक करो!" हर बुरे अभिनेताओं के लिए। यह एर्म है, एक "विकल्प"। इस विकल्प के बारे में मैं केवल इतना ही कह सकता हूं कि यह बेहद खराब है। इतना बुरा कि मैं भूल गया कि यह कैसे करना है। आप अकेले हैं, दोस्त।
ड्राइवरों को अपडेट न करें।
पिछले की तुलना में थोड़ा बेहतर विकल्प है कि ओडीबीसी 17 और ओएलडीडीबी 18 ड्राइवरों के साथ अपडेट न करें और चिपके रहें। हालाँकि, यह सबसे अच्छा स्टॉपगैप उपाय है। इस संकल्प के लिए किसी अनुप्रयोग परिवर्तन की आवश्यकता नहीं है, लेकिन यह केवल अपरिहार्य परिवर्तनों में देरी करता है। आप समय का सदुपयोग उन रास्तों को एक्सप्लोर करने में कर सकते हैं जो आपको नवीनतम संस्करण तक पहुंचाएंगे और आपके डेटा को ठीक से सुरक्षित रखेंगे।
आशा है कि इससे मदद मिलेगी!
