डोमेन ट्रस्टशिवाय 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 कार्यप्रवाहाने सत्यापित करा: स्वीकारलेली ओळख, प्रभावी परवानग्या आणि वाटाघाटी केलेले एन्क्रिप्शन, प्रत्येक सर्व्हरच्या स्वतःच्या सत्र दृश्यातून.