🤛🏿 🌒 👦🏼 DevOps vs DevSecOps: यह एक बैंक में कैसे दिखता है 🎽 🎅🏻 🕞

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

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

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

एक सरल रहस्योद्घाटन कि ठेकेदार को उत्पाद कोड तक पूर्ण पहुंच है, पहले से ही उनकी दुनिया को उल्टा कर दिया है।

उस पल में, देवसेप्स की कहानी शुरू हुई, जिसके बारे में मैं बताना चाहता हूं।

किस बैंक ने इस स्थिति से व्यावहारिक निष्कर्ष निकाला

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

, , « ».
, , .
- , . , . .

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

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

यह अचानक स्पष्ट हो गया कि यदि इससे पहले DevSecOps बैंकिंग सुरक्षा का विकासकर्ता की तरफ से कोई नियंत्रण नहीं था, तो नए प्रतिमान में, बुनियादी ढांचे पर सामान्य घटनाओं की तरह ही सुरक्षा को नियंत्रित किया जाता है। केवल अब असेंबली, लाइब्रेरी नियंत्रण और इसी तरह से अलर्ट हैं।

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

क्या बदल रहा था

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

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

सीआई: गिट, जेनकिन्स, मावेन, रोजलिन, ग्रैडल, जेनीट, जीरा, एमएफ फोर्टीफेट, सीए हार्वेस्ट, जीटलैबीसी।
CD: Ansible, कठपुतली, टीमसिटी, Gitlab TFS, लिक्विडबेस।
टेस्ट: सोनारक्बी, सोपुई, जेमीटर, सेलेनियम: एमएफ फोर्टीफाइ, परफॉर्मेंस सेंटर, एमएफ यूएफटी, एटस्कामा।
प्रस्तुति (रिपोर्टिंग, संचार): ग्राफाना, किबाना, जीरा, कंफ्लुएंस, रॉकेटवच।
संचालन : अन्सिबल, ज़ैबिक्स, प्रोमेथियस, इलास्टिक + लोगस्टैश, एमएफ सर्विस मैनेजर, जीरा, कंफ्लुएंस, एमएस प्रोजेक्ट।

एक स्टैक चयनित:

ज्ञान का आधार - एटलसियन संघर्ष;
टास्क ट्रैकर - एटलसियन जीरा;
कलाकृतियों का भंडार - "नेक्सस";
निरंतर एकीकरण प्रणाली - "गिटलैब सीआई";
निरंतर विश्लेषण प्रणाली - "सोनारक्यूब";
एप्लीकेशन सिक्योरिटी एनालिसिस सिस्टम - "माइक्रो फोकस फोर्टिफाई";
संचार प्रणाली - "गिटलैब मैटरैस्ट";
विन्यास प्रबंधन प्रणाली - "उत्तर देने योग्य";
निगरानी प्रणाली - "ईएलके", "टिक स्टैक" ("इन्फ्लक्सडाटा")।

उन्होंने एक टीम बनाना शुरू किया जो ठेकेदारों को अंदर खींचने के लिए तैयार होगी। बोध यह आया है कि कई महत्वपूर्ण चीजें हैं:

. — . , .
, . — , .

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

इसके अलावा, सर्किट का निर्माण - सॉफ्टवेयर इंस्टॉलेशन, कॉन्फ़िगरेशन। तैनाती के बुनियादी ढांचे और प्रबंधन के लिए लिपियों का विकास। अगला पाइपलाइन समर्थन के लिए संक्रमण है।

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

बाकी स्टैक सभी के लिए कमोबेश परिचित है। Ansible भाग में स्वचालन उपकरण का उपयोग किया गया था, और सुरक्षा गार्ड उनके साथ मिलकर काम करते थे। परियोजना से पहले बैंक द्वारा एटलसिनोवस्की स्टैक का उपयोग किया गया था। Fortinet Security Tools - यह सुरक्षा गार्डों द्वारा स्वयं प्रस्तावित किया गया था। परीक्षण फ्रेम बैंक द्वारा बनाया गया था, कोई सवाल नहीं पूछा गया। प्रश्न रिपॉजिटरी सिस्टम के कारण थे, मुझे इसकी आदत डालनी थी।

