Как провайдер защищает данные в облаке: от IAM до SOC

В 2024 году средняя стоимость утечки данных в мире достигла рекордных за все время наблюдений 4,88 млн долл. (по данным IBM Security [1]). Российская статистика на первый взгляд выглядит обнадеживающе: по данным экспертно-аналитического центра InfoWatch [5], за 2025 год число скомпрометированных записей персональных данных снизилось на 21,6%, до 1 343 млн против 1 714 млн годом ранее. Однако есть одно но – количество записей известно лишь в 37% зарегистрированных утечек. В остальных масштаб никто не посчитал.

Компании переносят в облако ERP-системы, базы клиентов, финансовые данные и логично задаются вопросом: что именно провайдер делает для защиты? Эта статья разбирает архитектуру безопасности в облаке по слоям, от управления доступом до круглосуточного мониторинга угроз.

Кто за что отвечает: модель разделения ответственности

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

Большинство инцидентов происходят именно на стороне клиента. По данным Google Cloud [2], компрометация учетных данных и мисконфигурации остаются основными точками проникновения в облачные среды, составляя 47,1% и 29,4% от общего числа первоначальных векторов атак соответственно. Провайдер не виноват, если клиент выдал сотруднику права администратора ко всем ресурсам или не включил многофакторную аутентификацию.

Модель разделения ответственности четко делит зоны контроля в зависимости от выбранной модели облачных услуг – IaaS, PaaS или SaaS.  

Понимание этих границ – начальная точка для любого разговора с провайдером о безопасности. Подробнее о разных моделях облачных услуг рассказали в статье. 

Безопасность облачной инфраструктуры строится слоями, и провайдер закрывает большую их часть. Задача клиента в том, чтобы понять, где начинается его зона ответственности, и выстроить там такой же уровень контроля.

Анжелика Захарова, руководитель практик кибербезопасности и 1С, K2 Cloud 

IAM: управление доступом как первый рубеж

Главное. IAM контролирует, кто и что может делать в облаке. 62% организаций называют его основой Zero Trust. Большинство утечек начинаются именно с компрометации учетных данных.

IAM (Identity and Access Management) отвечает за управление цифровыми удостоверениями и правами. По данным StrongDM [3], 62% организаций оценивают IAM как «очень важный» элемент архитектуры безопасности. Если злоумышленник получил рабочие учетные данные, хорошо настроенный IAM ограничит ущерб, плохо настроенный – даст ключи от всего.

Что входит в IAM у зрелого провайдера

Принцип минимальных привилегий. Каждый пользователь, сервис или приложение получают только те права, которые нужны для конкретной задачи. AWS IAM, Azure Active Directory и Google Cloud IAM реализуют это через гранулярные политики с точностью до отдельного API-метода.

Многофакторная аутентификация (MFA). Пароль давно не защита. Современные провайдеры требуют второй фактор – аппаратный ключ (YubiKey), TOTP-приложение или биометрию. Для привилегированных аккаунтов MFA обязательна.

Федеративная аутентификация. Корпоративные каталоги (Active Directory, Okta) интегрируются с облаком через SAML 2.0 или OpenID Connect. Сотрудник входит один раз через привычный корпоративный SSO и получает доступ к разрешенным ресурсам облака.

Временные учетные данные. Провайдеры выдают токены со сроком жизни от нескольких минут до нескольких часов. AWS STS генерирует временные данные для роли – даже если токен украдут, он быстро станет бесполезным.

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

Шифрование: данные в покое, в движении и в работе

Главное. Зрелые провайдеры шифруют данные во всех трех состояниях: при хранении, передаче и обработке. Управление ключами может быть на стороне провайдера или клиента.

Данные в покое (at rest). Все данные на дисках шифруются по умолчанию. AWS, Azure и большинство российских провайдеров используют AES-256. Клиент управляет ключами через KMS (Key Management Service) или приносит собственные ключи (BYOK, Bring Your Own Key). В варианте BYOK провайдер физически не может расшифровать данные, даже если захочет.

Данные в движении (in transit). Весь трафик между клиентом и облаком, а также внутри инфраструктуры провайдера шифруется через TLS 1.2/1.3. Для критичных сервисов применяют взаимную аутентификацию (mTLS) – обе стороны соединения предъявляют сертификаты.

