.net - क्या किसी वास्तविक दुनिया के उपयोग के "कोड एक्सेस सिक्योरिटी" है?




security code-access-security (6)

आपको एक बात यह जाननी चाहिए कि कोड एक्सेस सिक्योरिटी टैपर-प्रूफिंग के लिए एक विधि के रूप में काफी टूटी हुई है। देख:

सीएएस टैपर-प्रूफिंग टूटा हुआ है: सॉफ़्टवेयर लाइसेंसिंग के परिणाम

...

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

...

चेतावनी:

इस सवाल से पूछा गया था कि नेट और नेट कोर के नए संस्करणों ने "कोड एक्सेस सिक्योरिटी" (सीएएस) को हटा दिया है और / या बदल दिया है।

मूल प्रश्न:

मैं 70-536 .NET Framework - अनुप्रयोग विकास फाउंडेशन परीक्षा के लिए अध्ययन करने की प्रक्रिया में हूं, क्योंकि मैं कई वर्षों से प्रोग्रामिंग नेट कर रहा हूं, यह कठिन नहीं होना चाहिए!

हालांकि मुझे "कोड एक्सेस सिक्योरिटी" (सीएएस) के बारे में जानना है, क्योंकि मुझे इसे कभी भी इस्तेमाल करने या कॉन्फ़िगर करने की ज़रूरत नहीं है, मैं सोच रहा था कि किसी और को इसके लिए वास्तविक जीवन उपयोग मिला है या नहीं?

कृपया सीएएस का उपयोग करने के उदाहरण प्रदान करें और यह समाधान के बजाय समाधान का हिस्सा रहा है।

(अब तक बाकी सब कुछ कार्य के साथ कुछ संबंध रहा है मुझे अपने .NET प्रोग्रामिंग के वर्षों में करना पड़ा)

संबंधित सवाल:

परिणाम अब तक।

  • जब आप तृतीय पक्ष कोड होस्ट कर रहे हों तो सीएएस उपयोगी होता है। जैसे एक वेब होस्टिंग कंपनी सर्वर का नुकसान कर अपने ग्राहक के Asp.net कोड को रोकने के लिए इसका उपयोग कर सकती है। (कार्यालय भी इसका उपयोग करता है जब .NET को वीबीए के प्रतिस्थापन के रूप में उपयोग किया जाता है)

  • माइक्रोसॉफ्ट एप्लिकेशन के बाहर अब तक इसका एकमात्र विस्तृत उदाहरण इस्तेमाल किया जा रहा है:

    एक हालिया प्रोजेक्ट में मैंने कुछ ऐसा ही किया था: उपयोगकर्ता को लाइब्रेरी अपलोड करने की अनुमति दें, और प्रदर्शन के लिए इसका परीक्षण करें ("कौन सबसे अच्छा एल्गोरिदम बनाता है")। कहने की जरूरत नहीं है, हमें वहां सीएएस की भारी जरूरत है।

  • सीएएस जेआईटीडीसी प्रमाणन प्राप्त करने के लिए उपयोगी प्रतीत होता है, जो कि रक्षा विभाग के अमेरिकी विभाग की तरह है, हालांकि मुझे नहीं पता कि सीएएस किसी वास्तविक मूल्य का है, या यदि यह सिर्फ बॉक्स टिक रहा था।

(यदि आपको सीएएस का उपयोग करने वाले होस्ट को बाईपास करने की आवश्यकता है और आपके पास मशीन पर व्यवस्थापक अधिकार हैं, तो आप केवल अपनी असेंबली को जीएसी में डाल सकते हैं।)

आगे देख रहे हैं, सीएएस .NET 4 में थोड़ा कम जटिल है

कम से कम ऐसा लगता है कि नई माइक्रोसॉफ्ट परीक्षा में "नींव" परीक्षा नहीं होगी जिसमें सीएएस शामिल है। मुझे नहीं पता कि यह इसे नए विनफॉर्म / डब्ल्यूपीएफ परीक्षा में लाएगा या नहीं।


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

