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

По нашим данным, более четверти пользователей Yandex Cloud используют облачную платформу для разработки. Это понятно: в облаке легко развернуть всё необходимое для автоматизации разработки, тестирования, доставки и стабильной работы приложения.

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

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

DevOps в облакеDevOps в облаке

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

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

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

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

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

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

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

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

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

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

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

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

Расскажем, как можно упростить соответствие требованиям на каждом этапе.

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

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

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

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

• Управление изменениями. Тут действует простое правило: всё, что попадёт в продакшен, должна подтвердить незаинтересованная сторона. Например, ревью кода выполняет тот, кто не участвовал в разработке. Апдейты должны быть протестированы, а процесс обновления должен быть прозрачен, в том числе и для аудиторов.

• Управление уязвимостями. В продакшен не должны попадать уязвимости, в том числе уязвимые third-party-компоненты. Их нужно вовремя обнаруживать, ранжировать по критичности и исправлять. Самые строгие стандарты требуют, чтобы патч, исправляющий уязвимость, был установлен не позднее 30 дней после его выхода. Для поиска уязвимых компонентов в Yandex Cloud есть сканер, встроенный в сервис Yandex Container Registry. А включение динамического и статического анализатора кода из Yandex Managed Service for GitLab поможет сделать приложение безопаснее.

• Управление ключами и секретами. Ключи и секреты нужно хранить и передавать так, чтобы злоумышленник не смог до них добраться. «Хардкодить» такие данные очень плохая практика. Для управления секретами в Yandex Cloud есть сервисы KMS и Yandex Lockbox. KMS в том числе защищает секреты, которые хранятся в кластере Kubernetes^®. Yandex Lockbox — сервис для создания и хранения секретов в инфраструктуре Yandex Cloud. Эти инструменты и правильно построенные процессы позволят легко пройти любой аудит.

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

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

• Управление доступом. В облаке вы используете IAM. В IAM есть роли, и чтобы соответствовать требованиям, нужно, чтобы вы на своей стороне соблюдали принцип минимальных полномочий — давали доступ только тому, кому он необходим.

• Сетевая безопасность. Среду тестирования необходимо отделить от среды продакшена. Например, в Yandex Cloud есть VPC с механизмами Security Group. Эта связка очень выгодная не только со стороны ограничения сетевого трафика. Вам не нужно думать, какой вендор ушёл или какое сетевое устройство отключилось. Просто настраивайте группы безопасности и управляйте правилами файрвола и потоками трафика.

• Управление инцидентами. Многие стандарты требуют сбора логов аудита, корреляцию, настройку алертов. Систему мониторинга событий безопасности можно построить на базе Yandex Audit Trails и интеграции SIEM-решений, сервисов Yandex Managed Service for Elasticsearch или Yandex Managed Service for OpenSearch.

Если вы занимаетесь безопасностью, то, скорее всего, используете Kubernetes^®. Теперь вы знаете, как безопасно развернуть и настроить такой кластер.

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

По всему жизненному циклу приложения для контроля соответствия требованиям в рамках всё той же концепции Shift-left можно использовать продукты Yandex Cloud и различные наложенные средства.

Помимо Checkov есть целый набор инструментов, таких как Falco и Kyverno, позволяющих контролировать развёрнутую инфраструктуру на соответствие требованиям безопасности.

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

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

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

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