Данные в процессе обработки (in use). Самое молодое направление – Confidential Computing. AWS Nitro Enclaves, Azure Confidential Computing (Intel SGX) и Google Confidential VMs позволяют обрабатывать данные прямо в зашифрованном виде, не раскрывая их даже оператору облака. К 2025 году технология вышла из экспериментальной стадии и применяется в регулируемых отраслях: финтех, медицина, государственные сервисы.

Сетевая изоляция: VPC, Security Groups и WAF

Главное. Каждый клиент работает в логически изолированной сети. Фильтрация трафика настраивается на уровне подсети, отдельного ресурса и HTTP-запросов.

Virtual Private Cloud (VPC) дает каждому клиенту логически изолированный сегмент сети. Ресурсы разных клиентов не видят друг друга, даже если физически находятся на одном сервере.

Security Groups работают как виртуальный межсетевой экран вокруг каждого ресурса. Администратор описывает разрешенный трафик: только SSH с конкретного IP, только HTTPS из интернета, только соединения с базой из той же подсети. Все остальное блокируется по умолчанию.

Network ACL добавляет дополнительный слой фильтрации на уровне подсети. В отличие от Security Groups, ACL умеет явно запрещать конкретные типы трафика. Это удобно для блокировки известных диапазонов адресов.

Web Application Firewall (WAF) анализирует HTTP-трафик и блокирует атаки на уровне приложений: SQL-инъекции, межсайтовый скриптинг (XSS), включение файлов. Провайдеры предлагают управляемые наборы правил и возможность создавать собственные под специфику приложения.

Защита от DDoS. Крупные провайдеры автоматически поглощают объемные атаки. Продвинутые тарифы подключают команду экспертов, которые вручную настраивают контрмеры при крупных инцидентах. По данным StormWall [4], в 2025 году количество DDoS-атак в России выросло почти вдвое. Чем отличаются атаки на уровнях L3, L4 и L7 и что подключать под конкретный профиль угрозы, разбирали в материале про защиту от DDoS-атак в облаке.

Zero Trust: почему периметровая защита больше не работает

Главное. Zero Trust предполагает, что любой запрос может быть враждебным, независимо от того, откуда он пришел. Каждый пользователь и устройство верифицируются при каждом обращении.

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

Модель Zero Trust («нулевое доверие») строится на четырех принципах:

1. Верифицировать каждого пользователя и устройство при каждом запросе – независимо от прошлых сессий.
2. Не доверять сетевому местоположению: запрос изнутри корпоративной сети подозрителен ровно настолько же, как запрос снаружи.
3. Ограничивать доступ сессией и контекстом, а не выдавать постоянные разрешения.
4. Логировать и анализировать все действия в режиме реального времени.

Google реализовал Zero Trust в собственной инфраструктуре еще в 2010-х годах в проекте BeyondCorp. Сейчас подход доступен клиентам через Google Cloud BeyondCorp Enterprise. Microsoft строит аналогичную систему в Azure через Conditional Access и Microsoft Entra. В российском сегменте аттестованные облака следуют схожим принципам в рамках требований ФСТЭК.

SOC: кто следит за безопасностью облака круглосуточно

Главное. SOC (Security Operations Center, центр управления безопасностью) – это команда и техническая платформа, которые круглосуточно мониторят инфраструктуру, выявляют угрозы, реагируют на инциденты и предотвращают атаки на ваши облачные сервисы и данные.

SIEM. Системы SIEM (Security Information and Event Management) анализируют события из всех компонентов облака, выявляют аномалии и автоматизируют первичное расследование. Amazon и Microsoft используют собственные решения и часто интегрируются с внешними SIEM для гибкости и расширенного анализа. Современные SIEM-системы коррелируют события из сотен источников и выявляют атаки, которые по отдельности выглядят безобидно.

Threat Intelligence. Облачные провайдеры интегрируют данные о глобальных киберугрозах (Threat Intelligence) в свои сервисы: например, Google использует экспертизу Mandiant, а Microsoft работает с отдельным подразделением Threat Intelligence. Это позволяет выявлять и предотвращать атаки в реальном времени, используя данные миллионов событий по всему миру.