http://www.coderjournal.com/2008/03/securing-mvc-controller-actions/

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

यह मदद नहीं करता है कि माइक्रोसॉफ्ट ने वास्तव में यह काम नहीं किया है कि प्रत्येक दिन आवेदन में सीएएस का उपयोग कैसे किया जाना चाहिए। तो यह वास्तव में उपयोग की कमी का कारण है। हालांकि सीएएस कई कारणों में से एक है कि .NET ऐसी सुरक्षित भाषा है और इसके प्रतिस्पर्धियों की तुलना में बहुत कम समस्याओं से पीड़ित है।


पाठक को नोट करें: नीचे दी गई दो टिप्पणियां देखें; ऐसा लगता है कि मैं गलती से सीएएस की परिभाषा को गलत तरीके से (गलत तरीके से) आरबीएस में शामिल कर रहा हूं। मैं यहां संदर्भ के लिए उत्तर छोड़ दूंगा, लेकिन भेद को ध्यान में रखूंगा।

सीएएस के लिए दो हैंवेल हैं; उस परीक्षा में जो चीज आपको सबसे ज्यादा दिखाई देगी वह कोड दूसरे कोड को कॉल करने के लिए सभी बारीकियों है, जो आंशिक विश्वास के लिए उपयोगी हो सकती है, लेकिन अधिकांश समय यह केवल दर्द होता है - और इससे भी बदतर: यदि आपके कोड पर पूरा भरोसा है ( जो सबसे अधिक / बहुत कुछ करता है) इसमें से कोई भी वास्तव में निष्पादित नहीं करता है (यह पूरी तरह से छोड़ दिया जाता है)।

सीएएस आरबीएस का उपयोगी हिस्सा मुख्य अनुमति है, जिसका उपयोग किया जाता है; बेशक, आपके यूआई को सुविधाओं तक पहुंच सत्यापित करनी चाहिए, लेकिन आप डाल सकते हैं (अपने निम्न-डाउन तर्क में):

[PrincipalPermission(SecurityAction.Demand, Role = "ADMIN")]
static void DeleteOrder(int id) { ... }

इसे पूर्ण विश्वास में भी लागू किया जाएगा; आप IPrincipal प्रिंसिपल को लागू करके अपना खुद का प्रिंसिपल (उपयोगकर्ता से बंधे) को परिभाषित कर सकते हैं ( IsInRole() )। और चूंकि अधिकांश वातावरण में प्रिंसिपल समर्थित हैं (Winforms, webforms, mvc, wcf, आदि) यह विशिष्ट सुरक्षा मॉडल को संदर्भित किए बिना व्यावसायिक परत पर सुरक्षा को दोबारा जांचने के लिए एक बहुत ही लचीला तरीका बना सकता है। ध्यान दें कि उपरोक्त जांच किसी भी पर्यावरण में काम करेगी।

आप अपने यूआई को चलाने के लिए शायद इसका इस्तेमाल भी कर सकते हैं। मेरे पास एक यूजनेट पोस्ट था जो प्रिंसिपल के आधार पर सक्षम / अक्षम Winforms नियंत्रण (प्रति नियंत्रण भूमिका निर्दिष्ट करने के लिए रनटाइम गुणों का उपयोग करके, ToolTip आदि की तरह थोड़ा) - मुझे इसे मिनट में नहीं मिल रहा है, हालांकि (संपादित करें: शायद एक )।


मुझे अक्सर "वास्तविक दुनिया" में कोड पहुंच सुरक्षा का सामना करना पड़ता है, अक्सर जब मैं इसे कम से कम उम्मीद करता हूं। और एक तरह से, सिल्वरलाइट इसका उत्कृष्ट वास्तविक विश्व अनुप्रयोग होगा, ऐसा नहीं था कि सिल्वरलाइट ने अंत में सीएएस को नियोजित नहीं करना चुना था

होस्टिंग प्रदाताओं

