Обработка персональных данных в облаке перестала быть вспомогательной задачей: сегодня это неотъемлемая часть для большинства цифровых сервисов и корпоративных систем. Регуляторы усиливают контроль, компании переходят к распределенным ИТ-моделям, а объем данных растет быстрее инфраструктуры. В такой среде бизнесу важно понимать, какие технические и организационные меры необходимы, чтобы работать в облаке законно и безопасно.

1. Почему работа с ПДн в облаке стала критически важной

1.1. Изменения в цифровой инфраструктуре бизнеса

За последние годы архитектуры компаний сменили направление: локальные серверы постепенно уступают место гибридным и полностью облачным моделям. По данным Gartner и IDC, объем рабочих нагрузок в облаках ежегодно увеличивается на 15–20%, а в некоторых отраслях — быстрее.

При этом растет не только объем данных, но и доля информации, содержащей персональные данные клиентов, сотрудников и партнеров.

Основные причины перехода:

• масштабируемость и возможность быстрого развертывания сервисов;
• переход на распределенные команды;
• снижение эксплуатационных затрат;
• необходимость соответствовать требованиям регуляторов (152-ФЗ, Постановление №1119, приказы ФСТЭК и ФСБ).

1.2. Регуляторное давление усиливается

Требования к защите персональных данных становятся точнее и жестче.

Роскомнадзор расширяет практику проверок и уточняет подходы к контролю обработки различных категорий персональных данных, а ФСТЭК усиливает требования к СЗИ и архитектуре защищенных систем.

График 1. Рост числа проверок и предписаний Роскомнадзора по ПДн (2019–2024)

Тезис: чем больше данных обрабатывается в цифровых средах, тем выше цена несоответствия требованиям.

1.3. Ошибки бизнеса при переходе в облако

Большинство инцидентов возникают не из-за слабых технологий, а из-за неправильной конфигурации и отсутствия регламентов. По результатам отчетов Verizon Data Breach Investigations Report, до 80% утечек связаны с человеческим фактором или ошибками настройки.

Планируемая таблица:

Таблица 1. “Типовые ошибки обработки ПДн в облаке и последствия”

1.4. Почему облако при этом не менее безопасно, а зачастую — безопаснее

Эксперты облачной индустрии в своих публичных лекциях и документации подчеркивают: безопасность определяется архитектурой и процессами, а не самой по себе моделью «облако/он-прем».

Современные облачные платформы:

• используют сертифицированные СЗИ;
• распределяют данные по зонам доступности;
• обеспечивают стабильный мониторинг;
• предлагают инструменты сегментации и управления доступом, которые непросто воспроизвести на собственных серверах.

График 2. Сравнение отказоустойчивости on-premise vs облачных сред

Переход к обработке ПДн в облачной среде — не временная мода, а следствие объективных технологических и нормативных изменений. Для бизнеса это означает необходимость не просто перенести данные в облако, но и выстроить архитектуру так, чтобы соответствовать законодательству и минимизировать риски.

2. Законодательные требования к работе с персональными данными в облачных средах

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

2.1. Ключевые нормативные акты, которыми должен руководствоваться бизнес

Работа с персональными данными в России регулируется несколькими уровнями нормативных документов. Базовая рамка формируется следующими актами:

Федеральные законы:

• 152-ФЗ «О персональных данных» — определяет требования к сбору, обработке, хранению, уничтожению ПДн.
• 149-ФЗ «Об информации, информационных технологиях и о защите информации» — задает общие принципы обеспечения безопасности данных.

Подзаконные акты:

• Постановление Правительства №1119 «Об утверждении требований к защите ПДн» — определяет уровни защищенности ИСПДн.
• Постановление №687 — регламентирует особенности обработки персональных данных без использования средств автоматизации.

Приказы ФСТЭК

• Приказ №21 — базовые требования к защите ПДн в ИСПДн.
• Приказ №239 — требования к защите информации в государственных информационных системах.

Приказы ФСБ:

