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

From Vigyanwiki
No edit summary
No edit summary
 
(16 intermediate revisions by 3 users not shown)
Line 2: Line 2:
{{Information security}}
{{Information security}}


[[सॉफ्टवेयर इंजीनियरिंग]] में '''डिज़ाइन द्वारा सुरक्षित''' का अर्थ है कि [[सॉफ़्टवेयर]] उत्पादों और क्षमताओं को मूलभूत रूप से [[सुरक्षित]] होने के लिए डिज़ाइन किया गया है।
[[Index.php?title=Index.php?title=सॉफ्टवेयर इंजीनियरिंग|सॉफ्टवेयर इंजीनियरिंग]] में '''डिज़ाइन द्वारा सुरक्षित''' का अर्थ है कि [[सॉफ़्टवेयर]] उत्पादों और क्षमताओं को मूलभूत रूप से [[Index.php?title=सिक्योर|सिक्योर]] होने के लिए डिज़ाइन किया गया है।


सॉफ़्टवेयर डिज़ाइन की शुरुआत में वैकल्पिक सुरक्षा रणनीतियों, रणनीति और पैटर्न पर विचार किया जाता है, और सर्वश्रेष्ठ को आर्किटेक्चर द्वारा चुना और लागू किया जाता है, और उन्हें [[सॉफ्टवेयर डेवलपर्स]] के लिए मार्गदर्शक सिद्धांतों के रूप में उपयोग किया जाता है।<ref>{{cite journal |title=सुरक्षा वास्तुकला की कमजोरियों की एक सूची|journal=2017 IEEE International Conference on Software Architecture (ICSA) |year=2017 |doi=10.1109/ICSAW.2017.25|last1=Santos |first1=Joanna C. S. |last2=Tarrit |first2=Katy |last3=Mirakhorli |first3=Mehdi |pages=220–223 |isbn=978-1-5090-4793-2 |s2cid=19534342 }}</ref> ऐसे रणनीतिक डिज़ाइन पैटर्न का उपयोग करने के लिए भी प्रोत्साहित किया जाता है जिनका सुरक्षा पर लाभकारी प्रभाव पड़ता है, भले ही वे डिज़ाइन पैटर्न मूल रूप से सुरक्षा को ध्यान में रखकर तैयार नहीं किए गए थे।<ref>{{cite book |title=डिज़ाइन द्वारा सुरक्षित|publisher=Manning Publications| author1=Dan Bergh Johnsson|author2 = Daniel Deogun|author3=Daniel Sawano |date=2019 |isbn=9781617294358}}</ref>
सॉफ़्टवेयर डिज़ाइन की शुरुआत में वैकल्पिक सुरक्षा रणनीतियों, और पैटर्न पर विचार किया जाता है, और सर्वश्रेष्ठ को आर्किटेक्चर द्वारा चुना और अनुकूल किया जाता है, और उन्हें [[सॉफ्टवेयर डेवलपर्स]] के लिए मार्गदर्शक सिद्धांतों के रूप में उपयोग किया जाता है।<ref>{{cite journal |title=सुरक्षा वास्तुकला की कमजोरियों की एक सूची|journal=2017 IEEE International Conference on Software Architecture (ICSA) |year=2017 |doi=10.1109/ICSAW.2017.25|last1=Santos |first1=Joanna C. S. |last2=Tarrit |first2=Katy |last3=Mirakhorli |first3=Mehdi |pages=220–223 |isbn=978-1-5090-4793-2 |s2cid=19534342 }}</ref> और ऐसे रणनीतिक डिज़ाइन पैटर्न का उपयोग करने के लिए भी प्रोत्साहित किया जाता है जिनका सुरक्षा पर लाभकारी प्रभाव पड़ता है, भले ही वे डिज़ाइन पैटर्न मूल रूप से सुरक्षा को ध्यान में रखकर तैयार नहीं किए गए थे।<ref>{{cite book |title=डिज़ाइन द्वारा सुरक्षित|publisher=Manning Publications| author1=Dan Bergh Johnsson|author2 = Daniel Deogun|author3=Daniel Sawano |date=2019 |isbn=9781617294358}}</ref>


