Передача логов в SIEM-систему

Передача логов в SIEM-систему — стандартная практика SOC, но с 2025 года она стала точкой правового риска. Роскомнадзор квалифицирует IP-адреса, user-агенты и пользовательские идентификаторы как персональные данные. Уровень защищённости ИСПДн (УЗ-1..4 по ПП РФ №1119) определяет, какие меры по Приказу ФСТЭК №21 обязательны в пайплайне логирования. Эта статья разбирает правовые основания передачи, требования к обработчику, обезличивание для ML и риски мультиарендных SaaS-SIEM.

Являются ли логи персональными данными по 152-ФЗ?

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

На практике это означает: файл лога с полями user_id, ip, action, timestamp — это база персональных данных, а не техническая телеметрия. Передача такого файла в SIEM — обработка ПДн по поручению (п. 3 ст. 6 152-ФЗ), если SIEM-система принадлежит подрядчику или SaaS-провайдеру.

Отсутствие договора поручения с SIEM-провайдером — самостоятельное нарушение ч. 1 ст. 13.11 КоАП (обработка ПДн в случаях, не предусмотренных законом): штраф для юрлица 150 000–300 000 ₽ в редакции с 30.05.2025. При повторности — 300 000–500 000 ₽ по ч. 1.1.

Как уровень защищённости УЗ-1..4 влияет на архитектуру SIEM?

ПП РФ №1119 устанавливает четыре уровня защищённости информационных систем персональных данных. Уровень зависит от категории ПДн, типа угроз и числа субъектов. SIEM, обрабатывающий логи корпоративных систем с данными более 100 000 субъектов, при актуальности угроз 2-го типа попадает под УЗ-2.

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

• РСБ (регистрация событий безопасности): каналы передачи логов должны обеспечивать целостность записей — запрет на модификацию после отправки в SIEM. Требование применимо начиная с УЗ-4.
• ЗИС (защита информационной системы): шифрование канала передачи логов — TLS 1.2+ — обязательно для УЗ-3 и выше. Для УЗ-2 дополнительно требуется использование СКЗИ, сертифицированного ФСБ.
• УПД (управление доступом): разграничение прав аналитиков SOC к потокам логов в разрезе категорий ПДн. Без ролевой модели в SIEM передача данных о здоровье (специальные категории по ст. 10 152-ФЗ) и стандартных ПДн в единый индекс — нарушение принципа минимизации (ст. 5 152-ФЗ).

Что нужно сделать перед передачей логов в SIEM: обязательные меры

Передача логов в SIEM без предварительной подготовки — одна из наиболее распространённых точек несоответствия при проверках РКН в IT-компаниях. Порядок действий определяется нормами ст. 6, ст. 18.1 и ст. 19 152-ФЗ совместно с Приказом ФСТЭК №21.

Как обезличить логи для ML и SIEM без потери аналитической ценности?

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

• Введение идентификаторов (псевдонимизация): реальный IP или user_id заменяется детерминированным хешем (например, HMAC-SHA256 с ротируемым ключом). Модель ML сохраняет возможность отслеживать поведение одного субъекта во времени, не зная его личности. Ключ ротируется по расписанию — связь с оригиналом разрывается. Этот метод признаётся РКН обезличиванием при условии, что исходный идентификатор не хранится в той же системе.
• Обобщение: точный IP заменяется подсетью (/24), точная временная метка — 15-минутным окном. Применимо для аналитики, где нужна геолокация и суточные паттерны, но не конкретный пользователь.
• Декомпозиция: поля, напрямую идентифицирующие субъекта (email, полное имя), хранятся в отдельном защищённом хранилище; в SIEM передаётся только псевдоним. Соединение происходит только при расследовании инцидента с авторизацией.

Критически важно: обезличивание должно производиться до передачи данных в SIEM, а не внутри него. SIEM-система, хранящая необезличенные ПДн, является ИСПДн со всеми вытекающими требованиями по УЗ и Приказу ФСТЭК №21. Если SIEM находится у подрядчика — это поручение обработки необезличенных ПДн, требующее полноценного договора и аттестации системы.

Какие риски несёт мультиарендный SaaS-SIEM с точки зрения 152-ФЗ?

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

Типовые риски мультиарендности по 152-ФЗ:

• Смешение данных разных арендаторов при неправильной настройке индексов — нарушение конфиденциальности и ст. 7 152-ФЗ (обработчик обязан соблюдать конфиденциальность наравне с оператором).
• Локализация данных: если SaaS-SIEM хранит данные в иностранном облаке, оператор нарушает ч. 5 ст. 18 152-ФЗ о локализации. Штраф — 1–6 млн ₽ по ч. 8 ст. 13.11 КоАП; повторно — 6–18 млн ₽ по ч. 9. Требование действует с 01.09.2015 и последовательно ужесточается.
• Трансграничная передача логов: отправка событий в SIEM с серверами в США или ЕС без уведомления РКН по ст. 12 152-ФЗ — отдельное нарушение. Уведомление направляется через pd.rkn.gov.ru до начала передачи.
• Роль оператора vs. обработчика: если SaaS-провайдер самостоятельно определяет цели аналитики логов (например, обучает собственные ML-модели на данных клиентов) — он перестаёт быть обработчиком и становится соопе­ратором. Это существенно меняет объём его ответственности и требования к правовому основанию обработки.

