Cookie ID в логах

CISO сталкивается с одной и той же ситуацией: разработчики пишут в лог всё подряд — session_id, user_agent, IP и cookie. Юридически каждый из этих идентификаторов в связке с другими данными становится персональными данными по ст. 3 ФЗ-152. С 30.05.2025 ст. 13.11 КоАП насчитывает 18 частей, а ст. 272.1 УК действует с 11.12.2024. В этом материале разобраны три вопроса: когда cookie ID в логах — ПДн, какой уровень защищённости требуется и как выстроить обезличивание, чтобы выйти из-под регуляторной нагрузки.

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

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

На практике это означает следующее: если в логе есть строка вида 2025-11-03 14:22:01 | user_cookie=abc123 | ip=93.180.x.x | action=checkout и у оператора есть база, где abc123 привязан к аккаунту, — это ПДн. Аргумент «мы не знаем, кто это» не работает, когда инструменты сопоставления существуют внутри инфраструктуры.

Три признака, при наличии хотя бы одного cookie ID в логе образует ПДн:

• cookie связан с авторизованной сессией (session cookie после логина);
• cookie хранится дольше сессии и используется для трекинга поведения (persistent cookie);
• cookie передаётся сторонним аналитическим сервисам вместе с другими атрибутами пользователя.

Если ни одного из трёх признаков нет и cookie — анонимный технический идентификатор без возможности сопоставления — правовой нагрузки нет. Но это редкий случай для реальных продуктов.

Какой уровень защищённости ИСПДн требуется для SaaS с cookie-логами?

Уровень защищённости определяется по ПП РФ №1119 от 01.11.2012. Матрица строится по трём параметрам: категория ПДн, тип актуальных угроз и число субъектов. Cookie ID в логах — это, как правило, иные категории ПДн (не специальные и не биометрические), что переводит систему в диапазон УЗ-3 или УЗ-4.

Для большинства SaaS-продуктов с cookie-логами актуален следующий расчёт:

• Категория: иные ПДн (cookie без медицинских, финансовых или биометрических данных).
• Угрозы: тип 2 или тип 3. Тип 2 предполагает недекларированные возможности в системном ПО; тип 3 — только в прикладном. Большинство облачных SaaS работает с угрозами 3-го типа, но CISO обязан это задокументировать.
• Субъекты: если более 100 000 — автоматически УЗ-3 при угрозах 2-го типа.

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

Типичная ошибка CISO: определение УЗ без документирования модели угроз. РКН при проверке запросит именно документ о модели угроз — без него нет обоснования выбранного уровня, а значит, нет и подтверждения выполнения требований ст. 19 ФЗ-152.

Как выстроить обезличивание cookie ID для ML без нарушения 152-ФЗ?

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

Для cookie-логов применимы два метода на практике:

• Введение идентификаторов: cookie ID заменяется псевдонимом по таблице соответствий, которая хранится отдельно с ограниченным доступом. ML-модель обучается на псевдонимах, таблица соответствий к обучению не допускается.
• Обобщение и агрегация: вместо отдельных cookie-событий в лог пишется агрегированный профиль поведения — без привязки к конкретному идентификатору. Обучение модели на агрегатах не требует обработки ПДн в юридическом смысле.

Критическое условие: метод обезличивания должен быть задокументирован в политике обработки ПДн и в техническом описании ИСПДн. «Мы хешируем cookie» — не документация. Нужен приказ о применяемом методе обезличивания, описание процедуры и контроль за таблицей соответствий.

Что означает мультиарендность SaaS для поручения обработки ПДн?

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

Типичная схема: корпоративный клиент (арендатор) является оператором ПДн своих пользователей; SaaS-вендор обрабатывает эти данные по поручению. Это означает:

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

Если SaaS-вендор самостоятельно использует cookie-логи арендаторов для своей аналитики или обучения моделей — он переходит из статуса обработчика в статус оператора. Это меняет всю регуляторную нагрузку: уведомление РКН по ст. 22, самостоятельная политика обработки ПДн, отдельные правовые основания.

Практические сценарии: что происходит при проверке РКН

