Знакомимся с DevSecOps: что это и зачем нужно

~ 8 мин

Задача, которую ставит перед разработкой современный бизнес, — максимально ускорить выход продукта на рынок. Решить её помогает Agile-подход, когда все этапы жизненного цикла приложения (SDLC, Software Development Life Cycle) делятся на небольшие задачи, которые выполняются в ходе коротких спринтов. Таким образом, планирование, написание кода, его сборка, тестирование, развёртывание, эксплуатация и мониторинг выполняются постоянно и параллельно друг другу. Это позволяет регулярно выпускать релизы и непрерывно работать над продуктом.

Agile увеличивает скорость разработки, но сам по себе не гарантирует её качества. Чтобы выпускать качественное приложение, требуется не просто параллельная работа, а тесное взаимодействие всех команд. За такое взаимодействие сейчас отвечает методология DevOps, у которой не так давно появилась разновидность (или расширение) — DevSecOps.

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

В чём разница между DevOps и DevSecOps

Основной смысл DevOps — непрерывная, конвейерная разработка, при которой команды Development (планирование, программирование, сборка, тестирование) и Operations (развёртывание, эксплуатация, мониторинг) тесно сотрудничают на всех этапах работы. Таким образом, специалисты работают не обособленно, а знают о задачах друг друга и могут влиять на решения коллег, то есть представляют себе весь цикл создания и обслуживания приложения.

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

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

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

Однако делать сложный выбор между скоростью и безопасностью не придётся, если грамотно внедрить методологию DevSecOps.DevSecOps (Development + Security + Operations) — это такое расширение DevOps, при котором обеспечение безопасности «вшивается» в SDLC и становится частью всех его этапов. Безопасность, которая традиционно находилась в самом конце цепочки (то есть «справа»), теперь сдвигается «влево», ближе к её началу, а задачи безопасности становятся рутинными задачами в цикле Agile.

Цель DevSecOps — внедрять практики безопасности в DevOps так, чтобы это не затягивало сроки и не уменьшало эффективность разработки, то есть максимально быстро выпускать безопасные приложения.

Как работает DevSecOps

Кратко рассмотрим, как безопасность вписывается во все этапы SDLC.

Планирование

На этом шаге специалисты по безопасности наравне с другими командами оценивают требования бизнеса к приложению, просчитывают потенциальные риски и составляют общие требования к безопасности с учётом таких стандартов, как ISO/IEC 15408, ISO/IEC 27034, ГОСТ Р 56939-2016, приказов ФСТЭК России и других отраслевых стандартов и методологий.

Разработка

Требования безопасности учитываются уже на этапе написания кода. В этом разработчикам помогает SAST (Static Application Security Testing, статическое тестирование безопасности приложений). Инструменты SAST часто встроены прямо в среду разработки. Они в режиме реального времени подсвечивают проблемные места в коде и создают отчёты об уязвимостях. Программисты анализируют их и исправляют недочёты.

Код также может проходить ревью, когда его вручную проверяют другие программисты.

Сборка и тестирование

Когда код готов, его собирают для развёртывания в тестовой или рабочей среде: проверяют, не попали ли в код пароли или API-ключи, подключают нужные зависимости (библиотеки, плагины), упаковывают конфигурационные файлы.

На этом шаге к SAST присоединяются DAST (Dynamic Application Security Testing, динамическое тестирование) и IAST (Interactive Application Security Testing, интерактивное тестирование), а также SCA (Software Component Analysis, анализ компонентов ПО).

DAST работает на уже собранном и запущенном приложении. Оно анализирует пользовательские сессии и аутентификацию, работу внешних компонентов, расход памяти, возможность внедрения сторонних данных и др.

SCA-тесты проверяют на уязвимости внешние компоненты и зависимости, которые используются в приложении.

IAST совмещает в себе черты SAST, DAST и SCA и может анализировать как статичный, так и уже запущенный код. Оно работает с потоками данных, внешними компонентами, настройками конфигурации, запросами и подключениями.

Развёртывание

Верный способ минимизировать ошибки и уязвимости при развёртывании — применять подход Infrastructure as Code (инфраструктура как код). В этом случае все необходимые ресурсы (серверы, сети, базы данных) настраиваются не вручную, а автоматически с помощью скриптов. Это позволяет избежать человеческих ошибок при настройке инфраструктуры.

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

Эксплуатация и мониторинг

