SSMS पर कुछ लॉगिन करने के लिए SQL सर्वर तक पहुंच से कैसे इनकार करें, लेकिन .Net SqlClient डेटा प्रदाता को अनुमति दें

Question

हमारे पास एक ऐसी स्थिति है जहां डेवलपर्स के पास कोई UPDATEअनुमति नहीं है , लेकिन वे अनुप्रयोगों के साथ काम करते हैं और कनेक्शन तार देखते हैं -> वे कुछ SQL खातों (उदाहरण SQLLogin1) से पासवर्ड जानते हैं जिनके पास अद्यतन अनुमतियाँ हैं। वर्तमान में हमारे ऑपरेशन सही नहीं हैं, और कभी-कभी उत्पादन डेटा को संशोधित करने की आवश्यकता होती है (अभी तक इसके लिए कोई जीयूआई नहीं)।

DBA से संपर्क करने और उसे डेटा को संशोधित करने के लिए कहने के बजाय, डेवलपर (अनुचित तरीके से) SQL खाते का उपयोग करेगा ( SQLLogin1जिसमें डेटा को संशोधित करने की अनुमति है), और डेटा को स्वयं संशोधित करने के लिए SQL सर्वर प्रबंधन स्टूडियो से कनेक्ट करें।

DBA SQLLogin1नया कनेक्शन स्ट्रिंग और नया पासवर्ड देखकर डेवलपर के बिना पासवर्ड नहीं बदल सकता है , क्योंकि एप्लिकेशन कनेक्शन स्ट्रिंग जो SQLLogin1डेवलपर द्वारा बनाए रखा जाता है।

सवाल:

क्या SQLLogin1एसक्यूएल लॉगिन तक पहुंच से इनकार करने का एक तरीका है , लेकिन केवल अगर यह एसएसएमएस पर कनेक्ट हो रहा है?

उसी समय यदि SQLLogin1ओवर .Net SqlClient Data Provider( program_nameइन sys.dm_exec_sessions) कनेक्ट हो रहा है , तो उसे लॉगिन करने की अनुमति दी जानी चाहिए।

इस तरह हम डेवलपर को SSMS का उपयोग करने से कनेक्ट नहीं होने देना चाहते हैं SQLLogin1, जबकि जो एप्लिकेशन उपयोग कर रहा है SQLLogin1, वह अभी भी कनेक्ट करने में सक्षम होगा।

Answer 1

आप कस्टम लॉगऑन सत्यापन करने के लिए एक सर्वर लॉगऑन ट्रिगर का उपयोग कर सकते हैं और जब भी आप फिट देखते हैं तो उन्हें अस्वीकार कर सकते हैं। यदि आप SSMS का उपयोग कर रहे हैं तो आपको "सर्वर ऑब्जेक्ट्स" और "ट्रिगर" के अंदर सूचीबद्ध यह ट्रिगर दिखाई देगा।

उदाहरण के लिए:

CREATE TRIGGER strRejectSSMSConnectionForSQLLogin1
ON ALL SERVER FOR LOGON
AS
BEGIN

    IF ORIGINAL_LOGIN() = N'SQLLogin1' AND PROGRAM_NAME() LIKE N'Microsoft SQL Server Management Studio%'
    BEGIN
        RAISERROR('Direct connection by SSMS refused.', 16, 1)
        ROLLBACK
    END

END

ROLLBACKअंदर ट्रिगर कनेक्शन को अस्वीकार कर देंगे (वहाँ एक अंतर्निहित लेनदेन लॉगऑन घटना पर ट्रिगर करने के लिए कॉल लपेटकर है)।

लॉगऑन ट्रिगर को लागू करते समय सावधान रहें, यदि ठीक से कोडित नहीं किया गया है, तो आप लॉगिन को अस्वीकार कर देंगे जो लॉगिन (अपने स्वयं सहित) में सक्षम होना चाहिए। पहले परीक्षण / देव वातावरण पर परीक्षण करना सुनिश्चित करें।

ध्यान रखें कि इस कोड को सत्र बनाने से पहले निष्पादित किया जाता है , इसलिए सत्र आईडी (SPID) पर भरोसा करने वाले सिस्टम दृश्य में वर्तमान में चेक किया गया लॉगिन नहीं होगा जब तक कि ट्रिगर रोलबैक या उच्च पर्याप्त विफलता के बिना समाप्त नहीं हो जाता।

