डिज़ाइन द्वारा सुरक्षित: Difference between revisions

From Vigyanwiki
No edit summary
 
Line 63: Line 63:


{{Computer science}}
{{Computer science}}
[[Category: सॉफ्टवेयर गुणवत्ता]] [[Category: उदाहरण सी कोड वाले लेख]] [[Category: सॉफ्टवेयर विकास दर्शन]] [[Category: सॉफ्टवेयर विकास प्रक्रिया]] [[Category: कंप्यूटर सुरक्षा प्रक्रियाएँ]]


 
[[Category:Articles with hatnote templates targeting a nonexistent page]]
 
[[Category:CS1 errors]]
[[Category: Machine Translated Page]]
[[Category:Collapse templates]]
[[Category:Created On 09/07/2023]]
[[Category:Created On 09/07/2023]]
[[Category:Vigyan Ready]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Navigational boxes| ]]
[[Category:Navigational boxes without horizontal lists]]
[[Category:Pages with script errors]]
[[Category:Sidebars with styles needing conversion]]
[[Category:Template documentation pages|Documentation/doc]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates generating microformats]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that are not mobile friendly]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:Wikipedia metatemplates]]
[[Category:उदाहरण सी कोड वाले लेख]]
[[Category:कंप्यूटर सुरक्षा प्रक्रियाएँ]]
[[Category:सॉफ्टवेयर गुणवत्ता]]
[[Category:सॉफ्टवेयर विकास दर्शन]]
[[Category:सॉफ्टवेयर विकास प्रक्रिया]]

Latest revision as of 11:07, 2 August 2023

सॉफ्टवेयर इंजीनियरिंग में डिज़ाइन द्वारा सुरक्षित का अर्थ है कि सॉफ़्टवेयर उत्पादों और क्षमताओं को मूलभूत रूप से सिक्योर होने के लिए डिज़ाइन किया गया है।

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

सॉफ्टवेयर सिस्टम की सुरक्षा और गोपनीयता सुनिश्चित करने के लिए सिक्योर बाई डिज़ाइन तेजी से मुख्य धारा विकास दृष्टिकोण बनता जा रहा है। इस दृष्टिकोण में, सुरक्षा पर विचार किया जाता है और हर स्तर पर सिस्टम में बनाया जाता है और एक मजबूत आर्किटेक्चर डिजाइन के साथ शुरू होता है। सुरक्षा आर्किटेक्चर डिजाइन निर्णय विशिष्ट गुणवत्ता संबंधी चिंताओं को प्राप्त करने के लिए पुन: प्रयोज्य तकनीकों के रूप में परिभाषित प्रसिद्ध सुरक्षा रणनीतियों, और पैटर्न पर आधारित होते हैं। सिक्योरिटी पैटर्न आवश्यक प्रमाणीकरण, लागू करने के लिए समाधान प्रदान करते हैं, अथॉरिटी, कॉन्फिडेंटिएलिटी, डेटा इंटीग्रिटी, एकाउंटेबिलिटी, अवेलेबिलिटी, सिक्योरिटी और गैर-अस्वीकृति आवश्यकताएँ, तब भी जब सिस्टम पर अटैक हो रहा हो।[3] किसी सॉफ़्टवेयर सिस्टम की सिक्योरिटी सुनिश्चित करने के लिए, न केवल एक मजबूत इच्छित सुरक्षा आर्किटेक्चर को डिज़ाइन करना महत्वपूर्ण है, बल्कि सुरक्षा दृढ़ता बनाए रखने के लिए सॉफ़्टवेयर विकास के लिए अद्यतन सुरक्षा रणनीतियों, और पैटर्न को मैप करना भी आवश्यक है।

हमलों की अपेक्षा

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

अस्पष्टता के माध्यम से सुरक्षा से बचें

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

न्यूनतम विशेषाधिकार

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

पद्धतियाँ

विकास जीवनचक्र में सभी बिंदुओं पर सुरक्षित डिज़ाइन पर विचार किया जाना चाहिए।

कुछ पूर्व-निर्मित सिक्योर बाय डिज़ाइन विकास पद्धतियाँ मौजूद हैं।

माइक्रोसॉफ्ट सुरक्षा विकास जीवनचक्र

माइक्रोसॉफ्ट ने शास्त्रीय सर्पिल मॉडल के आधार पर कार्यप्रणाली और मार्गदर्शन जारी किया है।

मानक और विधान

मानक और विधान "सुरक्षित" की परिभाषा को नियंत्रित करके सुरक्षित डिजाइन में सहायता के लिए मौजूद हैं, और सुरक्षित प्रणालियों के परीक्षण और एकीकरण के लिए ठोस कदम प्रदान करते हैं।

मानकों के कुछ उदाहरण जो सिक्योर बाय डिज़ाइन सिद्धांतों को कवर या स्पर्श करते हैं:

  • ETSI TS 103 645 [5] जो UK सरकार के "उपभोक्ता स्मार्ट उत्पाद साइबर सुरक्षा को विनियमित करने के प्रस्तावों" में आंशिक रूप से शामिल है [6]
  • ISO/IEC 27000-श्रृंखला सुरक्षित डिज़ाइन के कई पहलुओं को शामिल करती है।

सर्वर/क्लाइंट आर्किटेक्चर

सर्वर/क्लाइंट आर्किटेक्चर में, दूसरी तरफ का प्रोग्राम अधिकृत क्लाइंट नहीं हो सकता है और क्लाइंट में सर्वर अधिकृत नहीं हो सकता है। यहां तक ​​​​कि जब भी क्लाइंट होते हैं, तब भी बीच-बीच में किया गया अटैक संचार से समझौता कर सकता है।

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

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

यह भी देखें

संदर्भ

  1. Santos, Joanna C. S.; Tarrit, Katy; Mirakhorli, Mehdi (2017). "सुरक्षा वास्तुकला की कमजोरियों की एक सूची". 2017 IEEE International Conference on Software Architecture (ICSA): 220–223. doi:10.1109/ICSAW.2017.25. ISBN 978-1-5090-4793-2. S2CID 19534342.
  2. Dan Bergh Johnsson; Daniel Deogun; Daniel Sawano (2019). डिज़ाइन द्वारा सुरक्षित. Manning Publications. ISBN 9781617294358.
  3. Hafiz, Munawar; Adamczyk, Paul; Johnson, Ralph E. (October 2012). "एक पैटर्न भाषा विकसित करना (सुरक्षा के लिए)". Onward! 2012: Proceedings of the ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software: 139–158. doi:10.1145/2384592.2384607. ISBN 9781450315623. S2CID 17206801.
  4. Dougherty, Chad; Sayre, Kirk; Seacord, Robert C.; Svoboda, David; Togashi, Kazuya (October 2009). "सुरक्षित डिज़ाइन पैटर्न". doi:10.1184/R1/6583640.v1. {{cite journal}}: Cite journal requires |journal= (help)
  5. "ETSI TS 103 645" (PDF).
  6. "Policy paper: Proposals for regulating consumer smart product cyber security - call for views".


बाहरी संबंध