DevOps vs DevSecOps: kung ano ang hitsura nito sa isang bangko

Ini-outsource ng bangko ang mga proyekto nito sa maraming kontratista. Sumulat ng code ang "mga panlabas", pagkatapos ay ipadala ang mga resulta sa isang hindi masyadong maginhawang anyo. Sa partikular, ganito ang hitsura ng proseso: iniabot nila ang isang proyekto na pumasa sa mga pagsubok sa pagganap sa kanila, at pagkatapos ay sinubukan sa loob ng perimeter ng pagbabangko para sa pagsasama, pag-load, at iba pa. Madalas na natuklasan na ang mga pagsubok ay nabigo. Pagkatapos ang lahat ay bumalik sa panlabas na developer. Gaya ng maaari mong hulaan, nangangahulugan ito ng mahabang oras ng lead para sa mga pag-aayos ng bug.

Ang bangko ay nagpasya na ito ay posible at kinakailangan upang i-drag ang buong pipeline sa ilalim ng pakpak nito, mula sa commits sa release. Upang ang lahat ay pare-pareho at nasa ilalim ng kontrol ng mga koponan na responsable para sa produkto sa bangko. Ibig sabihin, parang nagtatrabaho lang ang external contractor sa isang lugar sa katabing silid ng opisina. Sa corporate stack. Ito ay isang ordinaryong devops.

Saan nanggaling si Sec? Ang seguridad ng bangko ay naglagay ng mataas na pangangailangan sa kung paano maaaring gumana ang isang panlabas na kontratista sa segment ng network, kung anong access ang mayroon ang isang tao, paano at sino ang gumagana sa code. Kaya lang hindi pa alam ng IB na kapag nagtatrabaho sa labas ang mga contractor, kakaunti ang banking standards ang sinusunod. At pagkatapos ay sa loob ng ilang araw kailangan ng lahat na simulan ang pagmamasid sa kanila.

Ang simpleng paghahayag na may ganap na access ang contractor sa code ng produkto ay nabaligtad na ang kanilang mundo.

Sa sandaling ito, nagsimula ang kuwento ng DevSecOps, na gusto kong sabihin sa iyo.

Anong mga praktikal na konklusyon ang nakuha ng bangko mula sa sitwasyong ito?

Nagkaroon ng maraming kontrobersya tungkol sa katotohanan na ang lahat ay ginagawa sa maling paraan. Sinabi ng mga developer na ang seguridad ay abala lamang sa pagsisikap na makagambala sa pag-unlad, at sila, tulad ng mga bantay, ay sumusubok na ipagbawal nang hindi nag-iisip. Sa turn, ang mga espesyalista sa seguridad ay nag-alinlangan sa pagitan ng pagpili sa pagitan ng mga punto ng view: "ang mga developer ay gumagawa ng mga kahinaan sa aming circuit" at "ang mga developer ay hindi gumagawa ng mga kahinaan, ngunit sila mismo." Ang pagtatalo ay magpapatuloy sa mahabang panahon kung hindi para sa mga bagong pangangailangan sa merkado at ang paglitaw ng paradigm ng DevSecOps. Posibleng ipaliwanag na ang mismong pag-aautomat ng mga prosesong ito na isinasaalang-alang ang mga kinakailangan sa seguridad ng impormasyon "out of the box" ay makakatulong sa lahat na manatiling masaya. Sa kahulugan na ang mga patakaran ay isinulat kaagad at hindi nagbabago sa panahon ng laro (ang seguridad ng impormasyon ay hindi ipagbabawal ang isang bagay nang hindi inaasahan), at ang mga developer ay nagpapaalam sa seguridad ng impormasyon tungkol sa lahat ng nangyayari (ang seguridad ng impormasyon ay hindi nakatagpo ng isang bagay nang biglaan) . Ang bawat koponan ay may pananagutan din para sa sukdulang kaligtasan, at hindi ang ilang abstract na nakatatandang kapatid na lalaki.

1. Dahil ang mga panlabas na empleyado ay mayroon nang access sa code at isang bilang ng mga panloob na sistema, malamang na posible na alisin mula sa mga dokumento ang kinakailangan na "kailangang ganap na isagawa ang pag-unlad sa imprastraktura ng bangko."
2. Sa kabilang banda, kailangan nating palakasin ang kontrol sa kung ano ang nangyayari.
3. Ang kompromiso ay ang paglikha ng mga cross-functional na koponan, kung saan ang mga empleyado ay nakikipagtulungan nang malapit sa mga panlabas na tao. Sa kasong ito, kailangan mong tiyakin na gumagana ang koponan sa mga tool sa mga server ng bangko. Mula sa simula hanggang sa wakas.