Comments

धन्यवाद! प्रश्न - अगर मैं लॉगऑन ट्रिगर में कोई गलती करता हूं, और यह लॉग इन करने से भी sysadmin खाते को ब्लॉक करता है, तो क्या अभी भी SQL सर्वर में आने और लॉगऑन ट्रिगर को अक्षम करने का एक तरीका है?

— एलेक्सी विट्स्को

यदि आप डीएसी (समर्पित प्रशासक कनेक्शन) के साथ जुड़ते हैं तो आप इसके बिना ट्रिगर को छोड़ सकते हैं। यह एक विशेष एकल-उपयोगकर्ता कनेक्शन है जो आप सर्वर के खिलाफ जारी कर सकते हैं जब भी चीजें गलत होती हैं। यह आमतौर पर sqlcmd के साथ सीधे उपयोग किया जाता है, लेकिन आप इसे SSMS के साथ भी कर सकते हैं। docs.microsoft.com/en-us/prepret-versions/sql/…

— EzLo

यह कुछ मिनटों के लिए काम करेगा, जब तक कि डेवलपर एक अलग टूल का उपयोग नहीं करता। यदि आप अनुमतियों के साथ लॉगिन जानते हैं तो आप बस एक अच्छे डेवलपर को बाहर नहीं रख सकते।

— जो

यह सुरक्षा समाधान की तुलना में अधिक नीतिगत समाधान है। IE लॉगऑन ट्रिगर यह स्पष्ट करता है कि यह उत्पादन डेटाबेस से सीधे जुड़ने की नीति के खिलाफ है। और चूंकि यह संभावना नहीं है कि आप किसी भी तरह से वास्तव में दुर्भावनापूर्ण डेवलपर के खिलाफ रक्षा कर सकते हैं , जो काफी अच्छा हो सकता है।

— डेविड ब्राउन - Microsoft

@voo मुझे स्पष्ट करना चाहिए था। आप दुर्भावनापूर्ण डेवलपर्स के साथ उत्पादन पर्यावरण तक पहुंच के साथ रक्षा नहीं कर सकते ।

— डेविड ब्राउन -

Answer 2

मुझे लगता है कि आपकी समस्या का कोई विश्वसनीय समाधान नहीं है क्योंकि Application Nameयह परिवर्तन योग्य है parameterकि किसी भी उपयोगकर्ता द्वारा कैम को बदल दिया जाए।

यहाँ इसे कैसे बदलना है SSMS:

में Connect to Database Objectसंवाद विकल्प खुले चुनें Additional Connection Parametersऔर के लिए किसी भी नाम का चयन Application Nameइस तरह:

अब sys.dm_exec_sessionsDMV और Program_name () आपको दिखाएगा कि आपने Application Nameपैरामीटर में अपने कनेक्शन स्ट्रिंग में क्या पास किया है :

Answer 3

आप एक विशिष्ट ग्राहक को नहीं काट सकते, जैसा कि पहले से ही अन्य उत्तरों में विस्तृत है।

समाधान डेवलपर के खातों से उत्पादन प्रणालियों तक पहुंच विशेषाधिकार को हटाने के लिए है।

किसी भी परिवर्तन को स्क्रिप्ट किया जाना चाहिए और एक dba स्क्रिप्ट चलाएगा।

एक sysadmin द्वारा परिनियोजन किया जाता है; देवता एक पैकेज का निर्माण करते हैं जो वे किसी को उचित विशेषाधिकार के साथ देते हैं और देवता कभी भी उत्पादन प्रणालियों पर उपयोग किए गए कॉन्फ़िगरेशन को नहीं देखते हैं।

डिबगिंग को मामले के आधार पर एक स्टेजिंग वातावरण में उत्पादन डेटा की एक प्रतिलिपि के साथ एक पसंदीदा समाधान या सीमित विशेषाधिकारों के साथ एक अस्थायी खाते के रूप में आवश्यक होने पर व्यवस्थित किया जाता है।

Answer 4

