DevOps vs DevSecOps: как это выглядело в одном банке26.05.2020 15:32

oynk7pw97ofhpvx12dsi0qd56xa.jpeg

Банк аутсорсит свои проекты многим подрядчикам. «Внешники» пишут код, потом передают результаты в не совсем удобном виде. Конкретно процесс выглядел так: они передавали проект, который прошёл функциональные тесты у них, а затем тестировался уже внутри банковского периметра на интеграцию, нагрузку и так далее. Часто обнаруживалось, что тесты фейлятся. Тогда всё уходило обратно внешнему разработчику. Как вы можете догадаться, это означало большие сроки исправления ошибок.

Банк решил, что можно и нужно перетащить весь пайплайн к себе «под крылышко» от коммитов до выпуска. Чтобы всё было единообразно и под контролем команд, отвечающих за продукт в банке. То есть как если бы внешний подрядчик просто работал где-то в соседней комнате офиса. На корпоративном стеке. Это обычный девопс.

Откуда появилось Sec? Безопасность банка выставила высокие требования к тому, как внешний подрядчик может работать в сетевом сегменте, какой у кого доступ, как и кто работает с кодом. Просто ИБ ещё не знала, что когда подрядчики работают снаружи, мало какие банковские стандарты соблюдаются. А тут за пару дней надо их начать соблюдать всем.

Одно простое откровение, что подрядчик имеет полный доступ к коду продукта, уже перевернуло их мир.

В этот момент и началась история DevSecOps, про которую я хочу рассказать.

Какие банк сделал практические выводы из этой ситуации


Было много споров про то, что всё делается в сфере не так. Разработчики говорили, что безопасность занята только попытками помешать разработке, и они как вахтёры стараются запрещать, не думая. В свою очередь безопасники колебались между тем, что бы выбрать между точками зрения: «разработчики создают уязвимости в нашем контуре» и «разработчики не создают уязвимости, а сами ими являются». Спор бы продолжался долго, если бы не новые требования рынка и появление парадигмы DevSecOps. Удалось объяснить, что эта самая автоматизация процессов с учётом требований ИБ «из коробки» поможет всем остаться довольными. В смысле, что правила записываются сразу и не меняются по ходу игры (ИБ не будет запрещать что-то неожиданно), а разработчики держат в курсе ИБ про всё происходящее (ИБ не сталкивается с чем-то внезапно). За конечную безопасность отвечает ещё и каждая команда, а не некие абстрактные старшие братья.

  1. Раз уж внешние сотрудники уже имеют доступ к коду и ряду внутренних систем, наверное, можно убрать из документов требование «разработка должна вестись полностью на инфраструктуре банка».
  2. С другой стороны, нужно усилить контроль над тем, что происходит.
  3. Компромиссом стало создание кросс-функциональных команд, когда сотрудники тесно работают со внешними людьми. В этом случае нужно сделать так, чтобы команда работала на инструментах на серверах банка. От начала до конца.


То есть подрядчиков можно пускать, но нужно сделать им отдельные сегменты. Чтобы они не притащили снаружи какую-то заразу в инфраструктуру банка и чтобы не видели больше необходимого. Ну и чтобы их действия логировались. DLP для защиты от «сливов», всё вот это прикладывалось.

В принципе, к этому приходят все банки рано или поздно. Тут пошли проторенной дорожкой и согласовали требования к таким средам, где работают «внешники». Там появился максимальный набор средств контроля доступа, средств проверок уязвимостей, антивирусный анализ на контурах, на сборках и тестах. Это и назвали DevSecOps.

Внезапно выяснилось, что если до этого DevSecOps банковская безопасность не имела контроля над тем, что происходит на стороне разработчика, то в новой парадигме безопасность контролируется точно так же, как обычные события на инфраструктуре. Только теперь есть алерты на сборках, контроль библиотек и так далее.

Осталось только перевести команды на новую модель. Ну и создать инфраструктуру. Но это уже мелочи, это как нарисовать сову. Собственно, мы помогали с инфраструктурой, а в это время менялись процессы разработки.

Что менялось


Решили внедрять небольшими шагами, потому что понимали, что многие процессы развалятся, а многие «внешники» могут не выдержать новые условия труда под присмотром всех желающих.

