Банк аўтсорсіт свае праекты многім падрадчыкам. "Знешнікі" пішуць код, потым перадаюць вынікі ў не зусім зручным выглядзе. Канкрэтна працэс выглядаў так: яны перадавалі праект, які прайшоў функцыянальныя тэсты ў іх, а затым тэсціравалі ўжо ўнутры банкаўскага перыметра на інтэграцыю, нагрузку і гэтак далей. Часта выяўлялася, што тэсты фэйлі. Тады ўсё сыходзіла зваротна знешняму распрацоўшчыку. Як вы можаце здагадацца, гэта азначала вялікія тэрміны выпраўлення памылак.
Банк вырашыў, што можна і трэба перацягнуць увесь пайплайн да сябе "пад крылца" ад коммітаў да выпуску. Каб усё было аднастайна і пад кантролем каманд, якія адказваюць за прадукт у слоіку. Гэта значыць як калі б вонкавы падрадчык проста працаваў дзесьці ў суседнім пакоі офіса. На карпаратыўным стэку. Гэта звычайны дэвопс.
Адкуль з'явілася Sec? Бяспека банка выставіла высокія патрабаванні да таго, як знешні падрадчык можа працаваць у сеткавым сегменце, які ў каго доступ, як і хто працуе з кодам. Проста ИБ яшчэ не ведала, што калі падрадчыкі працуюць звонку, мала якія банкаўскія стандарты выконваюцца. А тут за пару дзён трэба іх пачаць выконваць усім.
Адно простае адкрыццё, што падрадчык мае поўны доступ да кода прадукта, ужо перавярнула іх мір.
У гэты момант і пачалася гісторыя 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 Centre, MF UFT, Ataсcama.
- Прэзентацыя (справаздачнасць, камунікацыя): Grafana, Kibana, Jira, Confluence, RocketChat.
- аперацыі (суправаджэнне, кіраванне): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Выбралі стэк:
- База ведаў - "Atlassian Confluence";
- Таск-трэкер - "Atlassian Jira";
- Рэпазітар артэфактаў - "Nexus";
- Сістэма бесперапыннай інтэграцыі - "Gitlab CI";
- Сістэма бесперапыннага аналізу – "SonarQube";
- Сістэма аналізу бяспекі прыкладанняў - "Micro Focus Fortify";
- Сістэма камунікацый – "GitLab Mattermost";
- Сістэма кіравання канфігурацыямі - "Ansible";
- Сістэма маніторынгу – "ELK", "TICK Stack" ("InfluxData").
Сталі ствараць каманду, якая будзе гатова перацягнуць падрадчыкаў унутр. Наступіла ўсведамленне, што ёсць некалькі важных рэчаў:
- Усё павінна быць уніфікавана хаця б на перадачы кода. Таму што колькі было падрадчыкаў - столькі і розных працэсаў распрацоўкі з асаблівасцямі. Трэба было абкласці ўсіх у прыкладна адзін, але з опцыямі.
- Падрадчыкаў шмат, і ручное стварэньне інфраструктуры не падыходзіць. Любая новая задача павінна запускацца вельмі хутка - гэта значыць інстанс павінен разгортвацца амаль імгненна, каб распрацоўшчыкі атрымлівалі наборы рашэнняў для кіравання сваім канвеерам.
Каб зрабіць першы крок – трэба было зразумець, што ўвогуле робіцца. А мы мусілі вызначыць, як да гэтага перайсці. Пачалі мы з таго, што дапамаглі намаляваць архітэктуру мэтавага рашэння як у інфраструктуры, так і па аўтаматызацыі CI/CD. Потым мы пачалі збіраць гэты канвеер. Патрэбна была адна інфраструктура, аднолькавая для ўсіх, дзе б бегалі адны і тыя ж канвееры. Мы прапаноўвалі варыянты з разлікамі, банк думаў, потым прымаў рашэнне, што і на якіх сродках будзе пабудавана.
Далей стварэнне контуру - ўстаноўка ПЗ, настройка. Распрацоўка скрыптоў па дэплоі інфраструктуры і па кіраванні. Далей ужо пераход на падтрымку канвеера.
Вырашылі абкатаць усё на пілоце. Што цікава, па ходзе пілатавання пэўны стэк з'явіўся ў слоіку ўпершыню. Сярод іншага на аб'ём пілота быў прапанаваны айчынны вендар аднаго з рашэнняў для больш хуткага запуску. Бяспека знаёмілася з ім па ходзе пілатавання, і гэта пакінула незабыўныя ўражанні. Калі вырашылі перайсці, на шчасце, інфраструктурны пласт замянілі на нутаніксавае рашэнне, якое ўжо круцілася ў банку да гэтага. Прычым да гэтага яно было для VDI, а мы перавыкарыстоўвалі для інфраструктурных сэрвісаў. На малых аб'ёмах яно не ўпісвалася ў эканоміку, а на вялікіх стала выдатным асяроддзем для распрацоўкі і тэсціравання.
Астатні стэк больш-менш знаёмы ўсім. Сродкі аўтаматызацыі ў частцы Ansible выкарыстоўваліся, з імі шчыльна працавалі бяспечнікі. Атласінаўскі стэк выкарыстоўваўся банкам і да праекту. Сродкі па бяспецы Fortinet - яно было прапанавана самімі бяспечнікамі. Фрэйм для тэсціравання ствараўся банкам, ніякіх пытанняў. Пытанні выклікала сістэма рэпазітароў, прыйшлося абвыкаць.
Падрадчыкам далі новы стэк. Далі час на перапісванне пад GitlabCI, і на тое, каб міграваць Jira у сегмент банка і гэтак далей.
Па кроках
Этап 1. Спачатку выкарыстоўвалі рашэнне айчыннага вендара, прадукт быў скамутаваны ў новы створаны сеткавы сегмент DSO. Платформу абралі па тэрмінах пастаўкі, гнуткасці маштабавання і магчымасці поўнай аўтаматызацыі. Правялі тэсты:
- Магчымасць гнуткага і цалкам аўтаматызаванага кіравання інфраструктурай платформы віртуалізацыі (сетка, дыскавая падсістэма, падсістэма вылічальных рэсурсаў).
- Аўтаматызацыя кіравання жыццёвым цыклам віртуальных машын (шабланізаванне, снапшоты, рэзервовыя копіі).
Пасля ўсталёўкі і базавай канфігурацыі платформы яна была скарыстана як кропка размяшчэння падсістэм другога этапу (прылады DSO, контуры распрацоўкі раздробных сістэм). Былі створаны неабходныя наборы пайплайнаў - стварэнне, выдаленне, змяненне, рэзервовае капіраванне віртуальных машын. Дадзеныя пайплайны выкарыстоўваліся як першы этап працэсу дэплою.
Вынік - прадастаўленае абсталяванне не адпавядае патрабаванням банка па прадукцыйнасці і адмоваўстойлівасці. ДІТ банка прыняў рашэнне аб стварэнні комплексу на базе ПАК Nutanix.
этап 2. Узялі стэк, які быў вызначаны, і для ўсіх падсістэм напісалі скрыпты аўтаматызаванай усталёўкі і постканфігурацыі, каб з пілота ў мэтавы контур усё перанеслася як мага хутчэй. Усе сістэмы былі разгорнутыя ў адмоваўстойлівай канфігурацыі (дзе гэтая магчымасць не абмяжоўваецца ліцэнзійнымі палітыкамі вендара), падлучаныя да падсістэм збору метрык і падзей. ИБ прааналізавала адпаведнасць сваім патрабаванням і дала зялёнае святло.
этап 3. Міграцыя ўсіх падсістэм і іх налад на новы ПАК. Скрыпты аўтаматызацыі інфраструктуры былі перапісаны, і перанос падсістэм DSO быў выкананы ў цалкам аўтаматызаваным рэжыме. Контуры распрацоўкі ІС былі пераствораны пайплайнамі каманд распрацоўкі.
Этап 4. Аўтаматызацыя ўстаноўкі прыкладнога ПЗ. Гэтыя задачы ставілі тымліды новых каманд.
Этап 5. Эксплуатацыя.
Аддалены доступ
Каманды распрацоўкі прасілі максімальнай гнуткасці ў працы з контурам, і патрабаванне выдаленага доступу з асабістых наўтбукаў было пастаўлена на самым пачатку праекта. У банку ўжо быў выдалены доступ, але ён не падыходзіў для распрацоўшчыкаў. Справа ў тым, схема выкарыстоўвала падлучэнне карыстальніка да абароненага VDI. Гэта падыходзіла для тых, каму на працоўным месцы было дастаткова пошты і пакета офіса. Распрацоўнікам спатрэбіліся б цяжкія кліенты, высокапрадукцыйныя, з вялікай колькасцю рэсурсаў. І вядома, яны павінны былі быць статычнымі, бо страта карыстацкай сесіі для тых, хто працуе з VStudio (напрыклад) ці іншым SDK, недапушчальная. Арганізацыя вялікай колькасці тоўстых статычных VDI для ўсіх каманд распрацоўкі моцна падаражала існае рашэнне VDI.
Вырашылі прапрацоўваць выдалены доступ напрамую да рэсурсаў сегмента распрацоўкі. Jira, Wiki, Gitlab, Nexus, стэнды зборкі і тэсціравання, віртуальная інфраструктура. Бяспекі выставілі патрабаванні, што доступ можа быць арганізаваны толькі пры ўмове захавання наступнага:
- З выкарыстаннем ужо існуючых у банку тэхналогій.
- Інфраструктура не павінна выкарыстоўваць існуючыя дамен-кантролеры, якія захоўваюць запісы аб прадуктыўных уліках аб'ектах.
- Доступ павінен быць абмежаваны толькі тымі рэсурсамі, якія патрабуюцца вызначанай камандзе (каб каманда аднаго прадукта не магла атрымаць доступ да рэсурсаў іншай каманды).
- Максімальны кантроль за RBAC'ам у сістэмах.
У выніку быў створаны асобны дамен для дадзенага сегмента. У гэтым дамене размяшчаліся ўсе рэсурсы сегмента распрацоўкі як уліковыя дадзеныя карыстальнікаў, так і інфраструктура. Кіраванне жыццёвым цыклам запісаў у дадзеным дамене адбываецца з выкарыстаннем існага ў слоіку IdM.
Непасрэдна аддалены доступ быў арганізаваны на базе існуючага абсталявання банка. Кіраванне доступамі было разведзена па групах AD, якім адпавядалі правілы на кантэкстах (адна прадуктовая група = адна група правілаў).
Упраўленне шаблонамі VM
Хуткасць стварэння контуру зборкі і тэставанні - адзін з асноўных KPI, пастаўленых кіраўніком блока распрацоўкі, бо хуткасць падрыхтоўкі асяроддзя непасрэдна ўплывае на агульны час выкананне пайплайну. Разглядаліся два варыянты падрыхтоўкі базавых выяў VM. Першы - мінімальныя памеры выявы, дэфолтныя для ўсіх прадуктаў сістэм, максімальнае адпаведнасць палітыкам банка па наладах. Другі - базавая выява, утрымоўвальны ў сабе ўсталяванае цяжкавагавае ПОППО, час усталёўкі якога магло моцна ўплываць на хуткасць выканання пайплайна.
Патрабаванні інфраструктуры і бяспекі таксама ўлічваліся пры распрацоўцы - падтрыманне выяў у актуальным стане (патчы і інш.), інтэграцыя з SIEM, налады бяспекі па прынятых у банку стандартах.
У выніку было прынята рашэнне выкарыстоўваць мінімальныя вобразы з мэтай мінімізацыі затрат на падтрымку іх у актуальным стане. Значна прасцей абнавіць базавую АС, чым ставіць патчы ў кожную выяву для новых версій ПОППО.
Па выніках быў сфарміраваны спіс з мінімальна патрабаванага набору аперацыйных сістэм, чыё абнаўленне праводзіцца камандай эксплуатацыі, а за абнаўленне ПАППО цалкам адказваюць скрыпты з пайплайна, а пры неабходнасці змяніць версію усталёўванага ПА – дастаткова ў пайплайн перадаць патрэбны тэг. Так, гэта патрабуе ад devops'a прадуктовай каманды больш складаных сцэнараў дэплою, але моцна скарачае час эксплуатацыі на падтрымку базавых выяў, якім магло б зваліцца на абслугоўванне больш за сотню базавых выяў VM.
Доступ у інтэрнэт
Яшчэ адным каменем спатыкнення з банкаўскай бяспекай стаў доступ з серады распрацоўкі да інтэрнэт-рэсурсаў. Прычым дадзены доступ можна разбіць на дзве катэгорыі:
- Інфраструктурны доступ.
- Доступ распрацоўшчыкам.
Інфраструктурны доступ быў арганізаваны шляхам праксіравання знешніх рэпазітараў Nexus'ам. Гэта значыць прамога доступу з віртуальных машын - не прадугледжвалася. Гэта дазволіла выйсці на кампраміс з ИБ, якая была катэгарычна супраць прадастаўлення любога доступу да знешняга свету з сегмента распрацоўкі.
Доступ распрацоўшчыкам да інтэрнэту патрабаваўся па цалкам зразумелых прычынах (stackoverflow). І хоць ва ўсіх каманд, як было вышэй сказана, быў выдалены доступ да контуру, не заўсёды зручна, калі з працоўнага месца распрацоўніка ў слоіку ў IDE ты не можаш зрабіць ctrl+v.
З ИБ былі дасягнуты дамоўленасці, што першапачаткова, на этапе тэсціравання, доступ будзе прадастаўлены праз банкаўскі проксі на базе white-list. Па заканчэнні праекта – доступ перавядуць на black-list. Былі падрыхтаваны вялізныя табліцы доступаў, у якіх былі пазначаны асноўныя рэсурсы і рэпазітары, да якіх спатрэбіўся доступ на старце праекта. Узгадненне дадзеных доступаў займала прыстойнае час, што дазваляла настойваць на максімальна хуткім пераходзе на блэк-лісты.
Вынікі
Праект скончыўся крыху менш за год таму. Як гэта ні дзіўна, але ўсе падрадчыкі своечасова перайшлі на новы стэк і ніхто не сышоў з-за новай аўтаматызацыі. ИБ не спяшаецца дзяліцца пазітыўнымі водгукамі, але і не скардзіцца, з чаго можна зрабіць выснову, што ім падабаецца. Канфлікты пацішэлі, таму што ИБ зноў адчувае кантроль, але пры гэтым не мяшае працэсам распрацоўкі. На каманды патрапіла больш адказнасці, і ў цэлым стаўленне да ИБ стала лепш. Банк разумеў, што пераход на DevSecOps амаль непазбежны, і зрабіў гэта, на мой погляд, найболей мякка і правільна.
Аляксандр Шубін, сістэмны архітэктар.
Крыніца: habr.com