DevOps vs DevSecOps: एका बँकेत ते कसे दिसते

बँक अनेक कंत्राटदारांना आपले प्रकल्प आउटसोर्स करते. "बाह्य" कोड लिहा, नंतर परिणाम अतिशय सोयीस्कर नसलेल्या स्वरूपात प्रसारित करा. विशेषतः, प्रक्रिया यासारखी दिसली: त्यांनी एक प्रकल्प सोपविला ज्याने त्यांच्यासह कार्यात्मक चाचण्या उत्तीर्ण केल्या आणि नंतर बँकिंग परिमितीमध्ये एकत्रीकरण, भार इत्यादीसाठी चाचणी केली गेली. चाचण्या अयशस्वी होत असल्याचे अनेकदा आढळून आले. मग सर्व काही बाह्य विकसकाकडे परत गेले. जसे तुम्ही अंदाज लावू शकता, याचा अर्थ बग फिक्ससाठी दीर्घ लीड टाइम्स होता.

बँकेने ठरवले की कमिटपासून रिलीझपर्यंत संपूर्ण पाइपलाइन तिच्या पंखाखाली ड्रॅग करणे शक्य आणि आवश्यक आहे. जेणेकरून सर्व काही एकसमान असेल आणि बँकेतील उत्पादनासाठी जबाबदार असलेल्या संघांच्या नियंत्रणाखाली असेल. म्हणजे जणू काही बाहेरचा ठेकेदार ऑफिसच्या पुढच्या खोलीत कुठेतरी काम करत होता. कॉर्पोरेट स्टॅकवर. हे एक सामान्य डेव्हॉप्स आहे.

सेक कुठून आला? बँकेच्या सुरक्षेने नेटवर्क सेगमेंटमध्ये बाह्य कंत्राटदार कसे कार्य करू शकतो, कोणाकडे कोणता प्रवेश आहे, कोडसह कसे आणि कोण कार्य करते यावर उच्च मागण्या केल्या आहेत. कंत्राटदार बाहेर काम करतात तेव्हा काही बँकिंग मानकांचे पालन केले जाते हे IB ला अद्याप माहित नव्हते. आणि मग काही दिवसात प्रत्येकाने त्यांचे निरीक्षण करणे सुरू केले पाहिजे.

कॉन्ट्रॅक्टरला उत्पादन कोडमध्ये पूर्ण प्रवेश होता या साध्या प्रकटीकरणाने त्यांचे जग आधीच उलथून टाकले होते.

या क्षणी, DevSecOps ची कथा सुरू झाली, ज्याबद्दल मी तुम्हाला सांगू इच्छितो.

या परिस्थितीतून बँकेने कोणते व्यावहारिक निष्कर्ष काढले?

सर्व काही चुकीच्या पद्धतीने केले जात असल्याबद्दल बराच वाद झाला होता. विकासकांनी सांगितले की सुरक्षा केवळ विकासात व्यत्यय आणण्याच्या प्रयत्नात व्यस्त आहे आणि ते वॉचमनप्रमाणे विचार न करता मनाई करण्याचा प्रयत्न करतात. या बदल्यात, सुरक्षा तज्ञांनी या दृष्टिकोनातून निवड करताना संकोच केला: "विकासक आमच्या सर्किटमध्ये असुरक्षा निर्माण करतात" आणि "विकासक असुरक्षा निर्माण करत नाहीत, परंतु ते स्वतःच असतात." बाजारातील नवीन मागणी आणि DevSecOps प्रतिमान उदयास आले नसते तर हा वाद बराच काळ चालू राहिला असता. हे समजावून सांगणे शक्य होते की माहिती सुरक्षा आवश्यकता लक्षात घेऊन प्रक्रियांचे हे ऑटोमेशन “बॉक्सच्या बाहेर” सर्वांना आनंदी राहण्यास मदत करेल. या अर्थाने की नियम ताबडतोब लिहून ठेवले जातात आणि गेम दरम्यान बदलत नाहीत (माहिती सुरक्षा अनपेक्षितपणे काहीतरी प्रतिबंधित करणार नाही), आणि विकासक जे काही घडते त्याबद्दल माहिती सुरक्षिततेची माहिती ठेवतात (माहिती सुरक्षा अचानक काहीतरी आढळत नाही) . प्रत्येक संघ अंतिम सुरक्षिततेसाठी देखील जबाबदार आहे, आणि काही अमूर्त वृद्ध भाऊ नाही.

