VPN पर SQL: सीधा क्लाइंट या आंतरिक वर्कस्टेशन?

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

दो रास्ते, दो स्रोत पते

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

लैपटॉप अब भी दूरस्थ सत्र नियंत्रित करता है, इसलिए वर्कस्टेशन उपयोगकर्ता प्रमाणीकरण या सत्र नीति का विकल्प नहीं है।

जाँचें कि डेटाबेस वास्तव में क्या देखता है

स्रोत पता मापने की चीज़ है, आरेख से अनुमान लगाने की नहीं। इसे किसी सक्रिय कनेक्शन के सर्वर पक्ष से पढ़ें।

Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"

कनेक्टिविटी परीक्षण साबित करता है कि श्रोता उस नेटवर्क से TCP स्वीकार करता है, जबकि क्वेरी साबित करती है कि सत्र किस लॉगिन और किस डेटाबेस तक पहुँचा। सर्वर द्वारा दर्ज पता देखने के लिए वर्तमान सत्र के लिए sys.dm_exec_connections से क्वेरी करें, जो किसी भी अनुवाद के बाद क्लाइंट पता लौटाता है। अगर वह मान लैपटॉप नहीं बल्कि गेटवे है, तो प्रति-उपयोगकर्ता होस्ट नियम डेटाबेस मशीन पर काम नहीं कर सकता। देखे गए मान को चुने गए डिज़ाइन के बगल में लिखें, क्योंकि पुनः कनेक्शन और पूल बदलाव उसे खिसका देते हैं।

श्रोता खोलें और इसके अलावा कुछ नहीं

केवल वही सेवा खोलें जिसकी परिनियोजन को ज़रूरत है। परिचित 1433 डिफ़ॉल्ट इंस्टेंस का पोर्ट है, कोई सार्वभौमिक स्थिरांक नहीं।

Get-NetTCPConnection -State Listen -LocalPort 1433

नामित इंस्टेंस अक्सर गतिशील पोर्ट पर सुनते हैं, SQL Server Browser UDP 1434 पर खोज का उत्तर देता है, और यह निर्भरता एक अलग जोखिम है जिसे न्यायोचित ठहराना पड़ता है। इंस्टेंस के लिए स्थिर पोर्ट पिन करने से Browser की ज़रूरत हट जाती है और फ़ायरवॉल नियम स्थिर हो जाते हैं। परीक्षण पास कराने के लिए क्लाइंट के मौजूदा एन्क्रिप्शन और प्रमाणपत्र जाँच बंद करने के बजाय उन्हें बनाए रखें। फिर पूरे VPN समूह को सर्वर भूमिका में जोड़ने के बजाय कार्यभार के लिए डेटाबेस भूमिकाएँ दें।

अनुमत रास्ता और अस्वीकृत रास्ता साबित करें

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

दर्ज करें कि क्लाइंट कहाँ चला, डेटाबेस ने कौन-सा स्रोत देखा और किस नियम ने अनुमति दी। यही वह सबूत है जो अगली समीक्षा माँगेगी।