जिन स्थानों पर आप इसे क्रिया में देखते हैं, वहां एक सुरक्षित वातावरण की आवश्यकता होती है: एएसपी.नेट स्वयं ही, लेकिन एएसपी.नेट होस्टिंग प्रदाता अपने बहुमूल्य सिस्टम में घुसपैठ को रोकने के लिए एक संशोधित सुरक्षा मॉडल का उपयोग करते हैं। मुझे इस तथ्य के बारे में पता है कि Webhost4Life इसका उपयोग करता है (इसके बारे में उनकी साइट पर कोई जानकारी नहीं है, लेकिन मैंने उनके साथ काम किया है, वास्तव में, वास्तव में है)। आगे देखकर, अन्य एएसपी.नेट होस्टिंग प्रदाता वही करते हैं, लेकिन वे इसके बारे में बहुत स्पष्ट नहीं हैं: godaddy.com पर धागा सीएएस को बदलने की इच्छा नहीं है (और कोई स्पष्टता नहीं है कि क्या समर्थित है और क्या नहीं) या 1 और 1 पर इस संबंधित चर्चा । कुछ क्लाउड होस्टिंग साइट्स (रैकस्पेसक्लाउड) ने इसे थोड़ा और आगे बढ़ाया और "माइक्रोसॉफ्ट के साथ एक संशोधित पूर्ण ट्रस्ट स्तर के लिए काम किया" जो कुछ भी हो सकता है।

संक्षेप में: यदि आपको एएसपी.NET होस्ट मिल जाता है, तो संभवतः उन्होंने सीएएस का उपयोग उन चीजों को करने से रोकने के लिए किया है जो वे नहीं चाहते हैं कि आप ऐसा करें। वे इसे "बुनियादी" (कई प्रतिबंध) होस्टिंग और "एंटरप्राइज़" (कुछ प्रतिबंध) होस्टिंग के बीच अंतर बना सकते हैं जो सीएएस को एक और अन्य अर्थ देता है।

सीएएस के अन्य अनुप्रयोग

कुछ वास्तविक-दुनिया स्थितियों के लिए जो मैंने स्वयं का सामना किया था। एक हालिया प्रोजेक्ट में मैंने कुछ ऐसा ही किया था: उपयोगकर्ता को लाइब्रेरी अपलोड करने की अनुमति दें, और प्रदर्शन के लिए इसका परीक्षण करें ("कौन सबसे अच्छा एल्गोरिदम बनाता है")। कहने की जरूरत नहीं है, हमें वहां सीएएस की भारी जरूरत है। अन्य उदाहरण या दिलचस्प संसाधन:

किसी भी परिस्थिति के लिए जहां आप बस पूर्ण नियंत्रण में हैं, आप अपना स्वयं का ऐप और कोड बनाते हैं (या इसे बनाया है) और आपके सिस्टम के पूर्ण नियंत्रण में हैं, मुझे नहीं लगता कि आपको अक्सर सीएएस की आवश्यकता होगी। यह कुछ और है जो आप कम विश्वसनीय स्रोतों से कोड चलाने के लिए मिनट का उपयोग करेंगे (जो मूल रूप से सबकुछ है जो आपके पूर्ण नियंत्रण में नहीं है)।

सीएएस बनाम ClickOnce

डिफ़ॉल्ट सीएएस सेटिंग्स किसी नेटवर्क शेयर या अन्य गैर-स्थानीय स्रोतों से चलने वाले कोड की क्षमताओं को सीमित करती हैं। यह समझ में आता है लेकिन कड़े प्रतिबंधों ने वितरित आवेदन के लिए केंद्रीय भंडार करना मुश्किल बना दिया है। .NET 2.0 ने ClickOnce पेश किया, जिसे सुरक्षा को ऊपर उठाना था ( यहां चर्चा )।

इंस्टॉलर को सिस्टम फ़ंक्शंस में कॉल करने से रोकने के लिए क्लिकऑन स्वयं सीएएस का उपयोग करता है । इस प्रकार, मेरा मानना ​​है कि यह तर्कसंगत रूप से सबसे अच्छा ज्ञात एप्लिकेशन है जो सीएएस पर निर्भर करता है

