Session ID и ПДн

Session ID в большинстве архитектур хранится в логах, передаётся в заголовках HTTP и Redis-кластерах, нередко попадает в аналитические системы. Если сессия привязана к учётной записи пользователя — идентификатор становится персональными данными по ст. 3 ФЗ-152. Для CISO это означает: логи с session ID подпадают под требования об уровнях защищённости по ПП РФ №1119, меры защиты по Приказу ФСТЭК №21, а утечка через брешь в логировании — под штрафы ч. 12–15 ст. 13.11 КоАП с 30.05.2025. Ниже — разбор нормативной логики, практика квалификации session ID, выбор УЗ для SaaS и требования к журналам аудита.

Почему session ID относится к персональным данным?

Статья 3 ФЗ-152 определяет персональные данные как любую информацию, относящуюся прямо или косвенно к определённому или определяемому физическому лицу. Session ID сам по себе — случайная строка. Однако в момент, когда он связан с пользовательской сессией (cookie, заголовок Authorization, запись в Redis или базе данных), он позволяет идентифицировать субъекта через совокупность атрибутов: IP-адрес, временную метку, идентификатор устройства и историю запросов.

Роскомнадзор в своей практике исходит из принципа «совокупной идентификации»: если два и более технических идентификатора в связке однозначно указывают на физическое лицо, вся совокупность — персональные данные. Session ID + user_id в логе — именно такой случай. Аналогичная логика применяется к cookies, что подтверждается позицией РКН по маркерам аналитических систем.

Практический вывод: если session ID присутствует в логах приложения, системных журналах, телеметрии или передаётся в облачные аналитические системы — он обрабатывается как ПДн. Это влечёт обязанность определить правовое основание обработки по ст. 6 ФЗ-152, установить уровень защищённости информационной системы и реализовать меры по Приказу ФСТЭК №21.

Как выбрать уровень защищённости (УЗ) для SaaS с session ID?

Постановление Правительства РФ №1119 от 01.11.2012 устанавливает четыре уровня защищённости информационных систем персональных данных (ИСПДн). Выбор уровня определяется тремя параметрами: категория обрабатываемых ПДн, тип актуальных угроз и число субъектов.

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

Угрозы 2-го типа связаны с наличием недокументированных возможностей в системном ПО. Для большинства SaaS-продуктов на стандартных стеках (Linux, PostgreSQL, Kubernetes) актуальны угрозы 3-го типа, что при общих ПДн и менее 100 000 субъектов даёт УЗ-3. Однако если продукт обрабатывает данные в интересах государственных органов или работает в секторе КИИ по ФЗ-187, оценка угроз усложняется и требует отдельной модели угроз.

Session ID как технический идентификатор не меняет базовую категорию ПДн, но меняет риск-профиль: компрометация session ID без маскирования в логах — это прямой вектор атаки с захватом сессии, что квалифицируется как инцидент с ПДн и запускает 24-часовой таймер уведомления РКН по ч. 3.1 ст. 21 ФЗ-152.

Что требует Приказ ФСТЭК №21 для защиты session ID?

Приказ ФСТЭК России №21 от 18.02.2013 определяет состав и содержание организационных и технических мер защиты ПДн. Меры сгруппированы в 15 групп: от идентификации и аутентификации (ИАФ) до обеспечения целостности (ОЦЛ) и защиты информационной среды (ЗИС). Базовый набор мер зависит от установленного УЗ.

Для session ID принципиальны три группы мер. Первая — регистрация событий безопасности (РСБ): все операции с сессиями (создание, обновление, завершение, попытки несанкционированного использования) должны фиксироваться в журнале аудита с временной меткой. Вторая — управление доступом (УПД): session ID не должен передаваться в открытом виде в URL-параметрах и должен иметь механизм ротации. Третья — защита носителей информации (ЗНИ): логи, содержащие session ID, подпадают под требования к носителям ПДн, включая контроль физического доступа и шифрование при хранении.

Отдельный вопрос — логирование в облачных средах. Если SaaS развёрнут в российском облаке (облако в РФ по ч. 5 ст. 18 ФЗ-152), журналы аудита с session ID хранятся на территории РФ. Если журналы уходят в SIEM-систему, размещённую за рубежом, — это трансграничная передача ПДн, требующая отдельного уведомления РКН по ст. 12 ФЗ-152.

Как обезличить session ID для ML-задач?

