Передача логов на ZSO/HSM

Передача логов на аппаратные или программные средства защиты информации становится правовым вопросом в тот момент, когда в лог-потоке оказываются персональные данные. Именно здесь пересекаются требования ФЗ-152, Приказа ФСТЭК №21, ПП РФ №1119 и уголовные риски по ст. 272.1 УК. В этом материале — структурированный анализ для CISO: какие нормы применимы, как правильно оформить передачу, что требуется технически и как снизить риск протокола РКН.

Что такое логирование как ПДн и когда оно регулируется 152-ФЗ?

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

Следовательно, обработка таких логов — сбор, хранение, передача, анализ — подпадает под режим 152-ФЗ. Передача лог-потока с ПДн на ZSO (средство защиты от несанкционированного доступа) или HSM (Hardware Security Module) является «передачей» в понимании ст. 3, а если получатель — сторонняя организация или внешний сервис, то это ещё и «поручение обработки» по п. 3 ст. 6 ФЗ-152.

На практике это означает: если логи с ПДн агрегируются в SIEM-системе стороннего провайдера, передаются в облачный HSM или реплицируются на узел ZSO в другом юридическом лице — необходим оформленный договор-поручение с перечнем действий, целями и мерами защиты. Без него — нарушение ч. 1 ст. 13.11 КоАП в редакции с 30.05.2025, штраф 150 000–300 000 ₽ для юридического лица.

Какой уровень защищённости (УЗ) нужен для систем с логами?

ПП РФ №1119 от 01.11.2012 устанавливает четыре уровня защищённости информационных систем персональных данных (ИСПДн). Уровень зависит от трёх факторов: категория ПДн, тип угроз и число субъектов. Лог-система, аккумулирующая действия пользователей, — это ИСПДн, если в логах есть хотя бы один из идентификаторов.

Для большинства корпоративных SaaS и IT-платформ актуальны УЗ-3 или УЗ-4. Порог в 100 000 субъектов критичен: при его превышении минимальный уровень смещается вверх. Ниже — ключевые сценарии для CISO:

• УЗ-4 — общие ПДн, угрозы 3 типа, до 100 000 субъектов. Типовой для корпоративных логов малого и среднего бизнеса.
• УЗ-3 — общие ПДн, угрозы 2 типа, или свыше 100 000 субъектов при угрозах 3 типа. Характерен для облачных платформ с большой пользовательской базой.
• УЗ-2 — специальные или биометрические категории ПДн при угрозах 2 типа. Актуален для медицинских IT-систем, систем контроля доступа с биометрией.
• УЗ-1 — высший уровень, специальные/биометрические ПДн при угрозах 1 типа. Для большинства коммерческих систем — редкость.

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

Как правильно оформить передачу логов на внешние ZSO и HSM?

Оформление передачи зависит от правового статуса получателя лог-потока. Возможны три ситуации.

Ситуация 1 — внутреннее подразделение одного юридического лица. Если ZSO или HSM эксплуатируются силами ИТ-службы того же юридического лица, поручение не требуется — это единый оператор. Необходимы внутренние ОРД: приказ об организации обработки, регламент логирования, описание ИСПДн в уведомлении РКН по ст. 22 ФЗ-152.

Ситуация 2 — сторонний MSSP или облачный провайдер. Здесь обязателен договор-поручение по п. 3 ст. 6 ФЗ-152. Договор должен содержать перечень передаваемых данных, цели обработки (мониторинг безопасности), меры защиты и запрет на использование в иных целях. Если провайдер — иностранная компания или размещает данные за рубежом, дополнительно требуется уведомление РКН о трансграничной передаче по ст. 12 ФЗ-152.

Ситуация 3 — аффилированная структура группы компаний. Юридически это всё равно разные операторы. Договор-поручение обязателен. Нередко группы компаний упускают этот момент — и именно здесь РКН фиксирует нарушения при плановых проверках.

Как передача логов взаимодействует с требованиями КИИ по 187-ФЗ?

Для субъектов критической информационной инфраструктуры (КИИ) по ФЗ-187 логирование приобретает дополнительный регуляторный слой. Значимые объекты КИИ обязаны передавать данные об инцидентах в ГосСОПКА. Если лог-система одновременно обрабатывает ПДн и является частью значимого объекта КИИ — применяются оба режима: 152-ФЗ и 187-ФЗ.

На практике это означает необходимость разграничения потоков: лог-данные для ГосСОПКА не должны содержать избыточных ПДн, которые не нужны для целей мониторинга инцидентов. Принцип минимизации по ст. 5 ФЗ-152 требует, чтобы состав передаваемых логов соответствовал заявленной цели.

Пересечение КИИ и 152-ФЗ создаёт риск одновременных проверок двух регуляторов — ФСТЭК (по 187-ФЗ) и РКН (по 152-ФЗ). При этом акт классификации объектов КИИ и акт классификации ИСПДн — это разные документы с разными требованиями к содержанию.

Что такое обезличивание логов для ML и как оно снижает правовую нагрузку?

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

С 2025 года действует регулирование обезличенных ПДн по ст. 13.1 ФЗ-152 (введена ФЗ-233). Приказ РКН, принятый в развитие этой нормы, закрепляет пять методов обезличивания: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация.

Для ML-пайплайнов, обучаемых на лог-данных, обезличивание — основной инструмент снижения регуляторной нагрузки. Однако важно понимать: обезличивание должно быть необратимым по методологии. Псевдонимизация (замена имени на идентификатор, который хранится отдельно) — это не обезличивание по ФЗ-152; обработка псевдонимизированных данных по-прежнему регулируется как обработка ПДн.

Для CISO это означает: перед передачей лог-потока на внешний ML-кластер или облачную платформу анализа необходимо применить один из пяти методов из приказа РКН и зафиксировать применённый метод в регламенте. Только тогда передача выйдет из-под режима поручения обработки.

