Тус банк төслөө олон гүйцэтгэгчдээр гүйцэтгүүлдэг. "Гадны" код бичээд үр дүнг тийм ч тохиромжтой биш хэлбэрээр дамжуулна. Тодруулбал, үйл явц нь иймэрхүү харагдаж байв: тэд тэдэнтэй хамт функциональ туршилтыг давсан төслийг хүлээлгэн өгч, дараа нь нэгдмэл байдал, ачаалал гэх мэт банкны периметрийн дотор туршиж үзсэн. Туршилтууд амжилтгүй болсон нь ихэвчлэн илэрсэн. Дараа нь бүх зүйл гадны хөгжүүлэгч рүү буцав. Таны таамаглаж байгаагаар энэ нь алдааг засахад удаан хугацаа шаардсан гэсэн үг юм.
Банк амлалт өгөхөөс эхлээд суллах хүртэл хоолойг бүхэлд нь жигүүрийнхээ доор чирэх боломжтой бөгөөд шаардлагатай гэж шийдсэн. Ингэснээр бүх зүйл жигд, банкинд бүтээгдэхүүн хариуцсан багуудын хяналтанд байдаг. Энэ нь гадны гүйцэтгэгч нь оффисын хажуугийн өрөөнд хаа нэгтээ ажиллаж байгаа мэт. Корпорацийн стек дээр. Энэ бол жирийн девоп юм.
Сек хаанаас ирсэн бэ? Банкны аюулгүй байдал нь гадны гүйцэтгэгч сүлжээний сегментэд хэрхэн ажиллах, хэн нэгэнд ямар хандалт хийх, кодтой хэрхэн, хэн ажиллах зэрэг өндөр шаардлага тавьдаг. Гүйцэтгэгчид гадаа ажиллахад банкны цөөн хэдэн стандарт мөрддөг гэдгийг IB хараахан мэдээгүй. Тэгээд хэд хоногийн дараа хүн бүр тэднийг ажиглаж эхлэх хэрэгтэй.
Гүйцэтгэгч нь бүтээгдэхүүний кодыг бүрэн ашиглах боломжтой гэсэн энгийн илчлэлт нь тэдний ертөнцийг аль хэдийн орвонгоор нь эргүүлсэн юм.
Энэ мөчид DevSecOps-ийн түүх эхэлсэн бөгөөд би та нарт хэлэхийг хүсч байна.
Энэ байдлаас банк ямар бодитой дүгнэлт хийсэн бэ?
Бүх зүйл буруу замаар явж байна гэсэн маргаан их байсан. Аюулгүй байдал нь зөвхөн хөгжилд саад учруулах гэж завгүй байдаг бөгөөд тэд манаач шиг бодолгүйгээр хориглохыг хичээдэг гэж хөгжүүлэгчид хэлэв. Хариуд нь аюулгүй байдлын мэргэжилтнүүд "хөгжүүлэгчид манай хэлхээнд эмзэг байдлыг бий болгодог" эсвэл "хөгжүүлэгчид эмзэг байдлыг үүсгэдэггүй, харин өөрсдөө байдаг" гэсэн үзэл бодлын хооронд сонголт хийхээс эргэлзэж байв. Зах зээлийн шинэ эрэлт хэрэгцээ болон DevSecOps парадигм бий болоогүй бол маргаан удаан үргэлжлэх байсан. Мэдээллийн аюулгүй байдлын шаардлагуудыг "хайрцагнаас нь гаргасан" энэхүү автоматжуулалт нь хүн бүр аз жаргалтай байхад тусална гэдгийг тайлбарлах боломжтой байв. Дүрмүүд нь шууд бичигдэж, тоглоомын явцад өөрчлөгддөггүй (мэдээллийн аюулгүй байдал нь гэнэтийн зүйлийг хориглохгүй), хөгжүүлэгчид мэдээллийн аюулгүй байдалд болж буй бүх зүйлийн талаар мэдээлэл өгдөг (мэдээллийн аюулгүй байдал нь гэнэт ямар нэгэн зүйлтэй тулгардаггүй) . Зарим хийсвэр ах нар биш харин баг бүр дээд зэргийн аюулгүй байдлыг хариуцдаг.
- Гадны ажилтнууд код болон хэд хэдэн дотоод системд аль хэдийн нэвтэрсэн тул "хөгжлийг бүхэлд нь банкны дэд бүтцээр хийх ёстой" гэсэн шаардлагыг баримтаас хасах боломжтой.
- Нөгөө талаар болж буй үйл явдалд тавих хяналтаа чангатгах хэрэгтэй.
- Энэ буулт нь ажилчид нь гадны хүмүүстэй нягт хамтран ажилладаг харилцан үйл ажиллагааны багуудыг бий болгох явдал байв. Энэ тохиолдолд та багийнхан банкны сервер дээрх хэрэгслүүд дээр ажиллаж байгаа эсэхийг шалгах хэрэгтэй. Эхнээс нь дуустал.
Өөрөөр хэлбэл, гүйцэтгэгчдийг оруулах боломжтой, гэхдээ тэдэнд тусдаа сегмент өгөх шаардлагатай. Тэд банкны дэд бүтцэд гаднаас ямар нэгэн халдвар авчрахгүйн тулд шаардлагатай зүйлээс илүүг олж харахгүйн тулд. За, ингэснээр тэдний үйлдлийг бүртгэх болно. Нэвчилтээс хамгаалах DLP, энэ бүгдийг багтаасан болно.
Зарчмын хувьд бүх банкууд эрт орой хэзээ нэгэн цагт үүнд ирдэг. Энд бид "гадны" ажилладаг ийм орчинд тавигдах шаардлагуудыг тохиролцсон. Хандалтыг хянах хэрэгсэл, эмзэг байдлыг шалгах хэрэгсэл, хэлхээ, угсралт, туршилтын вирусын эсрэг шинжилгээ зэрэг хамгийн олон төрлийн хэрэгсэл гарч ирэв. Үүнийг DevSecOps гэж нэрлэдэг.
Хэрэв өмнө нь DevSecOps банкны аюулгүй байдал нь хөгжүүлэгчийн талд юу болж байгааг хянах боломжгүй байсан бол шинэ парадигмын аюулгүй байдлыг дэд бүтцийн ердийн үйл явдлуудын нэгэн адил хянадаг нь гэнэт тодорхой болов. Зөвхөн одоо л цугларалт, номын сангуудын хяналт гэх мэт сэрэмжлүүлэг байдаг.
Багуудыг шинэ загварт шилжүүлэх л үлдлээ. За, дэд бүтцийг бий болго. Гэхдээ эдгээр нь өчүүхэн зүйл, яг л шар шувуу зурахтай адил юм. Уг нь бид дэд бүтцээр нь тусалсан, тэр үед хөгжлийн явц өөрчлөгдөж байсан.
Юу өөрчлөгдсөн бэ
Олон үйл явц задарч, олон “гадныхан” хүн бүрийн хяналтан дор шинэ ажлын нөхцөлийг тэсвэрлэх чадваргүй байж магадгүй гэдгийг ойлгосон учраас бид үүнийг бага багаар хэрэгжүүлэхээр шийдсэн.
Нэгдүгээрт, бид олон талт багууд байгуулж, шинэ шаардлагыг харгалзан төслүүдийг зохион байгуулж сурсан. Зохион байгуулалтын хувьд бид ямар үйл явцыг ярилцсан. Үүний үр дүнд бүх хариуцлагатай хүмүүстэй угсрах хоолойн диаграмм гарч ирэв.
- IC: 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, Ataccama.
- Танилцуулга (тайлагнах, харилцаа холбоо): Grafana, Kibana, Jira, Confluence, RocketChat.
- үйл ажиллагаа (засвар үйлчилгээ, менежмент): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Сонгосон стек:
- Мэдлэгийн сан - Атлассын бэлчир;
- Task tracker - Atlassian Jira;
- Олдворын агуулах - "Nexus";
- Тасралтгүй нэгтгэх систем - "Gitlab CI";
- Тасралтгүй шинжилгээний систем - "SonarQube";
- Хэрэглээний аюулгүй байдлын шинжилгээний систем - "Micro Focus Fortify";
- Харилцаа холбооны систем - "GitLab Mattermost";
- Тохиргооны удирдлагын систем - "Ansible";
- Хяналтын систем - "ELK", "TICK Stack" ("InfluxData").
Тэд гэрээлэгчдийг дотогшоо чирэхэд бэлэн байх багийг бүрдүүлж эхлэв. Хэд хэдэн чухал зүйл байдаг гэдгийг ойлгосон:
- Ядаж код дамжуулахдаа бүх зүйл нэгдмэл байх ёстой. Яагаад гэвэл өөр өөрийн гэсэн онцлогтой олон төрлийн бүтээн байгуулалтын үйл явц байсан шиг олон гүйцэтгэгч байсан. Хүн бүрийг нэг дор багтаах шаардлагатай байсан, гэхдээ сонголттой.
- Гүйцэтгэгч олон байдаг бөгөөд дэд бүтцийг гараар бий болгох нь тохиромжгүй. Аливаа шинэ ажил маш хурдан эхлэх ёстой - өөрөөр хэлбэл, жишээ нь бараг тэр даруйд тавигдах ёстой бөгөөд ингэснээр хөгжүүлэгчид дамжуулах хоолойгоо удирдах олон шийдэлтэй болно.
Эхний алхамыг хийхийн тулд юу хийж байгааг ойлгох шаардлагатай байв. Тэгээд бид яаж тийшээ очихоо тодорхойлох ёстой байсан. Бид дэд бүтэц болон CI/CD автоматжуулалтын аль алинд нь зорилтот шийдлийн архитектурыг зурахад тусалж эхэлсэн. Дараа нь бид энэ конвейерийг угсарч эхэлсэн. Бидэнд хүн бүрт адилхан, ижил конвейер ажилладаг нэг дэд бүтэц хэрэгтэй байсан. Бид тооцоотой хувилбаруудыг санал болгож байна гэж банк бодсоны дараа юуг, ямар хөрөнгөөр барихаа шийдсэн.
Дараа нь хэлхээ үүсгэх - програм хангамж суурилуулах, тохиргоо хийх. Дэд бүтцийг байршуулах, удирдах скрипт боловсруулах. Дараа нь конвейерийн дэмжлэг рүү шилжих шилжилтийг хийдэг.
Бид бүх зүйлийг нисгэгч дээр туршихаар шийдсэн. Сонирхолтой нь туршилтын явцад банкинд анх удаа тодорхой стек гарч ирэв. Бусад зүйлсийн дотор нэг шийдлийн дотоодын худалдагчийг хурдан эхлүүлэхийн тулд туршилтын хүрээнд санал болгов. Аюулгүй байдлынхан түүнийг нисгэхэд нь танилцаж, мартагдашгүй сэтгэгдэл үлдээсэн. Биднийг солихоор шийдсэн үед аз болоход дэд бүтцийн давхаргыг өмнө нь банкинд байсан Nutanix шийдлээр сольсон. Түүнээс гадна, өмнө нь VDI-д зориулагдсан байсан бол бид үүнийг дэд бүтцийн үйлчилгээнд дахин ашигласан. Бага хэмжээгээр энэ нь эдийн засагт тохирохгүй байсан ч их хэмжээгээр хөгжүүлэлт, туршилт хийх маш сайн орчин болсон.
Стекийн үлдсэн хэсэг нь бүгдэд багагүй танил юм. Ansible дахь автоматжуулалтын хэрэгслийг ашигласан бөгөөд аюулгүй байдлын мэргэжилтнүүд тэдэнтэй нягт хамтран ажилласан. Атлассин стекийг төсөл хэрэгжихээс өмнө банк ашиглаж байсан. Fortinet аюулгүй байдлын хэрэгслүүд - үүнийг хамгаалалтын ажилтнууд өөрсдөө санал болгосон. Туршилтын хүрээг банк бүтээсэн бөгөөд асуулт асуугаагүй. Хадгалах систем нь асуултуудыг тавьсан тул би үүнд дасах хэрэгтэй болсон.
Гүйцэтгэгчид шинэ стекийг өгсөн. Тэд GitlabCI-д зориулж үүнийг дахин бичих, Жира-г банкны сегмент рүү шилжүүлэх гэх мэт хугацаа өгсөн.
алхам алхамаар
1 шат. Нэгдүгээрт, бид дотоодын үйлдвэрлэгчийн шийдлийг ашигласан бөгөөд бүтээгдэхүүнийг шинээр үүсгэсэн DSO сүлжээний сегментэд холбосон. Энэхүү платформыг хүргэх хугацаа, уян хатан байдал, бүрэн автоматжуулалт хийх боломжоор сонгосон. Хийсэн туршилтууд:
- Виртуалчлалын платформын дэд бүтцийг (сүлжээ, дискний дэд систем, тооцоолох нөөцийн дэд систем) уян хатан, бүрэн автоматжуулсан удирдлагын боломж.
- Виртуал машины амьдралын мөчлөгийн удирдлагын автоматжуулалт (загвар, хормын хувилбар, нөөцлөлт).
Платформыг суурилуулж, үндсэн тохиргоо хийсний дараа үүнийг хоёр дахь шатны дэд системүүдийг (DSO хэрэгслүүд, жижиглэн худалдааны системийн хөгжлийн тойм) байрлуулах цэг болгон ашигласан. Шаардлагатай дамжуулах хоолойн багцыг бий болгосон - виртуал машиныг үүсгэх, устгах, өөрчлөх, нөөцлөх. Эдгээр дамжуулах хоолойг байрлуулах үйл явцын эхний үе шат болгон ашигласан.
Үүний үр дүнд нийлүүлсэн тоног төхөөрөмж нь банкны гүйцэтгэл, алдааг тэсвэрлэх шаардлагыг хангахгүй байна. Тус банкны DIT нь Nutanix програм хангамжийн багц дээр суурилсан цогцолбор байгуулахаар шийдсэн.
Үе шат 2. Бид тодорхойлсон стекийг авч, бүх дэд системд автоматжуулсан суурилуулалт болон тохируулгын дараах скриптүүдийг бичсэн бөгөөд ингэснээр бүх зүйлийг нисгэгчээс зорилтот хэлхээнд аль болох хурдан шилжүүлсэн. Бүх системийг гэмтэлд тэсвэртэй тохиргоонд (энэ чадвар нь худалдагчийн лицензийн бодлогоор хязгаарлагдахгүй) байрлуулсан бөгөөд хэмжүүр болон үйл явдлын цуглуулгын дэд системд холбогдсон. ОУТ шаардлагадаа нийцэж байгаа эсэхэд дүн шинжилгээ хийж, ногоон гэрэл асаалаа.
Үе шат 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 командыг хийх боломжгүй үед тийм ч тохиромжтой байдаггүй.
IS-тэй тохиролцоонд хүрч, эхний шатанд туршилтын шатанд цагаан жагсаалтад үндэслэн банкны итгэмжлэгдсэн төлөөлөгчөөр дамжуулан нэвтрэх боломжийг олгоно. Төсөл дууссаны дараа хандалт хар жагсаалтад шилжинэ. Төслийн эхэнд хандах шаардлагатай үндсэн нөөц, агуулахуудыг харуулсан асар том хандалтын хүснэгтүүдийг бэлтгэсэн. Эдгээр хандалтыг зохицуулахад нэлээд хугацаа зарцуулсан нь хар жагсаалтад аль болох хурдан шилжихийг шаардах боломжтой болсон.
Результаты
Төсөл жил хүрэхгүй хугацааны өмнө дууссан. Хачирхалтай нь, бүх гүйцэтгэгчид цаг тухайд нь шинэ стек рүү шилжсэн бөгөөд шинэ автоматжуулалтын улмаас хэн ч үлдээгүй. IB эерэг санал хүсэлтийг хуваалцах гэж яарахгүй байгаа ч гомдоллодоггүй бөгөөд үүнээс бид тэдэнд таалагдсан гэж дүгнэж болно. Мэдээллийн аюулгүй байдал дахин хяналтанд байгаа мэт боловч хөгжлийн үйл явцад саад болохгүй байгаа тул зөрчилдөөн намжсан. Багуудад үүрэг хариуцлага нэмэгдэж, мэдээллийн аюулгүй байдлын талаарх ерөнхий хандлага сайжирсан. Банк DevSecOps руу шилжих нь бараг гарцаагүй гэдгийг ойлгосон бөгөөд үүнийг миний бодлоор хамгийн эелдэг бөгөөд зөв аргаар хийсэн.
Александр Шубин, системийн архитектор.
Эх сурвалж: www.habr.com