Объекты КИИ (критической информационной инфраструктуры) по 187-ФЗ обязаны использовать отечественные SIEM-решения или иностранные SIEM с российской инсталляцией, соответствующей требованиям ФСТЭК. Для субъектов КИИ передача логов в иностранный облачный SIEM создаёт риски одновременно по 152-ФЗ и 187-ФЗ.

Три типовые ситуации, с которыми приходят CISO

Ситуация 1. Облачный SIEM (AWS/Azure) без договора поручения и уведомления РКН. Компания-оператор использует SIEM на иностранных серверах с 2022 года. Договор с провайдером — стандартный SaaS-terms без раздела об обработке ПДн. Доказательства нарушения при проверке: реестр уведомлений РКН не содержит записи о трансграничной передаче; в договоре нет перечня мер защиты, обязательных по ч. 3 ст. 6 152-ФЗ. Вероятный исход: нарушение ч. 5 ст. 18 (локализация) — ч. 8 ст. 13.11 КоАП, штраф 1–6 млн ₽; нарушение ст. 12 (трансграничка без уведомления) — ч. 1 ст. 13.11, штраф 150–300 тыс. ₽. Стратегия: перейти на облако в РФ или установить on-premise; параллельно подать уведомление о трансграничной передаче через pd.rkn.gov.ru и заключить договор поручения.

Ситуация 2. SIEM получает необезличенные логи медицинской системы. Клиника использует on-premise SIEM, куда поступают логи МИС с полями patient_id, диагноз, ФИО врача. Данные о здоровье — специальная категория по ст. 10 152-ФЗ; их обработка в SIEM без явного согласия или иного основания из п. 2 ст. 10 — нарушение. При утечке логов затрагиваются биографические и медицинские данные одновременно. Вероятный исход: нарушение ст. 10 + при утечке — ч. 12–14 ст. 13.11 КоАП (3–15 млн ₽ в зависимости от числа субъектов). Стратегия: ввести обезличивание (декомпозиция: patient_id → хеш, диагноз → код МКБ) до передачи в SIEM; обновить модель угроз и определить УЗ как УЗ-2 или УЗ-1.

Ситуация 3. Утечка через SIEM-подрядчика, данные появились в даркнете. SIEM-провайдер сообщил об инциденте в своей инфраструктуре. Клиент-оператор не имеет собственного процесса реагирования. Срок 24 часа на первичное уведомление РКН по ч. 3.1 ст. 21 152-ФЗ не соблюдён — нет внутреннего регламента, нет ответственного. Вероятный исход: штраф по ч. 11 ст. 13.11 за неуведомление — 1–3 млн ₽; штраф по ч. 12–14 за саму утечку — 3–15 млн ₽ в зависимости от масштаба. Стратегия: немедленно зафиксировать момент обнаружения, направить первичное уведомление через pd.rkn.gov.ru, подключить юристов для составления 72-часового отчёта.

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

Кейс 1. IT-компания (Сибирский ФО, осень 2025) передавала логи корпоративного портала в мультиарендный SaaS-SIEM с серверами в Финляндии. Договор поручения отсутствовал, уведомление о трансграничной передаче не подавалось. При плановой проверке РКН выявил два самостоятельных нарушения: отсутствие основания обработки по ч. 3 ст. 6 и нарушение локализации по ч. 5 ст. 18 152-ФЗ. CISO обратился в DATUM после получения акта. Юристы оспорили состав нарушения по локализации (данные в логах оказались частично обезличены), что снизило квалификацию с ч. 8 до ч. 1 ст. 13.11 КоАП. Итоговый штраф — в нижней части диапазона ч. 1. Параллельно компания перешла на российский облачный SIEM и заключила договор поручения.

Кейс 2. SaaS-разработчик (Центральный ФО, начало 2026) получил от клиента-оператора требование провести аудит SIEM-пайплайна перед подписанием DPA (Data Processing Agreement). Выяснилось: логи содержали поля email и session_token; обезличивание не применялось; уровень защищённости системы не определён. После аудита DATUM разработчик внедрил псевдонимизацию (HMAC с ротацией ключа) на уровне агента сбора логов, определил ИСПДн как УЗ-3 и получил аттестацию по Приказу ФСТЭК №21. DPA подписан, клиент-оператор снял требование о переносе данных.

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

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

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

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

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

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

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

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

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

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

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

5. Какие СЗИ обязательны для ИСПДн с SIEM?

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

Итог

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

DATUM сопровождает IT-компании и SaaS-разработчиков в вопросах 152-ФЗ с 2014 года — от определения УЗ и составления договора поручения до защиты интересов при проверке РКН и оспаривания протоколов по ст. 13.11 КоАП.

21 января 2029 года