अनुप्रयोग सुरक्षा: यह लगभग आसान है

"मुझे एक नोट दें कि मेरा कार्यक्रम सुरक्षित है।"

- कोई बात नहीं! इसके लिए आपने क्या किया?

- उह ... अच्छा ... यह है ... कुछ भी नहीं ...

"आपको क्यों लगता है कि वह सुरक्षित है?"

- ठीक है, आप जाँच करें!

- कोई बात नहीं! सभी खुशी X0000 डॉलर खर्च होंगे।

- ?!

लेख के बारे में

इस लेख में, मैं सुरक्षित सॉफ्टवेयर बनाने के लिए कुछ प्रथाओं के बारे में बात करता हूं।

पहला भाग सुरक्षित प्रोग्रामिंग के लिए समर्पित है।

एक ओर, सुरक्षित प्रोग्रामिंग तकनीकों को जाना जाता है। उनके उपयोग का अनुभव संचित किया गया है, बहुत सारा साहित्य लिखा गया है।

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

बेशक, लेख इस मुद्दे को पूरी तरह से कवर करने का दिखावा नहीं करता है। लेकिन इसे सही दिशा में थोड़ा कदम होने दें। और, मुझे आशा है, आप देखेंगे कि सुरक्षित प्रोग्रामिंग में कुछ भी असामान्य नहीं है।

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

चेतावनी! लेख बड़ा है और इसमें सावधानीपूर्वक पढ़ना शामिल है।

भाग I. सुरक्षित प्रोग्रामिंग

अपनी तकनीक को जानें

प्रत्येक तकनीक के दो पहलू होते हैं। एक पक्ष हमारे उपयोगकर्ता के लिए उपयोगी गुण हैं, हम उन्हें अपने उत्पादों में उपयोग करते हैं; दूसरा पक्ष वह गुण है जो एक पटाखा उपयोग कर सकता है, प्रौद्योगिकी की कमजोरियां। कभी-कभी एक तकनीक इतनी कमजोर होती है कि किसी भी परिस्थिति में इसका उपयोग उचित नहीं हो सकता है। उदाहरण के लिए, C प्रोग्राम में फ़ंक्शन लगभग हमेशा बुराई होता है। सुरक्षा के लिए आवश्यक उपाय करके अन्य तकनीकों का उपयोग किया जा सकता है। तो SQL सर्वर का उपयोग संभवतः sql इंजेक्शन के अवसरों को खोल सकता है। लेकिन हम जानते हैं कि इससे कैसे निपटा जाए और इसके लिए जरूरी सुरक्षात्मक उपाय किए जाएं।

हमें अपनी तकनीक के दोनों पक्षों को जानना होगा। कैसे एक उपयोगी कार्यक्रम बनाने के लिए किसी भी प्रोग्रामर का मुख्य ज्ञान है, इस ज्ञान के लिए धन्यवाद हम पैसा बनाते हैं। इसलिए, यह स्पष्ट है कि हम इस पहलू का अध्ययन करने के लिए अपना मुख्य समय समर्पित करते हैं।

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

अभी इस विषय को समर्पित इंटरनेट पर कई अच्छे संसाधन हैं।

ऐसा ही एक संसाधन है ओपन वेब एप्लीकेशन सिक्योरिटी प्रोजेक्ट । जैसा कि नाम से पता चलता है, परियोजना वेब अनुप्रयोगों की सुरक्षा के लिए समर्पित है, लेकिन अन्य क्षेत्रों में प्रोग्रामिंग करते समय एक ही जानकारी भी लागू की जा सकती है। साइट अब विकिपीडिया के लोकप्रिय रूप में बनी है, और इसमें अलग-अलग लेख हैं; विभिन्न सिद्धांतों के अनुसार समूहीकृत इन लेखों की सूची है। प्रौद्योगिकी द्वारा समूहीकृत लेखों का एक सूचक निम्नलिखित पते पर पाया जा सकता है।

