DevOps vs DevSecOps: jinsi ilivyokuwa katika benki moja

Benki hutoa miradi yake kwa wakandarasi wengi. "Wa nje" andika msimbo, kisha usambaze matokeo kwa fomu isiyofaa sana. Hasa, mchakato ulionekana kama hii: walikabidhi mradi ambao ulipitisha vipimo vya kazi nao, na kisha ukajaribiwa ndani ya mzunguko wa benki kwa ushirikiano, mzigo, na kadhalika. Mara nyingi iligunduliwa kuwa vipimo vilishindwa. Kisha kila kitu kilirudi kwa msanidi wa nje. Kama unavyoweza kukisia, hii ilimaanisha muda mrefu wa kuongoza kwa marekebisho ya hitilafu.

Benki iliamua kwamba inawezekana na ni muhimu kuburuta bomba lote chini ya mrengo wake, kutoka kwa ahadi hadi kutolewa. Ili kila kitu kiwe sawa na chini ya udhibiti wa timu zinazohusika na bidhaa katika benki. Hiyo ni, kana kwamba mkandarasi wa nje alikuwa akifanya kazi mahali fulani katika chumba kinachofuata cha ofisi. Kwenye safu ya ushirika. Hii ni devops ya kawaida.

Sec imetoka wapi? Usalama wa benki umeweka madai makubwa juu ya jinsi mkandarasi wa nje anaweza kufanya kazi katika sehemu ya mtandao, ufikiaji gani mtu anao, jinsi gani na ni nani anayefanya kazi na msimbo. Ni kwamba IB bado haikujua kuwa wakati wakandarasi wanafanya kazi nje, viwango vichache vya benki hufuatwa. Na kisha katika siku chache kila mtu anahitaji kuanza kuwaangalia.

Ufunuo rahisi kwamba mkandarasi alikuwa na ufikiaji kamili wa msimbo wa bidhaa tayari ulikuwa umegeuza ulimwengu wao juu chini.

Kwa wakati huu, hadithi ya DevSecOps ilianza, ambayo nataka kukuambia.

Je, benki ilipata hitimisho gani la vitendo kutokana na hali hii?

Kulikuwa na mabishano mengi kuhusu ukweli kwamba kila kitu kinafanywa kwa njia mbaya. Watengenezaji walisema kuwa usalama una shughuli nyingi tu kujaribu kuingilia maendeleo, na wao, kama walinzi, wanajaribu kupiga marufuku bila kufikiria. Kwa upande mwingine, wataalamu wa usalama walisitasita kati ya kuchagua kati ya maoni: "wasanidi programu huunda udhaifu katika mzunguko wetu" na "wasanidi programu hawaleti udhaifu, lakini wao wenyewe." Mzozo ungeendelea kwa muda mrefu ikiwa sio kwa mahitaji mapya ya soko na kuibuka kwa dhana ya DevSecOps. Iliwezekana kueleza kuwa otomatiki hii ya michakato inayozingatia mahitaji ya usalama wa habari "nje ya sanduku" itasaidia kila mtu kubaki na furaha. Kwa maana kwamba sheria zimeandikwa mara moja na hazibadilika wakati wa mchezo (usalama wa habari hautakataza kitu bila kutarajia), na watengenezaji huweka usalama wa habari kuhusu kila kitu kinachotokea (usalama wa habari haukutana na kitu ghafla) . Kila timu pia inawajibika kwa usalama wa mwisho, na sio ndugu wengine wakubwa.

1. Kwa kuwa wafanyikazi wa nje tayari wana ufikiaji wa nambari na mifumo kadhaa ya ndani, labda inawezekana kuondoa kutoka kwa hati hitaji "lazima maendeleo yafanyike kwenye miundombinu ya benki."
2. Kwa upande mwingine, tunahitaji kuimarisha udhibiti juu ya kile kinachotokea.
3. Maelewano yalikuwa kuundwa kwa timu zinazofanya kazi mbalimbali, ambapo wafanyakazi hufanya kazi kwa karibu na watu wa nje. Katika kesi hii, unahitaji kuhakikisha kuwa timu inafanya kazi kwenye zana kwenye seva za benki. Kuanzia mwanzo hadi mwisho.

