Мультиарендность SaaS и 152-ФЗ
С 30.05.2025 ст. 13.11 КоАП действует в расширенной редакции ФЗ-420 от 30.11.2024: 18 частей вместо прежних семи. Одновременно с 11.12.2024 введена ст. 272.1 УК РФ — уголовная ответственность за незаконное использование или хранение компьютерной информации с ПДн. Для CTO мультиарендной платформы это означает одно: архитектурные решения принятые год назад могут стать основанием для административного дела сегодня.
Кто оператор в мультиарендной SaaS: как разграничить роли?
Ст. 3 ФЗ-152 определяет оператора как лицо, которое организует и осуществляет обработку ПДн, определяя её цели и состав. В мультиарендной модели роли распределяются по-разному в зависимости от того, кто формирует цель обработки.
Типовая конструкция выглядит так: клиент SaaS-платформы (например, HR-сервис или CRM) является оператором по отношению к данным своих пользователей — он определяет цель. SaaS-вендор при этом выступает лицом, осуществляющим обработку по поручению оператора в соответствии с п. 3 ст. 6 ФЗ-152. Однако если платформа самостоятельно определяет хотя бы одну цель обработки — например, аналитику поведения пользователей для собственного продукта — она становится оператором в этой части.
Практическое следствие: вендор SaaS обязан заключить с каждым клиентом-оператором отдельный договор поручения обработки ПДн с полным перечнем действий. Без этого договора вендор юридически является самостоятельным оператором и обязан уведомить РКН по ст. 22 ФЗ-152. Штраф за отсутствие уведомления — 100–300 тыс. ₽ по ч. 10 ст. 13.11 КоАП.
Дополнительная сложность возникает, когда вендор агрегирует обезличенные данные нескольких клиентов для обучения ML-моделей. Здесь важно убедиться, что данные действительно обезличены по методам, утверждённым приказом РКН (5 методов: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение). Если агрегация производится до обезличивания — вендор обрабатывает ПДн как оператор и обязан иметь правовое основание.
Архитектура SaaS задокументирована, но роли в договорах не разграничены?
Если CTO не оформил договоры поручения обработки с каждым клиентом, вендор юридически является самостоятельным оператором по всем данным на платформе. Это означает обязанность уведомить РКН, определить УЗ и обеспечить меры по ст. 19 ФЗ-152. Юристы DATUM проведут аудит обработки ПДн по чек-листу из 38 пунктов и выдадут отчёт с приоритизированным планом устранения нарушений.
Заказать аудит 152-ФЗОтветим за 2 часа · +7 (983) 510-38-76 · info@vitveteam.ru
Какой уровень защищённости выбрать для мультиарендной SaaS?
Уровень защищённости информационной системы персональных данных (ИСПДн) определяется по ПП РФ №1119 от 01.11.2012 на основе трёх параметров: категория ПДн, тип актуальных угроз и количество субъектов. В мультиарендной SaaS все три параметра усложняются: каждый клиент-оператор может обрабатывать данные разных категорий, а общее число субъектов на платформе суммируется.
Ключевой практический вопрос: определяется ли УЗ по каждому клиенту отдельно или по платформе в целом? Если вендор является обработчиком по поручению, ответственность за определение УЗ лежит на операторе-клиенте — но требования к техническим мерам обязан реализовывать вендор. Если вендор является оператором — он определяет УЗ сам.
Для большинства B2B SaaS-платформ, обрабатывающих контактные данные и данные об использовании продукта, базовым является УЗ-3. Однако если хотя бы один клиент передаёт платформе медицинские данные, данные о судимостях или биометрию — часть системы переходит в категорию специальных или биометрических ПДн, что требует пересмотра УЗ для соответствующего сегмента.
Практическое решение для мультиарендной архитектуры — сегментация инфраструктуры: клиенты с чувствительными данными размещаются в изолированном контуре с более высоким УЗ. Это технически сложнее, но юридически безопаснее, чем поднимать УЗ для всей платформы.
Какие технические меры обязательны по Приказу ФСТЭК №21?
Приказ ФСТЭК №21 от 18.02.2013 определяет состав и содержание организационных и технических мер для нейтрализации угроз в ИСПДн. Структура документа — 15 групп мер (ИАФ, УПД, ОПС, ЗНИ, РСБ, АВЗ, СОВ, АНЗ, ОЦЛ, ОДТ, ЗСВ, ЗТС, ЗИС, УКФ, ОПО), итого 109 мер. Базовый набор формируется в зависимости от УЗ; часть мер адаптируется под конкретную систему.
Для CTO мультиарендной SaaS наиболее критичны четыре группы.
РСБ — регистрация событий безопасности. Все действия с ПДн — чтение, изменение, удаление, экспорт — должны логироваться с возможностью восстановления хронологии. В мультиарендной архитектуре логи должны быть разделены по клиентам: один клиент не должен иметь доступа к логам другого. Это одновременно требование ФЗ-152 и условие для 24-часового уведомления об утечке по ч. 3.1 ст. 21.
ЗСВ — защита виртуальной инфраструктуры. При использовании гипервизоров и контейнеризации (Kubernetes, Docker) требуется изоляция ресурсов виртуальных машин и контейнеров, принадлежащих разным клиентам. Общий кластер Kubernetes без namespace-политик и network policies не соответствует требованиям УЗ-3.
УПД — управление правами доступа. Персонал вендора не должен иметь прямого доступа к данным клиентов без явного поручения и регистрации события. Принцип минимальных привилегий должен быть реализован на уровне RBAC в базе данных и прикладном слое.
ЗНИ — защита машинных носителей. При облачном хостинге это означает требования к шифрованию дисков, политике удаления данных при освобождении ресурсов и порядку уничтожения ПДн при расторжении договора с клиентом.
Что подготовить CTO для подтверждения соответствия ФЗ-152
- Модель угроз и нарушителя с актуализацией по банку угроз ФСТЭК для каждого сегмента ИСПДн
- Акт определения уровня защищённости (УЗ-1..4) по ПП РФ №1119 для каждого контура
- Реестр обработчиков и договоры поручения обработки ПДн с каждым клиентом-оператором по п. 3 ст. 6 ФЗ-152
- Техническое задание на адаптацию мер по Приказу ФСТЭК №21 с перечнем реализованных и компенсирующих мер
- Регламент логирования событий безопасности с описанием разделения логов по клиентам и сроками хранения
Можно ли использовать иностранные облака для SaaS с данными граждан РФ?
С 01.09.2015 действует требование ч. 5 ст. 18 ФЗ-152 о локализации: запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ должны осуществляться в базах, физически расположенных на территории РФ. Штраф за нарушение — 1–6 млн ₽ по ч. 8 ст. 13.11 КоАП; при повторности — 6–18 млн ₽ по ч. 9.
Для SaaS-платформы это означает следующее: первичная запись ПДн российских субъектов должна производиться в российской инфраструктуре. Репликация данных за рубеж после первичной записи в РФ технически допускается при соблюдении требований к трансграничной передаче по ст. 12 ФЗ-152 — с уведомлением РКН для стран без адекватной защиты.
На практике использование AWS, Google Cloud или Azure с регионом вне РФ для первичного хранения данных российских пользователей является нарушением ч. 5 ст. 18 ФЗ-152. РКН имеет право заблокировать доступ к сервису. Допустимые варианты: облака с российскими дата-центрами (Yandex Cloud, VK Cloud, Selectel, SberCloud), аренда серверов в российских ЦОД или гибридная схема с первичным хранилищем в РФ.
Если CTO планирует миграцию на российское облако или использует иностранный провайдер для части клиентов — нужна оценка соответствия до момента, когда РКН зафиксирует нарушение. Штраф за локализацию — до 6 млн ₽, при повторности — до 18 млн ₽.
Заказать аудит 152-ФЗЧто такое обезличивание для ML и когда оно защищает от 152-ФЗ?
Обезличивание ПДн — это действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность ПДн конкретному субъекту. Обезличенные данные выходят из-под большинства требований ФЗ-152 и могут обрабатываться без согласия субъекта и без ограничений по целям.
Приказ РКН определяет 5 методов обезличивания: введение идентификаторов (замена прямых идентификаторов на суррогатные ключи), изменение состава и семантики (удаление или обобщение атрибутов), декомпозиция (разделение на несвязанные таблицы), перемешивание (перестановка значений атрибутов между записями), обобщение или агрегация (замена точных значений на диапазоны или агрегаты).
Для ML-обучения наиболее применимы агрегация и введение идентификаторов. Однако CTO должен учитывать: обезличивание должно предшествовать передаче данных в обучающий контур. Если модель обучается на реальных ПДн, а обезличивание происходит «на лету» внутри ML-пайплайна — это обработка ПДн, требующая правового основания.
Ещё один риск — реидентификация. Если ML-модель при инференсе способна восстановить атрибуты конкретного субъекта — данные не считаются обезличенными. РКН при проверке вправе потребовать демонстрацию того, что реидентификация практически невозможна.
Матрица сценариев: типовые ситуации для CTO мультиарендной SaaS
Сценарий 1. Общая база данных для всех клиентов без логической изоляции. Ситуация: все клиенты-операторы хранят ПДн в одной схеме PostgreSQL, разделённой только полем tenant_id. Доказательства нарушения: при SQL-инъекции или ошибке фильтрации один арендатор получает доступ к данным другого. Вероятный исход: если произойдёт утечка — оба оператора и вендор получат протоколы по ч. 12–14 ст. 13.11; вендор дополнительно — по ч. 11 (неуведомление об утечке за 24 часа, 1–3 млн ₽). Стратегия: переход на row-level security в PostgreSQL или разделение схем; документирование мер в техническом задании по Приказу ФСТЭК №21.
Сценарий 2. SaaS-платформа обучает общую ML-модель на данных всех клиентов без обезличивания. Ситуация: аналитический модуль агрегирует поведенческие данные пользователей всех клиентов для улучшения рекомендательного алгоритма. Доказательства нарушения: в договоре с клиентами указана только цель «предоставление SaaS-сервиса»; цель «улучшение ML-моделей» не указана и не согласована. Вероятный исход: вендор признаётся оператором с самостоятельной целью, нарушает ст. 5 ФЗ-152 (принцип целевого ограничения) и ст. 6 (отсутствие правового основания). Стратегия: либо добавить цель в договор поручения и уведомление РКН, либо обезличить данные до агрегации с применением документированных методов.
Сценарий 3. Вендор не уведомил РКН, считая себя обработчиком, но клиенты-операторы также не уведомили. Ситуация: стартап запустил B2B SaaS для HR-автоматизации, заключил договоры с 30 клиентами, уведомлений в реестре нет ни у кого. РКН инициировал проверку после жалобы уволенного сотрудника одного из клиентов. Вероятный исход: у вендора нет договоров поручения — он признаётся оператором; штраф по ч. 10 ст. 13.11 (100–300 тыс. ₽) плюс предписание устранить нарушения. У клиентов — аналогичные штрафы. Стратегия: немедленно оформить договоры поручения, один из клиентов-операторов подаёт уведомление в РКН; вендор при наличии самостоятельных целей — тоже.
Практика применения норм в 2025–2026 годах
Кейс 1. IT-компания (Северо-Западный ФО, весна 2026) эксплуатировала мультиарендную CRM-платформу с единой базой данных. После хакерской атаки произошла утечка данных трёх клиентов-операторов суммарно более 50 000 субъектов. Вендор направил первичное уведомление в РКН через 31 час — с превышением 24-часового срока по ч. 3.1 ст. 21 ФЗ-152. Штраф по ч. 11 ст. 13.11 составил сумму в нижней части диапазона 1–3 млн ₽. Суд учёл оперативность расследования и принятые меры по устранению уязвимости, но снизить штраф ниже минимума не смог: ст. 4.1.1 КоАП неприменима к ч. 11. ⚠️ Конкретный номер дела и точная сумма — менеджер уточняет при публикации.
Кейс 2. По публичному делу АС Санкт-Петербурга и Ленинградской области (дело № А56-4733/2026 от 10.03.2026) цифровая платформа инвестиционных проектов допустила утечку около 70 000 субъектов — ФИО, должность, служебный email, телефон — после хакерской атаки. Дело квалифицировано по ч. 14 ст. 13.11 КоАП (более 100 000 субъектов в части идентификаторов). Суд применил смягчающие обстоятельства. Источник: ГАРАНТ.РУ 23.03.2026.
Услуги DATUM по теме
- Аудит соответствия 152-ФЗ — чек-лист из 38 пунктов, отчёт с планом устранения
- DPIA (оценка воздействия) — для платформ с высоким риском обработки ПДн
- Комплект ОРД под ключ — политика, договоры поручения, приказы, регламенты
Частые вопросы
1. Какой УЗ выбрать для SaaS?
Уровень защищённости определяется отдельно для каждого сегмента ИСПДн по ПП РФ №1119: исходя из категории обрабатываемых ПДн (общие, специальные, биометрические), типа актуальных угроз (1–3) и числа субъектов. Для большинства B2B SaaS с общими категориями данных и угрозами 2-го типа базовым является УЗ-3. Если платформа обрабатывает медицинские данные или данные более 100 000 субъектов при угрозах 2-го типа — требуется УЗ-2. В мультиарендной архитектуре правильным решением является сегментация: клиенты с более чувствительными данными — в отдельном контуре с соответствующим УЗ.
2. Можно ли использовать иностранные облака?
Для первичного хранения и обработки ПДн граждан РФ — нельзя, если дата-центр находится за пределами РФ. Ч. 5 ст. 18 ФЗ-152 требует, чтобы запись, хранение и ключевые операции с ПДн российских субъектов производились в базах на территории РФ. AWS, Azure и Google Cloud с регионами вне РФ для этих целей не подходят. Допустимо использование иностранных облаков для вторичного хранения или аналитики при условии, что первичная запись происходит в российской инфраструктуре и соблюдены требования ст. 12 ФЗ-152 о трансграничной передаче.
3. Что такое обезличивание для ML?
Обезличивание для целей ML — это приведение обучающих данных к состоянию, при котором принадлежность записи конкретному субъекту не может быть установлена без дополнительной информации. Приказ РКН определяет 5 методов: введение идентификаторов (псевдонимизация), изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Обезличивание должно быть проведено до передачи данных в обучающий контур и задокументировано. Если модель способна при инференсе восстановить атрибуты субъекта — данные не считаются обезличенными.
4. Кто оператор в мультиарендной SaaS?
Оператором является тот, кто определяет цели обработки ПДн. В типовой схеме клиент SaaS-платформы — оператор, вендор — обработчик по поручению согласно п. 3 ст. 6 ФЗ-152. Договор поручения обязателен: без него вендор юридически становится самостоятельным оператором и обязан уведомить РКН по ст. 22. Если вендор самостоятельно определяет хотя бы одну цель — например, обучение ML-моделей — он является оператором в этой части и несёт полную ответственность по ФЗ-152.
5. Какие СЗИ обязательны?
Состав средств защиты информации определяется Приказом ФСТЭК №21 применительно к установленному УЗ. Для УЗ-3 базовый набор включает: антивирусную защиту (АВЗ), систему обнаружения вторжений (СОВ), защиту среды виртуализации (ЗСВ), регистрацию событий безопасности (РСБ) и управление доступом (ИАФ, УПД). Конкретные СЗИ должны быть сертифицированы ФСТЭК для обработки ПДн. Перечень сертифицированных продуктов — на сайте ФСТЭК России. Для КИИ-объектов дополнительно применяется 187-ФЗ с собственными требованиями к категорированию и защите.
Итог
Мультиарендная SaaS-архитектура создаёт правовую неопределённость в трёх ключевых точках: разграничение ролей оператора и обработчика, определение единого уровня защищённости для разнородных клиентских данных, соответствие требованиям локализации при использовании облачной инфраструктуры. Каждая из этих точек при проверке РКН или инциденте становится основанием для штрафа — от 100 тыс. ₽ за отсутствие уведомления до оборотного штрафа при повторной утечке.
DATUM сопровождает IT-компании и SaaS-вендоров в выстраивании соответствия ФЗ-152: от определения УЗ и разработки модели угроз до договоров поручения и ОРД под ключ. Практика «Ветров и партнёры» по 152-ФЗ с 2014 года.
14 февраля 2029 года