Բանկն իր նախագծերը հանձնում է բազմաթիվ կապալառուների: «Externals»-ը գրում է կոդ, այնուհետև արդյունքները փոխանցում ոչ այնքան հարմար ձևով։ Մասնավորապես, գործընթացը այսպիսի տեսք ուներ. նրանք հանձնեցին մի նախագիծ, որն իրենց հետ անցավ ֆունկցիոնալ թեստեր, այնուհետև փորձարկվեց բանկային պարագծի ներսում ինտեգրման, բեռնվածության և այլնի համար: Հաճախ պարզվում էր, որ թեստերը ձախողվում էին: Հետո ամեն ինչ վերադարձավ արտաքին մշակողին: Ինչպես կարող եք կռահել, սա նշանակում էր վրիպակների շտկման երկար ժամկետներ:
Բանկը որոշեց, որ հնարավոր է և անհրաժեշտ է ամբողջ խողովակաշարը քաշել իր թևի տակ՝ պարտավորություններից մինչև ազատում: Որպեսզի ամեն ինչ լինի միատեսակ և բանկում ապրանքի համար պատասխանատու թիմերի հսկողության ներքո։ Այսինքն՝ իբր արտաքին կապալառուն պարզապես ինչ-որ տեղ աշխատի գրասենյակի կողքի սենյակում։ Կորպորատիվ բուրգի վրա: Սա սովորական դևոպս է։
Որտեղի՞ց է հայտնվել Սեկը: Բանկի անվտանգությունը մեծ պահանջներ է դրել այն մասին, թե ինչպես կարող է արտաքին կապալառուն աշխատել ցանցի հատվածում, ինչ մուտք ունի ինչ-որ մեկը, ինչպես և ով է աշխատում կոդով: Պարզապես IB-ն դեռ չգիտեր, որ երբ կապալառուներն աշխատում են դրսում, բանկային մի քանի չափանիշներ են պահպանվում: Եվ հետո մի քանի օրից բոլորը պետք է սկսեն դիտարկել դրանք։
Պարզ բացահայտումը, որ կապալառուն լիովին հասանելի է եղել ապրանքի կոդը, արդեն շուռ էր տվել նրանց աշխարհը:
Այս պահին սկսվեց DevSecOps-ի պատմությունը, որի մասին ուզում եմ պատմել։
Ի՞նչ գործնական եզրակացություններ է արել բանկը այս իրավիճակից։
Շատ հակասություններ եղան այն մասին, որ ամեն ինչ սխալ է արվում։ Մշակողները ասացին, որ անվտանգությունը զբաղված է միայն զարգացումներին խանգարելու փորձով, և նրանք, ինչպես պահակները, փորձում են արգելել առանց մտածելու։ Իր հերթին, անվտանգության մասնագետները տատանվում էին տեսակետների միջև ընտրություն կատարելու միջև. «մշակողները խոցելիություններ են ստեղծում մեր միացումում» և «մշակողները խոցելիություններ չեն ստեղծում, այլ իրենք են»: Վեճը դեռ երկար կշարունակվեր, եթե չլինեին շուկայի նոր պահանջները և DevSecOps պարադիգմի ի հայտ գալը: Կարելի էր բացատրել, որ գործընթացների հենց այս ավտոմատացումը՝ հաշվի առնելով տեղեկատվական անվտանգության պահանջները «դուրս արկղից», կօգնի բոլորին երջանիկ մնալ։ Այն իմաստով, որ կանոնները գրվում են անմիջապես և խաղի ընթացքում չեն փոխվում (տեղեկատվական անվտանգությունը չի արգելի ինչ-որ անսպասելի բան), իսկ մշակողները տեղյակ են պահում տեղեկատվական անվտանգությանը այն ամենի մասին, ինչ տեղի է ունենում (տեղեկատվական անվտանգությունը հանկարծակի ինչ-որ բանի չի հանդիպում) . Յուրաքանչյուր թիմ նույնպես պատասխանատու է վերջնական անվտանգության համար, և ոչ թե որոշ վերացական ավագ եղբայրներ:
- Քանի որ արտաքին աշխատակիցներին արդեն հասանելի է կոդը և մի շարք ներքին համակարգեր, հավանաբար հնարավոր է փաստաթղթերից հանել «զարգացումը պետք է ամբողջությամբ իրականացվի բանկի ենթակառուցվածքի վրա» պահանջը։
- Մյուս կողմից՝ մենք պետք է ուժեղացնենք վերահսկողությունը տեղի ունեցողի նկատմամբ։
- Փոխզիջումը խաչաձև ֆունկցիոնալ թիմերի ստեղծումն էր, որտեղ աշխատակիցները սերտորեն աշխատում են արտաքին մարդկանց հետ: Այս դեպքում դուք պետք է համոզվեք, որ թիմը աշխատում է բանկի սերվերների գործիքների վրա: Սկզբից մինչև վերջ։
Այսինքն՝ կապալառուներին կարելի է ներս թողնել, բայց նրանց պետք է առանձին հատվածներ տալ։ Որպեսզի դրսից որևէ վարակ չմտցնեն բանկի ենթակառուցվածք և չտեսնեն ավելին, քան անհրաժեշտ է։ Դե, որպեսզի նրանց գործողությունները գրանցվեն: DLP արտահոսքից պաշտպանվելու համար, այս ամենը ներառված էր:
Սկզբունքորեն, բոլոր բանկերը վաղ թե ուշ գալիս են դրան: Այստեղ մենք գնացինք ծեծված ճանապարհով և պայմանավորվեցինք այնպիսի միջավայրերի համար, որտեղ «արտաքիններն» աշխատում են: Հայտնվել է մուտքի վերահսկման գործիքների առավելագույն տիրույթ, խոցելիության ստուգման գործիքներ, հակավիրուսային վերլուծություն սխեմաների, հավաքների և թեստերի վրա: Սա կոչվում է DevSecOps:
Հանկարծ պարզ դարձավ, որ եթե նախկինում DevSecOps բանկային անվտանգությունը չէր վերահսկում այն, ինչ տեղի է ունենում մշակողի կողմից, ապա նոր պարադիգմում անվտանգությունը վերահսկվում է այնպես, ինչպես սովորական իրադարձությունները ենթակառուցվածքում: Միայն հիմա ահազանգեր կան հավաքների, գրադարանների վերահսկողության և այլնի մասին։
Մնում է թիմերը տեղափոխել նոր մոդել։ Դե, ստեղծեք ենթակառուցվածքը։ Բայց սրանք մանրուքներ են, դա նման է բու նկարելու: Փաստորեն, մենք օգնեցինք ենթակառուցվածքների հարցում, և այն ժամանակ փոխվում էին զարգացման գործընթացները։
Ինչ է փոխվել
Մենք որոշեցինք դա իրականացնել փոքր քայլերով, քանի որ հասկացանք, որ շատ գործընթացներ կփլուզվեն, և շատ «արտաքիններ» կարող են չդիմանալ աշխատանքային նոր պայմաններին բոլորի հսկողության ներքո։
Նախ, մենք ստեղծեցինք բազմաֆունկցիոնալ թիմեր և սովորեցինք նախագծեր կազմակերպել՝ հաշվի առնելով նոր պահանջները: Կազմակերպչական առումով մենք քննարկել ենք, թե ինչ գործընթացներ։ Արդյունքը եղավ հավաքման խողովակաշարի դիագրամը բոլոր պատասխանատուներով:
- ՀԱՍԿԱՆԱԼԻ Է: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI:
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase:
- Test. Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama:
- Ներկայացում (զեկուցում, հաղորդակցություն). Grafana, Kibana, Jira, Confluence, RocketChat:
- Operations (սպասարկում, կառավարում). Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project:
Ընտրված բուրգ.
- Գիտելիքների բազա - Ատլասյան միացում;
- Առաջադրանքների որոնիչ - Atlassian Jira;
- Արտեֆակտի պահոց - «Nexus»;
- Շարունակական ինտեգրման համակարգ - «Gitlab CI»;
- Շարունակական վերլուծության համակարգ - «SonarQube»;
- Հավելվածի անվտանգության վերլուծության համակարգ - «Micro Focus Fortify»;
- Կապի համակարգ - «GitLab Mattermost»;
- Կազմաձևման կառավարման համակարգ - «Ansible»;
- Մոնիտորինգի համակարգ - «ELK», «TICK Stack» («InfluxData»):
Նրանք սկսեցին ստեղծել թիմ, որը պատրաստ կլինի ներս քաշել կապալառուներին: Գոյություն ունի գիտակցում, որ կան մի քանի կարևոր բաներ.
- Ամեն ինչ պետք է միասնական լինի, գոնե ծածկագիրը փոխանցելիս։ Որովհետև որքան կապալառուներ կային, այնքան տարբեր զարգացման գործընթացներ կային իրենց առանձնահատկություններով: Պետք էր բոլորին տեղավորել մոտավորապես մեկում, բայց տարբերակներով։
- Կան բազմաթիվ կապալառուներ, և ենթակառուցվածքների ձեռքով ստեղծումը հարմար չէ: Ցանկացած նոր առաջադրանք պետք է սկսվի շատ արագ, այսինքն՝ օրինակը պետք է տեղակայվի գրեթե ակնթարթորեն, որպեսզի մշակողները ունենան լուծումների մի շարք՝ իրենց խողովակաշարը կառավարելու համար:
Առաջին քայլն անելու համար պետք էր հասկանալ, թե ինչ է արվում։ Եվ մենք պետք է որոշեինք, թե ինչպես հասնել այնտեղ: Մենք սկսեցինք օգնելով գծել թիրախային լուծման ճարտարապետությունը ինչպես ենթակառուցվածքում, այնպես էլ CI/CD ավտոմատացման մեջ: Հետո մենք սկսեցինք հավաքել այս կոնվեյերը: Մեզ պետք էր մեկ ենթակառուցվածք, բոլորի համար նույնը, որտեղ կաշխատեին նույն փոխակրիչները։ Մենք հաշվարկներով տարբերակներ առաջարկեցինք, բանկը մտածեց, հետո որոշեց, թե ինչ է կառուցվելու, ինչ միջոցներով։
Հաջորդը շղթայի ստեղծումն է՝ ծրագրային ապահովման տեղադրում, կոնֆիգուրացիա։ Ենթակառուցվածքների տեղակայման և կառավարման սկրիպտների մշակում: Հաջորդը գալիս է փոխակրիչի աջակցության անցումը:
Մենք որոշեցինք ամեն ինչ փորձարկել օդաչուի վրա։ Հետաքրքիրն այն է, որ օդաչուների ժամանակ առաջին անգամ բանկում հայտնվեց որոշակի կույտ։ Ի թիվս այլ բաների, լուծումներից մեկի ներքին վաճառողն առաջարկվել է օդաչուի շրջանակի համար՝ արագ գործարկման համար: Անվտանգությունը նրան ճանաչեց օդաչու վարելիս, և դա անմոռանալի տպավորություն թողեց: Երբ մենք որոշեցինք անցնել, բարեբախտաբար, ենթակառուցվածքի շերտը փոխարինվեց Nutanix լուծույթով, որը նախկինում արդեն բանկում էր։ Ավելին, մինչ այդ դա VDI-ի համար էր, բայց մենք այն նորից օգտագործեցինք ենթակառուցվածքային ծառայությունների համար։ Փոքր ծավալներով այն չէր տեղավորվում տնտեսության մեջ, բայց մեծ ծավալներով այն հիանալի միջավայր էր դառնում զարգացման և փորձարկման համար։
Մնացած կույտը քիչ թե շատ ծանոթ է բոլորին: Ansible-ում օգտագործվել են ավտոմատացման գործիքներ, որոնց հետ սերտ համագործակցել են անվտանգության մասնագետները: Atlassin stack-ը բանկը օգտագործել է նախքան նախագիծը: Fortinet անվտանգության գործիքներ. այն առաջարկվել է հենց անվտանգության աշխատակիցների կողմից: Թեստավորման շրջանակը ստեղծվել է բանկի կողմից, հարցեր չեն տրվել: Պահեստային համակարգը հարցեր առաջացրեց, ես ստիպված էի վարժվել դրան:
Կապալառուներին տրվեց նոր փաթեթ: Նրանք մեզ ժամանակ տվեցին այն վերաշարադրելու GitlabCI-ի համար, և Ժիրային տեղափոխելու բանկային հատված և այլն:
քայլ առ քայլ
Քայլ 1. Նախ, մենք օգտագործեցինք լուծում ներքին վաճառողից, արտադրանքը միացվեց նոր ստեղծված DSO ցանցի հատվածին: Պլատֆորմն ընտրվել է իր առաքման ժամանակի, մասշտաբի ճկունության և ամբողջական ավտոմատացման հնարավորության համար: Անցկացված թեստեր.
- Վիրտուալացման հարթակի ենթակառուցվածքի (ցանց, սկավառակի ենթահամակարգ, հաշվողական ռեսուրսների ենթահամակարգ) ճկուն և լիովին ավտոմատացված կառավարման հնարավորություն։
- Վիրտուալ մեքենայի կյանքի ցիկլի կառավարման ավտոմատացում (կաղապարներ, ակնթարթներ, կրկնօրինակումներ):
Պլատֆորմի տեղադրումից և հիմնական կազմաձևումից հետո այն օգտագործվել է որպես երկրորդ փուլի ենթահամակարգերի տեղադրման կետ (DSO գործիքներ, մանրածախ համակարգերի մշակման ուրվագծեր): Ստեղծվել են խողովակաշարերի անհրաժեշտ հավաքածուներ՝ վիրտուալ մեքենաների ստեղծում, ջնջում, փոփոխում, կրկնօրինակում։ Այս խողովակաշարերն օգտագործվել են որպես տեղակայման գործընթացի առաջին փուլ:
Արդյունքն այն է, որ տրամադրված սարքավորումները չեն համապատասխանում բանկի պահանջներին աշխատանքի և սխալների հանդուրժողականության վերաբերյալ: Բանկի DIT-ը որոշել է համալիր ստեղծել Nutanix ծրագրային փաթեթի հիման վրա։
Քայլ 2. Մենք վերցրեցինք սահմանված փաթեթը և գրեցինք ավտոմատ տեղադրման և հետկոնֆիգուրացիայի սցենարներ բոլոր ենթահամակարգերի համար, որպեսզի ամեն ինչ հնարավորինս արագ տեղափոխվի օդաչուից դեպի թիրախային միացում: Բոլոր համակարգերը տեղակայվել են անսարքության հանդուրժող կազմաձևում (որտեղ այս հնարավորությունը սահմանափակված չէ վաճառողի արտոնագրման քաղաքականությամբ) և միացված է չափումների և իրադարձությունների հավաքագրման ենթահամակարգերին: IB-ն վերլուծել է իր պահանջների համապատասխանությունը և կանաչ լույս տվել:
Քայլ 3. Բոլոր ենթահամակարգերի և դրանց կարգավորումների միգրացիան դեպի նոր PAC: Ենթակառուցվածքի ավտոմատացման սցենարները վերաշարադրվել են, և DSO ենթահամակարգերի միգրացիան ավարտվել է ամբողջությամբ ավտոմատացված ռեժիմով: IP-ի զարգացման ուրվագծերը վերստեղծվել են զարգացման թիմերի խողովակաշարերի միջոցով:
Քայլ 4. Կիրառական ծրագրերի տեղադրման ավտոմատացում: Այս խնդիրները դրվել են նոր թիմերի թիմերի ղեկավարների կողմից:
Քայլ 5. Շահագործում.
Հեռավոր մուտք
Մշակող թիմերը խնդրեցին առավելագույն ճկունություն ապահովել սխեմայի հետ աշխատելիս, և անձնական նոթբուքներից հեռահար մուտքի պահանջը բարձրացվեց նախագծի հենց սկզբում: Բանկն արդեն ուներ հեռահար մուտք, բայց այն հարմար չէր ծրագրավորողների համար: Փաստն այն է, որ սխեման օգտագործում էր օգտագործողի կապը պաշտպանված VDI-ին: Սա հարմար էր նրանց համար, ովքեր իրենց աշխատավայրում միայն փոստի և գրասենյակային փաթեթի կարիք ունեն: Կառուցապատողներին պետք կգան ծանր հաճախորդներ, բարձր կատարողականություն, շատ ռեսուրսներով: Եվ, իհարկե, դրանք պետք է ստատիկ լինեին, քանի որ VStudio-ի (օրինակ) կամ այլ SDK-ի հետ աշխատողների համար օգտագործողի սեսիայի կորուստն անընդունելի է։ Բոլոր մշակողների թիմերի համար մեծ թվով հաստ ստատիկ VDI-ների կազմակերպումը մեծապես բարձրացրեց գոյություն ունեցող VDI լուծման արժեքը:
Մենք որոշեցինք աշխատել հեռահար հասանելիության վրա՝ անմիջապես զարգացման սեգմենտի ռեսուրսներին: Jira, Wiki, Gitlab, Nexus, կառուցեք և փորձարկեք նստարաններ, վիրտուալ ենթակառուցվածք: Անվտանգության աշխատակիցները պահանջել են, որ մուտքը հնարավոր լինի ապահովել միայն հետևյալի դեպքում.
- Օգտագործելով բանկում արդեն իսկ առկա տեխնոլոգիաները։
- Ենթակառուցվածքը չպետք է օգտագործի գոյություն ունեցող տիրույթի կարգավորիչներ, որոնք պահում են արտադրողական հաշվի օբյեկտների գրառումները:
- Մուտքը պետք է սահմանափակվի միայն այն ռեսուրսներով, որոնք պահանջվում են որոշակի թիմի կողմից (որպեսզի արտադրանքի մի թիմ չկարողանա մուտք գործել մեկ այլ թիմի ռեսուրսներ):
- Համակարգերում RBAC-ի նկատմամբ առավելագույն հսկողություն:
Արդյունքում այս հատվածի համար ստեղծվեց առանձին տիրույթ։ Այս տիրույթում տեղ են գտել զարգացման սեգմենտի բոլոր ռեսուրսները՝ ինչպես օգտագործողի հավատարմագրերը, այնպես էլ ենթակառուցվածքները: Այս տիրույթում գրառումների կյանքի ցիկլը կառավարվում է բանկում առկա IdM-ի միջոցով:
Ուղղակի հեռահար մուտքը կազմակերպվել է բանկի առկա սարքավորումների հիման վրա: Մուտքի վերահսկումը բաժանված էր AD խմբերի, որոնց համապատասխան էին կոնտեքստի կանոնները (մեկ ապրանքային խումբ = կանոնների մեկ խումբ):
VM Կաղապարի կառավարում
Հավաքման և փորձարկման հանգույցի ստեղծման արագությունը զարգացման ստորաբաժանման ղեկավարի կողմից սահմանված հիմնական KPI-ներից մեկն է, քանի որ միջավայրի պատրաստման արագությունն ուղղակիորեն ազդում է խողովակաշարի ընդհանուր կատարման ժամանակի վրա: Դիտարկվել է բազային VM պատկերների պատրաստման երկու տարբերակ. Առաջինը պատկերների նվազագույն չափերն են, համակարգի բոլոր ապրանքների լռելյայնությունը, կարգավորումների վերաբերյալ բանկի քաղաքականության առավելագույն համապատասխանությունը: Երկրորդը բազային պատկերն է, որը պարունակում է տեղադրված ծանր աշխատանքային POPPO, որի տեղադրման ժամանակը կարող է մեծապես ազդել խողովակաշարի կատարման արագության վրա:
Մշակման ընթացքում հաշվի են առնվել նաև ենթակառուցվածքի և անվտանգության պահանջները՝ պատկերների թարմացում (կարկատաններ և այլն), SIEM-ի հետ ինտեգրում, բանկի ստանդարտներին համապատասխան անվտանգության կարգավորումներ։
Արդյունքում որոշվեց օգտագործել մինիմալ պատկերներ՝ դրանք թարմացնելու ծախսերը նվազագույնի հասցնելու համար։ Շատ ավելի հեշտ է թարմացնել բազային ՕՀ-ն, քան POPPO-ի նոր տարբերակների համար յուրաքանչյուր պատկեր կարկատել:
Արդյունքների հիման վրա ձևավորվել է օպերացիոն համակարգերի նվազագույն պահանջվող փաթեթի ցանկը, որի թարմացումն իրականացնում է օպերացիոն թիմը, և խողովակաշարից սկրիպտներն ամբողջությամբ պատասխանատու են ծրագրաշարի թարմացման համար, իսկ անհրաժեշտության դեպքում՝ փոխել տարբերակը։ տեղադրված ծրագրաշարից - պարզապես անհրաժեշտ պիտակը փոխանցեք խողովակաշարին: Այո, սա պահանջում է devops արտադրանքի թիմից ունենալ ավելի բարդ տեղակայման սցենարներ, բայց դա զգալիորեն նվազեցնում է բազային պատկերներն աջակցելու համար պահանջվող գործառնական ժամանակը, որոնք այլ կերպ կարող են պահանջել ավելի քան հարյուր բազային VM պատկերներ պահպանման համար:
Մուտք դեպի ինտերնետ
Բանկային անվտանգության մյուս խոչընդոտը զարգացման միջավայրից ինտերնետ ռեսուրսների հասանելիությունն էր: Ավելին, այս մուտքը կարելի է բաժանել երկու կատեգորիայի.
- Ենթակառուցվածքի հասանելիություն.
- Մշակողի մուտք:
Ենթակառուցվածքի հասանելիությունը կազմակերպվել է Nexus-ի միջոցով արտաքին պահոցների միջնորդությամբ: Այսինքն՝ վիրտուալ մեքենաներից ուղղակի մուտք չի ապահովվել։ Սա հնարավորություն տվեց փոխզիջման հասնել տեղեկատվական անվտանգության հետ, որը կտրականապես դեմ էր զարգացման սեգմենտից արտաքին աշխարհ ցանկացած մուտք ապահովելուն։
Հասկանալի պատճառներով ծրագրավորողներին անհրաժեշտ էր մուտք գործել ինտերնետ (stackoverflow): Եվ չնայած բոլոր հրամանները, ինչպես նշվեց վերևում, ունեին հեռավոր մուտք դեպի շղթա, միշտ չէ, որ հարմար է, երբ դուք չեք կարող IDE-ում բանկում մշակողի աշխատավայրից կատարել ctrl+v:
ԻՊ-ի հետ պայմանավորվածություն է ձեռք բերվել, որ ի սկզբանե, թեստավորման փուլում, մուտքը կտրամադրվի բանկային վստահված անձի միջոցով՝ հիմնված սպիտակ ցուցակի վրա։ Ծրագրի ավարտից հետո մուտքը կտեղափոխվի սև ցուցակ: Պատրաստվեցին մուտքի հսկայական աղյուսակներ, որոնք ցույց էին տալիս հիմնական ռեսուրսները և պահեստները, որոնց մուտքն անհրաժեշտ էր ծրագրի սկզբում: Այս մուտքերի համակարգումը բավականին ժամանակ պահանջեց, ինչը հնարավորություն տվեց պնդել հնարավորինս արագ անցում դեպի սև ցուցակներ:
Արդյունքները
Նախագիծն ավարտվեց մեկ տարի առաջ։ Տարօրինակ կերպով, բոլոր կապալառուները ժամանակին անցան նոր փաթեթին, և ոչ ոք չհեռացավ նոր ավտոմատացման պատճառով: IB-ն չի շտապում կիսվել դրական արձագանքներով, սակայն չի էլ դժգոհում, որից կարելի է եզրակացնել, որ դա նրանց դուր է գալիս։ Հակամարտությունները թուլացել են, քանի որ տեղեկատվական անվտանգությունը կրկին իրեն զգում է վերահսկողության տակ, բայց չի խանգարում զարգացման գործընթացներին: Թիմերին տրվեց ավելի մեծ պատասխանատվություն, և ընդհանուր վերաբերմունքը տեղեկատվական անվտանգության նկատմամբ ավելի լավացավ։ Բանկը հասկացավ, որ DevSecOps-ին անցումը գրեթե անխուսափելի էր, և դա արեց, իմ կարծիքով, ամենանուրբ և ճիշտ ձևով։
Ալեքսանդր Շուբին, համակարգի ճարտարապետ.
Source: www.habr.com