सॉफ्टवेयर सिस्टम की सुरक्षा और [[गोपनीयता]] सुनिश्चित करने के लिए सिक्योर बाई डिज़ाइन तेजी से मुख्यधारा विकास दृष्टिकोण बनता जा रहा है। इस दृष्टिकोण में, सुरक्षा पर विचार किया जाता है और हर स्तर पर सिस्टम में बनाया जाता है और एक मजबूत वास्तुकला डिजाइन के साथ शुरू होता है। सुरक्षा वास्तुशिल्प डिजाइन निर्णय विशिष्ट गुणवत्ता संबंधी चिंताओं को प्राप्त करने के लिए पुन: प्रयोज्य तकनीकों के रूप में परिभाषित प्रसिद्ध सुरक्षा रणनीतियों, रणनीति और पैटर्न पर आधारित होते हैं। सुरक्षा रणनीति/पैटर्न आवश्यक [[प्रमाणीकरण]], लागू करने के लिए समाधान प्रदान करते हैं, प्राधिकरण, गोपनीयता, डेटा अखंडता, गोपनीयता, जवाबदेही, उपलब्धता, सुरक्षा और गैर-अस्वीकृति आवश्यकताएँ, तब भी जब सिस्टम पर हमला हो रहा हो।<ref>{{cite journal |title=एक पैटर्न भाषा विकसित करना (सुरक्षा के लिए)|journal=Onward! 2012: Proceedings of the ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software |doi=10.1145/2384592.2384607 |pages=139–158 |date=October 2012|last1=Hafiz |first1=Munawar |last2=Adamczyk |first2=Paul |last3=Johnson |first3=Ralph E. |isbn=9781450315623 |s2cid=17206801 }}</ref> किसी सॉफ़्टवेयर सिस्टम की सुरक्षा सुनिश्चित करने के लिए, न केवल एक मजबूत इच्छित सुरक्षा वास्तुकला को डिज़ाइन करना महत्वपूर्ण है, बल्कि सुरक्षा दृढ़ता बनाए रखने के लिए सॉफ़्टवेयर विकास के लिए अद्यतन सुरक्षा रणनीतियों, रणनीति और पैटर्न को मैप करना भी आवश्यक है।
सॉफ्टवेयर सिस्टम की सुरक्षा और [[गोपनीयता]] सुनिश्चित करने के लिए सिक्योर बाई डिज़ाइन तेजी से मुख्य धारा विकास दृष्टिकोण बनता जा रहा है। इस दृष्टिकोण में, सुरक्षा पर विचार किया जाता है और हर स्तर पर सिस्टम में बनाया जाता है और एक मजबूत आर्किटेक्चर डिजाइन के साथ शुरू होता है। सुरक्षा आर्किटेक्चर डिजाइन निर्णय विशिष्ट गुणवत्ता संबंधी चिंताओं को प्राप्त करने के लिए पुन: प्रयोज्य तकनीकों के रूप में परिभाषित प्रसिद्ध सुरक्षा रणनीतियों, और पैटर्न पर आधारित होते हैं। सिक्योरिटी पैटर्न आवश्यक [[प्रमाणीकरण]], लागू करने के लिए समाधान प्रदान करते हैं, अथॉरिटी, कॉन्फिडेंटिएलिटी, डेटा इंटीग्रिटी, एकाउंटेबिलिटी, अवेलेबिलिटी, सिक्योरिटी और गैर-अस्वीकृति आवश्यकताएँ, तब भी जब सिस्टम पर अटैक हो रहा हो।<ref>{{cite journal |title=एक पैटर्न भाषा विकसित करना (सुरक्षा के लिए)|journal=Onward! 2012: Proceedings of the ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software |doi=10.1145/2384592.2384607 |pages=139–158 |date=October 2012|last1=Hafiz |first1=Munawar |last2=Adamczyk |first2=Paul |last3=Johnson |first3=Ralph E. |isbn=9781450315623 |s2cid=17206801 }}</ref> किसी सॉफ़्टवेयर सिस्टम की सिक्योरिटी सुनिश्चित करने के लिए, न केवल एक मजबूत इच्छित सुरक्षा आर्किटेक्चर को डिज़ाइन करना महत्वपूर्ण है, बल्कि सुरक्षा दृढ़ता बनाए रखने के लिए सॉफ़्टवेयर विकास के लिए अद्यतन सुरक्षा रणनीतियों, और पैटर्न को मैप करना भी आवश्यक है।


