Учётные записи пользователей SaaS

С 2025 года регуляторная нагрузка на IT-продукты выросла кратно. Обновлённая ст. 13.11 КоАП, введённая ФЗ-420 от 30.11.2024, переводит разговор об учётных записях из категории «технический вопрос» в категорию «финансовый риск». Ниже — разбор того, как квалифицировать данные учётных записей, выбрать уровень защищённости, выстроить мультиарендную архитектуру и сохранить возможность обучать ML-модели без нарушения ФЗ-152.

Какие данные учётных записей SaaS считаются персональными?

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

Прямые идентификаторы: имя, фамилия, email-адрес, номер телефона, ИНН, СНИЛС, паспортные данные — если они собираются при регистрации или для выставления счёта. Косвенные идентификаторы: IP-адрес, user-agent, cookie-идентификаторы, device fingerprint, идентификатор сессии, история действий в интерфейсе. Каждый из них в связке с другими данными позволяет установить личность пользователя.

Логи активности пользователей — отдельная зона риска. Строка вида «userId=4721, action=export, timestamp=…» — это ПДн, если userId однозначно привязан к физическому лицу. РКН последовательно придерживается позиции: техническое разделение хранилища не освобождает от требований ФЗ-152, если деанонимизация возможна.

Дополнительная сложность — биометрия. Если в SaaS реализована аутентификация по лицу или голосу, применяется ст. 11 ФЗ-152: обработка биометрических ПДн без письменного согласия недопустима. Утечка биометрии квалифицируется по ч. 17 ст. 13.11 КоАП — штраф для юрлица 15–20 млн ₽.

Как выбрать уровень защищённости для SaaS по ПП РФ №1119?

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

Категории данных:

• Специальные категории (ст. 10 ФЗ-152): здоровье, расовая принадлежность, религиозные убеждения, судимость — автоматически подтягивают более высокий УЗ.
• Биометрические ПДн (ст. 11 ФЗ-152): отдельный трек с обязательным письменным согласием.
• Общедоступные ПДн: имя, email, должность — базовый УЗ.
• Иные категории — промежуточный вариант.

Типы угроз по ПП РФ №1119:

• Угрозы 1-го типа — недокументированные возможности в системном ПО (актуальны для критической инфраструктуры, КИИ по ФЗ-187).
• Угрозы 2-го типа — недокументированные возможности в прикладном ПО.
• Угрозы 3-го типа — только внешние атаки без недокументированных возможностей в ПО (типовой SaaS без КИИ-статуса).

Порог числа субъектов — 100 000. Если SaaS обрабатывает данные более 100 000 пользователей, уровень защищённости растёт на одну ступень по сравнению с тем же набором параметров при меньшей базе.

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

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

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

Мультиарендность (multi-tenancy) создаёт правовую неопределённость, которую регулятор трактует не в пользу вендора. Суть проблемы: на одной платформе работают десятки клиентов-организаций, каждая из которых загружает данные своих сотрудников или клиентов.

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

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

Ответственность за утечку через подрядчика несёт оператор-клиент — это устойчивая позиция судебной практики (case_generic_subpodryad). Вендор SaaS, в свою очередь, несёт ответственность за технические меры, предусмотренные договором поручения.

Как соблюсти требования локализации при использовании облачных провайдеров?

Часть 5 ст. 18 ФЗ-152 обязывает операторов при записи, систематизации, накоплении, хранении, уточнении и извлечении ПДн граждан РФ использовать базы данных, расположенные в России. Требование действует с 2015 года, но правоприменение усилилось после ужесточений 2025 года.

Для SaaS это означает: основная база пользовательских данных должна физически находиться на серверах в РФ. Облачные провайдеры AWS, Azure, GCP — если их датацентры расположены за рубежом — не подходят для первичного хранения. Это не запрет на использование иностранных облаков вообще: обработка обезличенных данных или технические компоненты (CDN, кэши) без ПДн под ч. 5 ст. 18 не подпадают.

Практические варианты соответствия:

• Перенести базу данных с ПДн в российский датацентр (Yandex Cloud, VK Cloud, Selectel, МТС Cloud, арендованный dedicated-сервер у российского хостера).
• Использовать гибридную архитектуру: ПДн — в РФ, аналитика на обезличенных данных — в любом облаке.
• При трансграничной передаче в страны без адекватной защиты — уведомить РКН до начала передачи (ст. 12 ФЗ-152) и получить разрешение.

Нарушение требования локализации квалифицируется по ч. 8 ст. 13.11 КоАП — штраф для юрлица от 1 до 6 млн ₽. Повторное нарушение по ч. 9 — от 6 до 18 млн ₽.

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

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

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