1. आदर्श अर्थों में, यह एक प्रक्रिया / नीति / प्रबंधन समस्या है। यहां तक ​​कि अगर किसी को पासवर्ड पता है, अगर यह किसी के लिए कंपनी की नीति के खिलाफ है, लेकिन उत्पादन से जुड़ने के लिए एक डीबीए (अच्छी तरह से, आपके पास एक रिलीज इंजीनियरिंग टीम और / या साइज़ एडिंस आदि हो सकते हैं), और नियमों को तोड़ने के लिए दंड हैं, तब यह पर्याप्त होना चाहिए (यह मानते हुए कि इस तरह के नियम लागू किए जाते हैं)।

2. किसी विशेष एप्लिकेशन को कनेक्ट होने से रोकने की कोशिश असंभव है। जैसा कि सेपिक ने प्रदर्शित किया , "प्रोग्राम का नाम" बदलना काफी आसान है। लेकिन यहां तक ​​कि अगर डेवलपर यह पता नहीं लगा सकता है, तो बहुत सारे अन्य प्रोग्राम हैं जो SQL सर्वर से जुड़ सकते हैं। अधिकांश लोगों के पास SQLCMD.exe और यहां तक ​​कि पदावनत OSQL.exe तक पहुंच होगी । डेवलपर विजुअल स्टूडियो के भीतर से कनेक्ट हो सकता है, और वे ".net SqlClient डेटा प्रदाता" के माध्यम से कनेक्ट करने के लिए अपना खुद का ऐप भी बना सकते हैं। ओह, और अब हमारे पास Azure Data Studio भी है। यह बहुत अधिक है।

3. फिर भी, यह तब भी संभव हो सकता है यदि हम इसे दूसरी दिशा से ले जाते हैं: एप्लिकेशन एक्स को कनेक्ट करने से रोकने के बजाय, केवल एप्लिकेशन वाई को कैसे कनेक्ट करने की अनुमति देता है? निश्चित रूप से, हम फिर से "प्रोग्राम नाम" पर पहुंच जाते हैं, और यहां तक ​​कि "होस्टनाम" को भी स्पूफ किया जा सकता है, लेकिन, मुझे पूरा यकीन है कि क्लाइंट का आईपी एड्रेस खराब नहीं हो सकता है (कम से कम कनेक्शन स्ट्रिंग कीवर्ड के माध्यम से नहीं)। आप ऐप सर्वर (एस) का आईपी पता जानते हैं, या इसे sys.dm_exec_connectionsडीएमवी ( client_net_addressक्षेत्र में) से आसानी से पा सकते हैं ।

   EzLo द्वारा सुझाए गए Logon ट्रिगर के साथ शुरू करते हुए , हम तर्क को संशोधित कर सकते हैं जो निर्धारित करता है कि कनेक्शन मान्य है या नहीं निम्नलिखित होने के लिए:

   IF (ORIGINAL_LOGIN() = N'SQLLogin1'
       AND (
                CONVERT(VARCHAR(10), CONNECTIONPROPERTY('net_transport')) <> 'TCP'
             OR CONVERT(VARCHAR(10), CONNECTIONPROPERTY('client_net_address')) <> '10.10.10.10'
    -- uncomment below (and comment-out line above) if app uses multiple IP addresses
    --       OR CONVERT(VARCHAR(10), CONNECTIONPROPERTY('client_net_address'))
    --                   NOT IN ( '10.10.10.10', '10.10.10.11', ...)
           ))
   BEGIN
       RAISERROR('Non-application connection refused.', 16, 1);
       ROLLBACK;
   END;
   

   अब का एकमात्र तरीका या तो उत्पादन मशीन पर लॉग इन करना होगा, या उनके वर्कस्टेशन को ऐप सर्वर के आईपी को खराब करना होगा। उम्मीद है कि उत्पादन पर लॉग करने के लिए देवों की कोई पहुंच नहीं है। और एक नेटवर्क पर मौजूदा आईपी को खराब करने से समस्याएं पैदा होती हैं जो उत्पादन को प्रतिकूल रूप से प्रभावित कर सकती हैं, इसलिए वे कोशिश नहीं करेंगे, है ना? सही?

Answer 5

मैंने पहले एक कंपनी के लिए काम किया था जिसमें एक डेवलपर के साथ यह समस्या थी। उसे निकाल दिया गया था, लेकिन हमने एक तालिका भी लागू की, जिसमें लॉगिन निगर के माध्यम से LoginName और AllowedMachine (एप्लिकेशन सर्वर) था। इससे हमारी समस्याओं का समाधान हुआ। या शायद यह गोलीबारी के कारण था।