Локализация ПДн на отечественном облаке (Яндекс.Облако, VK Cloud, MTS Cloud)

Переход на отечественные облачные платформы ускорился после 2022 года, но правовой каркас вокруг него менялся не менее быстро. Ст. 13.11 КоАП в редакции ФЗ-420 от 30.11.2024, вступившей в силу 30.05.2025, добавила восемь новых составов. Штраф за нарушение локализации вырос в шесть раз относительно старой нормы. При этом большинство технических директоров сталкиваются с двумя практическими вопросами: какой уровень защищённости (УЗ-1..4 по ПП РФ №1119) нужен конкретной ИСПДн в облаке и как правильно оформить договор с облачным провайдером как обработчиком по поручению. Ниже — разбор обоих вопросов на примере трёх крупнейших российских платформ.

Что означает локализация ПДн в облаке с точки зрения закона?

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

Ключевое изменение, которое внёс ФЗ-233 от 08.08.2024 и которое заработало с 01.07.2025: первичная запись должна происходить именно в российской базе. Схема «сначала пишем в AWS, потом реплицируем в Яндекс.Облако» перестала соответствовать требованиям. РКН подтвердил эту позицию в разъяснениях, которые появились после внесения поправок.

Для облачной инфраструктуры это означает: дата-центр облачного провайдера должен физически находиться в России, а договор с провайдером должен явно фиксировать, что обработка ПДн (в смысле ч. 5 ст. 18) осуществляется в российских ЦОД. Яндекс.Облако, VK Cloud и MTS Cloud размещают свои мощности в российских дата-центрах и декларируют соответствие требованиям локализации — однако декларации провайдера не освобождают оператора от собственной проверки.

Как определить уровень защищённости УЗ-1..4 для облачной ИСПДн?

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

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

Практический вопрос для CTO: какую часть мер Приказа №21 закрывает облачный провайдер, а какую должен закрыть оператор самостоятельно. Яндекс.Облако, VK Cloud и MTS Cloud публикуют матрицы ответственности (SRM — Shared Responsibility Matrix), в которых указывают, за какие группы мер отвечает провайдер, а за какие — клиент. Как правило, провайдер закрывает физическую безопасность (ЗТС), сетевую изоляцию (ЗИС) и базовое логирование (РСБ), но меры по управлению правами доступа (УПД), антивирусной защите (АВЗ) и защите носителей (ЗНИ) остаются за оператором.

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

Когда оператор размещает ИСПДн у облачного провайдера, провайдер становится лицом, осуществляющим обработку ПДн по поручению оператора (п. 3 ст. 6 ФЗ-152). Это не освобождает оператора от ответственности: если провайдер допустит утечку, штраф по ст. 13.11 КоАП получит именно оператор.

Поручение на обработку должно содержать: перечень действий, которые провайдер вправе совершать с ПДн; цели обработки; обязанность провайдера соблюдать конфиденциальность; обязанность принять меры защиты по ст. 19 ФЗ-152; запрет передавать ПДн третьим лицам без согласия оператора. Типовые DPA (Data Processing Agreement) Яндекс.Облака, VK Cloud и MTS Cloud содержат большинство этих элементов, но требуют проверки на соответствие именно вашей модели угроз и УЗ.

Отдельный вопрос — мультиарендная SaaS-архитектура. Если платформа обслуживает нескольких корпоративных клиентов (арендаторов), каждый из которых является самостоятельным оператором своих пользовательских ПДн, то SaaS-компания выступает обработчиком по поручению каждого арендатора. Договор с каждым арендатором должен включать поручение в смысле п. 3 ст. 6. Отсутствие такого поручения означает, что SaaS-компания обрабатывает ПДн без законного основания — состав по ч. 1 ст. 13.11 КоАП (150 000–300 000 ₽).

Обезличивание для ML: как не превратить датасет в нарушение?

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

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

Логирование действий пользователей (event logs, audit trails) также может содержать ПДн: IP-адрес, идентификатор сессии, данные об устройстве в сочетании с временными метками позволяют идентифицировать конкретное лицо. Хранение логов в облачном объектном хранилище (например, Яндекс Object Storage или VK Cloud S3) должно быть предусмотрено в модели угроз и включено в поручение обработки.

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

Сценарий 1 — Миграция продуктовой базы с AWS на Яндекс.Облако. Компания из Центрального ФО (осень 2025) перенесла PostgreSQL-кластер с пользовательскими ПДн из AWS eu-west-1 в Яндекс.Облако (регион ru-central1). Первичный сбор ПДн на этапе регистрации пользователей по-прежнему шёл через CDN с точкой присутствия во Франкфурте, где данные кэшировались на 300 мс до передачи в Москву. При плановой проверке РКН квалифицировал кэш как «хранение» по смыслу ч. 5 ст. 18 ФЗ-152, возбудив дело по ч. 8 ст. 13.11. Компания оспорила квалификацию в арбитражном суде региона, приводя технические логи с подтверждением транзитного характера кэша; рассмотрение продолжается. Стратегия для CTO: маршрутизировать регистрационный трафик только через российские точки входа ещё до миграции баз данных.

Сценарий 2 — SaaS для HR-tech (Северо-Западный ФО, начало 2026). Платформа обслуживала 40 корпоративных клиентов-операторов. ПДн сотрудников каждого клиента хранились в общем кластере VK Cloud без разделения на уровне логических баз данных. При проверке по жалобе субъекта РКН установил отсутствие индивидуальных DPA с каждым из 40 клиентов. Квалификация — ч. 1 ст. 13.11 КоАП (150 000–300 000 ₽ за каждый факт). Компания урегулировала вопрос до вынесения постановления, подписав стандартизированный DPA со всеми арендаторами и получив предупреждение по ст. 4.1.1 КоАП. Стратегия: в мультиарендной SaaS вести реестр DPA с каждым клиентом-оператором как обязательный ОРД-документ.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

Локализация ПДн в российском облаке — это не только выбор дата-центра провайдера, но и корректное определение УЗ, грамотно оформленное поручение обработки с каждым обработчиком и контроль маршрутизации первичного сбора данных. После 01.07.2025 схема «первичный сбор за рубежом + реплика в России» является нарушением ч. 5 ст. 18 ФЗ-152 с прямым составом по ч. 8 ст. 13.11 КоАП. Дополнительный риск — обезличивание датасетов для ML: псевдонимизация не заменяет обезличивание по методам РКН.

DATUM сопровождает перевод ИСПДн в отечественные облака: от определения УЗ и составления модели угроз до проверки DPA с Яндекс.Облаком, VK Cloud или MTS Cloud и подготовки полного пакета ОРД.

28 апреля 2029 года