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

Зачем вообще DSPM, если уже есть средства ИБ

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

DLP хорошо ловит попытки утечки и подозрительные действия, но обычно не отвечает на вопрос, какие именно чувствительные данные уже хранятся внутри и где. IAM показывает, у кого какие права, но без понимания ценности данных эти права трудно оценить. SIEM собирает события и помогает расследовать, но не инвентаризирует содержимое файлов и таблиц и не объясняет, какие активы важнее.

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

Заранее договоритесь, что считать успехом. Хороший результат - не «меньше алертов», а снижение реального риска: меньше общих папок с персональными данными, меньше БД с избыточными правами, меньше бесхозных архивов, понятные владельцы и сроки хранения.

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

Какие источники данных DSPM обычно покрывает

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

Чаще всего в покрытие входят файловые хранилища: сетевые папки, общие диски, корпоративные порталы и документы совместной работы. Именно здесь годами оседают Excel-таблицы, сканы, выгрузки из учетных систем и «временные» файлы.

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

С базами данных DSPM обычно работает на нескольких уровнях: реляционные БД, NoSQL, аналитические витрины и хранилища для BI. Важно, чтобы инструмент видел не только «основные» таблицы, но и производные наборы: реплики, выгрузки в витрины, промежуточные слои для отчетов.

Если в компании используются SaaS и облачные хранилища, DSPM подключается и к ним. На практике именно облачные папки и совместные пространства чаще всего становятся местом, где по ошибке включают доступ «всем по ссылке».

Отдельно проверьте, как инструмент обнаруживает тестовые контуры и разовые выгрузки. Типичный сценарий: разработчику дали выгрузку «на неделю», она попала в тестовую БД или папку проекта, а затем стала частью ежедневной работы.

Классы данных, которые DSPM ищет чаще всего

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

Чаще всего ищут:

• персональные данные: ИИН, ФИО, даты рождения, адреса, телефоны, e-mail, сканы удостоверений и паспорта;
• платежные и банковские данные: номера карт, IBAN/счета, платежные поручения, реквизиты контрагентов, детали транзакций;
• медицинскую информацию: диагнозы, результаты анализов, назначения, истории обращений;
• финансы и коммерческую тайну: бюджеты, прайс-листы, договоры, внутренние отчеты, закупочные планы;
• учетные данные и «секреты»: пароли в файлах, ключи API, токены, строки подключения, приватные ключи.

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

Простой пример: в общей папке лежит Excel «Список сотрудников», где ИИН записан как число без пробелов, а рядом есть «Подразделение» и «Телефон». Хороший DSPM пометит это как персональные данные даже при пустых значениях и «сломанных» форматах.

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

Файлы и БД: чем отличается поиск и разметка

DSPM по-разному работает со структурированными и неструктурированными данными. В базе данных «находка» обычно имеет четкий смысл (поле, таблица, набор записей), а в файлах совпадение может быть фрагментом текста без понятного контекста. От этого зависят точность, разметка и то, как быстро получится назначить владельца и принять меры.

В БД DSPM опирается на структуру: таблицы, столбцы, типы, связи и справочники. Разметка получается точнее: можно сказать «в этой колонке хранятся ИИН» или «в этой таблице есть медицинские диагнозы». Хорошие инструменты учитывают закономерности и бизнес-контекст, чтобы не путать, например, идентификатор заказа с номером документа.

С файлами сложнее. Документы, письма и вложения могут содержать чувствительные фрагменты среди обычного текста. Если встречаются изображения или отсканированные PDF, нужна OCR, иначе часть рисков будет пропущена. Полуструктурированные форматы (JSON, XML, логи, выгрузки) дают много совпадений, но без «схемы», поэтому инструмент должен отличать реальные персональные данные от технических полей и тестовых значений.

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

Если продукт добавляет контекст использования (кто читает, откуда, как часто), приоритизация становится проще. Один и тот же набор персональных данных в «тихой» таблице и в общей сетевой папке с широкими правами - это два разных уровня риска и разные действия.

Как оценить качество классификации и риск-скоринга

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

Классификация: глубина, точность и объяснимость

Смотрите на глубину классификации: кроме готовых детекторов (ИИН, номера карт и т.п.) должны быть свои шаблоны и словари. Иначе продукт будет хорошо видеть «универсальное», но пропустит внутренние коды, названия проектов и ваши форматы договоров.

Точность держится на двух вещах: ложные срабатывания и пропуски. Попросите показывать объяснение по каждой находке: что совпало (шаблон, словарь, модель), где найдено (колонка, лист, диапазон) и с какой уверенностью. Если продукт не может внятно ответить «почему», его трудно настраивать и еще труднее защищать решения перед бизнесом.

Гибкость правил часто решает судьбу пилота. Нужны исключения (папки, схемы, типы файлов), пороги уверенности и контекстные условия. Пример: 12 цифр подряд в логах не равно ИИН, если рядом нет других признаков персональных данных.

Риск-скоринг: что он учитывает на практике

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

Перед пилотом задайте несколько проверочных вопросов:

• Можно ли добавлять шаблоны и словари без разработки у вендора?
• Есть ли объяснение находки и уровень уверенности для каждого объекта?
• Можно ли настраивать исключения и контекстные правила?
• Как сканируются большие объемы и влияет ли это на рабочие системы?
• Что уходит наружу: метаданные, фрагменты контента, результаты, или все остается внутри периметра?

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

Внедрение DSPM шаг за шагом: от пилота к регулярной работе

Чтобы DSPM не превратился в бесконечный список находок, начинайте с пилота и четких границ. На первом этапе важнее не «найти все», а понять, где риск реально живет и как команда будет с ним работать.

