गैर-तुच्छ प्रश्नों के व्यावहारिक उत्तर, या जटिल आईटी परिदृश्य वाले संगठनों में DevSecOps को कैसे लागू किया जाए

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

कटौती के तहत - पहली वीटीबी बैठक से सबसे दिलचस्प "देवसेकॉप्स: गैर-तुच्छ सवालों के व्यावहारिक जवाब", जो नवंबर में वेवॉर्क साइट पर हुआ था। बैठक में 200 से अधिक विशेषज्ञों ने भाग लिया।

यह सब कैसे शुरू हुआ

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



लेकिन वास्तव में, सब कुछ बहुत अधिक जटिल है। इस रास्ते पर, बैंक को कई कठिनाइयों का सामना करना पड़ा। वीटीबी विकास प्रक्रिया स्वचालन विभाग के प्रमुख इगोर श्वाकोव ने अपनी रिपोर्ट में इस बारे में बात की।

आईटी के संदर्भ में मुख्य चुनौती वीटीबी की विशिष्टता है। ऐतिहासिक रूप से, बैंक बड़े खिलाड़ियों के अधिग्रहण और एकीकरण के माध्यम से विकसित हुआ, जिनमें से प्रत्येक की अपनी आईटी वास्तुकला, हार्डवेयर, व्यावसायिक प्रक्रियाएं आदि थीं, 2018 के बाद से, वीटीबी, वीटीबी 24 और मॉस्को के बैंक अपने स्वयं के अनूठे आईटी के साथ एक वीटीबी बन गए हैं। परिदृश्य, विषम और कहीं अलग-थलग अवसंरचना। स्वाभाविक रूप से, परिवर्तनकारी परिवर्तनों को करने के लिए, एक साथ एक व्यवसाय का निर्माण (जैसे कि एक व्यापार रणनीति) है और ऐसी स्थितियों में DevOps (और विशेष रूप से DevSecOps) को लागू करना एक गैर-तुच्छ कहानी है।

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

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

सिस्टम प्रतिकृति अनुभव

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

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

अगला दिलचस्प सवाल यह है कि सिस्टम को बैंक सर्किट में कैसे स्थानांतरित किया जाए।
एक नियम के रूप में, एक प्रणाली के मानक अनुवाद चक्र में 7-8 महीने लगते हैं। इसे निम्नानुसार रखा गया है।

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

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

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

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



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

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

नुकसान

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

विकास, परीक्षण और संचालन में शामिल सेवाओं को एक ही व्यवसाय की कार्यक्षमता पर काम करने वाली क्रॉस-फ़ंक्शनल टीमों में बदलने का निर्णय लिया गया। टीमों में आर्किटेक्चर और डेवलपमेंट स्पेशलिस्ट, टेक्नोलॉजिस्ट, टेस्टर और DevOps इंजीनियर शामिल हैं। केंद्रीकृत सेवाओं में, केवल वही रहता है जिसमें अद्वितीय योग्यताएं होती हैं या एक अद्वितीय लय (24/7) में रहती हैं - लागू और सिस्टम प्रशासन, सूचना सुरक्षा।

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

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

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

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



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

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

सभी के ऊपर साइबर सुरक्षा

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



आवश्यक IS प्रथाओं में शामिल हैं:

• जब वे विकास की परिधि में आते हैं तो ओपन सोर्स घटकों का नियंत्रण (ओपन सोर्स एनालिसिस, ओएसए);
  
• स्टेटिक कोड विश्लेषण (स्टेटिक एप्लीकेशन सिक्योरिटी टेस्टिंग, एसएएसटी);
  
• सॉफ्टवेयर घटकों की संरचना की निगरानी (सॉफ्टवेयर संरचना विश्लेषण, एससीए);
  
• सभी प्रकार के गतिशील विश्लेषण (डायनेमिक एप्लिकेशन सिक्योरिटी टेस्टिंग, DAST / इंटरएक्टिव एप्लीकेशन सिक्योरिटी टेस्टिंग, IAST / व्यवहार एप्लिकेशन सुरक्षा परीक्षण, BAST);
  
• बाइनरी कोड विश्लेषण और कंटेनर रचना नियंत्रण (बायटेकोड और कंटेनर विश्लेषण, बीसीए);
  
• WAF का कार्यान्वयन (वेब ​​अनुप्रयोग फ़ायरवॉल)।
  

उसी समय, DevOps प्रक्रियाओं को व्युत्पन्न DevSecOps प्रतिमान में स्केल करने और बदलने के लिए सबसे महत्वपूर्ण पहलू:

• विकास प्रक्रिया के दौरान डिफ़ॉल्ट रूप से सुरक्षित पुस्तकालयों, रूपरेखाओं और सॉफ्टवेयर घटकों का उपयोग (सिक्योर-बाय-डिफॉल्ट);
  
• CI / CD पाइपलाइन (Shift-Left दृष्टिकोण) की शुरुआत में आईएस प्रौद्योगिकी प्रथाओं का एकीकरण;
  
• सब कुछ-ए-कोड अवधारणा में सभी प्रक्रियाओं का स्वचालन;
  
• सुरक्षा चैंपियन के एक समुदाय का गठन जो उत्पादन टीमों में सूचना सुरक्षा के कार्यों के लिए जिम्मेदार हैं और एक इंजीनियरिंग सुरक्षा संस्कृति के मार्गदर्शक हैं;
  
• मौजूदा प्रक्रिया का आकलन करने और निरंतर सुधार के लिए दोनों DevSecOps परिपक्वता मॉडल का आवेदन;
  
• इंजीनियरिंग उत्पादन प्रक्रिया में सभी प्रतिभागियों के लिए सभी सुरक्षा गतिविधियों की पारदर्शिता सुनिश्चित करना।
  

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

यदि हम संपूर्ण रूप में परिवर्तन के बारे में बात करते हैं, तो हम निम्नलिखित प्रमुख सफलता कारकों को अलग कर सकते हैं:

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