Прозрачность SaaS-провайдера

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

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

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

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

Для CTO это означает следующее: договор с каждым клиентом SaaS должен содержать явный перечень действий с данными, цели, срок, меры защиты и обязанность провайдера не обрабатывать ПДн за пределами инструкций клиента. Отсутствие такого договора — основание для штрафа по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽), а при повторности — по ч. 1.1 (300–500 тыс. ₽).

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

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

Типичные варианты для SaaS:

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

Для большинства B2B SaaS-платформ, работающих с контактными данными сотрудников клиентов, применим УЗ-3 или УЗ-4. Самостоятельное занижение уровня без документированной оценки угроз — типичная причина предписаний по итогам проверок РКН. Определение типа угроз должно быть оформлено актом с обоснованием: почему угрозы 1-го типа неактуальны для конкретной архитектуры.

Как использовать иностранные облака и не нарушить локализацию?

Часть 5 ст. 18 ФЗ-152 обязывает оператора при сборе, систематизации, накоплении, хранении, уточнении и извлечении ПДн граждан РФ использовать базы данных, расположенные в России. С 01.07.2025 (ФЗ-233) ограничения ужесточились: первичная запись ПДн гражданина РФ должна происходить исключительно в российской базе данных.

Это означает для SaaS-провайдера следующее:

• Основная база данных с ПДн российских субъектов — только в инфраструктуре на территории РФ.
• Репликация в зарубежные облака (AWS, Azure, GCP) допустима только после записи в российскую базу и только для целей, не связанных с основной обработкой.
• Использование Salesforce, HubSpot, Zendesk для обработки ПДн российских клиентов как основной системы — нарушение ч. 5 ст. 18 ФЗ-152.
• Штраф за нарушение локализации по ч. 8 ст. 13.11 КоАП — от 1 до 6 млн ₽; при повторности по ч. 9 — от 6 до 18 млн ₽.

Практическое решение для SaaS с международной архитектурой: мастер-база в российском облаке (Яндекс.Облако, VK Cloud, SberCloud), репликация для аналитики — за рубежом, только в обезличенном виде с применением методов по Приказу РКН об обезличивании. Такая схема требует документированного технического обоснования и договора поручения с российским cloud-провайдером.

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

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

Приказ РКН об обезличивании закрепляет пять методов:

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

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

Логирование как ПДн: где граница?

Логи приложений, содержащие IP-адреса, идентификаторы сессий, user-agent, временные метки действий конкретных пользователей — это персональные данные по позиции РКН. Аналогичная позиция закреплена в решениях европейских регуляторов и принята российским правоприменением по аналогии. Это означает, что к логам применяются требования ст. 19 ФЗ-152 и соответствующего УЗ.

Практические последствия для SaaS:

• Срок хранения логов должен быть обоснован и ограничен: хранение «на всякий случай» без определённого срока нарушает принцип ст. 5 ФЗ-152 о необходимости уничтожения ПДн при достижении цели обработки.
• Передача логов с ПДн в SIEM иностранного вендора (Splunk, Datadog) — трансграничная передача, требующая уведомления РКН по ст. 12 ФЗ-152.
• Доступ DevOps-команды к production-логам с ПДн — обработка персональных данных, требующая включения в политику и ограничения на основе принципа минимальности доступа (УПД в Приказе ФСТЭК №21).
• Для КИИ (критической информационной инфраструктуры по 187-ФЗ) требования к логированию дополнительно регулируются приказами ФСТЭК по защите КИИ.

Типовые сценарии для CTO: разбор ситуаций

Сценарий 1. SaaS без чёткого договора поручения. Ситуация: B2B-платформа (Центральный ФО, лето 2025) обрабатывала ПДн сотрудников 200 корпоративных клиентов. Договоры с клиентами содержали только общую оговорку о конфиденциальности. При проверке РКН установил, что провайдер фактически определял сроки хранения и методы резервирования — то есть принимал самостоятельные решения об обработке. Провайдеру предъявлен протокол по ч. 1 ст. 13.11 КоАП. Стратегия: разработать типовой договор поручения по п. 3 ч. 1 ст. 6 ФЗ-152 с явным перечнем действий, получить подписи от всех клиентов, документировать, что решения об обработке принимает клиент.

Сценарий 2. ML-модель на необезличенных ПДн. Ситуация: SaaS-провайдер (Северо-Западный ФО, осень 2025) обучал рекомендательную модель на транзакционных данных клиентов без применения обезличивания. Данные были псевдонимизированы (заменены ID), но оставался ключ соответствия. При жалобе субъекта РКН запросил описание обработки. Провайдер не смог подтвердить, что данные не позволяют идентифицировать субъектов. Исход: предписание об устранении нарушений, штраф в диапазоне сотен тысяч рублей по ч. 1 ст. 13.11. Стратегия: применить метод введения идентификаторов с уничтожением ключа соответствия до начала обучения; задокументировать метод обезличивания по Приказу РКН.

Сценарий 3. Иностранный SIEM с логами, содержащими ПДн. Ситуация: технический директор финтех-SaaS (Уральский ФО, начало 2026) обнаружил, что production-логи с IP-адресами и user ID передаются в Datadog (США). Уведомление о трансграничной передаче в РКН не подавалось. После проведения аудита выявлено нарушение ст. 12 ФЗ-152. Стратегия: подать уведомление о трансграничной передаче в РКН, параллельно рассмотреть переход на российский SIEM или маскировку ПДн в логах до передачи, оформить договор с Datadog как договор поручения с указанием мер защиты.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

Практика DATUM включает аудит архитектуры SaaS-платформ, разработку договоров поручения для мультиарендных систем, определение УЗ с документированной оценкой угроз и сопровождение при взаимодействии с Роскомнадзором. По итогам аудита — отчёт с приоритизированным планом устранения нарушений.