SQL सर्वर 2017 पर CLR सख्त सुरक्षा

PERMISSION_SET =SAFE के साथ बनाई गई CLR असेंबली बाहरी सिस्टम संसाधनों तक कैसे पहुंच सकती है, अप्रबंधित कोड को कॉल कर सकती है, और sysadmin विशेषाधिकार प्राप्त कर सकती है?

यह .NET फ्रेमवर्क में किए गए सुरक्षा परिवर्तनों के कारण है, जो संस्करण 4.5 (मेरा मानना ​​है) से शुरू हो रहा है।

कोड एक्सेस सिक्योरिटी बेसिक्स के लिए MSDN दस्तावेज़ कहता है:

.NET फ्रेमवर्क कोड एक्सेस सिक्योरिटी (CAS) नामक एक ही एप्लिकेशन में चल रहे विभिन्न कोड पर विश्वास के विभिन्न स्तरों को लागू करने के लिए एक तंत्र प्रदान करता है। .NET फ्रेमवर्क में कोड एक्सेस सुरक्षा को कोड उत्पत्ति या अन्य पहचान पहलुओं के आधार पर सुरक्षा सीमाओं को लागू करने के लिए एक तंत्र के रूप में उपयोग नहीं किया जाना चाहिए। हम यह दर्शाने के लिए अपने मार्गदर्शन को अपडेट कर रहे हैं कि कोड एक्सेस सुरक्षा और सुरक्षा-पारदर्शी कोड आंशिक रूप से विश्वसनीय कोड, विशेष रूप से अज्ञात मूल के कोड के साथ सुरक्षा सीमा के रूप में समर्थित नहीं होंगे। हम वैकल्पिक सुरक्षा उपायों को लागू किए बिना अज्ञात मूल के कोड को लोड करने और निष्पादित करने के खिलाफ सलाह देते हैं।

और फिर .NET फ्रेमवर्क में सुरक्षा परिवर्तन के लिए पेज की ओर इशारा करता है जो बताता है:

.NET Framework 4.5 में सुरक्षा में सबसे महत्वपूर्ण परिवर्तन सशक्त नामकरण में है।

जो तब एन्हांस्ड स्ट्रांग नेमिंग के लिए प्रलेखन की ओर इशारा करता है जिसमें कहा गया है:

मजबूत नाम कुंजियों में एक हस्ताक्षर कुंजी और एक पहचान कुंजी होती है। असेंबली को हस्ताक्षर कुंजी के साथ हस्ताक्षरित किया जाता है और पहचान कुंजी द्वारा पहचाना जाता है। .NET Framework 4.5 से पहले, ये दोनों कुंजियां समान थीं। .NET Framework 4.5 से शुरू होकर, पहचान कुंजी पहले .NET Framework संस्करणों की तरह ही रहती है, लेकिन हस्ताक्षर कुंजी को एक मजबूत हैश एल्गोरिथम के साथ बढ़ाया जाता है। इसके अलावा, प्रति-हस्ताक्षर बनाने के लिए हस्ताक्षर कुंजी को पहचान कुंजी के साथ हस्ताक्षरित किया जाता है।

यह भी, सुरक्षित कोडिंग दिशानिर्देशों के लिए प्रलेखन में कहा गया है:

कोड एक्सेस सुरक्षा और सुरक्षा-पारदर्शी कोड आंशिक रूप से विश्वसनीय कोड के साथ सुरक्षा सीमा के रूप में समर्थित नहीं होगा। हम वैकल्पिक सुरक्षा उपायों को लागू किए बिना अज्ञात मूल के कोड को लोड करने और निष्पादित करने के खिलाफ सलाह देते हैं...

इसलिए, .NET के लिए सुरक्षा मॉडल वर्षों पहले बदल गया, लेकिन SQL सर्वर (SQL सर्वर 2017 तक) को पुराने सुरक्षा मॉडल का उपयोग जारी रखने की अनुमति दी गई है। ऐसा लगता है कि, SQL सर्वर 2017 से शुरू होकर, पुराने सुरक्षा मॉडल का समर्थन नहीं करने का निर्णय लिया गया था।

मुझे संदेह है कि पुराने सुरक्षा मॉडल को अनुमति देना था:

• SQL सर्वर (कम से कम CLR-संबंधित कार्यक्षमता / घटकों) को नए .NET Framework संस्करणों पर आधारित होने से रोकना, और

• Azure SQL डेटाबेस से समर्थित सुविधा के रूप में SQLCLR को अचानक हटाने के लिए जिम्मेदार (समर्थन 2014 के अंत में v12 के लॉन्च के साथ जोड़ा गया था, लेकिन फिर 15 अप्रैल, 2016 तक पूरी तरह से हटा दिया गया था)।

तो, हाँ, यह थोड़े बेकार है। इसका क्या अर्थ है (कम से कम फिलहाल के लिए) यह है कि किसी को पहले . की आवश्यकता है [master] में एक प्रमाणपत्र या असममित कुंजी बनाएं (जिसका उपयोग किसी भी असेंबली को लोड करने के लिए हस्ताक्षर करने के लिए किया गया है) फिर से लॉगिन बनाने के लिए और फिर UNSAFE ASSEMBLY . प्रदान करें उस लॉगिन के लिए। यह घटनाओं का वही क्रम है जो किसी को EXTERNAL_ACCESS loading लोड करते समय करने की आवश्यकता होती है और UNSAFE असेंबली, लेकिन अब, दुर्भाग्य से, SAFE . के लिए भी किए जाने की आवश्यकता है असेंबली।

