Банката възлага своите проекти на много контрагенти. „Външните“ пишат код, след което предават резултатите в не много удобна форма. По-конкретно процесът изглеждаше така: те предадоха проект, който премина функционални тестове с тях и след това беше тестван в банковия периметър за интеграция, натоварване и т.н. Често се откриваше, че тестовете се провалят. След това всичко се върна при външния разработчик. Както можете да предположите, това означаваше дълги срокове за корекции на грешки.
Банката реши, че е възможно и необходимо да привлече целия тръбопровод под крилото си, от ангажиментите до освобождаването. За да бъде всичко еднообразно и под контрола на екипите, отговарящи за продукта в банката. Тоест, сякаш външният изпълнител просто работи някъде в съседната стая на офиса. На корпоративния стек. Това е обикновен devops.
Откъде дойде Sec? Сигурността на банката е поставила високи изисквания към това как външен изпълнител може да работи в мрежовия сегмент, какъв достъп има някой, как и кой работи с кода. Просто IB все още не знаеше, че когато изпълнителите работят навън, се спазват малко банкови стандарти. И тогава след няколко дни всички трябва да започнат да ги наблюдават.
Простото разкритие, че изпълнителят е имал пълен достъп до кода на продукта, вече беше обърнало света им с главата надолу.
В този момент започна историята на 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. Взехме стека, който беше дефиниран, и написахме автоматизирани инсталационни и постконфигурационни скриптове за всички подсистеми, така че всичко да бъде прехвърлено от пилотната към целевата верига възможно най-бързо. Всички системи бяха внедрени в конфигурация, устойчива на грешки (където тази възможност не е ограничена от лицензионните политики на доставчика) и свързани с подсистеми за показатели и събиране на събития. IB анализира съответствието с изискванията си и даде зелена светлина.
Етап 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). И въпреки че всички команди, както беше споменато по-горе, имаха отдалечен достъп до веригата, не винаги е удобно, когато не можете да направите ctrl+v от работното място на разработчика в банката в IDE.
Беше постигнато споразумение с IS, че първоначално, на етап тестване, достъпът ще бъде осигурен чрез банково прокси на базата на бял списък. След завършване на проекта достъпът ще бъде прехвърлен към черния списък. Бяха изготвени огромни таблици за достъп, които посочваха основните ресурси и хранилища, до които беше необходим достъп в началото на проекта. Координирането на тези достъпи отне доста време, което направи възможно да се настоява за възможно най-бързия преход към черни списъци.
резултати
Проектът приключи преди малко по-малко от година. Колкото и да е странно, всички изпълнители преминаха към новия стек навреме и никой не напусна поради новата автоматизация. IB не бързат да споделят положителни отзиви, но и не се оплакват, от което можем да заключим, че им харесва. Конфликтите са утихнали, тъй като информационната сигурност отново се чувства под контрол, но не пречи на процесите на развитие. Екипите получиха повече отговорности, а цялостното отношение към информационната сигурност стана по-добро. Банката разбра, че преходът към DevSecOps е почти неизбежен и го направи, според мен, по най-нежния и правилен начин.
Александър Шубин, системен архитект.
Източник: www.habr.com