SOAR и автоматическое реагирование. Security Orchestration, Automation and Response позволяет реагировать на типовые инциденты без участия человека. Если обнаружен брутфорс, аккаунт блокируется автоматически. Выявлена подозрительная активность в базе данных – снимается снапшот, трафик изолируется. Среднее время реагирования сокращается с часов до секунд.

Управляемое обнаружение и реагирование (MDR). Часть провайдеров предлагает MDR как дополнительный сервис: команда аналитиков SOC провайдера работает с инфраструктурой клиента, расследует подозрительные события и дает рекомендации. Для компаний без собственной команды ИБ это закрывает дыру полностью.

Использование специализированных SOC-услуг и современных SIEM/SOAR-решений позволяет компаниям оперативно реагировать на угрозы в облаке, снижать риски простоев и утечек данных, экономить бюджеты на построение собственной инфраструктуры безопасности.

Управление уязвимостями и патч-менеджмент

Главное. В управляемых сервисах (базы данных, Kubernetes, serverless) провайдер патчит уязвимости сам (модель PaaS). За операционные системы клиентских ВМ отвечает клиент.

Провайдеры регулярно сканируют собственную инфраструктуру на известные уязвимости. Amazon Inspector, Microsoft Defender for Cloud и Google Container Analysis автоматически проверяют образы контейнеров и конфигурации ВМ.

Управляемые (managed) сервисы обновляются без участия клиента. База данных RDS на Amazon получает патч безопасности в настроенное окно обслуживания, клиент выбирает время, но не несет ответственности за сам патч. Это одно из главных преимуществ PaaS: провайдер закрывает уязвимости на уровне платформы быстрее, чем большинство корпоративных ИТ-команд.

Программы Bug Bounty добавляют внешний слой проверки: AWS, Google и Microsoft платят исследователям безопасности за обнаруженные уязвимости. Это создает дополнительный аудит силами мирового сообщества.

С начала 2026 года открытая программа есть у K2 Cloud: уязвимости в К2 Облаке может искать любой верифицированный исследователь площадки Standoff Bug Bounty от Positive Technologies. Подробнее об участии провайдера в программе Bug Bounty можно прочитать здесь. 

Резервное копирование и катастрофоустойчивость

Главное. Зрелые провайдеры реплицируют данные в несколько географических зон и гарантируют восстановление в рамках заявленных RTO и RPO.

Георепликация. Данные хранятся в нескольких дата-центрах в разных локациях. Полный выход из строя одного региона не приводит к потере данных, резервная копия уже есть в другом месте.

RTO и RPO в SLA. Recovery Time Objective (целевое время восстановления) и Recovery Point Objective (целевая точка восстановления) фиксируются в соглашении об уровне обслуживания. Клиент знает заранее: максимально возможная потеря данных – X минут, восстановление займет не более Y часов.

Важный нюанс: резервные копии клиентских данных – зона разделенной ответственности. Провайдер делает репликацию управляемых сервисов. За бекапы данных в клиентских приложениях отвечает клиент.

Аттестаты и сертификаты: как проверить слова провайдера

Главное. Независимые аудиты и сертификации подтверждают, что процессы безопасности провайдера соответствуют стандартам. Без этих документов заявления о «надежной защите» остаются маркетингом.

*Ключевое различие – SOC 2 Type I и Type II. Type I – это снимок на дату аудита, Type II – проверка процессов за период от 6 до 12 месяцев. Для критичной инфраструктуры запрашивайте именно Type II: он показывает систематическую работу, а разовая подготовка к аудиту будет в нем видна сразу.

Клиент получает доступ к отчетам через специальные порталы (AWS Artifact, Microsoft Service Trust Portal) или напрямую от провайдера. Для российского рынка особенно важно наличие аттестата по 152-ФЗ с уровнем защиты, соответствующим вашим данным ([7]).

