Доступ к логам: 5 уровней

Логирование действий пользователей, API-запросов и системных событий — стандартная практика любой SaaS-платформы. Проблема в другом: в большинстве российских IT-компаний доступ к логам либо не разграничен вовсе, либо разграничён без привязки к требованиям ФЗ-152. В результате DevOps-инженер видит ФИО клиентов, аналитик выгружает IP-адреса в Google Sheets, а ML-модель обучается на необезличенных сессионных данных. Каждое из этих действий — потенциальное нарушение. В этом материале разобраны 5 уровней доступа к логам, их привязка к уровням защищённости УЗ-1..4, требования Приказа ФСТЭК №21 к управлению привилегиями, порядок обезличивания для ML-пайплайнов и ответственность за нарушения по новым нормам ст. 13.11 КоАП.

Почему доступ к логам — это вопрос 152-ФЗ, а не только ИБ?

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

Это означает, что к логам применяются все обязанности по ст. 19 ФЗ-152: назначение лиц с доступом, фиксация их полномочий, контроль за действиями. Приказ ФСТЭК №21 прямо выделяет группу мер УПД (управление правами доступа) как обязательную для всех уровней защищённости — от УЗ-4 до УЗ-1. Отсутствие формальной матрицы доступа к логам — это не «недочёт архитектуры», а фиксируемое нарушение при проверке РКН.

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

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

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

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

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

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

5 уровней доступа к логам: операционная матрица

На практике DATUM выделяет пять функциональных уровней доступа, которые необходимо разграничить формально — через ролевую модель (RBAC) или атрибутивную (ABAC) в зависимости от архитектуры системы. Каждый уровень фиксируется в политике обработки ПДн и регламенте доступа к ИСПДн.

Уровень 1 — без доступа (No Access). Применяется для внешних подрядчиков, которые не являются уполномоченными обработчиками по ст. 6 ФЗ-152. Доступ к логам с ПДн исключён технически. Отсутствие поручения на обработку при фактическом доступе — нарушение ч. 1 ст. 13.11 КоАП (штраф 150–300 тыс. ₽).

Уровень 2 — агрегированный доступ (Aggregate). Аналитики и ML-инженеры получают только обезличенные или агрегированные данные. ПДн недоступны в сыром виде. Этот уровень требует формально задокументированного метода обезличивания по Приказу РКН (введение идентификаторов, обобщение, перемешивание). Без документированного метода — регулятор не признаёт данные обезличенными.

Уровень 3 — операционный доступ (Operational). DevOps и SRE-инженеры видят технические идентификаторы (session_id, request_id), но не прямые ПДн. Сопоставление с субъектом возможно только через отдельный запрос в основную базу, который логируется. Это стандартный уровень для УЗ-3 при соблюдении принципа наименьших привилегий.

Уровень 4 — расследовательский доступ (Investigative). Команда ИБ имеет доступ к полным логам включая ПДн — только в рамках расследования инцидента. Каждый факт доступа фиксируется в журнале с обоснованием. Этот уровень регулируется мерами группы РСБ (регистрация событий безопасности) Приказа ФСТЭК №21.

Уровень 5 — административный доступ (Administrative). CISO и ответственный за обработку ПДн по ст. 22.1 ФЗ-152 имеют полный доступ для целей контроля. Действия на этом уровне подлежат аудиту — в том числе на предмет соблюдения самими администраторами установленного порядка. Для УЗ-1 и УЗ-2 рекомендуется двойной контроль (четыре глаза).

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

Использование логов для обучения ML-моделей — распространённая практика в SaaS: поведенческие паттерны, рекомендательные системы, детекция аномалий. Правовая проблема возникает, когда в обучающей выборке остаются прямые или косвенные идентификаторы субъектов.

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

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

Для SaaS с мультиарендной архитектурой возникает дополнительный вопрос: данные разных арендаторов (tenants) не должны смешиваться при обезличивании. Утечка данных одного клиента через ML-модель, обученную на смешанной выборке, — это нарушение принципа несовместимости целей по ст. 5 ФЗ-152.

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

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

Принцип ответственности оператора за действия обработчика подтверждён практикой: если утечка произошла через подрядчика или провайдера, протокол составляется на оператора. Аргумент «это был наш вендор» не освобождает от ответственности по ст. 13.11 КоАП.

При использовании иностранных облачных провайдеров возникает риск нарушения требований локализации по ч. 5 ст. 18 ФЗ-152: запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ должны осуществляться в базах данных, расположенных на территории России. Хранение логов с ПДн российских пользователей в AWS us-east-1 или Azure West Europe — нарушение с 01.07.2025 в новой редакции. Штраф по ч. 8 ст. 13.11 КоАП — от 1 до 6 млн ₽; при повторности (ч. 9) — от 6 до 18 млн ₽.

Сценарии нарушений при доступе к логам: что реально происходит на практике

Сценарий 1. DevOps имеет неограниченный доступ к production-логам с ПДн. Ситуация: при отладке инцидента инженер экспортирует логи в локальную среду, в которой нет средств защиты. Данные 15 000 пользователей (ФИО, email, IP, история действий) находятся в незашифрованном файле на рабочей станции. Доказательства: журнал SIEM, запрос на экспорт, отсутствие регламента обезличивания. Вероятный исход: при проверке РКН — нарушение мер УПД Приказа ФСТЭК №21, нарушение ст. 19 ФЗ-152; при утечке этого файла — ч. 13 ст. 13.11 КоАП (штраф 5–10 млн ₽). Стратегия: ввести уровень 3 (операционный), исключить экспорт ПДн без обезличивания, зафиксировать в регламенте.

Сценарий 2. ML-команда обучает модель на сырых логах без обезличивания. Ситуация: аналитики получили дамп таблицы событий за 6 месяцев с user_id, привязанными к реальным субъектам через основную базу. Модель рекомендаций обучена на этих данных. Доказательства: задокументированного метода обезличивания нет, в политике обработки ПДн ML-пайплайн не упомянут как цель. Вероятный исход: нарушение ст. 5 ФЗ-152 (несовместимость целей — обучение модели не было заявлено), нарушение ст. 13.1 ФЗ-152; при проверке — штраф по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽) и предписание. Стратегия: добавить ML-обучение как отдельную цель в уведомление РКН, ввести уровень 2 (агрегированный доступ), задокументировать метод обезличивания.

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

Как это работает на практике

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

Кейс 2. Финтех-платформа (Центральный ФО, начало 2026, мультиарендная SaaS) обнаружила, что ML-команда 8 месяцев использовала необезличенные логи транзакций для обучения скоринговой модели. После внутреннего аудита, инициированного новым CISO, выявлено: данные 120 000 субъектов обрабатывались в целях, не указанных в уведомлении РКН; договоры поручения с двумя подрядчиками отсутствовали. Риск: ч. 14 ст. 13.11 КоАП (утечка более 100 000 субъектов при выявлении инцидента) — штраф 10–15 млн ₽ плюс риск ч. 1 ст. 13.11 за несовместимость целей. DATUM провёл DPIA, скорректировал уведомление в реестре РКН, ввёл регламент обезличивания для ML и заключил договоры поручения. Самостоятельное устранение до проверки РКН существенно снизило регуляторный риск.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

DATUM сопровождает IT-компании и SaaS-провайдеров по полному циклу: от определения уровня защищённости и аудита матрицы доступа до подготовки ОРД, проведения DPIA и защиты интересов при проверке РКН. Практика по 152-ФЗ ведётся с 2014 года в рамках сети «Ветров и партнёры».

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