मैं OWASP को बार-बार संदर्भित करता रहूंगा। यह परियोजना अनुप्रयोग सुरक्षा पेशेवरों के लिए एक बहुत ही मूल्यवान संसाधन है।

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

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

पुस्तकालयों का उपयोग करें

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

अब बड़ी संख्या में पुस्तकालय हैं। आप लगभग किसी भी कार्य के लिए तैयार समाधान पा सकते हैं, और आप सशुल्क लाइब्रेरी और ओपन सोर्स लाइब्रेरी दोनों पा सकते हैं।

उदाहरण के लिए, क्रिप्टोग्राफिक विधियों को लागू करने के लिए ओपनसेल की सिफारिश की जा सकती है। पुस्तकालय अच्छी तरह से जाना जाता है, हम में से अधिकांश के लिए एक हद तक सत्यापित है, एक मुफ्त लाइसेंस के तहत वितरित किया जाता है।

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

दुर्भाग्य से, ईएसएपीआई अभी विकसित नहीं हो रहा है। फिर भी, यह एक अच्छी तरह से स्थापित पुस्तकालय है, और उम्मीद है कि इसके समर्थन को नवीनीकृत किया जाएगा।

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

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

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

सामान्य तौर पर, यह सुरक्षित है: कम बाइक एक बेहतर समाधान है।

एक आत्म परीक्षण करो

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

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

आप बहुत समय बचाएंगे। हालांकि ऐसा लगता है कि समय बर्बाद हो रहा है, यह एप्लिकेशन डिबगिंग में एक महत्वपूर्ण कमी के कारण वापस आ जाएगा।

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

कृपया ध्यान दें: घमंड न केवल गुणवत्ता का दुश्मन है, बल्कि गति भी है।

कोड सत्यापन उपयोगिताओं का उपयोग करें

मूर्खतापूर्ण गलतियाँ करना मानव स्वभाव है। उसी समय, सभी प्रोग्रामर जानते हैं कि यह बेवकूफ त्रुटियां हैं जिनका पता लगाना सबसे मुश्किल है: किसी भी अपरिवर्तित अर्धविराम से पूरे दिन का नुकसान हो सकता है (यदि अधिक नहीं)।

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

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

स्वचालित विश्लेषण पर बहुत ज्यादा भरोसा न करें। इस तरह के कार्यक्रमों से उत्पन्न जानकारी को लगभग उसी तरह से व्यवहार किया जाना चाहिए जैसे हम संकलक चेतावनी से संबंधित हैं। हम सभी जानते हैं कि चेतावनी की अनुपस्थिति का मतलब त्रुटि की अनुपस्थिति नहीं है; इस तरह के स्कैनर सभी कमजोरियों से दूर प्रकट करते हैं, यहां तक ​​कि उन्हें एक प्रकार से भी जाना जाता है। दूसरी ओर, एक चेतावनी की उपस्थिति अभी तक एक समस्या का सबूत नहीं है, और सभी चेतावनियों से छुटकारा पाने की एक विचारहीन इच्छा कभी-कभी केवल अधिक गंभीर कमजोरियों का कारण बन सकती है।

स्वचालन हमारे समय को कुछ और रोचक बना सकता है। यदि आपके काम का हिस्सा कंप्यूटर को सौंपा जा सकता है, तो ऐसा क्यों नहीं किया जाता है?

कसौटी

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

इस व्यवहार का परीक्षण किया जा सकता है। और हम कार्यक्रम के स्वचालित परीक्षण के सभी लाभ प्राप्त करते हैं: इसे अक्सर मानव हस्तक्षेप के बिना लगभग पूरा किया जा सकता है।

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

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

परीक्षण सभी सुरक्षा समस्याओं को हल नहीं कर सकता है। लेकिन अगर कुछ स्वचालित रूप से परीक्षण करना संभव है, तो इसका उपयोग क्यों न करें?

कोड समीक्षा करें

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

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

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

