Как автоматизировать безопасность облака: от комплаенса до Kubernetes^®

Почему в облаке не работает классический подход к безопасности

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

Уже на витрине сайта замечена проблема: «наружу» торчат ссылки на бакеты, в одном из них — список клиентов. Классическая история перехода из тестирования в продакшен: открытый бакет удобен для отладки, но в продакшене такие вещи пора закрывать.

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

План намеченных работ выглядит так:

• Провести инвентаризацию: понять, какие права выданы и где лежат данные.
• Подготовиться к аудиту на соответствие требованиям: сайт попадает под 152-ФЗ и PCI DSS.
• Уделить особое внимание доступности и безопасности самого приложения.
• Отслеживать ситуацию постоянно, а не разово.

Что такое Yandex Security Deck

Yandex Security Deck — единая платформа обеспечения безопасности облачных приложений и инфраструктуры класса CNAPP. Внутри — отдельные модули под конкретные задачи: контроль конфигурации, контроль данных, защита Kubernetes, управление уязвимостями, обнаружение угроз.

Людей в безопасности не хватает, один безопасник не справится. Один из вариантов решения — смежники: инженеры, DevOps, разработчики. Платформа даёт им общий контекст и общую очередь задач, чтобы безопасность стала командной работой.

С чего начать: создаём окружение

Работа в Security Deck начинается с окружения, общего пространства, которое хранит контекст, настройки и права доступа. Данные о безопасности складываются в отдельно выбранный каталог, доступ к которому выдаётся только тем, кому он нужен.

Создание окружения состоит из нескольких шагов:

1. Выбрать каталог и дать окружению название.
2. Определить область сканирования: куда модули анализа имеют доступ. На вебинаре выбрали всю организацию; технически это работает через сервисный аккаунт.
3. Выбрать модули. Вариант по умолчанию: анализ данных и контроль конфигурации.
4. Подключить набор требований. Для старта можно взять базовый стандарт, он бесплатный.
5. Добавить команду: Полину нашли среди пользователей облака и выдали ей права на просмотр ресурсов.

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

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

Инвентаризация доступов: закрываем самый частый вектор атак

Первый вопрос, на который нужно ответить бизнесу: что вообще происходит в облаке? Что наделали подрядчики и смежники, с чего начать?

В разделе контроля доступов спикеры посмотрели на группу пользователей подрядчика, который делал сайт для «Круассании». У группы оказался доступ уровня администратора на всю организацию. Его отняли: если подрядчику понадобится помочь с доработкой, ему можно точечно выдать ограниченные права на нужные кластеры Kubernetes.

Где лежат чувствительные данные: модуль DSPM

DSPM (Data Security Posture Management) — модуль контроля данных: инвентаризация, классификация и глубокое сканирование хранилищ на предмет чувствительной информации.

В интерфейсе модуля видно, что у «Круассании» три бакета, а в них — документы, структурированные данные и много графики, всего несколько мегабайт. DSPM сначала показывает общую картину: форматы файлов и какие бакеты торчат «наружу». Это помогает сузить область проверки — сканировать всё подряд дорого и по процессорным ресурсам, и по деньгам.

По подозрительным местам запускается точечное сканирование: каждый файл проверяется на чувствительные данные, включая изображения. Модуль ищет персональные и платёжные данные, облачные секреты, а ещё умеет работать с кастомным словарём. Кроме бакетов Object Storage он анализирует диски в Яндекс 360.

Результаты оказались показательными: в одном бакете нашлись чувствительные данные, в другом — персональные. ИНН, скан паспорта, ФИО, телефоны: судя по всему, те самые заказы клиентов. Учитывая, что ссылки на эти бакеты светились прямо на сайте, доступ закрыли: в настройках включили доступ только с авторизацией.

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

Как работать с алертами, чтобы они не превращались в шум

Алерты со всех модулей собираются в единую очередь. Спикеры договорились о ролях: Рами настраивает контроли и фильтрует поток, Полина с командой разбирает алерты по своей части инфраструктуры.

Очередь алертов умеет:

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

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

Как выстроить соответствие 152-ФЗ и PCI DSS