Сценарий 1. SaaS без договора поручения и с cookie-логами в иностранном облаке. РКН при плановой проверке запрашивает документы об инфраструктуре. CISO предоставляет схему: primary database — AWS Frankfurt, логи — Elasticsearch Cloud EU. Инспектор составляет протокол по ч. 8 ст. 13.11 (нарушение локализации): штраф для юрлица 1–6 млн ₽. Дополнительно — протокол по ч. 1 ст. 13.11 за отсутствие правового основания обработки в логах. Параллельно — протокол по ч. 10 ст. 13.11 за неуведомление РКН о намерении осуществлять обработку ПДн: 100–300 тыс. ₽. Стратегия: договор поручения ретроактивно не спасает, но снижает риск при оспаривании; переезд в российское облако до проверки — единственная защита от ч. 8.

Сценарий 2. Утечка ML-датасета с необезличенными cookie-профилями. Датасет для обучения рекомендательной модели выгружается инженером на личный ноутбук. Ноутбук скомпрометирован. Датасет содержит 150 000 уникальных cookie ID с историей поведения. CISO обнаруживает инцидент через 6 часов. По ч. 3.1 ст. 21 ФЗ-152 и Приказу РКН №187 у него 24 часа на первичное уведомление и 72 часа на отчёт. Если уведомление направлено в срок и датасет признан частично обезличенным — квалификация может сдвинуться с ч. 14 (10–15 млн ₽) к ч. 12 (3–5 млн ₽) или меньшему составу. Стратегия: зафиксировать факт инцидента, сразу направить юристу, уведомить РКН через форму на pd.rkn.gov.ru.

Сценарий 3. Аудит перед выходом на корпоративный рынок. SaaS-стартап готовится к B2B-продажам. Корпоративные клиенты требуют подтверждение соответствия 152-ФЗ. CISO проводит предварительный аудит и обнаруживает: модель угроз не составлена, уровень защищённости не определён, договор поручения отсутствует в шаблоне, cookie-логи хранятся 12 месяцев без правового обоснования. Стоимость устранения — порядка 200–400 тыс. ₽ (ОРД, обновление архитектуры логирования, DPIA при необходимости). Альтернатива — потеря корпоративных контрактов или штраф при проверке. Стратегия: аудит до начала продаж экономит время на переделку архитектуры после.

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

Кейс 1. IT-компания (Северо-Западный ФО, осень 2025): SaaS-платформа для управления маркетинговыми рассылками хранила cookie-логи пользователей арендаторов в облаке на серверах за рубежом. Договор поручения с арендаторами отсутствовал. После плановой проверки РКН CISO получил два протокола — по нарушению локализации и за отсутствие правового основания. Штраф по совокупности составил несколько миллионов рублей. До вынесения постановления компания перенесла логирование в российское облако и заключила типовые договоры поручения — это было учтено судом как смягчающее обстоятельство.

Кейс 2. В деле об утечке ML-датасета рекомендательного сервиса (Центральный ФО, начало 2026): датасет содержал необезличенные cookie-профили более 10 000 субъектов. CISO направил первичное уведомление в РКН за 20 часов после обнаружения, через 68 часов — отчёт с описанием мер. Арбитражный суд региона при рассмотрении дела учёл оперативность реагирования и применил минимальный размер санкции по ч. 12 ст. 13.11 КоАП. Ключевым аргументом стало наличие задокументированной процедуры реагирования на инциденты — она подтвердила, что нарушение не было результатом системного игнорирования требований. ⚠️ Конкретный номер дела и точная сумма — менеджер уточняет при публикации.

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

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

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

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

Для большинства SaaS-платформ с иными ПДн (не специальными и не биометрическими) и числом субъектов до 100 000 при угрозах 3-го типа применяется УЗ-4 по ПП РФ №1119. Если субъектов более 100 000 или актуальны угрозы 2-го типа — УЗ-3, который требует сертифицированных СЗИ по отдельным группам мер Приказа ФСТЭК №21. Выбор уровня обязан быть задокументирован в модели угроз — без этого документа любой выбор уязвим при проверке РКН.

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

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

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

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

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

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

5. Какие СЗИ обязательны при УЗ-3 для ИСПДн с cookie-данными?

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

Итог

Cookie ID в логах образует ПДн при наличии средств сопоставления с субъектом. Уровень защищённости ИСПДн для SaaS-платформы определяется по ПП РФ №1119 и требует задокументированной модели угроз. Обезличивание по ст. 13.1 ФЗ-152 — рабочий инструмент снижения регуляторной нагрузки для ML, но только при корректном применении одного из пяти методов РКН и невозможности деобезличивания.

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