Сначала создали кросс-функциональные команды и научились организовывать проекты с учётом новых требований. В смысле организационно обсудили, какие процессы. Получилась схема пайплайна сборки со всеми ответственными.

  • CI: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
  • CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
  • Test: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Centre, MF UFT, Ataсcama.
  • Presentation (отчётность, коммуникация): Grafana, Kibana, Jira, Confluence, RocketChat.
  • Operations (сопровождение, управление): 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, стенды сборки и тестирования, виртуальная инфраструктура. Безопасники выставили требования, что доступ может быть организован только при условии соблюдения следующего:

  1. С использованием уже имеющихся в банке технологий.
  2. Инфраструктура не должна использовать существующие домен-контроллеры, которые хранят записи о продуктивных учётках\объектах.
  3. Доступ должен быть ограничен только теми ресурсами, которые требуются определённой команде (чтобы команда одного продукта не могла получить доступ к ресурсам другой команды).
  4. Максимальный контроль за RBAC'ом в системах.


В итоге был создан отдельный домен для данного сегмента. В этом домене располагались все ресурсы сегмента разработки как учётные данные пользователей, так и инфраструктура. Управление жизненным циклом записей в данном домене происходит с использованием существующего в банке IdM.

Непосредственно удалённый доступ был организован на базе существующего оборудования банка. Управление доступами было разведено по группам AD, которым соответствовали правила на контекстах (одна продуктовая группа = одна группа правил).

Управление шаблонами VM


Скорость создания контура сборки и тестирования — один из основных KPI, поставленных руководителем блока разработки, ведь скорость подготовки среды непосредственно влияет на общее время выполнение пайплайна. Рассматривались два варианта подготовки базовых образов VM. Первый — минимальные размеры образа, дефолтные для всех продуктов\систем, максимальное соответствие политикам банка по настройкам. Второй — базовый образ, содержащий в себе установленное тяжеловесное ПО\ППО, время установки которого могло сильно влиять на скорость выполнения пайплайна.

Требования инфраструктуры и безопасности также учитывались при разработке — поддержание образов в актуальном состоянии (патчи и пр.), интеграция с SIEM, настройки безопасности по принятым в банке стандартам.

В итоге было принято решение использовать минимальные образы с целью минимизации затрат на поддержку их в актуальном состоянии. Гораздо проще обновить базовую ОС, чем ставить патчи в каждый образ для новых версий ПО\ППО.

По результатам был сформирован список из минимально требуемого набора операционных систем, чьё обновление проводится командой эксплуатации, а за обновление ПО\ППО полностью отвечают скрипты из пайплайна, а при необходимости изменить версию устанавливаемого ПО — достаточно в пайплайн передать нужный тег. Да, это требует от devops’a продуктовой команды более сложных сценариев деплоя, но сильно сокращает время эксплуатации на поддержку базовых образов, которым могло бы свалиться на обслуживание больше сотни базовых образов VM.

Доступ в интернет


Ещё одним камнем преткновения с банковской безопасностью стал доступ из среды разработки к интернет-ресурсам. Причём данный доступ можно разбить на две категории:

  1. Инфраструктурный доступ.
  2. Доступ разработчикам.


Инфраструктурный доступ был организован путём проксирования внешних репозиториев Nexus'ом. То есть прямого доступа с виртуальных машин — не предусматривалось. Это позволило выйти на компромисс с ИБ, которая была категорически против предоставления любого доступа к внешнему миру из сегмента разработки.

Доступ разработчикам к интернету требовался по вполне понятным причинам (stackoverflow). И хотя у всех команд, как было выше сказано, был удалённый доступ к контуру, не всегда удобно, когда с рабочего места разработчика в банке в IDE ты не можешь сделать ctrl+v.

С ИБ были достигнуты договорённости, что первоначально, на этапе тестирования, доступ будет предоставлен через банковский прокси на базе white-list. По окончании проекта — доступ переведут на black-list. Были подготовлены огромные таблицы доступов, в которых были указаны основные ресурсы и репозитории, к которым потребовался доступ на старте проекта. Согласование данных доступов занимало приличное время, что позволяло настаивать на максимально быстром переходе на блэк-листы.

Результаты


Проект закончился чуть меньше года назад. Как это ни странно, но все подрядчики вовремя перешли на новый стек и никто не ушёл из-за новой автоматизации. ИБ не спешит делиться позитивными отзывами, но и не жалуется, из чего можно сделать вывод, что им нравится. Конфликты поутихли, потому что ИБ снова чувствует контроль, но при этом не мешает процессам разработки. На команды попало больше ответственности, и в целом отношение к ИБ стало лучше. Банк понимал, что переход на DevSecOps почти неизбежен, и сделал это, на мой взгляд, наиболее мягко и правильно.

Александр Шубин, системный архитектор.

© Habrahabr.ru