Шифрование данных в облаке (at rest, in transit)

Переход бизнеса в облако создаёт три слоя регуляторного риска: выбор уровня защищённости (УЗ) по ПП РФ №1119, применение мер ФСТЭК по Приказу №21 и соблюдение требований локализации по ч. 5 ст. 18 ФЗ-152. Шифрование данных в облаке — at rest (данные в хранилище) и in transit (данные в передаче) — пересекает все три слоя. В этой статье разбираем, как эти требования применяются к SaaS-архитектуре и мультиарендным средам, что обязательно по нормативу, а что — рекомендация.

Что требует закон: УЗ-1..4, ст. 19 ФЗ-152 и Приказ ФСТЭК №21

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

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

Ключевое разграничение для CTO: базовый набор мер по Приказу №21 — это минимум для конкретного УЗ. Оператор вправе адаптировать набор (исключить неприменимые меры или добавить компенсирующие), но обязан документально обосновать каждое изменение. Без такого обоснования любое отклонение от базового набора — нарушение.

Шифрование at rest: что считается достаточным по ФСТЭК?

Шифрование данных в покое (at rest) в контексте Приказа №21 относится к группам ЗНИ (защита носителей информации) и ЗИС (защита информационной системы). Для УЗ-3 обязателен контроль использования съёмных машинных носителей (ЗНИ.1) и их шифрование при хранении вне контролируемой зоны (ЗНИ.8). Для УЗ-2 добавляются требования к уничтожению данных на носителях (ЗНИ.7) и учёту носителей (ЗНИ.2).

В облачном контексте под «носителем» понимается и физический диск (managed by провайдером), и логический том (volume), и резервная копия. Типичная ошибка: шифрование основного тома настроено, но резервные копии хранятся в незашифрованном бакете объектного хранилища. РКН и ФСТЭК при проверке проверяют именно полноту охвата, а не только основные базы данных.

По практике DATUM, в 2025–2026 годах наиболее распространённые разрывы в конфигурации облачной инфраструктуры:

• Незашифрованные снапшоты виртуальных машин в объектном хранилище провайдера.
• Логи приложений, содержащие ПДн (фрагменты запросов с email или телефоном), в незашифрованном хранилище.
• Экспортные файлы (CSV/Excel) из CRM или аналитических систем, не охваченные политикой шифрования.
• Данные в промежуточных очередях сообщений (Kafka, RabbitMQ) без шифрования на уровне хранилища.

Для УЗ-1 и УЗ-2, где обрабатываются специальные категории (медицина, биометрия), ФСТЭК де-факто ожидает применение сертифицированных средств криптографической защиты (СКЗИ) классов КС1–КС3, соответствующих требованиям ФСБ. Использование несертифицированного шифрования (например, AES-256 в реализации иностранного облачного провайдера) для УЗ-1 является нарушением — даже при технически надёжном алгоритме.

Шифрование in transit: TLS, VPN и требования к каналам передачи

Защита данных при передаче (in transit) по Приказу №21 относится прежде всего к группе ЗИС, мера ЗИС.3 — «обеспечение защиты персональных данных от раскрытия, модификации и навязывания при их передаче (в том числе по беспроводным каналам)». Для всех уровней УЗ-1..4 эта мера входит в базовый набор.

На практике это означает: любая передача ПДн между клиентом и сервером, между микросервисами внутри облака, между облачными регионами или от облака к on-premise-системам должна быть защищена шифрованным каналом. Для публичных API достаточно TLS 1.2 или выше; для межсистемного взаимодействия, где обрабатываются специальные категории ПДн (УЗ-1, УЗ-2), применение сертифицированных СКЗИ (VPN на базе ГОСТ, например) становится требованием, а не рекомендацией.

Особый случай — мультиарендная SaaS-архитектура (multitenancy). Если несколько арендаторов (tenants) используют общую инфраструктуру, данные разных арендаторов в транзите должны быть изолированы. На уровне сети это решается разделением по VPC/VLAN; на уровне шифрования — использованием отдельных ключей для каждого тенанта. Смешение ключей шифрования арендаторов — типичная архитектурная ошибка, которая при компрометации одного ключа создаёт риск раскрытия данных всех арендаторов.

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

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

Для CTO это означает: первичная запись ПДн пользователя (регистрация, оформление заказа, заявка) должна происходить в российском дата-центре. Последующая трансграничная передача обезличенных или агрегированных данных — возможна при соблюдении ст. 12 ФЗ-152 (уведомление РКН или передача в страны с адекватной защитой). Хранение исходных ПДн в Salesforce, HubSpot, AWS eu-central-1 или любом другом зарубежном облаке — нарушение ч. 5 ст. 18, штраф по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽, а при повторности — от 6 до 18 млн ₽.

Допустимая архитектура при использовании зарубежных сервисов аналитики или CRM: первичная база ПДн — в облаке в РФ (Yandex Cloud, МТС Линк, SberCloud, «Облако МТС» и другие), а в зарубежный сервис передаются только обезличенные идентификаторы (псевдонимизированные или агрегированные данные) без возможности обратного сопоставления с конкретным субъектом. Это требует документального оформления: поручение обработки по п. 3 ст. 6 ФЗ-152, техническое описание метода обезличивания по Приказу РКН о методах обезличивания (5 методов: введение идентификаторов, изменение состава/семантики, декомпозиция, перемешивание, обобщение).

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

