DLP в организации: старт с классификации и пилота без ссор

С чего начинается конфликт вокруг DLP и как его избежать

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

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

Чтобы этого не было, заранее договоритесь о правилах запуска. На старте достаточно:

• Начать с режима наблюдения (без блокировок) и показать реальную картину: какие каналы и типы данных утекают чаще.
• Согласовать 2-3 категории данных, которые действительно критичны прямо сейчас (например, персональные данные клиентов, коммерческие условия, доступы).
• Определить, что считать «ошибкой»: не факт инцидента, а спорную блокировку, которая мешает работе.
• Сделать понятный путь исключений: кому писать, за сколько часов отвечают, кто утверждает.
• Назначить владельца процесса со стороны бизнеса, чтобы решения не зависали.

Успех на старте лучше мерить не «нулем инцидентов», а снижением спорных блокировок и ростом точности. Если за первые 4-8 недель вы получите карту основных рисков, список типовых утечек и 1-2 правила, которые реально соблюдаются без скандалов, это уже хороший результат.

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

Определяем цель: какие данные и какие утечки важнее всего

Чтобы DLP не превратился в вечный спор, начните не с настроек, а с простого вопроса: что для бизнеса будет больнее всего, если это утечет. Цель формулируйте через риск (штрафы, остановка проекта, потеря клиента), а не через абстрактное «защитим все».

На старте обычно достаточно выбрать 2-3 типа данных, которые реально описать и распознать. Часто это персональные данные (анкеты, списки сотрудников и клиентов, медданные), финансы (платежки, счета, бюджеты, отчеты), коммерческая тайна (цены, договоры, условия закупок) или документы проектов (ТЗ, чертежи, переписка с подрядчиками).

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

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

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

Роли и договоренности: кто принимает решения по правилам

Чтобы запуск не превратился в спор «ИБ против бизнеса», с первого дня договоритесь не о технологиях, а о праве голоса. Политики работают только там, где понятно, кто их предлагает, кто подтверждает, кто отвечает за последствия и кто объясняет людям, что меняется.

Минимальный набор участников обычно включает ИБ (риски и предложения по контролю), юристов (законность, персональные данные, договорные ограничения), HR (коммуникации и дисциплинарная часть при необходимости), ИТ (влияние на почту, устройства, поддержку) и владельца процесса в подразделении (как работа устроена на самом деле).

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

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

• ИБ описывает правило: что ограничиваем, где, почему и кого это затронет.
• Владелец процесса подтверждает, что работа не остановится, или предлагает исключения.
• Юристы и ИТ дают финальное «можно», после чего назначается дата включения.

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

Стартовая модель классификации данных, которую реально поддерживать

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

4 уровня, которых обычно хватает на старт

Обычно достаточно 3-4 уровней:

• Публичные: то, что можно публиковать без риска (пресс-релизы, открытые вакансии).
• Внутренние: рабочие материалы без чувствительных данных (регламенты, общие инструкции).
• Конфиденциальные: коммерческие условия, договоры, проекты, техническая документация.
• Строго конфиденциальные: персональные данные, финансовые реестры, данные по ключевым тендерам и госзакупкам.

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

Маркировка без перегруза

Маркировка должна занимать секунды. Рабочие варианты: шаблоны документов с уже выбранным классом, короткие теги в имени (например, [CONF]), типы документов в хранилище, авто-метки по ключевым полям (есть ИИН - класс повышается). Если маркировка требует отдельного обучения на час, ее быстро перестанут делать.

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

• Разрешить: для публичных и части внутренних.
• Предупредить: когда «внутренний» файл уходит наружу.
• Потребовать согласование: для конфиденциальных при отправке внешнему адресату.
• Заблокировать: для строго конфиденциальных в неразрешенные каналы (личная почта, мессенджеры, внешние диски).

Так модель становится поддерживаемой руками бизнеса, а не только силами ИБ.

Как выбрать подразделение для пилота без риска для компании

Пилот лучше начинать не там, где больше всего «страшных» данных, а там, где процессы понятны и результат можно быстро посчитать. Хорошо подходит команда, которая уже работает по правилам (пусть и неформальным) и готова обсуждать, что мешает.

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

Часто подходят продажи (коммерческие предложения, базы клиентов), бухгалтерия (платежки, счета, акты), HR (кадровые документы, резюме), закупки (договоры, тендерные материалы). Сценарии утечек там типовые и легко проверяемые.

Чтобы пилот был управляемым, ограничьте рамки:

• Каналы: начните с почты и съемных носителей, остальное добавите позже.
• Типы данных: 2-3 категории (например, персональные данные и договоры).
• Пользователи: одна команда или 10-30 сотрудников, не весь департамент.
• Срок: 4-6 недель, с понятными контрольными точками.

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

Пошаговый план пилота: от наблюдения до первых ограничений

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

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

Дальше соберите примеры для тестов. Попросите сотрудников дать 10-20 реальных файлов и пару типовых переписок (можно обезличить). Так вы проверите, что правила ловят нужное, а не все подряд.

От наблюдения к первым действиям

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

Затем выберите 1-2 сценария для точечных ограничений. Например, запрет отправки файлов с ИИН за пределы домена или блокировка копирования отчетов на съемные носители. Держите простую логику: одно ограничение - один понятный риск - один рабочий обходной путь (например, безопасный канал передачи).

Итог пилота

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

Правила, которые соблюдаются: как писать политики просто

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

Рабочий формат - «если - то». Одно правило отвечает на один вопрос: что считаем риском и что делаем.

• Если документ помечен как «Конфиденциально», то отправка наружу допускается только через согласованный канал.
• Если в письме есть ИИН или паспортные данные, то система сначала предупреждает пользователя.
• Если файл с базой клиентов попадает в мессенджер или облако, то действие блокируется.

