2025 तक, कुल वैश्विक डेटा निर्माण 181 ज़ेटाबाइट्स तक पहुंच जाएगा। उद्यमों के लिए, वह डेटा एक संपत्ति है, जो उन्हें अत्यधिक वैयक्तिकृत ग्राहक अनुभव बनाने के लिए विभिन्न प्रकार के प्रौद्योगिकी प्लेटफार्मों का लाभ उठाने की अनुमति देता है जो वफादारी पैदा करते हैं और नए व्यवसाय को आकर्षित करते हैं। हालाँकि, ये अनुभव साझा सुरक्षा मोड का उपयोग करके क्लाउड इंफ्रास्ट्रक्चर पर निर्भर हैं। यही वह जगह है जहां जोखिम निहित है, और यह बढ़ रहा है क्योंकि प्रौद्योगिकी कम-कोड और नो-कोड प्लेटफार्मों का उपयोग करके नागरिक डेवलपर्स की एक नई सेना को शामिल करने के लिए बढ़ रही है।
विरासत की मानसिकता को समझना और उस पर काबू पाना
गार्टनर अनुमान है कि 2025 तक, 70% एंटरप्राइज एप्लिकेशन लो-कोड और नो-कोड प्लेटफॉर्म जैसे सेल्सफोर्स और सर्विसनाउ से बनाए जाएंगे। विरासत-आधारित मानसिकता के साथ प्रतिक्रिया देना दो-तिहाई से अधिक एंटरप्राइज़ ऐप्स को विफलता के लिए तैयार करने का एक निश्चित तरीका है।
"विरासत मानसिकता" बुनियादी ढांचे को परेशान करने वाली समस्याओं का एक उपयुक्त वर्णनकर्ता है। यह उन अमीर, बिगड़ैल बच्चों की याद दिलाता है जो पूरी तरह से किए गए काम और उनसे पहले आए लोगों पर निर्भर हैं। यह विरासत बनाने का अच्छा तरीका नहीं है, और सिस्टम बनाने का भी उतना ही बुरा तरीका है।
जब आपके पास विरासती मानसिकता होती है, तो आप मान लेते हैं कि बुनियादी ढांचा तैयार हो गया है। प्लेटफ़ॉर्म सुरक्षित है, और सुरक्षा अंतर्निहित है। विश्वास केवल इसलिए माना जाता है क्योंकि तकनीक प्रशासक से पहले मौजूद थी।
वह विरासत मानसिकता कम-कोड और नो-कोड प्लेटफार्मों को परेशान करती है। उपयोगकर्ता संपूर्ण उद्यम अवसंरचना के माध्यम से उन्हें ले जाने के लिए एक प्लेटफ़ॉर्म की सुरक्षा पर भरोसा करते हैं। इसके बजाय, उस प्लेटफ़ॉर्म की सुरक्षा केवल उसी प्लेटफ़ॉर्म पर लागू होनी चाहिए।
मान लीजिए कि सेल्सफोर्स डेवलपर्स नए लीड के लिए एक स्वचालित असाइनमेंट प्रोग्राम बनाते हैं। वे इसे सेल्सफोर्स के भीतर आंतरिक असाइनमेंट के लिए उपयोग करते हैं, और यह ठीक है। वे प्लेटफ़ॉर्म की सुरक्षा पर भरोसा कर सकते हैं. उन्होंने स्वचालन में सुधार के लिए इसका विस्तार करने का निर्णय लिया। वे उस प्रोग्राम को ServiceNow, SAP, या Oracle जैसे बाहरी-सामना वाले CRM से जोड़ते हैं। विरासत की मानसिकता हावी हो जाती है: सेल्सफोर्स सुरक्षित है। ServiceNow, SAP या तृतीय-पक्ष सुरक्षित है।
तो, Salesforce + तृतीय पक्ष = सुरक्षित।
लेकिन, उस प्लस चिह्न में बहुत कुछ अज्ञात है। आप Salesforce में बनाए गए आंतरिक प्रोग्राम को तृतीय-पक्ष प्लेटफ़ॉर्म में बनाए गए बाहरी प्रोग्राम से सुरक्षित और अनुपालनपूर्वक कैसे कनेक्ट करते हैं? उस एक पात्र में त्रुटि की बहुत गुंजाइश है।
और वह केवल एक कनेक्शन है. सेल्सफोर्स में बनाए गए कई प्रोग्राम सैकड़ों अन्य लोगों को प्रभावित करते हैं। सैकड़ों अज्ञात लोगों के साथ उन लोगों द्वारा ऊपर वर्णित धन चिह्न की तरह व्यवहार किया जा रहा है जिनके पास विकास का बहुत कम या कोई अनुभव नहीं है।
एकमात्र समाधान DevSecOps सिद्धांतों की वापसी के साथ उस विकास को वापस धरती पर ले जाना है।
DevSecOps फ्रेमवर्क की स्थापना
देवसेकऑप्स अवधारणा के निर्माण के बाद से रूपरेखाएँ लिखी गईं, फिर से लिखी गईं और फिर से लिखी गईं। उन्हें स्थापित करते समय पहिये को फिर से आविष्कार करने की कोई आवश्यकता नहीं है, खासकर जब SAFECode और क्लाउड सुरक्षा गठबंधन छह स्तंभ बनाए गए हैं:
- सामूहिक जिम्मेदारी: सुरक्षा उद्यम में प्रत्येक व्यक्ति की ज़िम्मेदारी है-लेकिन लोग उन मानकों को पूरा नहीं कर सकते जिन्हें वे नहीं जानते हैं। साइबर सुरक्षा नीति को चलाने और इसे पूरे उद्यम में प्रसारित करने को सुनिश्चित करने के लिए लीड्स को नियुक्त किया जाना चाहिए।
- सहयोग और एकीकरण: ज्ञान को साझा और हस्तांतरित किया जाना चाहिए। उद्यमों के विरासत की मानसिकता में आने का आधा कारण यह है कि पुरानी प्रणाली को जानने वाला हर कोई चला गया है। निरंतर ज्ञान साझा करने से इस समस्या को खत्म करने में मदद मिलती है।
- व्यावहारिक कार्यान्वयन: व्यावहारिक कार्यान्वयन डेवलपर अनुभव से जुड़ता है। जो प्रक्रियाएँ कठिन, सांसारिक और बोझिल होती हैं उनका लंबे समय तक पालन नहीं किया जाता है। सुरक्षा को विकास प्रथाओं में शामिल किया जाना चाहिए - अर्थात, कोड की प्रत्येक पंक्ति के लिए परीक्षण की एक पंक्ति की आवश्यकता होती है। एक उच्च प्रदर्शन करने वाला उद्यम परीक्षण कोड की प्रत्येक पंक्ति को स्वचालित करने के लिए एक उपकरण का उपयोग करके इसे और आगे ले जाएगा।
- अनुपालन और विकास: अनुपालन आवश्यकताओं को विकास प्रक्रिया को इस तरह निर्देशित करना चाहिए कि डेवलपर्स को उनसे भटकने की अनुमति न मिले। उदाहरण के लिए, एक वित्तीय संस्थान के लिए एक डेवलपर एक ऐसे प्लेटफ़ॉर्म पर काम करेगा जिसे ग्रैम-लीच-ब्लिली अधिनियम के अनुरूप बनाया गया है। डेवलपर को अनुपालन के लिए अधिनियम के अलग-अलग पहलुओं को जानने की आवश्यकता नहीं है क्योंकि वे प्लेटफ़ॉर्म में निर्मित होते हैं।
- स्वचालन: डेवलपर्स से बोझ हटाने और मानवीय त्रुटि के जोखिम को कम करने के लिए जब भी संभव हो, पूर्वानुमानित, दोहराए जाने योग्य और उच्च मात्रा वाले कार्यों को स्वचालित किया जाना चाहिए।
- मॉनिटर: आधुनिक क्लाउड इन्फ्रास्ट्रक्चर बदलते और बढ़ते हैं। इस पर नज़र रखना महत्वपूर्ण है - आदर्श रूप से, किसी प्रकार के ऑर्केस्ट्रेशन के माध्यम से जो सभी विभिन्न अंतर्संबंधों को एक नज़र में देखने की अनुमति देता है।
में कम या कोई कोड नहीं पर्यावरण के अनुसार, ये स्तंभ उतने सीधे नहीं हैं जितनी कोई उम्मीद करेगा। इन उपकरणों का उपयोग करने वाले लोग अक्सर व्यावसायिक विशेषज्ञ होते हैं जिन्हें DevSecOps की बुनियादी बातों की बहुत कम जानकारी होती है।
लोगों, प्रक्रियाओं और प्रौद्योगिकी को एक साथ लाना
लो-कोड और नो-कोड प्लेटफ़ॉर्म का उपयोग वास्तव में इस कौशल अंतर को कम करने में मदद कर सकता है। कर्मचारी नए कौशल सीखना चाहते हैं। उद्यम लोगों, प्रक्रियाओं और प्रौद्योगिकी पर ध्यान केंद्रित करते हुए DevSecOps ढांचे की स्थापना करके इसका समर्थन कर सकते हैं।
- प्रक्रियाएं: शून्य-विश्वास वाले माहौल में, कम-कोड और बिना-कोड वाले डेवलपर्स को सिस्टम अखंडता को खतरे में डालने वाले कनेक्शन बनाने के बारे में चिंता करने की ज़रूरत नहीं है क्योंकि वे ऐसा करने में असमर्थ हैं। उनके पास अपनी पृथक प्रणाली के बाहर कोई आधारभूत प्राधिकार नहीं है।
- लोग: जवाबदेही की संस्कृति दोषारोपण की संस्कृति से भिन्न है। जवाबदेही का मतलब है कि व्यक्ति किसी समस्या या गलती के साथ आगे आने में सहज महसूस करते हैं क्योंकि ध्यान मुद्दे पर होता है, व्यक्ति पर नहीं।
- प्रौद्योगिकी: DevSecOps सिद्धांतों के उचित कार्यान्वयन में प्रौद्योगिकी सबसे बड़ी बाधा है क्योंकि यह डेवलपर्स के हाथ से बाहर है। संगठन उन्हें जो देता है उसका उन्हें अवश्य उपयोग करना चाहिए। यदि वह तकनीक काम नहीं करती है, तो डेवलपर्स ऐसे समाधान लेकर आएंगे जो न तो सुरक्षित हैं और न ही सुरक्षित। मूलतः, प्रौद्योगिकी एक बड़ी छाया आईटी जनरेटर बन जाती है।
हम विकास के एक रोमांचक समय में रह रहे हैं। अधिक से अधिक लोगों के पास सॉफ़्टवेयर बनाने, रणनीतियों का परीक्षण करने और व्यावसायिक मूल्य में सुधार करने का अवसर है। लेकिन इसके साथ जोखिम भी आता है। जो उद्यम उस जोखिम को प्रौद्योगिकी पर थोपने के तरीकों पर विचार करते हैं, वे अन्वेषण के लिए गुंजाइश छोड़ते हुए अपने विकास को जमीन पर रखेंगे।
