Защита данных: как выбрать надежную DLP-систему

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

Архитектура DLP: что именно система должна контролировать

DLP — Data Loss Prevention. Класс систем, которые обнаруживают, классифицируют и ограничивают передачу чувствительных данных. В нормальной архитектуре DLP не существует отдельно от каталогов пользователей, почтовой инфраструктуры, файловых хранилищ, прокси, SIEM и процессов ИБ.

Есть три базовых слоя.

Endpoint нужен, если в компании есть флешки, локальная печать, удаленные сотрудники, ноутбуки вне периметра. Network нужен, если ключевой риск — отправка данных через почту, веб-формы, облачные сервисы. Storage нужен, если никто не знает, где лежат персональные данные, коммерческие предложения, сканы паспортов и экспорт из CRM.

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

Например, для банка и производственной компании профиль риска разный. В банке критичны выгрузки из АБС, клиентские анкеты, ПДн, документы по кредитам. На производстве — чертежи, спецификации, техпроцессы, данные подрядчиков. В IT-компании — исходный код, токены, дампы баз, проектные документы. Одинаковая DLP-политика для этих трех сценариев даст шум, конфликты и ложное чувство защиты.

DLP не защищает «все данные». Она защищает описанные классы данных в описанных каналах. Все остальное — рекламная формулировка.

С чего начинать выбор DLP-системы

Выбор DLP-системы начинается не с демо вендора. Сначала нужен инвентарь данных и каналов. Иначе система будет ловить номера телефонов в письмах отдела продаж и пропускать архивы с клиентской базой через облачный диск.

Минимальный порядок работ выглядит так:

1. Описать классы данных.

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

2. Найти места хранения.

CRM, ERP, файловые серверы, почта, облачные диски, базы данных, локальные папки, резервные копии. Storage DLP на этом этапе часто показывает неприятную картину: критичные файлы лежат в общих папках без владельца.

3. Описать каналы передачи.

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

4. Определить действия системы.

Только мониторинг. Уведомление ИБ. Предупреждение пользователя. Карантин. Блокировка. Эскалация в SIEM. Разные данные требуют разных действий.

5. Проверить агентскую модель.

Поддержка Windows, macOS, Linux, VDI, терминальных серверов, удаленных ноутбуков. Если 30% сотрудников работают на macOS, а агент там урезан, это не мелкая деталь. Это дыра в покрытии.

6. Проверить интеграции.

AD/LDAP, почтовые серверы, SIEM, прокси, CASB, MDM, Service Desk, облачные хранилища. DLP без интеграций быстро превращается в отдельный склад событий.

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

Методы анализа: сигнатуры уже недостаточны

Старая DLP жила на регулярных выражениях и словарях. Номер паспорта. ИНН. Телефон. Почтовый адрес. Ключевые слова. Это работает, но плохо масштабируется. Номер телефона в подписи менеджера не равен утечке клиентской базы. Слово «договор» в письме не делает письмо инцидентом.

Современные программы для защиты данных используют несколько методов одновременно.

Регулярные выражения

Подходят для структурированных данных: номера карт, паспортные данные, ИНН, СНИЛС, телефоны, e-mail. Плюс — быстрый старт. Минус — высокий уровень ложных срабатываний при слабом контексте.

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

Цифровые отпечатки

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

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

OCR

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

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

Машинное обучение

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

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

UEBA

UEBA — User and Entity Behavior Analytics. Анализ поведения пользователей и сущностей. Для DLP это полезно, когда инцидент нельзя поймать одной сигнатурой.

Пример: сотрудник отдела закупок обычно отправляет 10–20 писем в день внутри домена. Затем за вечер скачивает большой объем договоров, архивирует их, отправляет на внешний адрес и подключает USB-накопитель. Каждое событие отдельно может быть допустимым. Последовательность — уже риск.

Критический показатель здесь — False Positive. Ложные срабатывания убивают внедрение быстрее, чем отсутствие редкой функции. Если аналитики получают поток мусора, они перестают смотреть события. Если пользователи видят блокировку нормальной работы, они ищут обходные пути.

Комплаенс: DLP и защита персональных данных

Для российских компаний отдельный слой — 152-ФЗ. Оператор персональных данных обязан принимать организационные и технические меры для защиты ПДн от неправомерного доступа. DLP не закрывает закон целиком. Но она дает контролируемый механизм: обнаружение ПДн, мониторинг передачи, фиксация событий, ограничение каналов.

В GDPR логика схожая: после 2018 года требования к защите персональных данных в международных процессах стали жестче. Особенно в части контроля доступа, обработки, передачи и инцидент-менеджмента.

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

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

DLP помогает доказать, что компания не только написала регламент, но и контролирует его исполнение. Однако если персональные данные лежат в Excel-файлах на общей сетевой папке с доступом «Все сотрудники», DLP будет фиксировать симптом. Не лечить архитектуру.

