DSPM‑подход: как превратить хаос в систему защиты данных в облаке

Представьте ситуацию. У компании есть несколько сотен облачных хранилищ, десятки баз данных, множество SaaS-приложений. Все работает, данные вроде бы под контролем. А теперь попробуйте ответить: в каком именно бакете лежат паспортные данные клиентов? Какие хранилища содержат финансовую отчетность? Где находятся копии тестовых баз с реальными email-адресами пользователей?

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

Парадокс облачной трансформации

Облака дали бизнесу невероятную гибкость. Хочешь создать новое хранилище? Нажал кнопку — готово за минуту. Нужна база для тестирования? Склонировал production — и вперед. Разработчик решил попробовать новый сервис? Завел аккаунт, загрузил данные, оценил функционал.

Вот только эта простота создания имеет обратную сторону. Разработчик создал временный бакет для тестирования — и забыл про него после релиза проекта. Через полгода в этом хранилище по-прежнему лежат копии чувствительных данных, причем никто даже не помнит о его существовании. Права доступа? Да кто их там настраивал. Шифрование? А зачем, это же «временное».

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

Shadow data: невидимая угроза

Профессионалы безопасности называют это явление «shadow data» — теневые данные. Это неконтролируемые копии чувствительной информации, разбросанные по незарегистрированным облачным хранилищам, старым базам данных, случайным SaaS-приложениям и персональным аккаунтам сотрудников.

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

Все это происходит вне формальных процессов, без должного контроля и часто даже без уведомления ИБ-службы. А теперь добавьте сюда тот факт, что сотрудники уходят, забывая отключить доступ к «своим» облачным ресурсам, и картина станет еще печальнее.

Цифры, которые не дают спать спокойно

Статистика последних месяцев показывает масштаб проблемы. Согласно данным исследований, более 20% российских организаций пострадали от атак на облачные сервисы только за первый квартал 2025 года. При этом общее число атак на российские компании в 2024 году выросло в 2,5 раза.

Но самое показательное — это не количество атак, а их цели. По оценке специалистов Yandex Cloud, которые провели анализ отраженных атак в первом полугодии 2025 года, конечной целью примерно 76% разобранных инцидентов были облачные базы данных и объектные хранилища S3. Злоумышленники прекрасно понимают, где находится самое ценное — не в файрволах и системах мониторинга, а в местах, где лежат реальные данные: клиентская информация, интеллектуальная собственность, финансовые записи, критическая бизнес-аналитика.

При этом число DDoS-атак в мире с 2023 по 2024 год увеличилось на 108%, а в России рост составил 53%. Особенно заметным стал рост сегмента облачных технологий в ИТ-сфере, на который пришлось 7% всех зафиксированных DDoS-инцидентов.

Как злоумышленники получают доступ

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

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

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

Модель совместной ответственности и её подводные камни

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

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

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

Первый шаг: понять, что у вас есть

Крупные облачные провайдеры предлагают инструменты для оценки безопасности инфраструктуры: у AWS это Security Hub, у Azure — Microsoft Defender for Cloud, у Google Cloud — Security Command Center. Рассмотрим подробнее, как это работает, на примере Yandex Cloud.

Yandex cloud предлагает сервис Security Deck. Это CNAPP-платформа для контроля безопасности облачных ресурсов, данных и приложений. Она объединяет инструменты для управления доступом, обеспечения прозрачности и безопасности данных, позволяя централизованно автоматизировать ключевые процессы ИБ и защищать облачные среды.

За время проведения более 15 Security-чекапов для клиентов Yandex Cloud во всех случаях были выявлены проблемы. В некоторых бакетах не было понимания, какие данные там хранятся. В других обнаружились мисконфигурации, при том, что пользователи были уверены в безопасности настроек.

Модуль контроля данных в Security Deck: следующий уровень защиты

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

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

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

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

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

Если организация уже использует DLP, DSPM станет ценным дополнением для облачной среды.

Рис. 1. Общая схема работы модуля контроля данных: от источников данных через поиск персональных данных до отправки алертов в Security Deck

Как это работает на практике

Представьте, что в вашем облачном окружении есть десятки бакетов Object Storage. Модуль контроля данных начинает автоматизированное обнаружение: сканирует все хранилища в указанном каталоге, находит файлы и начинает их анализировать.

Система умеет работать с разными форматами: PDF-документы, таблицы Excel, файлы Word, изображения, архивы. Для каждого типа применяется свой метод извлечения информации. Из PDF и документов извлекается текст и изображения. Из таблиц — структурированные данные. Дальше включается интеллектуальная классификация. Модуль использует два подхода: регулярные выражения для поиска структурированных данных (номера телефонов, email-адреса, ИНН, СНИЛС, номера паспортов) и машинное обучение для определения менее формализованных типов информации (ФИО, почтовые адреса, должности), а также изображений (сканы документов и другие изображения).

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

Все обнаруженные проблемы агрегируются и отправляются в Security Deck как алерты. Система не просто сообщает «найдены персональные данные», а дает конкретную информацию: в каком файле, в каком бакете, какой именно риск и что нужно сделать для его устранения. При необходимости AI-ассистент может предложить детальные рекомендации по исправлению.

Техническая архитектура: надежность и масштабируемость

Модуль построен с использованием Temporal в качестве оркестратора. Архитектура включает управляющий бэкенд, который служит входной точкой API, и воркеры обработки документов, отвечающие за чтение, распознавание и поиск чувствительных данных.

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

Процесс обработки разделен на несколько стадий.

На стадии Survey система определяет, какие объекты нужно сканировать, применяя фильтры по имени файла, типу контента и метаданным.