और फिर से, OWASP। बेशक, यह परियोजना इतनी महत्वपूर्ण कार्यप्रणाली को दरकिनार नहीं कर सकती। इसलिए, यदि आप अपनी परियोजना में कोड का ऑडिट करने जा रहे हैं (मैंने आपको ऐसा करने के लिए अभी तक आश्वस्त नहीं किया है?), इस साइट का संबंधित पृष्ठ एक अच्छा प्रारंभिक बिंदु है।

तो आप अभी तक एक कोड समीक्षा नहीं कर रहे हैं? तुझे कोई माफ़ नहीं करना है !!!

एक जटिल में सभी उपायों का उपयोग करें

उह ... क्या आपको यहां कुछ लिखना है?

भाग II सुरक्षा इंजीनियरिंग

सादृश्य को प्रेरित करना

चलो अब सुरक्षा से बचो। प्रोग्रामर के लिए सबसे आम कार्यों में से एक मौजूदा कार्यक्रम को संशोधित करना है। हमें अक्सर एक कार्यक्रम "खरोंच से" नहीं बनाना होता है, लेकिन एक मौजूदा एक - जिसे आप पसंद करते हैं, उसे बदलने ("बनाए रखने") के लिए।

इसलिए, हमें मौजूदा कार्यक्रम को बदलना होगा। और इसे एक "महत्वपूर्ण" परिवर्तन होने दें, ताकि इसका मतलब यह न हो, प्रत्येक प्रोग्रामर आसानी से खुद एक स्थिति सोच सकता है।

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

क्या यह एक गंभीर समस्या है?

मान लीजिए हमारा 100 लाइनों में एक कार्यक्रम है। मुझे लगता है कि हर अधिक या कम योग्य प्रोग्रामर आसानी से किसी भी, यहां तक ​​कि बहुत "महत्वपूर्ण" परिवर्तन कर देगा। और यह उसे ले जाएगा, अगर एक दिन नहीं, तो दो या तीन से अधिक नहीं, यहां "परिवर्तन" पर चर्चा करना भी हास्यास्पद है।

कार्यक्रम 10 हजार लाइनें है। कार्य सबसे आसान नहीं होगा, लेकिन यदि आप कोशिश करते हैं, तो आप इसे हल कर सकते हैं।

कार्यक्रम 1 मिलियन लाइनों का है। यहां सब कुछ बहुत जटिल है: आप कठिन धक्का दे सकते हैं और समस्या को हल कर सकते हैं, लेकिन यह सभी कोड को फेंकने और फिर से लिखने के लिए तेज़ और सस्ता हो सकता है।

बेशक, मैंने "छत से" कार्यक्रमों का आकार लिया। यह स्पष्ट है कि सब कुछ परिवर्तनों के "भौतिकता" और समस्या की उपेक्षा की डिग्री पर निर्भर करेगा। लेकिन हम सभी एक समान होते हैं, और हर कोई कल्पना करता है कि किसी कार्यक्रम को संशोधित करने की जटिलता कितनी तेजी से बढ़ती है।

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

अब वापस सुरक्षा के लिए।

सुरक्षित वास्तुकला और डिजाइन के सिद्धांत

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

मैं आपको इन सिद्धांतों की याद दिलाता हूं:

• तंत्र की सादगी (तंत्र की अर्थव्यवस्था);
  
• असफल-सुरक्षित चूक
  
• संरक्षण की पूर्ण पैठ (पूर्ण मध्यस्थता);
  
• खुला डिजाइन
  
• विशेषाधिकार अलग करना;
  
• न्यूनतम विशेषाधिकार
  
• संसाधन साझाकरण (कम से कम सामान्य तंत्र) को कम करना;
  
• मनोवैज्ञानिक स्वीकार्यता।
  

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

ऐसा लगता है कि आप स्वास्थ्य के लिए खुद को डिजाइन करते हैं, सुरक्षा के लिए लोगों के लिए।

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

हमें पैटर्न का उपयोग करना चाहिए।

सुरक्षित वास्तुकला और डिजाइन टेम्पलेट

