СЗИ в облаке: что обязательно

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

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

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

Для типового SaaS-продукта с иными ПДн пользователей (ФИО, email, телефон) и угрозами 3-го типа результат — УЗ-3, если субъектов менее 100 000, и УЗ-2, если более. Медицинская платформа со специальными ПДн (состояние здоровья по ст. 10 ФЗ-152) при угрозах 3-го типа и любом числе субъектов — УЗ-3. При угрозах 2-го типа — сразу УЗ-2.

Тип угрозы — ключевой рычаг. Большинство операторов обоснованно выбирают угрозы 3-го типа: недекларированные возможности в системном ПО признаются неактуальными при наличии организационных мер и сертифицированного ПО. Это снижает итоговый УЗ на одну ступень. Обоснование типа угроз фиксируется в модели угроз — документе, который CTO подписывает вместе с ответственным за защиту ПДн.

В мультиарендной SaaS каждый арендатор фактически создаёт отдельную ИСПДн. Если один клиент обрабатывает специальные ПДн (медицина, HR с биометрией для СКУД), а другой — только иные, итоговый УЗ для всей инфраструктуры определяется по наиболее высокому требованию. Это означает, что архитектура мультиарендности должна обеспечивать изоляцию потоков данных на уровне, достаточном для УЗ самого требовательного арендатора.

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

Приказ ФСТЭК №21 от 18.02.2013 определяет 109 мер в 15 группах. Базовый набор мер привязан к уровню защищённости: УЗ-4 — минимальный набор, УЗ-1 — максимальный. Каждую меру оператор либо реализует, либо обосновывает неприменимость и компенсирует альтернативой.

Для облачных ИСПДн наиболее критичны следующие группы мер.

ИАФ (идентификация и аутентификация). Для УЗ-3 и выше — многофакторная аутентификация административных учётных записей обязательна. В облаке это означает MFA для доступа к консоли управления (AWS IAM, Yandex Cloud IAM, VK Cloud), а не только для пользователей приложения. Привилегированный доступ через PAM-решение — рекомендуется уже с УЗ-3.

УПД (управление правами доступа). Принцип минимальных привилегий на уровне ролей облачного провайдера. Для мультиарендной SaaS — изоляция ролей между арендаторами на уровне IAM-политик. Это одновременно мера защиты по Приказу №21 и требование к архитектуре поручения обработки.

РСБ (регистрация событий безопасности). Логи доступа к ПДн, изменений конфигурации и событий безопасности — обязательны. Срок хранения логов нормативно не установлен Приказом №21, но в модели угроз рекомендуется обосновывать не менее 6 месяцев. Важный нюанс: логи, содержащие записи о действиях с ПДн конкретных субъектов, сами по себе являются ПДн — Роскомнадзор последовательно придерживается этой позиции.

АВЗ (антивирусная защита). Требуется с УЗ-4. В облачной среде это означает защиту образов виртуальных машин и контейнеров, а не только хостов. Для контейнерных оркестраторов (Kubernetes) — сканирование образов в CI/CD-пайплайне как часть мер группы АВЗ.

ЗИС (защита информационной системы). Сегментация сети, межсетевое экранирование, защита от несанкционированного доступа извне. В публичном облаке реализуется через Security Groups, WAF и VPC-политики провайдера — при условии, что эти инструменты сертифицированы ФСТЭК или применяются совместно с сертифицированными наложенными средствами.

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

Когда оператор передаёт обработку ПДн облачному провайдеру, возникают отношения поручения по п. 3 ст. 6 ФЗ-152. Провайдер становится лицом, осуществляющим обработку по поручению, — но оператором не является. Ответственность перед субъектом остаётся у оператора.

Договор с провайдером должен содержать: исчерпывающий перечень действий с ПДн (хранение, резервное копирование, передача в рамках отказоустойчивости), цели обработки, обязанность провайдера соблюдать ФЗ-152, конкретный перечень мер защиты, запрет на передачу ПДн третьим лицам без согласия оператора и обязанность уведомить об инциденте в течение, достаточном для соблюдения оператором 24-часового срока по ч. 3.1 ст. 21 ФЗ-152.

На практике крупные облачные провайдеры в РФ (Yandex Cloud, VK Cloud, SberCloud) предлагают типовые приложения о поручении обработки ПДн. Но типовой документ не закрывает специфику конкретной ИСПДн: перечень действий в нём обычно максимально широкий, а обязательства по срокам уведомления об инцидентах — размытые. CTO должен убедиться, что договорная конструкция не создаёт разрыв между фактическими возможностями и нормативными требованиями.

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

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

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

Для обезличивания в ML-пайплайне важны два критерия. Первый: метод должен исключать возможность деобезличивания без дополнительных данных, которые хранятся отдельно и с ограниченным доступом. Второй: процесс обезличивания должен быть задокументирован — какой метод применён, к каким полям, кто имеет доступ к таблице соответствия идентификаторов.

В контексте облачного ML-пайплайна это означает: исходный датасет с ПДн хранится в защищённом хранилище с доступом по минимальным привилегиям (ИАФ + УПД по Приказу №21), обезличенный датасет передаётся в вычислительный кластер по поручению обработки, таблица соответствия — в отдельном изолированном хранилище с аудитом доступа.

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

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

Кейс 1. IT-компания (Северо-Западный ФО, начало 2026) развернула мультиарендную SaaS-платформу для HR-клиентов. Один из арендаторов начал обрабатывать биометрические данные сотрудников (фото для СКУД). Модель угроз и УЗ были определены на этапе запуска под иные ПДн (УЗ-3), пересмотр при изменении состава данных не проводился. При внеплановой проверке РКН установил, что фактический состав обработки требует УЗ-2, а часть мер Приказа №21 для УЗ-2 не реализована. По итогам вынесено предписание об устранении нарушений и составлен протокол по ч. 1 ст. 13.11 КоАП. Штраф по ч. 1 — в диапазоне 150 000–300 000 ₽. Для компании с выручкой свыше 500 млн ₽ реальная проблема не в сумме штрафа, а в предписании: его исполнение потребовало переработки архитектуры хранения биометрии и внедрения дополнительных СЗИ суммарной стоимостью значительно выше штрафа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

СЗИ в облаке — это не отдельный продукт, который можно подключить после запуска. Это архитектурное решение, которое начинается с расчёта УЗ по ПП РФ №1119, продолжается выбором мер по Приказу ФСТЭК №21 и заканчивается корректным договором поручения обработки с облачным провайдером. Каждый из этих шагов влияет на легальность всей конструкции.

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

3 июня 2026 года