Hiyo ni, wakandarasi wanaweza kuruhusiwa, lakini wanahitaji kupewa sehemu tofauti. Ili wasilete aina fulani ya maambukizi kutoka nje kwenye miundombinu ya benki na ili wasione zaidi ya kile kinachohitajika. Naam, ili matendo yao yameingia. DLP kwa ulinzi dhidi ya uvujaji, yote haya yalijumuishwa.

Kimsingi, benki zote huja hii mapema au baadaye. Hapa tulipitia njia iliyopigwa na kukubaliana juu ya mahitaji ya mazingira kama hayo ambapo "wa nje" hufanya kazi. Kulionekana upeo wa juu wa zana za kudhibiti ufikiaji, zana za kukagua uwezekano wa kuathirika, uchanganuzi wa kizuia virusi kwenye saketi, mikusanyiko na majaribio. Hii inaitwa DevSecOps.

Ghafla ikawa wazi kwamba ikiwa kabla ya usalama wa benki ya DevSecOps hakuwa na udhibiti juu ya kile kinachotokea kwa upande wa msanidi programu, basi katika dhana mpya ya usalama inadhibitiwa kwa njia sawa na matukio ya kawaida kwenye miundombinu. Ni sasa tu kuna arifu juu ya makusanyiko, udhibiti wa maktaba, na kadhalika.

Kilichobaki ni kuhamisha timu kwa mtindo mpya. Naam, tengeneza miundombinu. Lakini hizi ni vitu vidogo, ni kama kuchora bundi. Kwa kweli, tulisaidia na miundombinu, na wakati huo michakato ya maendeleo ilikuwa ikibadilika.

Nini kimebadilika

Tuliamua kuitekeleza kwa hatua ndogo, kwa sababu tulielewa kuwa michakato mingi ingesambaratika, na wengi "wa nje" hawawezi kuhimili hali mpya za kazi chini ya usimamizi wa kila mtu.

Kwanza, tuliunda timu zinazofanya kazi mbalimbali na tukajifunza kupanga miradi kwa kuzingatia mahitaji mapya. Kwa maana ya shirika tulijadili michakato gani. Matokeo yake yalikuwa mchoro wa bomba la kusanyiko na wale wote waliohusika.

• IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
• CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
• Mtihani: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Kituo cha Utendaji, MF UFT, Ataccama.
• Uwasilishaji (kuripoti, mawasiliano): Grafana, Kibana, Jira, Confluence, RocketChat.
• uendeshaji (matengenezo, usimamizi): Ansible, Zabbix, Prometheus, Elastic + Logstash, Meneja wa Huduma wa MF, Jira, Confluence, MS Project.

Rafu iliyochaguliwa:

• Msingi wa Maarifa - Ushawishi wa Atlassian;
• Mfuatiliaji wa kazi - Atlassian Jira;
• Hifadhi ya vizalia - "Nexus";
• Mfumo wa ujumuishaji unaoendelea - "Gitlab CI";
• Mfumo wa uchambuzi unaoendelea - "SonarQube";
• Mfumo wa uchambuzi wa usalama wa programu - "Micro Focus Forify";
• Mfumo wa mawasiliano - "GitLab Mattermost";
• Mfumo wa usimamizi wa usanidi - "Inawezekana";
• Mfumo wa ufuatiliaji - "ELK", "TICK Stack" ("InfluxData").

Walianza kuunda timu ambayo itakuwa tayari kuwavuta wakandarasi ndani. Kuna ufahamu kwamba kuna mambo kadhaa muhimu:

• Kila kitu kinapaswa kuunganishwa, angalau wakati wa kusambaza nambari. Kwa sababu kama wakandarasi wengi walivyokuwa, kulikuwa na michakato mingi tofauti ya maendeleo na upekee wao wenyewe. Ilihitajika kutoshea kila mtu katika takriban moja, lakini kwa chaguzi.
• Kuna makandarasi wengi, na uundaji wa miundombinu kwa mikono haufai. Kazi yoyote mpya inapaswa kuanza haraka sana - yaani, mfano unapaswa kutumwa mara moja ili wasanidi wawe na seti ya suluhu za kudhibiti bomba lao.

