ПДн администратора SaaS-аккаунта

Для технического директора SaaS-продукта вопрос персональных данных администраторов выглядит незначительным: email для входа, имя в профиле, IP в логах — что тут особенного. На практике эта связка создаёт полноценную информационную систему персональных данных с требованиями по защите, уведомлению РКН и оформлению документации. С 2025 года регулятор планомерно проверяет IT-компании по новым критериям, а суды начали формировать практику по ФЗ-420. В этой статье — как правильно квалифицировать данные администраторов, какой уровень защищённости определить, как оформить отношения с облачным провайдером и что проверить перед аудитом РКН.

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

Статья 3 ФЗ-152 определяет персональные данные как любую информацию, относящуюся к прямо или косвенно определённому физическому лицу. Администратор SaaS-аккаунта — конкретный человек, даже если он действует как представитель юрлица. Это означает, что следующие поля однозначно квалифицируются как ПДн:

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

Ключевой вопрос — не то, является ли конкретное поле «персональным», а то, позволяет ли совокупность полей идентифицировать человека. Связка «корпоративный email + роль в системе» уже достаточна для идентификации: вы знаете, кто этот человек, где работает и к каким данным имеет доступ.

Отдельно следует рассмотреть логирование. Журналы событий ИСПДн — обязательный элемент технической защиты по Приказу ФСТЭК №21 (мера РСБ: регистрация событий безопасности). Но эти журналы содержат строки вида «пользователь admin@company.ru выполнил действие X в 14:22». Это означает, что логи сами по себе — часть ИСПДн, и к ним применяются те же требования защиты, что и к основной базе пользователей. Хранение логов в незащищённом S3-бакете или их передача в стороннюю SIEM-систему без оформления поручения — нарушение ст. 19 и ст. 6 ФЗ-152.

Как определить уровень защищённости ИСПДн для SaaS-платформы?

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

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

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

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

Как оформить поручение обработки ПДн для облачного провайдера?

Большинство SaaS-платформ использует сторонние облака для хранения данных: российские (Яндекс Облако, Selectel, SberCloud) или зарубежные (AWS, GCP, Azure). С точки зрения ФЗ-152 облачный провайдер — это лицо, осуществляющее обработку ПДн по поручению оператора (ст. 6 п. 3 ФЗ-152). Без письменного договора поручения обработки провайдер хранит ваши пользовательские данные без правового основания.

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

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

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

Обезличивание ПДн администраторов для ML: что допускает Приказ РКН?

Обезличивание данных пользователей для обучения ML-моделей — распространённая практика в SaaS. Логи действий администраторов, паттерны использования функций, последовательности запросов — всё это ценный обучающий материал. Но если в логах содержатся email или имена, данные остаются персональными, и их нельзя использовать в обучении без дополнительных мер.

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

Для ML-задач наиболее применимы метод введения идентификаторов и агрегация. Конкретный сценарий: вы хотите обучить модель на истории действий администраторов. Заменяете email на UUID, удаляете имя и должность, оставляете временные метки и типы действий. UUID хранится в отдельной таблице (ключ соответствия) с ограниченным доступом. Обучающая выборка — только анонимизированная часть. Если ключ соответствия не компрометируется, данные перестают быть персональными.

Важный нюанс: метод обезличивания должен соответствовать требованиям Приказа РКН. Использование нестандартных или недостаточных методов — риск претензий со стороны регулятора при проверке. Перед запуском ML-пайплайна с историческими пользовательскими данными рекомендуется провести DPIA (оценку воздействия на ПДн) и зафиксировать применяемые методы обезличивания в технической документации.

Кто оператор при мультиарендной SaaS: платформа или клиент?

Это один из самых сложных вопросов архитектуры соответствия для SaaS-компаний. Разберём три типичных сценария.

Сценарий 1 — SaaS-платформа как обработчик. Клиент (компания) является оператором своих пользовательских данных. Платформа обрабатывает их по поручению на основании договора. В этом случае платформа обязана: соблюдать инструкции оператора, применять требуемые меры защиты, не обрабатывать данные в своих целях без согласования. Это наиболее распространённая модель для B2B SaaS — CRM, HRM, ERP-систем.

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

Сценарий 3 — совместные операторы. Часть данных (например, технические логи для поддержки) обрабатывается платформой в своих целях, другая часть (контент, созданный пользователем) — в целях клиента. Это смешанная модель, требующая отдельного разграничения в договоре.

Как это выглядит на практике: два сценария из работы IT-компаний

Кейс 1. IT-компания из Сибирского федерального округа (осень 2025) эксплуатировала мультиарендную SaaS-платформу для управления проектами с базой около 80 000 корпоративных пользователей. Данные хранились в российском облаке, но договор поручения обработки с провайдером отсутствовал. При внеплановой проверке РКН выявил отсутствие договора и несоответствие между заявленным в уведомлении числом субъектов и фактическим. По итогам — протокол по ч. 1 ст. 13.11 КоАП. Технический директор привлёк юристов на стадии составления возражений на протокол. Компания подтвердила факт устранения нарушения до рассмотрения дела, применила ст. 4.1.1 КоАП. Штраф в сотни тысяч рублей заменён на предупреждение.

Кейс 2. Разработчик облачной аналитической платформы (Северо-Западный ФО, начало 2026) использовал журналы действий администраторов (с email в незашифрованном виде) для обучения ML-модели рекомендаций. Модель была развёрнута в продакшн без DPIA и без применения методов обезличивания по Приказу РКН. После жалобы одного из клиентов-операторов РКН инициировал внеплановую проверку. Выявлено нарушение ст. 5 и ст. 13.1 ФЗ-152 (обработка данных в целях, несовместимых с исходными). Назначен штраф по ч. 1 ст. 13.11 КоАП. CTO инициировал срочный аудит и DPIA — это позволило зафиксировать план устранения и снизить вероятность повторного нарушения с оборотными последствиями.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

ПДн администраторов SaaS-аккаунта — полноценная ИСПДн с требованиями по УЗ, договорам поручения, локализации и защите. Три ключевых риска для CTO: неверно определённый уровень защищённости по ПП РФ №1119, отсутствие договора поручения с облачным провайдером и использование необезличенных пользовательских данных в ML-пайплайнах. Каждый из них при проверке РКН создаёт основание для протокола по ст. 13.11 КоАП.

DATUM сопровождает IT-компании и SaaS-разработчиков в вопросах соответствия 152-ФЗ: от определения УЗ и оформления ОРД до DPIA перед запуском ML-функций и защиты в арбитраже при получении протокола.

17 апреля 2029 года