Архитектура безопасности защищенной облачной платформы

На сегодняшний день, 08 июня 2026 года, облачные технологии стали фундаментом для бизнеса любого масштаба. Однако перенос записей, разговоров, документов и персональных данных в облако поднимает критически важный вопрос: насколько надежно защищена эта информация? Статья подробно разбирает архитектуру безопасности защищённой облачной платформы, модель разделения ответственности, требования российского законодательства и лучшие практики защиты данных.

Модель разделения ответственности: кто за что отвечает?

Понимание границ ответственности — отправная точка любой стратегии безопасности. По стандартам индустрии (в т.ч. подходами Microsoft, AWS, и российских провайдеров вроде Selectel, Cloud.ru, T1 Облако, MWS, ITGLOBAL.COM) используется модель Shared Responsibility Model:

• Зона ответственности провайдера (Безопасность «ОБЛАКА»): Физическая защита дата-центров (уровень Tier III и выше), инженерная инфраструктура, сетевое оборудование, системы хранения, гипервизоры и технологии виртуализации. Провайдер гарантирует работоспособность «железа» и виртуализационного слоя.
• Зона ответственности клиента (Безопасность «В ОБЛАКЕ»): Настройка прав доступа (IAM), шифрование данных на уровне приложений, конфигурация гостевых ОС, защита конечных точек (EDR/Антивирус), управление учетными записями пользователей и настройка сетевых экранов (Security Groups).

Важно: Защита технологий виртуализации всегда находится в зоне ответственности провайдера. Клиент не имеет доступа к гипервизору и не может им управлять напрямую.

Нормативное соответствие: 152-ФЗ, 187-ФЗ и требования ФСТЭК

Для российского рынка это ключевой критерий выбора платформы. Защищённая облачная платформа должна обеспечивать соответствие:

1. Федеральный закон № 152-ФЗ «О персональных данных»: Оператору персональных данных (клиенту) необходимо заключить с провайдером договор поручения на обработку персональных данных. Критически важно заранее убедиться, что провайдер готов подписать такой документ (например, в Selectel это оформляется через тикет-систему).
2. Федеральный закон № 187-ФЗ «О безопасности критической информационной инфраструктуры (КИИ)»: Если система клиента входит в реестр КИИ, облако должно соответствовать категории значимости (КЗ 1, 2, 3).
3. Приказ ФСТЭК России № 21 (Уровни защищенности УЗ-1, УЗ-2, УЗ-3): Большинство сертифицированных российских облаков (Cloud.ru, T1, ITGLOBAL.COM, MWS) предоставляют сегменты с подтвержденным УЗ-1 (высший уровень) или УЗ-2. Наличие аттестатов ФСТЭК и сертификатов ФСБ — обязательное условие для госсектора и критической инфраструктуры.
4. ГОСТ Р 57580 (соответствие 152-ФЗ) и требования регуляторов (ЦБ РФ, ФСТЭК, ФСБ).

Примеры соответствия у ведущих провайдеров (на 2026 год):

• Cloud.ru: Соблюдает 152-ФЗ, 187-ФЗ, ГИС. Имеет аттестаты на УЗ-1 (Приказ ФСТЭК 21).
• T1 Облако: Надежность 99,95% SLA за счет нескольких зон доступности (геораспределенные ДЦ Tier III). Соответствует 152-ФЗ.
• ITGLOBAL.COM: Защищенная платформа по 152-ФЗ (УЗ-2), в РБ, Приказ 66 ОАЦ.
• MWS (Mail.ru Cloud Solutions): Развернут защищенный сегмент по требованиям ФСТЭК/ФСБ, использует шифрование, токенизацию, маскировку.

Технические механизмы защиты данных

Защищённая платформа реализует защиту на всех уровнях стека OSI:

Шифрование (Encryption)

• В транзите (In Transit): Обязательное использование TLS 1.2/1.3 для всех соединений (API, панель управления, репликация, бэкапы).
• На покое (At Rest): Стандарт де-факто, AES-256. Ключи управления могут храниться в KMS провайдера или в собственной системе управления ключами клиента (BYOK — Bring Your Own Key / CMEK, Customer Managed Encryption Keys).
• Блочное хранение: Раздельное хранение данных и метаданных для усложнения анализа при утечке дисков.

Управление идентификацией и доступом (IAM & MFA)

По данным Keeper Security и лучших практик, облачная безопасность в значительной степени основана на IAM и DLP (Data Loss Prevention).

• Многофакторная аутентификация (MFA): Обязательна для всех привилегированных аккаунтов. Комбинация: пароль + биометрия/OTP + аппаратные токены FIDO2 (Advanced Protection Program). Это снижает риск компрометации даже при утечке пароля.
• Принцип минимальных привилегий (Least Privilege): Ролевая модель доступа (RBAC), детальная настройка политик доступа к ресурсам (бакетам, БД, VM).
• Федерация идентификаторов (SSO/SAML/OIDC): Интеграция с корпоративным IdP (Active Directory, Keycloak, Яндекс 360 и т.д.).

Сетевая безопасность и сегментация