Обучение ML-моделей на персональных данных — практика, создающая одновременно регуляторный и этический риск. Данные, использованные для обучения модели, технически «встроены» в веса модели и могут быть восстановлены через атаку membership inference. Регулятор это понимает: с 2025 года обезличенные ПДн регулируются отдельно (ст. 13.1 ФЗ-152, введена ФЗ-233 от 08.08.2024).

Ключевой принцип: если данные обезличены по методам, установленным Приказом РКН (5 методов), и обратное сопоставление с субъектом невозможно — они перестают быть персональными данными. Это снимает ограничения ч. 5 ст. 18 (локализация) и ст. 12 (трансграничная передача) для работы с обезличенным датасетом за рубежом.

На практике обезличивание для ML означает:

• Замену прямых идентификаторов (ФИО, email, телефон, паспорт) на технические идентификаторы без обратной связи с исходными данными.
• Обобщение квазиидентификаторов: возраст вместо даты рождения, регион вместо адреса, диапазон дохода вместо точной суммы.
• Документирование процедуры обезличивания: метод, дата, ответственный, подтверждение необратимости.
• Хранение таблицы соответствия (маппинга реальных ID на технические) исключительно в российском дата-центре, отдельно от обезличенного датасета.

Логирование в контексте ML — отдельный риск. Запросы к модели в продакшне могут содержать ПДн (имя пользователя в промпте, номер договора, медицинские симптомы). Если эти запросы логируются для дообучения — логи становятся базой ПДн со всеми вытекающими требованиями по локализации, шифрованию и сроку хранения. Логирование как ПДн — практика, которую РКН начал учитывать при проверках в 2025–2026 годах.

Типовые сценарии для CTO: как регулятор оценивает инциденты

Сценарий 1. Утечка через незашифрованный бакет резервных копий. Ситуация: облачный провайдер в РФ, основная база зашифрована, но S3-совместимый бакет с ночными бэкапами оставлен с публичным доступом. Доказательства: факт публичного доступа фиксируется сканером РКН или через уведомление от исследователя безопасности. Вероятный исход: нарушение мер ЗНИ по Приказу №21 + нарушение ст. 19 ФЗ-152. Если в бэкапах более 10 000 субъектов — штраф по ч. 13 ст. 13.11 КоАП от 5 до 10 млн ₽. Стратегия: закрытый доступ к бакетам, шифрование резервных копий, аудит политик объектного хранилища — до инцидента, а не после.

Сценарий 2. SaaS-провайдер с клиентами-операторами: кто отвечает за шифрование? Ситуация: компания предоставляет B2B SaaS для управления кадровым документооборотом. Клиенты (операторы ПДн) загружают данные своих сотрудников. Провайдер — лицо, осуществляющее обработку по поручению (ст. 6 п. 3 ФЗ-152). Вероятный исход: ответственность за технические меры защиты (шифрование, логирование, ключевая схема) — на провайдере как на лице, осуществляющем обработку. Ответственность перед РКН — на операторе-клиенте. При инциденте РКН выставит протокол оператору, но оператор взыщет ущерб с провайдера по договору поручения. Стратегия: в SLA и договоре поручения чётко зафиксировать технические меры безопасности, уровень УЗ и ответственность за соответствие Приказу №21. Провайдер должен быть готов к аудиту мер со стороны оператора-клиента.

Сценарий 3. Утечка через ML-логи в иностранном облаке. Ситуация: продакшн-логи запросов к языковой модели содержат фрагменты ПДн пользователей (имена, email из контекста запроса). Логи хранятся в облаке в ЕС для удобства отладки. Нарушения: хранение ПДн граждан РФ за пределами РФ (ч. 5 ст. 18 ФЗ-152) + отсутствие уведомления о трансграничной передаче (ст. 12 ФЗ-152) + нарушение локализации. Штраф по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽. Стратегия: политика маскирования ПДн в логах (log scrubbing) до передачи за рубеж, либо перенос ML-инфраструктуры в российский облачный регион.

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

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

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

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

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

3. Что такое обезличивание для ML и как его оформить?

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

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

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

5. Какие средства защиты информации (СЗИ) обязательны по Приказу №21?

Обязательные СЗИ определяются базовым набором мер для конкретного УЗ. Для УЗ-3: антивирусная защита (АВЗ.1), защищённый канал передачи (ЗИС.3), регистрация событий (РСБ.1–3), управление доступом (УПД.1–5). Для УЗ-1 и УЗ-2 при наличии специальных категорий или биометрии — сертифицированные СКЗИ классов КС1–КС3 для шифрования at rest и in transit. Применение несертифицированных средств (даже технически надёжных, например AES-256 в иностранной реализации) для УЗ-1 не соответствует требованиям без специального обоснования.

Итог

Шифрование данных в облаке — не опция, а базовое требование ст. 19 ФЗ-152 и Приказа ФСТЭК №21 для любого уровня защищённости. Разрыв между настроенным шифрованием основных баз и незащищёнными резервными копиями, логами или очередями сообщений — типичная ситуация, которая при инциденте превращается в нарушение с штрафом от 3 до 15 млн ₽. Требования локализации с 01.07.2025 закрыли вопрос об иностранных облаках для первичного хранения ПДн граждан РФ.

DATUM сопровождает CTO и технические команды в проведении аудита ИСПДн, разработке модели угроз, оформлении поручений на обработку с облачными провайдерами и подготовке технической документации по Приказу №21. По итогам аудита выдаётся отчёт с приоритизированным планом устранения разрывов.

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

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

13 января 2029 года