Ibig sabihin, puwedeng pasukin ang mga contractor, pero kailangan silang bigyan ng hiwalay na segment. Upang hindi sila magdala ng ilang uri ng impeksyon mula sa labas sa imprastraktura ng bangko at upang hindi nila makita ang higit sa kung ano ang kinakailangan. Well, upang ang kanilang mga aksyon ay naka-log. DLP para sa proteksyon laban sa pagtagas, lahat ng ito ay kasama.

Sa prinsipyo, ang lahat ng mga bangko ay darating sa ito maaga o huli. Dito kami nagpunta sa mabagal na landas at sumang-ayon sa mga kinakailangan para sa gayong mga kapaligiran kung saan gumagana ang "mga panlabas". May lumitaw na maximum na hanay ng mga access control tool, vulnerability checking tool, anti-virus analysis sa mga circuit, assemblies at pagsubok. Ito ay tinatawag na DevSecOps.

Biglang naging malinaw na kung bago ang seguridad ng pagbabangko ng DevSecOps ay walang kontrol sa kung ano ang mangyayari sa panig ng developer, kung gayon sa bagong paradigm ang seguridad ay kinokontrol sa parehong paraan tulad ng mga ordinaryong kaganapan sa imprastraktura. Ngayon lang may mga alerto sa mga pagtitipon, kontrol sa mga aklatan, at iba pa.

Ang natitira na lang ay ilipat ang mga koponan sa bagong modelo. Buweno, lumikha ng imprastraktura. Ngunit ito ay mga trifle, ito ay tulad ng pagguhit ng isang kuwago. Sa totoo lang, tumulong kami sa imprastraktura, at sa oras na iyon ang mga proseso ng pag-unlad ay nagbabago.

Ano ang nagbago

Napagpasyahan naming ipatupad ito sa maliliit na hakbang, dahil naunawaan namin na maraming proseso ang mawawasak, at maraming "mga panlabas" ang maaaring hindi makayanan ang mga bagong kondisyon sa pagtatrabaho sa ilalim ng pangangasiwa ng lahat.

Una, gumawa kami ng mga cross-functional na koponan at natutong ayusin ang mga proyekto na isinasaalang-alang ang mga bagong kinakailangan. Sa kahulugan ng organisasyonal, tinalakay namin kung ano ang mga proseso. Ang resulta ay isang diagram ng pipeline ng pagpupulong kasama ang lahat ng mga responsable.

• IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
• CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
• Pagsubok: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
• Pagtatanghal (pag-uulat, komunikasyon): Grafana, Kibana, Jira, Confluence, RocketChat.
• Mga Operasyon (pagpapanatili, pamamahala): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.

Napiling stack:

• Knowledge Base - Atlassian Confluence;
• Tagasubaybay ng gawain - Atlassian Jira;
• Artifact repository - "Nexus";
• Patuloy na sistema ng pagsasama - "Gitlab CI";
• Patuloy na sistema ng pagsusuri - "SonarQube";
• Sistema ng pagsusuri sa seguridad ng aplikasyon - "Micro Focus Fortify";
• Sistema ng komunikasyon - "GitLab Mattermost";
• Sistema ng pamamahala ng configuration - "Ansible";
• Sistema ng pagsubaybay - “ELK”, “TICK Stack” (“InfluxData”).

Nagsimula silang lumikha ng isang koponan na handang kaladkarin ang mga kontratista sa loob. Napagtanto na mayroong ilang mahahalagang bagay:

• Ang lahat ay dapat na pinag-isa, hindi bababa sa kapag nagpapadala ng code. Dahil nagkaroon ng maraming mga kontratista bilang mayroong napakaraming iba't ibang mga proseso ng pag-unlad na may sariling mga kakaiba. Ito ay kinakailangan upang magkasya ang lahat sa humigit-kumulang isa, ngunit may mga pagpipilian.
• Mayroong maraming mga kontratista, at ang manu-manong paglikha ng imprastraktura ay hindi angkop. Ang anumang bagong gawain ay dapat magsimula nang napakabilis - ibig sabihin, ang instance ay dapat na i-deploy nang halos agad-agad upang ang mga developer ay magkaroon ng isang hanay ng mga solusyon upang pamahalaan ang kanilang pipeline.

