Гибридное облако и 152-ФЗ
Регулирование гибридных облаков по 152-ФЗ сформировалось не в одной норме, а в пересечении нескольких: требования к локализации (ч. 5 ст. 18 ФЗ-152), уровни защищённости из ПП РФ №1119, технические меры по Приказу ФСТЭК №21, режим поручения обработки (п. 3 ст. 6 ФЗ-152) и, с 2025 года, регулирование обезличенных данных для ML (ст. 13.1 ФЗ-152). Для CTO это означает архитектурные решения, которые одновременно удовлетворяют инженерным и правовым требованиям. Статья разбирает каждый из этих блоков и показывает, где типичная гибридная схема создаёт реальные правовые риски.
Как определить уровень защищённости для гибридной ИСПДн?
Уровень защищённости (УЗ) информационной системы персональных данных (ИСПДн) определяется по трём осям: категория обрабатываемых ПДн, тип актуальных угроз и количество субъектов. Все три параметра закреплены в ПП РФ №1119 от 01.11.2012.
Категории данных образуют четыре класса: специальные (здоровье, политические взгляды, судимость по ст. 10 ФЗ-152), биометрические (ст. 11 ФЗ-152), иные персональные данные и общедоступные. Для гибридного облака критичен вопрос: если специальные ПДн хранятся в приватном контуре, а их метаданные или производные — в публичном облаке, категория системы в целом определяется по наиболее чувствительному типу данных во всей распределённой системе.
Порог в 100 000 субъектов разделяет УЗ-3 и УЗ-2 при иных равных условиях для ИСПДн с «иными» ПДн (не специальными, не биометрическими). SaaS-платформа с мультиарендной архитектурой, обрабатывающая данные сотрудников нескольких корпоративных клиентов, легко пересекает этот порог суммарно по всем арендаторам — даже если для каждого отдельного клиента данных меньше 100 000.
Тип актуальных угроз — зона ответственности CTO. Угрозы 1-го и 2-го типа связаны с недокументированными возможностями в ПО и требуют формального моделирования угроз. Для большинства коммерческих SaaS-платформ, не использующих специально сертифицированную ОС или СУБД, актуальны угрозы как минимум 2-го типа, что при наличии специальных ПДн сразу поднимает планку до УЗ-2. Использование публичного облака иностранного провайдера без сертифицированных средств защиты информации автоматически означает невозможность исключить угрозы 1-го типа — это УЗ-1 по ПП РФ №1119.
Не уверены, какой УЗ применим к вашей гибридной платформе?
Ошибка в определении уровня защищённости означает неверный состав технических мер по Приказу ФСТЭК №21. Это основание для предписания РКН при плановой проверке и штрафа по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽ за первое нарушение, 300–500 тыс. ₽ — при повторном). Юристы и технические консультанты DATUM проведут аудит ИСПДн по чек-листу из 38 пунктов и определят актуальный УЗ с обоснованием модели угроз.
Заказать аудит 152-ФЗОтветим за 2 часа · +7 (983) 510-38-76 · info@vitveteam.ru
Какие требования ФСТЭК обязательны для гибридного облака?
Приказ ФСТЭК №21 от 18.02.2013 устанавливает меры защиты в 15 группах — от идентификации и аутентификации (ИАФ) до обеспечения целостности (ОЦЛ) и защиты информационной инфраструктуры (ЗИС). Для каждого УЗ определён базовый набор мер; оператор вправе адаптировать его с учётом актуальных угроз, но не опускаться ниже базового.
В гибридной архитектуре ключевая сложность — распределение мер между приватным и публичным контурами. Публичный облачный провайдер отвечает за физическую безопасность инфраструктуры и, как правило, за гипервизорный уровень. Меры на уровне ОС, СУБД, сетевого периметра и прикладного ПО — ответственность оператора ПДн. Если провайдер не предоставляет сертифицированные СЗИ (средства защиты информации), оператор обязан развернуть их самостоятельно поверх инфраструктуры провайдера.
Наиболее частые пробелы в гибридных схемах по данным проверок:
- Отсутствие регистрации событий безопасности (группа РСБ) в публичном облаке — логи остаются у провайдера и недоступны оператору в нужном формате.
- Нет разграничения доступа (УПД) между арендаторами в мультиарендной SaaS — данные клиента А технически доступны администратору клиента Б.
- Отсутствие антивирусной защиты (АВЗ) на виртуальных машинах в публичном контуре — провайдер её не обеспечивает, оператор не установил.
- Нет контроля съёмных носителей (ЗНИ) — в гибридных схемах с DevOps-пайплайнами данные могут копироваться на локальные машины разработчиков.
Локализация ПДн в гибридном облаке: что изменилось с 01.07.2025?
Требование локализации по ч. 5 ст. 18 ФЗ-152 действует с 01.09.2015, но ФЗ-233 от 08.08.2024 ужесточил его применение с 01.07.2025: теперь не только хранение, но и первичный сбор, систематизация и накопление ПДн граждан РФ должны происходить в базах данных на территории России. Это прямо затрагивает гибридные схемы, в которых данные первично поступают в зарубежное облако (например, через CDN-узел, расположенный за рубежом), а затем реплицируются в российский контур.
Штраф за нарушение локализации по ч. 8 ст. 13.11 КоАП составляет 1–6 млн ₽ для юрлица; при повторном нарушении по ч. 9 — 6–18 млн ₽. РКН фиксирует нарушения локализации в ходе плановых и внеплановых проверок, а также по жалобам субъектов.
Для гибридного облака безопасная схема выглядит так: все операции первичной записи, систематизации и хранения ПДн граждан РФ — только в российском контуре (on-premise или сертифицированное российское облако). Публичный зарубежный контур допустим для обработки обезличенных данных, аналитики на агрегированных показателях, хранения не-ПДн.
Что подготовить CTO для соответствия 152-ФЗ в гибридном облаке
- Акт определения уровня защищённости ИСПДн с моделью угроз, подписанный уполномоченным лицом (основание — ПП РФ №1119).
- Перечень мер защиты по Приказу ФСТЭК №21 с указанием, какие меры реализованы в приватном контуре, какие — в публичном, и кем.
- Договор-поручение с облачным провайдером по п. 3 ст. 6 ФЗ-152: перечень операций, цели, обязанность провайдера соблюдать конфиденциальность и применять меры защиты.
- Схема потоков данных с маркировкой: какие ПДн, из каких систем, в какой контур передаются, включая CDN и резервные копии.
- Журнал событий безопасности с настроенным экспортом из публичного контура в российскую систему мониторинга (требование группы РСБ, Приказ ФСТЭК №21).
Как правильно оформить поручение обработки ПДн облачному провайдеру?
По п. 3 ст. 6 ФЗ-152 оператор вправе поручить обработку ПДн третьему лицу на основании договора или иного документа. Ключевые условия: договор должен содержать перечень разрешённых действий с ПДн, цели обработки, обязанность соблюдать конфиденциальность и применять меры защиты, соответствующие требованиям 152-ФЗ. Провайдер при этом не становится самостоятельным оператором — он действует в интересах и по инструкциям оператора.
Три типичные ошибки при оформлении поручения в гибридных схемах:
- Ссылка на стандартные условия провайдера (Terms of Service). ToS иностранного провайдера не содержат обязательств, предусмотренных п. 3 ст. 6 ФЗ-152. Договор-поручение — отдельный документ.
- Неполный перечень действий. Если провайдер выполняет резервное копирование, репликацию, шифрование — каждое действие должно быть указано явно. «Хранение данных» не покрывает «передачу данных между дата-центрами провайдера».
- Отсутствие права аудита. Оператор отвечает за действия провайдера как за собственные (ч. 5 ст. 6 ФЗ-152). Без договорного права на проверку провайдера оператор не может подтвердить соответствие мер защиты.
В мультиарендной SaaS возникает дополнительный вопрос о роли: является ли SaaS-платформа оператором в отношении данных своих клиентов или лицом, осуществляющим обработку по поручению клиента-оператора? Ответ зависит от того, кто определяет цели и состав обработки. Если клиент самостоятельно определяет, какие данные загружать и для чего, — платформа, как правило, выступает обработчиком по поручению. Если платформа использует данные для собственных целей (аналитика, улучшение сервиса, обучение моделей) — она становится соопоратором по этим целям.
Если ваша SaaS-платформа обрабатывает ПДн клиентов и вы не уверены в статусе оператора/обработчика — РКН при проверке квалифицирует это как обработку без правового основания (ч. 1 ст. 13.11 КоАП, штраф 150–300 тыс. ₽ за первичное, 300–500 тыс. ₽ при повторном). Срок включения в реестр операторов после уведомления — 30 дней (ч. 4 ст. 22 ФЗ-152).
Заказать аудит 152-ФЗЧто такое обезличивание для ML и как оно работает в гибридной архитектуре?
Ст. 13.1 ФЗ-152 (введена ФЗ-233 от 08.08.2024) ввела регулирование обезличенных персональных данных. С 2025 года для передачи обезличенных данных в федеральную государственную систему (ЕИП НСУД) применяются методы, утверждённые Приказом РКН. Для коммерческих операторов, использующих обезличивание в целях ML, этот приказ задаёт де-факто стандарт допустимых методов.
Регулятор выделяет пять методов обезличивания: введение идентификаторов (замена прямых идентификаторов на псевдонимы), изменение состава и семантики (удаление или замена атрибутов), декомпозиция (разделение набора данных на части, не позволяющие идентификацию по отдельности), перемешивание (изменение порядка записей для разрыва связей), обобщение и агрегация (замена точных значений диапазонами или статистическими показателями).
Для ML-пайплайна в гибридном облаке это означает: обезличивание должно происходить в российском контуре (в рамках локализованной ИСПДн) до передачи данных в публичный облачный контур для обучения моделей. Если обезличивание производится уже в зарубежном облаке — это передача ПДн за рубеж, требующая либо уведомления РКН (ст. 12 ФЗ-152), либо наличия адекватной защиты в стране назначения.
Критически важен вопрос качества обезличивания. Данные считаются обезличенными, только если идентификация субъекта невозможна без несоразмерных усилий. Псевдонимизация (замена имени на идентификатор при сохранении ключа соответствия) — не обезличивание в смысле ст. 3 ФЗ-152. Модель, обученная на псевдонимизированных данных и способная по косвенным признакам идентифицировать субъектов (membership inference attack), работает с ПДн — и вся архитектура обучения подпадает под требования 152-ФЗ.
Типичные правовые сценарии в гибридных облачных архитектурах
Сценарий 1. SaaS-платформа использует AWS/Azure для обработки данных российских пользователей. Ситуация: CTO выбрал иностранный облачный провайдер для масштабируемости. Данные клиентов реплицируются в регион EU. Доказательства нарушения: технический маршрут трафика, данные whois о расположении серверов, отсутствие уведомления о трансграничной передаче в реестре РКН. Вероятный исход: предписание об устранении нарушения локализации + штраф по ч. 8 ст. 13.11 КоАП (1–6 млн ₽). Стратегия: либо перевод первичной обработки в российский регион провайдера (AWS GovCloud недоступен, но есть Yandex Cloud, SberCloud, МТС Cloud), либо использование зарубежного облака только для обработки обезличенных данных. Договор-поручение с провайдером — обязателен.
Сценарий 2. Утечка данных через compromised DevOps-пайплайн в гибридной схеме. Ситуация: разработчик имел доступ к production-данным через CI/CD-систему, развёрнутую частично в публичном облаке. Инцидент затронул 15 000 субъектов. Доказательства: логи CI/CD-системы, данные DLP, результаты форензики. Исход без надлежащего реагирования: неуведомление РКН в 24 часа — штраф по ч. 11 ст. 13.11 КоАП (1–3 млн ₽) в дополнение к штрафу за саму утечку по ч. 12 (3–5 млн ₽). Стратегия: немедленная изоляция CI/CD-контура, параллельное первичное уведомление РКН в рамках 24 часов по Приказу РКН №187, через 72 часа — отчёт с описанием технических мер устранения. Отдельное правовое основание: ст. 272.1 УК РФ применима к инсайдеру, если умысел доказан.
Сценарий 3. ML-модель обучена на ПДн без обезличивания и развёрнута в иностранном облаке. Ситуация: data science команда обучила модель рекомендаций на полных данных пользователей, модель развёрнута в EU-регионе AWS. CTO не участвовал в принятии решения. Исход: передача ПДн за рубеж без уведомления РКН — нарушение ст. 12 ФЗ-152, трансграничная передача без правового основания; при последующей утечке — ч. 12–14 ст. 13.11 КоАП. Стратегия: ретроспективное обезличивание датасета, уведомление РКН о трансграничной передаче либо перенос инференса в российский регион, фиксация правового заключения в документации проекта.
Как это применяется на практике
Кейс 1. IT-компания (Сибирский ФО, осень 2025) использовала гибридную архитектуру: on-premise-кластер для хранения ПДн клиентов + публичное облако EU-провайдера для ML-обработки. CTO не оформил договор-поручение с провайдером и не уведомил РКН о трансграничной передаче. В ходе внеплановой проверки РКН установил факт передачи данных за рубеж без правового основания. Компания получила предписание об устранении и штраф в размере нескольких сотен тысяч рублей по ч. 1 ст. 13.11 КоАП. После аудита и переноса ML-пайплайна в российский регион предписание закрыто в установленный срок.
Кейс 2. Финтех-платформа (Центральный ФО, начало 2026) обрабатывала данные более 120 000 субъектов в мультиарендной SaaS на базе гибридного облака. Определённый оператором УЗ-4 не соответствовал фактическим параметрам системы: пороговое значение в 100 000 субъектов было превышено, что требовало УЗ-3 по ПП РФ №1119. Техническая экспертиза в рамках аудита DATUM выявила 14 мер Приказа ФСТЭК №21, не реализованных для УЗ-3. По итогам аудита CTO получил приоритизированный план устранения; внеплановая проверка РКН, инициированная жалобой субъекта, завершилась предписанием без штрафа — благодаря тому, что план устранения был документально зафиксирован до проверки.
Услуги DATUM по теме
- Аудит соответствия 152-ФЗ — определение УЗ, модель угроз, чек-лист по 38 пунктам
- DPIA (оценка воздействия) — для высокорисковой обработки в гибридных и облачных средах
- Комплект ОРД под ключ — договоры-поручения, политика, приказы, регламент реагирования
Частые вопросы
1. Какой УЗ выбрать для SaaS с мультиарендной архитектурой?
УЗ определяется по совокупности параметров: тип ПДн (специальные, биометрические или иные), тип актуальных угроз и количество субъектов — по ПП РФ №1119. Для мультиарендной SaaS количество субъектов считается суммарно по всем арендаторам. Если суммарно обрабатывается более 100 000 субъектов с «иными» ПДн при угрозах 3-го типа — УЗ-3. При угрозах 2-го типа (характерны для коммерческих приложений без сертифицированной ОС) — УЗ-2. Моделирование угроз и акт определения УЗ оформляются документально и хранятся у оператора как доказательство при проверке.
2. Можно ли использовать иностранные облака после ужесточения локализации с 01.07.2025?
Иностранные облака допустимы для операций, не связанных с первичным сбором, систематизацией, накоплением, хранением, уточнением и извлечением ПДн граждан РФ. Это значит: обработка обезличенных данных, хранение не-ПДн, аналитика на агрегированных показателях. Любые операции с персональными данными граждан РФ — только в базах данных на территории России (ч. 5 ст. 18 ФЗ-152). Трансграничная передача ПДн в страну без адекватной защиты требует уведомления РКН (ст. 12 ФЗ-152).
3. Что такое обезличивание для ML и чем оно отличается от псевдонимизации?
Обезличивание — приведение данных к виду, при котором идентификация субъекта без несоразмерных усилий невозможна (ст. 3 ФЗ-152). Регулятор утвердил пять методов: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение/агрегация. Псевдонимизация — замена идентификаторов с сохранением ключа соответствия — не является обезличиванием в смысле закона. Данные, псевдонимизированные с сохранением ключа, остаются ПДн и обрабатываются по всем требованиям 152-ФЗ. Для ML-пайплайна обезличивание должно происходить в российском контуре до передачи данных в зарубежное облако.
4. Кто является оператором ПДн в мультиарендной SaaS-платформе?
Если клиент SaaS самостоятельно определяет цели и состав обработки (загружает данные своих сотрудников или клиентов для своих бизнес-задач) — SaaS-платформа выступает лицом, осуществляющим обработку по поручению (п. 3 ст. 6 ФЗ-152), а клиент — оператором. Если платформа использует данные для собственных целей (улучшение сервиса, обучение моделей, реклама) — она соооператор по этим целям. В этом случае платформа обязана уведомить РКН и выполнять все требования оператора по ст. 18.1, 19, 22 ФЗ-152.
5. Какие СЗИ обязательны для ИСПДн в гибридном облаке?
Состав средств защиты информации определяется Приказом ФСТЭК №21 исходя из УЗ и модели угроз. Для УЗ-3 и УЗ-4 применение сертифицированных СЗИ рекомендовано, но не всегда обязательно — достаточно мер защиты, обеспечивающих нейтрализацию актуальных угроз. Для УЗ-1 и УЗ-2 сертифицированные СЗИ обязательны для нейтрализации угроз 1-го и 2-го типа соответственно. В гибридном облаке это означает: если угрозы 1-го или 2-го типа актуальны, использование несертифицированного иностранного облачного ПО (гипервизора, СУБД) формально создаёт неустранимый пробел в выполнении требований ФСТЭК.
Итог
Гибридное облако создаёт комплексную правовую задачу: правильно определить УЗ для распределённой ИСПДн, обеспечить соответствие мер защиты Приказу ФСТЭК №21 в обоих контурах, соблюсти требования локализации при первичном сборе данных, оформить поручение обработки с облачным провайдером и правильно квалифицировать роли в мультиарендной архитектуре. Каждый из этих элементов при проверке РКН анализируется отдельно, и ошибка в любом из них — самостоятельное основание для штрафа.
Практика DATUM по сопровождению IT-компаний и SaaS-платформ в части 152-ФЗ охватывает полный цикл: от определения УЗ и модели угроз до оформления договоров-поручений с облачными провайдерами и DPIA для высокорисковых сценариев обработки. Опыт сети «Ветров и партнёры» по защите ПДн — с 2014 года.
14 января 2029 года