2010-12-13 14 views
6

सुरक्षित करने के लिए कैसे करें जिन परियोजनाओं पर आप काम कर रहे हैं, उनके लिए डीएलएल को सुरक्षित करने के लिए सबसे अच्छा अभ्यास क्या है? कुछ डीएलएल के विकास में दिलचस्पी रखने के लिए डेटा एक्सेस लेयर (डीएएल) और बिजनेस लॉजिक लेयर (बीएलएल) कार्यक्षमता होगी। ऐसे कई ऐप्स हो सकते हैं जो अंततः व्यापार विशिष्ट कार्यों को करने के लिए इन डीएलएल को हिट कर सकते हैं।.NET DLL के

इन डीएलएल को सुरक्षित करने का सबसे अच्छा तरीका क्या है ताकि उन्हें केवल निर्माता के अनुप्रयोगों द्वारा ही उपयोग किया जा सके?

डीएलएल के अनधिकृत उपयोग को अवरुद्ध करने और संभावित विघटन के खिलाफ सुरक्षा दोनों के लिए सुरक्षा दोनों वांछनीय हैं।

+2

क्या आपका मतलब है कि उन्हें डिकंपलिंग के खिलाफ सुरक्षित रखें या उन्हें आसानी से उपयोग के विरुद्ध सुरक्षित करें? – NotMe

+0

अभी के लिए मैं उपयोग की तलाश में हूं, लेकिन वास्तव में दोनों की तलाश में हूं। तदनुसार सवाल अपडेट किया गया। – Matt

उत्तर

4

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

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

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

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

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

+0

वास्तव में नहीं। .NET आपको exe-file असेंबली को भी संदर्भित करने की अनुमति देता है, इसलिए इससे बहुत कम या कोई फर्क नहीं पड़ता है। –

+0

लाल गेट से परावर्तक जैसे टूल के साथ। यहां तक ​​कि एक निष्पादन योग्य में लगभग कुछ भी सापेक्ष आसानी से अव्यवस्थित लगता है। तो क्या यह एक exe में शामिल है वास्तविकता में किसी भी मदद प्रदान करते हैं? – Matt

+0

मैं ब्रायन के बिंदु प्रति "कोड को डीएलएल में खींचें" सुझाव वापस लेता हूं। बाकी खड़े हैं: कोई पूर्ण लॉक-आउट नहीं है, इसलिए आपको यह तय करना होगा कि परिणाम को अधिक असुविधाजनक बनाने के लिए आप कितना निवेश करना चाहते हैं। – dthorpe

1

ओपन कुंजी तंत्र का उपयोग करके प्रमाणीकरण स्थापित करें। डीएलएल में कार्य केवल तभी काम करेंगे जब आप वैध कुंजी और टोकन की आपूर्ति करते हैं।

+0

क्या आप कुछ प्रकार के उदाहरणों को स्पष्ट या लिंक प्रदान कर सकते हैं? – Matt

1

अगर किसी के पास उन सभी असेंबली के साथ मशीन तक पहुंच है, तो आपको किसी को पुन: उपयोग करने के बारे में चिंतित होना चाहिए, वे सीधे आपकी असेंबली का उपयोग करने के बजाय डेटाबेस पर जा सकते हैं।

यदि यह डेस्कटॉप एप्लिकेशन या कुछ है और आप सीधे डेटाबेस तक पहुंच रहे हैं तो आपको अपने एप्लिकेशन को फिर से सोचने, वेब सेवाओं या डेटा को सीधे डेटाबेस पर जाने के बजाय डेटा तक पहुंचने की आवश्यकता है।

+0

परिदृश्य एक प्रतिकृति वातावरण में मौजूद है। किसी भी समय मशीनों को इंटरनेट कनेक्टिविटी हो सकती है या नहीं, वेब सेवाओं को एक विकल्प नहीं बना सकता है। – Matt

+0

Sooooo ... मुझे नहीं लगता कि आपका बिंदु क्या है। सीधे डेटाबेस से बात करना बुरा है, और आपके पास अभी भी सीधे बात करने का कोई कारण नहीं है। – Phill

+0

ठीक है मेरे पास अलग परियोजनाओं में एक डीएएल और बीएलएल है और फिर डीएलएल में संकलित किया गया है। ये पुस्तकालय हमारे तर्क और डीबी संचालन को नियंत्रित करते हैं। मुख्य ऐप एक WPF ऐप है जिसमें केवल प्रस्तुति परत होती है। अन्य उप-अनुप्रयोग भी हैं जो कुछ डीएएल और बीएलएल संचालन के खिलाफ भी प्रभावित होंगे। यह आवश्यक विभिन्न ऐप्स से डुप्लिकेट कोडिंग से बचने के लिए किया जाता है। डीएएल का पूरा उद्देश्य डीबी से बात करना है। – Matt

1

अपनी बौद्धिक संपदा की रक्षा करना वास्तव में संभव नहीं है यदि आप इसे फॉर्म में भेजते हैं .NET DLL क्लाइंट के लिए। आप क्लाउड में अपने एप्लिकेशन लॉजिक को होस्ट कर सकते हैं, हालांकि यह आपके परिदृश्य के अनुरूप नहीं हो सकता है।

यहां तक ​​कि "सर्वश्रेष्ठ" obfuscators भी अचूक नहीं हैं।आप शायद एक आरामदायक हैकर बंद कर सकते हैं, लेकिन जैसा कि dthorpe कहते हैं, अगर कोई वास्तव में आपकी असेंबली को अपनाना चाहता है, तो वे करेंगे।

संबंधित मुद्दे