Upang gawin ang unang hakbang, ito ay kinakailangan upang maunawaan kung ano ang ginagawa. At kailangan naming matukoy kung paano makarating doon. Nagsimula kami sa pamamagitan ng pagtulong sa pagguhit ng arkitektura ng target na solusyon kapwa sa imprastraktura at CI/CD automation. Pagkatapos ay sinimulan naming i-assemble ang conveyor na ito. Kailangan namin ng isang imprastraktura, pareho para sa lahat, kung saan tatakbo ang parehong mga conveyor. Nag-alok kami ng mga opsyon na may mga kalkulasyon, naisip ng bangko, pagkatapos ay nagpasya kung ano ang itatayo at kung anong mga pondo.

Susunod ay ang paglikha ng circuit - pag-install ng software, pagsasaayos. Pagbuo ng mga script para sa pag-deploy at pamamahala ng imprastraktura. Susunod ay ang paglipat sa suporta sa conveyor.

Nagpasya kaming subukan ang lahat sa piloto. Kapansin-pansin, sa panahon ng piloting, isang tiyak na stack ang lumitaw sa bangko sa unang pagkakataon. Sa iba pang mga bagay, ang isang domestic vendor ng isa sa mga solusyon ay inaalok para sa saklaw ng piloto para sa isang mabilis na paglulunsad. Nakilala siya ng security habang nagpi-pilot siya, at nag-iwan ito ng hindi malilimutang impresyon. Noong nagpasya kaming lumipat, sa kabutihang palad, ang layer ng imprastraktura ay napalitan ng solusyon ng Nutanix, na nasa bangko na noon. Bukod dito, bago iyon ay para sa VDI, ngunit ginamit namin ito para sa mga serbisyo sa imprastraktura. Sa maliliit na volume ay hindi ito umaangkop sa ekonomiya, ngunit sa malalaking volume ito ay naging isang mahusay na kapaligiran para sa pag-unlad at pagsubok.

Ang natitirang bahagi ng stack ay higit pa o hindi gaanong pamilyar sa lahat. Ginamit ang mga tool sa pag-automate sa Ansible, at nakipagtulungan sa kanila ang mga espesyalista sa seguridad. Ang Atlassin stack ay ginamit ng bangko bago ang proyekto. Mga tool sa seguridad ng Fortinet - iminungkahi ito ng mga tao mismo ng seguridad. Ang testing frame ay ginawa ng bangko, walang mga tanong na itinanong. Ang sistema ng repositoryo ay nagtaas ng mga katanungan; kailangan kong masanay dito.

Ang mga kontratista ay binigyan ng bagong stack. Binigyan nila kami ng oras upang muling isulat ito para sa GitlabCI, at i-migrate si Jira sa segment ng pagbabangko, at iba pa.

hakbang-hakbang

Hakbang 1. Una, gumamit kami ng solusyon mula sa isang domestic vendor, ang produkto ay konektado sa isang bagong nilikha na segment ng network ng DSO. Napili ang platform para sa oras ng paghahatid nito, flexibility ng scaling at ang posibilidad ng ganap na automation. Nagsagawa ng mga pagsubok:

• Posibilidad ng flexible at ganap na automated na pamamahala ng virtualization platform infrastructure (network, disk subsystem, computing resources subsystem).
• Automation ng virtual machine lifecycle management (templating, snapshots, backups).

Pagkatapos ng pag-install at pangunahing pagsasaayos ng platform, ginamit ito bilang punto ng paglalagay ng pangalawang yugto ng mga subsystem (mga tool ng DSO, mga balangkas ng pagbuo ng mga retail system). Ang mga kinakailangang hanay ng mga pipeline ay nilikha - paglikha, pagtanggal, pagbabago, pag-backup ng mga virtual machine. Ang mga pipeline na ito ay ginamit bilang unang yugto ng proseso ng pag-deploy.

Ang resulta ay ang ibinigay na kagamitan ay hindi nakakatugon sa mga kinakailangan ng bangko para sa pagganap at pagpapahintulot sa pagkakamali. Nagpasya ang DIT ng bangko na lumikha ng isang kumplikadong batay sa pakete ng software ng Nutanix.

