Логи DLP-системы

DLP-системы перехватывают файлы, письма, сообщения в мессенджерах и запросы к базам данных. Всё это — персональные данные работников и, косвенно, клиентов. С 2024–2025 годов регулирование ужесточилось по трём направлениям одновременно: расширена ст. 13.11 КоАП (ФЗ-420 от 30.11.2024), введена уголовная ответственность по ст. 272.1 УК (ФЗ-421 от 30.11.2024) и ужесточены требования к локализации (ФЗ-233). Эта статья объясняет, как логи DLP-системы квалифицируются по ФЗ-152, какой уровень защищённости применять, когда нужно поручение на обработку и как обезличивать данные перед передачей в ML-модели.

Почему логи DLP считаются персональными данными?

DLP-система перехватывает и сохраняет содержание переписки, список посещённых ресурсов, копии файлов и метаданные действий конкретного пользователя. По ст. 3 ФЗ-152 персональные данные — любая информация, прямо или косвенно относящаяся к определённому физическому лицу. Логи с именем учётной записи, IP-адресом рабочей станции или идентификатором сотрудника соответствуют этому критерию напрямую.

Важен и состав перехватываемых данных. Если DLP фиксирует медицинские термины в переписке, сведения о профсоюзной деятельности или личную переписку — возникает обработка специальных категорий ПДн по ст. 10 ФЗ-152. Такая обработка допускается только в строго ограниченных случаях, включая письменное согласие субъекта.

Логирование как таковое является обработкой ПДн: систематизацией, накоплением и хранением. Это означает, что оператор обязан соблюдать все принципы ст. 5 ФЗ-152: определить конкретную цель, не хранить дольше необходимого, обеспечить соответствие объёма данных заявленной цели.

Какой уровень защищённости выбрать для DLP-инфраструктуры?

ПП РФ №1119 от 01.11.2012 устанавливает четыре уровня защищённости (УЗ-1..УЗ-4) в зависимости от трёх параметров: категории обрабатываемых ПДн, типа угроз (угрозы 1, 2 или 3 типа) и числа субъектов. Для DLP-систем корпоративного уровня отправная точка — как минимум УЗ-3.

На практике DLP-система крупной организации почти всегда обрабатывает данные более 100 000 субъектов (все сотрудники + контрагенты в переписке), что при угрозах 2 типа автоматически требует УЗ-3. Если перехватываются специальные категории ПДн — состояние здоровья, религиозные взгляды и т. п. — применяется УЗ-2 или УЗ-1 в зависимости от типа угроз.

Приказ ФСТЭК №21 от 18.02.2013 конкретизирует обязательный набор мер для каждого УЗ. Для УЗ-3 базовый набор включает идентификацию и аутентификацию (ИАФ), управление доступом (УПД), регистрацию событий (РСБ), антивирусную защиту (АВЗ), обнаружение вторжений (СОВ) и защиту среды виртуализации (ЗСВ) — 15 групп мер с детализацией до подпунктов. Каждый пропущенный пункт фиксируется при проверке ФСТЭК или РКН как самостоятельное нарушение.

Поручение на обработку: когда DLP-вендор становится обработчиком?

Если DLP-система развёрнута в инфраструктуре вендора (SaaS-модель) или техническую поддержку осуществляет внешняя компания с доступом к логам, такой вендор является лицом, осуществляющим обработку по поручению оператора, по ст. 6 ч. 3 ФЗ-152. Без письменного договора-поручения оператор нарушает требования ст. 6, что квалифицируется по ч. 1 ст. 13.11 КоАП.

Мультиарендная SaaS создаёт дополнительную сложность. Если один и тот же экземпляр DLP-платформы обслуживает нескольких клиентов-операторов, каждый из них должен иметь отдельное поручение с вендором. Важно проверить, что данные клиентов физически или логически изолированы: отсутствие изоляции в мультиарендной среде — нарушение принципа соответствия объёма целям по ст. 5 ФЗ-152.

Для SaaS-DLP с размещением в облаке за рубежом возникает трансграничная передача ПДн по ст. 12 ФЗ-152. До передачи в страну, не входящую в перечень стран с адекватной защитой, оператор обязан уведомить РКН. Требование локализации по ч. 5 ст. 18 ФЗ-152 распространяется на первичный сбор, систематизацию и хранение ПДн граждан РФ — облако с DLP-логами должно находиться в Российской Федерации.