1. बाह्य कर्मचाऱ्यांना आधीपासूनच कोड आणि अनेक अंतर्गत प्रणालींमध्ये प्रवेश असल्याने, "विकास पूर्णपणे बँकेच्या पायाभूत सुविधांवर केला पाहिजे" ही आवश्यकता कागदपत्रांमधून काढून टाकणे शक्य आहे.
2. दुसरीकडे, जे घडत आहे त्यावर नियंत्रण मजबूत करणे आवश्यक आहे.
3. तडजोड क्रॉस-फंक्शनल टीम्सची निर्मिती होती, जिथे कर्मचारी बाह्य लोकांशी जवळून काम करतात. या प्रकरणात, तुम्हाला हे सुनिश्चित करणे आवश्यक आहे की कार्यसंघ बँकेच्या सर्व्हरवरील साधनांवर कार्य करतो. सुरुवातीपासून शेवटपर्यंत.

म्हणजेच, कंत्राटदारांना परवानगी दिली जाऊ शकते, परंतु त्यांना स्वतंत्र विभाग देणे आवश्यक आहे. जेणेकरून ते बँकेच्या पायाभूत सुविधांमध्ये बाहेरून काही प्रकारचे संक्रमण आणू नयेत आणि जेणेकरुन त्यांना आवश्यकतेपेक्षा जास्त दिसत नाही. बरं, जेणेकरून त्यांच्या कृती लॉग केल्या जातील. लीकपासून संरक्षणासाठी डीएलपी, हे सर्व समाविष्ट होते.

तत्वतः, सर्व बँका या लवकर किंवा नंतर येतात. येथे आम्ही मारलेल्या ट्रॅकवर गेलो आणि अशा वातावरणाच्या आवश्यकतांवर सहमत झालो जिथे "बाह्य" कार्य करतात. प्रवेश नियंत्रण साधने, असुरक्षा तपासण्याची साधने, सर्किट्स, असेंब्ली आणि चाचण्यांवरील अँटी-व्हायरस विश्लेषणाची कमाल श्रेणी दिसून आली. याला DevSecOps म्हणतात.

अचानक हे स्पष्ट झाले की जर DevSecOps पूर्वी बँकिंग सुरक्षेवर विकासकाच्या बाजूने काय घडते यावर कोणतेही नियंत्रण नसेल, तर नवीन प्रतिमानात सुरक्षा पायाभूत सुविधांवरील सामान्य घटनांप्रमाणेच नियंत्रित केली जाते. फक्त आता असेंब्ली, लायब्ररींवर नियंत्रण वगैरे सूचना आहेत.

संघांना नवीन मॉडेलमध्ये हस्तांतरित करणे बाकी आहे. बरं, पायाभूत सुविधा निर्माण करा. पण या क्षुल्लक गोष्टी आहेत, हे उल्लू काढण्यासारखे आहे. वास्तविक, आम्ही पायाभूत सुविधांसाठी मदत केली आणि त्या वेळी विकास प्रक्रिया बदलत होत्या.

काय बदलले आहे

आम्ही लहान चरणांमध्ये ते अंमलात आणण्याचा निर्णय घेतला, कारण आम्हाला समजले की अनेक प्रक्रिया विस्कळीत होतील आणि अनेक "बाह्य" प्रत्येकाच्या देखरेखीखाली नवीन कार्य परिस्थितीचा सामना करू शकत नाहीत.

प्रथम, आम्ही क्रॉस-फंक्शनल टीम तयार केल्या आणि नवीन आवश्यकता लक्षात घेऊन प्रकल्प आयोजित करण्यास शिकलो. संघटनात्मक अर्थाने आम्ही कोणत्या प्रक्रियांवर चर्चा केली. परिणाम सर्व जबाबदार लोकांसह असेंब्ली पाइपलाइनचा आराखडा होता.

• सीआय: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
• CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
• चाचणीः Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Atacama.
• सादरीकरण (रिपोर्टिंग, कम्युनिकेशन): ग्राफना, किबाना, जिरा, संगम, रॉकेटचॅट.
• ऑपरेशन (देखभाल, व्यवस्थापन): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF सेवा व्यवस्थापक, Jira, Confluence, MS Project.

