Bare metal vs виртуализация: 152-ФЗ

Технические директора задают этот вопрос на аудитах всё чаще: можно ли закрыть требования 152-ФЗ на гипервизоре, или специальные категории ПДн требуют физической изоляции? С ужесточением ст. 13.11 КоАП в редакции ФЗ-420 от 30.11.2024 цена ошибки в архитектуре выросла кратно. В материале — разбор по уровням защищённости, позиция ФСТЭК по виртуализации, кейсы из практики и ответы на типовые вопросы CTO.

Что требует 152-ФЗ от инфраструктуры: УЗ-1, УЗ-2, УЗ-3, УЗ-4?

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

Для SaaS-платформы с общими данными пользователей и числом субъектов до 100 000 при угрозах 3-го типа обычно достаточен УЗ-3. Если платформа обрабатывает состояние здоровья, биометрию или число субъектов превышает 100 000 — автоматически возникает УЗ-2 или УЗ-1. Именно здесь начинается архитектурный выбор.

Ключевое следствие: УЗ-1 и УЗ-2 предписывают меры по защите от угроз, связанных с недокументированными возможностями системного программного обеспечения — то есть гипервизора. УЗ-3 и УЗ-4 таких требований явно не содержат, что открывает дорогу к виртуализации без особых ограничений.

Чем bare metal отличается от виртуализации с точки зрения Приказа ФСТЭК №21?

Приказ ФСТЭК №21 описывает меры защиты в 15 группах (ИАФ, УПД, ОПС, ЗНИ, РСБ, АВЗ, СОВ, АНЗ, ОЦЛ, ОДТ, ЗСВ, ЗТС, ЗИС, УКФ, ОПО). Группа ЗСВ — защита среды виртуализации — существует только при наличии виртуализации. На bare metal эта группа мер просто не применяется.

На практике это означает следующее. Bare metal при УЗ-1 и УЗ-2 — меньше поверхность атаки через гипервизор, проще прохождение аттестации. Виртуализация при тех же УЗ — добавляет ЗСВ-меры, которые в ряде случаев невозможно закрыть сертифицированными средствами без существенных затрат.

При УЗ-3 и УЗ-4 виртуализация допустима без аттестации виртуальной среды как критического контрола. Достаточно корректно реализовать ЗСВ-меры через штатные инструменты гипервизора и дополнительные СЗИ — это закрывает требования ФСТЭК для большинства коммерческих ИСПДн.

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

Мультиарендность — архитектура, при которой несколько клиентов обрабатывают ПДн в одной инфраструктуре с логической изоляцией. С точки зрения 152-ФЗ здесь возникает вопрос: кто оператор, а кто осуществляет обработку по поручению?

Для SaaS-провайдера, размещающего ИСПДн клиентов на общем кластере, ситуация выглядит так: клиент — оператор, SaaS-провайдер — обработчик по поручению. Это означает, что УЗ определяет клиент-оператор исходя из своих ПДн. Провайдер обязан обеспечить инфраструктуру, отвечающую максимальному УЗ среди всех арендаторов — либо изолировать арендаторов с разными УЗ на уровне физического или логического сегментирования.

На виртуализированной инфраструктуре логическая изоляция арендаторов закрывается политиками гипервизора, сетевой сегментацией (VLAN, микросегментация) и контролем доступа к образам ВМ. Без этих мер смешение ПДн разных арендаторов — прямое нарушение ст. 5 ФЗ-152 (принцип несовместимости целей). На bare metal изоляция физическая: арендатор получает выделенный сервер, что упрощает доказательство соответствия при аттестации.

Можно ли использовать иностранные облака после ужесточения локализации с 01.07.2025?

С 01.07.2025 требования к локализации ужесточены в части первичного сбора и систематизации ПДн граждан РФ: запись, систематизация, накопление, хранение, уточнение и извлечение — только в базах на территории РФ (ч. 5 ст. 18 ФЗ-152, в ред. ФЗ-233 от 08.08.2024). Иностранное облако как первичная база — прямое нарушение.

