Передача логов в SOC

Передача логов в SOC — операция, которая воспринимается как сугубо техническая: настроил syslog-пересылку, подписал NDA с провайдером SOC и забыл. Между тем в 2025 году Роскомнадзор закрепил позицию: сетевые идентификаторы, связанные с конкретным лицом, подпадают под определение персональных данных (ст. 3 ФЗ-152). Это означает, что каждая запись в потоке событий — потенциально ПДн, а сам SOC-провайдер становится лицом, осуществляющим обработку по поручению. Материал разбирает правовую конструкцию такой передачи, требования к уровням защищённости по ПП РФ №1119, обязательства по Приказу ФСТЭК №21 и способы снизить риск через обезличивание для ML-аналитики.

Почему логи — это персональные данные и кто за это отвечает?

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

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

Следствие второе: за действия SOC-провайдера перед субъектами ПДн отвечает оператор — компания, которая направила логи. Верховный суд последовательно подтверждает: утечка через подрядчика не освобождает оператора от ответственности по ст. 13.11 КоАП.

Какой уровень защищённости требуется для ИСПДн с логами?

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

Если в логах содержатся только «иные категории» ПДн (общие: ФИО, IP, логин) и число субъектов не превышает 100 000, при угрозах 3-го типа (наиболее распространённых) — назначается УЗ-3. Если число субъектов превышает 100 000 или угрозы отнесены ко 2-му типу — УЗ-2. При наличии в логах данных о состоянии здоровья (например, медицинские ИС) или биометрии — УЗ-1 или УЗ-2 независимо от числа субъектов.

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

Для SaaS-платформ с мультиарендностью (multitenancy) расчёт УЗ проводится отдельно для каждого арендатора (tenant), если их ПДн логически разделены. Смешение потоков логов разных арендаторов в общем хранилище без сегрегации может поднять УЗ всей платформы до максимального среди её арендаторов — типичная ошибка архитектуры.

Как правильно организовать передачу логов: поручение или соучастие?

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

На практике SOC-провайдеры нередко используют полученные логи для обучения собственных ML-моделей детектирования угроз. Это — самостоятельная цель, выходящая за рамки поручения. Если договор это не запрещает, оператор-клиент рискует оказаться соучастником нарушения ст. 5 ФЗ-152 (принцип соответствия целей обработки).

Обязательные условия договора поручения с SOC-провайдером: исчерпывающий перечень действий с ПДн (сбор, запись, хранение, анализ, уничтожение), цели (мониторинг безопасности, реагирование на инциденты), запрет использования для собственных нужд провайдера, срок хранения и порядок уничтожения, требования к УЗ и мерам ФСТЭК, уведомление оператора при инциденте в течение 24 часов.

Обезличивание логов для ML-аналитики в SOC: где граница?

SOC-провайдеры всё чаще предлагают ML-сервисы поведенческого анализа (UEBA): модели обучаются на исторических логах, выявляя аномалии. Обучение на персональных данных без обезличивания нарушает принцип минимизации ст. 5 ФЗ-152 и требует дополнительного правового основания.

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

Ключевое ограничение: обезличивание должно быть необратимым для SOC-провайдера. Если провайдер располагает таблицей соответствия хэшей реальным идентификаторам — обезличивание юридически не состоялось. Хранение ключей деобезличивания у оператора при передаче провайдеру хэшированных данных — допустимая архитектура.

Как выглядит риск на практике: три сценария для CISO

Сценарий 1 — SOC за рубежом без уведомления РКН. Компания подключила европейского MSSP для мониторинга периметра. Логи уходят на серверы в ЕС. Уведомление о трансграничной передаче по ст. 12 ФЗ-152 не подавалось. При плановой проверке РКН обнаруживает передачу в «третью страну» без документов. Оператор получает предписание и штраф по ч. 1 ст. 13.11 КоАП (150 000 — 300 000 ₽). Параллельно — проверка локализации: первичные логи создаются и хранятся за рубежом, что нарушает ч. 5 ст. 18 ФЗ-152. Риск по ч. 8 ст. 13.11 — от 1 до 6 млн ₽.

Сценарий 2 — российский SOC без договора поручения. IT-компания из Приволжского ФО (лето 2025) передавала поток событий SIEM в SOC-провайдера на основании рамочного SLA без указания на ПДн. При инциденте с утечкой учётных данных 12 000 сотрудников РКН квалифицировал SOC-провайдера как несанкционированного получателя ПДн. Оператор привлечён по ч. 12 ст. 13.11 (утечка 1 000 — 10 000 субъектов) — штраф в диапазоне 3–5 млн ₽. SOC-провайдер — отдельным протоколом. Стратегия: заключить договор поручения ретроактивно не получилось; смягчение достигнуто через ст. 4.1.1 КоАП (первичное нарушение, отсутствие вреда субъектам). ⚠️ Конкретный номер дела и точная сумма — менеджер уточняет при публикации.

Сценарий 3 — SaaS-платформа и мультиарендность. CISO SaaS-оператора (Центральный ФО, начало 2026) обнаружил, что логи всех арендаторов хранятся в общем индексе Elasticsearch. Среди арендаторов — медицинская организация, чьи логи содержат идентификаторы пациентов (спецкатегория). Смешение подняло УЗ всей платформы до УЗ-2, что потребовало сертифицированных СЗИ по Приказу ФСТЭК №21. Выявлено в ходе DPIA. Стоимость DPIA — 200 000 ₽; стоимость архитектурной переработки — 1,5 млн ₽. Альтернатива — штраф по ч. 13 ст. 13.11 за утечку спецкатегорий от 5 до 10 млн ₽ плюс уголовный риск по ст. 272.1 УК. ⚠️ Конкретный номер дела — менеджер уточняет при публикации.

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

• Аудит соответствия 152-ФЗ — проверка правового основания передачи логов, договоров поручения, УЗ и мер ФСТЭК
• DPIA (оценка воздействия) — обязательна при обработке логов с высоким риском, мультиарендности и ML-аналитике
• Комплект ОРД под ключ — договор поручения с SOC, политика обезличивания, регламент реагирования за 24/72 часа

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

1. Какой УЗ выбрать для SaaS с мультиарендностью?

УЗ рассчитывается по ПП РФ №1119 для каждого арендатора отдельно, если их данные логически изолированы. При смешении потоков платформа принимает максимальный УЗ среди своих арендаторов. Если хотя бы один арендатор обрабатывает спецкатегории ПДн (ст. 10 ФЗ-152) — вся платформа должна соответствовать УЗ-1 или УЗ-2 в зависимости от типа угроз. Практическое решение: логическая и физическая сегрегация данных арендаторов с раздельным расчётом УЗ для каждого контура.

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

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

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

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

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

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

5. Какие СЗИ обязательны по Приказу ФСТЭК №21 для систем с логами?

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

Итог

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

DATUM сопровождает IT-компании и SaaS-операторов в выстраивании правовой конструкции передачи логов: от расчёта УЗ и подготовки договора поручения до проведения DPIA и представления интересов при проверке РКН.