Audit log в SaaS: ПДн администратора

С 30.05.2025 ст. 13.11 КоАП действует в редакции ФЗ-420 от 30.11.2024: 18 частей вместо прежних семи. Для SaaS-команды это означает, что любая запись в журнале аудита, позволяющая идентифицировать конкретного человека, автоматически подпадает под режим ПДн. Одновременно с 11.12.2024 действует ст. 272.1 УК — незаконное хранение или использование компьютерной информации с ПДн грозит уже не штрафом, а лишением свободы. Ниже — как разграничить роли оператора и обработчика в мультиарендной архитектуре, что считать минимально необходимым набором мер защиты и как организовать обезличивание для ML без потери полезности данных.

Является ли audit log персональными данными?

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

Роскомнадзор в своей правоприменительной практике устойчиво квалифицирует IP-адрес как ПДн при наличии возможности сопоставления с учётной записью. В SaaS-продукте такая возможность есть всегда: таблица пользователей и таблица логов находятся в одной инфраструктуре или связаны через API. Это означает, что audit log — это не технический артефакт за пределами ФЗ-152, а часть информационной системы персональных данных (ИСПДн).

Практический вывод для CTO: система логирования должна быть включена в периметр ИСПДн и учтена при определении уровня защищённости по ПП РФ №1119. Хранить логи в отдельном S3-бакете без применения организационных и технических мер, установленных Приказом ФСТЭК №21, — нарушение ч. 1 ст. 13.11 КоАП.

Какой уровень защищённости применяется к SaaS и почему это важно для audit log?

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

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

Audit log, хранящийся в той же инфраструктуре, что и основные данные, наследует уровень основной ИСПДн. Если лог выведен в отдельный сервис (например, Elasticsearch или сторонний SIEM), этот сервис сам становится частью ИСПДн и требует аналогичных мер защиты — либо данные в нём должны быть обезличены.

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

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

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

Это разграничение имеет практические последствия для audit log. ПДн администраторов клиента — сотрудников, настраивающих систему, — также являются ПДн субъектов. Вендор обрабатывает их по договору-поручению. Если договор не содержит перечень обрабатываемых категорий ПДн, перечень операций, цели, обязательство об уничтожении после прекращения договора — это нарушение порядка поручения обработки. Регулятор при проверке смотрит именно на этот документ.

Отдельный вопрос — ПДн администраторов самого вендора, имеющих доступ к инфраструктуре клиентских тенантов. Запись о том, что инженер службы поддержки вошёл в тенант клиента в 14:32 и выполнил определённое действие, — это ПДн этого инженера. Одновременно эта запись может содержать информацию о действиях с ПДн пользователей клиента, то есть попадать под режим конфиденциальности. Хранить такие логи без разграничения — значит создавать риск сразу по нескольким основаниям.

Обезличивание для ML: как убрать ПДн из audit log без потери ценности данных

Данные журналов аудита — ценное сырьё для ML-моделей обнаружения аномалий, предсказания отказов и оптимизации UX. Проблема в том, что передача немодифицированного audit log в ML-конвейер означает передачу ПДн. Если конвейер работает за пределами основной ИСПДн или обрабатывает данные в иных целях — нарушается принцип целеограниченности по ст. 5 ФЗ-152.

Приказ РКН (действует с 01.09.2025) закрепил пять методов обезличивания: введение идентификаторов (псевдонимизация), изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Для audit log наиболее применимы два из них.

Первый — введение идентификаторов: замена user_id и IP-адреса на стабильный псевдоним внутри сессии. Это сохраняет причинно-следственные связи между событиями (важно для поведенческого анализа), но устраняет прямую связь с личностью. При этом таблица соответствия «псевдоним — реальный пользователь» должна храниться отдельно, с более строгим доступом, чем сами логи.

Второй — обобщение и агрегация: замена точных временных меток на временны́е окна (час, смена), замена IP-адреса на подсеть /24, замена конкретного action на категорию действия. Этот метод необратим и подходит для аналитики, не требующей воспроизведения конкретного инцидента.

Важно: обезличенные данные по ст. 13.1 ФЗ-152 (в ред. ФЗ-233 от 08.08.2024) с 2025 года имеют отдельный правовой режим. Если обезличивание выполнено по одному из пяти методов и данные переданы в ЕИП НСУД или третьей стороне — это не считается передачей ПДн. Но если применённый метод не соответствует требованиям РКН — данные остаются ПДн независимо от намерений разработчика.

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

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

