DATUM-аудит системы логирования

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

Когда лог-запись становится персональными данными?

Ст. 3 ФЗ-152 определяет ПДн как любую информацию, прямо или косвенно относящуюся к определённому физическому лицу. Типичная строка лога содержит: временну́ю метку, IP-адрес, идентификатор пользователя (user_id, session_id), строку User-Agent, код действия. Каждый из этих элементов в отдельности может быть недостаточен для идентификации. Но их комбинация — достаточна.

Позиция РКН, закреплённая в методических разъяснениях, признаёт IP-адреса ПДн при наличии механизма установления личности. В SaaS-сервисах с авторизацией такой механизм существует всегда: сервер способен сопоставить IP с учётной записью. Следовательно, любая система логирования, в которую попадают запросы аутентифицированных пользователей, обрабатывает ПДн.

Отдельный вопрос — логи API-шлюзов в мультиарендных (multi-tenant) SaaS-платформах. Один и тот же лог-поток содержит данные субъектов нескольких клиентов-операторов одновременно. Это создаёт риск смешения баз с несовместимыми целями (ст. 5 ФЗ-152) и запутывает цепочку поручения обработки по ст. 6 ФЗ-152.

Какой уровень защищённости применим к системе логирования?

ПП РФ №1119 от 01.11.2012 устанавливает четыре уровня защищённости информационных систем, обрабатывающих ПДн. Уровень зависит от трёх параметров: категория ПДн, тип актуальных угроз и количество субъектов.

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

На практике SaaS-платформы с федеральным охватом (банки, медтех, HR-системы) обрабатывают данные более 100 000 субъектов в логах уже через несколько месяцев после запуска. CISO должен контролировать этот порог и перестраивать защитные меры при его превышении — это меняет и перечень обязательных СЗИ по Приказу ФСТЭК №21.

Какие меры ФСТЭК обязательны для системы логирования?

Приказ ФСТЭК №21 от 18.02.2013 определяет состав и содержание организационных и технических мер для каждого уровня защищённости. Применительно к системам логирования ключевые группы мер следующие.

РСБ — регистрация событий безопасности. Группа мер РСБ прямо регулирует ведение журналов. Базовый набор УЗ-3 включает: регистрацию событий доступа к ПДн, регистрацию изменений привилегий, защиту журналов от несанкционированного удаления или изменения, резервное копирование журналов. УЗ-2 дополнительно требует мониторинга в режиме реального времени и автоматического реагирования на инциденты.

УПД — управление правами доступа. Доступ к лог-файлам с ПДн должен предоставляться по принципу минимальных привилегий. Разработчики, имеющие доступ к production-логам без ограничения по scope — типовое нарушение, выявляемое при проверке РКН.

ЗНИ — защита носителей информации. При выгрузке логов на внешние хранилища (S3-совместимые объектные хранилища, SIEM-системы, облачные сервисы) обязательно шифрование данных в покое и в транзите. Хранилище должно находиться в РФ (ч. 5 ст. 18 ФЗ-152).

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

Как работает обезличивание для ML и почему логи — зона риска?

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

Проблема логирования в контексте ML состоит в следующем: сырые логи передаются в аналитические системы и модели обнаружения аномалий без предварительного обезличивания. Разработчик считает, что user_id — это технический ключ, не являющийся ПДн. Однако при наличии таблицы сопоставления user_id с email и телефоном (а она существует в любом production-приложении) метод введения идентификаторов не применён, и данные остаются ПДн.

На практике обезличивание для ML реализуется через конвейер предобработки: лог-агрегатор заменяет user_id псевдонимом (введение идентификаторов), IP-адрес усекается до /24 или обобщается до региона (обобщение), строки User-Agent хэшируются или удаляются. Таблица сопоставления псевдонимов хранится отдельно, с ограниченным доступом и собственным журналом аудита.

Кто оператор в мультиарендной SaaS: разграничение ответственности

В мультиарендной SaaS-архитектуре система логирования обрабатывает события всех клиентов-арендаторов в едином потоке. Это порождает вопрос о статусе участников: кто оператор, кто обработчик по поручению (ст. 6 ФЗ-152), и несёт ли SaaS-провайдер самостоятельную ответственность.

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

При этом логи, которые SaaS-провайдер ведёт в собственных целях (мониторинг производительности, отладка), обрабатываются на основании собственного правового основания провайдера. Смешение «сервисных» и «клиентских» логов в одном хранилище — классическая ошибка архитектуры, ведущая к нарушению ст. 5 ФЗ-152 (несовместимость целей).

Типовые сценарии нарушений и их правовые последствия

Сценарий 1. Логи в иностранном облаке. SaaS-компания хранит логи приложения в AWS EU (Франкфурт). Логи содержат user_id и IP пользователей из РФ. Обработка ПДн граждан РФ на зарубежном хранилище нарушает ч. 5 ст. 18 ФЗ-152 (локализация). При проверке РКН — штраф по ч. 8 ст. 13.11 КоАП: 1–6 млн ₽. При повторном нарушении — 6–18 млн ₽ (ч. 9). Стратегия: перенести первичное хранение логов в облако с ЦОД в РФ; репликация за рубеж допустима только после формирования российской базы.

Сценарий 2. Утечка через SIEM без разграничения доступа. Подрядчик по ИБ-мониторингу получил полный доступ к SIEM с не обезличенными логами. В результате кибератаки на инфраструктуру подрядчика утекли данные 15 000 пользователей. Оператор несёт ответственность за действия подрядчика — это устоявшийся принцип судебной практики (case_generic_subpodryad). Квалификация: ч. 13 ст. 13.11 КоАП (утечка 10 000–100 000 субъектов) — 5–10 млн ₽; дополнительно ч. 11 (неуведомление об утечке в 24 часа) — 1–3 млн ₽. Стратегия: включить в договор с подрядчиком обязательства по ИБ, ограничить scope доступа к SIEM, применить обезличивание перед выгрузкой данных третьим лицам.

Сценарий 3. ML-модель на сырых логах. Data-команда обучает модель обнаружения аномалий на production-логах с user_id без предварительного обезличивания. Модель и обучающая выборка хранятся в ML-платформе с расширенным кругом доступа (дата-инженеры, аналитики). Нарушение: обработка ПДн с целью, не предусмотренной уведомлением в реестре РКН (ст. 22 ФЗ-152), без правового основания. Штраф — ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽). При утечке обучающей выборки — дополнительно по ч. 12–14 в зависимости от объёма. Стратегия: внедрить конвейер обезличивания по Приказу РКН (введение идентификаторов + обобщение IP) до передачи данных в ML-платформу; зафиксировать цель обработки в уведомлении РКН.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

Система логирования — не вспомогательная техническая компонента, а полноценная ИСПДн с требованиями к классификации по ПП РФ №1119, техническим мерам по Приказу ФСТЭК №21 и локализации по ч. 5 ст. 18 ФЗ-152. Четыре системных риска: иностранное облако без российской первичной базы, сырые логи в ML-пайплайне без обезличивания, смешение целей в мультиарендной архитектуре и отсутствие договора поручения с вендором SIEM — каждый из них покрывается отдельной частью ст. 13.11 КоАП с ценой от 1 до 15 млн ₽.

Практика DATUM по техническому комплаенсу 152-ФЗ охватывает задачи CISO: от классификации ИСПДн и разработки модели угроз до оформления договоров поручения с облачными провайдерами и подготовки к проверке РКН по ИТ-инфраструктуре.