Развёрнутое приложение может самостоятельно защищаться от атак с помощью механизма RASP (Run-time Application Security Protection). Такие инструменты встраиваются в код ещё на этапе разработки, а используются уже при эксплуатации. Они отслеживают трафик, поведение пользователей, запросы к приложению и могут предотвращать угрозы.

Кроме RASP, за безопасностью приложения следят системы непрерывного мониторинга. Если они замечают аномалии, то тут же отправляют уведомления и отчёты специалистам по безопасности, чтобы те могли как можно быстрее разобраться в инциденте.

Почему DevSecOps актуален и зачем его внедрять

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

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

Представим обычный сервис бронирования путешествий. В нём есть разделы с поиском и бронированием жилья, управлением платежами и пользователями, чатами с провайдерами жилья и поддержкой сервиса, отзывами клиентов и т. д. Все эти разделы распределены по микросервисам. 

А поскольку микросервисы не зависят друг от друга, команда разработки, например, раздела оплаты может спокойно обновить только свою часть — для этого не нужно синхронизироваться с другими командами и можно не бояться, что обновления повлияют на другие разделы. Также благодаря такому подходу приложение целиком становится более надёжным: если один компонент, например блок с отзывами, выйдет из строя, остальные продолжат работать.Как правило, микросервисы существуют в контейнерах — изолированных средах, которые содержат все необходимые микросервису ресурсы (библиотеки, зависимости и т. д.). Чтобы многочисленные контейнеры адекватно взаимодействовали, ими нужно управлять. Это можно делать, например, с помощью Kubernetes, в котором контейнеры организуются в кластер.

Мы намеренно упростили схему, но даже в таком виде очевидна многослойная структура. Это значит, что обеспечивать безопасность системы нужно на четырёх уровнях — по модели 4C:

  • код в микросервисе (Code);
  • контейнер (Container);
  • кластер (Cluster);
  • инфраструктура в целом (Cloud / Co-Lo / Corporate Datacenter).

Такая структура, как говорят специалисты по кибербезопасности, увеличивает поверхность атаки — количество точек, через которые злоумышленник может проникнуть в систему.

Микросервисная архитектура может подвергаться атакам с разных сторон, например:

  • перехват данных, которые передаются между микросервисами;
  • использование уязвимостей API, через которые общаются микросервисы;
  • эксплуатация недостаточно надёжных механизмов аутентификации и авторизации;
  • межсервисные атаки — если «заражён» один сервис, он может атаковать другие;
  • использование уязвимостей в контейнерах, в которых работают микросервисы, и средствах управления контейнерами.

По данным Positive Technologies на I квартал 2024 года, каждая третья атака на организации проводилась именно через эксплуатацию уязвимостей. Чаще всего от нападений хакеров страдали госучреждения, ИТ-компании, промышленные предприятия, медицинские и финансовые организации. Однако «чувствительные» данные (персональная, учётная и платёжная информация, коммерческая тайна), за которыми в основном и охотятся злоумышленники, могут быть у компании любого размера и из любой сферы. Поэтому, отодвигая вопросы безопасности на второй план, бизнес рискует в финансовом, репутационном и юридическом плане. 

Минимизировать эти риски помогают практики DevSecOps. Внедряя их, компания также получает следующие преимущества:

  • Быстрое и недорогое устранение уязвимостей. Чем раньше в коде обнаруживаются проблемы, тем проще их решать. Также это снижает вероятность того, что уязвимый код попадёт в рабочую версию приложения.
  • Сокращение времени на разработку. Поскольку проверка безопасности во многом автоматизирована, это сокращает время на ручное тестирование, а значит, разработка в целом идёт быстрее.
  • Рост лояльности клиентов. Если приложение работает без сбоев, быстро поставляется пользователям и отвечает их запросам, доверие клиентов к компании растёт.

Всё это в итоге положительно влияет на репутацию и прибыль компании.

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

Чтобы не тратить время на поиск таких инструментов, можно воспользоваться готовыми, гарантированно рабочими решениями. Как правило, они есть в платформах, которые расширяют встроенные возможности Kubernetes. Инструменты безопасности в платформе предварительно настроены — достаточно просто развернуть её, чтобы получить защищённый кластер. 

Одна из таких платформ — Deckhouse Kubernetes Platform. Её компоненты скачиваются напрямую из реестра вендора, используют только проверенные зависимости и регулярно сканируются на наличие уязвимостей. Безопасность самих приложений в контейнерах обеспечивают продвинутые настройки сети, прав пользователей и SSL-сертификатов, а быстро реагировать на инциденты безопасности позволяют аудит событий в кластере и детально проработанный мониторинг.