प्वाइंट होना: आपको सीएएस को कुछ ऐसा बनाने में सक्षम होना चाहिए जो सीधे शेयर से चलाया जा सके, या आप इसे अनदेखा करते हैं और क्लिकऑन का उपयोग करते हैं।

सीएएस पर माइक्रोसॉफ्ट का सर्वेक्षण

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

एक और दुनिया में सीएएस

हालांकि, यह पोस्ट एक दिलचस्प जगह पर इंगित करता है: सीएएस ने दूसरी दुनिया में आवेदन किया: यूनिक्स / लिनक्स। वे इसे सीएएस नहीं कहते हैं, इसके बजाय यह BitFrost । वास्तविक दुनिया के अनुप्रयोग के लिए यह कैसे है: "वन लैपटॉप प्रति चाइल्ड" प्रोजेक्ट , जो पारंपरिक यूनिक्स सुरक्षा मॉडल के प्रतिस्थापन के रूप में बिटफ्रॉस्ट पर निर्भर करता है।

अद्यतन: यूनिक्स / लिनक्स में सीएएस पर बिटफ्रॉस्ट और सर्वेक्षण पर अनुभाग के रूप में अनुभाग।
अद्यतन: जोड़ा सीएएस बनाम ClickOnce खंड
अद्यतन: सीएएस का उपयोग कर संसाधनों की अतिरिक्त सूची (और इन सभी अद्यतनों के लिए माफी माँगें!)


हमने अपने अनुप्रयोगों के लिए सीएएस का उपयोग वास्तव में कठिन नहीं था, क्योंकि हम केवल अनधिकृत कोड निष्पादन को रोकने की कोशिश करेंगे। स्थानीय नेटवर्क शेयर से हमारे सॉफ़्टवेयर का उपयोग करने में समस्याएं आईं, लेकिन एक केस-पॉलिसी ने समस्या को साफ कर दिया।

  1. हमने एक मजबूत नाम का उपयोग करके हमारी सभी असेंबली सुरक्षित की।
  2. हमने अपने मजबूत नाम के साथ सभी असेंबली के लिए एक कैस-पॉलिसी बनाई और स्थानीय क्षेत्र नेटवर्क और स्थानीय रूप से कोड से शुरू करने के लिए हमारे मजबूत नाम से हस्ताक्षरित कोड की अनुमति दी।
  3. सभी सार्वजनिक वर्गों पर लिंक-डिमांड विशेषता प्राप्त करने के लिए आवश्यक स्थानीय क्षेत्र नेटवर्क (डेटा सीडी जलाने के लिए घटक) की आवश्यकता वाले स्थानीय क्षेत्र नेटवर्क से लोड की गई असेंबली।

.NET3.5 के अपडेट के बाद से हमारी समस्याएं अब मौजूद नहीं थीं, क्योंकि स्थानीय क्षेत्र नेटवर्क पर कोड अब स्थानीय कोड की तरह संभाला जाता है।


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

हालांकि, कैशिंग कोड को डेटा एक्सेस असेंबली में कुछ संवेदनशील वर्गों या विधियों तक पहुंचने की आवश्यकता हो सकती है, जो कि कुल पैकेज के उपभोक्ताओं तक पहुंच नहीं होनी चाहिए। इसलिए ये डेटा एक्सेस क्लासेस और विधियां बस public नहीं हो सकती हैं। कैशिंग असेंबली में उप-वर्गों के साथ डेटा एक्सेस असेंबली में संरक्षित विधियां कुछ मामलों के आसपास हो सकती हैं, लेकिन अक्सर यह विरासत का दुरुपयोग होता है। कस्टम अनुमति (उदाहरण के लिए DataPackagePermisson ) के लिए कॉलर्स पर रखे लिंकडेमैंड के साथ उन्हें public से छोड़ने के लिए यह और अधिक सुरुचिपूर्ण हो सकता है कि प्रशासक केवल कैशिंग असेंबली को ही प्रदान करेंगे।





code-access-security