Банк өз жобаларын көптеген мердігерлерге береді. «Сыртқылар» кодты жазады, содан кейін нәтижелерді өте ыңғайлы емес пішінде жібереді. Нақтырақ айтқанда, процесс келесідей болды: олар олармен функционалдық сынақтардан өткен жобаны тапсырды, содан кейін интеграция, жүктеме және т.б. үшін банк периметрі ішінде сынақтан өтті. Тесттердің сәтсіз болғаны жиі анықталды. Содан кейін бәрі сыртқы әзірлеушіге оралды. Сіз болжап отырғандай, бұл қателерді түзету үшін ұзақ уақытты білдіреді.
Банк міндеттемеден босатуға дейін бүкіл құбырды қанатының астына апару мүмкін және қажет деп шешті. Барлығы біркелкі және банктегі өнімге жауапты топтардың бақылауында болуы үшін. Яғни, сыртқы мердігер кеңсенің келесі бөлмесінде бір жерде жұмыс істеп жатқандай. Корпоративтік стекте. Бұл кәдімгі девоп.
Сек қайдан пайда болды? Банк қауіпсіздігі сыртқы мердігердің желі сегментінде қалай жұмыс істей алатыны, біреудің қандай рұқсаты бар, кодпен қалай және кім жұмыс істейтіні туралы жоғары талаптар қойды. Тек ХБ мердігерлер сыртта жұмыс істеген кезде банктік стандарттар аз сақталатынын әлі білмеген. Содан кейін бір-екі күннен кейін барлығы оларды бақылай бастауы керек.
Мердігердің өнім кодына толық қол жетімділігі туралы қарапайым ашу олардың әлемін төңкеріп жіберді.
Осы сәтте мен сізге айтқым келетін DevSecOps тарихы басталды.
Бұл жағдайдан банк қандай практикалық қорытынды жасады?
Әр нәрсенің дұрыс емес жасалып жатқаны туралы даулар көп болды. Әзірлеушілер қауіпсіздіктің тек дамуға кедергі келтіруге тырысатынын және олар күзетшілер сияқты ойланбастан тыйым салуға тырысатынын айтты. Өз кезегінде, қауіпсіздік мамандары: «әзірлеушілер біздің схемада осалдықтарды жасайды» және «әзірлеушілер осалдықтарды жасамайды, бірақ олар өздері» деген көзқарастардың арасында таңдау жасаудан тартынды. Жаңа нарықтық талаптар мен DevSecOps парадигмасының пайда болуы болмаса, дау ұзақ уақыт бойы жалғасатын еді. Ақпараттық қауіпсіздік талаптарын «қораптан тыс» ескере отырып, процестерді дәл осылай автоматтандыру барлығына бақытты болуға көмектесетінін түсіндіруге болады. Ережелер бірден жазылады және ойын барысында өзгермейді (ақпараттық қауіпсіздік күтпеген жерден ештеңеге тыйым салмайды) және әзірлеушілер ақпараттық қауіпсіздікті болып жатқан барлық нәрселер туралы хабардар етеді (ақпараттық қауіпсіздік кенеттен бірдеңеге тап болмайды) . Әрбір команда кейбір абстрактілі ағалар емес, соңғы қауіпсіздік үшін жауап береді.
- Сыртқы қызметкерлер кодқа және бірқатар ішкі жүйелерге қол жеткізе алатындықтан, құжаттардан «дамыту толығымен банктің инфрақұрылымында жүргізілуі керек» деген талапты алып тастауға болады.
- Екінші жағынан, не болып жатқанын бақылауды күшейту керек.
- Компромисс қызметкерлер сыртқы адамдармен тығыз жұмыс істейтін кросс-функционалды командаларды құру болды. Бұл жағдайда команданың банк серверлеріндегі құралдармен жұмыс істейтініне көз жеткізу керек. Басынан аяғына дейін.
Яғни, мердігерлерді кіргізуге болады, бірақ оларға бөлек сегменттер беру керек. Олар банк инфрақұрылымына қандай да бір инфекцияны сырттан әкелмеуі үшін және қажет болғаннан көп нәрсені көрмеуі үшін. Олардың әрекеттері тіркелуі үшін. Ағып кетуден қорғауға арналған DLP, мұның бәрі енгізілген.
Негізінде барлық банктер бұған ерте ме, кеш пе келеді. Мұнда біз «сыртқы» жұмыс істейтін орталарға қойылатын талаптарды келістік. Қол жеткізуді басқару құралдарының, осалдықтарды тексеру құралдарының, схемалардағы, жинақтардағы және сынақтардағы антивирустық талдаулардың максималды ауқымы пайда болды. Бұл DevSecOps деп аталады.
Кенеттен белгілі болды, егер бұрын DevSecOps банктік қауіпсіздік әзірлеуші тарапынан не болып жатқанын бақылай алмаса, онда жаңа парадигмада қауіпсіздік инфрақұрылымдағы қарапайым оқиғалар сияқты басқарылады. Тек қазір жинақтар, кітапханаларды бақылау және т.б. туралы ескертулер бар.
Тек командаларды жаңа үлгіге көшіру ғана қалды. Ал, инфрақұрылымды жасаңыз. Бірақ бұл ұсақ-түйек, бұл үкі салу сияқты. Шындығында, біз инфрақұрылымға көмектестік, сол кезде даму процестері өзгеріп жатты.
Не өзгерді
Біз оны кішігірім қадамдармен жүзеге асыруды шештік, өйткені біз көптеген процестердің ыдырайтынын және көптеген «сыртқылар» әркімнің қадағалауымен жаңа жұмыс жағдайларына төтеп бере алмауы мүмкін екенін түсіндік.
Біріншіден, біз кросс-функционалды топтар құрдық және жаңа талаптарды ескере отырып жобаларды ұйымдастыруды үйрендік. Ұйымдастыру тұрғысынан біз қандай процестерді талқыладық. Нәтижесі барлық жауаптылармен бірге құрастыру құбырының схемасы болды.
- МЕН ТҮСІНЕМІН: 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.
Таңдалған стек:
- Білім базасы – Атласс тоғысуы;
- Тапсырмаларды бақылаушы - Atlassian Jira;
- Артефакт репозиторийі – «Nexus»;
- Үздіксіз интеграция жүйесі – «Gitlab CI»;
- Үздіксіз талдау жүйесі – «SonarQube»;
- Қолданбалардың қауіпсіздігін талдау жүйесі – «Micro Focus Fortify»;
- Коммуникациялық жүйе – «GitLab Mattermost»;
- Конфигурацияны басқару жүйесі – «Ansible»;
- Бақылау жүйесі – «ELK», «TICK Stack» («InfluxData»).
Олар мердігерлерді ішке тартуға дайын команда құра бастады. Бірнеше маңызды нәрселер бар екенін түсіну бар:
- Кем дегенде кодты жіберген кезде барлығы біртұтас болуы керек. Өйткені өз ерекшеліктері бар әртүрлі даму процестері қанша болса, сонша мердігерлер болды. Барлығын шамамен бір, бірақ опциялармен біріктіру керек болды.
- Мердігерлер көп, инфрақұрылымды қолмен жасау жарамайды. Кез келген жаңа тапсырма өте жылдам басталуы керек, яғни әзірлеушілер өз құбырларын басқаруға арналған шешімдер жиынтығына ие болу үшін дананы дерлік дерлік орналастыру керек.
Бірінші қадамды жасау үшін не істеп жатқанын түсіну керек болды. Біз оған қалай жетуге болатынын анықтауымыз керек еді. Біз инфрақұрылымда да, CI/CD автоматтандыруында да мақсатты шешімнің архитектурасын салуға көмектесуден бастадық. Содан осы конвейерді құрастыруға кірістік. Бізге барлығына бірдей, бірдей конвейерлер жүретін бір инфрақұрылым қажет болды. Біз есептеулермен нұсқаларды ұсындық, банк ойлады, содан кейін нені және қандай қаражатпен салынатынын шешті.
Келесі кезекте схеманы құру - бағдарламалық қамтамасыз етуді орнату, конфигурациялау. Инфрақұрылымды орналастыру және басқару үшін сценарийлерді әзірлеу. Келесі кезекте конвейерді қолдауға көшу.
Біз барлығын ұшқышта сынап көруді шештік. Бір қызығы, пилоттық өткізу кезінде банкте алғаш рет белгілі бір стек пайда болды. Басқа нәрселермен қатар, жылдам іске қосу үшін пилоттық ауқым үшін шешімдердің бірінің отандық жеткізушісі ұсынылды. Қауіпсіздік оны ұшқышты басқарған кезде танысты және бұл ұмытылмас әсер қалдырды. Біз ауысуды шешкен кезде, бақытымызға орай, инфрақұрылымдық қабат бұрын банкте болған Nutanix шешімімен ауыстырылды. Оның үстіне, бұған дейін бұл VDI үшін болатын, бірақ біз оны инфрақұрылымдық қызметтер үшін қайта пайдаландық. Кішігірім көлемде ол экономикаға сәйкес келмеді, бірақ үлкен көлемде ол әзірлеу және тестілеу үшін тамаша орта болды.
Стектің қалған бөлігі барлығына азды-көпті таныс. Ansible-де автоматтандыру құралдары қолданылды және қауіпсіздік мамандары олармен тығыз жұмыс істеді. Atlassin стегін банк жобаға дейін пайдаланған. Fortinet қауіпсіздік құралдары - оны қауіпсіздік қызметкерлері өздері ұсынған. Тестілеу шеңберін банк жасаған, сұрақтар қойылмаған. Репозиторий жүйесі сұрақтар туғызды, мен оған үйренуім керек болды.
Мердігерлерге жаңа стек берілді. Олар бізге оны GitlabCI үшін қайта жазуға және Jira-ны банк сегментіне көшіруге және т.б. уақыт берді.
бірте-бірте
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 көмегімен сыртқы репозиторийлерді проксимен қамтамасыз ету арқылы ұйымдастырылды. Яғни виртуалды машиналардан тікелей қол жеткізу қамтамасыз етілмеді. Бұл ақпараттық қауіпсіздік бойынша ымыраға келуге мүмкіндік берді, бұл даму сегментінен сыртқы әлемге кез келген қол жеткізуді қамтамасыз етуге мүлдем қарсы болды.
Әзірлеушілерге белгілі себептермен Интернетке кіру қажет болды (стекверфласт). Жоғарыда айтылғандай, барлық пәрмендер схемаға қашықтан қол жеткізуге ие болғанымен, IDE ішіндегі банктегі әзірлеушінің жұмыс орнынан ctrl+v орындай алмасаңыз, бұл әрқашан қолайлы емес.
АЖ-мен келісімге қол жеткізілді, бұл бастапқыда тестілеу сатысында рұқсат ақ тізімге негізделген банктік прокси арқылы қамтамасыз етіледі. Жоба аяқталғаннан кейін рұқсат қара тізімге ауыстырылады. Жобаның басында қол жеткізу қажет болатын негізгі ресурстар мен репозиторийлер көрсетілген үлкен қол жеткізу кестелері дайындалды. Бұл қол жеткізулерді үйлестіру жеткілікті уақытты алды, бұл қара тізімдерге ең жылдам өтуді талап етуге мүмкіндік берді.
нәтижелері
Жоба бір жылдан сәл аз уақыт бұрын аяқталды. Бір қызығы, барлық мердігерлер жаңа стекке уақытында ауысты және жаңа автоматтандыруға байланысты ешкім кеткен жоқ. IB оң пікірлермен бөлісуге асықпайды, бірақ шағымданбайды, осыдан біз оларға ұнайды деген қорытынды жасауға болады. Қақтығыстар бәсеңдеді, себебі ақпараттық қауіпсіздік қайтадан бақылауда екенін сезінеді, бірақ даму процестеріне кедергі келтірмейді. Командаларға жауапкершілік артып, ақпараттық қауіпсіздікке деген жалпы көзқарас жақсарды. Банк DevSecOps-қа көшудің сөзсіз дерлік екенін түсінді және оны, менің ойымша, ең жұмсақ және дұрыс жасады.
Александр Шубин, жүйе сәулетшісі.
Ақпарат көзі: www.habr.com