डिज़ाइन द्वारा सुरक्षित
सॉफ्टवेयर इंजीनियरिंग में डिज़ाइन द्वारा सुरक्षित का अर्थ है कि सॉफ़्टवेयर उत्पादों और क्षमताओं को मूलभूत रूप से सुरक्षित होने के लिए डिज़ाइन किया गया है।
सॉफ़्टवेयर डिज़ाइन की शुरुआत में वैकल्पिक सुरक्षा रणनीतियों, रणनीति और पैटर्न पर विचार किया जाता है, और सर्वश्रेष्ठ को आर्किटेक्चर द्वारा चुना और लागू किया जाता है, और उन्हें सॉफ्टवेयर डेवलपर्स के लिए मार्गदर्शक सिद्धांतों के रूप में उपयोग किया जाता है।[1] ऐसे रणनीतिक डिज़ाइन पैटर्न का उपयोग करने के लिए भी प्रोत्साहित किया जाता है जिनका सुरक्षा पर लाभकारी प्रभाव पड़ता है, भले ही वे डिज़ाइन पैटर्न मूल रूप से सुरक्षा को ध्यान में रखकर तैयार नहीं किए गए थे।[2]
सॉफ्टवेयर सिस्टम की सुरक्षा और गोपनीयता सुनिश्चित करने के लिए सिक्योर बाई डिज़ाइन तेजी से मुख्यधारा विकास दृष्टिकोण बनता जा रहा है। इस दृष्टिकोण में, सुरक्षा पर विचार किया जाता है और हर स्तर पर सिस्टम में बनाया जाता है और एक मजबूत वास्तुकला डिजाइन के साथ शुरू होता है। सुरक्षा वास्तुशिल्प डिजाइन निर्णय विशिष्ट गुणवत्ता संबंधी चिंताओं को प्राप्त करने के लिए पुन: प्रयोज्य तकनीकों के रूप में परिभाषित प्रसिद्ध सुरक्षा रणनीतियों, रणनीति और पैटर्न पर आधारित होते हैं। सुरक्षा रणनीति/पैटर्न आवश्यक प्रमाणीकरण, लागू करने के लिए समाधान प्रदान करते हैं, प्राधिकरण, गोपनीयता, डेटा अखंडता, गोपनीयता, जवाबदेही, उपलब्धता, सुरक्षा और गैर-अस्वीकृति आवश्यकताएँ, तब भी जब सिस्टम पर हमला हो रहा हो।[3] किसी सॉफ़्टवेयर सिस्टम की सुरक्षा सुनिश्चित करने के लिए, न केवल एक मजबूत इच्छित सुरक्षा वास्तुकला को डिज़ाइन करना महत्वपूर्ण है, बल्कि सुरक्षा दृढ़ता बनाए रखने के लिए सॉफ़्टवेयर विकास के लिए अद्यतन सुरक्षा रणनीतियों, रणनीति और पैटर्न को मैप करना भी आवश्यक है।
आक्षेपों की अपेक्षा
सॉफ़्टवेयर पर दुर्भावनापूर्ण हमलों को घटित माना जाना चाहिए, और प्रभाव को कम करने का ध्यान रखा जाना चाहिए। अमान्य उपयोगकर्ता इनपुट के साथ-साथ सुरक्षा कमजोरियाँ अपेक्षित हैं।[4] भेद्यता-खोलने वाली गलतियों के जोखिम को कम करके सुरक्षा बढ़ाने के तरीके के रूप में "अच्छे" सॉफ़्टवेयर डिज़ाइन, जैसे डोमेन-संचालित डिज़ाइन या क्लाउड नेटिव, का उपयोग करने का चलन निकटता से संबंधित है - भले ही उपयोग किए गए डिज़ाइन सिद्धांतों की मूल रूप से सुरक्षा उद्देश्यों के लिए कल्पना नहीं की गई थी।
अस्पष्टता के माध्यम से सुरक्षा से बचें
आम तौर पर, जो डिज़ाइन अच्छी तरह से काम करते हैं वे गुप्त होने पर निर्भर नहीं होते हैं। अक्सर, गोपनीयता खतरे वाली आबादी के एक उपसमूह को हतोत्साहित करके हमलावरों की संख्या को कम कर देती है। तर्क यह है कि यदि हमलावर के लिए जटिलता में वृद्धि होती है, तो लक्ष्य से समझौता करने के लिए हमलावर का बढ़ा हुआ प्रयास उन्हें हतोत्साहित करेगा। हालाँकि इस तकनीक का तात्पर्य अंतर्निहित जोखिमों को कम करना है, लेकिन समय के साथ लागू किए गए खतरों के अभिनेताओं और तकनीकों का लगभग अनंत सेट अधिकांश गोपनीयता तरीकों को विफल कर देगा। हालांकि अनिवार्य नहीं है, उचित सुरक्षा का आमतौर पर मतलब यह है कि हर किसी को डिज़ाइन को जानने और समझने की अनुमति है क्योंकि यह सुरक्षित है। इसका फायदा यह है कि बहुत से लोग कंप्यूटर कोड को देख रहे हैं, जिससे यह संभावना बेहतर हो जाती है कि कोई भी खामी जल्द ही मिल जाएगी (लिनस का नियम देखें)। नुकसान यह है कि हमलावर कोड भी प्राप्त कर सकते हैं, जिससे उनके लिए शोषण के लिए कमजोरियों को ढूंढना आसान हो जाता है। हालाँकि, आमतौर पर यह माना जाता है कि खुले कंप्यूटर कोड का लाभ नुकसान से अधिक है।
न्यूनतम विशेषाधिकार
साथ ही, यह महत्वपूर्ण है कि हर चीज़ यथासंभव न्यूनतम विशेषाधिकार के साथ काम करे (न्यूनतम विशेषाधिकार का सिद्धांत देखें)। उदाहरण के लिए, एक वेब सर्वर जो प्रशासनिक उपयोगकर्ता ("रूट" या "एडमिन") के रूप में चलता है, उसके पास फ़ाइलों और उपयोगकर्ताओं को हटाने का विशेषाधिकार हो सकता है। इस तरह के प्रोग्राम में एक दोष पूरे सिस्टम को खतरे में डाल सकता है, जबकि एक वेब सर्वर जो एक अलग वातावरण के अंदर चलता है, और केवल आवश्यक नेटवर्क और फाइल सिस्टम कार्यों के लिए विशेषाधिकार रखता है, उस सिस्टम से समझौता नहीं कर सकता है जिस पर वह चल रहा है जब तक कि उसके चारों ओर की सुरक्षा भी त्रुटिपूर्ण न हो।
पद्धतियाँ
विकास जीवनचक्र (जो भी विकास पद्धति चुनी जाए) में सभी बिंदुओं पर सुरक्षित डिज़ाइन पर विचार किया जाना चाहिए।
कुछ पूर्व-निर्मित सिक्योर बाय डिज़ाइन विकास पद्धतियाँ मौजूद हैं (उदाहरण के लिए माइक्रोसॉफ्ट सुरक्षा विकास जीवनचक्र)।
माइक्रोसॉफ्ट सुरक्षा विकास जीवनचक्र
माइक्रोसॉफ्ट ने शास्त्रीय सर्पिल मॉडल के आधार पर कार्यप्रणाली और मार्गदर्शन जारी किया है।
मानक और विधान
मानक और विधान "सुरक्षित" की परिभाषा को नियंत्रित करके सुरक्षित डिजाइन में सहायता के लिए मौजूद हैं, और सुरक्षित प्रणालियों के परीक्षण और एकीकरण के लिए ठोस कदम प्रदान करते हैं।
मानकों के कुछ उदाहरण जो सिक्योर बाय डिज़ाइन सिद्धांतों को कवर या स्पर्श करते हैं:
- ETSI TS 103 645 [5] जो UK सरकार के "उपभोक्ता स्मार्ट उत्पाद साइबर सुरक्षा को विनियमित करने के प्रस्तावों" में आंशिक रूप से शामिल है [6]
- ISO/IEC 27000-श्रृंखला सुरक्षित डिज़ाइन के कई पहलुओं को शामिल करती है।
सर्वर/क्लाइंट आर्किटेक्चर
सर्वर/क्लाइंट आर्किटेक्चर में, दूसरी तरफ का प्रोग्राम अधिकृत क्लाइंट नहीं हो सकता है और क्लाइंट का सर्वर अधिकृत सर्वर नहीं हो सकता है। यहां तक कि जब वे होते हैं, तब भी बीच-बीच में किया गया हमला संचार से समझौता कर सकता है।
अक्सर क्लाइंट/सर्वर सिस्टम की सुरक्षा को तोड़ने का सबसे आसान तरीका सुरक्षा तंत्र के पास जाना नहीं है, बल्कि उनके आसपास जाना है। बीच में एक आदमी पर हमला इसका एक सरल उदाहरण है, क्योंकि आप इसका उपयोग किसी उपयोगकर्ता का प्रतिरूपण करने के लिए विवरण एकत्र करने के लिए कर सकते हैं। यही कारण है कि आपके डिज़ाइन में कूटलेखन , क्रिप्टोग्राफ़िक हैश फ़ंक्शन और अन्य सुरक्षा तंत्रों पर विचार करना महत्वपूर्ण है ताकि यह सुनिश्चित किया जा सके कि संभावित हमलावर से एकत्र की गई जानकारी पहुंच की अनुमति नहीं देगी।
क्लाइंट-सर्वर सुरक्षा डिज़ाइन की एक अन्य प्रमुख विशेषता सर्वोत्तम कोडिंग प्रथाएँ हैं। उदाहरण के लिए, क्लाइंट और ब्रोकर जैसी ज्ञात सॉफ़्टवेयर डिज़ाइन संरचना का अनुसरण करने से ठोस आधार के साथ एक अच्छी तरह से निर्मित संरचना को डिज़ाइन करने में मदद मिल सकती है। इसके अलावा, यदि सॉफ़्टवेयर को भविष्य में संशोधित किया जाना है, तो यह और भी महत्वपूर्ण है कि यह क्लाइंट और सर्वर के बीच अलगाव की तार्किक नींव का पालन करे। ऐसा इसलिए है क्योंकि यदि कोई प्रोग्रामर आता है और प्रोग्राम की गतिशीलता को स्पष्ट रूप से नहीं समझ पाता है, तो वे कुछ ऐसा जोड़ या बदल सकते हैं जो सुरक्षा दोष जोड़ सकता है। सर्वोत्तम डिज़ाइन के साथ भी, यह हमेशा एक संभावना है, लेकिन डिज़ाइन का मानकीकरण जितना बेहतर होगा, ऐसा होने की संभावना उतनी ही कम होगी।
यह भी देखें
- कंप्यूटर सुरक्षा
- साइबर सुरक्षा मानक
- हार्डनिंग (कंप्यूटिंग)
- सुरक्षा के अनेक स्वतंत्र स्तर
- डिफ़ॉल्ट रूप से सुरक्षित
- अस्पष्टता के माध्यम से सुरक्षा
- सॉफ्टवेयर सुरक्षा आश्वासन
संदर्भ
- ↑ 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.
- ↑ Dan Bergh Johnsson; Daniel Deogun; Daniel Sawano (2019). डिज़ाइन द्वारा सुरक्षित. Manning Publications. ISBN 9781617294358.
- ↑ 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.
- ↑ 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) - ↑ "ETSI TS 103 645" (PDF).
- ↑ "Policy paper: Proposals for regulating consumer smart product cyber security - call for views".
बाहरी संबंध
- Secure Programming for Linux and Unix HOWTO
- Secure UNIX Programming FAQ
- Top 10 Secure Coding Practices
- Security by Design Principles
Note: This template roughly follows the 2012 ACM Computing Classification System. | ||
| हार्डवेयर |  | |
| कंप्यूटर सिस्टम संगठन | ||
| नेटवर्क | ||
| सॉफ्टवेयर संगठन | ||
| सॉफ्टवेयर नोटेशन और टूल्स | ||
| सॉफ्टवेयर डेवलपमेंट | ||
| गणना का सिद्धांत | ||
| कलन विधि | ||
| कंप्यूटिंग का गणित | ||
| सूचना प्रणाली | ||
| सुरक्षा | ||
| मानव-कंप्यूटर संपर्क | ||
| Concurrency | ||
| कृत्रिम बुद्धि | ||
| मशीन लर्निंग | ||
| ग्राफिक्स | ||
| एप्लाइड कंप्यूटिंग |
| |
