DLP-системы (Data Leak Prevention) не гарантируют защиты от утечек данных. Причина — в ошибках внедрения: неверная настройка политик, игнорирование новых каналов передачи данных, ставка только на сигнатурные методы. В результате бизнес остаётся уязвимым, несмотря на кажущуюся работоспособность системы защиты данных.
- 1. Введение
- 2. Ошибка 1. Защита без инвентаризации и аудита данных
- 3. Ошибка 2. Привилегированные пользователи становятся главной угрозой
- 4. Ошибка 3. ИИ-ассистенты как новый канал утечки
- 5. Ошибка 4. Фокус на личную информацию (PII) вместо интеллектуальной собственности
- 6. Ошибка 5. Стеганография и нестандартные методы вывода данных за периметр
- 7. Ошибка 6. Периферийные системы (тикет-сервисы) как вектор атак
- 8. Ошибка 7. Ограниченность сигнатурного подхода и необходимость поведенческого анализа
- 9. Ошибка 8. Статичные политики, не успевающие за изменениями бизнеса
- 10. Ошибка 9. Отсутствие пилотного внедрения
- 11. Выводы
Введение
Требования к защите данных в России последовательно ужесточаются, однако число утечек не снижается. Наоборот, поверхность для атак растёт. К традиционным каналам добавился искусственный интеллект (ИИ). За 2025 год количество утечек данных через генеративные ИИ-инструменты выросло в 30 раз. Чтобы упростить работу, люди загружают в чат-боты персональные данные, финансовую отчётность, внутреннюю переписку. И тем самым они становятся инициаторами утечки данных, часто даже неосознанно.
Стабильным источником риска остаются мессенджеры, корпоративная почта, облачные сервисы и файлообменники. Немалую угрозу несут уволенные сотрудники: около 38 % из них перед уходом из компании пытаются получить доступ к базам клиентов или партнёров. В целом же каждая вторая компания ежегодно фиксирует не менее 6 внутренних инцидентов безопасности.
При этом уровень фактической защищённости остаётся низким. По данным ФСТЭК России, базовый уровень защиты информации выстроен лишь примерно у 13 % из 170 организаций, относящихся к КИИ. Это означает, что у большинства компаний контроль утечек остаётся фрагментарным — несмотря на рост инвестиций и внимание СМИ к громким инцидентам.
На этом фоне спрос на системы защиты конфиденциальной информации (Data Leak Prevention, DLP) закономерно увеличивается. Но практика показывает: сам факт внедрения ещё не снижает риски. Эффект зависит от того, насколько корректно настроены политики контроля и встроена ли система в реальные рабочие процессы. Анализ инцидентов последних лет позволяет выделить типовые ошибки, которые чаще всего обнуляют эффективность DLP.
Ошибка 1. Защита без инвентаризации и аудита данных
DLP-проект должен начинаться не с выбора инструмента, а с понимания того, что нужно защищать. Если в компании нет перечня конфиденциальной информации и непонятно кто имеет к ней доступ, предсказуемо, что часть рисков просто остаётся вне поля зрения.
Пример ошибки: инцидент с Nike
В январе 2026 года группа WorldLeaks опубликовала на своём сайте около 1,4 ТБ внутренних данных Nike. Утечка затронула 188 347 файлов за период с 2020 по 2026 год. Среди них: технические пакеты, спецификации материалов, чертежи прототипов, схемы, дизайн-файлы, аудиты фабрик, информация о партнёрах, производственные процессы. Также в утёкших данных оказались внутренние бизнес-документы, стратегические презентации, обучающие материалы для сотрудников и партнёрские соглашения.
Примечательно, что персональных данных клиентов и сотрудников там не было. Злоумышленники получили только интеллектуальную собственность и операционную информацию — именно то, что создаёт конкурентное преимущество. Ни один из этих файлов по отдельности не нарушал типовых правил DLP. Системы были заточены на поиск личной информации (Personally Identifiable Information, PII). DLP ищет «паспорт», а не «чертёж подошвы», если чертёж не помечен особым образом.
Атакующие в данном случае применили тактику value-chain extortion — кражу данных, формирующих цепочку создания стоимости, вместо традиционной охоты за персональными данными.
Чем грозит ошибка
Конкуренты получают доступ к научно-исследовательским и опытно-конструкторским разработкам (Research and Development, R&D) и производственным процессам. Утечка создаёт дополнительные точки входа для атак на партнёров и всю цепочку поставок. Главное — всё это происходит не из-за того, что DLP не сработала. Проблема в том, что компания не знала, какие данные нужно защищать в первую очередь.
Как это исправить
Сначала нужно определить категории информации, которая требует защиты. Обычно это персональные данные, финансовая отчётность, коммерческая тайна, клиентские базы и конструкторская документация. Важно не пытаться объять необъятное, а выделить сведения, потеря которых ударит по бизнесу или приведёт к штрафам.
Затем — найти, где эти данные физически лежат. Они могут быть разбросаны по файловым серверам, базам данных, корпоративной почте, облачным хранилищам, конечным устройствам сотрудников. Для этого используются специализированные модули discovery, которые есть в современных DLP-системах.
Параллельно нужно понять, как данные движутся: кто с ними работает, куда их отправляет, какие каналы для этого использует (почта, мессенджеры, облака, флешки). Это позволяет отделить легитимные бизнес-потоки от потенциально опасных.
К процессу нужно подключить владельцев данных — руководителей отделов (Data Owners), которые знают, какие данные реально нужны их сотрудникам для работы. Без их участия любая классификация останется формальной.
Рисунок 1. Информация о Nike на сайте World Leaks (Источник: BleepingComputer)
Ошибка 2. Привилегированные пользователи становятся главной угрозой
Практически в любой компании есть категория сотрудников, для которой правила работают иначе. Например, топ-менеджерам и ключевым специалистам разрешают пользоваться мессенджерами для личных переписок, загружать файлы в облака, обходить DLP-контроль. Это удобно с точки зрения администрирования, но создаёт брешь, которой могут воспользоваться злоумышленники.
Система либо вообще не контролирует этих людей, либо настроена настолько лояльно, что любые подозрительные действия списываются на «особый статус». Парадокс в том, что именно привилегированные пользователи должны находиться под самым пристальным контролем: у них больше доступа, а значит, выше потенциальный ущерб.
Пример ошибки: инцидент с директором CISA
В августе 2024 года и. о. директора Агентства по кибербезопасности и защите инфраструктуры США (CISA) Мадху Готтумуккала загрузил конфиденциальные данные в публичную версию ChatGPT. К счастью это были не секретные сведения, а правительственные материалы, связанные с контрактами. В любом случае информация не должна была покидать федеральные сети.
Готтумуккала специально запросил и получил разрешение на использование ChatGPT, в то время как остальным сотрудникам этот инструмент был заблокирован. По сути, для него создали персональное исключение из общих правил. Системы безопасности сработали, датчики зафиксировали загрузку, множественные предупреждения появились в первую неделю августа. Но к моменту разбирательства данные уже ушли в инфраструктуру OpenAI.
Чем грозит ошибка
Модель исключений, созданная для повышения производительности, на деле превращает самых статусных сотрудников в самых рискованных. Инциденты обнаруживаются постфактум, когда данные уже покинули периметр. Для госкомпаний и госорганов утечка даже несекретных, но чувствительных документов оборачивается регуляторными расследованиями, потерей доверия и штрафами.
Как это исправить
Вместо того чтобы давать руководству «зелёный коридор», следует настроить политики так, чтобы они позволяли легитимные действия, но блокировали вредоносные. Технически это реализуется через связку DLP и PAM-систем (управления привилегированным доступом, Privileged Access Management). PAM отвечает за выдачу и контроль привилегированных доступов, DLP — за мониторинг действий.
Расширенный доступ должен предоставляться только по аргументированному запросу, где прописаны обоснование, уровень доступа и конкретный срок действия. Никаких пожизненных прав.
Также нужно регулярно проводить аудит систем на предмет излишних прав и лишних учётных записей. Причём сотрудники ИБ тоже должны попадать под эти проверки.
Ошибка 3. ИИ-ассистенты как новый канал утечки
Активное внедрение ИИ-агентов в корпоративную среду создаёт дополнительные векторы риска. Они интегрируются с почтовыми системами, календарями, чатами, репозиториями кода и CI/CD-пайплайнами, получая широкий доступ к внутренней информации. Предполагается, что агенты должны подчиняться тем же политикам безопасности, что и сотрудники, однако на практике архитектура их работы может вступать в противоречие с настройками DLP.
Согласно исследованию InfoWatch, 77 % сотрудников вставляют в поля ввода ИИ-ассистентов конфиденциальные данные. При этом около 82 % таких действий происходят через учётные записи и устройства, не зарегистрированные в корпоративных системах управления, что делает эту активность невидимой для средств защиты.
По данным Cybersecurity Insiders за 2026 год, отдельная проблема — «теневой ИИ»: 75 % опрошенных директоров по информационной безопасности обнаружили в своих сетях неутверждённые ИИ-инструменты, которые сотрудники внедрили самостоятельно, часто со встроенными учётными данными и избыточными привилегиями.
Рисунок 2. Опрос службы ИБ, есть ли в компании политики доступа для идентификаторов ИИ (Источник: Cybersecurity Insiders)
Рисунок 3. Опрос директоров по ИБ, знают ли они об использовании теневого ИИ в их компании (Источник: Cybersecurity Insiders)
Пример ошибки: инцидент с Microsoft Copilot
В январе 2026 года корпоративные клиенты Microsoft заметили, что Copilot начал обобщать письма, которые по настройкам DLP и меткам чувствительности должны были быть полностью исключены из обработки. Проблему зарегистрировали под идентификатором CW1226324. Среди пострадавших организаций оказалась Национальная служба здравоохранения Великобритании.
Баг в коде позволял ИИ-ассистенту получать доступ к содержимому писем из папок Outlook «Отправленные» и «Черновики» — несмотря на установленные защитные метки и политики DLP. Коммерческие предложения, проекты договоров, внутренние оценки, переписка с регуляторами — все эти данные могли обрабатываться Copilot и потенциально попадать в ответы другим пользователям или использоваться для обучения моделей. Microsoft подтвердила проблему и начала развёртывание исправления в начале февраля, однако между обнаружением и устранением прошло несколько недель.
Чем грозит ошибка
Проблема носит не столько злонамеренный, сколько архитектурный характер. Легитимный инструмент, наделённый широкими привилегиями, перестаёт корректно учитывать ограничения, заданные в системе безопасности.
Традиционные DLP создавались для работы с файлами и вложениями, но не рассчитаны на мониторинг операций копирования-вставки и взаимодействия с чат-интерфейсами. В результате компания теряет контроль над чувствительными данными, притом что формально все действия остаются в рамках разрешённых.
Как это исправить
Акцент смещается с ориентированных на файлы DLP к динамическим средствам контроля, отслеживающим потоки данных в браузере, операции копирования-вставки и активность в неуправляемых SaaS-сессиях. Необходимо провести инвентаризацию ИИ-инструментов, отделив ИИ-идентичности от пользователей, классифицировать их и внедрить политики загрузки информации в ассистенты.
DLP-решения должны поддерживать анализ контента в полях ввода браузера и контроль копирования-вставки в реальном времени с поведенческим анализом и сбором телеметрии для обнаружения аномалий. Адаптивные политики доступа должны блокировать рискованные вставки в чаты на основе контекста. Мониторинг необходимо распространить на неуправляемые устройства и учётные записи.
Рисунок 4. Эволюция автономных ИИ-идентификаторов (Источник: Cybersecurity Insiders)
Ошибка 4. Фокус на личную информацию (PII) вместо интеллектуальной собственности
Исторически DLP-системы настраивались под защиту персональных данных: номеров банковских карт, паспортных данных, телефонов, адресов. Риск регуляторных штрафов за утечку именно этой категории заставлял компании выстраивать защиту вокруг PII. Однако инциденты последних лет показывают, что фокус злоумышленников сместился. Их всё больше интересуют не персональные данные, а интеллектуальная собственность, технологические процессы, конструкторская документация, исходные коды — то, что формирует конкурентное преимущество и не подлежит восстановлению.
Согласно отчёту IBM Cost of a Data Breach 2025, в инцидентах с использованием неконтролируемых ИИ-инструментов (shadow AI) утечки интеллектуальной собственности происходят в 40 % случаев — значительно чаще, чем в среднем по всем инцидентам (33 %). При этом стоимость утечки одной записи, содержащей интеллектуальную собственность, достигает $178, что на 11 % выше средней стоимости утечки персональных данных ($160). Организации с высоким уровнем теневого ИИ несут в среднем на $670 000 больше убытков от утечек.
Пример ошибки: инцидент с инженером Google
В январе 2026 года федеральный суд признал бывшего инженера Google Линвея Дина виновным в краже коммерческой тайны. На протяжении года он копировал чувствительные ИИ-разработки в заметки на корпоративном ноутбуке, конвертировал их в PDF и выгружал в личное облачное хранилище.
За 12 месяцев набралось более 1200 документов — примерно 14 тысяч страниц конфиденциальной информации о технологиях Google. DLP не реагировала, поскольку каждое отдельное действие выглядело как рутинная работа с документацией, а сами файлы не содержали маркеров, по которым система была настроена искать утечки.
Чем грозит ошибка
Конкуренты или иностранные государства получают доступ к технологической документации и могут использовать наработки без затрат на исследования и разработки. Финансовые потери от кражи интеллектуальной собственности могут многократно превышать любые штрафы за утечку персональных данных.
Потеря технологических наработок обходится бизнесу значительно дороже за счёт утраты рыночных позиций и необходимости замедлить или остановить разработки. Кроме того, такие инциденты подрывают доверие партнёров и инвесторов, которые вкладывались в уникальные разработки компании.
Как это исправить
Чтобы DLP видела интеллектуальную собственность, нужно расширить классификацию защищаемых данных за пределы персональных данных. Конструкторская документация, исходные коды, технологические карты должны быть описаны и включены в политики контроля. Также нужен контекстный анализ, оценивающий не только содержимое файлов, но и действия пользователя. Например, если сотрудник начинает работать с документами, которые не относятся к его функциям, или скачивает необычно много материалов, система должна это заметить.
ИИ-сервисы должны получать доступ только к тем данным и задачам, для которых они предназначены, — так же, как это делается для привилегированных пользователей.
Ошибка 5. Стеганография и нестандартные методы вывода данных за периметр
Стеганография — метод сокрытия данных внутри других данных: текста в изображении, файла в аудио или видео. Для традиционных DLP-систем картинка остаётся картинкой, даже если внутри неё спрятана база данных клиентов или чертежи нового продукта. Такие решения анализируют текстовый контент, проверяют сигнатуры, но не заглядывают внутрь медиафайлов, которые сотрудники ежедневно пересылают через мессенджеры, почту и соцсети.
Эксперты «СёрчИнформ» подтверждают, что инсайдеры активно используют подобные техники. Например, склейку файлов штатными средствами операционной системы или специальные стеганографические программы, доступные в открытых источниках.
Пример ошибки: демонстрация Deep Secure
В 2018 году исследователи Deep Secure показали атаку, полностью обходящую DLP. Жертва получала polyformatted-файл, который визуально открывался как обычный Word-документ, но содержал fileless malware. При открытии распаковывался бэкдор, настроенный на прослушивание определённого хештега в Twitter (ныне — социальная сеть X). Атакующий публиковал картинку со стеганографически встроенной командой «выполнить dir».
Бэкдор извлекал команду из изображения, выполнял её, результат снова прятал в картинку и загружал на легальный файлообменник. DLP на всём пути видела только обычные картинки и трафик в легитимные соцсети. По оценке исследователей, можно было вывести до 300 тысяч записей кредитных карт, спрятав их в 50 изображениях, и остаться полностью необнаруженным.
Чем грозит ошибка
DLP-система, настроенная на анализ текстового трафика и сигнатур вредоносных программ, оказывается слепа к угрозам, замаскированным в медиафайлах. Атакующие могут годами выносить данные, маскируя их под обычный трафик изображений, видео или аудио. Обнаружить такую утечку стандартными средствами практически невозможно — для DLP картинка остаётся картинкой, даже если внутри неё скрыты терабайты информации.
Как это исправить
В России активно развивается собственное направление борьбы со стеганографией, основанное на методах активного обнаружения. Учёные из Самарского университета разрабатывают программные модули стегоанализа, использующие LSB-кодирование, метод преобразования Фурье, хи-квадрат и гистограммный анализ для выявления скрытой информации в изображениях. В РУТ (МИИТ) создан комплексный статистический стегодетектор StegoRevealer, зарегистрированный в Роспатенте, который способен обрабатывать изображения в режиме, близком к реальному времени, и интегрироваться в автоматизированные системы.
Первый уровень защиты — внедрение подобных инструментов стегоанализа для выборочной или автоматической проверки подозрительных медиафайлов. Однако полагаться только на автоматическое обнаружение рискованно: алгоритмы сокрытия постоянно эволюционируют, а сплошная проверка каждого файла требует колоссальных ресурсов.
Второй, более надёжный уровень — поведенческий анализ. DLP-система должна отслеживать не только содержимое, но и контекст: какие сотрудники, в каком объёме и куда загружают медиафайлы. Если инженер, который никогда этим не занимался, вдруг начинает массово заливать изображения на файлообменники или использовать специализированное ПО для склейки файлов, это тревожный сигнал, даже если сами картинки выглядят безобидно.
Третий подход, который предлагают российские эксперты, — использование стеганографии на стороне защиты. Например, внедрение невидимых человеческому глазу цифровых водяных знаков (forensic watermarking) с информацией о сессии пользователя на экран монитора. Это позволяет точно определить, кто именно сфотографировал или заскринил конфиденциальные данные. Такая проактивная защита не предотвращает саму передачу, но создаёт неоспоримые доказательства для расследования инцидентов.
Ошибка 6. Периферийные системы (тикет-сервисы) как вектор атак
При построении защиты компании обычно фокусируются на основных каналах передачи данных: корпоративной почте, веб-трафике, USB-устройствах. Однако периферийные системы, например тикет-сервисы (Okdesk, OTRS и аналоги), нередко остаются вне периметра контроля DLP. Они не воспринимаются как значимый канал риска, хотя активно используются злоумышленниками как для доставки вредоносного софта, так и для эксфильтрации данных. В российских компаниях такие системы широко применяются в техподдержке, ритейле и госсекторе, однако их безопасность часто недооценивают.
Пример ошибки: APT-Q-27 атакует через Zendesk
В середине января 2026 года CyStack зафиксировала скрытую атаку на финсектор. Вектор заражения проследили до отдела корпоративной поддержки клиентов. Сотрудник перешёл по вредоносной ссылке, полученной в тикете Zendesk. URL выглядел как безобидное изображение, но фактически загружал исполняемый файл, замаскированный под расширение .pif:
hxxps://storage[.]googleapis[.]com/iwantuu/photo202512.pif#image2025-12-29-14-53.jpg
Windows по умолчанию скрывает известные расширения, поэтому файл выглядел как легитимное изображение.
Рисунок 5. Как отображался файл в проводнике (Источник: CyStack)
Файл имел валидную (хоть и отозванную) цифровую подпись компании Portier Global Pty Ltd, что позволяло обходить фильтры SmartScreen. Дроппер создавал каталог под кеш Windows Update, скачивал легитимный загрузчик и вредоносную DLL. Затем техника DLL sideloading загружала финальную нагрузку в память, не оставляя следов на диске. Атака осталась незамеченной для почтовых шлюзов и антивирусов. Аналитики связали инфраструктуру и модульный дизайн бэкдора с группой APT-Q-27 (GoldenEyeDog).
Рисунок 6. Цепочка атак через Zendesk (Источник: CyStack)
Чем грозит ошибка
Email-шлюзы не видят атаку, антивирусы не детектят вредонос. Доверенные бизнес-системы превращаются в канал доставки вредоносного кода в обход всех стандартных защит.
Как это исправить
Распространить DLP-контроль на тикет-системы и другие периферийные каналы коммуникации, не ограничиваясь традиционной почтой и веб-трафиком.
Внедрить технические ограничения на уровне самих систем: настроить создание тикетов только для аутентифицированных пользователей, удалить плейсхолдеры, позволяющие использовать произвольные адреса, применять CAPTCHA для предотвращения автоматизированных атак.
Использовать поведенческий анализ вместо сигнатурного. Отслеживать аномальные паттерны, например обращение легитимного процесса к нестандартным DLL или создание скрытых каталогов, имитирующих системные пути.
Ошибка 7. Ограниченность сигнатурного подхода и необходимость поведенческого анализа
Архитектура DLP-систем базируется на сигнатурных методах — регулярных выражениях, списках ключевых слов, цифровых отпечатках файлов. Такой подход эффективен для обнаружения строго формализованных данных: номеров банковских карт, паспортных данных, документов с грифом «конфиденциально». Однако современные утечки всё чаще выходят за рамки подобных шаблонов.
Сигнатуры не фиксируют ситуации, когда сотрудник бухгалтерии обращается к репозиториям с исходным кодом, администратор авторизуется в системе ночью с давно неактивной учётной записи или пользователь дробит архив и отправляет его по частям. Каждое из этих действий по отдельности может выглядеть легитимно, однако в совокупности они формируют картину инцидента.
Поведенческий анализ (User and Entity Behavior Analytics, UEBA) предлагает иной подход. Вместо поиска точных совпадений система изучает активность пользователей и объектов, формируя базовый профиль нормативного поведения для каждого сотрудника. Она фиксирует типичные параметры: время входа в систему, географию подключений, объёмы передаваемых данных, частоту обращений к тем или иным ресурсам, цепочки действий «кто — кому — когда».
Когда реальное поведение начинает отклоняться от профиля, система вычисляет риск-скор — числовую оценку вероятности инцидента. Если скор превышает заданный порог, генерируется оповещение.
Пример ошибки: инцидент с бывшим инженером Intel
В ноябре 2025 года Intel подала иск против бывшего инженера из Сиэтла, который попытался вынести конфиденциальные данные. Его попытка использовать внешний диск была заблокирована DLP-контролями, однако он нашёл слепую зону и перенёс 18 000 файлов на сетевое хранилище (NAS), которое не отслеживалось сигнатурными правилами.
Сигнатурная DLP не заметила этого, ведь формально сотрудник не делал никаких запрещённых действий. Но поведенческий анализ мог бы среагировать на то, что сотрудник с высокими привилегиями массово перемещал данные в нестандартное место назначения на фоне скорого увольнения.
Чем грозит ошибка
Отсутствие поведенческих механизмов не позволяет DLP идентифицировать инсайдеров, действующих в рамках предоставленных полномочий, и не даёт возможности обнаруживать атаки, растянутые во времени или использующие нестандартные маршруты передачи информации.
Как это исправить
Сигнатурные методы нужно дополнять поведенческим анализом. UEBA-системы должны собирать данные со всех ключевых источников (почта, VPN, CRM, AD, облака) и отслеживать для каждого пользователя метрики: время доступа, геолокацию, объёмы передаваемых данных, типы запрашиваемых ресурсов и цепочки «кто — кому — когда». Важно сравнивать поведение сотрудника с коллегами из аналогичных должностей (peer-group analysis). Высокий риск-скор должен автоматически запускать процедуры реагирования — от дополнительной аутентификации до временной блокировки.
Ошибка 8. Статичные политики, не успевающие за изменениями бизнеса
Распространённая практика — однократная настройка DLP-политик на этапе внедрения системы с последующей многолетней эксплуатацией без содержательных изменений. При этом бизнес-процессы компании непрерывно эволюционируют: появляются новые продукты и направления, меняется состав партнёров, сотрудники перемещаются между отделами, внедряются дополнительные SaaS-сервисы. Политики защиты, адекватно отражавшие угрозы год назад, со временем либо начинают пропускать утечки по новым каналам, либо генерируют избыточное количество ложных срабатываний, блокируя уже неактуальные операции.
Пример ошибки: инцидент с инженером Google
Эта ситуация перекликается с уже упомянутым случаем с инженером Google (ошибка 4). Его действия на протяжении года не вызывали срабатываний именно потому, что политики DLP были статичны и описывали разрешённые операции «вчерашнего дня», не учитывая аномальность накопленной активности сотрудника, готовящегося к увольнению. Система защищала отдельные файлы, но не видела паттерна поведения.
Чем грозит ошибка
Система продолжает охранять данные, утратившие актуальную ценность, но пропускает инциденты в зонах реальной активности бизнеса. Администраторы вынуждены затрачивать ресурсы на разбор ложных срабатываний от устаревших правил, а инженеры ищут легитимные обходные пути для выполнения текущих задач, что дополнительно снижает уровень безопасности.
Как это исправить
Политики нужно пересматривать минимум раз в квартал, привлекая владельцев бизнес-процессов. Если правило даёт сотни ложных срабатываний или не срабатывает вовсе — это повод для корректировки. Отслеживать новые инструменты (мессенджеры, облака) и своевременно включать их в периметр контроля. Вместо статичных правил активнее использовать поведенческий анализ, который адаптируется к изменениям автоматически.
Ошибка 9. Отсутствие пилотного внедрения
DLP-систему часто запускают сразу в продуктивную среду без пилотного проекта. Без тестового периода и адаптации к реальным бизнес-процессам возникает одна из двух проблем. Либо система генерирует лавину ложных срабатываний, блокируя легитимные операции и парализуя работу, либо политики настраивают намеренно слабо, чтобы не мешать бизнесу, и DLP превращается в формальность, не фиксирующую реальные угрозы.
Пример ошибки: пентест Securitum
В апреле 2025 года специалисты Securitum провели аудит безопасности в компании с DLP-системой. Тестирование показало, что система пропускает запись чувствительных файлов на USB-накопители, хотя при попытке копирования выдавала сообщение об ошибке. Даже после установки дополнительного защитного ПО (ESET) простой shell-скрипт отключал защиту, позволяя обойти блокировку USB из-за отсутствия механизмов самозащиты у самого DLP-решения. Никакой пилотный проект не проводился, поэтому уязвимости остались незамеченными до момента аудита.
Чем грозит ошибка
Без предварительного тестирования в реальных условиях невозможно корректно оценить фактические маршруты движения данных, используемые каналы и потребность в исключениях. Настройка «вслепую» закономерно приводит либо к конфликту с бизнес-подразделениями, либо к созданию формальной защиты, не закрывающей актуальные угрозы.
Как это исправить
Обязательно проводить пилотный проект перед полноценным внедрением. На тестовом периоде собирать статистику о реальных потоках данных, выявлять неочевидные сценарии работы сотрудников и согласовывать политики с владельцами бизнес-процессов. Только после этого поэтапно включать защиту в продуктивную среду.
Выводы
Российский рынок DLP активно растёт. По оценкам, в 2026 году его объём может достичь 58 млрд рублей. Однако, как показывают приведённые примеры, увеличение количества внедрённых систем не гарантирует пропорционального роста защищённости. Главные риски связаны не с отсутствием DLP как таковой, а с её конфигурацией: защитой не тех данных, созданием «слепых зон» для руководства, отсутствием поведенческого анализа и невниманием к новым каналам (ИИ-ассистенты, тикет-системы). Без встраивания DLP в реальные бизнес-процессы и регулярного пересмотра политик система рискует остаться дорогостоящим инструментом формального соответствия, не закрывающим актуальные угрозы.
