डोमेन ट्रस्ट बिना Excel बाट साझेदारको SQL Server मा
Excel जडानलाई स्वीकृत पहिचान, प्रमाणित TLS र एउटा नेटवर्क मार्ग चाहिन्छ। पहिलोमा मात्र डोमेन ट्रस्ट समावेश हुन्छ; बाँकी अन्यत्र हुन्छन्।
अर्को संस्थाको 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 कार्यप्रवाहले प्रमाणित गर्नुहोस्: स्वीकृत पहिचान, प्रभावकारी अनुमति र वार्ता गरिएको इन्क्रिप्शन, प्रत्येक सर्भरको आफ्नै सत्र दृश्यबाट।