Практические ответы на нетривиальные вопросы, или Как внедрять DevSecOps в организации со сложным IT-ландшафтом

В настоящий момент в рамках реализации новой стратегии развития и цифровой трансформации ВТБ активно внедряет DevOps, интегрирует в инженерный процесс практики разработки защищенного программного обеспечения, повышает уровень автоматизации, оптимизирует рутинные производственные процессы. Цель этих изменений можно сформулировать в трех ключевых тезисах: скорость, надежность и эффективность. Естественно, при проведении столь глобальных преобразований важным становится проведение открытых неформальных встреч, в рамках которых можно поделиться собственным опытом, обсудить различные развилки и нюансы внедрения тех или иных производственных практик. Митапы — отличный формат для повышения общей вовлеченности, осведомленности и обмена опытом как с коллегами из банка, так и с партнерами из других компаний. 

Под катом — самое интересное с первого митапа ВТБ «DevSecOps: практические ответы на нетривиальные вопросы», который прошел в ноябре на площадке WeWork. Во встрече приняли участие более 200 специалистов.

Как все начиналось

Как известно, ВТБ — второй банк в России по числу клиентов, активам и финансовым показателям. С 2018 года банк в рамках стратегии развития начал активно менять свой технологический курс и принял решение о постепенном переходе к внутреннему (in-house) развитию IT-систем. До этого большинство систем и решений поставляли вендоры. Теперь же стало важным повысить качество, безопасность и скорость поставок за счет формирования внутренних команд и построения собственного производственного IT-процесса. Все вроде бы просто и понятно: есть кейсы, есть решения — бери и внедряй.

Но в реальности все гораздо сложнее. На этом пути банку пришлось столкнуться с множеством трудностей. Об этом рассказал в своем докладе Игорь Шваков, начальник управления автоматизации процесса разработки ВТБ.

Главный вызов — уникальность ВТБ с точки зрения IT. Исторически банк развивался за счет приобретения и интеграции крупных игроков, у каждого из которых была своя IT-архитектура, «железо», бизнес-процессы и т. д. С 2018 года ВТБ, ВТБ24 и Банк Москвы стали единым ВТБ со своим уникальным IT-ландшафтом, разнородной, а где-то и разрозненной инфраструктурой. Естественно, проводить трансформационные изменения, одновременно наращивать бизнес (такова бизнес-стратегия) и внедрять DevOps (и тем более DevSecOps) в подобных условиях — нетривиальная история. 

Первая сложность, которая возникла в самом начале, — большое количество вендоров и, как следствие, узкая собственная компетенция. Нам нужно было перевести внешних подрядчиков, которые работали вне периметра, на инфраструктуру и процессы банка. Вторая сложность — бизнес-заказчики требовали активного развития IT-систем, чтобы обеспечивать достижение высоких бизнес-показателей. Поэтому нам приходилось работать в ситуации растущей транзакционной активности клиентов и высокой интеграционной зависимости систем.

Изначально мы планировали осуществлять переход на рельсы in-house постепенно: выбрать системы и определить цели, затем подготовить команды и инфраструктуру, а на последнем этапе выбрать инструменты и настроить DevSecOps Pipeline. Но в реальности нам пришлось делать все и сразу, а заодно решать возникающие проблемы.

Опыт тиражирования системы

Поскольку у нас отсутствовала инфраструктура для in-house разработки, было решено все виртуализировать и перейти на архитектуру х86 для минимизации стоимости и затрат. В результате была построена инфраструктурная платформа на базе уже имевшегося гиперконвергентного решения Nutanix, и все средства разработки мы максимально перевели на нее.

Но железо железом, а работают на нем люди. В связи с этим встал вопрос, как формировать команды. Мы решили остановиться на следующих соотношениях: на двух разработчиков in-house должен приходиться один технолог, на команду из 10 разработчиков — один DevOps-инженер и два тестировщика-автоматизатора. Это то, к чему мы пришли на собственном опыте, работая с более чем двумя десятками систем. И такой подход оказался весьма эффективным.