Как это выглядит в реальном отчете: K2 Cloud прошел оценку по ГОСТ Р 57580.1-2017 с коэффициентом соответствия 0,94 из 1,00 и подтвердил аудитами ГОСТ Р ИСО/МЭК 27001-2021 и 27017-2021. Что именно проверяли и как читать результат, разбирали в материале про безопасность облака для финансовых организаций (по результатам аудита в конце 2025 года коэффициент соответствия К2 Облака ГОСТ Р 57580.1-2017 вырос с 0.94 до 0.95).

Что остается на стороне клиента

Главное. Провайдер защищает инфраструктуру. Настройка прав доступа, шифрование данных приложений, мониторинг пользовательских действий – это ответственность клиента.

Самая частая ошибка: компании думают, что переход в облако автоматически решает все вопросы безопасности, но это не так.

Что клиент делает сам:

• Настройка политик IAM: кто имеет доступ к каким ресурсам и с какими правами
• Включение и настройка MFA для всех пользователей, особенно для привилегированных аккаунтов
• Шифрование данных внутри приложений (провайдер шифрует диски, но не данные в памяти приложения)
• Мониторинг активности пользователей и реагирование на аномалии
• Обновление операционных систем и ПО в клиентских виртуальных машинах
• Резервное копирование данных приложений (сверх базовых снапшотов провайдера)
• Настройка правил WAF под специфику своих приложений

Риски безопасности, связанные с собственными сотрудниками, все чаще не про случайные ошибки. По данным InfoWatch [6], за 9 месяцев 2025 года 95,6% утечек по вине персонала пришлись на умышленную кражу данных. Поэтому технический контроль доступа и мониторинг действий пользователей закрывают вполне реальный сценарий: осознанную угрозу изнутри.

Полезная аналогия: провайдер строит и охраняет здание, ставит замки на все двери. Но кому выдать ключи, кто может войти в серверную, а кто нет, решает клиент. Если клиент выдал ключи всем подряд, охранник на входе не поможет.

Закрывать эту зону своими силами не обязательно: часть задач можно отдать профессиональным сервисам. Как делится ответственность в такой модели, разбирали эксперты K2 Cloud и «Лаборатории Касперского» в материале про облачные сервисы безопасности для бизнеса.

Что спросить у провайдера перед подключением

Главное. Несколько конкретных вопросов помогут оценить реальный уровень защиты, а не маркетинговые обещания.

Перед подписанием договора с облачным провайдером запросите ответы на следующие вопросы. 

1. Какие сертификаты, актуальные для вашей отрасли, есть в наличии? Для финансовых организаций критичны PCI DSS 4.0 и ГОСТ Р 57580.1-2017. Для работы с ПДн важен 152-ФЗ с нужным уровнем защиты. Для КИИ обязательно соответствие 187-ФЗ и требованиям ФСТЭК.
2. Где физически хранятся данные? В России ПДн должны храниться только на территории РФ (требование 152-ФЗ). Уточните, есть ли механизм закрепления данных за конкретным регионом.
3. Как работает управление ключами шифрования? Можно ли использовать BYOK? Кто технически имеет доступ к ключам?
4. Что входит в мониторинг по умолчанию и что стоит дополнительно? SIEM, MDR, уведомления об инцидентах: какой набор вам нужен и что за него нужно доплачивать?
5. Какой уровень SLA и регламент реагирования на инциденты гарантируются? Узнайте, в какие сроки команда SOC обязуется реагировать на инциденты и как фиксируется исполнение этих регламентов.
6. Каков процесс уведомления при инциденте? В какие сроки провайдер оповещает клиента? Что входит в план реагирования? Кто ваша точка контакта при инциденте в 3 часа ночи?
7. Есть ли доступ к отчетам аудитов? Запросите SOC 2 Type II и, для российского рынка, аттестат ФСТЭК или заключение об оценке соответствия по 152-ФЗ.
8. Какие метрики и отчеты предоставляются? Какие данные получит бизнес по итогам операций SOC? Заранее выясните, насколько детально и регулярно вы будете получать аналитическую информацию, какие KPI отслеживает SOC.
9. Есть ли возможность интегрировать свои бизнес-приложения и нетиповые источники данных? Это особенно важно для компаний с нестандартной инфраструктурой – уточните, сможет ли провайдер подключить кастомные сервисы или специфичный софт.

Ответы на эти вопросы стоит получить до подписания договора, а не в момент первого инцидента.