Управление безопасностью в различных облачных сервисах представляет сложную задачу, особенно учитывая, что каждый провайдер имеет собственные уязвимости. Согласно исследованию облачной безопасности за 2026 год, проведённому компанией Intruder на основе данных 3000 организаций, использующих AWS, Azure и Google Cloud, профили рисков между провайдерами практически не имеют общих черт.

Различия в рисках безопасности между облачными провайдерами

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

Слабая защита идентификации и отсутствие логирования распространены повсеместно, встречаясь у 80-98% аккаунтов независимо от провайдера. Остальные четыре категории показывают значительные различия:

  • Доступные сервисы: AWS (76%), Azure (64%), Google Cloud (8%)
  • Открытые брандмауэры: AWS (83%), Azure (45%), Google Cloud (34%)
  • Слабое шифрование: AWS (49%), Azure (35%), Google Cloud (8%)
  • Неправильная настройка сервисов: AWS (68%), Azure (80%), Google Cloud (37%)

Наибольший разрыв наблюдается в категории доступных сервисов — 76% на AWS против 8% на Google Cloud. Открытые брандмауэры и слабое шифрование следуют аналогичной схеме, где AWS занимает первое место, а Google Cloud — последнее. Исключением является неправильная настройка сервисов: здесь лидирует Azure (80%), а Google Cloud отстаёт (37%).

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

Google Cloud имеет наименьшую распространённость проблем в пяти категориях и предлагает наименьшее количество сервисов. Более низкая распространённость также может объясняться иным подходом к распределению ответственности — модель Shared Fate обеспечивает более безопасные параметры по умолчанию, особенно в отношении доступа в сеть и шифрования.

AWS: проблемы с брандмауэрами и шифрованием

Наиболее частые ошибки в аккаунтах AWS:

  1. Хранилище S3 не требует HTTPS (87%)
  2. Чрезмерно открытый входящий доступ к важным портам (через ACL) (84%)
  3. Слишком разрешительные списки контроля доступа сети (83%)
  4. Политики IAM позволяют повышение привилегий (83%)
  5. VPC Endpoint не включён для EC2 (82%)

Хранилища S3 без требования HTTPS — самая распространённая проблема. S3 — один из наиболее используемых облачных сервисов хранения, и хотя атаки типа "человек посередине" против него редки, нет причин оставлять доступ по незащищённому протоколу HTTP.

Политики IAM, позволяющие повышение привилегий, затрагивают 83% аккаунтов. AWS IAM известен своей сложностью, и управляемая политика, выглядящая безопасно, может предоставить более широкие права доступа, чем предполагалось. В одном недавнем инциденте злоумышленник переместился от утечки учётных данных к правам администратора менее чем за 10 минут, скомпрометировав 19 принципалов AWS.

Azure: проблемы с хранилищем и идентификацией

Самые распространённые ошибки конфигурации в аккаунтах Azure:

  1. Ротация ключей хранилища не включена (67%)
  2. Ключи доступа хранилища включены (66%)
  3. Открыт публичный доступ к хранилищу (61%)
  4. Пользователи Entra без двухфакторной аутентификации (55%)
  5. Trusted Launch не включён (45%)

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

Более половины аккаунтов не имеют двухфакторной аутентификации для пользователей Entra ID. Это значимо, так как Entra ID управляет доступом не только к облачным ресурсам, но и к Microsoft 365, приложениям SaaS третьих сторон и локальным системам. Взлом Midnight Blizzard в 2024 году начался с атаки перебора пароля против тестового аккаунта без двухфакторной аутентификации.

Google Cloud: управление доступом

Почти все основные проблемы на Google Cloud связаны с управлением идентификацией и доступом:

  1. OS Login MFA не включён (77%)
  2. OS Login не включён (76%)
  3. Неиспользуемые учётные записи сервисов (75%)
  4. Слишком разрешительные учётные записи сервисов (53%)
  5. Чрезмерно открытый входящий доступ к важным портам (34%)

Более 75% аккаунтов не используют элементы управления OS Login, которые обеспечивают более безопасную альтернативу традиционному SSH.

Влияние размера организации на уровень риска

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

Исключением является управление доступом. Слабая защита идентификации затрагивает 87% малых предприятий, 95% среднеразмерных организаций и 98% крупных предприятий. Это важно, потому что часто один учётный запись с повышенными привилегиями достаточно, чтобы обойти системы защиты, которые были укреплены в других местах.

Среднеразмерные организации также требуют больше времени для устранения проблем облачной безопасности — в среднем 35 дней, в сравнении с 8-16 днями для малых предприятий и 10 днями для крупных компаний. Это указывает на то, что команды среднего размера управляют облачной сложностью на уровне предприятия без достаточных выделенных ресурсов.

Выводы для команд безопасности

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