ठेकेदारों को एक नया ढेर दिया गया। उन्होंने GitlabCI के तहत फिर से लिखने और जीरा को बैंक सेगमेंट में स्थानांतरित करने का समय दिया और इसी तरह।

क्रमशः

चरण 1. सबसे पहले, हमने एक घरेलू विक्रेता के समाधान का उपयोग किया, उत्पाद को नए बनाए गए डीएसओ नेटवर्क सेगमेंट में बदल दिया गया। प्लेटफॉर्म को डिलीवरी समय, मापनीयता और पूर्ण स्वचालन क्षमताओं के लिए चुना गया था। आयोजित परीक्षण:

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

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

परिणाम - प्रदान किए गए उपकरण प्रदर्शन और गलती सहनशीलता के लिए बैंक की आवश्यकताओं को पूरा नहीं करते हैं। DIT बैंक ने PAC Nutanix पर आधारित एक कॉम्प्लेक्स बनाने का फैसला किया।

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

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

स्टेज 4. एप्लीकेशन सॉफ्टवेयर इंस्टालेशन का ऑटोमेशन। ये कार्य नई टीमों के टीम लीडरों द्वारा निर्धारित किए गए थे।

स्टेज 5. ऑपरेशन।

दूरस्थ पहुँच

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

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

बैंक में पहले से उपलब्ध तकनीकों का उपयोग करना।
बुनियादी ढांचा मौजूदा डोमेन नियंत्रकों का उपयोग नहीं करना चाहिए जो उत्पादक खातों / वस्तुओं के रिकॉर्ड संग्रहीत करते हैं।
पहुंच केवल उन संसाधनों तक सीमित होनी चाहिए जो किसी विशेष टीम द्वारा आवश्यक हो (ताकि एक उत्पाद की टीम किसी अन्य टीम के संसाधनों तक नहीं पहुंच सके)।
सिस्टम में RBAC पर अधिकतम नियंत्रण।

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

मौजूदा बैंक उपकरणों के आधार पर सीधे रिमोट एक्सेस का आयोजन किया गया था। अभिगम नियंत्रण को AD समूहों में विभाजित किया गया था, जो संदर्भों (एक उत्पाद समूह = एक नियम समूह) में नियमों के अनुरूप था।

VM टेम्प्लेट प्रबंधित करें

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

विकास के दौरान अवसंरचना और सुरक्षा आवश्यकताओं को भी ध्यान में रखा गया - छवियों को अद्यतित (पैच, आदि) बनाए रखना, बैंक के द्वारा अपनाए गए मानकों के अनुसार, सीमेंस के साथ एकीकरण, सुरक्षा सेटिंग्स।

परिणामस्वरूप, उन्हें बनाए रखने की लागत को कम करने के लिए न्यूनतम छवियों का उपयोग करने का निर्णय लिया गया। सॉफ़्टवेयर / सॉफ़्टवेयर के नए संस्करणों के लिए प्रत्येक छवि में पैच स्थापित करने की तुलना में बेस ओएस को अपडेट करना बहुत आसान है।

परिणामों के आधार पर, ऑपरेटिंग सिस्टम के न्यूनतम आवश्यक सेट से एक सूची संकलित की गई, जिसका अपडेट ऑपरेटिंग टीम द्वारा किया जाता है, और पाइपलाइन से स्क्रिप्ट पूरी तरह से सॉफ़्टवेयर / सॉफ़्टवेयर को अपडेट करने के लिए ज़िम्मेदार होती है, और यदि आवश्यक हो, तो स्थापित सॉफ़्टवेयर के संस्करण को पाइप लाइन में वांछित टैग को स्थानांतरित करने के लिए पर्याप्त है। हां, इसके लिए devops'a उत्पाद टीम को अधिक जटिल परिनियोजन परिदृश्यों की आवश्यकता होती है, लेकिन मूल छवियों का समर्थन करने के लिए ऑपरेटिंग समय को बहुत कम कर देता है, जो सौ से अधिक मूल VM छवियों पर सेवा में गिर सकता है।

इंटरनेट का इस्तेमाल

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

इन्फ्रास्ट्रक्चर एक्सेस।
डेवलपर्स तक पहुंच।

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

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

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

परिणाम

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

अलेक्जेंडर शुबीन, सिस्टम आर्किटेक्ट।

DevOps vs DevSecOps: यह एक बैंक में कैसे दिखता है