निवडलेला स्टॅक:

• नॉलेज बेस - अटलासियन संगम;
• टास्क ट्रॅकर - अटलासियन जिरा;
• आर्टिफॅक्ट रेपॉजिटरी - "नेक्सस";
• सतत एकीकरण प्रणाली - "गिटलॅब सीआय";
• सतत विश्लेषण प्रणाली - "सोनारक्यूब";
• अनुप्रयोग सुरक्षा विश्लेषण प्रणाली - "मायक्रो फोकस फोर्टीफाय";
• कम्युनिकेशन सिस्टम - "गिटलॅब मॅटरमोस्ट";
• कॉन्फिगरेशन व्यवस्थापन प्रणाली - "जवाब";
• मॉनिटरिंग सिस्टम - “ELK”, “टिक स्टॅक” (“InfluxData”).

त्यांनी एक संघ तयार करण्यास सुरुवात केली जी कंत्राटदारांना आत ओढण्यासाठी तयार असेल. तेथे अनेक महत्त्वाच्या गोष्टी आहेत याची जाणीव आहे:

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

पहिले पाऊल उचलण्यासाठी, काय केले जात आहे हे समजून घेणे आवश्यक होते. आणि तिथे कसे जायचे हे ठरवायचे होते. आम्ही पायाभूत सुविधा आणि CI/CD ऑटोमेशन या दोन्हीमध्ये लक्ष्य समाधानाची आर्किटेक्चर काढण्यास मदत करून सुरुवात केली. मग आम्ही हे कन्व्हेयर असेंबल करायला सुरुवात केली. आम्हाला एक पायाभूत सुविधा आवश्यक आहे, प्रत्येकासाठी समान, जिथे समान कन्व्हेयर चालतील. आम्ही गणनेसह पर्याय ऑफर केले, बँकेने विचार केला, मग काय बांधले जाईल आणि कोणत्या निधीसह ते ठरवले.

पुढे सर्किटची निर्मिती आहे - सॉफ्टवेअरची स्थापना, कॉन्फिगरेशन. पायाभूत सुविधांच्या उपयोजन आणि व्यवस्थापनासाठी स्क्रिप्टचा विकास. पुढे कन्व्हेयर सपोर्टचे संक्रमण होते.

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

बाकीचे स्टॅक प्रत्येकाला कमी-अधिक प्रमाणात परिचित आहेत. Ansible मधील ऑटोमेशन साधने वापरली गेली आणि सुरक्षा तज्ञांनी त्यांच्याशी जवळून काम केले. ॲटलासिन स्टॅकचा वापर बँकेने प्रकल्पापूर्वी केला होता. फोर्टिनेट सुरक्षा साधने - हे स्वतः सुरक्षा लोकांनी प्रस्तावित केले होते. चाचणी फ्रेम बँकेने तयार केली आहे, कोणतेही प्रश्न विचारले नाहीत. रिपॉझिटरी सिस्टमने प्रश्न उपस्थित केले होते;

कंत्राटदारांना नवीन गाळे देण्यात आले. त्यांनी आम्हाला ते GitlabCI साठी पुन्हा लिहिण्यासाठी आणि जिराला बँकिंग विभागात स्थलांतरित करण्यासाठी वेळ दिला.

क्रमाक्रमाने

स्टेज एक्सएनयूएमएक्स. प्रथम, आम्ही घरगुती विक्रेत्याकडून एक उपाय वापरला, उत्पादन नवीन तयार केलेल्या DSO नेटवर्क विभागाशी जोडले गेले. प्लॅटफॉर्म त्याची वितरण वेळ, स्केलिंग लवचिकता आणि पूर्ण ऑटोमेशनच्या शक्यतेसाठी निवडले गेले. आयोजित केलेल्या चाचण्या:

• व्हर्च्युअलायझेशन प्लॅटफॉर्म इन्फ्रास्ट्रक्चर (नेटवर्क, डिस्क सबसिस्टम, संगणकीय संसाधन उपप्रणाली) च्या लवचिक आणि पूर्णपणे स्वयंचलित व्यवस्थापनाची शक्यता.
• जीवनचक्र व्यवस्थापनाचे ऑटोमेशन व्हर्च्युअल मशीन्स (टेम्पलेट्स, स्नॅपशॉट्स, बॅकअप्स).

