Срок хранения серверных логов

С 30.05.2025 ст. 13.11 КоАП действует в редакции ФЗ-420 от 30.11.2024: 18 частей вместо прежних 7, оборотный штраф за повторную утечку — до 500 млн ₽. Серверные логи попали в зону риска: они содержат ПДн, обрабатываются системами, которые не всегда включены в реестр уведомлений РКН, и хранятся без формального регламента. Ниже — разбор для CISO: что считается ПДн в логах, какой срок хранения обоснован, как логирование встраивается в модель угроз по ПП РФ №1119, и что делать с обезличиванием для ML-пайплайнов.

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

По ст. 3 ФЗ-152 персональные данные — любая информация, относящаяся к определённому или определяемому физическому лицу. Для логов ключевое слово — «определяемый». IP-адрес в связке с временной меткой и user-agent позволяет идентифицировать пользователя через провайдера или внутреннюю базу сессий. Роскомнадзор в своей правоприменительной практике относит IP-адреса к ПДн при наличии у оператора технической возможности сопоставить их с конкретным субъектом.

Логи становятся ПДн, если содержат хотя бы один из следующих элементов:

• IP-адрес пользователя в сочетании с идентификатором аккаунта или сессии;
• строки URL-запросов с персонализированными параметрами (email, phone, user_id);
• заголовки Authorization или Cookie с токенами, привязанными к учётной записи;
• геолокационные координаты из запросов мобильного приложения;
• записи об ошибках аутентификации с введёнными логинами.

Если лог-файл содержит только агрегированные метрики без идентификаторов (количество запросов в секунду, коды HTTP-ответов без привязки к пользователю) — это не ПДн. Такая граница важна: она определяет, нужно ли включать лог-систему в уведомление РКН по ст. 22 ФЗ-152 и применять к ней меры защиты по Приказу ФСТЭК №21.

Какой срок хранения серверных логов установлен нормативно?

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

Практически значимые сроки складываются из нескольких источников:

• Требования ФСТЭК по Приказу №21: меры группы РСБ (регистрация событий безопасности) предполагают хранение журналов аудита на срок, определённый моделью угроз оператора. Для УЗ-3 и УЗ-4 минимальный рекомендованный срок — 3 месяца; для УЗ-1 и УЗ-2 (специальные и биометрические ПДн) — от 6 месяцев до года.
• Требования КИИ по 187-ФЗ: для субъектов критической информационной инфраструктуры журналы безопасности значимых объектов КИИ хранятся не менее 3 лет согласно требованиям ФСТЭК к значимым объектам КИИ.
• Срок давности по КоАП: для административных нарушений по ст. 13.11 — 3 года (ст. 4.5 КоАП). CISO обоснованно хранит логи реагирования на инциденты 3 года, чтобы подтвердить принятые меры при проверке.
• Сроки по договорным отношениям: если логи SaaS-платформы подтверждают факты оказания услуг, применяется общий срок исковой давности — 3 года (ГК РФ).
• Требования ст. 21 ч. 3.1 ФЗ-152: документация об инциденте и принятых мерах хранится до завершения разбирательства с РКН; на практике — не менее 3 лет.

Таким образом, для большинства операторов разумный и защитимый срок хранения серверных логов, содержащих ПДн, — от 3 месяцев (минимум по ФСТЭК для УЗ-3/4) до 3 лет (максимум по срокам давности КоАП и ГК). Хранить дольше без задокументированной цели — значит нарушать принцип минимизации из ст. 5 ФЗ-152.

Как уровни защищённости УЗ-1..4 влияют на требования к логам?

Уровень защищённости ИСПДн по ПП РФ №1119 от 01.11.2012 определяет обязательный состав мер защиты. Лог-инфраструктура напрямую затрагивается мерами группы РСБ из Приказа ФСТЭК №21.

Соответствие между уровнем защищённости и требованиями к логированию:

• УЗ-4 (общие ПДн, менее 100 000 субъектов, угроза 3-го типа): регистрация входов/выходов, событий управления доступом; срок хранения — определяет оператор, рекомендуется не менее 3 месяцев.
• УЗ-3 (общие ПДн более 100 000 субъектов или специальные ПДн менее 100 000 не госоргана): те же меры РСБ плюс аудит привилегированных действий; срок — не менее 3–6 месяцев.
• УЗ-2 (специальные ПДн более 100 000 субъектов или биометрические данные): расширенный аудит, включая неуспешные аутентификации и изменения конфигурации СЗИ; срок — не менее 6–12 месяцев.
• УЗ-1 (специальные ПДн более 100 000 субъектов с угрозами 1–2 типа): полный аудит всех событий безопасности с защитой журналов от модификации (WORM-хранилище или криптографическая защита); срок — не менее 1 года.

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

Что такое обезличивание логов для ML и как оно снимает требования 152-ФЗ?

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