Чтобы не блокировать всех подряд, задайте пороги. Они помогают отделить случайную ошибку от попытки унести данные. Например: предупреждать при 1-2 совпадениях по шаблону, блокировать при большом объеме, массовой рассылке или при одновременном совпадении нескольких признаков (тип данных + внешний адрес + вложение).

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

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

Коммуникации с людьми: уведомления, обучение, обратная связь

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

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

• Что: «Файл с персональными данными нельзя отправлять во внешнюю почту».
• Почему: «Это снижает риск утечки и штрафов».
• Что делать: «Используйте корпоративный обмен или запросите согласование».
• Контакт: «Если ошибка - напишите в поддержку ИБ».

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

Обратная связь должна быть простой: один адрес или чат, понятный владелец и срок ответа. Например: первая реакция за 4 рабочих часа, решение или план действий - до 2 рабочих дней. Если нужна эскалация, заранее назовите, кто подключается (ИБ, юристы, владелец процесса).

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

Метрики и контроль качества: что измерять на пилоте

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

Бизнесовые метрики: цена правил для процессов

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

• Время типовых операций: отправка счета, выгрузка отчета, обмен с подрядчиком.
• Число остановленных операций: сколько раз сотрудник не смог завершить действие из-за правила.
• Доля ложных срабатываний: сколько алертов оказалось «нормальной работой».
• Время разбора: от события до решения (разрешить, запретить, изменить правило).
• Количество обращений в поддержку: вопросы, жалобы, просьбы «снять блокировку».

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

ИБ-метрики: что реально защищаем

Со стороны ИБ важны не «все события», а фокус на критических классах данных и повторяемых сценариях. Смотрите количество событий по важным классам (персональные данные, финансы, коммерческие условия), повторяемость (тот же пользователь, документ, шаблон) и каналы (почта, мессенджеры, веб, съемные носители, печать).

Отдельно ведите журнал решений по правилам: дата, что изменили, почему, кто согласовал, какой эффект ожидали. Без этого через месяц никто не вспомнит, почему «так настроено», и пилот снова превратится в спор.

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

Частые ошибки при запуске DLP и как их обойти

Главная проблема на старте - слишком сложные правила. Часто пытаются сразу описать все типы данных, все каналы и все исключения. В итоге никто не понимает, что можно, а что нельзя, и политики начинают «лечить» бесконечными правками. Лучше начать с 3-4 понятных категорий (публичные, внутренние, конфиденциальные, строго конфиденциальные) и пары признаков. Остальное добавляйте только после того, как увидели реальные события.

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

Часто запуск тормозит организационно: нет владельца процесса, и согласования тянутся неделями. Назначьте одного ответственного (не «комитет»), который собирает требования, принимает спорные решения и фиксирует договоренности.

Еще одна ловушка - закрыть глаза на каналы, которые для конкретного отдела критичны. Если бухгалтерия печатает отчеты, а закупки носят документы на съемных носителях для подрядчиков, эти пути нельзя оставлять «на потом».

Что обычно помогает:

• Начать с наблюдения и короткого списка самых дорогих рисков для бизнеса.
• Делать правила короткими и проверяемыми, с минимумом исключений.
• Перед блокировками обеспечить безопасную альтернативу (защищенная папка, утвержденный способ обмена).
• Вместо угроз наказаний дать понятные подсказки: что делать вместо запрета.
• Раз в неделю разбирать 5-10 кейсов и корректировать правила по фактам.

Пример: в пилоте в финдепартаменте правило «запретить отправку Excel наружу» ломает работу. Гораздо лучше ограничить только файлы с признаками бюджета (ключевые слова, шаблон), а для остального дать понятный маршрут согласования или разрешенный канал передачи.

Пример сценария: один инцидент от начала до решения

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

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

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

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

ИБ фиксирует событие: кто отправлял, какой тип данных обнаружен, куда, каким способом и что выбрал сотрудник (обезличивание или согласование). По итогам кейса правило корректируют: например, разрешают передачу обезличенных списков в определенный домен подрядчика, но только при наличии маркера «для пропуска/доступа». Полные наборы данных переводят в режим блокировки после нескольких недель пилота.

Короткий чек-лист и следующие шаги после пилота

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

Перед стартом следующего этапа проверьте, что готов минимум:

• Согласованный список 10-20 типов данных, которые вы реально защищаете (например: договоры, персональные данные, финансовые отчеты), и простые метки классификации.
• Роли и ответственность: кто владелец данных, кто утверждает правила, кто разбирает события и в какие сроки.
• Набор тестовых примеров: 5-10 типовых файлов и сценариев (отправка на личную почту, загрузка в облако, копирование на флешку), чтобы проверять настройки.
• Канал обратной связи для сотрудников и шаблон объяснения: что произошло и что можно сделать вместо запретного действия.
• Регламент исключений: кто и как выдает временное разрешение, чтобы не тормозить работу.

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

Дальше соберите план масштабирования на 2-3 подразделения. Обычно логично идти туда, где данные похожи на пилотные, но объем больше: например, сначала бухгалтерия и закупки, затем HR или клиентский сервис. На каждое подразделение держите короткий пакет: 3-5 правил, 1 владелец данных, 2-3 метрики (события, ложные срабатывания, время разбора).

Отдельно продумайте инфраструктуру и поддержку: где будет работать DLP (серверы, хранилища, резервирование), какие рабочие места требуют обновления, кто обеспечивает круглосуточную реакцию. Если нужна помощь на этом этапе, ее часто закрывает системный интегратор - например, GSE.kz (gse.kz) поставляет рабочие станции и серверы и оказывает услуги интеграции и поддержки 24/7 через сервисную сеть по Казахстану.