Логи сервера как ПДн: позиция РКН

Серверные логи исторически считались техническими артефактами вне правового поля. Позиция РКН изменила эту практику: ведомство последовательно признаёт IP-адреса и связанные с ними идентификаторы персональными данными, если оператор способен соотнести их с конкретным человеком. С вступлением в силу ФЗ-420 от 30.11.2024 цена неопределённости резко выросла. Ниже — разбор позиции регулятора, её влияния на архитектуру логирования, требования к уровням защищённости и обезличиванию для ML.

Почему IP-адрес в логе — это ПДн по позиции РКН?

Ст. 3 ФЗ-152 определяет персональные данные как любую информацию, относящуюся прямо или косвенно к определённому или определяемому физическому лицу. Ключевое слово — «определяемому». IP-адрес сам по себе не идентифицирует человека однозначно. Однако в связке с идентификатором сессии, cookie-файлом, учётной записью или записями о транзакциях он приобретает идентифицирующий потенциал.

РКН в неоднократных разъяснениях занимал позицию: если оператор технически способен сопоставить IP-адрес с конкретным пользователем — такой адрес является ПДн. Аналогично оцениваются User-Agent, токены авторизации, идентификаторы устройств в access- и error-логах, а также строки запросов, содержащие параметры с именем или email пользователя.

Практическое следствие: access-лог Nginx или Apache, в котором зафиксированы IP, метка времени и URI с параметрами пользователя, подпадает под действие ФЗ-152. Хранение, передача и обработка такого лога требуют правового основания по ст. 6 ФЗ-152, организационных и технических мер по ст. 19, а сама база логов должна находиться на серверах в РФ в соответствии с ч. 5 ст. 18 ФЗ-152.

Исключение — полностью анонимные метрики, где IP усечён до подсети (/24 и короче) и не хранятся иные идентификаторы, позволяющие восстановить субъекта. Такой подход используется в конфигурациях аналитики без привязки к аккаунту, однако он требует документального подтверждения архитектурного решения и оценки риска повторной идентификации.

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

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

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

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

Практически значимый вопрос для CISO: входит ли система агрегации логов (ELK, Loki, Graylog) в контур ИСПДн? Если в неё поступают события с ПДн — входит. Это означает, что SIEM-решение должно удовлетворять требованиям соответствующего УЗ, а доступ к нему — разграничиваться согласно УПД.

Как логи сервера влияют на мультиарендную SaaS-архитектуру?

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

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

Добавляет сложности KII (критическая информационная инфраструктура): если SaaS-провайдер является субъектом КИИ по ФЗ-187, требования к логированию пересекаются с обязательствами по ФЗ-187 и приказу ФСТЭК №239. Логи инцидентов безопасности могут одновременно подпадать под требования обоих регуляторов.

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

Машинное обучение на production-логах — распространённая практика для аномалий безопасности, рекомендательных систем и предиктивного масштабирования. Проблема: обучающая выборка содержит ПДн пользователей. Использование необезличенных логов для ML создаёт самостоятельное правовое основание обработки, которое должно быть закреплено в уведомлении РКН и согласиях (если применимо).

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

Практический критерий достаточности обезличивания для ML: после применения методов оператор обязан провести оценку риска повторной идентификации. Если такой риск выше пренебрежимого — меры недостаточны. Результат оценки фиксируется документально и прикладывается к ОРД системы ML. DPIA (оценка воздействия на субъектов) рекомендуется при масштабной обработке логов для ML, особенно если модель принимает решения, затрагивающие права субъектов.

Как это работает на практике: разбор типовых ситуаций

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

Ситуация 2. ML-конвейер без обезличивания. Команда data science в компании (Центральный ФО, осень 2025) обучала модель детектирования аномалий на production-логах без предварительного обезличивания. Аудит выявил: в обучающей выборке — email-адреса из параметров запросов, идентификаторы сессий. Правовое основание для этой обработки в уведомлении РКН отсутствовало. Компания провела псевдонимизацию, пересобрала выборку, обновила уведомление. Санкций удалось избежать до возбуждения дела.

Ситуация 3. Утечка логов через подрядчика SIEM. Оператор передал логи внешнему SIEM-провайдеру без оформления договора поручения по ч. 3 ст. 6 ФЗ-152. Провайдер допустил публичный доступ к индексу Elasticsearch на три дня. По принципу судебной практики, оператор несёт ответственность за действия подрядчика. Риск: ч. 12 ст. 13.11 КоАП (утечка от 1 000 до 10 000 субъектов) — 3–5 млн ₽, плюс ч. 11 за нарушение 24-часового срока уведомления РКН — 1–3 млн ₽.

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

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

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

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

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

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

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

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

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

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

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

5. Какие средства защиты информации обязательны для ИСПДн с логами?

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

Итог

Позиция РКН по серверным логам как ПДн не нова, однако санкционное давление резко возросло с 30.05.2025: штрафы по ч. 12–15 ст. 13.11 КоАП достигают 500 млн ₽ при повторной утечке. Ненадлежащая квалификация логов, хранение вне РФ или передача в ML-конвейер без обезличивания — три наиболее частых точки риска в IT-компаниях и SaaS-провайдерах.

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