VPN माथि SQL: सिधा क्लाइन्ट वा आन्तरिक वर्कस्टेसन?
VPN ल्यापटपबाट सिधा SQL र व्यवस्थित वर्कस्टेसनमा SSMS फरक विश्वास मार्ग हुन्। प्रत्येकले बनाउने स्रोत ठेगाना र अनुमतिहरूको तुलना गर्नुहोस्।
टिमहरू आफ्ना ल्यापटपमा 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 समूहलाई सर्भर भूमिकामा थप्नुको सट्टा कार्यभारका लागि डेटाबेस भूमिका दिनुहोस्।
अनुमति दिइएको मार्ग र अस्वीकार गरिएको मार्ग प्रमाणित गर्नुहोस्
सामान्य स्वीकृत प्रयोगकर्ताका रूपमा नयाँ सत्र खोल्नुहोस् र सर्भर पहिचान, डेटाबेस र आवश्यक कार्यको पुष्टि गर्नुहोस्। त्यसपछि बहिष्करण पुष्टि गर्नुहोस्: नीति बाहिरको स्रोत वा खाता उही परीक्षणमा असफल हुनुपर्छ। वर्कस्टेसन डिजाइनका लागि, ल्यापटपले सिधै डेटाबेसमा पुगेर सीमा छल्न नसक्ने जाँच्नुहोस्। सिधा पहुँचका लागि, पुनः जडानपछि पनि मार्ग र स्रोत नियम लागू रहने जाँच्नुहोस्।
क्लाइन्ट कहाँ चल्यो, डेटाबेसले कुन स्रोत देख्यो र कुन नियमले अनुमति दियो लेख्नुहोस्। त्यो नै अर्को समीक्षाले माग्ने प्रमाण हो।