2 Stage. Kinuha namin ang stack na tinukoy, at nagsulat ng awtomatikong pag-install at post-configuration na mga script para sa lahat ng mga subsystem upang ang lahat ay mailipat mula sa pilot patungo sa target na circuit sa lalong madaling panahon. Na-deploy ang lahat ng system sa isang fault-tolerant na configuration (kung saan ang kakayahang ito ay hindi limitado ng mga patakaran sa paglilisensya ng vendor) at konektado sa mga sukatan at mga subsystem ng koleksyon ng kaganapan. Sinuri ng IB ang pagsunod sa mga kinakailangan nito at nagbigay ng berdeng ilaw.

3 Stage. Ang paglipat ng lahat ng mga subsystem at ang kanilang mga setting sa bagong PAC. Ang mga script ng automation ng imprastraktura ay muling isinulat, at ang paglipat ng mga subsystem ng DSO ay nakumpleto sa isang ganap na automated na mode. Ang mga contour ng IP development ay muling nilikha ng mga pipeline ng mga development team.

Hakbang 4. Automation ng pag-install ng software ng application. Ang mga gawaing ito ay itinakda ng mga pinuno ng pangkat ng mga bagong koponan.

Hakbang 5. Pagsasamantala.

Malayong pag-access

Ang mga development team ay humiling ng maximum na kakayahang umangkop sa pagtatrabaho sa circuit, at ang pangangailangan para sa malayuang pag-access mula sa mga personal na laptop ay itinaas sa pinakadulo simula ng proyekto. Ang bangko ay mayroon nang malayuang pag-access, ngunit hindi ito angkop para sa mga developer. Ang katotohanan ay ginamit ng scheme ang koneksyon ng user sa isang protektadong VDI. Ito ay angkop para sa mga nangangailangan lamang ng mail at isang pakete ng opisina sa kanilang lugar ng trabaho. Kakailanganin ng mga developer ang mabibigat na kliyente, mataas na pagganap, na may maraming mapagkukunan. At siyempre, kailangan nilang maging static, dahil hindi katanggap-tanggap ang pagkawala ng session ng user para sa mga nagtatrabaho sa VStudio (halimbawa) o iba pang SDK. Ang pag-aayos ng isang malaking bilang ng mga makapal na static na VDI para sa lahat ng mga development team ay lubos na nagpapataas ng halaga ng kasalukuyang solusyon sa VDI.

Nagpasya kaming gumawa ng malayuang pag-access nang direkta sa mga mapagkukunan ng segment ng pag-unlad. Jira, Wiki, Gitlab, Nexus, build at test bench, virtual na imprastraktura. Hiniling ng mga security guard na ang pag-access ay maaari lamang ibigay alinsunod sa mga sumusunod:

1. Gamit ang mga teknolohiyang magagamit na sa bangko.
2. Ang imprastraktura ay hindi dapat gumamit ng mga kasalukuyang controller ng domain na nag-iimbak ng mga talaan ng mga produktibong bagay ng account.
3. Ang pag-access ay dapat na limitado lamang sa mga mapagkukunang kinakailangan ng isang partikular na koponan (upang hindi ma-access ng isang pangkat ng produkto ang mga mapagkukunan ng isa pang koponan).
4. Pinakamataas na kontrol sa RBAC sa mga system.

Bilang resulta, isang hiwalay na domain ang ginawa para sa segment na ito. Ang domain na ito ay naglalaman ng lahat ng mapagkukunan ng segment ng pag-unlad, parehong mga kredensyal ng user at imprastraktura. Ang ikot ng buhay ng mga tala sa domain na ito ay pinamamahalaan gamit ang IdM na umiiral sa bangko.

Ang direktang malayuang pag-access ay inayos batay sa kasalukuyang kagamitan ng bangko. Ang kontrol sa pag-access ay nahahati sa mga pangkat ng AD, kung saan tumutugma ang mga panuntunan sa mga konteksto (isang pangkat ng produkto = isang pangkat ng mga panuntunan).

Pamamahala ng Template ng VM

Ang bilis ng paglikha ng assembly at testing loop ay isa sa mga pangunahing KPI na itinakda ng pinuno ng development unit, dahil ang bilis ng paghahanda ng kapaligiran ay direktang nakakaapekto sa kabuuang oras ng pagpapatupad ng pipeline. Dalawang opsyon para sa paghahanda ng mga batayang larawan ng VM ay isinasaalang-alang. Ang una ay ang pinakamababang laki ng larawan, default para sa lahat ng produkto ng system, maximum na pagsunod sa mga patakaran ng bangko tungkol sa mga setting. Ang pangalawa ay ang batayang imahe, na naglalaman ng isang mabigat na tungkuling POPPO na naka-install, ang oras ng pag-install na maaaring lubos na makaimpluwensya sa bilis ng pagpapatupad ng pipeline.