वर्तमान में इसे पूरी तरह से पोर्टेबल तरीके से संभालने के लिए कोई तंत्र नहीं है (अर्थात बाहरी फाइलों पर निर्भर नहीं है) और इसे विजुअल स्टूडियो/एसएसडीटी द्वारा मैन्युअल हस्तक्षेप के बिना नियंत्रित नहीं किया जा सकता है। यह पहले से ही मामला था, लेकिन कम से कम इसे पूरी तरह से पोर्टेबल फैशन में संभालने के लिए एक सेट अप बनाना संभव था (यानी पूरी तरह से एक .sql स्क्रिप्ट में निहित):कृपया SQLCLR स्तर 7 के लिए सीढ़ी देखें:विवरण के लिए विकास और सुरक्षा (यह एक लेख है जिसे मैंने लिखा है)।

हेक्स बाइट्स से प्रमाणपत्र बनाना संभव है (यानी FROM BINARY = 0x... ) लेकिन यह विजुअल स्टूडियो (जो एमएसबिल्ड पर निर्भर करता है) / एसएसडीटी के साथ काम नहीं करता है क्योंकि प्रमाणपत्र का उपयोग करने के लिए signtool का उपयोग करना आवश्यक है और MSBuild sn . का उपयोग करता है ।

इसे व्यावहारिक बनाने के लिए जैसे कि विजुअल स्टूडियो / एमएसबिल्ड / एसएसडीटी प्रकाशन प्रक्रिया काम करती है (जिसका अर्थ यह होगा कि कोई भी पूरी तरह से आत्मनिर्भर .sql स्क्रिप्ट बनाने में सक्षम होगा जो बिना भरोसा किए असममित कुंजी बनाने में सक्षम होगा) एक बाहरी फ़ाइल), CREATE ASYMMETRIC KEY बाइनरी स्ट्रिंग से बनाए जाने की अनुमति देने के लिए कमांड को बढ़ाने की आवश्यकता है। मैंने यह सुझाव माइक्रोसॉफ्ट कनेक्ट पर दिया है - क्रिएट सर्टिफिकेट की तरह ही बाइनरी हेक्स बाइट्स स्ट्रिंग से एसिमेट्रिक की बनाने की अनुमति दें - इसलिए कृपया इसका समर्थन करें :-)।

वैकल्पिक रूप से (फिलहाल, जब तक एमएस उम्मीद से बेहतर तरीका नहीं बनाता है, जैसे कि मेरे असममित कुंजी सुझाव), आप निम्नलिखित ब्लॉग पोस्ट में वर्णित दो तकनीकों में से किसी एक को आजमा सकते हैं (दोनों पूरी तरह से एसएसडीटी के साथ काम करते हैं):

• SQLCLR बनाम SQL सर्वर 2017, भाग 2:"CLR सख्त सुरक्षा" - समाधान 1
• SQLCLR बनाम SQL सर्वर 2017, भाग 3:"CLR सख्त सुरक्षा" - समाधान 2

अंतिम . के रूप में रिसॉर्ट, आप निम्नलिखित दृष्टिकोण पर विचार कर सकते हैं:

1. अस्थायी रूप से [master] सेट करें डेटाबेस से TRUSTWORTHY ON

   अगले चरण के लिए (यानी CREATE ASSEMBLY ) सफलतापूर्वक निष्पादित करने के लिए, लॉगिन जो कि डेटाबेस का स्वामी है (अर्थात वही SID जिसका उपयोग [dbo] द्वारा किया जाता है [master] . के उपयोगकर्ता ) के पास UNSAFE ASSEMBLY . होना चाहिए अनुमति। अगर [master] sa . के स्वामित्व में है या कोई अन्य sysadmin, तो उसके पास सभी अनुमतियाँ हैं और यह आवश्यकता पूरी हो गई है। लेकिन, अगर [master] एक कम-विशेषाधिकार प्राप्त लॉगिन (एक "सर्वोत्तम अभ्यास") के स्वामित्व में है, तो आपको CREATE ASSEMBLY के लिए निम्नलिखित कथन को निष्पादित करने की आवश्यकता होगी काम करने के लिए जब TRUSTWORTHY ON है :

   EXEC (N'USE [master]; GRANT UNSAFE ASSEMBLY TO [{DB_Owner_Login}];');
   

2. असेंबली को [master] में बनाएं
3. असेंबली से असममित कुंजी बनाएं
4. विधानसभा छोड़ें
5. [master] सेट करें डेटाबेस से TRUSTWORTHY OFF
6. असममित कुंजी से लॉगिन बनाएं
7. अनुदान दें UNSAFE ASSEMBLY उस लॉगिन के लिए (यह उस डीबी की आवश्यकता को प्रतिस्थापित करता है जहां असेंबली लोड की जाती है जिसे TRUSTWORTHY ON पर सेट किया जाता है। और इसके मालिक के लिए UNSAFE ASSEMBLY . के लिए लॉग इन करें अनुमति)।

कृपया ध्यान दें कि मैंने नहीं किया यहां एक विकल्प के रूप में नई "विश्वसनीय असेंबली" सुविधा शामिल करें। इसका उल्लेख नहीं करने का कारण यह है कि इसमें लाभों की तुलना में कई अधिक खामियां हैं, यह उल्लेख नहीं करना कि यह पहली जगह में पूरी तरह से अनावश्यक है, क्योंकि मौजूदा कार्यक्षमता पहले से ही "विश्वसनीय असेंबली" की स्थिति को संबोधित करने के लिए थी। उस पर पूर्ण विवरण और मौजूदा, अहस्ताक्षरित असेंबली को संभालने के उचित तरीके के डेमो के लिए, कृपया देखें:SQLCLR बनाम SQL सर्वर 2017, भाग 4:"विश्वसनीय असेंबली" - निराशा।