Следующий интересный вопрос — как перевести системы в контур банка?
Как правило, стандартный цикл перевода одной системы занимает 7–8 месяцев. Он раскладывается следующим образом. 

• В течение первых двух месяцев идет подбор персонала. Одновременно анализируются договорные отношения с внешними подрядчиками на предмет возможности перевода их на работу в контур банка.
• К третьему месяцу формируется ключевая компетенция по системе и укомплектовывается DevOps-команда в части разработки, настройки pipeline и автоматизированного тестирования. Параллельно регламентируются и предоставляются доступы к информационным системам для внешних команд. 
• Четвертый месяц — обучение команды и передача кода в репозиторий банка от вендора. 
• Пятый — совместная разработка командами банка и внешнего подрядчика, тонкий тюнинг Pipeline и запуск первых поставок по нему.
• На шестой и седьмой месяцы проходят пилотные доработки через весь процесс уже непосредственно на инфраструктуре банка.
• Результат — на седьмой месяц совместная команда работает уже внутри одного контура разработки в банке.

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

На данный момент в банке уже работают больше двадцати команд разработки (более 500 штатных и внешних разработчиков), каждая из которых использует свой pipeline в части CI. Для большей части данных команд реализован этап CD. Также есть несколько систем, которые уже используют автоматическую доставку изменений на промышленные контуры.

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

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

Сейчас процесс набирает обороты, добавляются новые системы, стандартизируется технологический стек, единые этапы pipeline, отчетность, правила работы. Также переходит на новый уровень зрелости подход к тиражированию практик на другие команды и блоки банка, оптимизируются процессы, уточняются необходимые роли и компетенции внутри команд, ответственность участников. В общем, процесс тиражирования поставлен на рельсы и превращается из startup внутри большого банка в технологичное enterprise решение. Этот путь был пройден чуть больше чем за полтора года от момента монтажа железа в ЦОД до выката изменений в автоматическом режиме на промышленный или предпромышленный контур.

Подводные камни

В рамках новой стратегии ВТБ переход к практикам DevSecOps был выделен как один из стратегических стримов на уровне всего банка. Подробнее об этом в своем докладе рассказал Александр Калабухов, руководитель Центра инженерных практик Управления развития систем IT-производства и сопровождения ВТБ.

Было решено трансформировать службы, занимающиеся разработкой, тестированием и эксплуатацией, в кросс-функциональные команды, работающие над одной бизнес-функциональностью. Команды включают в себя специалистов по архитектуре и разработке, технологов, тестировщиков и DevOps-инженеров. В централизованных службах осталось только то, что обладает уникальными компетенциями или живет в уникальном ритме (24/7) — прикладное и системное администрирование, информационная безопасность.

Такой переход к кросс-функциональным командам предъявляет новые требования к процессам управления кодом (исходным, тестирования, развертывания и т. д.), управления тестированием и разработкой. Там, где ранее были допустимы разрывы в процессах, сейчас они становятся критическими препятствиями, и мы совершенствуем наш DevSecOps ландшафт в части инструментов и устранения разрывов в процессах.

Кстати, об инструментах. Одна из проблем заключается в том, что банки попадают под определенные регуляторные требования, связанные с банковской тайной и другими подобными ограничениями. Любая система в банке проходит стадию приемо-сдаточных испытаний на соответствие требованиям информационной безопасности, в том числе и в плане инструментов DevOps. К сожалению, большинство DevOps-инженеров никогда не работали в такой жесткой регламентированной среде, и они зачастую мало знают про аудит этих инструментов, про то, как должны быть ограничены сетевые доступы и доступ к данным, что делать с секретами, которыми обмениваются DevOps-инструменты и т. п.

