Selectel, Cloud.ru, SberCloud: соответствие 152-ФЗ

Для технического директора выбор облачной платформы под ИСПДн — это одновременно инфраструктурное и юридическое решение. Три крупнейших российских провайдера — Selectel, Cloud.ru и SberCloud — имеют аттестованные сегменты и декларируют соответствие требованиям регуляторов. Но между декларацией провайдера и реальным соответствием оператора требованиям 152-ФЗ, Приказа ФСТЭК №21 и ПП РФ №1119 существует разрыв, который заполняет CTO. Ниже — анализ этого разрыва по ключевым точкам: уровни защищённости, поручение обработки, обезличивание для ML, мультиарендность и KII.

Как выбрать уровень защищённости для облачной ИСПДн?

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

На практике CTO нередко занижает уровень угрозы: декларирует тип 3 («угрозы, связанные только с прикладным ПО»), не проводя оценку фактических векторов атаки. Это снижает требования к СЗИ, но создаёт уязвимость при проверке ФСТЭК или РКН: если актуальность угрозы будет переквалифицирована, весь аттестат окажется недействительным.

Selectel предоставляет аттестованный сегмент под УЗ-1..УЗ-3 (FZ-152 Segment), Cloud.ru — платформу «ГосТех» с аттестацией до УЗ-2, SberCloud — Kubernetes-среду с заявленным УЗ-3. Ни один из провайдеров не берёт на себя роль оператора: все три работают по модели поручения обработки (п. 3 ст. 6 ФЗ-152). Аттестат провайдера покрывает физическую инфраструктуру; ответственность за прикладной уровень, политики доступа и согласия субъектов остаётся на операторе.

Что означает поручение обработки для SaaS с мультиарендностью?

Мультиарендная SaaS-платформа создаёт нетривиальную картину ролей. Платформа как юридическое лицо одновременно является оператором ПДн своих сотрудников и лицом, осуществляющим обработку по поручению, — для данных клиентов (арендаторов). Каждый арендатор при этом остаётся оператором в отношении ПДн своих пользователей.

На практике это означает: если арендатор SaaS-платформы допустил утечку из-за уязвимости в общем компоненте (например, в слое изоляции контейнеров Kubernetes), ответственность по ст. 13.11 КоАП несёт арендатор как оператор — вне зависимости от того, что уязвимость была на стороне платформы. Договор поручения должен явно распределять зоны ответственности, включать требование к уведомлению оператора об инцидентах в течение срока, совместимого с его обязанностью сообщить РКН в 24 часа (ч. 3.1 ст. 21 ФЗ-152).

Все три провайдера предоставляют типовые DPA (Data Processing Agreement), но их содержание требует проверки: срок уведомления об инциденте у провайдера нередко составляет 72 часа, тогда как оператору нужен буфер для собственного первичного уведомления за 24 часа. Такой договор создаёт структурный дефицит времени.

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

Обучение ML-моделей на персональных данных — одна из самых частых серых зон. Технический директор нередко полагает, что раз модель не выдаёт конкретных ПДн, то и обработки ПДн нет. Это неверно: загрузка датасета с ПДн в вычислительный кластер — это уже обработка (хранение, использование) по ст. 3 ФЗ-152.

Для ML-пайплайна в облаке правомерная схема выглядит так: до загрузки в вычислительную среду (будь то Selectel ML Space, Cloud.ru ML Platform или SberCloud AI) датасет обезличивается одним из пяти методов приказа РКН. Обезличенные данные уже не являются ПДн при условии, что таблица соответствия идентификаторов хранится отдельно и недоступна в вычислительной среде. Это снимает требования 152-ФЗ с самого облачного сегмента — но не с хранилища таблицы соответствия, которое остаётся ИСПДн.

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

Что требует Приказ ФСТЭК №21 от облачной ИСПДн?

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

При использовании облака разделение мер между провайдером и оператором закрепляется в матрице ответственности. Типовое распределение для IaaS: провайдер отвечает за ЗТС, ЗСВ (виртуализация), ЗИС (физический и сетевой периметр); оператор — за ИАФ, УПД, ОПС, РСБ, АВЗ, СОВ, АНЗ, ОЦЛ на уровне своих приложений и данных. При PaaS провайдер берёт дополнительно часть ИАФ и УПД на уровне платформы, но оператор всё равно обязан реализовать меры на уровне приложения.

Ключевой риск — неформализованное распределение. Если матрица не подписана, при инциденте невозможно доказать, что оператор выполнил свою часть требований. РКН и ФСТЭК при проверке запросят документальное подтверждение каждой меры базового набора.

Как российские облака соотносятся с требованиями КИИ?

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

Selectel, Cloud.ru и SberCloud имеют сертифицированные сегменты, подходящие для размещения значимых объектов КИИ. Однако статус субъекта КИИ определяется не провайдером, а оператором самостоятельно — через категорирование объектов по ПП РФ №127. Если категорирование не проведено, а система фактически является объектом КИИ, — это отдельный риск, не связанный с 152-ФЗ, но пересекающийся с ним при хранении ПДн на значимом объекте.

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

Кейс 1. SaaS-компания (Северо-Западный ФО, осень 2025) развернула платформу на Selectel, оформила договор поручения обработки, провела классификацию ИСПДн как УЗ-3. При плановой проверке РКН выяснилось, что ML-пайплайн обучается на необезличенном датасете пользователей в том же облачном сегменте. Регулятор квалифицировал это как обработку ПДн за пределами объявленных целей (ст. 5 ФЗ-152) и возбудил дело по ч. 1 ст. 13.11 КоАП. Штраф составил несколько сотен тысяч рублей. После получения предписания компания внедрила обезличивание по методу введения идентификаторов с отдельным хранилищем таблицы соответствия — вне вычислительного кластера. ⚠️ Точный номер дела и сумма штрафа — менеджер уточняет при публикации.

Кейс 2. Финтех-оператор (Центральный ФО, начало 2026) использовал Cloud.ru для обработки ПДн клиентов с УЗ-2. После смены провайдера технический директор не переоформил договор поручения обработки — новый провайдер работал фактически без правового основания. РКН при внеплановой проверке зафиксировал нарушение п. 3 ст. 6 ФЗ-152. Протокол по ч. 1 ст. 13.11 КоАП. Договор поручения был оформлен в ходе проверки, что учтено как смягчающее обстоятельство, однако не исключило штраф. ⚠️ Конкретные реквизиты дела — менеджер проверяет перед публикацией.

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

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

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

1. Какой УЗ выбрать для SaaS с базой более 100 000 пользователей?

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

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

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

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

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

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

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

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

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

Итог

Selectel, Cloud.ru и SberCloud предоставляют аттестованную инфраструктуру, совместимую с требованиями 152-ФЗ и Приказа ФСТЭК №21. Но аттестат провайдера покрывает только физический и виртуализационный уровень — прикладная архитектура, договор поручения, модель угроз, обезличивание для ML и матрица мер ФСТЭК №21 остаются зоной ответственности оператора.

Юристы и технические аналитики DATUM сопровождают облачные проекты от классификации ИСПДн и выбора УЗ до подготовки к проверке РКН — с учётом актуальных требований в редакции с 30.05.2025.