Задача, которую ставит перед разработкой современный бизнес, — максимально ускорить выход продукта на рынок. Решить её помогает 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-сертификатов, а быстро реагировать на инциденты безопасности позволяют аудит событий в кластере и детально проработанный мониторинг.