Сценарий 2. Audit log в иностранном облаке без уведомления РКН о трансграничной передаче. CTO разместил Elasticsearch в AWS eu-west или в другом зарубежном регионе. Логи содержат ПДн граждан РФ. С точки зрения ч. 5 ст. 18 ФЗ-152 и редакции ФЗ-233 от 08.08.2024 это нарушение локализации: хранение ПДн граждан РФ должно осуществляться в базах на территории РФ. Вероятный состав: ч. 8 ст. 13.11 КоАП, штраф 1 000 000–6 000 000 ₽. При повторности — ч. 9, до 18 000 000 ₽. Стратегия: перевести хранение в облако на территории РФ или применить сертифицированное ФСТЭК средство криптозащиты с хранением ключей в РФ (если применимо).

Сценарий 3. Утечка audit log через уязвимость в API. Неавторизованный запрос вернул страницу результатов с user_id, email, IP и временными метками. Факт зафиксирован в системе мониторинга. У команды есть 24 часа на первичное уведомление РКН (ч. 3.1 ст. 21 ФЗ-152, Приказ РКН №187 от 14.11.2022). Несоблюдение срока — состав по ч. 11 ст. 13.11 КоАП, штраф 1 000 000–3 000 000 ₽. Объём утечки определяет дополнительный состав: от 1 000 до 10 000 субъектов — ч. 12 (3–5 млн ₽), от 10 000 до 100 000 — ч. 13 (5–10 млн ₽), свыше 100 000 — ч. 14 (10–15 млн ₽). При повторности — оборотный штраф по ч. 15: 1–3% годовой выручки, не менее 20 млн ₽, не более 500 млн ₽.

Практика: что происходит при проверке

Кейс 1. IT-компания (Сибирский ФО, осень 2025) эксплуатировала SaaS-платформу для B2B-клиентов. Audit log хранился в отдельном Elasticsearch-кластере на сервере в дата-центре за рубежом. Внеплановая проверка РКН выявила нарушение локализации по ч. 5 ст. 18 ФЗ-152. Арбитражный суд региона квалифицировал нарушение по ч. 8 ст. 13.11 КоАП. С учётом первичности нарушения и частичного устранения до вынесения постановления штраф составил сумму в нижней части диапазона — в несколько миллионов рублей. После вынесения постановления компания перевела хранение в российский ЦОД и обратилась за юридическим сопровождением при повторном уведомлении РКН. ​Конкретный номер дела и точная дата — менеджер уточняет при публикации.

Кейс 2. Технический директор SaaS-компании (Центральный ФО, начало 2026) самостоятельно провёл предварительный аудит перед подачей уведомления в РКН. Выяснилось, что в уведомлении не была указана обработка ПДн через систему логирования, хотя audit log содержал email-адреса и IP администраторов клиентов. Договоры-поручения с клиентами отсутствовали. Юристы DATUM помогли подать уточнённое уведомление в РКН, заключить типовые договоры-поручения и разработать политику обработки данных в подсистеме логирования. Проверка РКН, инициированная по жалобе, не выявила текущих нарушений — предписание не выносилось.

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

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

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

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

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

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

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

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

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

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

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

5. Какие СЗИ обязательны для SaaS с УЗ-3?

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

Итог

Audit log в SaaS — это ПДн по умолчанию: IP-адреса, идентификаторы и временны́е метки в совокупности идентифицируют администратора. Это означает включение подсистемы логирования в ИСПДн, определение УЗ по ПП РФ №1119, применение мер ФСТЭК по Приказу №21 и оформление договора-поручения с каждым клиентом. Хранение в зарубежном облаке без локализации — риск штрафа от 1 до 18 млн ₽ по ч. 8–9 ст. 13.11 КоАП. Передача необезличенных логов в ML — нарушение принципа целеограниченности по ст. 5 ФЗ-152.

DATUM сопровождает IT-компании и SaaS-вендоров в вопросах соответствия ФЗ-152: от классификации ИСПДн и разработки модели угроз до формирования комплекта договоров-поручений и политики обезличивания для аналитических систем.

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