Использование логов с session ID для обучения ML-моделей или A/B-тестирования — типовая практика в SaaS-продуктах. Проблема: передача таких логов дата-команде без обезличивания означает обработку ПДн в новых целях, несовместимых с исходными (принцип ст. 5 ФЗ-152). Это требует либо отдельного согласия субъектов, либо надлежащего обезличивания.

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

Практически корректная схема для ML-пайплайна выглядит так: в production-среде session ID заменяется на стабильный псевдоним (токен), привязанный к user_id через таблицу соответствия, доступную только авторизованному сервису. Дата-команда работает исключительно с псевдонимами. Таблица соответствия хранится отдельно и не передаётся в аналитические среды. При таком подходе аналитический датасет содержит обезличенные данные, и передача дата-команде не создаёт нарушений ст. 5 и ст. 6 ФЗ-152.

Кто несёт ответственность при мультиарендной SaaS-архитектуре?

В мультиарендной (multi-tenant) SaaS-системе session ID одновременно циркулируют в инфраструктуре провайдера и логической среде каждого арендатора. Вопрос о том, кто является оператором ПДн, принципиален для распределения ответственности по ст. 13.11 КоАП.

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

Критическая точка: если договор между SaaS-провайдером и арендатором не содержит явного условия о поручении обработки ПДн — оба участника могут быть признаны самостоятельными операторами. Это означает отдельные обязательства по уведомлению РКН (ст. 22 ФЗ-152) и отдельную ответственность при инциденте. На практике большинство российских SaaS-договоров не содержат надлежащего условия о поручении, что создаёт системный правовой риск.

Как применяются штрафы за утечку session ID на практике?

С 30.05.2025 ст. 13.11 КоАП действует в редакции ФЗ-420 от 30.11.2024. Размер штрафа за утечку зависит от числа затронутых субъектов: от 1 000 до 10 000 — 3–5 млн ₽ (ч. 12), от 10 000 до 100 000 — 5–10 млн ₽ (ч. 13), более 100 000 — 10–15 млн ₽ (ч. 14). При повторной утечке — оборотный штраф по ч. 15: 1–3% совокупной годовой выручки, не менее 20 млн ₽ и не более 500 млн ₽.

Дополнительный риск — неуведомление РКН об инциденте. Если CISO не направил первичное уведомление в течение 24 часов с момента обнаружения утечки (ч. 3.1 ст. 21 ФЗ-152, Приказ РКН №187), штраф по ч. 11 ст. 13.11 составит 1–3 млн ₽ отдельно от основного. Срок не восстанавливается.

Кейс 1. IT-компания (Сибирский ФО, весна 2025) обрабатывала session ID в облачном SIEM без соглашения о поручении обработки. После хакерской атаки через уязвимость в агенте логирования утекли session ID совместно с user_id — порядка 15 000 субъектов. CISO направил уведомление в РКН через 31 час с момента обнаружения — срок 24 ч нарушен. Компания получила два протокола: по ч. 13 ст. 13.11 (утечка 10 000–100 000 субъектов) и по ч. 11 ст. 13.11 (нарушение срока уведомления). Суд назначил штрафы в нижней части диапазона с учётом первичности нарушения и принятых мер после инцидента.

Кейс 2. Ссылаясь на реестр практики: в деле о реагировании на утечку данных образовательной платформы (Центральный ФО, начало 2026) технический директор совместно с юристами подготовил первичное уведомление РКН за 19 часов и представил 72-часовой отчёт с описанием вектора атаки через компрометацию session store. Арбитражный суд, рассматривая дело по ч. 12 ст. 13.11, применил ст. 4.1.1 КоАП и заменил штраф предупреждением с учётом оперативности и статуса первичного нарушения. ⚠️ Конкретный номер дела и точная дата уточняются менеджером при публикации.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

Session ID — персональные данные в момент, когда он связан с идентифицируемым пользователем. Это означает обязанность классифицировать ИСПДн по ПП РФ №1119, реализовать меры по Приказу ФСТЭК №21, заключить соглашение о поручении обработки с облачными провайдерами и SIEM-операторами, а также обезличивать идентификаторы перед передачей в ML-пайплайны.

DATUM сопровождает IT-компании и SaaS-провайдеров при классификации ИСПДн, подготовке модели угроз, выстраивании политики логирования и реагировании на инциденты в режиме 24/72 часов по Приказу РКН №187.