Почему DLP не предотвращает все утечки: мессенджеры, личные устройства и другие слепые зоны

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

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

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

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

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

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

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

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

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

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

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

Затем бизнес-процессы постепенно меняются. Одно подразделение подключает сервис совместного редактирования документов. Другое переносит обсуждение проектов в новый мессенджер. Сотрудники начинают работать удаленно и чаще использовать личные устройства. Появляются подрядчики с доступом к корпоративным системам. Генеративный И И становится повседневным инструментом для подготовки писем, анализа документов и работы с кодом.

Контур может устареть после:

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

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

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

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

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

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

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

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

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

Еще одна сложная зона — использование личных смартфонов и компьютеров.

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

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

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

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

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

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

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

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

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

Не все пробелы возникают из-за новых технологий. Часть из них появляется в процессе эксплуатации DLP.

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

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

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

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

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

Другая крайность состоит в попытке контролировать слишком многое.

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

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

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

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

Федеральный закон № 152-ФЗ не устанавливает общей обязанности применять именно DLP. Статья 19 требует от оператора принимать необходимые правовые, организационные и технические меры для защиты персональных данных от неправомерного или случайного доступа и других неправомерных действий.

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

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

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

Начинать следует не с немедленного расширения лицензии или приобретения нового продукта. Сначала нужно понять природу разрыва.

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

После инвентаризации у компании появляется несколько вариантов:

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

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

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

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

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

DLP не контролирует организацию целиком. Она контролирует заданные категории данных в доступных ей каналах и по настроенным правилам.

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

Проверку действующей DLP стоит начинать не с вопроса о программе, а с другого: соответствует ли ее область контроля тому, как сотрудники действительно обращаются с информацией?