डोमेन ट्रस्ट के बिना Excel से साझेदार के SQL Server तक

दूसरे संगठन के SQL Server पर तालिका खोलने वाली Excel कार्यपुस्तिका को तीन चीज़ें चाहिए, जिन पर सामान्यतः एक ही चीज़ की तरह चर्चा होती है: वह पहचान जिसे सर्वर स्वीकार करे, वह परिवहन जिसे क्लाइंट सत्यापित करे, और वह नेटवर्क पथ जिसे दोनों पक्ष अनुमति दें। डोमेन ट्रस्ट पहली को पूरा करने का एक तरीका है, और सबसे व्यापक। TLS दूसरी को पूरा करता है और पहली के बारे में कुछ नहीं कहता। पथ तीसरी को पूरा करता है और अपने आप में कुछ भी नहीं बचाता।

तीनों को अलग करना स्प्रेडशीट को प्रशासनिक संबंध के बजाय एक छोटा, समीक्षा-योग्य अनुरोध बना देता है।

प्रश्न जिन तीन निर्णयों को छिपाता है

पहचान वह है जो डेटाबेस मानता है कि आप हैं: विश्वसनीय डोमेन का Windows खाता, अपने स्वयं के पासवर्ड वाला SQL लॉगिन, या प्रमाणपत्र-आधारित पहचान। परिवहन यह है कि सत्र एन्क्रिप्टेड है या नहीं और क्लाइंट सर्वर की प्रमाणपत्र श्रृंखला जाँचता है या नहीं। पथ यह है कि पैकेट श्रोता तक कैसे पहुँचते हैं, जो VPN, निजी लिंक या फ़ायरवॉल नियमों वाला सार्वजनिक एंडपॉइंट हो सकता है। हर एक अलग जगह रहता है और हर एक अकेले विफल हो सकता है।

फ़ॉरेस्ट ट्रस्ट पहली का व्यापक उत्तर देता है और यह संगठनों के बीच संबंध है, एक कार्यपुस्तिका के लिए सेटिंग नहीं। यह कुछ भी एन्क्रिप्ट भी नहीं करता, जो उन लोगों को चौंकाता है जिन्होंने मान लिया था कि ट्रस्ट ही सुरक्षा नियंत्रण है।

फ़ॉरेस्ट ट्रस्ट के बिना पहचान

लक्ष्य वातावरण में जानबूझकर तैयार किया गया खाता बिना किसी ट्रस्ट के संकीर्ण आवश्यकता पूरी कर सकता है, बशर्ते क्लाइंट का कार्यप्रवाह इसका उपयोग कर सके। SQL प्रमाणीकरण दूसरा सामान्य उत्तर है जब नीति अनुमति देती है: लॉगिन अपना स्वयं का क्रेडेंशियल जीवनचक्र रखता है और डोमेन में शामिल नहीं होता या Windows एकीकृत प्रमाणीकरण उत्पन्न नहीं करता। प्रमाणपत्र या टोकन आधारित पहचान नए प्लेटफ़ॉर्म पर तीसरा विकल्प है। आप जो भी चुनें, केवल वही डेटाबेस अनुमतियाँ दें जिनकी कार्यपुस्तिका को वास्तव में आवश्यकता है।

किसी के व्यक्तिगत लॉगिन के बजाय समर्पित खाते को प्राथमिकता दें। स्प्रेडशीट में साझा क्रेडेंशियल एक सहायता समस्या है जो होने की प्रतीक्षा कर रही है, और नामित खाता परियोजना समाप्त होने पर निरसन संभव बनाता है।

एन्क्रिप्शन हाँ, फिर भी प्रमाणपत्र पर भरोसा?

ODBC Driver 18 के साथ, Encrypt=Yes;TrustServerCertificate=No ऐसा एन्क्रिप्टेड सत्र माँगता है जिसका प्रमाणपत्र वास्तव में जाँचा जाता है। तब कनेक्शन स्ट्रिंग को वह सर्वर नाम देना होगा जिसे प्रमाणपत्र कवर करता है, और क्लाइंट को उसकी श्रृंखला पर भरोसा करना होगा। Driver 18 पहले के संस्करणों के विपरीत डिफ़ॉल्ट रूप से एन्क्रिप्शन भी लागू करता है, इसलिए पुरानी कनेक्शन स्ट्रिंग अब बिना बताए TLS पर बातचीत कर सकती है। स्पष्ट सेटिंग्स इच्छित नीति को सभी मशीनों पर दृश्यमान बनाती हैं, जो तब मायने रखता है जब कई लोग एक ही कार्यपुस्तिका बनाए रखते हैं।

TrustServerCertificate=Yes एन्क्रिप्ट करता है और सत्यापन छोड़ देता है, जो नाम के बेमेल या असत्यापित श्रृंखला के लिए समतुल्य मरम्मत नहीं है। यह उस संकेत को हटा देता है जो आपको बताता कि क्लाइंट गलत एंडपॉइंट पर पहुँचा, इसलिए प्रमाणपत्र या नाम ठीक करें।

सर्वर-साइड प्रवर्तन एक अलग नियंत्रण है। यदि एन्क्रिप्शन हर क्लाइंट पर लागू होना चाहिए, तो सर्वर की बाध्य-एन्क्रिप्शन सेटिंग कॉन्फ़िगर करें और सत्यापित करें, क्योंकि एक सहयोगी कनेक्शन स्ट्रिंग कुछ भी लागू नहीं करती।

नेटवर्क पथ ही सुरक्षा नहीं है

VPN के माध्यम से पहुँचा जाने वाला निजी श्रोता जोखिम कम करता है, और यह काम करने के लिए VPN को सही गंतव्य और वापसी मार्ग ले जाने होंगे। काम करने वाला टनल प्रमाणीकरण की आवश्यकता या प्रमाणपत्र सत्यापन को नहीं हटाता, और TLS यह सीमित नहीं करता कि कौन से दूरस्थ सिस्टम कनेक्शन का प्रयास कर सकते हैं। ये तीन अलग अवलोकन हैं: TLS हैंडशेक, VPN लॉगिन और अधिकृत क्वेरी। केवल तीसरा साबित करता है कि कार्यपुस्तिका ने वह डेटा पढ़ा जिसे पढ़ने की उसे अनुमति थी।

इसलिए डेटाबेस को इंटरनेट पर उजागर करके ट्रस्ट के प्रश्न का उत्तर देने के शॉर्टकट का विरोध करें। संकीर्ण उत्तर सामान्यतः समर्पित खाता, सत्यापित एन्क्रिप्शन और एक स्वीकृत पथ है, उसी क्रम में।

सामान्य Excel कार्यप्रवाह से सत्यापित करें: स्वीकृत पहचान, प्रभावी अनुमतियाँ और बातचीत किया गया एन्क्रिप्शन, प्रत्येक सर्वर के अपने सत्र दृश्य के माध्यम से।