व्यावसायिक सिस्टम निर्माण में लाइब्रेरी के उपयोग के साथ जोखिम और उपाय

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

लाइब्रेरी क्या होती है

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

ध्यान दें, लाइब्रेरी के समान अर्थ में फ्रेमवर्क नामक शब्द भी है। इसके अलावा, OSS (ओपन सोर्स सॉफ़्टवेयर) नामक शब्द भी है। व्यावसायिक सिस्टम के संदर्भ में OSS सिस्टम के घटक होते हैं और इस लेख में लाइब्रेरी के बराबर होते हैं, लेकिन यह शब्द आपके कानों के लिए अधिक परिचित हो सकता है। हालांकि, इस लेख में हम लाइब्रेरी शब्द का उपयोग करेंगे।

लाइब्रेरी के फायदे: तेज और सुरक्षित

सिस्टम कंपनियों के लिए अपने निर्माण से बजाय लाइब्रेरी का उपयोग करने की वजह दो होती हैं।

• अपने निर्माण से तेज बनाने की क्षमता
• अपने निर्माण से अधिक सुरक्षा

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

लाइब्रेरी के नुकसान क्या हैं

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

अगर अपडेट नहीं किया जाता तो वुल्नरेबिलिटी हो सकती है

व्यक्तिगत जानकारी, क्रेडिट कार्ड की जानकारी, और कंपनी की गुप्त जानकारी चुराने की कोशिश करने वाले अपराधी रोजाना लाइब्रेरी (और अन्य सॉफ्टवेयर) की सुरक्षा में कमियां ढूंढते हैं। इन सुरक्षा कमियों को IT शब्दावली में “वुल्नरेबिलिटी” कहा जाता है। उपयोग की गई लाइब्रेरी में छिपी वुल्नरेबिलिटी के कारण हुए नुकसान के कई उदाहरण हैं। उदाहरण के लिए, जापानी संचार मंत्रालय की सर्वेक्षण साइट पर उपयोग की गई Struts2 नामक लाइब्रेरी की वुल्नरेबिलिटी के कारण करीब 200,000 ग्राहकों की जानकारी लीक हुई थी। उसी तरह, Struts2 का उपयोग करने वाली एक टिकट बिक्री साइट ने क्रेडिट कार्ड की जानकारी 32,187 लीक करने का खतरा था। सिस्टम की डिलीवरी के समय अज्ञात रहने वाली लाइब्रेरी की वुल्नरेबिलिटी बाद में सामने आ सकती है।

अपडेट करने से सिस्टम बंद होने का खतरा होता है

कई बार, वुल्नरेबिलिटी होने के बावजूद अपडेट नहीं किया जा सकता। इसका कारण यह होता है कि अपडेट करने से सिस्टम अस्थायी रूप से काम करना बंद कर सकता है। लाइब्रेरी सिस्टम कंपनी द्वारा लिखी गई प्रोग्राम नहीं होती है, इसलिए इसकी पूरी जानकारी होना वास्तविक रूप से कठिन होता है। इसलिए, अपडेट करने से सिस्टम में अनपेक्षित समस्याएं उत्पन्न हो सकती हैं, और सिस्टम अस्थायी रूप से काम करना बंद कर सकता है, यह जोखिम पूरी तरह से नहीं हटाया जा सकता। ग्राहक के रूप में, आपको शायद यह लगे कि सिस्टम कंपनी ने डिलीवर की गई सिस्टम की जानकारी नहीं रखी है, लेकिन वास्तव में, आधुनिक सिस्टम में उपयोग की जाने वाली लाइब्रेरी की गुणवत्ता और मात्रा इतनी होती है कि एक साधारण सिस्टम कंपनी इसे संभाल नहीं सकती। उदाहरण के लिए, उपयोगकर्ता इंटरफेस के निर्माण के लिए लाइब्रेरी में सबसे लोकप्रिय “React” नामक लाइब्रेरी है। यह लाइब्रेरी गुणवत्ता के हिसाब से Facebook के इंजीनियरों द्वारा बनाई गई उच्च कोटि की है, और मात्रा के हिसाब से यह कोड की पंक्तियों में 195,486 (टिप्पणी 1) है, जो बहुत अधिक है।

मामले जिनमें कमजोरियाँ न्यायिक निर्णय बन गईं

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

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

तोक्यो जिला न्यायालय, 23 जनवरी 2014

निम्नलिखित सामान्य फाउंडेशन सॉफ्टवेयर जानकारी सेंटर के दस्तावेज़ में इस निर्णय को लाइब्रेरी की कमजोरियों के संदर्भ में व्याख्या किया गया है।

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

IoT युग में OSS का उपयोग और कानूनी मुद्दे Q&A संग्रह[PDF][ja] (पृष्ठ 84)

इस प्रकार, यदि लाइब्रेरी की कमजोरियाँ होती हैं, लेकिन यदि यह पहले से ज्ञात कमजोरियाँ हैं और हमले को पूर्वानुमान करना आसान माना जाता है, तो इसे सिस्टम कंपनी की जिम्मेदारी के रूप में देखा जा सकता है।

और अधिक व्यावहारिक संवेदनशीलता उपाय क्या हैं?

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

1. रखरखाव संविदा का हिस्सा बनने के साथ-साथ लाइब्रेरी अपडेट
2. संवेदनशीलता निदान

रखरखाव संविदा का हिस्सा बनने के साथ-साथ लाइब्रेरी अपडेट

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

संवेदनशीलता निदान

सिस्टम द्वारा संभाले जाने वाले डेटा की मात्रा और UI की मांग दिन-ब-दिन बढ़ती जा रही है, जबकि नई संवेदनशीलताओं की संख्या लगातार बढ़ रही है। इसलिए, केवल सिस्टम कंपनी द्वारा संवेदनशीलता को पूरी तरह से रोकना मुश्किल है। इसलिए, संवेदनशीलता निदान की आवश्यकता होती है। IPA के अनुसार, कुल में 50% से अधिक, और बड़ी कंपनियों में 80% से अधिक व्यापारी संवेदनशीलता निदान कर रहे हैं।

संवेदनशीलता निदान में, मुफ्त उपकरण से लेकर महंगे मैन्युअल निदान तक विभिन्न प्रकार की चीजें होती हैं। विशेष रूप से, जिनकी लीक होने पर घातक परिणाम हो सकते हैं, ऐसी जानकारी का सामना करने वाले मामलों में, संवेदनशीलता निदान को विशेषज्ञता के रूप में करने वाले व्यापारियों को सौंपना और पर्याप्त लागत लगाने का उपाय अनिवार्य होता है। इसके अलावा, संवेदनशीलता रोजाना खोजी जाती है, इसलिए, न केवल डिलीवरी के समय बल्कि डिलीवरी के बाद भी निरंतर संवेदनशीलता निदान[ja] (P15) करना महत्वपूर्ण होता है।

सारांश

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