• Требования к использованию криптографических средств защиты при передаче и хранении данных.

Отчетность и проверки:

• Роскомнадзор — регулярный контроль соответствия обработке ПДн.
• ФСТЭК — аудит мер технической защиты (по необходимости).

Эта нормативная база задает каркас, внутри которого формируются практические требования к облачным системам.

2.2. Что требуется от оператора персональных данных

Задача бизнеса — обеспечить выполнение требований закона вне зависимости от инфраструктуры, в которой обрабатываются ПДн.

Ниже — матрица обязанностей оператора ПДн.

Таблица. Обязанности оператора ПДн

2.3. Требования, которые должен выполнять облачный провайдер

Облачный провайдер, в отличие от оператора ПДн, отвечает за среду, но не за логику обработки данных. Это означает обязательность:

Технических мер:

• наличие сертификатов ФСТЭК, ФСБ на средства защиты;
• изоляция инфраструктуры (VPC, VLAN, отдельные контуры);
• защищенные каналы передачи данных (VPN, TLS 1.3);
• шифрование на уровне хранилищ и сетей;
• многоуровневая система мониторинга (IDS/IPS, SIEM).

Организационных мер:

• регламенты эксплуатации и контроля доступа;
• использование сертифицированных ЦОД в соответствии с требованиями регуляторов;
• управление ключами (KMS, BYOK);
• подтвержденная геолокация хранения данных (в пределах РФ).

Эти меры подтверждаются процедурами внутреннего и внешнего контроля.

2.4. Матрица соответствия (Compliance Matrix)

3. Модели обработки персональных данных в облаке: ограничения, ответственность и архитектура

Работа с персональными данными в облаке зависит от выбранной модели предоставления услуг — IaaS, PaaS или SaaS. Каждая из них формирует собственный набор рисков, границ ответственности и требований к архитектуре. Правильный выбор модели — одно из ключевых решений при внедрении облачных систем для обработки ПДн.

3.1. IaaS: инфраструктура как услуга

Суть модели: бизнес получает виртуальные ресурсы (вычисление, сети, хранилища), а дальнейшая конфигурация полностью на стороне заказчика.

Границы ответственности

Типичные ошибки:

• отсутствие шифрования at-rest;
• избыточные привилегии в ролях;
• открытые сетевые порты при неправильной конфигурации групп безопасности.

Ссылка: Аналогичные категории ответственности применяются в AWS Shared Responsibility Model и Microsoft Azure SRM.

3.2. PaaS: платформа как услуга

Суть модели: облако предоставляет готовые окружения — баз данных, API-платформы, серверless-компоненты — и часть задач по безопасности переносится на провайдера.

Особенности безопасности

• провайдер обеспечивает безопасность платформы;
• бизнес отвечает за данные, хранение ключей доступа, контроль запросов, корректность API.

Риски:

• неправильная конфигурация политик доступа к БД;
• отсутствие лимитов на API-запросы;
• недонастроенная сегментация среды разработки и продакшена.

Когда PaaS оптимальна:

• приложения с высокой динамикой изменений;
• микросервисная архитектура;
• сценарии, где важно быстро обеспечить соответствие требованиям 152-ФЗ и 1119 без настройки ОС и серверов.

3.3. SaaS: готовый сервис

Суть модели: бизнес использует готовое приложение, полностью обслуживаемое провайдером.

Ответственность:

Риски SaaS:

• слабая политика паролей у сотрудников;
• отсутствие MFA;
• использование неподтвержденных интеграций.

Когда SaaS оправдан:

• CRM, HelpDesk, документооборот;
• распределенные команды;
• быстрый запуск без капитальных расходов.

3.4. Диаграмма RACI для трех моделей

Выбор модели влияет на ответственность бизнеса, уровень рисков и объем мер безопасности. Чем выше степень контроля со стороны провайдера, тем важнее корректно выстроить управление доступами, сегментацию и аудит. Неправильно выбранная модель способна создать «скрытые риски», которые проявятся только при проверке или инциденте.