На стадии Load происходит загрузка файлов — данные могут сохраняться локально на воркере или во внешнем системном бакете в зависимости от архитектуры обработки.

Стадия Unpack распаковывает архивы, применяя те же фильтры, что и на начальном этапе. Файлы, не попадающие под критерии, не распаковываются и не тарифицируются.

Parse извлекает из документов фрагменты в каноническом формате: текст преобразуется в UTF-8 строки, изображения в Loseless WEBP, таблицы в Parquet.

На стадии Identify фрагменты отправляются на обработку в соответствующие воркеры — регулярные выражения, ML-модели или детекторы секретов из внешних сервисов вроде Yandex Lockbox. Найденные типы данных сохраняются в YDB вместе с их локациями в исходных объектах.

Алгоритм обработки текстового потока

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

Три уровня анализа:

• Нейросеть (ML-анализ) — понимает контекст. Отличает фамилию человека от названия улицы, распознаёт адрес, даже если он написан нестандартно. Устойчива к опечаткам. Для обнаружения сущностей со слабо формализованным контекстом используется модель на основе Transition-Based Parsing. Модель оптимизируется на предсказание всей последовательности тегов для предложения, что повышает точность на границах сущностей. Для русского языка используется специальный токенизатор, оптимизированный под кириллицу.
• Регулярные выражения (RegEx) — ищет данные со строгим форматом: номера паспортов, банковских карт, ИНН, IP-адреса. Для снижения ложных срабатываний применяются дополнительные проверки:
  • Алгоритм Luhn — валидация контрольной суммы для номеров банковских карт
  • Проверка контрольных разрядов — для государственных идентификаторов (ИНН, СНИЛС)
  • Поддержка вариативных форматов — обработка данных с разделителями и без них
• Словарный поиск (точный и нечёткий) — работает с большими справочниками терминов:
  • Точный поиск (алгоритм Ахо-Корасик) — высокопроизводительный поиск по большим словарям за один линейный проход по тексту. Мгновенно находит известные маркеры («паспорт», «договор», «Visa»).
  • Нечёткий поиск (Sliding Window + Levenshtein) — находит сущности с опечатками или ошибками распознавания.

Умная фильтрация

Результаты от всех трёх модулей проверяются перекрёстно. Если RegEx нашёл 16 цифр подряд — это ещё не повод для тревоги. Но если рядом словарный поиск нашёл слово «Visa», а нейросеть подтвердила финансовый контекст — система делает вывод: это номер банковской карты. Такой подход отсеивает случайные цифровые последовательности.

Финальная стадия Aggregate формирует алерты на основе правил агрегации. Например, если в публичном бакете обнаружено более 100 записей с персональными данными, создается алерт высокого приоритета. Все алерты отправляются в Security Deck для дальнейшей обработки командой безопасности.

Кому нужен модуль контроля данных

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

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

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

DevSecOps-команды и разработчики интегрируют DSPM в CI/CD pipelines для раннего выявления проблем с данными и потенциальных утечек секретов. Они получают конкретную обратную связь о том, какие данные обрабатывают их приложения и как их защитить.

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

Аналитики безопасности применяют DSPM для охоты на угрозы и обнаружения аномального доступа к чувствительным данным, коррелируя данные с другими сигналами безопасности из других модулей Security deck, таких как Контроль безопасности контейнеризованных приложений(KSPM), Контроль конфигураций (CSPM), Контроль доступа пользователей (CIEM) и др.)

Реальные кейсы: когда DSPM спасает ситуацию

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

После развертывания модуля контроля данных выяснилось, что информация о клиентах находилась в семи неиспользуемых бакетах Object Storage, созданных несколько лет назад для «временных» проектов. DSPM обнаружил, что два из этих хранилищ были полностью открыты в интернете без какого-либо шифрования.

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

Второй кейс связан с предотвращением утечки секретов. В крупной SaaS-компании команда разработчиков активно использовала Terraform. Один из разработчиков случайно оставил в tf.state файле production-ключ облачного провайдера в бакете, к которому имели доступ другие разработчики, не имеющие прав на работу с боевой средой.

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

После развертывания модуля DSPM и настройки мониторинга бакетов были найдены валидные ключи в файлах Terraform (state-файлах), которые в срочном порядке перенесли в безопасное хранилище. DevSecOps-интеграция, включающая детекторы секретов и централизованное хранение ключей, позволяет минимизировать человеческий фактор и гарантирует, что критичные секреты не попадут к злоумышленникам, даже если ошибка допущена в коде.

Интеграция в бизнес-процессы

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

При реагировании на инциденты DSPM предоставляет классификацию данных внутри скомпрометированного бакета для понимания критичности и масштабов утечки, ускоряя анализ и исправление. Для управления комплаенсом модуль автоматически генерирует отчеты с классификацией чувствительных данных внутри облачных хранилищ для дальшей работы с этим отчетом в рамках соответствия нормативным требованиям регуляторов и аудиторов.

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

Что дальше?

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

Модуль контроля данных в Security Deck — это не альтернатива существующим инструментам, а новый уровень видимости и контроля, который работает вместе с ними. Он отвечает на критический вопрос: «Где находятся наши данные и насколько они защищены?» — вопрос, который не может быть полностью решен никаким другим инструментом.

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

В мире, где мировой ущерб от киберпреступности в 2024 году составил 9 триллионов долларов, а атаки становятся все более изощренными и целенаправленными, знание того, где находятся ваши данные и как они защищены, перестает быть опцией. Это становится базовым требованием для выживания бизнеса.

Подробнее о Security Deck и модуле контроля данных можно узнать на официальной странице продукта.