==हमलों की अपेक्षा==
==हमलों की अपेक्षा==
सॉफ़्टवेयर पर दुर्भावनापूर्ण हमलों को घटित माना जाना चाहिए, और प्रभाव को कम करने का ध्यान रखा जाना चाहिए। अमान्य [[उपयोगकर्ता (कंप्यूटिंग)]] इनपुट के साथ-साथ सुरक्षा कमजोरियाँ अपेक्षित हैं।<ref>{{cite journal|last1=Dougherty|first1=Chad|last2=Sayre|first2=Kirk|last3=Seacord|first3=Robert C.|last4=Svoboda|first4=David|last5=Togashi|first5=Kazuya|title=सुरक्षित डिज़ाइन पैटर्न|doi=10.1184/R1/6583640.v1|date=October 2009}}</ref> भेद्यता-खोलने वाली गलतियों के जोखिम को कम करके सुरक्षा बढ़ाने के तरीके के रूप में अच्छे सॉफ़्टवेयर डिज़ाइन, जैसे [[डोमेन-संचालित डिज़ाइन]] या [[ बादल मूल निवासी ]], का उपयोग करने का चलन निकटता से संबंधित है - भले ही उपयोग किए गए डिज़ाइन सिद्धांतों की मूल रूप से सुरक्षा उद्देश्यों के लिए कल्पना नहीं की गई थी।
सॉफ़्टवेयर पर दुर्भावनापूर्ण अटैकों को निर्मित माना जाना चाहिए, और प्रभाव को कम करने का ध्यान रखा जाना चाहिए। अमान्य [[Index.php?title=उपयोगकर्ता|उपयोगकर्ता]] इनपुट के साथ-साथ सुरक्षा निर्बलता अपेक्षित हैं।<ref>{{cite journal|last1=Dougherty|first1=Chad|last2=Sayre|first2=Kirk|last3=Seacord|first3=Robert C.|last4=Svoboda|first4=David|last5=Togashi|first5=Kazuya|title=सुरक्षित डिज़ाइन पैटर्न|doi=10.1184/R1/6583640.v1|date=October 2009}}</ref> भेद्यता-खोलने वाली गलतियों के जोखिम को कम करके सुरक्षा बढ़ाने के तरीके के रूप में "अच्छे" सॉफ़्टवेयर डिज़ाइन, जैसे [[डोमेन-संचालित डिज़ाइन]] या [[Index.php?title=क्लाउड नेटिव|क्लाउड नेटिव]], का उपयोग करने का चलन निकटता से संबंधित है - भले ही उपयोग किए गए डिज़ाइन सिद्धांतों की मूल रूप से सुरक्षा उद्देश्यों के लिए कल्पना नहीं की गई थी।


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


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


== पद्धतियाँ ==
== पद्धतियाँ ==
विकास जीवनचक्र (जो भी सॉफ़्टवेयर विकास प्रक्रिया चुनी जाए) में सभी बिंदुओं पर सुरक्षित डिज़ाइन पर विचार किया जाना चाहिए।
विकास जीवनचक्र में सभी बिंदुओं पर सुरक्षित डिज़ाइन पर विचार किया जाना चाहिए।


कुछ पूर्व-निर्मित सिक्योर बाय डिज़ाइन विकास पद्धतियाँ मौजूद हैं (उदाहरण के लिए Microsoft सुरक्षा विकास जीवनचक्र)।
कुछ पूर्व-निर्मित सिक्योर बाय डिज़ाइन विकास पद्धतियाँ मौजूद हैं।


=== माइक्रोसॉफ्ट सुरक्षा विकास जीवनचक्र ===
=== माइक्रोसॉफ्ट सुरक्षा विकास जीवनचक्र ===
{{Main|Microsoft Security Development Lifecycle}}
{{Main|
[[माइक्रोसॉफ्ट]] ने शास्त्रीय [[सर्पिल मॉडल]] के आधार पर कार्यप्रणाली और मार्गदर्शन जारी किया।
माइक्रोसॉफ्ट सुरक्षा विकास जीवनचक्र}}
[[माइक्रोसॉफ्ट]] ने शास्त्रीय [[सर्पिल मॉडल]] के आधार पर कार्यप्रणाली और मार्गदर्शन जारी किया है।