प्लॅटफॉर्मच्या स्थापनेनंतर आणि मूलभूत कॉन्फिगरेशननंतर, ते दुसऱ्या टप्प्यातील उपप्रणाली (DSO टूल्स, रिटेल सिस्टम्स डेव्हलपमेंट बाह्यरेखा) च्या प्लेसमेंटचा बिंदू म्हणून वापरले गेले. पाइपलाइनचे आवश्यक संच तयार केले गेले - व्हर्च्युअल मशीनची निर्मिती, हटवणे, बदल, बॅकअप. या पाइपलाइनचा वापर तैनाती प्रक्रियेचा पहिला टप्पा म्हणून करण्यात आला.

याचा परिणाम असा होतो की प्रदान केलेली उपकरणे कार्यक्षमतेसाठी आणि दोष सहिष्णुतेसाठी बँकेच्या आवश्यकतांची पूर्तता करत नाहीत. बँकेच्या DIT ने Nutanix सॉफ्टवेअर पॅकेजवर आधारित कॉम्प्लेक्स तयार करण्याचा निर्णय घेतला.

स्टेज 2. आम्ही परिभाषित केलेला स्टॅक घेतला आणि सर्व उपप्रणालींसाठी स्वयंचलित स्थापना आणि पोस्ट-कॉन्फिगरेशन स्क्रिप्ट्स लिहिल्या जेणेकरून सर्व काही शक्य तितक्या लवकर पायलटकडून लक्ष्य सर्किटमध्ये हस्तांतरित केले जाईल. सर्व प्रणाली दोष-सहिष्णु कॉन्फिगरेशनमध्ये तैनात केल्या गेल्या होत्या (जेथे ही क्षमता विक्रेत्याच्या परवाना धोरणांद्वारे मर्यादित नाही) आणि मेट्रिक्स आणि इव्हेंट संकलन उपप्रणालींशी कनेक्ट केली गेली. IB ने त्याच्या आवश्यकतांच्या पूर्ततेचे विश्लेषण केले आणि हिरवा कंदील दिला.

स्टेज 3. नवीन PAC मध्ये सर्व उपप्रणाली आणि त्यांची सेटिंग्जचे स्थलांतर. इन्फ्रास्ट्रक्चर ऑटोमेशन स्क्रिप्ट पुन्हा लिहिल्या गेल्या आणि DSO उपप्रणालींचे स्थलांतर पूर्णपणे स्वयंचलित मोडमध्ये पूर्ण झाले. विकास संघांच्या पाइपलाइनद्वारे IP विकासाचे रूपरेषा पुन्हा तयार करण्यात आली.

स्टेज एक्सएनयूएमएक्स. ऍप्लिकेशन सॉफ्टवेअर इंस्टॉलेशनचे ऑटोमेशन. ही कार्ये नवीन संघांच्या टीम लीडने सेट केली होती.

स्टेज एक्सएनयूएमएक्स. शोषण.

दूरस्थ प्रवेश

विकास कार्यसंघांनी सर्किटसह काम करताना जास्तीत जास्त लवचिकता मागितली आणि प्रकल्पाच्या अगदी सुरुवातीस वैयक्तिक लॅपटॉपवरून रिमोट ऍक्सेसची आवश्यकता वाढवली गेली. बँकेकडे आधीपासूनच रिमोट ऍक्सेस होता, परंतु ते विकसकांसाठी योग्य नव्हते. वस्तुस्थिती अशी आहे की योजनेने वापरकर्त्याचे कनेक्शन संरक्षित व्हीडीआयशी वापरले. ज्यांना त्यांच्या कामाच्या ठिकाणी फक्त मेल आणि ऑफिस पॅकेजची गरज होती त्यांच्यासाठी हे योग्य होते. विकसकांना भरपूर संसाधनांसह भारी क्लायंट, उच्च कार्यक्षमतेची आवश्यकता असेल. आणि अर्थातच, ते स्थिर असले पाहिजेत, कारण जे VStudio (उदाहरणार्थ) किंवा इतर SDK सह काम करतात त्यांच्यासाठी वापरकर्ता सत्र गमावणे अस्वीकार्य आहे. सर्व डेव्हलपमेंट टीम्ससाठी मोठ्या प्रमाणात जाड स्टॅटिक व्हीडीआय आयोजित केल्याने सध्याच्या व्हीडीआय सोल्यूशनची किंमत मोठ्या प्रमाणात वाढली आहे.