Ili kuchukua hatua ya kwanza, ilikuwa ni lazima kuelewa ni nini kilikuwa kinafanywa. Na tulilazimika kuamua jinsi ya kufika huko. Tulianza kwa kusaidia kuchora usanifu wa suluhisho lengwa katika miundombinu na otomatiki ya CI/CD. Kisha tukaanza kukusanya conveyor hii. Tulihitaji miundombinu moja, sawa kwa kila mtu, ambapo wasafirishaji sawa wangefanya kazi. Tulitoa chaguzi na mahesabu, benki ilifikiria, kisha ikaamua nini kitajengwa na kwa fedha gani.

Ifuatayo ni kuundwa kwa mzunguko - ufungaji wa programu, usanidi. Ukuzaji wa hati za uwekaji na usimamizi wa miundombinu. Inayofuata inakuja mpito kwa usaidizi wa conveyor.

Tuliamua kujaribu kila kitu kwenye majaribio. Inashangaza, wakati wa majaribio, stack fulani ilionekana katika benki kwa mara ya kwanza. Miongoni mwa mambo mengine, muuzaji wa ndani wa mojawapo ya ufumbuzi alitolewa kwa wigo wa majaribio kwa uzinduzi wa haraka. Usalama ulimfahamu alipokuwa akiendesha majaribio, na iliacha hisia isiyoweza kusahaulika. Tulipoamua kubadili, kwa bahati nzuri, safu ya miundombinu ilibadilishwa na suluhisho la Nutanix, ambalo lilikuwa tayari katika benki kabla. Zaidi ya hayo, kabla ya hapo ilikuwa ya VDI, lakini tuliitumia tena kwa huduma za miundombinu. Kwa kiasi kidogo haikufaa katika uchumi, lakini kwa kiasi kikubwa ikawa mazingira bora ya maendeleo na majaribio.

Rafu iliyobaki inajulikana zaidi au chini kwa kila mtu. Zana za otomatiki katika Ansible zilitumika, na wataalamu wa usalama walifanya kazi nao kwa karibu. Rafu ya Atlassin ilitumiwa na benki kabla ya mradi. Vyombo vya usalama vya Fortinet - ilipendekezwa na watu wa usalama wenyewe. Sura ya majaribio iliundwa na benki, hakuna maswali yaliyoulizwa. Mfumo wa hazina ulizua maswali; ilibidi niizoea.

Wakandarasi walipewa rundo mpya. Walitupa muda wa kuiandika upya kwa GitlabCI, na kuhamia Jira hadi sehemu ya benki, na kadhalika.

Hatua kwa hatua

Hatua ya 1. Kwanza, tulitumia suluhisho kutoka kwa muuzaji wa ndani, bidhaa hiyo iliunganishwa na sehemu mpya ya mtandao wa DSO iliyoundwa. Jukwaa lilichaguliwa kwa wakati wake wa kujifungua, kubadilika kwa kuongeza na uwezekano wa automatisering kamili. Mitihani iliyofanywa:

• Uwezekano wa usimamizi rahisi na wa kiotomatiki kikamilifu wa miundombinu ya jukwaa la uboreshaji (mtandao, mfumo mdogo wa diski, mfumo mdogo wa rasilimali za kompyuta).
• Uendeshaji otomatiki wa usimamizi wa mzunguko wa maisha wa mashine (kuiga, picha, nakala rudufu).

Baada ya usanidi na usanidi wa msingi wa jukwaa, ilitumika kama sehemu ya uwekaji wa mifumo ndogo ya hatua ya pili (zana za DSO, muhtasari wa ukuzaji wa mifumo ya rejareja). Seti muhimu za bomba ziliundwa - uundaji, ufutaji, urekebishaji, nakala rudufu ya mashine za kawaida. Mabomba haya yalitumika kama hatua ya kwanza ya mchakato wa kupeleka.

Matokeo yake ni kwamba vifaa vilivyotolewa havikidhi mahitaji ya benki ya utendaji na uvumilivu wa makosa. DIT ya benki iliamua kuunda tata kulingana na kifurushi cha programu cha Nutanix.

Hatua 2. Tulichukua rafu iliyofafanuliwa, na tukaandika hati za usakinishaji otomatiki na usanidi wa baada ya mifumo yote ndogo ili kila kitu kihamishwe kutoka kwa jaribio hadi saketi lengwa haraka iwezekanavyo. Mifumo yote iliwekwa katika usanidi unaostahimili hitilafu (ambapo uwezo huu hauzuiliwi na sera za leseni za muuzaji) na kuunganishwa kwenye vipimo na mifumo midogo ya ukusanyaji wa matukio. IB ilichambua utiifu wa mahitaji yake na kutoa mwanga wa kijani.