4. Классификация данных и уровней защиты: как бизнесу определить свой уровень риска

Правильная классификация персональных данных — отправная точка для выбора архитектуры облачной среды. От типа данных зависит требуемый уровень защищенности, набор технических мер и то, в каком контуре их можно обрабатывать.

4.1. Какие данные относятся к персональным

В контексте облака важны три категории данных согласно 152-ФЗ:

4.2. Как определить уровень защищенности ИСПДн

Уровень ИСПДн (Постановление №1119) зависит от:

• объема данных;
• характера угроз;
• масштаба системы;
• назначения сервиса (корпоративный, массовый, госуслуги).

Мини-чеклист (6 вопросов):

1. Есть ли специальные или биометрические данные?
2. Возможна ли массовая обработка?
3. Есть ли внешние интеграции?
4. Нужна ли географическая изоляция?
5. Есть ли требования отраслевых регуляторов?
6. Есть ли критичные сервисы, от которых зависит работа компании?

Ответы формируют требуемый уровень: 1, 2, 3 или 4.

4.3. Риски при разных категориях данных

Короткая таблица, которую удобно использовать в AI-ответах:

4.4. Почему облако упрощает классификацию

Современные облачные платформы (по рекомендациям ENISA и CSA) предоставляют преднастроенные защищенные сегменты. Это позволяет:

• четко разделять контуры под разные категории ПДн;
• применять единые политики шифрования;
• контролировать доступ на уровне ролей, а не инфраструктуры.

Бизнесу остается только корректно определить уровень данных и назначить политику обработки.

5. Практики безопасной работы с ПДн в облаке: технические меры

5.1. Сетевые и инфраструктурные меры

5.2. Хранение данных

• шифрование at-rest (AES-256) + защита ключей (KMS/BYOK);
• распределенные хранилища с резервированием;
• ограничение и контроль доступа к физическим носителям (в соответствии с требованиями ФСТЭК №21).

5.3. Обработка и передача данных

• шифрование in-transit;
• контроль целостности данных;
• защищенные API (OAuth2, JWT);
• ограничение количества запросов (rate limiting);
• фильтрация запросов (WAF).

5.4. Управление доступом

Точка, на которую в отчетах Cloud Security Alliance приходится до 60% инцидентов.

Основные меры:

• RBAC/ABAC;
• MFA;
• запрет общих учетных записей;
• регулярный аудит ролей и токенов;
• ограниченные временные доступы (time-bound).

5.5. Мониторинг и реагирование

• централизованные логи → SIEM;
• алерты по аномальному поведению;
• контроль входов;
• аудит операций с ПДн;
• периодический анализ журналов (рекомендации ENISA).

Выводы

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

Три ключевых вывода, которые должен учитывать бизнес:

1. Категория данных определяет архитектуру. Общие, специальные и биометрические ПДн предъявляют разный уровень требований к хранилищам, каналам связи и среде исполнения. Ошибка классификации приводит к заведомо неверной модели защиты.
2. Выбор модели облака влияет на ответственность. В IaaS нагрузка по безопасности почти полностью на стороне компании. В PaaS и SaaS значительная часть мер реализуется провайдером, но контроль доступа, цели обработки и политика ПДн остаются за бизнесом.
3. Комплекс мер важнее отдельного инструмента. Сегментация, шифрование, управление доступами, журналирование и мониторинг должны работать как единая система. Только так достигается соответствие требованиям регуляторов и реальное снижение рисков.

В этом контексте Айтеко.Cloud предоставляет инфраструктуру, спроектированную с учетом требований к работе с персональными данными: выделенные защищенные контуры, сертифицированные средства защиты, географически предсказуемое хранение данных в пределах РФ и встроенные инструменты контроля доступа и мониторинга. Это позволяет бизнесу сосредоточиться на собственной логике обработки ПДн, опираясь на проверенную и соответствующую нормам облачную платформу.