Как обезличивать логи DLP для ML-моделей?

Обезличивание DLP-логов перед передачей в системы машинного обучения — не выбор, а требование. Необезличенные ПДн в ML-датасете означают обработку ПДн с новой целью, несовместимой с исходной (мониторинг безопасности), что нарушает принцип целевой обработки по ст. 5 ФЗ-152. С 2025 года обезличивание регулируется Приказом РКН, устанавливающим пять методов.

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

Важно разграничивать псевдонимизацию и обезличивание. Псевдонимизация — замена идентификаторов на псевдонимы при сохранении ключа соответствия — не является обезличиванием по ФЗ-152, поскольку субъект остаётся косвенно идентифицируемым. Передача псевдонимизированных логов вендору ML-аналитики без поручения на обработку — самостоятельное нарушение.

Практические сценарии: что происходит при проверке

Ниже — три типичные ситуации, возникающие при внеплановых проверках РКН IT-компаний и крупных корпоративных операторов с DLP-инфраструктурой.

Сценарий 1. DLP в SaaS без поручения. Компания использует облачную DLP-платформу иностранного вендора. Поручение на обработку не оформлено, уведомление РКН не содержит DLP-системы в перечне ИСПДн. РКН фиксирует два нарушения: отсутствие поручения (ч. 1 ст. 13.11, 150–300 тыс. ₽) и неполноту уведомления (ч. 10 ст. 13.11, 100–300 тыс. ₽). Данные хранятся за рубежом — третье нарушение по ч. 8 ст. 13.11 (1–6 млн ₽). Итого: три протокола одновременно. Стратегия: немедленно перевести хранение в российскую инфраструктуру, оформить поручение задним числом невозможно — нужно новое, подать актуализированное уведомление в РКН и просить объединения дел.

Сценарий 2. Утечка логов через уязвимость в DLP-агенте. DLP-агент на рабочих станциях содержал уязвимость, эксплуатированную злоумышленником. Утекло более 50 000 записей переписки сотрудников — специальные категории ПДн (упоминания о здоровье). CISO обнаружил инцидент через 6 часов, уведомил РКН в течение 20 часов. Применяется ч. 13 ст. 13.11 КоАП (10 000–100 000 субъектов, 5–10 млн ₽) и ч. 16 за специальные категории. Оперативность уведомления — смягчающее обстоятельство. Стратегия: задокументировать время обнаружения, полноту 72-часового отчёта по Приказу РКН №187 и принятые меры защиты для применения ст. 4.1 КоАП.

Сценарий 3. DLP-логи в ML без обезличивания. Команда Data Science использует выгрузки из DLP-системы для обучения модели детектирования инсайдерских угроз. Выгрузки содержат имена пользователей и контент переписки. Правовое основание для обработки с новой целью (обучение ML) отсутствует. При аудите — нарушение ст. 5 (несовместимость целей) по ч. 1 ст. 13.11. Если модель развёрнута у вендора за рубежом — трансграничная передача без уведомления РКН (ч. 10 ст. 13.11). Стратегия: ввести процедуру обезличивания на входе конвейера обучения, оформить отдельное основание обработки, уведомить РКН о новой цели.

Как это применяется на практике

Кейс 1. IT-компания Сибирского ФО (осень 2025) подверглась внеплановой проверке РКН после жалобы уволенного сотрудника. DLP-система хранила логи переписки за три года без ограничения срока в локальных актах. РКН зафиксировал нарушение принципа ограничения хранения по ст. 5 ФЗ-152 и отсутствие поручения с вендором поддержки. Компания получила предписание об устранении и штраф в диапазоне сотен тысяч рублей по ч. 1 ст. 13.11 КоАП. После аудита DATUM были определены сроки хранения логов по категориям (оперативные — 90 дней, инцидентные — 3 года) и оформлено поручение с вендором. ⚠️ Конкретный номер дела и точная сумма — менеджер уточняет при публикации.