Комплаенс без инвентаризации данных — бумага. DLP без комплаенса — дорогой сенсор без процесса реагирования.

Ловушки внедрения: где DLP ломает бизнес

Главная ошибка — включить блокировки до аудита. На презентации это выглядит уверенно: запретим отправку ПДн наружу, запретим USB, запретим печать. В эксплуатации это превращается в очередь заявок, ручные исключения и конфликт ИБ с бизнесом.

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

Правильный деплой идет по фазам.

Фаза 1. Пассивный мониторинг

Система ничего не блокирует. Только собирает события. Цель — понять реальные каналы передачи, типы документов, группы пользователей, объем шума. Срок зависит от размера компании, но меньше нескольких недель обычно недостаточно: не видно циклов отчетности, зарплатных периодов, закрытия месяца.

Фаза 2. Классификация и базовые политики

На основании мониторинга создаются классы данных и правила. Не 200 политик сразу. Несколько контролируемых сценариев:

• отправка ПДн на внешние домены;
• выгрузка клиентских баз;
• копирование критичных документов на USB;
• отправка архивов с исходным кодом;
• массовая печать документов с чувствительными метками.

На этом этапе лучше использовать предупреждения и уведомления. Пользователь видит причину. ИБ видит контекст. Бизнес может оспорить правило.

Фаза 3. Ограниченные блокировки

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

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

Фаза 4. Интеграция с расследованиями

События DLP должны попадать в SIEM. Там они коррелируются с входами в систему, EDR-событиями, сетевыми аномалиями, изменением прав доступа. Иначе аналитик видит только факт отправки файла, но не видит, что за час до этого у пользователя сменился IP, сработала фишинговая ссылка и началась массовая выгрузка из CRM.

Техническая зрелость DLP проявляется не в красивом дашборде. Она проявляется в том, сколько времени нужно, чтобы из события получить ответ: кто, что, откуда, куда, почему, было ли это разрешено, что делать дальше.

Интеграция с SIEM и UEBA: DLP как сенсор, а не остров

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

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

Хорошая интеграция должна поддерживать:

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

UEBA усиливает эту связку. Она снижает зависимость от жестких правил. Но не отменяет их. Поведенческий анализ хорош там, где действия формально разрешены, но последовательность подозрительна.

Пример рабочей корреляции:

1. Пользователь получает письмо с фишинговым вложением.

2. EDR фиксирует запуск подозрительного процесса.

3. Через VPN начинается вход из нетипичной географии.

4. Пользователь скачивает большой объем файлов из хранилища.

5. DLP фиксирует попытку отправки архива наружу.

6. SIEM поднимает приоритет инцидента, потому что события связаны.

Без такой связки DLP увидит только последний шаг. Иногда этого достаточно для блокировки. Но недостаточно для понимания атаки.

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

Как оценивать DLP на пилоте

Пилот должен проверять не презентацию, а эксплуатацию. Дайте системе реальные данные, реальные каналы, реальные группы пользователей. Не стоит строить тест только на искусственных файлах «паспорт Иванова.docx». Такая проверка покажет, что регулярное выражение умеет искать номер паспорта. Это не выбор DLP-системы.

Нормальный пилот включает несколько сценариев:

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

Оценивать надо не только «поймала/не поймала». Метрики шире.

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

Что должно быть в спецификации перед покупкой

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

В документе стоит зафиксировать:

1. Контролируемые каналы.

Почта, веб, USB, печать, буфер обмена, облачные диски, мессенджеры, VDI, терминальные сессии. По каждому — уровень контроля: мониторинг, предупреждение, блокировка.

2. Поддерживаемые платформы.

Версии Windows, macOS, Linux, серверные ОС, VDI, MDM, удаленная работа. Нужна проверка на фактических рабочих местах.

3. Методы анализа.

Регулярные выражения, словари, fingerprinting, OCR, ML-классификация, UEBA. По каждому — условия использования и ограничения.

4. Производительность.

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

5. Интеграции.

AD/LDAP, SIEM, SOAR, Service Desk, почтовые системы, прокси, CASB, облачные платформы.

6. Журналирование и хранение событий.

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

7. Роли и доступы.

Разделение администраторов, аналитиков, аудиторов. Логирование действий внутри самой DLP.

8. Процесс исключений.

Владелец данных, срок действия, согласование, аудит.

9. Обновление политик и моделей.

Кто обновляет, как тестируется, как откатывается, как фиксируются изменения.

10. Требования по комплаенсу.

152-ФЗ, внутренние регламенты, отраслевые нормы, требования к отчетности.

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

Ограничения, о которых надо сказать до бюджета

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

DLP снижает риск там, где есть:

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

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

Выбирать DLP надо как архитектурный компонент, а не как «программу для защиты данных». Сначала карта данных. Потом каналы. Потом методы детекта. Потом пилот на реальных сценариях. Потом ограниченные блокировки. Потом корреляция с SIEM и UEBA.

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