Точечные проблемы закрыты — пора подходить к рискам системно. В разделе соответствия требованиям доступны разные стандарты; для «Круассании» актуальны 152-ФЗ и PCI DSS. Их можно включить в один клик, но спикеры пошли через настройки и включили стандарты точечно, только в модуле контроля конфигурации: один стандарт может задействовать сразу несколько модулей, и на старте это лишний шум.

Сразу после включения система показала уровень соответствия выше 80% и список нарушений, замапленных на конкретные требования стандартов: про шифрование и слишком широкие доступы. Нашлись и сотни однотипных срабатываний — роли, массово выданные участникам вебинара, на инфраструктуре которого шло демо.

Здесь Рами сформулировал принцип работы безопасника в платформе: не вываливать всё на смежников. Слепо следовать всем рекомендациям стандарта не обязательно: приемлемый уровень риска определяет безопасник. Из общего списка правил нужно «фигурно вырезать» те, что будут генерировать действительно релевантные алерты.

Зачем нужны исключения из правил

Пример: правило требует наличия файрвола. Файрвол в компании есть, но внешний: Security Deck его не видит. Чтобы правило не «шумело», для него создают исключение: выбирают правило или конкретный ресурс, помечают «проверено вручную» и оставляют комментарий, например ссылку на настройки файрвола. Если придёт аудитор, обоснование исключения уже зафиксировано.

Как защитить Kubernetes: KSPM и контроль уязвимостей

Приложение — основа бизнеса: остановится оно, остановится и поток денег. Для его защиты предназначен сценарий, состоящий из двух модулей.

KSPM (Kubernetes Security Posture Management) — контроль безопасности Kubernetes. Работает в нескольких режимах: контролирует admission-политики при развёртывании, а с агентом на базе Tetragon анализирует происходящее на уровне операционной системы, собирает логи и данные инвентаризации.

У Kubernetes своя вселенная, и KSPM становится инструментом диалога безопасника с командой, которая занимается кластерами. Модуль серьёзный, поэтому его включают не на всю организацию, а точечно: на вебинаре — только на кластер, который обслуживает магазин.

Управление уязвимостями — модуль, который сканирует образы контейнеров в реестрах. Можно выбрать конкретные реестры или только артефакты, связанные с Kubernetes. Триггером служит расписание (в ситуации из вебинара — раз в три дня, только свежие образы) и появление новых образов в реестре.

Примеры срабатываний из демо:

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

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

Как модули следят за инфраструктурой в динамике

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

Частота проверок у модулей разная:

• контроль конфигурации (CSPM) запускается раз в несколько часов и перепроверяет всё заново;
• контроль данных (DSPM) срабатывает при появлении новых файлов;
• контроль Kubernetes (KSPM) работает в реальном времени: агент стоит прямо в рантайме.

Как ловить угрозы в реальном времени: модуль обнаружения угроз

Следующий уровень — модуль обнаружения угроз (threat detection). Он доступен только в подписках и работает на базе событий Audit Trails. В отличие от опроса API, который может падать или отдавать неточные данные, аудитные события падают в реальном времени сплошным потоком. На их основе правила вытаскивают то, на что нужно реагировать.

Модуль ловит, например, такое: кто-то открыл публичный доступ к виртуальной машине, базе данных или бакету, выдал роль администратора, создал новый ключ. Отдельная способность — поиск утекших ключей Yandex Cloud: модуль смотрит большой поисковый индекс Яндекса и интегрирован с GitHub и GitLab. Сейчас доступно около 12 преднастроенных правил, список будет пополняться.

Спикеры разобрали два срабатывания.

Первое: кто-то выдал публичный доступ к бакету со статикой сайта (картинками круассанов). Проверили: доступ и должен быть публичным, сайт без него не работает. На такое событие не реагируем.

Второе срабатывание серьёзнее, и это реальный случай: при подготовке вебинара ключ сервисного аккаунта утёк в публичный доступ. Порядок действий: по ID субъекта из алерта найти сервисный аккаунт, удалить статический ключ и перевыпустить новый. Отдельная рекомендация: лучше вообще не использовать статические ключи, но иногда без них не обойтись.