Для ML-пайплайнов, обучающихся на логах, практически применимы три метода из пяти утверждённых:

• Введение идентификаторов: замена реальных user_id, IP-адресов и email на псевдонимы через детерминированное хеширование с секретным солтом. Важно: соль хранится отдельно от датасета; без неё обратное сопоставление невозможно.
• Обобщение и агрегация: замена точных IP-адресов на подсети (/24), точных временных меток — на часовые интервалы, географических координат — на регионы. Подходит для аналитических задач, где точность до субъекта не нужна.
• Декомпозиция: разделение лога на два файла: технический (IP, user-agent, timestamp) и бизнесовый (user_id, действие, параметры). Файлы хранятся в изолированных системах; для ML-задачи передаётся только один.

После корректного обезличивания лог-датасет можно хранить неограниченно долго для обучения моделей — требования ст. 5 ФЗ-152 о сроках не применяются. Однако CISO должен задокументировать применённый метод и его параметры: если РКН при проверке потребует подтверждения, что данные действительно обезличены, наличие этой документации является доказательством.

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

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

Это означает двойную ответственность. SaaS-провайдер несёт ответственность за безопасность лог-инфраструктуры как оператор. Клиент несёт ответственность за правомерность обработки данных своих пользователей. Для разграничения необходим договор поручения обработки по ст. 6 ч. 3 ФЗ-152 с явным перечнем действий и обязанностей каждой стороны.

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

Как это применяется на практике

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

Кейс 2. SaaS-провайдер (Уральский ФО, начало 2026) хранил логи с IP-адресами и идентификаторами пользователей бессрочно — регламента хранения не было. При утечке базы логов через уязвимость в API было затронуто более 10 000 субъектов. Применена ч. 13 ст. 13.11 КоАП (штраф 5–10 млн ₽). Дополнительно РКН выдал предписание об утверждении политики хранения с конкретными сроками. CISO компании был привлечён к дисциплинарной ответственности внутренним решением совета директоров. Ситуация разрешилась бы мягче при наличии задокументированного регламента и обезличивания логов старше 6 месяцев.

Типовые сценарии: CISO и лог-инфраструктура

Сценарий 1. Логи хранятся бессрочно, регламента нет. Ситуация: накопленная база логов за 5 лет содержит IP-адреса, user_id и строки запросов. Доказательства: в политике обработки ПДн лог-система не упомянута; уведомление РКН не охватывает эту цель. Вероятный исход: при инциденте или плановой проверке — нарушение ч. 1 ст. 13.11 (штраф до 300 000 ₽) и, при утечке, — ч. 12–14 (3–15 млн ₽). Стратегия: немедленно провести классификацию логов, установить срок хранения (3–36 месяцев по цели), внедрить автоудаление.

Сценарий 2. Логи передаются в облако вне РФ для обучения ML-модели. Ситуация: данные пользователей (IP + действия) поступают напрямую в зарубежный ML-сервис без предварительного обезличивания. Доказательства: нет договора поручения обработки, нет записи в российскую базу. Вероятный исход: нарушение локализации по ч. 8 ст. 13.11 (1–6 млн ₽) плюс трансграничная передача без уведомления РКН по ч. 10 ст. 13.11 (100–300 тыс. ₽). Стратегия: внедрить обезличивание методом введения идентификаторов до передачи, оформить поручение обработки с иностранным провайдером, уведомить РКН о трансграничной передаче по ст. 12 ФЗ-152.

Сценарий 3. SIEM фиксирует инцидент, но логи за нужный период уже удалены. Ситуация: регламент хранения установлен на 30 дней, инцидент обнаружен через 45 дней. Доказательства принятых мер защиты отсутствуют. Вероятный исход: невозможность подготовить 72-часовой отчёт для РКН по Приказу №187 с полным описанием инцидента; риск квалификации как неполного уведомления по ч. 11 ст. 13.11 (1–3 млн ₽). Стратегия: установить дифференцированные сроки хранения — оперативные логи 30 дней, логи безопасности и аудита не менее 6 месяцев для УЗ-3 и не менее года для УЗ-1/2.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

Серверные логи с идентификаторами пользователей — полноценные персональные данные со всеми вытекающими обязанностями по 152-ФЗ. Срок их хранения нигде не закреплён единой нормой: он определяется принципом целесообразности (ст. 5 ФЗ-152), требованиями ФСТЭК по уровню УЗ (от 3 месяцев до года) и сроками давности по КоАП и ГК (до 3 лет). Хранение дольше задокументированной цели — самостоятельное нарушение; утечка через лог-инфраструктуру — штраф от 3 до 500 млн ₽ в зависимости от объёма и повторности.

Практика DATUM охватывает аудит лог-инфраструктуры в составе аудита соответствия 152-ФЗ, разработку политик хранения и регламентов обезличивания для ML-пайплайнов, сопровождение проверок РКН в IT-компаниях и SaaS-провайдерах.