हमारे काम में, बार-बार लगातार कार्य उत्पन्न होते हैं। प्रत्येक प्रणाली, प्रत्येक कार्यक्रम कुछ अन्य लोगों के समान है। और मानक कार्यों के लिए, मानक समाधान हैं - टेम्पलेट।

उनके प्रमाण के लिए टेम्पलेट अच्छे हैं। प्रत्येक टेम्पलेट अनुभव से उत्पन्न हुई, यह परीक्षण, त्रुटि, सुधार, समस्याओं के उन्मूलन का परिणाम है। टेम्प्लेट का उपयोग करके, हम सटीक अनुमान लगा सकते हैं कि इससे क्या परिणाम होंगे, इसका क्या लाभ होगा, और किन समस्याओं से जूझना होगा।

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

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

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

बेशक, हम आवेदन सुरक्षा पैटर्न में रुचि रखते हैं।यहां आप विभिन्न स्तरों के बारे में भी बात कर सकते हैं: सुरक्षित व्यवहार के पैटर्न, और एक सुरक्षित कार्यक्रम की संरचना के पैटर्न हैं।

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

लेकिन मैं पाठकों का ध्यान एक सुरक्षित कार्यक्रम की संरचना की ओर आकर्षित करना चाहता हूं। हां, यह छाया में है: इसे प्रदर्शित करना मुश्किल है, इसे बेचना मुश्किल है।

लेकिन सुरक्षा अपने व्यवहार की तुलना में कार्यक्रम की संरचना पर कम निर्भर नहीं है। इसमें त्रुटि करने की संभावना कार्यक्रम की संरचना पर निर्भर करती है; कार्यक्रम की संरचना निर्धारित करती है कि क्या यह त्रुटि एक भेद्यता बन जाती है; कार्यक्रम की संरचना यह निर्धारित करती है कि यह भेद्यता कितनी गंभीर होगी। उदाहरण के लिए, इस बारे में सोचें कि किस त्रुटि के कारण अधिक गंभीर परिणाम होंगे: कोड में जो महत्वपूर्ण डेटा तक पहुंच है, या कोड में ऐसी पहुंच नहीं है?

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

पहला प्रकाशन - "सुरक्षा डिज़ाइन पैटर्न" ( पीडीएफ))। मेरी राय में, यह सुरक्षित कार्यक्रमों के संरचनात्मक पैटर्न पर उच्चतम गुणवत्ता वाले प्रकाशनों में से एक है। यह लगभग 10 साल पहले 2004 में ओपन ग्रुप कंसोर्टियम द्वारा प्रकाशित किया गया था । इस प्रकाशन में आपको टेम्प्लेट का उपयोग करके सुरक्षा को डिजाइन करने की पद्धति और उनमें से कई का वर्णन दोनों मिलेगा।

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

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

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

अन्य साहित्य है। लेकिन, मेरी राय में, वर्णित दो स्रोत पर्याप्त होंगे, कम से कम शुरुआत के लिए। उनमें उपलब्ध जानकारी का पता लगाकर, आप पहले से ही अधिक सुरक्षित कार्यक्रम बना सकते हैं।

पढ़ें, सोचें, आवेदन करें।

निष्कर्ष

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

एक मध्यम-जटिल कार्यक्रम को डिजाइन करने के बारे में सोचकर, आप अपने आप को बहुत समय, पैसा बचाएंगे और संभवतः, अपनी प्रतिष्ठा बनाए रखेंगे।

उच्च गुणवत्ता वाली वास्तुकला और एक जटिल कार्यक्रम का डिज़ाइन इसे सुरक्षित बनाने का एकमात्र तरीका है।

अगली बार जब आप किसी नए कार्यक्रम की योजना बनाते हैं या किसी मौजूदा को फिर से तैयार करने के बारे में सोचते हैं।

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

एक छोटे से बोनस के रूप में, मैं लेख के विषय पर साहित्य की सूक्ष्म समीक्षा जोड़ूंगा।