Утверждены пять методов обезличивания:

• Введение идентификаторов — замена прямых идентификаторов (имени, email) на псевдонимы без сохранения таблицы соответствия в том же контуре.
• Изменение состава или семантики — удаление или трансформация атрибутов, позволяющих установить личность.
• Декомпозиция — разбиение набора данных на части, каждая из которых не позволяет идентифицировать субъекта.
• Перемешивание — перестановка значений атрибутов между записями.
• Обобщение (агрегация) — замена точных значений диапазонами или агрегатами (возраст → возрастная группа, геолокация → регион).

Критически важно: обезличивание должно быть необратимым в рабочем контуре. Если рядом хранится таблица соответствия pseudoID → userID, данные юридически остаются ПДн. Это типовая ошибка в ML-пайплайнах: псевдонимизация без уничтожения связки не считается обезличиванием по российскому праву.

Логи системных событий (access log, audit trail) также могут содержать ПДн, если позволяют идентифицировать пользователя. Хранение таких логов требует либо их обезличивания, либо включения в реестр обрабатываемых ПДн с соответствующим правовым основанием.

Типовые сценарии нарушений и их последствия

Сценарий 1. SaaS хранит пользовательские данные в AWS eu-west без уведомления РКН о трансграничной передаче.

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

Сценарий 2. Утечка учётных записей через уязвимость в API.

Ситуация: хакер через незакрытую уязвимость IDOR получает доступ к 15 000 учётных записей (email, хэши паролей, телефоны). Инцидент обнаружен командой безопасности через 6 часов. Данные — иные категории ПДн (не спецкатегория). У компании нет регламента реагирования на инциденты, уведомление в РКН за 24 часа не подаётся. Исход: штраф за неуведомление по ч. 11 ст. 13.11 КоАП от 1 до 3 млн ₽ плюс штраф за саму утечку по ч. 13 (от 5 до 10 млн ₽ за 10 000–100 000 субъектов). Стратегия: выстроить SIEM-процесс фиксации инцидентов и заранее подготовить шаблон первичного уведомления по Приказу РКН №187.

Сценарий 3. ML-модель обучена на необезличенных пользовательских данных.

Ситуация: дата-инженеры выгружают production-данные (email, история действий, user_id) в S3-бакет для обучения рекомендательной модели. Согласие пользователей на обработку данных в целях ML отсутствует. При аудите юридический советник компании выявляет нарушение ст. 5 ФЗ-152 (несовместимость целей) и ст. 9 (отсутствие согласия на новую цель). Исход: штраф по ч. 1 ст. 13.11 (150–300 тыс. ₽) и предписание об уничтожении датасета. Стратегия: обезличить данные по методам Приказа РКН до выгрузки или получить отдельное согласие на обработку в целях улучшения сервиса.

Как это выглядит в судебной практике

Кейс 1. IT-компания (Северо-Западный ФО, лето 2025): вендор SaaS для HR-автоматизации хранил данные 40 000 пользователей клиентов в облаке на серверах в ЕС без поручения на обработку и без уведомления РКН о трансграничной передаче. После внеплановой проверки РКН составлен протокол по ч. 8 ст. 13.11 КоАП. В арбитраже компания представила план миграции данных в российский датацентр и частично выполненные технические меры по УЗ-3. Штраф снижен до нижней границы диапазона. Заключение: наличие плана устранения нарушений фиксируется как смягчающее обстоятельство по ст. 4.1 КоАП.

Кейс 2. Из публичной практики: в деле АС Москвы (№ А40-351064/2025, РЭШ) за утечку более 100 000 субъектов суд применил ч. 14 ст. 13.11 КоАП. Несмотря на масштаб утечки, штраф был снижен из-за статуса субъекта. Это показывает: категория субъекта (микропредприятие, социально значимая организация) влияет на итоговый размер санкции, но не отменяет ответственности. Для коммерческих SaaS-компаний без специального статуса аналогичное нарушение означало бы штраф от 10 до 15 млн ₽ без смягчения.

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

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

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

1. Какой уровень защищённости выбрать для SaaS с данными корпоративных пользователей?

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

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

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

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

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

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

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

5. Какие технические средства защиты обязательны по Приказу ФСТЭК №21?

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

Итог

Учётные записи пользователей SaaS — не просто технические объекты, а персональные данные с полным спектром обязанностей оператора по ФЗ-152. Неправильная квалификация архитектуры хранения, отсутствие договора поручения с клиентами или обезличивания в ML-пайплайне — каждый из этих пробелов создаёт основание для штрафа от 150 тыс. до 18 млн ₽ по ст. 13.11 КоАП в редакции с 30.05.2025.

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