Типичные сценарии и их правовая квалификация

Сценарий 1 — SaaS-платформа передаёт логи авторизации в облачный SIEM стороннего провайдера. Логи содержат email, IP, временные метки. Провайдер SIEM — иностранная компания с инфраструктурой в ЕС. Ситуация: нарушение ч. 5 ст. 18 ФЗ-152 (первичная обработка ПДн граждан РФ должна вестись в базах на территории РФ), нарушение ст. 12 (трансграничная передача без уведомления РКН). Вероятный исход при проверке — протоколы по ч. 1 ст. 13.11 и ч. 8 ст. 13.11 (1–6 млн ₽ за нарушение локализации). Стратегия: перевести хранение первичных логов в российский облачный сегмент, оформить договор-поручение с российским MSSP, при необходимости — уведомить РКН о трансграничной передаче агрегированных данных.

Сценарий 2 — корпоративный HSM эксплуатируется ИТ-аутсорсером в рамках группы компаний. Договор на ИТ-обслуживание подписан, но отдельного соглашения-поручения об обработке ПДн нет. В логах — действия HR-системы с персональными данными работников. Ситуация: отсутствие поручения по п. 3 ст. 6 ФЗ-152 — нарушение ч. 1 ст. 13.11. Доказательная база РКН: лог-трафик между юридическими лицами без НПА-основания. Вероятный исход: штраф 150 000–300 000 ₽, предписание об устранении. Стратегия: включить в договор ИТ-аутсорсинга отдельный раздел или приложение-поручение с перечнем ПДн и мерами защиты.

Сценарий 3 — CISO обнаружил, что ML-модель обучалась на необезличенных логах пользователей без согласия субъектов. Ситуация: нарушение ч. 1 ст. 13.11 (обработка несовместимая с первоначальными целями), потенциально — ч. 2 (если использовались специальные категории ПДн). С 11.12.2024 действует ст. 272.1 УК РФ: незаконное использование компьютерной информации с ПДн — до 4 лет лишения свободы по базовому составу. Стратегия: остановить использование необезличенных данных, применить методы обезличивания из приказа РКН, зафиксировать в документах, уведомить DPO.

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

Кейс 1. IT-компания из Сибирского федерального округа (осень 2025) передавала логи аутентификации корпоративного портала на SIEM-платформу европейского провайдера. В логах фиксировались email, геолокация и поведенческие данные около 45 000 пользователей. При внеплановой проверке РКН выявил отсутствие договора-поручения и нарушение требований локализации. Был составлен протокол по ч. 1 и ч. 8 ст. 13.11 КоАП. В арбитражном суде региона компании удалось снизить совокупный штраф: по ч. 1 применена ст. 4.1.1 КоАП (замена на предупреждение при первичности), по ч. 8 — назначен штраф в нижней части диапазона с учётом принятых мер устранения. Общий исход — несколько сотен тысяч рублей вместо потенциальных 1–6 млн ₽. Ключевой фактор смягчения: CISO оперативно перевёл хранение в российский облачный сегмент до вынесения постановления.

Кейс 2. Финтех-платформа (Центральный федеральный округ, начало 2026) использовала необезличенные транзакционные логи для обучения модели скоринга. Данные содержали ФИО, даты операций и суммы — ПДн около 120 000 субъектов. DPIA не проводилась, поручение на передачу данных ML-команде не оформлялось. После жалобы субъекта РКН возбудил дело по ч. 1 ст. 13.11. Компания привлекла юристов на этапе составления протокола: была подготовлена доказательная база применения обезличивания (метод введения идентификаторов по приказу РКН) и подписан ретроактивный регламент ML-обработки. Штраф снижен до нижней границы диапазона. DPIA по итогу зафиксировала остаточные риски и закрыла вопрос для будущих проверок.

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

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

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

1. Какой УЗ выбрать для SaaS-платформы с лог-системой?

Уровень защищённости определяется по ПП РФ №1119 исходя из трёх параметров: категория ПДн в логах (общие, специальные или биометрические), тип актуальных угроз (1, 2 или 3 — по модели угроз ФСТЭК) и число субъектов. Для большинства SaaS-платформ с общими ПДн и угрозами 3 типа актуален УЗ-4; при числе субъектов свыше 100 000 или угрозах 2 типа — УЗ-3. Модель угроз должна быть оформлена документально до начала обработки.

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

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

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

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

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

В мультиарендной SaaS ответ зависит от того, кто определяет цели и состав обработки. Если клиент (тенант) загружает ПДн своих пользователей — он оператор, SaaS-провайдер — обработчик по п. 3 ст. 6 ФЗ-152. Если SaaS-провайдер самостоятельно определяет, какие данные собирать и зачем (например, поведенческая аналитика для своих целей) — он оператор в отношении этих данных. В логах нередко смешиваются оба потока: это требует чёткого разграничения в договоре и в ОРД.

5. Какие технические средства защиты (СЗИ) обязательны при передаче логов?

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

Итог

Передача логов на ZSO и HSM — это обработка ПДн, если лог-поток содержит идентифицирующую информацию. Правовой режим определяется статусом получателя (поручение или нет), уровнем защищённости ИСПДн по ПП РФ №1119 и территориальным расположением инфраструктуры. Игнорирование этих требований создаёт риски по ч. 1, ч. 8 ст. 13.11 КоАП (до 6 млн ₽) и по ст. 272.1 УК для должностных лиц.

Практика DATUM по технической стороне 152-ФЗ включает аудит лог-архитектур, подготовку моделей угроз, оформление договоров-поручений и DPIA для ML-систем. Работаем с IT-компаниями, SaaS-провайдерами и субъектами КИИ.