Ang mga kinakailangan sa imprastraktura at seguridad ay isinasaalang-alang din sa panahon ng pag-unlad - pinapanatili ang mga larawan na napapanahon (mga patch, atbp.), pagsasama sa SIEM, mga setting ng seguridad ayon sa mga pamantayan ng bangko.

Bilang resulta, napagpasyahan na gumamit ng kaunting mga larawan upang mabawasan ang gastos sa pagpapanatiling napapanahon ang mga ito. Mas madaling i-update ang base OS kaysa i-patch ang bawat larawan para sa mga bagong bersyon ng POPPO.

Batay sa mga resulta, nabuo ang isang listahan ng pinakamababang kinakailangang hanay ng mga operating system, ang pag-update nito ay isinasagawa ng pangkat ng pagpapatakbo, at ang mga script mula sa pipeline ay ganap na responsable para sa pag-update ng software, at kung kinakailangan, baguhin ang bersyon ng naka-install na software - ilipat lamang ang kinakailangang tag sa pipeline. Oo, kailangan nito ang pangkat ng produkto ng devops na magkaroon ng mas kumplikadong mga sitwasyon sa pag-deploy, ngunit lubos nitong binabawasan ang oras ng pagpapatakbo na kinakailangan upang suportahan ang mga batayang larawan, na maaaring mangailangan ng higit sa isang daang mga batayang larawan ng VM upang mapanatili.

Access sa Internet

Ang isa pang hadlang sa seguridad sa pagbabangko ay ang pag-access sa mga mapagkukunan ng Internet mula sa kapaligiran ng pag-unlad. Bukod dito, ang pag-access na ito ay maaaring nahahati sa dalawang kategorya:

1. Pag-access sa imprastraktura.
2. Access ng developer.

Inayos ang pag-access sa imprastraktura sa pamamagitan ng pag-proxy ng mga external na repository gamit ang Nexus. Iyon ay, ang direktang pag-access mula sa mga virtual machine ay hindi ibinigay. Ginawa nitong posible na maabot ang isang kompromiso sa seguridad ng impormasyon, na tiyak na laban sa pagbibigay ng anumang pag-access sa labas ng mundo mula sa segment ng pag-unlad.

Kailangan ng mga developer ng access sa Internet para sa mga malinaw na dahilan (stackoverflow). At kahit na ang lahat ng mga utos, tulad ng nabanggit sa itaas, ay may malayuang pag-access sa circuit, hindi palaging maginhawa kapag hindi mo magawa ang ctrl+v mula sa lugar ng trabaho ng developer sa bangko sa IDE.

Isang kasunduan ang naabot sa IS na sa simula, sa yugto ng pagsubok, ang pag-access ay ibibigay sa pamamagitan ng isang proxy sa pagbabangko batay sa isang white-list. Sa pagkumpleto ng proyekto, ang access ay ililipat sa black-list. Inihanda ang malalaking talahanayan ng pag-access, na nagsasaad ng mga pangunahing mapagkukunan at mga repository kung saan kinakailangan ang pag-access sa simula ng proyekto. Ang pag-uugnay sa mga pag-access na ito ay tumagal ng isang patas na tagal ng oras, na naging posible upang igiit ang pinakamabilis na posibleng paglipat sa mga blacklist.

Natuklasan

Natapos ang proyekto wala pang isang taon ang nakalipas. Kakatwa, lahat ng mga kontratista ay lumipat sa bagong stack sa oras at walang umalis dahil sa bagong automation. Hindi nagmamadali ang IB na magbahagi ng positibong feedback, ngunit hindi rin nagrereklamo, kung saan maaari nating tapusin na gusto nila ito. Ang mga salungatan ay humupa dahil ang seguridad ng impormasyon ay muling nararamdaman na may kontrol, ngunit hindi nakakasagabal sa mga proseso ng pag-unlad. Ang mga koponan ay binigyan ng higit na responsibilidad, at ang pangkalahatang saloobin sa seguridad ng impormasyon ay naging mas mahusay. Naunawaan ng bangko na ang paglipat sa DevSecOps ay halos hindi maiiwasan, at ginawa ito, sa aking opinyon, sa pinaka banayad at tamang paraan.

Alexander Shubin, arkitekto ng sistema.

Pinagmulan: www.habr.com