API SaaS и ПДн

Большинство SaaS-продуктов обрабатывают персональные данные через API — регистрация, аутентификация, передача данных клиентам-арендаторам. До 30.05.2025 максимальный штраф за утечку через API не превышал 100 000 ₽. После вступления ФЗ-420 в силу потолок вырос до 500 млн ₽ при повторности. Эта статья разбирает, какой правовой режим применяется к SaaS с API, как определить уровень защищённости, когда нужно обезличивание для ML и кто несёт ответственность в мультиарендной архитектуре.

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

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

SaaS в B2B-сегменте чаще всего обрабатывает данные сотрудников клиентов — ФИО, email, телефон, должность. Это общие персональные данные. При угрозах типа 2 и базе до 100 000 субъектов — применяется УЗ-3. Если клиент-арендатор загружает медицинские или биометрические данные, категория повышается до специальной, и уровень защищённости меняется. CTO обязан предусмотреть механизм информирования о составе загружаемых данных при онбординге нового клиента.

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

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

В мультиарендной (multi-tenant) архитектуре возникает вопрос: кто является оператором персональных данных субъектов-пользователей клиента — сам клиент или SaaS-провайдер? Ответ зависит от того, кто определяет цели и способы обработки.

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

На практике SaaS-провайдеры нередко оказываются совместными операторами: они формируют технические параметры обработки (структуру баз, логирование, резервирование), что выходит за рамки чистого поручения. В этом случае требуется отдельное соглашение о совместной обработке с разграничением обязанностей. Без такого соглашения при утечке оба участника несут солидарную ответственность перед субъектом.

Отдельный вопрос — API-ключи и токены доступа. Если API-ключ клиента позволяет читать данные других арендаторов из-за уязвимости — это утечка, за которую отвечает SaaS-провайдер независимо от договора поручения. Логирование всех API-вызовов с привязкой к tenant_id — минимальное требование для разграничения ответственности при инциденте.

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

Обучение ML-моделей на реальных персональных данных без обезличивания — обработка ПДн в новых целях, не заявленных в уведомлении РКН и не предусмотренных согласием субъектов. Это нарушение принципа ограничения цели по ст. 5 ФЗ-152.

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

Для SaaS с ML-функциональностью правильная архитектура выглядит так: сырые ПДн хранятся в основной ИСПДн с соблюдением УЗ; перед передачей в обучающий pipeline применяется один из методов обезличивания; результат — обезличенный датасет, на который нормы об ПДн не распространяются. Отсутствие этого этапа означает, что ML-пайплайн является частью ИСПДн и на него распространяются все требования ФСТЭК.

Можно ли использовать иностранные облака для хранения ПДн граждан РФ?

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

AWS, GCP, Azure имеют российские регионы или партнёрские решения. Использование иностранного облачного провайдера допустимо при выполнении двух условий: физические серверы с ПДн граждан РФ находятся в РФ, и провайдер не передаёт данные за рубеж без уведомления РКН по ст. 12 ФЗ-152. Использование зарубежных аналитических инструментов (Datadog, New Relic, Splunk) для обработки логов, содержащих ПДн — отдельная проблема трансграничной передачи.

Для SaaS с глобальной клиентской базой применяется принцип разделения хранилищ: данные граждан РФ — в ИСПДн на российском хостинге, данные иностранных субъектов — в зарубежной инфраструктуре. API-роутинг реализует автоматическое определение юрисдикции субъекта при регистрации. При использовании единого глобального облака без разделения — риск по ч. 8 ст. 13.11.

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

Кейс 1. B2B-платформа автоматизации HR-процессов (Центральный ФО, осень 2025). CTO не разграничил роли оператора и обработчика в договорах с клиентами. После утечки через уязвимость в API (около 15 000 субъектов) РКН возбудил дело по ч. 13 ст. 13.11 КоАП. Отягчающим обстоятельством стало отсутствие договоров поручения: платформа была признана самостоятельным оператором, а не обработчиком. Штраф составил несколько миллионов рублей; суд отказал в применении ст. 4.1.1 КоАП, поскольку юрлицо не являлось микропредприятием.

Кейс 2. SaaS-провайдер в сегменте EdTech (Приволжский ФО, начало 2026). ML-модуль платформы обучался на реальных ПДн студентов без обезличивания. При плановой проверке РКН выявил обработку данных в целях, не указанных в уведомлении. Нарушение квалифицировано по ч. 1 ст. 13.11 КоАП. Одновременно выдано предписание об устранении. CTO в течение 30 дней реализовал псевдонимизацию на уровне ETL-пайплайна — предписание исполнено, повторная проверка нарушений не выявила.

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

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

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

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

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

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

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

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

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

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

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

5. Какие СЗИ обязательны для SaaS по Приказу ФСТЭК №21?

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

Итог

Архитектурные решения в SaaS — выбор облачного провайдера, схема мультиарендности, наличие ML-пайплайна — напрямую определяют правовой режим обработки ПДн и набор обязательных мер защиты. С 30.05.2025 цена архитектурной ошибки выросла: штраф за утечку через API от 10 000 субъектов составляет 5–10 млн ₽, повторная — до 500 млн ₽ по оборотному составу.

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

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