Изоляция данных арендаторов

Многоарендная архитектура (multi-tenancy) — стандарт для современных SaaS-платформ. Когда одна инфраструктура обслуживает десятки или сотни организаций, данные каждого арендатора должны быть юридически и технически изолированы. Провал изоляции — это не только архитектурная ошибка: с 30.05.2025 это прямой путь к штрафу по ч. 12–15 ст. 13.11 КоАП, а при определённых обстоятельствах — к уголовной ответственности по ст. 272.1 УК РФ. В этом материале рассмотрены правовые требования к изоляции ПДн арендаторов, выбор уровня защищённости, обезличивание для ML и типовые риски архитектурных решений.

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

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

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

Локализация по ч. 5 ст. 18 ФЗ-152 обязывает записывать, систематизировать, накапливать, хранить, уточнять и извлекать ПДн граждан РФ исключительно в базах данных на территории России. Это требование действует с 01.09.2015 и было дополнительно ужесточено ФЗ-233 с 01.07.2025: первичный сбор данных теперь также должен происходить на российских серверах. Для CTO это означает, что даже временное «приземление» данных на зарубежный узел перед репликацией в РФ образует состав нарушения по ч. 8 ст. 13.11 КоАП (штраф 1–6 млн ₽).

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

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

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

Практическое правило: ИСПДн платформы должна соответствовать наивысшему уровню из всех требуемых арендаторами. Если хотя бы один арендатор обрабатывает специальные категории ПДн (ст. 10 ФЗ-152), вся система попадает под требования УЗ-1 или УЗ-2. Выход — физическое или логическое разделение контуров: выделенный изолированный контур для «тяжёлых» арендаторов и общий контур для «лёгких».

Угрозы 1-го типа предполагают наличие недокументированных возможностей в системном ПО; 2-го типа — в прикладном. В практике большинства коммерческих SaaS-платформ Роскомнадзор и ФСТЭК принимают обоснование угроз 2-го или 3-го типа при наличии задокументированной модели угроз, подготовленной по методическим рекомендациям ФСТЭК. Отсутствие модели угроз само по себе является нарушением требований ст. 19 ФЗ-152 и ПП РФ №1119.

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

Как обезличивание ПДн применяется в ML-пайплайнах мультиарендной SaaS?

Обучение ML-моделей на реальных ПДн арендаторов — распространённая практика, которая до 2025 года оставалась в правовой «серой зоне». С введением ст. 13.1 ФЗ-152 (ФЗ-233 от 08.08.2024) обезличенные ПДн получили отдельный правовой режим. Регулятор устанавливает требования к методам обезличивания и порядку передачи обезличенных данных в государственные системы.

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

В мультиарендной SaaS особую опасность представляет перекрёстное обучение: если модель обучается на данных арендатора А и её инференс доступен арендатору Б, возможна косвенная утечка признаков. Это квалифицируется как несанкционированный доступ к ПДн, а при наличии умысла — по ст. 272.1 УК РФ (введена ФЗ-421 от 30.11.2024, действует с 11.12.2024). Архитектурное решение — изолированные ML-контуры по арендаторам или federated learning с агрегацией только обновлений весов модели.

Логирование действий с ПДн в контексте ML — отдельный вопрос. РСБ-группа мер Приказа ФСТЭК №21 обязывает фиксировать все операции с защищаемыми данными. Для ML-пайплайна это означает: каждый запрос к датасету, каждый инференс-вызов и каждое изменение в обучающей выборке должны быть залогированы с идентификатором арендатора, меткой времени и идентификатором субъекта обращения. Сами логи содержат косвенные ПДн и подпадают под режим защиты.

Как строится изоляция на уровне договоров и ОРД — типовые сценарии для CTO

Техническая изоляция без юридического оформления не снимает ответственности с платформы. Рассмотрим три типовых сценария.

Сценарий 1. SaaS-платформа не заключила договоры-поручения с арендаторами. Арендатор передаёт ПДн своих клиентов на платформу без письменного поручения по ст. 6 ч. 3 ФЗ-152. Платформа де-факто становится самостоятельным оператором, обрабатывающим ПДн без правового основания. При проверке РКН — протокол по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽). Если утечка — арендатор вправе предъявить регрессные требования. Стратегия: ввести стандартный DPA (Data Processing Agreement) как обязательное приложение к договору, фиксирующее перечень ПДн, цели, меры защиты и инструкции по уничтожению.