Как организовать работу команд, когда бизнес растёт

Бизнес «Круассании» развивается: появляется мобильное приложение, растут инфраструктура и количество алертов, а ресурсы команды ограничены.

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

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

Для этого есть ролевая модель: роли администратора и редактора Security Deck выдают ответственным за безопасность, а командам достаются точечные роли вплоть до конкретных модулей, например только KSPM.

Окружения тоже можно разделять: для платёжной системы или персональных данных — окружение со строгими требованиями регуляторов, для dev-среды — отдельное окружение с тремя-четырьмя правилами, которым должны следовать разработчики. У каждого окружения своя жизнь, свои правила и доступы.

Какой операционный ритм поддерживать

Автоматизация не отменяет процесса. Воспользуйтесь шпаргалкой, по которой можно выстроить работу с алертами:

Доступы, по-хорошему, стоит смотреть чаще, но это трудоёмко, поэтому эту работу мы тоже планируем автоматизировать.

Что дополняет Security Deck до и после инцидента

Всё показанное на вебинаре — превентивные меры. Полную картину можно разложить по стадиям: инструменты до атаки, во время и после. Исходить стоит из того, что инцидент случится — вопрос не «состоится ли он», а «когда».

• До атаки — Security Deck и весь арсенал CNAPP, плюс Identity Hub с централизованным управлением учётными записями, двухфакторной аутентификацией и SSO, плюс Smart Web Security для защиты от DDoS и атак на веб-приложения.
• Всегда — Audit Trails: события безопасности стоит складывать в бакет и хранить хотя бы несколько месяцев, а желательно год, чтобы было по чему разбирать инцидент.
• Во время и после атаки — для критичной инфраструктуры Yandex Cloud Detection and Response: команда, которая мониторит инфраструктуру 24/7 и реагирует на инциденты.

Эти сервисы живут за рамками Security Deck, но их события можно совмещать с общей очередью алертов. Суть не в списке модулей, а в едином интерфейсе и едином подходе к безопасности.

Сколько это стоит

Бесплатно и без подписки доступны:

• события Audit Trails уровня конфигурации;
• базовый стандарт контроля конфигурации (21 проверка);
• инвентаризация доступов и данных.

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

Базовая подписка на основные модули Security Deck начинается от 25 тыс. рублей; в некоторых случаях модули можно включать точечно на отдельные ресурсы и снизить цену.

Для крупных и зрелых по безопасности организаций есть расширенная подписка: контроль безопасности Kubernetes, управление уязвимостями, выделенный агент и DSPM без ограничений по объёму сканируемых данных (ограничена только скорость).

Если сомневаетесь, что подходит именно вам, начните с бесплатных базовых вещей, а дальше запросите демо: команда сервиса покажет платформу и при необходимости проведёт анализ защищённости текущей инфраструктуры.

Что можно сделать прямо сейчас

Четыре шага:

1. Включить логи: контрольные события уровня конфигурации в Audit Trails. Это бесплатно.
2. Проверить доступы: именно с них чаще всего начинается атака.
3. Проверить, какие данные и где у вас лежат.
4. Подключить сервисы безопасности: проверить инфраструктуру на нужные стандарты и включить модуль обнаружения угроз, чтобы контролировать всё в динамике.

Что в итоге

• В облаке безопасность нельзя обеспечить разовым аудитом: среда меняется по несколько раз в день, контроль должен быть автоматическим и постоянным.
• Начинать стоит с инвентаризации доступов и данных: большинство атак на облачную инфраструктуру начинается с легитимных, но плохо контролируемых доступов.
• Бесплатного базового набора (Audit Trails, базовый стандарт из 21 проверки, инвентаризация) уже достаточно, чтобы увидеть самые вопиющие проблемы.
• Задача безопасника — не транслировать смежникам все требования стандартов подряд, а «фигурно вырезать» релевантные контроли и управлять шумом через исключения.
• Безопасность — это командная работа с операционным ритмом: критичное — сегодня, среднее — за неделю, комплаенс — раз в месяц, исключения и доступы — раз в квартал.