Разделённая ответственность в облаке: почему бизнес считает, что за безопасность отвечает провайдер, и чем это заканчивается

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

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

Ниже — типовые ошибки, которые показывают, где проходит граница между зоной ответственности провайдера и клиента.

Открытый бакет: утечка без взлома

Один из самых распространённых сценариев — публичный доступ к объектному хранилищу. Например, команда создаёт бакет для теста, открывает его "наружу", чтобы быстрее проверить работу сервиса, а затем забывает закрыть. Позже туда попадают документы, резервные копии, выгрузки из CRM или персональные данные.

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

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

Как избежать:

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

Слабые пароли и отсутствие MFA

Ещё один типовой сценарий — слабый пароль от облачной консоли и отключённая многофакторная аутентификация. Для администратора это может выглядеть как временное упрощение: нужно быстро подключиться, протестировать сервис, передать доступ коллеге или подрядчику. Для злоумышленника — прямой путь к управлению инфраструктурой.

Если пароль уже был скомпрометирован в другом сервисе или легко подбирается, отсутствие MFA превращает одну слабую учётную запись в точку входа ко всей инфраструктуре: виртуальным машинам, базам данных, бэкапам и сетевым настройкам.

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

Компрометация административного доступа может остановить сервисы, привести к удалению данных, шифрованию инфраструктуры, несанкционированным расходам и длительному восстановлению.

Как избежать:

• использовать уникальные сложные пароли длиной не менее 12–16 символов;
• хранить пароли в менеджере паролей;
• обязательно включать MFA для всех учётных записей, особенно привилегированных;
• регулярно проводить аудит аккаунтов и удалять неиспользуемые;
• контролировать подозрительные попытки входа.

Избыточные права: когда удобство побеждает безопасность

В облаке доступы часто расширяют из лучших побуждений. Разработчику нужно срочно исправить ошибку в production, подрядчику — настроить интеграцию, сервисному администратору — что-то быстро поправить. Чтобы не тратить время на точечную настройку ролей, им дают административный доступ или права сразу ко всем боевым средам.

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

В этом случае провайдер отвечает за работоспособность системы ролевого доступа (IAM): чтобы у клиента была возможность разграничивать роли, создавать политики, ограничивать доступы и вести журналирование. Но какие права кому назначены — ответственность клиента.

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

Как избежать:

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

Незакрытые уязвимости в виртуальных машинах

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

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

Последствия могут быть серьёзными: проникновение в VM, установка вредоносного ПО, кража данных, дальнейшее перемещение по облачной сети. Для атакующего такая машина становится точкой входа, особенно если внутри есть доступы к базам данных, внутренним сервисам или другим облачным ресурсам.

Как избежать:

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

Репликация — не резервное копирование

Ещё одна распространённая ошибка — считать встроенную репликацию полноценным резервным копированием. Репликация помогает при инфраструктурных сбоях, но не защищает от ошибок пользователя или логических сбоев.

Показательный пример — реальный инцидент в Google Cloud Platform. Клиент потерял 11 дней данных из-за того, что не настроил управляемые бэкапы. Инфраструктура облака при этом не была основной проблемой: данные не удалось восстановить потому, что у компании не было корректной стратегии резервного копирования.

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

Для бизнеса отсутствие бэкапов — один из самых дорогих классов ошибок. Оно приводит к длительным простоям, потере транзакций, нарушению обязательств перед клиентами и прямым финансовым убыткам.

Как избежать:

• настроить автоматическое резервное копирование с хранением нескольких версий;
• предусмотреть восстановление на конкретный момент времени;
• регулярно проверять работоспособность бэкапов через тестовое восстановление;
• документировать стратегию резервного копирования;
• учитывать требования бизнеса к RTO и RPO — времени восстановления и допустимой потере данных.

Учетные данные в коде: секунды до компрометации

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

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

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

Как избежать:

• не хранить пароли, токены и API-ключи в исходном коде;
• использовать специализированные сервисы управления секретами;
• настроить автоматическое сканирование репозиториев на наличие секретов;
• включить проверки в CI/CD-процессы;
• регулярно ротировать ключи и учётные данные, особенно после инцидентов.

Незащищённые API: открытая дверь в прикладной контур

Даже если инфраструктура настроена корректно, уязвимость может появиться на уровне приложения. Например, компания публикует API без полноценной аутентификации, не ограничивает частоту запросов, оставляет открытый CORS или не проверяет права доступа для разных типов пользователей.

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

Провайдер отвечает за защиту своих API управления. Но API, которое разрабатывает и публикует клиент, находится в зоне ответственности клиента.

Как избежать:

• использовать надёжную аутентификацию и авторизацию: OAuth 2.0, JWT, API-ключи;
• настраивать ограничение по числу запросов (rate limiting) и защиту от DDoS-атак уровня L7;
• применять WAF для защиты веб-приложений и API;
• мониторить подозрительную активность;
• регулярно тестировать безопасность API с учётом рекомендаций OWASP API Security Top 10.

Что важно помнить бизнесу

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

Чтобы модель разделённой ответственности работала, её нужно описать не только в договоре, но и во внутренних процессах. Для каждого уровня должно быть понятно, кто отвечает за настройки, кто контролирует изменения, и кто реагирует на инциденты. Особенно если в облаке размещаются персональные данные, критичные бизнес-системы, клиентские сервисы или production-среды.

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

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