Банк өзүнүн долбоорлорун көптөгөн подрядчыларга тапшырат. "Тышкылар" кодду жазып, андан кийин натыйжаларды өтө ыңгайлуу эмес формада өткөрүп беришет. Тактап айтканда, процесс мындайча көрүндү: алар алар менен функционалдык тесттерден өткөн долбоорду тапшырып, андан кийин интеграция, жүктөө ж.б.у.с. үчүн банк периметринин ичинде сыналган. Көбүнчө тесттер ийгиликсиз болуп жатканы аныкталды. Андан кийин баары тышкы иштеп чыгуучуга кайтып келди. Сиз ойлогондой, бул мүчүлүштүктөрдү оңдоо үчүн узак убакытты билдирет.
Банк бүтүндөй куурду өзүнүн канатынын астына, милдеттенмеден бошотууга чейин сүйрөп кетүү мүмкүн жана зарыл деп чечти. Ошентип, баары бирдей жана банктагы продукт үчүн жооптуу топтордун көзөмөлүндө болот. Башкача айтканда, тышкы подрядчы жөн эле кеңсенин кийинки бөлмөсүндө бир жерде иштеп жаткандай. Корпоративдик стекте. Бул кадимки девоп.
Сек кайдан келген? Банктын коопсуздугу тышкы подрядчы тармак сегментинде кантип иштей алат, кимдир бирөө кандай кире алат, код менен кантип жана ким иштейт деген жогорку талаптарды койгон. Жөн гана IB подрядчылар сыртта иштегенде банктык стандарттардын бир нечеси сакталаарын билген эмес. Анан бир-эки күндөн кийин ар бир адам аларды байкай башташы керек.
Подрядчынын өнүм кодуна толук мүмкүнчүлүгү бар экендигинин жөнөкөй ачылышы алардын дүйнөсүн тескери бурган.
Ушул тапта мен сизге айтып бергиси келген DevSecOps окуясы башталды.
Бул абалдан банк кандай практикалык тыянак чыгарды?
Баардыгы туура эмес жасалып жатат деген талаш-тартыштар көп болду. Иштеп чыгуучулар коопсуздук өнүгүүгө тоскоол болуу менен алек экенин айтышты жана алар, күзөтчүлөр сыяктуу, ойлонбой туруп тыюу салууга аракет кылышат. Өз кезегинде, коопсуздук боюнча адистер: "иштеп чыгуучулар биздин схемада аялуу жерлерди жаратышат" жана "иштеп чыгуучулар алсыздыктарды жаратпайт, бирок алар өздөрү." Эгерде рыноктун жаңы талаптары жана DevSecOps парадигмасы пайда болбогондо талаш-тартыш көпкө созулмак. Маалыматтык коопсуздук талаптарын "кутудан тышкары" эске алуу менен процесстерди автоматташтыруу ар бир адамга бактылуу бойдон калууга жардам берерин түшүндүрүүгө мүмкүн болду. Эрежелер дароо жазылып, оюн учурунда өзгөрүлбөйт деген мааниде (маалыматтык коопсуздук күтүлбөгөн жерден эч нерсеге тыюу салбайт), ал эми иштеп чыгуучулар маалыматтык коопсуздукту болуп жаткан бардык нерселерден кабардар кылып турушат (маалыматтык коопсуздук капысынан бир нерсеге туш болбойт) . Ар бир команда, ошондой эле кээ бир абстрактуу улуу бир туугандар эмес, акыркы коопсуздук үчүн жооптуу болуп саналат.
- Тышкы кызматкерлер кодго жана бир катар ички системаларга кирүү мүмкүнчүлүгүнө ээ болгондуктан, балким, документтерден “иштеп чыгуу толугу менен банктын инфраструктурасында жүргүзүлүшү керек” деген талапты алып салуу мүмкүн.
- Экинчи жагынан, болуп жаткан окуяларга көзөмөлдү күчөтүшүбүз керек.
- Компромисс болуп кызматкерлер сырткы адамдар менен тыгыз иштешкен кайчылаш-функционалдык топторду түзүү болду. Бул учурда, сиз команда банктын серверлер боюнча аспаптарда иштегенине ынануу керек. башынан аягына чейин.
Башкача айтканда, подрядчыларга уруксат берилиши мүмкүн, бирок аларга өзүнчө сегменттер берилиши керек. Алар банктын инфраструктурасына сырттан кандайдыр бир инфекцияны алып келбеши үчүн жана керектүүдөн ашыкчасын көрбөшү үчүн. Ооба, алардын иш-аракеттери журналга жазылат. агып каршы коргоо үчүн DLP, мунун баары камтылган.
Негизи баардык банктар буга эртеби-кечпи келишет. Бул жерде биз «тышкылар» иштеген мындай чөйрөлөргө талаптарды макулдаштык. Мүмкүнчүлүктөрдү башкаруу куралдарынын максималдуу диапазону, аялуу жерлерди текшерүү куралдары, микросхемаларда, ассамблеяларда жана тесттерде антивирустук анализ пайда болду. Бул DevSecOps деп аталат.
Күтүлбөгөн жерден белгилүү болуп калды, эгерде буга чейин DevSecOps банктык коопсуздугу иштеп чыгуучу тарапта эмне болуп жатканын көзөмөлдөй албаса, анда жаңы парадигмада коопсуздук инфраструктурадагы кадимки окуялардай эле башкарылат. Азыр гана чогулуштар, китепканаларды контролдоо жана башкалар боюнча эскертүүлөр бар.
Болгону командаларды жаңы моделге өткөрүү калды. Мейли, инфраструктураны түзүңүз. Бирок бул майда-чүйдө нерселер, үкү тарткандай. Чынында, биз инфраструктурага жардам бердик, ал кезде өнүгүү процесстери өзгөрүп жатты.
Эмне өзгөрдү
Биз аны майда кадамдар менен ишке ашырууну чечтик, анткени биз көптөгөн процесстер бузулуп, ар кимдин көзөмөлү астында жаңы иштөө шарттарына көптөгөн “тышкылар” туруштук бере албай калышы мүмкүн экенин түшүндүк.
Биринчиден, биз кайчылаш-функционалдык командаларды түзүп, жаңы талаптарды эске алуу менен долбоорлорду уюштурууну үйрөндүк. Уюштуруу жагынан биз кандай процесстерди талкууладык. Жыйынтыгында бардык жооптуулар менен монтаждоочу түтүктүн схемасы түзүлдү.
- IC: Гит, Дженкинс, Мэвен, Рослин, Градл, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, куурчак, TeamCity, Gitlab TFS, Liquidbase.
- Test: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Атаккама.
- көрсөтүү (отчет берүү, байланыш): 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'де автоматташтыруу куралдары колдонулган жана коопсуздук адистери алар менен тыгыз иштешкен. Atlassin стек долбоорго чейин банк тарабынан колдонулган. Fortinet коопсуздук куралдары - бул коопсуздук кызматкерлери тарабынан сунушталган. Сыноо алкагы банк тарабынан түзүлгөн, эч кандай суроолор берилген эмес. Репозиторий системасы суроолорду жаратты, мен ага көнүшүм керек болчу.
Подрядчыларга жаңы стек берилди. Алар бизге аны GitlabCI үчүн кайра жазууга жана Жираны банк сегментине көчүрүү үчүн жана башкаларга убакыт беришти.
кадам сайын
Step 1. Биринчиден, биз ата мекендик сатуучудан чечимди колдондук, продукт жаңы түзүлгөн DSO тармак сегментине туташтырылды. Платформа жеткирүү убактысы, масштабдуу ийкемдүүлүгү жана толук автоматташтыруу мүмкүнчүлүгү үчүн тандалган. Өткөрүлгөн тесттер:
- Виртуалдаштыруу платформасынын инфраструктурасын ийкемдүү жана толук автоматташтырылган башкаруу мүмкүнчүлүгү (тармак, диск подсистемасы, эсептөө ресурстарынын подсистемасы).
- Виртуалдык машинанын жашоо циклин башкарууну автоматташтыруу (шаблондоо, көз ирмемдик сүрөттөр, резервдик көчүрмөлөр).
Платформаны орнотуу жана негизги конфигурациялоодон кийин ал экинчи этаптын подсистемаларын (DSO инструменттери, чекене системаларды өнүктүрүү схемалары) жайгаштыруу пункту катары колдонулган. Түтүктөрдүн керектүү топтомдору түзүлдү - виртуалдык машиналарды түзүү, жок кылуу, өзгөртүү, резервдик көчүрмөлөө. Бул түтүктөр жайгаштыруу процессинин биринчи этабы катары колдонулган.
Натыйжада, берилген жабдуулар банктын иштешине жана катачылыкка чыдамдуулук талаптарына жооп бербейт. Банктын DIT программасы Nutanix программалык пакетинин негизинде комплекс түзүүнү чечти.
этап 2. Биз аныкталган стекти алып, бардык подсистемалар үчүн автоматташтырылган орнотуу жана конфигурациядан кийинки скрипттерди жаздык, ошентип баары пилоттук схемадан максаттуу схемага мүмкүн болушунча тез өткөрүлдү. Бардык системалар катага чыдамдуу конфигурацияда орнотулган (бул мүмкүнчүлүк сатуучунун лицензиялоо саясаты менен чектелбейт) жана метрикага жана окуяларды чогултуу подсистемаларына туташтырылган. ХБ анын талаптарынын аткарылышын талдап, жашыл жарык күйдү.
этап 3. Бардык подсистемаларды жана алардын жөндөөлөрүн жаңы ПАКга көчүрүү. Инфраструктураны автоматташтыруу сценарийлери кайра жазылып, DSO подсистемаларынын миграциясы толук автоматташтырылган режимде аяктады. интеллектуалдык менчикти өнүктүрүүнүн контурлары иштеп чыгуучу топтордун түтүктөрү аркылуу кайра түзүлдү.
Step 4. Колдонмо программаларды орнотууну автоматташтыруу. Бул милдеттерди жа-цы бригадалардын жетек-чилери койгон.
Step 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