Кейс 2. Финансовая организация Центрального ФО (начало 2026) использовала мультиарендную SaaS-DLP. При переходе на новый контракт вендор мигрировал данные через промежуточный европейский дата-центр без уведомления клиента. РКН квалифицировал это как трансграничную передачу без уведомления по ч. 10 ст. 13.11 КоАП (100–300 тыс. ₽). Оператор доказал отсутствие умысла и оперативно устранил нарушение; суд снизил штраф до минимума. Ключевым документом стало поручение на обработку с запретом трансграничной передачи без согласования — именно его отсутствие в исходном договоре создало риск. ⚠️ Номер дела и точная сумма — менеджер уточняет при публикации.

Услуги DATUM по теме

• Аудит соответствия 152-ФЗ — проверка DLP-инфраструктуры по 38 пунктам, включая УЗ, поручение и обезличивание
• DPIA (оценка воздействия) — обязательна перед запуском ML на DLP-данных и при высокорисковой обработке
• Комплект ОРД под ключ — политика, регламент логирования, поручение вендору, приказы о назначении ответственного

Частые вопросы

1. Какой УЗ выбрать для SaaS-DLP?

Минимальный порог для корпоративной DLP с базой более 100 000 субъектов и угрозами 2 типа — УЗ-3 по ПП РФ №1119. Если система перехватывает специальные категории ПДн (здоровье, убеждения) — требуется УЗ-2 или УЗ-1 в зависимости от типа угроз. Определение УЗ оформляется отдельным приказом руководителя с приложением модели угроз. Без документального определения УЗ любой проверяющий вправе квалифицировать ситуацию как нарушение ст. 19 ФЗ-152.

2. Можно ли использовать иностранные облака для хранения DLP-логов?

Нет, если логи содержат ПДн граждан РФ. Ч. 5 ст. 18 ФЗ-152 обязывает хранить ПДн граждан РФ в базах, расположенных на территории России. DLP-логи с именами пользователей, идентификаторами и контентом подпадают под это требование. Хранение в иностранном облаке — нарушение по ч. 8 ст. 13.11 КоАП (штраф 1–6 млн ₽). Обезличенные данные, прошедшие верификацию по методам Приказа РКН, под это ограничение не подпадают.

3. Что такое обезличивание для ML и чем оно отличается от псевдонимизации?

Обезличивание по ФЗ-152 — необратимое преобразование, после которого данные не позволяют идентифицировать субъекта без привлечения дополнительной информации, хранящейся отдельно. Для ML-конвейеров применяют методы Приказа РКН: введение идентификаторов, обобщение, изменение состава. Псевдонимизация — замена идентификаторов при сохранении ключа — обезличиванием не является: данные по-прежнему косвенно идентифицируют субъекта и требуют всего комплекса мер защиты по ст. 19 ФЗ-152.

4. Кто является оператором в мультиарендной SaaS?

Оператором остаётся компания-клиент, которая определяет цели и состав обрабатываемых ПДн. Вендор SaaS — лицо, осуществляющее обработку по поручению, по ст. 6 ч. 3 ФЗ-152. Это означает, что клиент несёт ответственность за соблюдение ФЗ-152 в полном объёме, включая уровень защищённости, локализацию и трансграничную передачу. Принцип «ВС РФ: оператор отвечает за утечку через подрядчика» действует независимо от условий договора с вендором.

5. Какие СЗИ обязательны при обработке ПДн через DLP?

Обязательный состав зависит от присвоенного УЗ и определяется Приказом ФСТЭК №21. Для УЗ-3 базовый набор включает средства идентификации и аутентификации (ИАФ), управление доступом (УПД), регистрацию событий (РСБ), антивирусную защиту (АВЗ) и обнаружение вторжений (СОВ). Средства должны быть сертифицированы по требованиям ФСТЭК или иметь аттестат соответствия. Применение несертифицированных СЗИ при УЗ-1 и УЗ-2 — самостоятельное нарушение, фиксируемое при аттестации ИСПДн.

Итог

Логи DLP-системы — это персональные данные, требующие правового основания для сбора, определения уровня защищённости по ПП РФ №1119, оформления поручения с вендором и политики обезличивания перед передачей в ML. Каждый из этих элементов — самостоятельный состав нарушения при его отсутствии. С 30.05.2025 цена ошибки кратно выросла: ч. 12–15 ст. 13.11 КоАП предусматривают штрафы от 3 до 500 млн ₽.

DATUM сопровождает IT-компании и корпоративных операторов в выстраивании правовой архитектуры DLP: от определения УЗ и разработки модели угроз до оформления поручений с вендорами и подготовки к проверкам РКН.