Основная задача построения защиты данных внутри банка заключается в том, чтобы ни один человек не имел доступа сразу ко всем данным. Именно поэтому разработчики не могут выполнять функции прикладных и системных администраторов. Подобные ограничения есть и к DevSec-инженерам. Естественно, что никто из перечисленных специалистов не может быть администратором информационной безопасности. После того как определены все роли и периметр их полномочий, можно встраивать стандартный процесс предоставления прав DevOps-инструментов в общий процесс предоставления прав в банке. 

Важный аспект — сетевая безопасность. Необходимо выполнять правило, согласно которому устанавливать соединение можно только из более доверенных контуров в менее доверенные. Если процесс осуществляется в обратную сторону, необходимо обеспечивать сетевые разрывы с помощью специальных средств. Сетевые соединения должны быть безопасно установлены и еще зашифрованы между собой. Иначе возможно проникновение вирусов и другого вредоносного программного обеспечения по цепочке, что может привести к утечке данных и инцидентам на промышленных средах.

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

Поэтому, несмотря на все богатство имеющихся DevOps-инструментов, приходится проводить их стандартизацию. При правильном подходе информационная безопасность в банке вносит ограничения в процесс разработки и эксплуатации, но не препятствует внедрению новых технологий.

Кибербезопасность превыше всего

В условиях трансформации бизнеса и сокращения времени вывода новых цифровых продуктов на рынок основным индустриальным вызовом становится обеспечение информационной безопасности на всех этапах непрерывного производственного процесса. Теме интеграции практик разработки защищенного ПО в DevOps был посвящен доклад Юрия Сергеева, управляющего партнера Swordfish Security и лидера DevSecOps-индустрии в России.
Реализация парадигмы кибербезопасности в DevOps представляет собой достаточно сложный процесс, в рамках которого слой Security-практик как бы обволакивает весь производственный инженерный цикл. Сами практики обеспечения информационной безопасности поддерживаются инструментальным стеком, интегрированным во все этапы технологического процесса.

К необходимым практикам ИБ относятся:

• Контроль компонент с открытым исходным кодом при попадании в периметр разработки (Open Source Analysis, OSA);
• Статический анализ кода (Static Application Security Testing, SAST);
• Контроль состава компонент ПО (Software Composition Analysis, SCA);
• Все виды динамического анализа (Dynamic Application Security Testing, DAST / Interactive Application Security Testing, IAST / Behavioral Application Security Testing, BAST);
• Анализ бинарного кода и контроль состава контейнеров (Bytecode and Container Analysis, BCA);
• Реализация WAF (Web Application Firewall).

В то же время важнейшими аспектами при масштабировании и трансформации DevOps процессов в производную парадигму DevSecOps являются:
 

• Использование безопасных по умолчанию библиотек, фреймворков и компонент ПО в процессе разработки (Secure-by-Default);
• Интеграция технологических практик ИБ в самое начало конвейера CI/CD (Shift-Left подход);
• Автоматизация всех процессов в концепции Everything-as-a-Code; 
• Формирование сообщества security-чемпионов, которые отвечают за задачи информационной безопасности в производственных командах и являются проводниками инженерной security-культуры;
• Применение модели зрелости DevSecOps как для оценки существующего процесса, так и для постоянного совершенствования;
• Обеспечение прозрачности всех security активностей для всех участников инженерного производственного процесса.

Отдельно стоит акцентировать внимание на важности практики DevSecOps-оркестрации (Application Security Testing Orchestration, ASTO), реализующей сквозную интеграцию инструментального стека ИБ с инструментами разработки, автоматизированное управление security-конвейером (пайплайнами), а также сбор,  консолидацию и анализ всех данных в рамках непрерывного процесса разработки защищенного ПО. Практика оркестрации позволяет значительно сэкономить ресурсы и сократить более чем в 10 раз общее время внедрения инициативы DevSecOps в сложных гетерогенных инженерных окружениях. 

Если же говорить о трансформации в целом, то можно выделить следующие ключевые факторы успеха: 

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