आम्ही थेट विकास विभागाच्या संसाधनांपर्यंत दूरस्थ प्रवेशावर काम करण्याचा निर्णय घेतला. जिरा, विकी, गिटलॅब, नेक्सस, बनवा आणि चाचणी बेंच, आभासी पायाभूत सुविधा. सुरक्षा रक्षकांनी मागणी केली आहे की प्रवेश फक्त खालील गोष्टींच्या अधीन आहे:

1. बँकेत आधीच उपलब्ध असलेल्या तंत्रज्ञानाचा वापर करणे.
2. पायाभूत सुविधांनी विद्यमान वापरू नये डोमेनउत्पादक लेखांकन वस्तूंच्या नोंदी साठवणारे नियंत्रक.
3. प्रवेश केवळ विशिष्ट संघाला आवश्यक असलेल्या संसाधनांपुरता मर्यादित असावा (जेणेकरून एक उत्पादन संघ दुसऱ्या संघाच्या संसाधनांमध्ये प्रवेश करू शकत नाही).
4. सिस्टममध्ये RBAC वर जास्तीत जास्त नियंत्रण.

परिणामी, या विभागासाठी स्वतंत्र डोमेन तयार केले गेले. या डोमेनमध्ये सर्व विकास विभाग संसाधने, वापरकर्ता क्रेडेन्शियल आणि पायाभूत सुविधा दोन्ही आहेत. या डोमेनमधील रेकॉर्डचे जीवनचक्र बँकेत विद्यमान आयडीएम वापरून व्यवस्थापित केले जाते.

बँकेच्या विद्यमान उपकरणांच्या आधारे थेट दूरस्थ प्रवेश आयोजित केला गेला. प्रवेश नियंत्रण AD गटांमध्ये विभागले गेले होते, ज्याच्याशी संबंधित नियम (एक उत्पादन गट = नियमांचा एक गट).

VM टेम्पलेट व्यवस्थापन

असेंब्ली आणि टेस्टिंग लूप तयार करण्याची गती ही विकास युनिटच्या प्रमुखाने सेट केलेल्या मुख्य केपीआयपैकी एक आहे, कारण वातावरण तयार करण्याची गती थेट पाइपलाइनच्या एकूण अंमलबजावणीच्या वेळेवर परिणाम करते. बेस VM प्रतिमा तयार करण्यासाठी दोन पर्यायांचा विचार करण्यात आला. प्रथम किमान प्रतिमा आकार, सर्व सिस्टम उत्पादनांसाठी डीफॉल्ट, सेटिंग्जशी संबंधित बँकेच्या धोरणांचे कमाल अनुपालन. दुसरी मूळ प्रतिमा आहे, ज्यामध्ये हेवी-ड्यूटी POPPO स्थापित आहे, ज्याची स्थापना वेळ पाइपलाइनच्या अंमलबजावणीच्या गतीवर मोठ्या प्रमाणात प्रभाव टाकू शकते.

विकासादरम्यान पायाभूत सुविधा आणि सुरक्षा आवश्यकता देखील विचारात घेतल्या गेल्या - प्रतिमा अद्ययावत ठेवणे (पॅच इ.), SIEM सह एकत्रीकरण, बँक मानकांनुसार सुरक्षा सेटिंग्ज.

परिणामी, त्यांना अद्ययावत ठेवण्याचा खर्च कमी करण्यासाठी किमान प्रतिमा वापरण्याचा निर्णय घेण्यात आला. POPPO च्या नवीन आवृत्त्यांसाठी प्रत्येक इमेज पॅच करण्यापेक्षा बेस OS अपडेट करणे खूप सोपे आहे.

