На аудите DLP в одной финансовой компании я увидел классическую картину: система стояла, политики включены, лицензии оплачены - а менеджер по работе с VIP-клиентами три месяца сливал выписки по счетам через личный Gmail без единого алерта. Причина банальная: политика проверяла вложения формата .xlsx и .csv, а сотрудник копировал данные в тело письма. DLP честно пропускала всё, что не попадало под шаблон вложения. Эта история - не исключение, а норма. По данным Ponemon/Proofpoint Cost of Insider Threats Global Report 2022, средняя годовая стоимость инсайдерских инцидентов достигла $15,38 млн - рост на 34% по сравнению с 2020 годом. Проблема не в отсутствии DLP, а в том, как настроены политики предотвращения утечек данных.
Почему типовые DLP-политики пропускают инсайдеров
Большинство DLP-внедрений в российских компаниях работают в режиме "ловим очевидное": регулярки для номеров банковских карт, ключевые слова типа "конфиденциально" и блокировка USB-портов. Для противодействия инсайдерским угрозам этого мало, потому что инсайдер - не внешний злоумышленник. Он знает, какие слова триггерят систему, какие каналы мониторятся и как обойти контроль, не нарушая формальных правил.Proofpoint в анализе конвергенции DLP и ITM (Insider Threat Management) разделяет защиту от утечек на три уровня, и работать они должны одновременно:
Контентный анализ - что передаётся. Система проверяет содержимое по цифровым отпечаткам, регулярным выражениям, ключевым словам, словарям. Для повышения точности используют Exact Data Match (EDM) - прямое сопоставление с эталонной базой, и Indexed Document Match (IDM) - fingerprinting документов. По данным Palo Alto Networks, оба метода серьёзно снижают количество ложных срабатываний по сравнению с голым regex.
Контекстный анализ - при каких обстоятельствах передаётся. Кто отправитель, с какого устройства, в какое время, кому адресовано. Одна и та же таблица с клиентской базой - рутина для менеджера по продажам в 10:00 и красный флаг в 23:00 с личного устройства.
Поведенческий анализ (UBA/UEBA) - почему сотрудник так действует. Система фиксирует отклонения от нормального паттерна: резкий рост объёма скачиваемых файлов, обращение к данным, с которыми сотрудник раньше не работал, активность в нерабочие часы.
Только в связке эти три уровня формируют политики предотвращения утечек данных, способные ловить реального инсайдера, а не только случайную отправку файла не тому адресату.
Инсайдер - это не всегда злоумышленник
Прежде чем строить политики, стоит разделить угрозы на категории. Согласно классификации Virtuelle Group, типичные инсайдерские сценарии делятся на пять групп:- Случайная ошибка - сотрудник отправил файл не тому получателю или вложил не тот документ. Самый частый случай, и самый недооценённый.
- Несанкционированный шаринг - пересылка рабочих файлов через личную почту или облако "для удобства". Мотив - не навредить, а "так быстрее".
- Преднамеренная кража данных - увольняющийся или обиженный сотрудник целенаправленно выгружает базы клиентов, финансовые отчёты, IP.
- Утечка при удалённой работе - личные устройства, незащищённые сети, копирование на USB, снимки экрана.
- Несоблюдение политик обработки данных - нарушение внутренних регламентов и требований ФЗ-152, включая передачу ПДн без согласия субъекта (ст. 9 ФЗ-152).
Настройка DLP-политик для электронной почты
Email остаётся главным каналом утечек по одной причине: он легитимный. Сотрудник отправляет десятки писем в день, и задача DLP - отделить нормальный рабочий поток от эксфильтрации. Инсайдерские угрозы через почту - это не только вложения, но и тело письма, тема, даже получатель.
Базовые правила контентного анализа
Начните с регулярных выражений для чувствительных данных в российском контексте. Минимальный набор шаблонов, который должен быть в каждой DLP-политике для email:
Код:
# Номер банковской карты (Visa, MasterCard, МИР)
\b\d{4}[\s\-]?\d{4}[\s\-]?\d{4}[\s\-]?\d{4}\b
# Паспорт РФ (серия и номер); обязательно комбинировать с контекстными словами (паспорт, серия, выдан), иначе FP rate неприемлем
# Пример с контекстом: (?i)(паспорт|серия)[\s:]*\d{2}\s?\d{2}\s?\d{6}
\b\d{2}\s?\d{2}\s?\d{6}\b
# ИНН юрлица (10 цифр) и физлица (12 цифр); без валидации контрольной цифры - высокий FP rate, используйте EDM или валидатор по алгоритму ФНС
\b(\d{10}|\d{12})\b
# СНИЛС
\b\d{3}[\-\s]\d{3}[\-\s]\d{3}[\s]?\d{2}\b\b\d{10}\b сгенерирует тысячи ложных срабатываний: он поймает любые 10-значные числа, включая номера заказов и внутренние идентификаторы. Привязывайте regex к условиям: адрес получателя вне корпоративного домена, наличие в письме ещё двух-трёх чувствительных полей (ФИО + номер счёта + сумма), отправка в нерабочее время.Действия при срабатывании
Для email-канала DLP-система поддерживает несколько типов реакции:| Действие | Когда применять | Риск для бизнеса |
|---|---|---|
| Блокировка | Подтверждённая эксфильтрация (преднамеренная кража) | Высокий - может заблокировать легитимную переписку |
| Шифрование | Отправка чувствительных данных партнёрам/контрагентам | Низкий - письмо доставляется, но защищено |
| Карантин с уведомлением руководителя | Подозрительная отправка, требующая проверки | Средний - задержка доставки |
| Логирование без блокировки | Первичный мониторинг, пилотная эксплуатация | Нулевой - но утечка не предотвращается |
| Уведомление пользователя | Случайные ошибки, обучение персонала | Низкий - сотрудник получает предупреждение |
На этапе пилотной эксплуатации всегда начинайте с логирования. Две-четыре недели в режиме наблюдения покажут реальную картину: сколько срабатываний в день, какой процент ложных, какие подразделения генерируют основной поток алертов. Только после калибровки переходите к блокировке. Я видел проекты, где блокировку включали сразу - через неделю бизнес требовал "выключить эту штуку".
Sequence detection: цепочки подозрительных действий
Согласно документации Microsoft Purview Insider Risk Management, одна из рабочих техник - sequence detection, обнаружение последовательности действий. Суть: DLP-система анализирует не отдельные события, а цепочки:- Сотрудник скачал 50 файлов с SharePoint за 15 минут.
- Переименовал файлы (убрал маркеры конфиденциальности из названий).
- Отправил их архивом на внешний email-адрес.
Ещё один полезный механизм - cumulative exfiltration detection: система отслеживает не разовую отправку, а совокупный объём данных за период. Сотрудник, который каждый день отправляет по одному небольшому файлу на личную почту, не вызовет срабатывания порогового правила. Но кумулятивный контроль зафиксирует, что за месяц он вынес 200 документов. Именно так чаще всего и работает "тихая" эксфильтрация.
Контроль утечек через мессенджеры
Настройка DLP для мессенджеров - самый болезненный вопрос. Здесь сталкиваются два мира: корпоративные платформы с API для интеграции и личные мессенджеры с end-to-end шифрованием.
Корпоративные мессенджеры: Teams, Slack
Microsoft Teams и Slack поддерживают нативную интеграцию с DLP. В Teams политики Microsoft Purview Information Protection применяются к сообщениям в каналах и личных чатах - можно блокировать отправку сообщений с чувствительными данными или заменять контент уведомлением "сообщение заблокировано политикой DLP". В Slack аналогичные возможности доступны через Slack Enterprise Grid с подключением DLP-провайдера через API.Настройка DLP-политик для корпоративных мессенджеров мало отличается от email: те же regex-шаблоны, те же словари, те же цифровые отпечатки. Разница в скорости: в мессенджере сотрудник ожидает мгновенную доставку, и задержка на анализ контента даже в 2-3 секунды воспринимается как "всё висит". Это нужно учитывать при выборе между inline-блокировкой и асинхронным анализом.
Личные мессенджеры: Telegram, WhatsApp
С личными мессенджерами ситуация сложнее на порядок. WhatsApp использует сквозное (E2E) шифрование, обычные чаты Telegram - шифрование клиент-сервер (MTProto), E2E в Telegram доступно только в секретных чатах. На сетевом уровне SSL-инспекция может дать частичный доступ к трафику веб-версий, но Desktop-клиенты с certificate pinning обходят корпоративный MITM. Основным средством контроля остаётся endpoint-агент - компонент DLP на рабочей станции.Endpoint-агент перехватывает действия до шифрования:
- Мониторинг буфера обмена - фиксирует copy-paste чувствительных данных в окно мессенджера.
- Контроль файловых операций - детектирует перетаскивание или прикрепление файлов к Telegram Desktop.
- Снимки экрана - некоторые DLP-решения (SearchInform КИБ, Solar Dozor) фиксируют содержимое окна приложения.
- Контроль ввода с клавиатуры - спорный метод с точки зрения приватности, но технически рабочий.
Для российского рынка DLP-систем контроль мессенджеров реализован по-разному. SecureTower заявляет поддержку перехвата Viber и Telegram, SearchInform КИБ мониторит мессенджеры через агент на рабочей станции, Solar Dozor контролирует мессенджеры через агент с поддержкой Windows, GNU/Linux и macOS. При выборе решения проверяйте не маркетинговые заявления, а конкретную механику: перехватывает система текст сообщений или только факт запуска приложения. Разница - как между видеонаблюдением и датчиком движения.
DLP для облачных сервисов и Shadow IT
Облачные сервисы - третий критический канал утечек. Сотрудник загружает отчёт на Google Drive "чтобы поработать дома", расшаривает папку на Яндекс.Диске для подрядчика, синхронизирует рабочие файлы через Dropbox на личный ноутбук. Каждое из этих действий - потенциальная инсайдерская угроза, и DLP-система должна контролировать все три состояния данных в облаке: data at rest (хранение), data in motion (передача) и data in use (использование).Два подхода к облачному DLP
Согласно классификации Palo Alto Networks и CrowdStrike, облачный DLP реализуется двумя способами:API-based - DLP-система подключается к облачному сервису через API и сканирует уже загруженные файлы. Плюс: не влияет на производительность, полный доступ к метаданным (кто создал, кому расшарил, когда изменил). Минус: работает post-factum - файл уже в облаке, когда система его находит.
Inline через CASB/SSE - Cloud Access Security Broker (CASB) или Security Service Edge (SSE) встаёт прослойкой между пользователем и облачным сервисом. Весь трафик к SaaS-приложениям проходит через CASB, где применяются DLP-политики в реальном времени. Плюс: превентивная блокировка. Минус: требует перенаправления трафика (прокси-режим или агент), может конфликтовать с VPN.
В инфраструктурах на Microsoft 365 нативная интеграция с Microsoft Defender for Cloud Apps (бывший MCAS) - полноценным CASB - покрывает OneDrive, SharePoint, Teams и Exchange Online без дополнительных прослоек. Для сторонних SaaS (Salesforce, Box, Dropbox) работает через API-коннекторы или reverse proxy. Для Google Workspace аналогичную роль выполняют Google DLP-правила в Admin Console. А вот для Яндекс.Диска и других российских облаков нативной DLP-интеграции нет - потребуется endpoint-агент или CASB с поддержкой российских сервисов. На практике это InfoWatch Traffic Monitor или SearchInform КИБ через контроль браузерного трафика.
Shadow IT: невидимые облака
Отдельная головная боль - Shadow IT. По анализу CrowdStrike, сотрудники используют неодобренные облачные сервисы для обмена файлами без ведома ИТ-отдела. DLP-система на сетевом шлюзе может обнаружить обращения к неавторизованным доменам: file.io, wetransfer.com, temp.sh. На практике формируется allowlist разрешённых облачных сервисов, и любое обращение за его пределы генерирует алерт или блокируется.Нужно помнить о требованиях ФЗ-152: если в облачный сервис загружаются персональные данные, оператор ПДн обязан обеспечить их конфиденциальность (ст. 7 ФЗ-152). Использование зарубежных облачных хранилищ для ПДн российских граждан создаёт дополнительные комплаенс-риски, которые DLP-политика должна учитывать через блокировку загрузки ПДн на иностранные площадки.
Ложные срабатывания: как не убить бизнес-процессы
Главный враг DLP-администратора - не инсайдер, а ложное срабатывание. Политика, которая блокирует каждое третье легитимное письмо, будет отключена бизнесом через неделю. По данным Proofpoint, именно высокий уровень false positives - причина, по которой организации не переводят DLP из режима мониторинга в режим блокировки.Конкретные приёмы снижения ложных срабатываний:
Комбинируйте условия. Не один regex, а regex + контекст (внешний получатель + нерабочее время + объём данных выше порога). Каждое дополнительное условие кратно снижает false positive rate.
Используйте EDM вместо regex для структурированных данных. Exact Data Match сверяет содержимое с реальной базой (таблица клиентов, список сотрудников), а не с абстрактным шаблоном. Если в вашей DLP есть поддержка EDM - используйте его для критических данных в первую очередь.
Создавайте исключения для бизнес-процессов. Бухгалтерия регулярно отправляет платёжные документы с реквизитами. Финансовый отдел обменивается отчётами с аудиторами. Для этих процессов создаются allowlist-правила: разрешённые отправители -> разрешённые получатели -> разрешённые типы данных. Всё, что выходит за рамки allowlist, - алерт.
Калибруйте пороги. Риск-скоры настраиваются не раз и навсегда. Документация Microsoft Purview рекомендует периодически пересматривать пороги на основе аналитики: если за месяц 90% алертов ложные - порог нужно поднять. Звучит очевидно, но я видел системы, где пороги не менялись с момента внедрения два года назад.
Чеклист настройки DLP-политик против инсайдерских угроз
Этот чеклист можно передать DLP-администратору или включить в отчёт по аудиту ИБ.Честный разговор о том, что DLP не умеет. Инсайдер, который фотографирует экран на смартфон, диктует данные по телефону или запоминает ключевую информацию - вне зоны действия любой DLP. Система предотвращения утечек данных контролирует цифровые каналы, не физические. Самая частая ошибка, которую я наблюдаю в проектах - ожидание от DLP стопроцентной защиты.
DLP ловит 80% типовых сценариев: случайные ошибки, "удобную" пересылку через личную почту, массовую выгрузку перед увольнением. Оставшиеся 20% - целенаправленные атаки подготовленного инсайдера, против которых нужны UBA, контроль физического доступа, процедуры offboarding и проверка службой безопасности.
Второй момент, который мало кто проговаривает вслух: DLP-проект без классификации данных - деньги на ветер. Я видел внедрения, где политики создавались "по ощущениям" безопасника, без участия владельцев данных из бизнеса. Результат - тысячи алертов в день, релевантных - единицы. Через три месяца алерты перестают смотреть, и система превращается в дорогой логгер.
Кто реально хочет закрыть канал инсайдерских утечек - начинайте не с покупки DLP, а с инвентаризации данных и честного ответа на вопрос: что именно мы защищаем и от какого конкретно сценария. Возьмите чеклист из этой статьи, пройдитесь по пунктам 1-4 - и вы уже будете впереди большинства компаний, которые купили DLP за миллионы и получили дорогой логгер.
Последнее редактирование модератором:
