वयस्कों के लिए गुणन तालिका को समझाने के लिए सुरक्षा किस तरह की है, इसके बारे में लिखना संभव है। वास्तव में, हाल ही में सुरक्षा के बारे में बहुत कुछ लिखा गया है, और यहां तक ​​कि गृहिणियों को भी इसकी अच्छी समझ है। लेकिन, मेरे अनुभव में, इस क्षेत्र में अभी भी कई मिथक, भ्रांतियां हैं।


इन मिथकों में से एक कार्यक्रम के एक निश्चित कार्य के रूप में सुरक्षा का विचार है।

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

उदाहरण संख्या 2. सूचना प्रणाली के संरक्षण और सॉफ्टवेयर उत्पादों के लिए सुरक्षा आवश्यकताओं के विकास में शामिल जानकारी की सुरक्षा में विशेषज्ञता वाली एक गंभीर कंपनी। विभागाध्यक्ष हमने बात की। मेरे शब्दों में, "सुरक्षित कार्यक्रम" पूछता है: "सुरक्षा कार्यों के साथ एक कार्यक्रम?"।

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

सुरक्षा कार्यक्षमता नहीं है?

आइए सुरक्षा की बजाय पारंपरिक परिभाषा के साथ शुरू करें (मैं यहां मानता हूं कि सुरक्षा और सुरक्षा समानार्थक शब्द हैं), जिसे माइकल हॉवर्ड और डेविड लेब्लांक अपनी पुस्तक में देते हैं:

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

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

हालाँकि, ध्यान दें कि इस तरह की परिभाषा में सुरक्षा कार्यक्षमता का कोई संकेत नहीं है। इसी समय, कई विशेषज्ञ बहुत स्पष्ट रूप से कहते हैं कि सुरक्षा सॉफ्टवेयर की एक गैर-कार्यात्मक संपत्ति है। इसलिए जॉन विएगा और हैरी मैकग्राफ ने अपनी पुस्तक [2] में लिखा है:

क्या सुरक्षा एक ऐसी सुविधा है जिसे एक निकास प्रणाली में जोड़ा जा सकता है? क्या यह सॉफ्टवेयर की स्थिर संपत्ति है जो समान रहती है चाहे कोई भी वातावरण हो जिसमें कोड रखा जाता है? इन सवालों का जवाब सशक्त नहीं है।

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

तो, सुरक्षा एक सॉफ्टवेयर सुविधा नहीं है, यह इसकी संपत्ति है। और इस संपत्ति की प्रकृति काफी दिलचस्प है।

सुरक्षा को लेकर ऐसा क्या खास है

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

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

बेशक, इस बात पर आपत्ति जताई जा सकती है कि “सुरक्षा कार्यों” का उद्देश्य इसके लिए ठीक है। वे सुरक्षा प्रदान करते हैं, सिस्टम को "गलत" एक्सेस नहीं देते हैं।

हां। और नहीं।

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

दूसरी ओर, यदि सभी उपयोगकर्ताओं के पास सिस्टम में सभी वस्तुओं के संबंध में समान अधिकार थे, तो फिर से, सुरक्षा कार्यों को छोड़ा जा सकता है।

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

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

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

सभी समान विचार सॉफ्टवेयर विकास पर लागू होते हैं। इसकी सुरक्षा सुनिश्चित करने के लिए, संपूर्ण रूप से कार्यक्रम की संपत्ति के रूप में एक सुरक्षा प्रणाली बनाना आवश्यक है।

यह विकास प्रक्रिया को कैसे प्रभावित करता है?

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

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

लेकिन, सुरक्षा से निपटने के लिए, डेवलपर को नकारात्मक उम्मीदों के साथ काम करना होगा और कई समस्याओं को हल करना होगा।

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

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

और तीसरा, क्लाइंट को यह साबित करना आवश्यक है कि हमने एक प्रोग्राम बनाया है जो सुरक्षा सहित उसकी जरूरतों को पूरा करेगा। बेशक, हम यह कह सकते हैं कि यदि कार्यक्रम विनिर्देशों को पूरा करता है, तो ग्राहक को कोई शिकायत नहीं होनी चाहिए। औपचारिक रूप से, यह ऐसा है। व्यवहार में, इस स्तर पर यह सलाह दी जाती है कि ग्राहक को तर्कों के साथ यह साबित करना चाहिए कि कार्यक्रम में कमजोरियां नहीं हैं - कार्यक्षमता जो उनके नकारात्मक शब्दों में सुरक्षा आवश्यकताओं का उल्लंघन करती है। यदि ऐसा नहीं किया जाता है, तो क्लाइंट ने औपचारिक रूप से कार्यक्रम को अपनाया है, आगे सहयोग से इनकार कर सकता है।

इस प्रकार, सॉफ़्टवेयर की सुरक्षा विशेषता को विकास के सभी चरणों में विशेष उपायों की आवश्यकता होती है। इन उपायों पर चर्चा करने के लिए, यहां तक ​​कि एक संक्षिप्त, एक लेख की मात्रा पूरी तरह से अपर्याप्त है।

एक और विचार

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

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

साहित्य

1. माइकल हॉवर्ड, डेविड लेब्लांक "सिक्योर कोड," माइक्रोसॉफ्ट प्रेस, 2005 रूसी संस्करण, आईएसबीएन 5-7502-023-0, पृष्ठ 2।

2. जॉन विएगा, गैरी मैकग्रा "बिल्डिंग सिक्योर सॉफ्टवेयर। कैसे सुरक्षा समस्याओं से बचने के लिए सही तरीका ", एडिसन-वेस्ले 2005, आईएसबीएन 0-201-72152-एक्स, पी। 13

3. मायर्स जी। "सॉफ्टवेयर विश्वसनीयता", वर्ल्ड 1980