Меня зовут Владислав Архипов, я архитектор команды разработки security‑сервисов в Yandex Cloud. Мы занимаемся как непосредственной безопасностью облачной платформы и её клиентов, так и созданием сервисов безопасности.
Итоги 2025 года в сфере информационной безопасности показали, что нагрузка на security‑команды любого уровня растёт вместе с ростом потока данных. На нашем примере: к середине 2025 года количество типовых событий безопасности, которые мы обрабатывали, в среднем составляло 28 млрд в день, а рост за год составил 20%. При этом всё чаще необходимо анализировать потоковые источники данных, где традиционные подходы с периодической выгрузкой информации просто исчерпали себя.
В этой статье вместе с руководителем Cloud Security Operations Юрием Наместниковым @namestnikov мы расскажем, как создаём Security Deck и добиваемся прозрачности процессов ИБ, а также о том, как хронологическое хранилище помогает справляться с растущими потоками данных. Покажем, как мы превращаем разрозненные события в стейт и храним в хронологической базе данных, а также в чём отличие нашего запатентованного решения от других на уровне архитектуры.
В чём главные проблемы безопасности в облаке
В Yandex Cloud более 75 сервисов, и современный аналитик Security Operation Center (SOC) должен знать о происходящем в каждом из них, что практически невозможно. При этом сложность облачных инфраструктур растёт с каждым годом. Поэтому для нас автоматизация ИБ уже давно не желательная опция, а must have.
Но можно выделить несколько зон облачной безопасности, где всё не так просто:
Инвентаризация всех ресурсов, при которой бессилен традиционный подход через API.
Контроль доступов, где важны ограничения ресурсной модели by design.
Мисконфигурации настроек в инфраструктуре как один из самых частых источников уязвимостей для размещённых там приложений. Согласно данным нашего SOC, до 30% всех угроз связаны с такими мисконфигурациями.
Для устранения этих рисков зрелые облачные платформы развивают свои Cloud Native Application Protection Platforms — CNAPP‑платформы с нативными инструментами для защиты клиентских приложений. Но изучив накопленный в индустрии опыт, при создании своего CNAPP в Yandex Cloud мы поняли, что с точки зрения отслеживания мисконфигураций не все привычные решения нам подойдут.
Что такое CNAPP и с какими трудностями столкнулись мы как разработчики
CNAPP — единый центр управления безопасностью приложений в облаке. Он включает:
Инструменты автоматизации безопасности в облачной инфраструктуре.
Единый интерфейс для оценки рисков.
Механизмы защиты приложений, которые могут использоваться на стороне разработчиков и DevOps.
В процессе создания нашей платформы Security Deck мы рассматривали CNAPP как способ организовать и упорядочить всё многообразие средств безопасности, которые есть в Yandex Cloud, выразив его через общие наборы правил и общие сущности.
Поэтому, с одной стороны, внутри Security Deck мы выделили самостоятельные модули: Cloud Security Posture Management (CSPM), Data Security Posture Management (DSPM), Cloud Workload Protection Platform (CWPP) и другие. А с другой стороны, важно было сформировать единый пайплайн, который решает задачи безопасности облака.
И когда мы рассматриваем управление рисками с точки зрения такого системного подхода, видим много технических нюансов. Пойдём по порядку.
Проблемы инвентаризации и мисконфигураций
Облако — динамическая среда, которая постоянно меняется. Когда мы проверяем корректность конфигурации облаков так, как это принято во многих CNAPP, с помощью API, то так или иначе делаем слепок среды в процессе работы. Однако что происходит между двумя слепками — остаётся под вопросом. Из‑за этого возникает сразу несколько трудностей.
Риск неконсистентности. У нас есть процесс сбора состояния ресурсов из облака по API, и одновременно с этим есть какие‑то конкурентные д��йствия с этими же ресурсами, со стороны как живых пользователей, так и автоматики.
Для примера: есть два фолдера, в которых находятся ресурсы. Чтобы собрать состояния, нужно полистить сначала один фолдер, потом дойти до каждого из ресурсов в соответствующий сервис, повторить всё то же самое для второго фолдера.
Если за то время, когда мы листим фолдер A, но ещё не дошли до фолдера Б, кто‑нибудь перенесёт ресурс из фолдера Б в фолдер А, мы его уже не увидим. Ресурс как бы пропал. А если в это же время кто‑то перенесёт ресурс в фолдер Б, мы внезапно получим его в двух фолдерах одновременно.
С ростом количества ресурсов и числа пользователей вероятность такого растёт, и разрешать каждый конфликт всё сложнее.
Слепая зона между запусками. В той же самой ситуации с двумя итерациями сбора состояния через API представим: когда мы закончили одну операцию листинга, какой‑нибудь пользователь приходит и создаёт кривую виртуалку, делает с ней что‑то совсем неправильное и потом удаляет её до второго прохода.
Для системы безопасности той виртуалки как будто никогда не существовало. Понятно, что это не обязательно злонамеренный пользователь, — может быть, какой‑то честный мисконфиг или временная виртуалка. Но всё время, пока она существует, это представляет угрозу безопасности, про которую важно знать.
Длинная цепочка обратной связи. Предположим, у нас есть прогон системы, когда нам всё‑таки удалось поймать невалидное состояние. Видим какую‑то проблему, находим ответственного, идём к нему, говорим: «Надо поправить». Ответственный откликается: «Да, всё поправлю».
Следующий прогон происходит через несколько часов, а мы видим: ничего не исправлено. Идём ещё раз, снова просим. Человек ещё раз говорит: «Точно поправлю». Так может продолжаться довольно долго, и всё это время конфигурация остаётся небезопасной.
Сложности создания единого источника правды обо всех ресурсах
Поскольку принцип минимальных привилегий by design в Yandex Cloud реализован на уровне архитектуры — то всё работает в рамках единой ресурсной модели. Облачная платформа представляет собой множество слабо связанных сервисов, которые имеют общие соглашения по базовым контрактам (модель безопасности, API операций и тому подобное).
Какие из этого есть следствия, добавляющие трудностей при разработке CNAPP:
Разработку и эксплуатацию сервисов обеспечивают отдельные команды, у нас нет единых гейтвеев для доступа к данным, схем деплоя, фреймворков разработки.
Некоторые сервисы имеют сложную модель данных, находящихся в разнообразных хранилищах (не только БД).
Каждый сервис является единственным владельцем информации о своих сущностях.
Сервисы могут устанавливать ссылки на сущности других сервисов, используя механизм как слабых, так и сильных ссылок (Reference API).
Многие сервисы умеют жить вне состава Yandex Cloud как самостоятельные продукты или части других продуктов.
С точки зрения надёжности это скорее хорошо: сервисы проектируются исходя из того, чтобы число внешних точек отказа для них было минимальным. Но у нас как у разработчиков возникает вопрос: где же взять нужные нам данные без задержек и слепых зон?
Как приблизиться к realtime-инвентаризации в рамках Cloud Security Posture Management
Чтобы организовать мониторинг состояния облачной инфраструктуры в CNAPP, мы используем модуль CSPM, который помогает проводить контроль предикатов над состоянием облачных активов. И здесь сначала важно разобраться в терминологии.
Актив (asset) — это любая сущность, про которую мы можем собрать какую‑то информацию (например, из логов, событий трейла или API). Например, это виртуальные машины (ВМ), сети, хранилища, обладающие набором атрибутов, которые могут изменяться во времени. Сами активы тоже могут создаваться и удаляться.
Предикаты (правила безопасности) определяют условия, которые должны выполняться для активов в любой момент времени.
В рамках CSPM мы отслеживаем конфигурации, то есть состояние инфраструктуры целиком, и проводим её оценку. Если действие или связанный с ним актив нарушает предопределённую политику безопасности (предикат), то действие блокируется.
Например, если в бакете есть персональные данные, то он не должен быть открыт наружу с помощью прав доступа, или если есть виртуальная машина с доступом в интернет, то она не должна получать доступ в приватную сеть и тому подобное
Следовательно, внутри сервиса безопасности важно предусмотреть несколько сценариев работы с активами:
Изменение свойств актива во времени.
Состояние актива или группы активов в точке во времени.
Поток изменений свойств актива или группы активов, начиная с определённого момента.
Атрибуты актива во времени могут меняться, и, соответственно, мы хотим как‑то понимать в каждой точке во времени, какие значения имели эти атрибуты.
Классический подход, про который мы уже рассказали, — собираем все активы с помощью периодической выгрузки из API (или другого источника состояния, например БД) и запускаем поверх них запросы, проверяющие предикаты. Уже известные нам недостатки: активы живут в разных системах, нет транзакционности, сложно собрать консистентное состояние, кто‑то обязательно будет отставать во времени или убежит вперёд.
Но другой недостаток подхода в том, что злоумышленник, зная время проверок (а они не могут быть частыми из‑за скорости сборки состояния через API), может совершать попытки атак в эти диапазоны времени.
Альтернативные подходы, применяемые в последнее время, — анализ потоковых источников, например логов или событий трейла. Но есть недостаток: сложно сформулировать предикаты над таким потоком, чтобы отслеживать необходимые изменения над состоянием.
Например, есть облако, а в нём виртуальные машины, они связаны с помощью различных сетей. Предикат, который хотим проверять: не существует ВМ, одновременно имеющей доступ в интернет и во внутреннюю сеть. Над состоянием такой предикат проверяется легко (можно даже простым SQL‑запросом описать машины, которые его нарушают).
Однако над потоком такой предикат будет выглядеть очень сложно, потому что к его нарушению (а что ещё более сложно, к его возврату в состояние выполнения из нарушения) приводит множество разных не связанных с изначальным условием событий:
виртуальную машину остановили или запустили;
виртуальной машине поменяли сетевые настройки;
изменили настройки маршрутов или групп безопасности сетей;
перенесли облако с виртуальными машинами в другую организацию.
Чтобы обойти сложности и недостатки обоих подходов, мы можем выбрать третий путь — режим работы CSPM, который обеспечивает повышенную тщательность и непрерывность верификации, приближая её к режиму реального времени.
Как это выглядит? Обычно поток всё равно преобразуют в состояние, накапливая события в нём и изменяя собранный стейт актива. Это позволяет реагировать на нарушение сразу же, как только оно возникло.
Но это всё ещё не позволяет проводить ретроспективный анализ нарушений, так как нет гарантии, что события приходят в порядке их возникновения. Логический порядо�� событий может значительно отличаться от физического порядка и времени, когда эти события получены и обработаны. Например, логи часто приезжают с задержкой, которая может быть длиной в часы.
В ходе поиска подходящих решений мы так и не нашли те, которые описывали бы использование в CSPM‑системе continuous‑проверки на основе хронологии. Поэтому создали своё.
Наш подход — создание хронологической БД активов, в которой есть вся хронология актива и обеспечен быстрый доступ к ней для анализатора предикатов на любую выбранную точку во времени. Для этого мы используем реляционное дерево интервалов, которое храним в YDB и поддерживаем в правильном состоянии, «слушая» изменения из событий аудита, логов и других потоковых источников.
Что под капотом хронологического хранилища
Хронологическая база данных. Многие СУБД содержат средства для управления хронологией и удобный синтаксис запросов к ним. Но есть тонкость — сами хронологии могут быть разными:
System (или Transaction) Time — время внесения изменений;
Application (или Valid) Time — логическое время;
Decision Time — время принятия решения об изменении.
Таблицы и БД с одной или несколькими хронологиями часто называют Temporal, Bi‑Temporal, Tri‑Temporal и так далее
Во многих коммерческих БД, например в Oracle или Microsoft SQL Server, хронологические таблицы поддерживаются. Но в текущих условиях возможность использования таких СУБД ограничена. Если же говорить про популярные опенсорс‑технологии, то в PostgreSQL поддержки хронологических таблиц до сих пор нет — есть несколько extensions с поддержкой части функциональности, а в 17-й версии ядра патч с поддержкой хронологий отклонили.
Основой реализации нашего хронологического хранилища стала YDB — созданная в Яндексе распределённая отказоустойчивая база данных Distributed SQL с открытым исходным кодом. Система на её основе позволяла выйти на более высокую скорость работы, чем у перечисленных выше реализаций. Дополнительно YDB даёт нам возможность практически бесплатно горизонтально масштабироваться.
Для описанных сложных сценариев классические индексы баз данных плохо подходят: никакой одномерный индекс не позволяет найти все интервалы, содержащие нужную нам точку. В качестве стандартного подхода к решению этой задачи используются:
реляционное дерево интервалов (RIT);
геоиндексы (двумерный индекс);
специализированные GIST‑индексы для интервальных типов данных.
Мы используем специализированные индексы на основе интервального дерева внутри YDB. Вот как это работает на примере статического дерева интервалов с фиксированным разрешением в 1 секунду и числом узлов 24 − 1.
Хранение дерева интервалов в БД стоит нам дополнительно одной числовой 32-битной колонки и двух индексов (на картинке выше).
Запрос интервалов, содержащих точку, составляет не более 32 range scan в сумме по двум индексам.
Для типового набора в 100 тыс. активов время ответа при чтении данных с диска составляет около 1 секунды плюс время на последовательное чтение данных в зависимости от их размера.
Схема актива. Мы версионируем схему данных, используя Protobuf (он также хранится внутри базы данных). Получается компактно и обеспечивает строгую типизацию. Это позволяет нам достаточно быстро получать хронологию данных любого актива, любой группы активов за секунды (< 2 секунд для 10 тыс. активов).
Все наши активы имеют базовые атрибуты и специальные, в зависимости от типа актива. Так что схема может меняться со временем, а сервис умеет работать с версиями схем. Также хорошая схема обладает свойствами как backward, так и forward compatibility. Этого несложно достичь за счёт опциональности всех атрибутов, кроме базовых.
Наша схема выглядит так:
Структуры данных позволяют нам не только обращаться почти мгновенно ко всему состоянию целиком (а не состоянию отдельного актива) на любую точку во времени, но и понимать, к изменению каких активов в каких интервалах времени привело полученное событие. Таким образом, мы получаем возможность анализировать на потоке все интервалы времени всех активов и проверять все предикаты в эти интервалы, то есть в любую точку во времени мы знаем, какие из предикатов нарушены, а какие выполнены.
Наполнение БД с потока. Обработка события у нас всегда идёт по логическому времени события, поскольку возможны ситуации, когда событие приходит «в прошлое». А логическое время события может быть определено в источнике, который его породил. Всего у нас существует 47 различных сценариев, что нужно делать с хронологией актива при получении нового события, в зависимости от его логического времени и уже известной хронологии.
Для realtime‑отслеживания используется Audit Trails — сервис, представляющий собой поток значимых событий относительно всех активов с их метаданными. Он является обязательным механизмом доставки событий для всех сервисов облачной платформы. Audit Trails делает возможным получение трейла со всех организаций с фильтром по типу событий. Это позволяет собирать хронологию облачных ресурсов в автоматическом режиме.
Облачные ресурсы как активы также представлены в системе Asset Explorer, которая собирает менеджмент‑события и строит хронологическое состояние всех активов организации. Важный вопрос здесь: что считать таким активом? Исходя из нашей философии, они абстрактны, и многие из них не обязаны быть ресурсами облака. Так мы решаем частый запрос — как следить за всей инфраструктурой целиком, а не только за облачной её частью.
Получение всех активов через Asset Explorer по организации на порядки быстрее построения состояния через API, и это состояние всегда консистентное. В первую очередь здесь подразумевается консистентность каждого актива в отдельности. Однако если источник событий предоставляет информацию, позволяющую получить консистентную картину нескольких активов, то такое в нашей системе тоже возможно.
В результате такой связки для хронологической БД мы умеем получать представление всех активов организации на любой момент времени в прошлом.
Как работает такой CSPM с обработкой в реальном времени
Обработка событий и Temporal Database (хронологическая БД)
Поток событий, связанных с активами (создание, удаление, изменение атрибутов), поступает в обработчик событий (Event Processor). Этот компонент строит и поддерживает хронологическую базу данных (Temporal Database), которая хранит полную историю состояний активов во времени. Критически важной особенностью БД является способность вставлять события в любую точку логического времени, даже в прошлое, если поступают события с более ранним временем (например, обнаружение пропущенного события ATTACHED, которое произошло между CREATED и DELETED). БД позволяет эффективно выполнять запросы:— на получение истории изменений конкретного актива за период;
— на получение состояния всех активов, удовлетворяющих заданному фильтру (по типу, атрибутам), в конкретный момент логического времени.
Генерация триггеров и фильтрация правил (Rule Filter)
При обновлении Temporal DB обработчик событий также генерирует поток триггерных событий (Trigger Events), указывающих на конкретные интервалы времени и активы, состояние которых изменилось. Эти триггеры поступают в компонент фильтрации правил (Rule Filter). Основная задача этого компонента — определить, какие именно правила безопасности (предикаты) могли быть затронуты произошедшим изменением в указанных интервалах времени.Фильтрация основана на анализе того, какие типы активов и их атрибуты используются в условиях каждого правила (предиката). Например, изменение атрибута виртуальной сети затронет только те правила, которые в своём условии ссылаются на виртуальные сети или активы, связанные с сетями. Это существенно сокращает количество правил, требующих немедленной проверки в ответ на каждое событие, по сравнению с проверкой всех правил подряд.
Проверка правил (Rule Engine)
Движок правил (Rule Engine) получает от Rule Filter задания на проверку конкретных правил в конкретных интервалах времени.
Ключевая оптимизация: поскольку внутри интервала, указанного в триггере, атрибуты соответствующих активов не менялись (так как границы интервала определяются моментами изменений), то достаточно выполнить проверку правила в одной точке этого интервала (например, в начальной точке). Состояние системы — всех релевантных активов и их атрибутов — на требуемый момент логического времени загружается из Temporal DB. Сами правила безопасности могут быть описаны на предметно‑ориентированном языке (DSL) и транслироваться в SQL‑запросы к этому состоянию.Анализ и хранение результатов
Результаты проверки правил («выполнено/нарушено в проверенной точке интервала», что экстраполируется на весь интервал) поступают в компонент хранения и анализа результатов (Security Rule Results). Этот компонент сравнивает новые результаты с ранее известными. Если обнаружено нарушение правила в новом интервале времени или, наоборот, если нарушение в ранее известном интервале больше не актуально. Например, из‑за поступления события, «закрывающего» интервал нарушения, результаты обновляются. Это обеспечивает актуальную картину всех интервалов времени, когда каждое правило безопасности не выполнялось, на основе всей известной на данный момент информации (событий).
К Yandex Cloud постоянно подключаются новые сервисы, и мы хотим подключать их без перенормализации и доставания. Поэтому мы делаем это через Audit Trails и таким образом решаем задачу корректной совместной работы всех этих правил и новых сервисов.
Таким образом, получается, что API и Audit Trails — два равноправных и единственных в облачной платформе источника данных, которые поставляют сервисы. Не нужно заставлять сервисы поддерживать другие протоколы доставки данных об их ресурсах.
Что планируем дальше?
Сейчас в реальных условиях мы в большей степени говорим о режиме работы CSPM, который обеспечивает верификацию, приближенную к режиму реального времени. Но созданное командой решение — это перспективная разработка с возможностью полностью непрерывного CSPM, и эти идеи мы уже начали реализовывать в нашем продукте, чтобы в скором времени перейти на полный realtime.
Безусловно, в этой статье я коснулся самых главных принципов разработки, исходя из нашей задачи, не описывая всех деталей реализации. Одно подробное описание работы над хронологическим хранилищем могло бы вылиться не в одну статью.
Поэтому буду благодарен за вопросы о том, о чём было бы интересно узнать подробнее, — это поможет сделать полезнее наши будущие доклады и статьи на эту тему. А чтобы быть в курсе выступлений и новостей нашей команды безопасности, подписывайтесь на канал Безопасно говоря и заглядывайте в Inside Yandex Cloud, где мы рассказываем о жизни всей большой команды Yandex Cloud.