Hatua 3. Uhamisho wa mifumo yote midogo na mipangilio yake hadi PAC mpya. Hati za otomatiki za miundombinu ziliandikwa upya, na uhamishaji wa mifumo ndogo ya DSO ilikamilishwa katika hali ya kiotomatiki kikamilifu. Mtaro wa maendeleo ya IP uliundwa upya na mabomba ya timu za maendeleo.

Hatua ya 4. Ufungaji wa programu ya kiotomatiki. Kazi hizi ziliwekwa na viongozi wa timu ya timu mpya.

Hatua ya 5. Unyonyaji.

Ufikiaji wa mbali

Timu za maendeleo ziliuliza kubadilika kwa kiwango cha juu katika kufanya kazi na mzunguko, na hitaji la ufikiaji wa mbali kutoka kwa kompyuta ndogo ya kibinafsi lilitolewa mwanzoni mwa mradi. Benki tayari ilikuwa na ufikiaji wa mbali, lakini haikufaa kwa watengenezaji. Ukweli ni kwamba mpango huo ulitumia uunganisho wa mtumiaji kwenye VDI iliyolindwa. Hii iliwafaa wale ambao walihitaji tu barua na kifurushi cha ofisi mahali pao pa kazi. Watengenezaji wangehitaji wateja wazito, utendaji wa juu, na rasilimali nyingi. Na kwa kweli, walipaswa kuwa tuli, kwani upotezaji wa kikao cha watumiaji kwa wale wanaofanya kazi na VStudio (kwa mfano) au SDK nyingine haikubaliki. Kupanga idadi kubwa ya VDI nene tuli kwa timu zote za maendeleo iliongeza sana gharama ya suluhisho lililopo la VDI.

Tuliamua kufanya kazi kwenye ufikiaji wa mbali moja kwa moja kwa rasilimali za sehemu ya maendeleo. Jira, Wiki, Gitlab, Nexus, jenga na kujaribu madawati, miundombinu pepe. Walinzi wamedai kwamba ufikiaji unaweza kutolewa tu kwa kuzingatia yafuatayo:

1. Kwa kutumia teknolojia zilizopo tayari kwenye benki.
2. Miundombinu haipaswi kutumia vidhibiti vilivyopo vya kikoa vinavyohifadhi rekodi za vitu vya akaunti vinavyozalisha.
3. Ufikiaji unapaswa kupunguzwa tu kwa rasilimali zinazohitajika na timu mahususi (ili timu moja ya bidhaa isiweze kufikia rasilimali za timu nyingine).
4. Udhibiti wa juu zaidi wa RBAC katika mifumo.

Kwa hivyo, kikoa tofauti kiliundwa kwa sehemu hii. Kikoa hiki kilihifadhi rasilimali zote za sehemu ya uendelezaji, vitambulisho vya mtumiaji na miundombinu. Mzunguko wa maisha wa rekodi katika kikoa hiki unadhibitiwa kwa kutumia IdM iliyopo ya benki.

Ufikiaji wa moja kwa moja wa kijijini ulipangwa kwa misingi ya vifaa vilivyopo vya benki. Udhibiti wa ufikiaji uligawanywa katika vikundi vya AD, ambayo sheria juu ya muktadha zililingana (kikundi kimoja cha bidhaa = kikundi kimoja cha sheria).

Usimamizi wa Kiolezo cha VM

Kasi ya kuunda kitanzi cha mkutano na kupima ni mojawapo ya KPIs kuu iliyowekwa na mkuu wa kitengo cha maendeleo, kwa sababu kasi ya kuandaa mazingira huathiri moja kwa moja wakati wa utekelezaji wa jumla wa bomba. Chaguzi mbili za kuandaa picha za msingi za VM zilizingatiwa. Ya kwanza ni ukubwa wa chini wa picha, chaguomsingi kwa bidhaa zote za mfumo, utiifu wa juu zaidi wa sera za mipangilio ya benki. Ya pili ni picha ya msingi iliyo na POPPO ya kazi nzito iliyosakinishwa, wakati wa usakinishaji ambao unaweza kuathiri sana kasi ya utekelezaji wa bomba.

