Обезличивание логов для анализа
С 01.09.2025 вступили в силу правила обезличивания по приказу РКН (5 методов, обязательных для операторов, передающих данные в ЕИП НСУД), а с 01.07.2025 ужесточилась локализация по ч. 5 ст. 18 ФЗ-152. Для CISO это означает: любой лог-конвейер, затрагивающий ПДн граждан РФ, требует либо полного обезличивания до передачи, либо оформленного поручения обработки и российского облака. Этот материал разбирает, как выстроить обезличивание логов технически и юридически корректно, не ломая аналитику.
Когда логи становятся персональными данными?
Персональные данные по ст. 3 ФЗ-152 — любая информация, прямо или косвенно относящаяся к определённому физическому лицу. IP-адрес в логе веб-сервера косвенно идентифицирует пользователя — РКН последовательно квалифицирует его как ПДн. Email в access-логе, user_id, связанный с профилем, MSISDN в CDR-записях — аналогично. Даже хэш сессии, если он воспроизводимо вычисляется из известного email, не является обезличиванием по смыслу нормы.
Позиция РКН: данные считаются обезличенными только в том случае, если из них невозможно восстановить исходный субъект без дополнительного ключа, а ключ хранится отдельно и с ограниченным доступом. Хэш без соли, маска с сохранением длины строки или простое удаление одного поля при сохранении прочих — не соответствуют этому критерию.
На практике логи приложений содержат несколько уязвимых полей одновременно: IP + user_agent + timestamp с точностью до миллисекунды образуют уникальный отпечаток, идентифицирующий пользователя даже при удалении прямых идентификаторов. Это означает, что обезличивание логов для анализа должно затрагивать не одно поле, а всю совокупность квазиидентификаторов.
Какие требования ФЗ-152 и ФСТЭК применяются к логам в ИСПДн?
Если логи хранятся в информационной системе, обрабатывающей ПДн, они включаются в периметр этой ИСПДн. Уровень защищённости определяется по ПП РФ №1119 от 01.11.2012: категория данных (специальные, биометрические, общие, иные) × тип актуальных угроз × количество субъектов (порог 100 000). Для типичного SaaS с общими ПДн и угрозами 3-го типа — это УЗ-3 или УЗ-4. При специальных категориях (логи медицинского приложения с диагнозами) — УЗ-1 или УЗ-2 независимо от числа субъектов.
Именно подсистема РСБ создаёт коллизию: Приказ ФСТЭК №21 требует вести подробные журналы событий ИБ (входы, выходы, изменения прав, обращения к ПДн), а эти журналы сами содержат ПДн — идентификаторы пользователей, временны́е метки, IP. Передавать такие журналы во внешнюю SIEM-систему или облачный хранилище без мер защиты нельзя.
Для SaaS с мультиарендной архитектурой проблема усложняется: в одном лог-потоке перемешаны записи разных клиентов-операторов. Поставщик SaaS выступает лицом, осуществляющим обработку по поручению (ст. 6 п. 3 ФЗ-152), и обязан обеспечить изоляцию данных каждого оператора. Без поименованного поручения и без изоляции в логах — нарушение условий обработки.
Логи уходят в облако или SIEM без оформленного поручения?
Если CISO не может показать поручение обработки ПДн по ст. 6 ФЗ-152 для каждой внешней системы, принимающей логи, — это готовое основание для протокола РКН по ч. 1 ст. 13.11 КоАП. Штраф по ч. 1 — 150–300 тыс. ₽, но при утечке через этот же канал — ч. 12–14 с суммой от 3 до 15 млн ₽. Юристы DATUM проведут аудит обработки ПДн по чек-листу из 38 пунктов, включая проверку всех поручений для внешних систем, и выдадут план устранения нарушений с приоритетами.
Заказать аудит 152-ФЗОтветим за 2 часа · +7 (983) 510-38-76 · info@vitveteam.ru · Telegram
Как технически обезличить логи без потери аналитической ценности?
Пять методов, закреплённых приказом РКН, применяются к логам по-разному. Выбор метода зависит от того, какой аналитический вопрос должен оставаться решаемым после обезличивания.
Введение идентификаторов (псевдонимизация). IP-адрес и user_id заменяются на детерминированный псевдоним через HMAC-SHA256 с секретным ключом. Ключ хранится отдельно, в HSM или vault с ограниченным доступом. Аналитика сохраняет возможность строить воронки, сессионные цепочки и когортный анализ — при этом конкретный пользователь не раскрывается. Условие: ключ не должен попадать в аналитическую систему.
Обобщение и агрегация. Точный IP заменяется маской /24, временна́я метка округляется до 15 минут, точный user-agent усекается до браузер+ОС без версии. Этот метод необратим — восстановление невозможно даже при наличии ключа. Подходит для построения статистических отчётов и тренировки ML-моделей, где точная идентификация не нужна.
Декомпозиция. Лог разбивается на два потока: поведенческий (события, timestamp, параметры) и идентификационный (user_id, IP, email). Потоки хранятся в разных хранилищах с разным контролем доступа. ML-модель обучается только на поведенческом потоке. Этот метод технически сложнее, но позволяет сохранить возможность ручного расследования инцидентов по запросу службы ИБ.
Изменение состава и семантики. Из лог-записи удаляются поля, несущие прямой идентификатор, а смысловые поля (тип события, код ответа, URI без параметров) сохраняются. Применяется для потоков, где идентификация пользователя вообще не нужна для аналитики — например, мониторинг производительности.
Перемешивание. Значения атрибута перераспределяются между записями таким образом, что связь атрибута с конкретной записью разрывается. Применимо ограниченно — разрушает временну́ю последовательность, что делает его бесполезным для большинства лог-аналитических задач.
Для KII (объекты критической информационной инфраструктуры по 187-ФЗ) требования строже: обезличивание логов необходимо согласовывать в контексте мер защиты, предусмотренных ведомственными приказами. Передача логов КИИ в облако, в том числе российское, без отдельного согласования с ФСТЭК — риск предписания.
Что проверить до передачи логов в аналитическую систему
- Поручение обработки ПДн оформлено в письменном виде для каждой внешней системы (SIEM, облако, ML-платформа) по ст. 6 п. 3 ФЗ-152 — включает перечень операций, цели, срок и требования к защите.
- ИСПДн присвоен уровень защищённости по ПП РФ №1119 — определены актуальные угрозы, категория ПДн и число субъектов; документ утверждён и актуален.
- Применяется один или несколько методов обезличивания из приказа РКН; метод зафиксирован в модели угроз или техническом задании на ИСПДн.
- Облачная инфраструктура расположена в РФ (ч. 5 ст. 18 ФЗ-152): первичный сбор и хранение ПДн граждан РФ — только в российских ЦОД.
- Ключи псевдонимизации не попадают в аналитическую систему; доступ к ключам логируется отдельно с контролем по Приказу ФСТЭК №21 (группа ИАФ).
Какие сценарии нарушений встречаются на практике?
Сценарий 1. SaaS-компания отправляет сырые логи в иностранный SIEM. Ситуация: стартап использует облачный SIEM американского вендора для мониторинга инцидентов. Логи содержат IP и user_id российских пользователей. Поручения обработки нет, уведомление о трансграничной передаче в РКН не подавалось. Доказательства: при внеплановой проверке РКН запрашивает список систем обработки ПДн — он не совпадает с уведомлением. Вероятный исход: протокол по ч. 1 ст. 13.11 (150–300 тыс. ₽) + по ч. 8 за нарушение локализации (1–6 млн ₽) при хранении первичных данных за рубежом. Стратегия: перевести SIEM на российского провайдера или выстроить лог-прокси с обезличиванием на периметре до передачи за рубеж; оформить поручение и уведомление о трансграничке.
Сценарий 2. ML-команда обучает модель на production-логах. Ситуация: дата-сайентисты получили дамп логов рекомендательной системы для обучения модели персонализации. В логах — user_id, история кликов, сессии. Согласия на использование ПДн в целях ML отдельно не собирались; цель обработки в уведомлении РКН не указана. Доказательства: при запросе субъекта на ознакомление с данными выясняется, что его записи есть в обучающем наборе. Исход: нарушение принципа целевого ограничения по ст. 5 ФЗ-152 — обработка в целях, несовместимых с заявленными; протокол по ч. 1 ст. 13.11. Стратегия: до передачи логов в ML применить обобщение + псевдонимизацию; добавить цель «аналитика и улучшение сервиса» в уведомление РКН; зафиксировать в поручении, что обработчик не вправе реидентифицировать субъектов.
Сценарий 3. Утечка лог-архива через незащищённый S3-бакет. Ситуация: архив логов за 18 месяцев оказался в открытом доступе из-за ошибки конфигурации объектного хранилища. Содержимое — 4,2 млн записей с IP, user_id, email. До инцидента политика хранения логов не существовала, обезличивание не применялось. Исход: обязанность уведомить РКН за 24 часа по ч. 3.1 ст. 21 ФЗ-152; при числе субъектов >100 000 — ч. 14 ст. 13.11 (10–15 млн ₽); при повторности в течение трёх лет — оборотный штраф по ч. 15 (от 20 млн ₽). Стратегия: немедленное закрытие доступа, фиксация факта; юридическое сопровождение уведомления РКН; параллельный перевод лог-архива на обезличенное хранение.
Если инцидент с логами уже произошёл или CISO получил запрос РКН — у вас 24 часа на первичное уведомление (ч. 3.1 ст. 21 ФЗ-152). Срок не восстанавливается. DATUM возьмёт реагирование: первичное уведомление, координация расследования, отчёт за 72 часа.
Заказать аудит 152-ФЗКак это применяется на практике
Кейс 1. IT-компания (Сибирский ФО, осень 2025) использовала иностранный облачный SIEM для хранения логов SaaS-продукта с 200 тыс. российских пользователей. Аудит DATUM выявил отсутствие поручения обработки и нарушение локализации. В течение двух месяцев лог-конвейер был перестроен: введена псевдонимизация HMAC на периметре, данные переведены на российский облачный провайдер, оформлено поручение. До подачи уведомления о проверке РКН компания успела зафиксировать принятые меры — это позволило ограничиться предписанием вместо штрафа по ч. 8 ст. 13.11.
Кейс 2. Финтех-компания (Центральный ФО, начало 2026) обнаружила открытый S3-бакет с лог-архивом на 1,8 млн записей. DATUM подключился в течение часа: за 22 часа было направлено первичное уведомление в РКН, за 68 часов — отчёт о расследовании. Арбитражный суд региона учёл оперативность уведомления и отсутствие предшествующих нарушений при назначении штрафа по ч. 13 ст. 13.11; применение ст. 4.1 КоАП позволило снизить санкцию до нижней границы диапазона.
Услуги DATUM по теме
- Аудит соответствия 152-ФЗ — проверка лог-конвейеров, поручений, локализации, 38-пунктный чек-лист
- DPIA (оценка воздействия) — для обработки ПДн в ML-пайплайнах и новых аналитических систем
- Комплект ОРД под ключ — поручения обработки, политика, регламент реагирования на инциденты
Частые вопросы
1. Какой УЗ выбрать для SaaS?
Уровень защищённости определяется по ПП РФ №1119: пересечение категории ПДн (общие, специальные, биометрические), типа актуальных угроз (1–3) и числа субъектов (до или свыше 100 000). Для типового B2C SaaS с общими ПДн и угрозами 3-го типа при числе субъектов до 100 000 — УЗ-4; при превышении порога — УЗ-3. При наличии специальных категорий (здоровье, убеждения) — не ниже УЗ-2 независимо от числа субъектов. Уровень фиксируется в акте классификации ИСПДн и не пересматривается автоматически — только при изменении параметров системы.
2. Можно ли использовать иностранные облака?
Первичный сбор, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ должны осуществляться в базах данных на территории РФ (ч. 5 ст. 18 ФЗ-152, действует с 01.07.2025 в усиленной редакции). Передача уже собранных данных за рубеж допустима при выполнении условий ст. 12 ФЗ-152 (уведомление РКН о трансграничной передаче) и только в страны из перечня адекватной защиты либо при дополнительных гарантиях. Иностранное облако как основное хранилище логов с ПДн российских пользователей — нарушение ч. 5 ст. 18, штраф по ч. 8 ст. 13.11 составляет 1–6 млн ₽.
3. Что такое обезличивание для ML?
Обезличивание для ML — применение методов из приказа РКН (введён в действие с 01.09.2025) к обучающим данным таким образом, чтобы модель не могла восстановить конкретного субъекта. На практике: псевдонимизация user_id через HMAC с изолированным ключом + обобщение сетевых атрибутов (IP → /24, timestamp → 15-минутный слот) + удаление прямых идентификаторов. Обезличенные данные выходят из-под большинства требований ФЗ-152, но только если реидентификация действительно невозможна — простой хэш без соли этому критерию не удовлетворяет.
4. Кто оператор в мультиарендной SaaS?
В мультиарендной SaaS оператором ПДн конечных пользователей является клиент (tenant), а не поставщик платформы. Поставщик выступает лицом, осуществляющим обработку по поручению оператора в рамках ст. 6 п. 3 ФЗ-152. Это означает: для каждого tenant должно быть заключено поручение обработки с перечнем операций; поставщик не вправе использовать лог-данные разных tenants для своих целей без отдельного основания. Отсутствие поручений при мультиарендности — типовая находка при аудите.
5. Какие СЗИ обязательны?
Состав обязательных средств защиты информации определяется Приказом ФСТЭК №21 от 18.02.2013 применительно к установленному уровню защищённости. Для УЗ-4 обязательны меры из групп ИАФ, УПД, РСБ, АВЗ, ОЦЛ, ЗТС, ЗИС. Конкретные СЗИ — сертифицированные ФСТЭК продукты — выбираются по базовым наборам мер. При УЗ-1 и УЗ-2 требования существенно шире: добавляются группы СОВ (обнаружение вторжений), ЗСВ (виртуализация), ОДТ (отказоустойчивость). Самостоятельное определение адаптированного базового набора мер — задача модели угроз, которую утверждает CISO или уполномоченное подразделение.
Итог
Обезличивание логов для анализа — не опциональная мера, а требование ФЗ-152 при передаче лог-данных за периметр ИСПДн: в ML-пайплайн, SIEM, облако или аналитическую платформу. Без корректного применения методов по приказу РКН и без поручения обработки по ст. 6 любой из этих каналов становится основанием для протокола. При утечке через него — штраф от 3 до 15 млн ₽, при повторности — до 500 млн ₽.
DATUM сопровождает IT-компании и SaaS-продукты в выстраивании лог-конвейеров, соответствующих ФЗ-152: от классификации ИСПДн по ПП РФ №1119 и выбора методов обезличивания до оформления поручений обработки и подготовки к проверке РКН.
14 февраля 2029 года