Сценарий 2. Договор-поручение есть, но реальная обработка шире заявленного. В договоре указана «передача данных в аналитическую систему», фактически платформа обучает на этих данных ML-модель и предоставляет её всем арендаторам. Это нарушение ст. 5 ФЗ-152 (несовместимость целей) и ст. 6 (превышение поручения). Штраф — ч. 1 или ч. 2 ст. 13.11, при систематичности — повторный состав. Стратегия: расширить DPA с явным перечислением всех сценариев использования данных, включая ML; при необходимости — получить отдельное согласие субъектов на использование их данных для обучения моделей.

Сценарий 3. Утечка через уязвимость в логике разграничения доступа (cross-tenant breach). API-эндпоинт не проверяет принадлежность запрашиваемого объекта к арендатору запросчика (IDOR-уязвимость). Один арендатор получает доступ к данным другого. При объёме более 1 000 субъектов — немедленное уведомление РКН за 24 часа (ч. 3.1 ст. 21 ФЗ-152), штраф по ч. 11 ст. 13.11 за нарушение срока уведомления (1–3 млн ₽) плюс штраф по ч. 12–14 за саму утечку (3–15 млн ₽). Стратегия: регулярный pentest изоляции контуров арендаторов, обязательная атрибуция tenant_id на уровне middleware, логирование всех cross-tenant запросов.

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

Кейс 1. IT-компания Приволжского ФО (весна 2026), SaaS-платформа для HR-систем. При обновлении ORM-слоя разработчик допустил ошибку в параметризации запросов, в результате 40 арендаторов получили возможность просматривать выгрузки соседних организаций в течение 6 часов. Платформа обнаружила инцидент через систему мониторинга и уведомила РКН в течение 19 часов. Затронуто около 8 000 субъектов — нарушение квалифицировано по ч. 12 ст. 13.11 КоАП (штраф в диапазоне нескольких миллионов рублей). Своевременное уведомление и наличие зафиксированных мер защиты позволили юристам компании добиться применения нижней границы санкции.

Кейс 2. По материалам дела АС Санкт-Петербурга и Ленинградской области № А56-4733/2026 (ПКР Аналитика) — утечка около 70 000 субъектов (ФИО, должность, служебный email, телефон) после хакерской атаки, квалифицированная по ч. 14 ст. 13.11 КоАП (утечка более 100 000 субъектов по идентификаторам). Суд применил смягчающие обстоятельства. Для CTO ключевой вывод: наличие задокументированных мер защиты и оперативное расследование напрямую влияют на итоговый размер штрафа.

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

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

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

1. Какой УЗ выбрать для SaaS, если арендаторы обрабатывают данные разных категорий?

Уровень защищённости определяется по наиболее строгому требованию среди всех арендаторов в рамках одной ИСПДн согласно ПП РФ №1119. Если хотя бы один арендатор обрабатывает специальные категории ПДн (состояние здоровья, биометрия), вся система требует УЗ-1 или УЗ-2. Архитектурное решение — выделение изолированных контуров с разными УЗ для арендаторов разных категорий. Это позволяет не переводить всю платформу на наиболее строгий уровень.

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

Нет, если речь идёт о первичном сборе, хранении или обработке ПДн граждан РФ. Ч. 5 ст. 18 ФЗ-152 в редакции после ФЗ-233 (с 01.07.2025) требует, чтобы запись, систематизация, накопление, хранение, уточнение и извлечение ПДн российских граждан происходили только в базах данных на территории РФ. Хранение реплики в зарубежном облаке после первичной записи в российском ЦОД формально допустимо при соблюдении требований трансграничной передачи (ст. 12 ФЗ-152), однако требует уведомления РКН для стран без адекватной защиты.

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

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

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

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

5. Какие СЗИ обязательны для SaaS-платформы уровня УЗ-3?

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

Итог

Изоляция данных арендаторов в мультиарендной SaaS — это одновременно архитектурная задача и правовое требование. Выбор УЗ, оформление договоров-поручений, обезличивание ML-данных и логирование доступа — каждый из этих элементов имеет конкретную норму в ФЗ-152, ПП РФ №1119 или Приказе ФСТЭК №21. Провал по любому из них с 30.05.2025 может стоить от 3 до 500 млн ₽.

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

14 января 2029 года