परिणामांवर आधारित, ऑपरेटिंग सिस्टमच्या किमान आवश्यक संचाची एक सूची तयार केली गेली, ज्याचे अद्यतन ऑपरेशन टीमद्वारे केले जाते आणि पाइपलाइनच्या स्क्रिप्ट्स सॉफ्टवेअर अद्यतनित करण्यासाठी पूर्णपणे जबाबदार आहेत आणि आवश्यक असल्यास, आवृत्ती बदला. स्थापित सॉफ्टवेअरचे - फक्त आवश्यक टॅग पाइपलाइनवर हस्तांतरित करा. होय, यासाठी devops उत्पादन कार्यसंघाकडे अधिक जटिल परियोजन परिस्थिती असणे आवश्यक आहे, परंतु हे बेस प्रतिमांना समर्थन देण्यासाठी आवश्यक ऑपरेशनल वेळ मोठ्या प्रमाणात कमी करते, जे अन्यथा राखण्यासाठी शंभरपेक्षा जास्त बेस VM प्रतिमा आवश्यक असू शकतात.

इंटरनेटवर प्रवेश

बँकिंग सुरक्षेतील आणखी एक अडसर म्हणजे विकासाच्या वातावरणातून इंटरनेट संसाधनांचा प्रवेश. शिवाय, हा प्रवेश दोन श्रेणींमध्ये विभागला जाऊ शकतो:

1. पायाभूत सुविधांमध्ये प्रवेश.
2. विकसक प्रवेश.

Nexus सह बाह्य रिपॉझिटरीज प्रॉक्सी करून इन्फ्रास्ट्रक्चर ऍक्सेस आयोजित केले होते. म्हणजेच, व्हर्च्युअल मशिन्समधून थेट प्रवेश प्रदान केला गेला नाही. यामुळे माहिती सुरक्षेशी तडजोड करणे शक्य झाले, जे विकास विभागातून बाहेरील जगामध्ये प्रवेश देण्याच्या विरुद्ध होते.

विकसकांना स्पष्ट कारणांसाठी (स्टॅकओव्हरफ्लो) इंटरनेटवर प्रवेश आवश्यक होता. आणि जरी वर नमूद केल्याप्रमाणे सर्व कमांड्सना सर्किटमध्ये रिमोट ऍक्सेस होता, तरीही जेव्हा तुम्ही IDE मधील बँकेतील डेव्हलपरच्या कामाच्या ठिकाणी ctrl+v करू शकत नाही तेव्हा ते नेहमीच सोयीचे नसते.

IS सोबत एक करार झाला की सुरुवातीला, चाचणी टप्प्यावर, व्हाईट-लिस्टवर आधारित बँकिंग प्रॉक्सीद्वारे प्रवेश प्रदान केला जाईल. प्रकल्प पूर्ण झाल्यावर, प्रवेश काळ्या-सूचीमध्ये हस्तांतरित केला जाईल. प्रचंड प्रवेश तक्ते तयार करण्यात आली होती, जी मुख्य संसाधने आणि भांडार दर्शवितात ज्यात प्रकल्पाच्या सुरूवातीस प्रवेश आवश्यक होता. या ॲक्सेसेसचे समन्वय साधण्यासाठी बराच वेळ लागला, ज्यामुळे ब्लॅकलिस्टमध्ये शक्य तितक्या जलद संक्रमणासाठी आग्रह धरणे शक्य झाले.

निकाल

हा प्रकल्प वर्षभरापूर्वीच संपला. विचित्रपणे, सर्व कंत्राटदारांनी वेळेवर नवीन स्टॅकवर स्विच केले आणि नवीन ऑटोमेशनमुळे कोणीही सोडले नाही. IB सकारात्मक अभिप्राय शेअर करण्याची घाई करत नाही, परंतु तक्रारही करत नाही, ज्यावरून आम्ही असा निष्कर्ष काढू शकतो की त्यांना ते आवडते. संघर्ष कमी झाला आहे कारण माहिती सुरक्षा पुन्हा नियंत्रणात आहे, परंतु विकास प्रक्रियेत व्यत्यय आणत नाही. संघांना अधिक जबाबदारी देण्यात आली आणि माहितीच्या सुरक्षेबद्दलचा एकूण दृष्टिकोन अधिक चांगला झाला. बँकेला समजले की DevSecOps मध्ये संक्रमण जवळजवळ अपरिहार्य आहे आणि माझ्या मते, सर्वात सभ्य आणि योग्य मार्गाने केले.

अलेक्झांडर शुबिन, सिस्टम आर्किटेक्ट.

स्त्रोत: www.habr.com