Архивация логов: правила

Логирование — инструмент расследования инцидентов. Однако те же журналы становятся источником утечки, если хранятся без шифрования, дольше установленного срока или передаются в облачный сервис за рубежом. В 2025 году РКН зафиксировал 118 случаев компрометации баз; значительная часть инцидентов затрагивала именно технические журналы с косвенными идентификаторами пользователей. В статье разобраны требования к архивации логов по ФЗ-152, ПП РФ №1119, Приказу ФСТЭК №21, режим обезличивания для ML и специфика мультиарендных SaaS.

Почему логи — это ПДн и что из этого следует?

IP-адрес пользователя, идентификатор сессии, временная метка действия и device fingerprint в совокупности позволяют идентифицировать физическое лицо. Роскомнадзор последовательно квалифицирует такую информацию как персональные данные по ст. 3 ФЗ-152. Следствие: обработка логов — это обработка ПДн со всеми вытекающими обязанностями.

На практике это означает: цели обработки логов должны быть зафиксированы в политике обработки ПДн и в уведомлении в реестре РКН. Если компания собирает логи «на всякий случай» без конкретных сроков хранения — она нарушает ст. 5 ФЗ-152 уже в момент сбора. Основание для проверки по ч. 1 ст. 13.11 КоАП — штраф 150 000–300 000 ₽ при первичном нарушении, 300 000–500 000 ₽ при повторном.

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

Какой уровень защищённости (УЗ) нужен для хранения логов?

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

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

Какие меры защиты при архивации логов требует Приказ ФСТЭК №21?

Приказ ФСТЭК №21 от 18.02.2013 определяет базовый набор мер по 15 группам. Для архивации логов критичны три группы.

РСБ — регистрация событий безопасности. Оператор обязан фиксировать события доступа к логам, их изменения и удаления. Архив журналов сам должен логироваться — замкнутый контроль. При УЗ-3 и УЗ-2 требуется хранение записей о событиях не менее установленного срока (конкретный срок определяется оператором в политике, но рекомендуемый минимум — 1 год для инцидентного расследования).

ЗНИ — защита носителей информации. Архивные логи на резервных носителях (ленты, внешние диски, облачные хранилища) должны быть защищены от несанкционированного доступа. Для УЗ-1 и УЗ-2 обязательно использование сертифицированных ФСТЭК средств криптографической защиты информации (СКЗИ) при хранении на съёмных носителях.

ОДТ — обеспечение доступности. Архивация должна обеспечивать восстановление данных при инциденте. Отсутствие резервных копий логов за период до инцидента лишает оператора доказательной базы при расследовании и может быть расценено РКН как ненадлежащая организация обработки по ст. 19 ФЗ-152.

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

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

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

Важно: обезличенные данные по ст. 13.1 ФЗ-152 остаются под регуляторным контролем при передаче в ЕИП НСУД по требованию Минцифры. Для коммерческого ML это означает: применённый метод обезличивания должен быть задокументирован, а сам факт передачи в аналитическую систему — отражён в уведомлении реестра операторов.

Облако в РФ, SaaS-мультиарендность и поручение обработки: как это работает?

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

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

Для КИИ (критической информационной инфраструктуры) по 187-ФЗ требования к хранению логов дополнительно ужесточаются: передача данных о событиях ИБ на объектах КИИ в зарубежные SIEM запрещена. Если ваша организация является субъектом КИИ — архивация логов инцидентов должна осуществляться исключительно в российских системах.

Типичные сценарии: как это работает на практике?

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

Сценарий 2. ML-команда обучает модель на сырых логах.
Ситуация: аналитическая команда FinTech-компании передаёт журналы транзакций (IP, время, сумма, ID пользователя) в систему ML без какого-либо обезличивания. Доказательства: отсутствует регламент обезличивания, политика не содержит ML в качестве цели обработки. Вероятный исход: нарушение ст. 5 ФЗ-152 (несовместимость целей), ст. 13.1 ФЗ-152 (нарушение порядка обезличивания) — основание для штрафа по ч. 1 ст. 13.11 КоАП (150 000–300 000 ₽) и предписания об устранении. Стратегия: применить метод введения идентификаторов (замена ID псевдонимом) и обобщение по временным окнам; зафиксировать метод в регламенте и обновить политику.

Сценарий 3. Утечка архивных логов без уведомления РКН.
Ситуация: CISO телеком-компании Северо-Западного ФО (осень 2025) зафиксировал компрометацию архива логов за 18 месяцев — затронуто около 45 000 субъектов. Первичное уведомление РКН отправлено через 31 час после обнаружения. Вероятный исход: штраф по ч. 11 ст. 13.11 КоАП (неуведомление в 24 часа) — 1 000 000–3 000 000 ₽; плюс штраф по ч. 13 ст. 13.11 за утечку 10 000–100 000 субъектов — 5 000 000–10 000 000 ₽. Стратегия: регламент реагирования на утечку должен включать автоматическое триггерное уведомление ответственного лица и шаблон первичного сообщения в РКН — это позволяет уложиться в 24 часа даже при сложных инцидентах.

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

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

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

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

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

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

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

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

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

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

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

5. Какие СЗИ обязательны для архивации логов?

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

Итог

Архивация логов подпадает под требования ФЗ-152 в полном объёме: нужны правовые основания обработки, фиксированные сроки хранения, меры защиты по Приказу ФСТЭК №21 в соответствии с УЗ по ПП РФ №1119, локализация в российских базах и документированное обезличивание при передаче в ML или аналитические системы. Ошибки в любом из этих элементов создают самостоятельные основания для штрафа по ст. 13.11 КоАП — от 150 000 ₽ до 18 млн ₽ за нарушения локализации.

DATUM сопровождает IT-команды и CISO при аудите обработки технических данных (логи, SIEM, облачные хранилища), определении УЗ, разработке регламентов архивации и обезличивания, а также при подготовке к проверкам РКН в части ИСПДн.

14 апреля 2029 года