Mahitaji ya miundombinu na usalama pia yalizingatiwa wakati wa maendeleo - kusasisha picha (viraka, nk), kuunganishwa na SIEM, mipangilio ya usalama kulingana na viwango vya benki.

Kwa hivyo, iliamuliwa kutumia picha ndogo ili kupunguza gharama ya kusasisha. Ni rahisi zaidi kusasisha OS ya msingi kuliko kubandika kila picha kwa matoleo mapya ya POPPO.

Kulingana na matokeo, orodha iliundwa ya seti ya chini inayohitajika ya mifumo ya uendeshaji, sasisho ambalo linafanywa na timu ya operesheni, na maandishi kutoka kwa bomba yana jukumu la kusasisha programu, na ikiwa ni lazima, badilisha toleo. ya programu iliyowekwa - tu kuhamisha lebo inayohitajika kwenye bomba. Ndiyo, hii inahitaji timu ya bidhaa ya devops kuwa na matukio changamano zaidi ya uwekaji, lakini inapunguza sana muda wa uendeshaji unaohitajika ili kusaidia picha za msingi, ambazo zinaweza kuhitaji zaidi ya picha mia moja za msingi za VM ili kudumisha.

Ufikiaji wa Mtandao

Kikwazo kingine kwa usalama wa benki ilikuwa upatikanaji wa rasilimali za mtandao kutoka kwa mazingira ya maendeleo. Kwa kuongezea, ufikiaji huu unaweza kugawanywa katika vikundi viwili:

1. Ufikiaji wa miundombinu.
2. Ufikiaji wa msanidi.

Ufikiaji wa miundombinu ulipangwa kwa kutumia hazina za nje kwa kutumia Nexus. Hiyo ni, ufikiaji wa moja kwa moja kutoka kwa mashine halisi haukutolewa. Hii ilifanya iwezekane kufikia maelewano na usalama wa habari, ambayo kimsingi ilikuwa dhidi ya kutoa ufikiaji wowote kwa ulimwengu wa nje kutoka kwa sehemu ya maendeleo.

Watengenezaji walihitaji ufikiaji wa Mtandao kwa sababu za wazi (stackoverflow). Na ingawa amri zote, kama ilivyotajwa hapo juu, zilikuwa na ufikiaji wa mbali kwa mzunguko, sio rahisi kila wakati wakati huwezi kufanya ctrl+v kutoka mahali pa kazi ya msanidi programu kwenye benki kwenye IDE.

Makubaliano yalifikiwa na IS kwamba mwanzoni, katika hatua ya majaribio, ufikiaji utatolewa kupitia wakala wa benki kulingana na orodha nyeupe. Baada ya kukamilika kwa mradi, ufikiaji utahamishiwa kwenye orodha nyeusi. Majedwali makubwa ya ufikiaji yalitayarishwa, ambayo yalionyesha rasilimali kuu na hazina ambazo ufikiaji ulihitajika mwanzoni mwa mradi. Kuratibu ufikiaji huu kulichukua muda wa kutosha, ambao ulifanya iwezekane kusisitiza juu ya mpito wa haraka iwezekanavyo kwa orodha zisizoruhusiwa.

Matokeo

Mradi ulimalizika chini ya mwaka mmoja uliopita. Cha ajabu, wakandarasi wote walibadilisha kwa stack mpya kwa wakati na hakuna mtu aliyeondoka kwa sababu ya otomatiki mpya. IB hana haraka ya kushiriki maoni chanya, lakini halalamiki pia, ambayo tunaweza kuhitimisha kuwa wanaipenda. Mizozo imepungua kwa sababu usalama wa habari unahisi kudhibitiwa tena, lakini hauingiliani na michakato ya usanidi. Timu zilipewa jukumu zaidi, na mtazamo wa jumla kuelekea usalama wa habari ukawa bora. Benki ilielewa kuwa mpito kwa DevSecOps ulikuwa karibu kuepukika, na ilifanya hivyo, kwa maoni yangu, kwa njia ya upole na sahihi zaidi.

Alexander Shubin, mbunifu wa mfumo.

Chanzo: mapenzi.com