Каналы утечки информации: что проверить перед запуском DLP

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

По данным исследования «СёрчИнформ», в 2025 году с утечками персональных данных столкнулась примерно половина российских компаний — 51%. Основными каналами стали мессенджеры, на которые пришлось 57% инцидентов, и электронная почта — 52%. В малом и среднем бизнесе картина похожая: мессенджеры использовались в 58% случаев, почта — в 49%, съемные носители — в 28%, облачные хранилища — в 23%.

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

Ландшафт угроз: где компания теряет данные

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

В наших проектах мы обычно разбиваем каналы на четыре группы.

Коммуникационные каналы

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

Проблема здесь не только в намеренном сливе информации. Сотрудник может:

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

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

Съемные носители и локальные устройства

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

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

DLP должна различать как минимум три сценария:

1. Разрешенная рабочая передача. Например, сотрудник копирует обезличенный файл на корпоративный носитель.

2. Передача с повышенным риском. Документ содержит персональные данные или коммерческую информацию, а носитель не зарегистрирован в компании.

3. Явное нарушение политики. Сотрудник копирует большой массив документов перед увольнением или передает данные на устройство, которое не связано с его рабочими задачами.

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

Облачные хранилища и внешние SaaS-сервисы

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

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

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

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

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

Печать, скриншоты и визуальный канал

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

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

Для таких зон могут понадобиться дополнительные меры:

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

DLP эффективна не тогда, когда видит абсолютно всё, а тогда, когда компания понимает, какие события действительно требуют реакции.

Как провести аудит каналов до установки системы

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

Шаг 1. Соберите карту данных

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

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

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

Шаг 2. Проведите интервью с владельцами процессов

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

На интервью стоит задавать не общий вопрос «как вы передаете документы?», а просить описать конкретный сценарий:

1. Где появляется исходный файл?

2. Кто его обрабатывает?

3. Через какой канал он передается?

4. Какие данные можно удалить или обезличить?

5. Что произойдет, если система заблокирует операцию?

6. Кто должен принять решение при срабатывании правила?

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

Шаг 3. Сопоставьте каналы с рисками

После интервью удобно свести результаты в рабочую таблицу.

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

Правовой фундамент: мониторинг должен быть легитимным

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

Для легитимизации мониторинга обычно требуется комплекс мер:

• ввести режим коммерческой тайны в соответствии с 98-ФЗ;
• утвердить перечень конфиденциальной информации;
• описать правила использования электронной почты, мессенджеров, облачных сервисов и съемных носителей;
• закрепить порядок контроля рабочих коммуникаций в локальных нормативных актах;
• получить письменные согласия сотрудников на обработку персональных данных в системе;
• определить ответственных за доступ к журналам и расследование инцидентов;
• установить сроки хранения событий DLP и порядок их удаления.

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

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

Обучение — часть правового и технического контура

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

Хороший онбординг DLP включает:

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

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

Технические ловушки: SSL-перехват и электронная подпись

Перехват SSL/TLS-трафика часто рассматривают как универсальный способ увидеть, что происходит внутри защищенного соединения. Но в корпоративной инфраструктуре есть сервисы, которые нельзя проверять по стандартному сценарию подмены сертификата.

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

Перед включением SSL-инспекции необходимо составить список исключений:

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

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

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

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

Нагрузка на инфраструктуру: SPAN, серверы и рабочие станции

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

Порт зеркалирования и сетевое оборудование

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

До внедрения нужно проверить:

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

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

Производительность рабочих станций

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

Особого внимания требуют:

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

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

Серверная мощность и хранение событий

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

Расчет серверных мощностей лучше строить на фактической телеметрии пилота:

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

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

Как настроить правила без потока ложных срабатываний

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

Настройку лучше вести по уровням.

Первый уровень — наблюдение

На старте система фиксирует действия, но не блокирует их. Это позволяет увидеть:

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

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

Второй уровень — предупреждение

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

Третий уровень — выборочная блокировка

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

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

Регламент реагирования: что делать при обнаружении инцидента

DLP не завершает работу в момент блокировки. Система только сообщает, что действие соответствует определенному правилу. Дальше начинается процесс расследования, который должен быть заранее описан.

Минимальный маршрут выглядит так:

1. Зафиксировать событие. Сохранить сведения о пользователе, устройстве, файле, канале, времени и сработавшем правиле.

2. Проверить контекст. Выяснить, была ли операция частью рабочего сценария, ошибкой адресата или намеренной передачей.

3. Ограничить дальнейшее распространение. При необходимости отозвать ссылку, заблокировать учетную запись, остановить доступ к хранилищу или изолировать устройство.

4. Определить масштаб. Проверить, какие данные затронуты, сколько записей могло быть передано и кто еще имел доступ.

5. Подключить ответственных. В зависимости от ситуации это ИБ, ИТ, юристы, владелец процесса, служба персонала и руководство.

6. Оформить результат. Зафиксировать причину, принятые меры и изменения, которые нужно внести в правила.

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

При выявлении утечки персональных данных нужно учитывать требования 152-ФЗ. Согласно указанной в фактуре статье 21, оператор обязан уведомить Роскомнадзор о выявленном факте утечки в течение 24 часов. Поэтому у компании заранее должны быть определены ответственные, шаблоны внутренней фиксации инцидента и порядок передачи информации юристам и руководству.

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

Как связать внедрение с бизнес-эффектом

Рынок DLP в России оценивается в 47 млрд рублей в 2025 году, а на 2026 год прогнозируется рост до 58 млрд. Это показывает, что системы предотвращения утечек перестали быть инструментом только для крупных банков и промышленных холдингов. Но сам по себе бюджет на DLP не создает ROI.

Эффект появляется, когда компания может связать внедрение с измеримыми результатами:

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

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

Порядок действий перед промышленным запуском

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

1. Определить категории данных и владельцев информационных активов.

2. Описать основные каналы передачи по каждому бизнес-процессу.

3. Выделить мессенджеры, почту, съемные носители, облака, печать и веб-сервисы, которые действительно используются командой.

4. Подготовить локальные нормативные акты, согласия и правила электронной коммуникации.

5. Составить список систем, исключаемых из SSL-перехвата из-за ЭП и особенностей аутентификации.

6. Рассчитать сетевую и серверную нагрузку на основании пилотных данных.

7. Развернуть агентов на ограниченной группе и две недели отслеживать производительность рабочих станций.

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

9. Назначить владельцев реагирования и установить целевые MTTD и MTTR.

10. Провести обучение сотрудников с объяснением разрешенных альтернатив.

11. Проверить сценарий уведомления об утечке персональных данных в установленный срок.

12. Через месяц после запуска пересмотреть правила по статистике ложных срабатываний и реальных инцидентов.

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

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