== मानक और विधान ==
== मानक और विधान ==
{{Main | Application security#Security standards and regulations}}
{{Main |अनुप्रयोग सुरक्षा#सुरक्षा मानक और विनियम}}
मानक और विधान सिक्योर की परिभाषा को नियंत्रित करके सुरक्षित डिजाइन में सहायता के लिए मौजूद हैं, और सुरक्षित प्रणालियों के परीक्षण और एकीकरण के लिए ठोस कदम प्रदान करते हैं।
 
मानक और विधान "सुरक्षित" की परिभाषा को नियंत्रित करके सुरक्षित डिजाइन में सहायता के लिए मौजूद हैं, और सुरक्षित प्रणालियों के परीक्षण और एकीकरण के लिए ठोस कदम प्रदान करते हैं।


मानकों के कुछ उदाहरण जो सिक्योर बाय डिज़ाइन सिद्धांतों को कवर या स्पर्श करते हैं:
मानकों के कुछ उदाहरण जो सिक्योर बाय डिज़ाइन सिद्धांतों को कवर या स्पर्श करते हैं:
* ईटीएसआई टीएस 103 645 <ref>{{cite web|title=ETSI TS 103 645|url=https://www.etsi.org/deliver/etsi_ts/103600_103699/103645/01.01.01_60/ts_103645v010101p.pdf}}</ref> जो उपभोक्ता स्मार्ट उत्पाद साइबर सुरक्षा को विनियमित करने के लिए यूके सरकार के प्रस्तावों में आंशिक रूप से शामिल है <ref>{{cite web |title=Policy paper: Proposals for regulating consumer smart product cyber security - call for views|url=https://www.gov.uk/government/publications/proposals-for-regulating-consumer-smart-product-cyber-security-call-for-views/proposals-for-regulating-consumer-smart-product-cyber-security-call-for-views}}</ref>
* ETSI TS 103 645 <ref>{{cite web|title=ETSI TS 103 645|url=https://www.etsi.org/deliver/etsi_ts/103600_103699/103645/01.01.01_60/ts_103645v010101p.pdf}}</ref> जो UK  सरकार के "उपभोक्ता स्मार्ट उत्पाद साइबर सुरक्षा को विनियमित करने के प्रस्तावों" में आंशिक रूप से शामिल है <ref>{{cite web |title=Policy paper: Proposals for regulating consumer smart product cyber security - call for views|url=https://www.gov.uk/government/publications/proposals-for-regulating-consumer-smart-product-cyber-security-call-for-views/proposals-for-regulating-consumer-smart-product-cyber-security-call-for-views}}</ref>
* ISO/IEC 27000-श्रृंखला सुरक्षित डिज़ाइन के कई पहलुओं को शामिल करती है।
* ISO/IEC 27000-श्रृंखला सुरक्षित डिज़ाइन के कई पहलुओं को शामिल करती है।


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


अक्सर क्लाइंट/सर्वर सिस्टम की सुरक्षा को तोड़ने का सबसे आसान तरीका सुरक्षा तंत्र के पास जाना नहीं है, बल्कि उनके आसपास जाना है। बीच में एक आदमी पर हमला इसका एक सरल उदाहरण है, क्योंकि आप इसका उपयोग किसी उपयोगकर्ता का प्रतिरूपण करने के लिए विवरण एकत्र करने के लिए कर सकते हैं। यही कारण है कि आपके डिज़ाइन में [[ कूटलेखन ]], [[क्रिप्टोग्राफ़िक हैश फ़ंक्शन]] और अन्य सुरक्षा तंत्रों पर विचार करना महत्वपूर्ण है ताकि यह सुनिश्चित किया जा सके कि संभावित हमलावर से एकत्र की गई जानकारी पहुंच की अनुमति नहीं देगी।
अक्सर क्लाइंट/सर्वर सिस्टम की सुरक्षा को तोड़ने का सबसे आसान तरीका सुरक्षा तंत्र के पास जाना नहीं है, बल्कि उनके आसपास जाना है। क्योंकि इसका उपयोग किसी उपयोगकर्ता का प्रतिरूपण करने के लिए विवरण एकत्र करने के लिए कर सकते हैं। यही कारण है कि आपके डिज़ाइन में [[Index.php?title=एन्क्रिप्शन|एन्क्रिप्शन]], [[Index.php?title=हैशिंग|हैशिंग]] और अन्य सुरक्षा तंत्रों पर विचार करना महत्वपूर्ण है ताकि यह सुनिश्चित किया जा सके कि संभावित अटैकरों से एकत्र की गई जानकारी प्रवेश की अनुमति नहीं देगी।


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


==यह भी देखें==
==यह भी देखें==
Line 61: Line 63:


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


[[Category: Machine Translated Page]]
[[Category:Articles with hatnote templates targeting a nonexistent page]]
[[Category:CS1 errors]]
[[Category:Collapse templates]]
[[Category:Created On 09/07/2023]]
[[Category:Created On 09/07/2023]]
[[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

श्रृंखला का हिस्सा
सूचना सुरक्षा
vectorial version
सुरक्षा संबंधित श्रेणियां
थ्रेट्स
डिफेंसेस

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

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

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

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

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

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

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

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

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

पद्धतियाँ

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

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

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

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

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

मानक और विधान

Main article: अनुप्रयोग सुरक्षा § सुरक्षा मानक और विनियम

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

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

  • 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".


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=डिज़ाइन_द्वारा_सुरक्षित&oldid=233105’