Multi-cloud стратегия и 152-ФЗ

Рост числа multi-cloud внедрений в российских IT-компаниях продолжается — даже в условиях ограничений на западные сервисы. Отечественные провайдеры (Yandex Cloud, SberCloud, VK Cloud, Cloud.ru) используются в комбинации с зарубежными для целей резервирования, CDN или ML-вычислений. Проблема: большинство таких архитектур проектируется без правового аудита по 152-ФЗ. Результат — скрытые нарушения локализации, незакрытые поручения обработки и неверно определённый УЗ для каждого сегмента. В этом материале — разбор ключевых пересечений multi-cloud и 152-ФЗ для технического директора, который отвечает за архитектуру.

Как 152-ФЗ делит облачные операции: что можно в иностранном облаке?

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

Это создаёт рабочую модель для multi-cloud: российский кластер — для первичной обработки ПДн; иностранный кластер — для работы с обезличенными данными, CDN-кэшем, ML-инференсом на нечувствительных данных. Но реализация требует двух обязательных шагов: корректного обезличивания по методам Приказа РКН (5 методов: введение идентификаторов, изменение состава/семантики, декомпозиция, перемешивание, обобщение/агрегация) и документального разграничения потоков данных между кластерами.

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

Какой уровень защищённости выбрать для каждого кластера в multi-cloud?

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

Типичная ошибка: УЗ определяется один раз для системы в целом, а затем распространяется на все кластеры одинаково. На практике кластер с биометрическими ПДн (скажем, аутентификация по лицу в СКУД) требует более высокого УЗ, чем кластер с агрегированной аналитикой. Если система содержит ПДн более 100 000 субъектов и обрабатывает специальные категории — базовый УЗ не ниже УЗ-2. Угрозы первого типа (уязвимости на уровне гипервизора) автоматически поднимают минимальный УЗ — для облачной инфраструктуры это критично.

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

Как оформить поручение обработки в SaaS с мультиарендностью?

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

В мультиарендной архитектуре (multi-tenancy) особое значение имеет логическая изоляция данных арендаторов. Если данные клиентов физически находятся в одном хранилище, но логически разделены — это допустимо, однако поручение должно прямо предусматривать механизм изоляции и запрет на смешивание данных разных операторов. Облачный провайдер, в свою очередь, выступает субпоручителем — и договор должен либо прямо разрешать субпоручение, либо запрещать его.

Критичный пункт для CTO: если система логирует действия пользователей (клики, сессионные данные, метаданные запросов) — эти данные в большинстве случаев являются ПДн по позиции РКН. Логирование как ПДн требует правового основания: либо согласие, либо договор, либо законный интерес. Включать такое логирование в ИСПДн и определять для него УЗ — обязанность оператора.

Обезличивание для ML: как не нарушить 152-ФЗ при обучении моделей

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

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

Отдельный вопрос — КИИ (критическая информационная инфраструктура). Если ML-система используется в объектах КИИ, дополнительно применяются требования ФЗ-187 и подзаконных актов ФСТЭК. Совмещение 152-ФЗ и КИИ-требований в одной архитектуре — отдельная задача, требующая согласования с ФСТЭК.

Как это выглядит на практике: два сценария для CTO

Сценарий 1. SaaS-платформа с иностранным ML-облаком (Центральный ФО, начало 2026). Технический директор IT-компании выстроил архитектуру: основная БД — в российском облаке, ML-обучение — в иностранном. Данные передавались «в обезличенном виде», но без применения методов по Приказу РКН и без документации. При внеплановой проверке РКН установил: переданные наборы содержат косвенные идентификаторы (user_id, связанный с основной БД), реидентификация тривиальна. Обработка квалифицирована как трансграничная передача ПДн без уведомления по ст. 12 ФЗ-152 и нарушение ч. 5 ст. 18 ФЗ-152. Возбуждены дела по ч. 8 и ч. 1 ст. 13.11 КоАП. Совокупный штраф составил несколько миллионов рублей. ⚠️ Номер дела и точная сумма — менеджер уточняет при публикации.

Сценарий 2. Мультиарендный SaaS без договора-поручения (Северо-Западный ФО, осень 2025). Компания предоставляла CRM-SaaS клиентам из малого бизнеса. Данные клиентов SaaS физически хранились в общем кластере без разграничения. Договоры с клиентами не содержали условий о поручении обработки. При жалобе субъекта ПДн в РКН выявлено: SaaS-провайдер фактически самостоятельно обрабатывает ПДн клиентов без правового основания (ни согласия, ни поручения). Дело по ч. 1 ст. 13.11 КоАП завершилось штрафом в диапазоне 150 000–300 000 ₽ и предписанием переработать договорную документацию. ⚠️ Номер дела — менеджер уточняет при публикации.

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

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

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

1. Какой УЗ выбрать для SaaS с данными физических лиц?

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

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

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

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

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

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

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

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

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

Итог

Multi-cloud стратегия совместима с 152-ФЗ при соблюдении трёх условий: локализация первичных операций с ПДн граждан РФ в российском кластере, корректное обезличивание данных перед передачей в иностранный кластер, документальное оформление поручений с каждым провайдером. УЗ определяется для каждого сегмента отдельно по ПП РФ №1119 — единый УЗ на всю архитектуру недостаточен.

DATUM сопровождает IT-компании и SaaS-провайдеров в части 152-ФЗ: от карты потоков ПДн и модели угроз до договоров-поручений с облачными провайдерами и подготовки к проверкам РКН. Практика по технической стороне 152-ФЗ — с 2014 года.