• VPC (Virtual Private Cloud): Изолированные частные сети с настраиваемой маршрутизацией.
• Security Groups / NACL: Stateful/Stateless файрволы на уровне инстансов и подсетей.
• Защищенные сектора / Сегментация: Создание изолированных контуров для чувствительных нагрузок (например, сегмент УЗ-1 в MWS или приватные пулы в Cloud.ru).
• DDoS-защита: L3/L4/L7 защита входящим трафиком (часто входит в базовый пакет или как аддон).
• Приватные каналы связи: Выделенные высокоскоростные каналы (Direct Connect, Cloud Interconnect) для гибридных облаков, исключающие выход в публичный интернет.

Защита на уровне хоста и приложений

• Агентская защита (CWPP / EDR): Установка агентов мониторинга целостности файлов (FIM), антивируса, обнаружения руткитов на виртуальных машинах.
• Управление уязвимостями (Vulnerability Management): Сканирование образов контейнеров и ОС в реестре (Container Registry) и на работающих инстансах.
• CNAPP (Cloud-Native Application Protection Platform): Единая панель (Single Pane of Glass) для корреляции событий безопасности, управления конфигурацией (CSPM) и защитой рантайма (CWPP), как рекомендует Microsoft Security.

Физическая безопасность и надежность

• Дата-центры уровня Tier III (параллельно обслуживаемая инфраструктура, 99.982% доступность).
• Географически распределенные зоны доступности (Availability Zones) в одном регионе для синхронной репликации (RPO=0).
• Многоуровневая физическая охрана: биометрия, мантрапы, видеонаблюдение 24/7, защита от проникновения.

Мониторинг, аудит и реагирование на инциденты

Защита не статична. Платформа должна предоставлять инструменты для непрерывного контроля:

• Аудит-логи (Audit Logs): Неизменяемые журналы всех действий по API и консоли (кто, что, когда сделал). Хранение от 90 дней до лет (в рейтинге 2025 года — до 30 180 дней / 10 лет для бизнеса).
• Интеграция с SIEM / SOAR: Экспорт логов в Splunk, QRadar, Positive Technologies MaxPatrol SIEM, Solar Dozor и др. через стандартные протоколы (Syslog, HTTP, Kafka).
• Cloud Security Posture Management (CSPM): Автоматическая проверка конфигураций на соответствие best practices (CIS Benchmarks) и требованиям регуляторов (незакрытые бакеты, открытые порты 22/3389, отсутствие шифрования).
• Threat Detection (KDR / CDR): Обнаружение аномалий в поведении контейнеров, процессов, сетевых соединений (MITRE ATT&CK mapping).

Резервное копирование и восстановление (Backup & DR)

Целостность данных — часть безопасности (CIA triad: Availability).

• Версионирование объектов: Защита от случайного удаления и ransomware (WORM — Write Once Read Many / Object Lock).
• Кросc-региональная репликация (CRR): Асинхронное копирование в другой регион для Disaster Recovery.
• Тестирование восстановления: Регулярные (drills) восстановления БД и файловых систем из бэкапов.

Чек-лист: как выбрать защищённую платформу для записи данных

Перед подписанием договора проверьте провайдера по этим пунктам:

Лучшие практики для клиента (Ваша зона ответственности)

Даже на самой защищённой платформе (УЗ-1) данные можно утерять из-за ошибок конфигурации. Обязательно внедряйте:

1. Внедрите MFA везде. Без исключений для админов, разработчиков, тех. аккаунтов CI/CD.
2. Шифруйте чувствительные данные на уровне приложения (Application-level encryption) перед отправкой в облачное хранилище/БД. Это защитит данные даже при компрометации инфраструктуры провайдера или ошибке доступа к диску.
3. Автоматизируйте проверку конфигураций (CSPM / IaC Scanning). Проверяйте Terraform/Ansible код на этапе CI/CD (Checkov, Terrascan, KICS).
4. Проводите регулярные пентесты и Red Teaming. Внешние и внутренние аудиты безопасности облачной инфраструктуры (с согласованием провайдера).
5. Обучение персонала. Фишинг и социальная инженерия остаются главным вектором атаки на облако (компрометация ключей API, паролей консоли).
6. Управление секретами. Не храните ключи в коде/конфигах. Используйте Vault (HashiCorp, Яндекс Lockbox, AWS Secrets Manager, Azure Key Vault).
7. Жизненный цикл данных. Политики удаления (Lifecycle policies), версионирование, Legal Hold для судебных споров.

Защищённая облачная платформа для записи данных в 2026 году — это не просто «виртуальная машина в запертом дата-центре». Это комплексное решение, объединяющее:

• Жесткое юридическое соответствие (152-ФЗ, 187-ФЗ, ФСТЭК УЗ-1/2, ФСБ);
• Прозрачную модель разделения ответственности;
• Современные криптографические механизмы с контролем ключей клиентом (CMEK/BYOK);
• Гибкое управление идентификацией (IAM/MFA/FIDO2) и сетевую изоляцию;
• Непрерывный мониторинг, аудит и интеграцию с SIEM/SOAR;
• Высокую доступность (Multi-AZ, Tier III) и гарантированное восстановление.

Выбирая провайдера (Cloud.ru, T1, Selectel, Yandex Cloud, MWS, ITGLOBAL.COM, SberCloud и др.), требуйте предоставить паспорт безопасности информационной системы, актуальные аттестаты ФСТЭК и готовность подписать договор поручения. Помните: провайдер защищает облако, но за безопасность ваших данных в облаке отвечаете вы. Внедрение практик Zero Trust, шифрования на уровне приложений и непрерывного мониторинга конфигураций — единственный способ гарантировать конфиденциальность, целостность и доступность ваших записей.