Что такое DevSecOps и как автоматизировать комплаенс

Что такое DevSecOps и как автоматизировать комплаенс

Согласно результатам нашего опроса, 25% пользователей Yandex Cloud используют облачную платформу для разработки. И это понятно, так как в облаке достаточно просто развернуть всё, что нужно для автоматизации разработки, тестирования, доставки и стабильной работы приложения.

Но как быть тем организациям, которым, кроме стандартных задач обеспечения защиты, необходимо контролировать соблюдение формальных требований по безопасности? Яркий пример — финтех-приложения, которые должны соответствовать множеству стандартов: 152-ФЗ, ГОСТ 57580, PCI DSS и другим. Это и раньше была непростая задача, а сейчас, когда жизненный цикл современных приложений настолько ускорился, что уже нет времени на проведение аудитов и контроль соответствия, проблем стало ещё больше. Поговорим о том, как соответствовать требованиям безопасности в условиях автоматизации разработки и непрерывной доставки приложений.

DevOps в облаке

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

Однако для наиболее эффективной и надёжной разработки программного обеспечения и его вывода на рынок требуется тесное взаимодействие разных команд: не только разработчиков и системных администраторов, но и специалистов по информационной безопасности. Автоматизация разработки приложений может включать в себя и учёт рисков безопасности, анализ кода и конфигураций, контроль безопасности и проверку на соответствие и соблюдение законодательства. Это особенно важно при создании и эксплуатации финтех-приложений (рис. 1).

Рисунок 1. Автоматизация разработки и доставки приложения в облачных платформах

Sec в DevOps: Концепция Shift-left

Почему безопасностью нужно заниматься как можно раньше? Как правило, разработчики создавали версию приложения, и только затем тестировщики и специалисты по безопасности проводили анализ её защищённости. Но в условиях, когда в командах разработки практикуется методология непрерывной интеграции и развёртывания кода (CI/CD), длительные задержки на проверку ИБ становятся недопустимыми. Более того, внедрение сложнее. Присутствие специалистов по ИБ требуется на всех этапах разработки.

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

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

Рисунок 2. Стоимость исправления ошибок на различных этапах жизненного цикла разработки приложения

В облаках на всех этапах — разработка кода, сборка образа и разворачивание контейнеров — есть сервисы, которые помогают не только автоматизировать процессы, но и обеспечить контроль безопасности. Например, управляемые GitLab или Kubernetes. В этих продуктах большое количество инструментов и подходов к обеспечению безопасности, контроля безопасности, различные плагины и инструменты (рис. 2).

Как построить безопасный процесс разработки и соответствовать требованиям

Вернёмся к финтех-приложению. Ему необходимо соответствовать сразу многим законам, положениям и отраслевым стандартам.

Для упрощения разделим жизненный цикл разработки приложения на три основных этапа (рис. 3):

Рисунок 3. Основные задачи обеспечения безопасности приложения в условиях автоматизации

Этап безопасной разработки

Начинать нужно с обучения разработчиков. Подготовить гайды и рекомендаций по безопасному программированию с примерами на ваших языках. Это поможет не допускать типовых и простых ошибок в самом начале пути. Материалы должны находиться всегда под рукой. Мы в Yandex Cloud внутри храним такие практики на внутреннем портале Yandex Wiki. Это сервис для создания корпоративной базы знаний, которую наполняют и обновляют сами сотрудники компании. А для планирования и обсуждения деталей используем Yandex Tracker — сервис для управления проектами и процессами.

Этап безопасного развёртывания приложения

Безопасное развёртывание приложений можно разделить на три части.

• Управление изменениями. Простое правило: всё, что попадёт в продакшен, должно подтверждаться «незаинтересованной стороной». Например, код-ревью должен выполнить тот, кто не принимал участия в разработке. Апдейты — протестированы. Процесс — прозрачен, чтобы при запросе показать его аудиторам.
• Управление уязвимостями. В продакшен не должны попадать уязвимости, в том числе уязвимые third-party-компоненты. Их нужно вовремя обнаруживать, ранжировать по критичности и исправлять. Самые требовательные стандарты требуют, что патч, исправляющий уязвимость, нужно установить не позднее 30 дней после его выхода. Для поиска уязвимых компонентов в YandexCloud есть сканер, который встроен в сервис Container Registry. А включение динамического и статического анализатора кода из Managed Service for GitLab поможет сделать исходный код безопаснее.
• Управление ключами и секретами. Ключи и секреты нужно хранить и передавать так, чтобы злоумышленник не смог к ним добраться. «Хардкодить» такие данные — очень плохая практика. Для управления секретами в YandexCloud есть сервисы KMS и Lockbox. KMS в том числе защищает секреты, которые хранятся в кластере Kubernetes. Правильно построенный процесс и использование этих инструментов позволят легко пройти любой аудит.

