Bankas savo projektus perduoda daugeliui rangovų. „Išoriniai“ rašo kodą, tada perduoda rezultatus nelabai patogia forma. Konkrečiai, procesas atrodė taip: jie perdavė projektą, kuris kartu su jais išlaikė funkcinius testus, o tada buvo išbandytas bankininkystės perimetro viduje dėl integracijos, apkrovos ir pan. Dažnai buvo nustatyta, kad bandymai buvo nesėkmingi. Tada viskas grįžo į išorinį kūrėją. Kaip galite atspėti, tai reiškė ilgą klaidų taisymo laiką.
Bankas nusprendė, kad galima ir būtina po savo sparnu tempti visą dujotiekį – nuo įsipareigojimų iki paleidimo. Kad viskas būtų vienoda ir būtų kontroliuojama komandų, atsakingų už produktą banke. Tai yra, tarsi išorės rangovas tiesiog dirbtų kažkur kitame biuro kambaryje. Ant įmonės krūvos. Tai eilinis devops.
Iš kur atsirado Sekas? Banko saugumas iškėlė aukštus reikalavimus, kaip išorinis rangovas gali dirbti tinklo segmente, kokią prieigą kažkas turi, kaip ir kas dirba su kodu. Tiesiog IB dar nežinojo, kad kai rangovai dirba lauke, laikomasi nedaug bankininkystės standartų. Ir tada po poros dienų visi turi pradėti juos stebėti.
Paprastas apreiškimas, kad rangovas turėjo visišką prieigą prie produkto kodo, jau apvertė jų pasaulį aukštyn kojomis.
Šiuo metu prasidėjo DevSecOps istorija, apie kurią noriu papasakoti.
Kokias praktines išvadas bankas padarė iš šios situacijos?
Daug ginčų kilo dėl to, kad viskas daroma ne taip. Kūrėjai teigė, kad saugumas užsiima tik bandymu trukdyti plėtrai, o jie, kaip ir budėtojai, negalvodami bando uždrausti. Savo ruožtu saugumo specialistai dvejojo, ar rinktis vieną iš požiūrių: „kūrėjai sukuria pažeidžiamumą mūsų grandinėje“ ir „kūrėjai nekuria pažeidžiamumų, o yra jie patys“. Ginčas būtų tęsiamas ilgą laiką, jei ne nauji rinkos poreikiai ir DevSecOps paradigmos atsiradimas. Buvo galima paaiškinti, kad būtent toks procesų automatizavimas atsižvelgiant į informacijos saugumo reikalavimus „iš dėžės“ padės visiems likti laimingiems. Ta prasme, kad taisyklės užrašomos iš karto ir nesikeičia žaidimo metu (informacijos saugumas ko nors netikėtai neuždraus), o kūrėjai informuoja informacijos saugumą apie viską, kas vyksta (informacijos saugumas su kažkuo nesusiduria staiga) . Kiekviena komanda taip pat yra atsakinga už maksimalų saugumą, o ne kokie nors abstraktūs vyresni broliai.
- Kadangi išoriniai darbuotojai jau turi prieigą prie kodo ir daugybės vidinių sistemų, tikriausiai galima iš dokumentų pašalinti reikalavimą „plėtra turi būti vykdoma tik banko infrastruktūroje“.
- Kita vertus, turime stiprinti kontrolę to, kas vyksta.
- Kompromisas buvo tarpfunkcinių komandų, kuriose darbuotojai glaudžiai bendradarbiauja su išorės žmonėmis, sukūrimas. Tokiu atveju turite įsitikinti, kad komanda dirba su įrankiais banko serveriuose. Nuo pradžios iki galo.
Tai yra, rangovus galima įleisti, bet jiems reikia skirti atskirus segmentus. Kad jie neįneštų kažkokios infekcijos iš išorės į banko infrastruktūrą ir kad nepamatytų daugiau nei reikia. Na, kad jų veiksmai būtų registruojami. DLP apsaugai nuo nutekėjimo, visa tai buvo įtraukta.
Iš esmės visi bankai anksčiau ar vėliau prie to ateina. Čia nuėjome pramintu keliu ir susitarėme dėl reikalavimų tokioms aplinkoms, kuriose veikia „išorės“. Atsirado maksimalus prieigos kontrolės įrankių asortimentas, pažeidžiamumo tikrinimo įrankiai, antivirusinė grandinių, mazgų ir testų analizė. Tai vadinama DevSecOps.
Staiga paaiškėjo, kad jei iki DevSecOps bankininkystės saugumas nekontroliavo to, kas vyksta kūrėjo pusėje, tai naujojoje paradigmoje saugumas kontroliuojamas taip pat, kaip ir įprasti įvykiai infrastruktūroje. Tik dabar yra perspėjimai apie surinkimus, bibliotekų valdymą ir pan.
Belieka komandas perkelti į naują modelį. Na, sukurkite infrastruktūrą. Bet tai smulkmenos, tai tarsi pelėdos piešimas. Tiesą sakant, padėjome su infrastruktūra, o tuo metu keitėsi plėtros procesai.
Kas pasikeitė
Nusprendėme tai įgyvendinti mažais žingsneliais, nes supratome, kad daugelis procesų subyrės, o daugelis „išorinių“ gali neatlaikyti naujų darbo sąlygų visiems prižiūrimi.
Pirmiausia sukūrėme daugiafunkcines komandas ir išmokome organizuoti projektus atsižvelgdami į naujus reikalavimus. Organizacine prasme aptarėme kokius procesus. Rezultatas buvo surinkimo vamzdyno schema su visais atsakingais asmenimis.
- PI: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- Kompaktinių diskų: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Testas: Sonarqube, SoapUI, jMeter, Selenas: MF Fortify, Performance Center, MF UFT, Ataccama.
- pristatymas (ataskaitų teikimas, bendravimas): Grafana, Kibana, Jira, Confluence, RocketChat.
- operacijos (priežiūra, valdymas): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Pasirinktas krūvas:
- Žinių bazė – Atlassian Confluence;
- Užduočių sekimo priemonė – Atlassian Jira;
- Artefaktų saugykla - „Nexus“;
- Nuolatinio integravimo sistema - „Gitlab CI“;
- Nuolatinės analizės sistema – „SonarQube“;
- Programų saugumo analizės sistema – „Micro Focus Fortify“;
- Ryšių sistema - „GitLab Mattermost“;
- Konfigūracijos valdymo sistema - „Ansible“;
- Stebėjimo sistema – „ELK“, „TICK Stack“ („InfluxData“).
Jie pradėjo kurti komandą, kuri būtų pasirengusi tempti rangovus į vidų. Suvokiama, kad yra keletas svarbių dalykų:
- Viskas turėtų būti suvienodinta, bent jau perduodant kodą. Nes rangovų buvo tiek, kiek įvairių plėtros procesų su savo ypatumais. Reikėjo visus sutalpinti maždaug į vieną, bet su pasirinkimais.
- Rangovų daug, rankiniu būdu infrastruktūros kūrimas netinka. Bet kokia nauja užduotis turėtų prasidėti labai greitai – tai yra, egzempliorius turėtų būti įdiegtas beveik akimirksniu, kad kūrėjai turėtų sprendimų rinkinį savo konvejeriui valdyti.
Norint žengti pirmąjį žingsnį, reikėjo suprasti, kas daroma. Ir mes turėjome nuspręsti, kaip ten patekti. Pradėjome padėdami nubraižyti tikslinio sprendimo architektūrą tiek infrastruktūroje, tiek CI/CD automatizavime. Tada pradėjome montuoti šį konvejerį. Reikėjo vienos infrastruktūros, visiems vienodos, kur važiuotų tie patys konvejeriai. Pasiūlėme variantus su skaičiavimais, pagalvojo bankas, tada sprendė, kas ir už kokias lėšas bus statoma.
Kitas yra grandinės sukūrimas - programinės įrangos įdiegimas, konfigūravimas. Infrastruktūros diegimo ir valdymo scenarijų kūrimas. Kitas ateina perėjimas prie konvejerio palaikymo.
Nusprendėme viską išbandyti pilote. Įdomu tai, kad pilotavimo metu pirmą kartą banke atsirado tam tikras krūvas. Be kita ko, vieno iš sprendimų vietiniam pardavėjui buvo pasiūlytas bandomasis greitas paleidimas. Apsauga jį pažino pilotuojant, ir tai paliko nepamirštamą įspūdį. Kai nusprendėme pakeisti, laimei, infrastruktūros sluoksnis buvo pakeistas Nutanix sprendimu, kuris jau buvo banke. Be to, prieš tai jis buvo skirtas VDI, bet mes vėl panaudojome infrastruktūros paslaugoms. Mažais kiekiais jis netilpo į ekonomiką, tačiau dideliais kiekiais tapo puikia aplinka plėtrai ir bandymams.
Likusi krūva yra daugiau ar mažiau žinoma visiems. Buvo naudojami Ansible automatizavimo įrankiai, su jais glaudžiai bendradarbiavo saugos specialistai. „Atlassin stack“ bankas naudojosi prieš įgyvendindamas projektą. Fortinet saugumo įrankiai – tai pasiūlė patys apsaugos žmonės. Testavimo rėmelį sukūrė bankas, klausimų neužduota. Saugyklų sistema kėlė klausimų, turėjau prie jos priprasti.
Rangovams buvo suteiktas naujas krūvas. Jie davė mums laiko jį perrašyti GitlabCI, perkelti Jira į bankininkystės segmentą ir pan.
žingsnis po žingsnio
Žingsnis 1. Pirmiausia panaudojome vietinio pardavėjo sprendimą, produktas buvo prijungtas prie naujai sukurto DSO tinklo segmento. Platforma pasirinkta dėl jos pristatymo laiko, mastelio lankstumo ir visiško automatizavimo galimybės. Atlikti testai:
- Galimybė lanksčiai ir visiškai automatizuotai valdyti virtualizacijos platformos infrastruktūrą (tinklas, diskų posistemis, skaičiavimo resursų posistemis).
- Virtualios mašinos gyvavimo ciklo valdymo automatizavimas (šablonų kūrimas, momentinės nuotraukos, atsarginės kopijos).
Po platformos įdiegimo ir bazinės konfigūracijos ji buvo naudojama kaip antrojo etapo posistemių (DSO įrankių, mažmeninės prekybos sistemų plėtros metmenų) išdėstymo taškas. Buvo sukurti reikalingi konvejerų rinkiniai – virtualių mašinų kūrimas, trynimas, modifikavimas, atsarginės kopijos. Šie dujotiekiai buvo naudojami kaip pirmasis diegimo proceso etapas.
Dėl to pateikta įranga neatitinka banko veiklos ir gedimų tolerancijos reikalavimų. Banko DIT nusprendė sukurti kompleksą „Nutanix“ programinės įrangos paketo pagrindu.
2 stadija. Mes paėmėme nustatytą krūvą ir parašėme automatizuotus diegimo ir pokonfigūravimo scenarijus visoms posistemėms, kad viskas būtų kuo greičiau perkelta iš bandomosios programos į tikslinę grandinę. Visos sistemos buvo įdiegtos gedimams atsparios konfigūracijos (kai šios galimybės neriboja pardavėjo licencijavimo politika) ir prijungtos prie metrikos ir įvykių rinkimo posistemių. IB išanalizavo atitiktį savo reikalavimams ir uždegė žalią šviesą.
3 stadija. Visų posistemių ir jų nustatymų perkėlimas į naują PAC. Infrastruktūros automatizavimo scenarijai buvo perrašyti, o DSO posistemių migracija baigta visiškai automatizuotu režimu. IP kūrimo kontūrus atkūrė kūrimo komandų vamzdynai.
Žingsnis 4. Programinės įrangos diegimo automatizavimas. Šias užduotis iškėlė naujų komandų komandų vadovai.
Žingsnis 5. Išnaudojimas.
Nuotolinis prisijungimas
Kūrėjų komandos prašė maksimalaus lankstumo dirbant su grandine, o nuotolinės prieigos iš asmeninių nešiojamųjų kompiuterių reikalavimas buvo iškeltas pačioje projekto pradžioje. Bankas jau turėjo nuotolinę prieigą, tačiau ji netiko kūrėjams. Faktas yra tas, kad schema naudojo vartotojo ryšį su apsaugotu VDI. Tai tiko tiems, kuriems darbo vietoje reikėjo tik pašto ir biuro paketo. Kūrėjams reikėtų didelių klientų, didelio našumo, turinčių daug išteklių. Ir, žinoma, jie turėjo būti statiški, nes naudotojo seanso praradimas tiems, kurie dirba su VStudio (pavyzdžiui) ar kitu SDK, yra nepriimtinas. Daugelio storų statinių VDI suorganizavimas visoms kūrėjų komandoms labai padidino esamo VDI sprendimo kainą.
Nusprendėme dirbti su nuotoline prieiga prie plėtros segmento išteklių. Jira, Wiki, Gitlab, Nexus, kurkite ir testuokite stendus, virtualią infrastruktūrą. Apsaugos darbuotojai pareikalavo, kad prieiga būtų suteikta tik tuo atveju, jei:
- Naudojant banke jau turimas technologijas.
- Infrastruktūra neturėtų naudoti esamų domeno valdiklių, kurie saugo produktyvių paskyros objektų įrašus.
- Prieiga turėtų būti apribota tik tais ištekliais, kurių reikia konkrečiai komandai (kad viena produktų komanda negalėtų pasiekti kitos komandos išteklių).
- Maksimalus RBAC valdymas sistemose.
Dėl to šiam segmentui buvo sukurtas atskiras domenas. Šiame domene buvo visi kūrimo segmento ištekliai – ir vartotojo kredencialai, ir infrastruktūra. Šio domeno įrašų gyvavimo ciklas valdomas naudojant banke esantį IdM.
Tiesioginė nuotolinė prieiga buvo organizuota remiantis turima banko įranga. Prieigos valdymas buvo suskirstytas į AD grupes, kurioms atitiko kontekstų taisyklės (viena produktų grupė = viena taisyklių grupė).
VM šablonų valdymas
Surinkimo ir testavimo ciklo sukūrimo greitis yra vienas iš pagrindinių KPI, kurį nustato kūrimo padalinio vadovas, nes aplinkos paruošimo greitis tiesiogiai įtakoja bendrą konvejerio vykdymo laiką. Buvo svarstomi du bazinių VM vaizdų paruošimo variantai. Pirmasis yra minimalūs vaizdo dydžiai, numatytieji visiems sistemos produktams, maksimali atitiktis banko nustatymų politikai. Antrasis yra bazinis vaizdas, kuriame yra sumontuotas didelio našumo POPPO, kurio montavimo laikas gali labai paveikti dujotiekio vykdymo greitį.
Kuriant buvo atsižvelgta ir į infrastruktūros ir saugumo reikalavimus – vaizdų atnaujinimą (patchų ir pan.), integraciją su SIEM, saugos nustatymus pagal banko standartus.
Dėl to buvo nuspręsta naudoti minimalų vaizdų skaičių, kad būtų sumažintos jų atnaujinimo išlaidos. Daug lengviau atnaujinti bazinę OS, nei pataisyti kiekvieną vaizdą naujoms POPPO versijoms.
Remiantis gautais rezultatais, buvo sudarytas minimalaus reikalingo operacinių sistemų rinkinio sąrašas, kurio atnaujinimą atlieka operacijų komanda, o scenarijai iš konvejerio yra visiškai atsakingi už programinės įrangos atnaujinimą ir, jei reikia, versijos keitimą. įdiegtos programinės įrangos – tiesiog perkelkite reikiamą žymą į dujotiekį. Taip, tam reikia, kad „devops“ produktų komanda turėtų sudėtingesnius diegimo scenarijus, tačiau tai labai sumažina veikimo laiką, reikalingą baziniams vaizdams palaikyti, o kitu atveju gali prireikti daugiau nei šimto bazinių VM vaizdų.
Interneto prieiga
Kitas bankininkystės saugumo kliūtis buvo prieiga prie interneto išteklių iš kūrimo aplinkos. Be to, šią prieigą galima suskirstyti į dvi kategorijas:
- Prieiga prie infrastruktūros.
- Kūrėjo prieiga.
Prieiga prie infrastruktūros buvo organizuota naudojant „Nexus“ išorines saugyklas. Tai yra, tiesioginė prieiga iš virtualių mašinų nebuvo suteikta. Tai leido pasiekti kompromisą dėl informacijos saugumo, o tai kategoriškai priešinosi bet kokios prieigos prie išorinio pasaulio suteikimui iš plėtros segmento.
Kūrėjams prireikė prieigos prie interneto dėl akivaizdžių priežasčių (stackoverflow). Ir nors visos komandos, kaip minėta aukščiau, turėjo nuotolinę prieigą prie grandinės, ne visada patogu, kai negalite atlikti ctrl+v iš kūrėjo darbo vietos banke IDE.
Buvo pasiektas susitarimas su IS, kad iš pradžių, bandymo etape, prieiga bus teikiama per banko įgaliotąjį serverį, pagrįstą baltuoju sąrašu. Pasibaigus projektui, prieiga bus perkelta į juodąjį sąrašą. Buvo parengtos didžiulės prieigos lentelės, kuriose buvo nurodyti pagrindiniai ištekliai ir saugyklos, prie kurių buvo reikalinga prieiga projekto pradžioje. Šių prieigų derinimas užtruko nemažai laiko, todėl buvo galima reikalauti kuo greičiau pereiti prie juodųjų sąrašų.
rezultatai
Projektas baigėsi kiek mažiau nei prieš metus. Kad ir kaip būtų keista, visi rangovai laiku perėjo prie naujos rietuvės ir niekas neišėjo dėl naujos automatikos. IB neskuba dalintis teigiamais atsiliepimais, bet ir nesiskundžia, iš kurių galime daryti išvadą, kad jiems tai patinka. Konfliktai nurimo, nes informacijos saugumas vėl jaučiasi kontroliuojamas, bet netrukdo plėtros procesams. Komandoms buvo suteikta daugiau atsakomybės, pagerėjo bendras požiūris į informacijos saugumą. Bankas suprato, kad perėjimas prie DevSecOps beveik neišvengiamas, ir padarė tai, mano nuomone, švelniausiu ir teisingiausiu būdu.
Aleksandras Šubinas, sistemos architektas.
Šaltinis: www.habr.com