Что это означает практически для CTO. Salesforce, HubSpot, AWS в регионе eu-west, Azure West Europe — нарушение локализации, если в них ведётся первичная запись ПДн граждан РФ. Допустимая схема: первичная база в РФ (bare metal или виртуализация у российского хостера), репликация или API-интеграция с зарубежным сервисом только для вторичной обработки, предварительно обезличенных или агрегированных данных.

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

Как обезличивание для ML меняет архитектурные требования?

ML-пайплайны работают с большими массивами данных: обучение моделей, ретроспективный анализ поведения, скоринг. Если в обучающей выборке — персональные данные в исходном виде, это полноценная обработка ПДн с соответствующим УЗ и требованиями ФСТЭК. Обезличивание снимает часть требований.

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

Архитектурно это означает: ML-датасеты можно хранить на виртуализированной инфраструктуре с более низкими требованиями, если обезличивание проведено корректно и задокументировано. Вычислительный кластер для обучения моделей на обезличенных данных — не ИСПДн. Это прямо влияет на выбор между bare metal и облаком для ML-слоя.

Логирование как ПДн: что фиксировать и как хранить?

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

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

На bare metal хранение логов в отдельном физическом томе или выделенном сервере — стандартная практика. На виртуализированной инфраструктуре логи необходимо выводить во внешнее хранилище, физически или логически изолированное от ВМ с ИСПДн, чтобы скомпрометированная ВМ не давала доступа к журналам безопасности. Это требование группы РСБ, и оно одинаково применяется к обоим типам инфраструктуры.

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

Кейс 1. Финтех-компания (Центральный ФО, весна 2025) мигрировала CRM и аналитическую платформу с AWS на российский публичный облачный провайдер. УЗ ИСПДн — 3 (общие ПДн, угрозы 3-го типа, число субъектов до 100 000). Виртуализация на гипервизоре была признана допустимой после оформления договора поручения обработки и внедрения мер группы ЗСВ. Аудит DATUM выявил отсутствие модели угроз и актуального уведомления в реестре РКН — оба документа были оформлены до начала миграции, штрафные риски по ч. 10 ст. 13.11 (100–300 тыс. ₽) устранены.

Кейс 2. EdTech-платформа (Сибирский ФО, осень 2025) обрабатывала ПДн несовершеннолетних на виртуализированном кластере без выделения под УЗ-2 (специальная категория — сведения о состоянии здоровья для сопровождения детей с ОВЗ). РКН провёл внеплановую проверку по жалобе. По итогам — предписание и штраф по ч. 1 ст. 13.11 в сотни тысяч рублей. После привлечения DATUM платформа разделила ИСПДн: данные несовершеннолетних с ОВЗ перенесены на выделенные физические ноды с УЗ-2, остальные — оставлены на виртуализации под УЗ-3.

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

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

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

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

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

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

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

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

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

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

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

5. Какие СЗИ обязательны при виртуализации?

При виртуализации в ИСПДн Приказ ФСТЭК №21 предписывает меры группы ЗСВ: контроль целостности гипервизора и образов ВМ, изоляция ВМ между собой, ограничение доступа к среде управления виртуализацией. Для УЗ-1 и УЗ-2 применяемые СЗИ должны иметь сертификат ФСТЭК соответствующего класса. Для УЗ-3 и УЗ-4 допустимо использование встроенных средств защиты гипервизора (VMware, KVM, Hyper-V) при их корректной настройке и документировании.

Итог

Bare metal остаётся обоснованным выбором для УЗ-1 и УЗ-2: меньше поверхность атаки, проще аттестация, нет группы мер ЗСВ по ФСТЭК. Виртуализация закрывает требования 152-ФЗ для УЗ-3 и УЗ-4 при корректной реализации ЗСВ-мер, физической локализации в РФ и надлежащем договоре поручения. ML-слой на обезличенных данных может быть полностью выведен за периметр ИСПДн — при условии, что обезличивание реализовано по методам РКН и задокументировано.

Юристы и технические консультанты DATUM сопровождают выбор инфраструктуры для ИСПДн на этапе проектирования: определение УЗ, разработка модели угроз, оформление поручения обработки с провайдером, подготовка ОРД под архитектуру.