Этап защиты инфраструктуры

Это защита вашего работающего продакшен-кластера. Возьмём несколько базовых процессов:

• Управление доступом. Если вы в облаке, то используете IAM. В IAM есть роли, и чтобы соответствовать требованиям, нужно, чтобы вы на своей стороне соблюдали принцип минимальных полномочий. То есть давали доступ только тому, кому он необходим.
• Сетевая безопасность. Среду тестирования необходимо отделить от среды продакшен. Например, в Yandex Cloud есть VPC с механизмами Security Group. Эта связка очень выгодная не только со стороны ограничения сетевого трафика. Вам не нужно думать, какой вендор ушёл или какое сетевое устройство отключилось. Просто настраивайте группы безопасности и управляйте правилами фаервола и потоками трафика.
• Управление инцидентами. Сбор логов аудита, корреляция, алерты — это всё требуется многими стандартами. Для того чтобы соответствовать требованиям и строить безопасность, в облаке есть много инструментов. Например, Cloud Trail и Cloud Logging. А свою систему мониторинга событий безопасности можно построить на базе Yandex Audit Trails и интеграции сервисов Yandex Managed Service for Elasticsearch или Yandex Managed Open Search.

Автоматизация контроля соответствия требованиям

По всему жизненному циклу можно использовать как продукты Yandex Cloud, так и различные наложенные средства для контроля соответствия требованиям в рамках всё той же концепции shift-left. Например, Checkov, разработанный компанией Bridge Crew, сканирует конфигурации облачной инфраструктуры, которая управляется в разных средах виртуализации и контейнеризации таких как Kubernetes и выявляет ошибки с точки зрения безопасности и соответствия требований и стандартов. Также инструмент позволяет написать и добавить собственные проверки, что позволяет контролировать актуальную версию приложения намного эффективнее. Есть в Checkov и автоматическое исправление обнаруженных уязвимостей, что имеет особую практическую значимость на этапе развёртывания уже написанного кода.

С недавних пор Checkov поддерживает Yandex Cloud и содержит целый перечень проверок, которые можно использовать для контроля соблюдения нормативных требований. К примеру, PSI DSS требует в некотором контексте отсутствие наличия публичных IP-адресов для некоторых компонентов или шифрования. Вы можете автоматизировать эту проверку на этапе развёртывания уже написанного кода (рис. 4).

Рисунок 4. Соответствие требований PCI DSS cпомощью проверок Checkov

Но кроме Checkov, есть целый набор инструментов, которые дают возможность контролировать соответствие развёрнутой инфраструктуры требованиям безопасности, такие как Falco и Kyverno (рис. 5).

Рисунок 5. Сравнение инструментов безопасности в контексте контролей PCI DSS

Кроме опенсорс-приложений, можно подключить и корпоративные системы мониторинга. Например, MaxPatrol позволяет контролировать события безопасности в финтех-инфраструктуре. А контролировать соответствие всего облака можно с помощью класса решений CSPM (Cloud Security Posture Management). На российском рынке представлены NeoCat и Cloud Advisor (рис. 6).

Рисунок 6. Автоматизация задач соответствия требованиям

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

Безопасная разработка в облаке — это реально

Сейчас в разработке складывается такая ситуация, что нужно ускоряться и максимально всё автоматизировать. Что делать с безопасностью? Либо принимать риски, либо вливаться в процесс DevOps, хорошо, что сейчас есть все инструменты для безопасности. С внедрением DevSecOps появляется возможность создавать, разрабатывать и поддерживать безопасные продукты. При этом можно контролировать степень соответствия требованиям регуляторов и стандартов в условиях динамической среды. Вы также можете автоматизировать задачи безопасности в облаке, где для вас подготовлены готовые инструменты.

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