Аттестация облачного провайдера по 152-ФЗ

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

Что такое уровень защищённости и как CTO выбирает УЗ для облака?

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

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

Практическая ошибка CTO: выбор УЗ «по минимуму» без документированной модели угроз. Роскомнадзор и ФСТЭК при проверке смотрят не на декларацию, а на обоснование. Если модель угроз не составлена или составлена формально — уровень защищённости оспаривается, и весь аттестационный пакет аннулируется.

Какие меры защиты обязательны по Приказу ФСТЭК №21 для облачного провайдера?

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

Для облачного провайдера ключевые группы — ЗСВ (защита среды виртуализации) и УПД (управление доступом в мультиарендной среде). Отсутствие изоляции виртуальных машин разных арендаторов — это автоматически нарушение ЗСВ.Б.1 и повод для вынесения предписания.

Базовый набор мер для каждого УЗ определяется таблицей Приказа №21: при УЗ-3 обязательны около 60 базовых мер из 109. Адаптация набора (исключение мер или компенсирующие меры) возможна только при наличии обоснования в техническом паспорте системы. Без этого обоснования инспектор ФСТЭК зафиксирует нарушение по каждой отсутствующей мере отдельно.

Мультиарендность SaaS: кто оператор и как разграничить ответственность?

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

Для правомерности поручения необходимо письменное соглашение, в котором закреплены: перечень ПДн, перечень действий, цели обработки, обязанность обеспечить конфиденциальность, технические меры по конкретному УЗ. Без такого соглашения провайдер обрабатывает ПДн без правового основания — это состав ч. 1 ст. 13.11 КоАП, штраф 150–300 тыс. ₽ за каждый tenant-договор.

Критическая точка для SaaS — смешение данных разных tenants в одной таблице БД или в едином хранилище логов. Если физическое или логическое разграничение не обеспечено, провайдер фактически обрабатывает ПДн нескольких операторов одновременно без их ведома. При проверке РКН это квалифицируется как нарушение ч. 1 ст. 13.11 по каждому оператору отдельно.

Локализация и иностранные облака: что изменилось с 01.07.2025?

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

С 01.07.2025 ФЗ-233 ужесточил трактовку: первичный сбор ПДн теперь также должен происходить в российской инфраструктуре. Это означает, что форма на сайте, мобильное приложение или API-запрос, направляющий данные напрямую в зарубежный облачный сервис, формально нарушает ч. 5 ст. 18, даже если потом данные реплицируются в РФ.

Для CTO это означает: Salesforce, HubSpot, AWS без российской зоны доступности, Google Analytics 4 с передачей сырых событий на серверы за рубежом — каждый из этих инструментов требует либо замены, либо архитектурного решения (прокси, локальная копия). Иностранное облако допустимо только для данных, не содержащих ПДн граждан РФ, или для обезличенных данных после применения утверждённых методов.

Обезличивание для ML: как использовать ПДн в моделях легально?

Обучение ML-моделей на реальных ПДн без надлежащего правового основания — распространённая серая зона. Если данные используются для целей, не указанных в согласии субъекта, это нарушение принципа ограничения цели (ст. 5 ФЗ-152) и состав ч. 1 ст. 13.11 КоАП. Выход — обезличивание данных до обучения модели.

С 2025 года действует приказ РКН, утверждающий пять методов обезличивания: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. После применения хотя бы одного из этих методов данные перестают считаться персональными, и ограничения ФЗ-152 к ним не применяются.

На практике: метод обобщения (замена точного значения диапазоном — возраст 34 → «30–40») достаточен для большинства задач классификации. Метод введения идентификаторов (замена ФИО и контактов на UUID с хранением таблицы соответствия отдельно) сохраняет связность данных для персонализации, но исключает возможность идентификации по основному датасету.

Важно: обезличивание должно быть задокументировано. Без акта о применении метода, описания параметров и заключения об остаточном риске де-анонимизации данные считаются необезличенными. Это позиция РКН, подтверждённая в разъяснениях регулятора 2024–2025 годов.

Логирование как ПДн: какие журналы создают риск?

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

Для Приказа ФСТЭК №21 регистрация событий (группа РСБ) обязательна для всех УЗ. Одновременно хранение логов без ограничения срока нарушает принцип минимизации ст. 5 ФЗ-152. Коллизия решается так: срок хранения логов устанавливается политикой (типично 6–12 месяцев для операционных, 36 месяцев для аудит-трейлов), по истечении — уничтожение с актом.

Отдельный риск — SIEM и системы мониторинга, агрегирующие логи от нескольких tenants в едином хранилище. Без логического разграничения по tenant-ID это смешение ПДн разных операторов. При использовании облачного SIEM (в том числе зарубежного) применяется требование локализации в полном объёме.

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

Сценарий 1. Провайдер проходит аттестацию самостоятельно. IT-компания (Сибирский ФО, весна 2025) эксплуатировала облачную платформу для клиентов — операторов ПДн с данными сотрудников. CTO запросил аттестат у лицензиата ФСТЭК. В ходе предаттестационного обследования выяснилось: модель угроз не составлена, меры группы ЗСВ частично отсутствуют (нет изоляции образов VM), логи хранятся без ограничения срока. Провайдер устранил нарушения за 4 месяца, после чего получил аттестат УЗ-3. Стоимость устранения превысила стоимость первоначального аудита в 3 раза.

Сценарий 2. Заказчик проверяет провайдера при заключении договора. Медицинская информационная система (Центральный ФО, начало 2026) выбирала облако для МИС с данными пациентов (специальные ПДн, требуется не ниже УЗ-2). При due diligence выяснилось: аттестат провайдера выдан на УЗ-3, не охватывает специальные категории; соглашение о поручении обработки отсутствует. Провайдер был заменён. Разрыв контракта обошёлся дешевле, чем штраф по ч. 12 ст. 13.11 КоАП при утечке медицинских ПДн (3–5 млн ₽ за 1 000–10 000 субъектов).

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

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

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

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

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

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

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

3. Что такое обезличивание для ML и какие методы признаёт РКН?

Обезличивание для ML — приведение датасета к виду, при котором субъект не идентифицируется и не идентифицируем без дополнительной информации. РКН утвердил пять методов: введение идентификаторов (псевдонимизация), изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Применение должно быть задокументировано актом с оценкой остаточного риска де-анонимизации. Без документирования данные считаются необезличенными.

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

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

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

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

Итог

Аттестация облачного провайдера по 152-ФЗ — это не разовая бюрократическая процедура, а постоянный процесс: модель угроз, выбор УЗ, реализация мер по Приказу №21, соглашения с tenants и документирование обезличивания. Ошибки в любом из этих элементов создают риски от 150 тыс. до 18 млн ₽ по ст. 13.11 КоАП плюс уголовную ответственность по ст. 272.1 УК при умышленной утечке.

DATUM сопровождает IT-компании и облачных провайдеров в подготовке к аттестации: от модели угроз и выбора УЗ до пакета соглашений о поручении обработки и документирования обезличивания для ML.