В понедельник утром Артём, инженер небольшой оптовой компании, получил задачу, которую можно было уместить в одну фразу: «сделай так, чтобы клиентская база больше не утекала». Повод был свежим: отдел продаж отправил прайс с контактами клиентов не тому адресату, и руководитель компании решил, что пора «поставить защиту». Через месяц система была куплена и настроена подрядчиком, и в компании появилось ощущение, что вопрос закрыт.
Ощущение продержалось неделю. Сначала перестали уходить письма с прайсами, потому что в них были телефоны. Потом заблокировалась отправка договора поставщику. Потом менеджер не смог отправить клиенту его же заказ: в письме были его телефон и адрес, а правило считало это утечкой. Отдел продаж попросил «временно отключить», руководитель разрешил, и через некоторое время система работала, но никто в компании уже не смог бы сказать, что именно она защищает.
Системы этого класса называют DLP — от английского data loss prevention, предотвращение утечек, — и от названия как раз берётся главное заблуждение. Слово «предотвращение» звучит так, будто программа сама понимает, что такое утечка, и сама её останавливает. На деле она видит только то, что ей объяснили люди, и исполняет только те решения, которые в компании успели принять. Если решений не было, система начинает угадывать.
Эта статья — про разрыв между ожиданием «DLP блокирует утечки» и реальностью. Защита держится на трёх вещах: классификации данных, продуманных правилах и разборе срабатываний. Уберите любую из них, и останется дорогая программа, которая мешает работать и почти не мешает утекать.
Что DLP видит, а что ему приходится угадывать
DLP ставят на пути данных, которые покидают компанию. Пути эти устроены по-разному, и от различий зависит, что система вообще способна заметить. Письмо — это поток: оно уходит через почтовый сервер, и там его можно прочитать, а флешка — предмет: её подключают к компьютеру, и копирование видно только на нём. Печать — создание копии, которую уже не отозвать: лист выходит из принтера и живёт своей жизнью. Облако и веб — непрерывный поток: файл уходит через браузер, и перехватить его можно на устройстве или на сетевом шлюзе. Мессенджеры стоят особняком: переписка часто зашифрована, на сети её не прочитать, поэтому контроль возможен только на устройстве в момент отправки.
Один канал закрыть легко, пять — трудно, а закрыть один и забыть про остальные бессмысленно: данные утекут туда, где не смотрят. Поэтому DLP почти всегда ставится сразу в нескольких точках — агент на компьютере, шлюз на почте, контроль веб-трафика, управление съёмными носителями, учёт печати. Каждая точка видит свой кусок, и только вместе они дают картину.
Дальше системе нужно решить, что считать чувствительным. Способов ровно три, и они сильно различаются по надёжности. Первый — сигнатура: шаблон, по которому узнают номер телефона, номер банковской карты, паспортные данные, словарь ключевых слов, отпечаток конкретного документа. Второй — метка: пометка, которую файл получил при классификации и носит с собой. Третий — контекст: кто, куда, когда и сколько отправляет. Зрелая система комбинирует все три, но начинается почти всегда с сигнатур, потому что они не требуют предварительной работы.
И вот здесь кроется главное. Сигнатура узнаёт форму, а не смысл. Номер телефона в клиентской базе и номер телефона в договоре с поставщиком выглядят одинаково, потому что это один и тот же набор цифр. Пока в компании никто не решил, какие данные считаются чувствительными, система вынуждена угадывать по внешнему виду — и ошибается в обе стороны: пропускает то, что не похоже на шаблон, и блокирует то, что похоже, но безобидно.
Почему правила без классификации стреляют по всему
Настройка в компании Артёма выглядела логично. В системе появились правила на номера телефонов, адреса электронной почты и слова «клиент», «договор», «прайс». Отдельно настроили отпечаток выгрузки клиентской базы: если файл совпадает с ней по содержимому, отправка наружу запрещена. Всё, что срабатывало, блокировалось — так казалось надёжнее.
Первые дни система работала как задумано: несколько писем действительно остановились. Но очень быстро выяснилось, что под правила попадает почти вся нормальная работа. Закупки отправляли поставщикам заявки с контактами менеджеров. Юрист согласовывал договоры, в которых были телефоны сторон. Маркетинг готовил рассылку и проверял её на себе, кадры отправляли документы кандидатов. Каждое из этих действий было законным и требовало либо исключения, либо разговора.
Исключения посыпались одно за другим. Сначала их добавляли точечно, потом по отделам: продажам разрешили внешние адреса, потому что иначе они не могли работать; закупкам — потому что у них поставщики; юристам — потому что договоры. Правил стало больше, исключений ещё больше, а система перестала блокировать что-либо значимое. Формально защита была настроена, фактически — отключена по частям, и никто не мог назвать момент, когда это произошло.
Важно. Правило, которое мешает работе, не защищает данные. Оно учит сотрудников искать обходной путь, и обычно они его находят.
Обход оказался простым и не требовал злого умысла. Менеджер, которому нужно было срочно отправить клиенту спецификацию, отправлял её с личной почты на телефоне. Другой пересылал файл себе в мессенджер и оттуда — адресату. Третий фотографировал экран: на снимке данные есть, но для системы это картинка, а не текст с шаблоном. Четвёртый брал личную флешку, потому что корпоративная копировалась медленно. Никто из них не собирался воровать базу; все хотели закрыть задачу до конца дня.
В этот момент произошло самое неприятное. Данные не перестали уходить — они начали уходить по каналам, которые система не видит или видит частично. Личная почта, мессенджер на личном телефоне, фотография экрана — всё это оставляет гораздо меньше следов, чем корпоративное письмо. Чем жёстче было правило, тем шире становилась зона, где защиты не было вовсе. Строгость без разбора не усилила контроль, а перенесла его в слепую зону.
Отсюда следует вывод, который сначала кажется неудобным. Проблема была не в том, что правила слишком строгие, а в том, что они не знали, что защищают. Номер телефона сам по себе ничего не значит: значение имеет, в каком документе он находится, кому и зачем отправляется. Чтобы это различить, компании нужен ответ на вопрос, который DLP задать не может, — какие данные у неё есть и какие из них важны.
Как у данных появляется владелец и метка
Классификация звучит как большая работа, но начинается она не с описания всех файлов на дисках, а с нескольких решений. Нужно назвать категории данных, которые компания считает чувствительными: клиентская база, договоры, закупочные цены, кадровые документы, внутренняя переписка. Для каждой категории определяется уровень — что можно показывать всем, что только внутри, что нельзя выносить наружу, — а также порядок действий, если данные всё-таки вышли.
Главное в этом процессе — не уровень, а человек, который его назначает. Владелец данных — это подразделение, которое понимает их ценность и последствия потери: продажи отвечают за клиентскую базу, закупки за условия поставщиков, кадры за документы сотрудников. Служба безопасности не может придумать эти решения за бизнес, иначе получается то, что получилось у Артёма: правила писались по догадке, а исключения выдавались под давлением. Без владельца любая классификация превращается в список запретов, который никто не защищает.
Когда владелец назван, появляется метка. Это пометка, которая ставится файлу при создании или при переносе в хранилище и дальше едет вместе с ним: категория, уровень, иногда срок хранения. Метка удобна тем, что фиксирует решение один раз, а не заставляет систему угадывать заново при каждой отправке. Правило «файл с меткой клиентской базы не уходит на внешние адреса» гораздо точнее, чем правило «в письме есть несколько номеров телефонов».
Но у меток есть слабое место, о котором стоит сказать честно. Они стареют и теряются: файл пересохранили в другой формат, скопировали в архив, отправили в мессенджер — и метка осталась в исходнике, а не в копии. Поэтому классификация не отменяет сигнатуры, а дополняет их. Метка отвечает за документы, где решение уже принято; сигнатура подстраховывает там, где метки нет или она потерялась; контекст решает, насколько подозрительна конкретная отправка.
Есть ещё один способ уменьшить ущерб, не запрещая работу. Если данные зашифрованы, а ключи лежат отдельно, потеря файла не равна потере информации: без ключа это набор байтов. Если имена и телефоны заменены на обезличенные идентификаторы, аналитик может работать с таблицей, не видя персональных данных. Это не отменяет контроль, но снижает цену ошибки: иногда проще сделать так, чтобы утекший файл ничего не значил, чем гарантировать, что он не утечёт. Но ключи и таблицы соответствия становятся новой критичной точкой, и защищать их нужно не меньше, чем исходные данные.
Почему контекст важнее запрета
Вернёмся к примеру с телефоном. Одна и та же строка с контактом клиента может быть нормальной рабочей необходимостью и нарушением — в зависимости от того, куда она уходит, сколько её и кто отправляет. Менеджер поддержки, который пересылает клиенту его собственные данные, не создаёт утечку. Тот же менеджер, выгружающий всю таблицу на личный адрес, создаёт её немедленно. Разница не в содержимом файла, а в обстоятельствах.
Поэтому зрелое правило описывается не одним условием, а сочетанием. Что именно уходит — метка или сигнатура. Куда — внутренний адрес, известный контрагент, личный домен. Сколько — одна запись, страница, вся выгрузка. Кто и когда — роль, обычное поведение сотрудника, рабочий день или ночь перед увольнением. Каждое из этих условий по отдельности слабое, но вместе они дают точность, которой не даёт ни один шаблон.
Из этого следует ещё одно изменение — отказ от тотальной блокировки. Блокировка уместна там, где действие необратимо и явно выходит за рамки: массовая выгрузка клиентской базы на внешний адрес, копирование помеченных файлов на съёмный носитель, отправка документов с ограниченным доступом за пределы компании. Предупреждение уместно там, где контекст неоднозначен: сотрудник отправляет небольшой фрагмент, адресат внешний, но похож на контрагента. В этом случае система не должна решать за человека — она должна спросить и записать ответ.
У предупреждения есть достоинство: оно оставляет след. Сотрудник подтверждает отправку и указывает основание, и этот ответ потом можно проверить при разборе. Блокировка без объяснения такого следа не оставляет — она раздражает и подталкивает к обходу. Поэтому у сообщения о блокировке должна быть понятная причина и легальный путь: «этот файл помечен как клиентская база, отправьте его через корпоративный файлообмен» работает лучше, чем «операция запрещена».
Отдельно стоит сказать про исключения, потому что именно они убивают правила. Исключение — это не «отключить для отдела навсегда», а решение с именем, сроком и причиной: кому, зачем, до какой даты, что компенсирует риск. Если исключение продлевается каждый раз без пересмотра, это уже не исключение, а дыра с документальным оформлением. Полезно раз в несколько месяцев просматривать список и закрывать пункты, чья причина исчезла.
Ложные срабатывания и люди, которые обходят правила
Даже точные правила ошибаются. Ложное срабатывание — не дефект, который можно устранить навсегда, а издержка, которой нужно управлять. Опасность здесь не в самом факте ошибки, а в её количестве: когда очередь предупреждений растёт быстрее, чем её разбирают, сотрудники перестают читать сообщения и подтверждают всё подряд. Через некоторое время настоящее срабатывание тонет в потоке привычных, и его никто не замечает.
Поэтому разбор нужно строить как процесс, а не как героический рывок. У очереди должен быть владелец и правило деления срабатываний на три вида. Первый — ошибка правила: сигнатура ловит лишнее, метка стоит не там, порог выставлен неверно, и чинится здесь правило, а не человек. Второй — нарушение политики без последствий: сотрудник отправил данные, которые не должны были уходить, но получатель внутренний или данных было мало. Здесь нужен разговор и, возможно, обучение. Третий — инцидент: данные вышли за пределы компании, и дальше работает план реагирования.
Инцидент требует ответов на конкретные вопросы, и лучше, чтобы они были заданы заранее. Что именно ушло, в каком объёме, кому, когда, успел ли получатель прочитать, можно ли удалить копию, нужно ли кого-то уведомлять. Ответы определяют масштаб, а масштаб — решение о том, что делать дальше. Не менее важен вопрос «почему правило это пропустило»: без него следующий такой случай повторится.
Теперь про сотрудников, которые обходят правила: причин обычно три, и путать их нельзя. Первая — человек не знает, что эти данные нельзя отправлять: тогда работает обучение, а не наказание. Вторая — знает, но не может иначе: нет легального способа, а задача горит. Здесь виноват процесс, а не человек, и правильное действие — сделать нормальный путь быстрее обходного. Третья — знает, может, но делает намеренно, например перед уходом из компании. Здесь нужны организационные меры вплоть до дисциплинарных, и это редкий случай по сравнению с первыми двумя.
И здесь есть соблазн превратить защиту в наблюдение за людьми: читать переписку, проверять личные устройства, следить за каждым движением. Это разрушает доверие и приводит к обратному результату — люди начинают обходить систему аккуратнее. Разумнее ограничиться корпоративными каналами, метаданными и понятным сотрудникам правилом: что именно контролируется и зачем. Открытость здесь не наивность, а условие того, что правила будут соблюдать.
Почему DLP не заменяет доступы и копии
У всего описанного есть граница. DLP контролирует поток — момент, когда данные покидают компанию. Он не решает, кто имеет право видеть данные внутри. Если клиентская база лежит на общем диске и открыта всем, система поймает только выход, а до этого файл мог прочитать любой сотрудник, и никакое правило этого не заметит.
Поэтому DLP работает в паре с управлением доступами: доступ выдаётся по необходимости, а не «на всякий случай», и забирается при смене роли или увольнении. Минимальные права уменьшают число людей, которые вообще могут столкнуться с чувствительными данными, и тем самым сокращают количество срабатываний, которые нужно разбирать. Это не отдельная задача, а та же работа с данными, только с другой стороны.
Вторая граница — резервные копии. DLP не восстанавливает данные и не спасает от шифровальщика: программа, которая шифрует файлы, не нарушает правил отправки, она действует внутри. Если завтра база окажется зашифрованной или удалённой, защита от утечек не поможет её вернуть. Журналы DLP — тоже не копия данных: по ним можно понять, что произошло, но не восстановить содержимое.
И третья граница — сам процесс. DLP не исправляет привычку хранить всё в почте, не отменяет общие папки и не заставляет людей думать о данных. Он лишь делает видимой ту границу, которую компания уже провела. Если границы нет, система будет рисовать её наугад — и получит ровно то, с чего мы начали: поток предупреждений, которые никто не читает, и сотрудников, которые отправляют базу с личной почты.
Через несколько месяцев в компании Артёма система выглядела иначе. Правил стало меньше: остались те, что опирались на метки и контекст, а не на номера телефонов. Категорий было несколько, и у каждой появился владелец из бизнеса, который решал, что можно выносить наружу. Массовая выгрузка клиентской базы по-прежнему блокировалась, а отправка одного заказа клиенту проходила с предупреждением и подтверждением. Появился корпоративный файлообмен для больших файлов, и обходной путь через личную почту стал медленнее легального.
Разбор срабатываний превратился в короткую еженедельную встречу, на которую приходил представитель продаж. Это оказалось важнее любой тонкой настройки: именно продажи объясняли, какие предупреждения бессмысленны, а какие указывают на реальную проблему. Число исключений сократилось не потому, что людям запретили, а потому, что им стало проще работать по правилам.
Утечек после этого не стало ноль, и было бы нечестно обещать обратное. Изменилось другое: компания перестала узнавать об утечках от контрагентов и начала видеть их сама — с объёмом, адресатом и понятным следующим шагом. DLP в этой схеме оказался не стеной, а мембраной: он пропускает рабочее и задерживает то, что выходит за рамки, но только если кто-то заранее решил, где эта рамка проходит.
Главная мысль статьи в этом и состоит. DLP не защищает данные — он исполняет решения о данных, которые компания приняла до него. Классификация отвечает на вопрос «что мы защищаем», владелец данных — «кто это решает», контекстные правила — «где проходит граница», разбор срабатываний — «что делать, когда граница нарушена». Без этих ответов система остаётся дорогим способом мешать работе и учить людей обходить защиту. С ними она становится тем, чем и должна быть: инструментом, который видит поток и помогает удерживать его в рамках.
Разобраться в обязанностях компании при утечке поможет разбор 152-ФЗ простыми словами. Отдельная история — утечка через подрядчика: там видно, почему защита внутри компании не закрывает риск, который приходит с чужой стороны. Незнакомые термины, включая классификацию, метки и ложные срабатывания, собраны в словаре.