Составьте карту источников и выберите 1-2 самых рискованных зоны. Часто это общая сетевая папка с широкими правами или старая БД, где никто не помнит, что внутри.

Дальше определите критичные классы данных под вашу отрасль и регуляторику. Обычно достаточно 10-20, иначе вы утонете в шуме.

Перед первым сканированием договоритесь о ролях. На практике удобно разделять ответственность на три уровня: владелец данных (бизнес, кто отвечает за смысл), владелец системы (ИТ, кто управляет хранилищем и доступами), владелец процесса (безопасность/комплаенс, кто задает правила и контроль).

После запуска снимите базовую линию: где лежат чувствительные данные, у кого доступ, сколько «открытых» мест. Сразу настройте исключения (часть архивов, системные каталоги и т.п.), чтобы статистика не раздувалась.

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

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

Как не утонуть в тысячах находок без владельцев

«Тысячи находок» обычно появляются из-за трех причин: сразу подключили слишком много источников, поставили низкие пороги (все совпадения считаются чувствительными) и получили дубликаты одних и тех же данных в копиях, выгрузках и архивах. Если разбирать это поштучно, команда ИБ быстро выгорит.

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

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

Дальше включайте группировку в кейсы: один риск на множество похожих объектов. Например, «общая папка Бухгалтерия: 340 файлов с паспортными данными» вместо 340 тикетов. Это снижает шум и помогает исправлять причину, а не симптомы.

Проблема «без владельцев» решается организационно. Назначайте владельца не на файл, а на систему, подразделение или бизнес-процесс (например, «кадровые документы» или «выписки клиентов»). Если работаете через интегратора, заранее согласуйте, кто со стороны бизнеса будет принимать решения по доступам и срокам.

Для управления достаточно нескольких статусов (например, «новый», «в работе», «закрыто», «принято как риск») и 3-5 метрик без лишних деталей: сколько кейсов открыто и закрыто за период, доля находок без владельца, топ систем по риску, среднее время до назначения владельца.

Типичные ошибки при выборе и запуске DSPM

Самая частая ошибка - пытаться покрыть все системы за первый месяц. DSPM быстро находит много «интересного», но без фокусного пилота вы получите лавину находок и разочарование. Лучше выбрать 1-2 критичных источника (например, файловые шары отдела продаж и одну ключевую БД) и заранее определить, какие классы данных и сценарии риска вы хотите увидеть.

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

Третья - отсутствие модели владельцев и процесса согласования. Если у находки нет владельца данных, владельца системы и ответственного за исправление, она быстро становится «ничьей». В итоге DSPM превращается в витрину проблем, а не в инструмент управления риском.

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

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

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

Обычная история: в отделе продаж нужно «быстро проверить» качество выгрузки из CRM. Аналитик экспортирует клиентскую базу в Excel, сохраняет файл в общей сетевой папке «Общее\Временное», отправляет коллегам и забывает удалить. Через пару недель таких файлов становится несколько, часть переименована в «final_2», «актуальное», «для сверки».

После подключения DSPM к файловым шарам выясняется, что в одной папке лежат выгрузки с ИИН, телефонами и адресами, а рядом - сканы договоров и доверенностей. Самое неприятное не количество файлов, а доступы: у папки стоит «чтение для всех сотрудников», и права наследуются дальше на вложенные каталоги.

Почему «нет владельца»? Папку мог создать бывший сотрудник. Группа, которой он выдал доступ, осталась. В бизнесе уже никто не помнит, кто просил папку и зачем.

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

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

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

Быстрый чеклист перед покупкой и пилотом DSPM

Перед пилотом договоритесь не про «все данные компании», а про понятный старт. Иначе DSPM быстро превратится в поток находок, где непонятно, что критично и кто должен реагировать.

Ограничьте периметр: выберите 5-10 источников, которые действительно отражают риски (например, файловые шары отдела продаж, CRM-выгрузки, 1-2 основные БД, почтовые вложения в архиве). По каждому источнику заранее назначьте ответственных со стороны бизнеса и ИТ.

До запуска полезно проверить базовые вещи: список критичных классов данных и их приоритет, наличие гостевого/публичного/широкого доступа к хранилищам, места с дампами БД и выгрузками Excel/CSV, а также правило группировки находок (по системе, владельцу, типу данных или проекту). Отдельно продумайте, как будете назначать владельцев - по владельцу системы, подразделению, каталогу или тегам проекта.

Чтобы пилот был полезным, заранее выберите 3-4 метрики: топ рисков за неделю, среднее время до устранения, доля находок без владельца, доля «критичных» находок, которые подтверждаются при проверке.

Следующие шаги: как выбрать продукт и запустить пилот

Определите цель пилота и 2-3 риск-сценария, где результат будет понятен и бизнесу, и ИБ. Например: персональные данные в общих папках, секреты (пароли, ключи) в выгрузках и бэкапах, чувствительные таблицы в БД без владельца и без контроля доступа.

Затем зафиксируйте требования к продукту и среде: где развертываем (облако или on-prem, сегмент, доступы), что происходит с метаданными и результатами сканирования, какие интеграции нужны (AD/IdP, DLP/SIEM, тикетинг, каталоги данных, CMDB), какие отчеты и KPI ждут руководители, какие ограничения по окнам сканирования и нагрузке на БД, какие исключения должны быть сразу.

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

Процесс работы с находками лучше спланировать до старта: кто принимает находки (ИБ), кто исправляет (владельцы систем и данных), кто утверждает изменения (бизнес). Практичное правило для пилота: каждая находка должна получить владельца и статус в течение 3-5 рабочих дней.

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