Исследование Intruder's 2026 Cloud Security Index построено на данных о неверных настройках в 3000 организациях, использующих AWS, Azure и Google Cloud. Проверялись шесть групп рисков: слабое управление идентификацией и доступом (IAM), отсутствие журналирования, ошибки конфигурации сервисов, слишком открытые межсетевые экраны, доступные извне службы и слабое шифрование. Две проблемы почти не зависят от выбранной платформы: слабый IAM и недостаточное журналирование обнаружены в 80–98% учетных записей.
Остальные риски распределены резко неравномерно. Открытые сервисы встречаются в 76% сред AWS, 64% Azure и лишь 8% Google Cloud. Разрешающие правила межсетевых экранов обнаружены соответственно в 83%, 45% и 34% случаев, слабое шифрование — в 49%, 35% и 8%. По ошибкам настройки сервисов впереди Azure с 80%, затем идут AWS с 68% и Google Cloud с 37%. AWS показывает наибольшую распространенность проблем в пяти из шести категорий, а Google Cloud — наименьшую также в пяти категориях.
Разрыв между AWS и Google Cloud объясняется, по крайней мере частично, устройством самих платформ. AWS предлагает самый широкий набор сервисов, а значит, больше вариантов конфигурации и больше мест, где можно ошибиться. У Google Cloud сервисов меньше, а модель Shared Fate предполагает более безопасные настройки по умолчанию, особенно для сетевой доступности и шифрования. Это не делает платформу неуязвимой: просто основные слабости смещаются в другую область.
В AWS чаще всего встречается настройка S3 Does Not Enforce HTTPS — 87%. Далее идут разрешение входящего трафика к чувствительным портам через ACL — 84%, чрезмерно открытый Network ACL — 83%, возможность повышения привилегий через политику IAM — 83% и отсутствие VPC Endpoint для EC2 — 82%. S3 широко используют для облачного хранения, поэтому возможность обращаться к нему по обычному HTTP выглядит особенно ненужной. Атаки «человек посередине» на S3 редки, но оставлять незашифрованный канал без практической причины всё равно плохая привычка.
Сложность AWS IAM создаёт менее заметную угрозу: управляемая политика может выглядеть безопасной, но фактически давать лишние разрешения. Цена такой ошибки измеряется минутами. В одном инциденте злоумышленник воспользовался раскрытыми учетными данными, менее чем за 10 минут получил административные права и скомпрометировал 19 субъектов AWS. Поэтому проверять нужно не названия политик, а итоговые полномочия, включая возможные цепочки повышения привилегий.
В Azure первые три позиции связаны с Azure Storage Accounts: автоматическая ротация ключей не включена в 67% случаев, ключи доступа разрешены в 66%, публичный сетевой доступ открыт в 61%. Близкие показатели намекают на неприятный сценарий: несколько защитных механизмов часто отсутствуют одновременно. В таких хранилищах может находиться персональная идентифицируемая информация (PII), поэтому сочетание постоянных ключей и публичного доступа заметно увеличивает последствия одной утечки.
Ещё у 55% учетных записей Azure обнаружены пользователи Entra ID без многофакторной аутентификации (MFA), а Trusted Launch не включён в 45% случаев. Entra ID управляет доступом к облачным ресурсам, Microsoft 365, сторонним SaaS-приложениям и локальным системам. Масштаб возможного ущерба хорошо показал взлом сети Microsoft группировкой Midnight Blizzard в 2024 году: атака началась с распыления паролей против устаревшей тестовой учетной записи, где MFA отсутствовала.
У Google Cloud картина иная: четыре из пяти самых частых ошибок относятся к идентификации и доступу. OS Login MFA не включён в 77% сред, сам OS Login — в 76%, неиспользуемые сервисные учетные записи присутствуют в 75%, чрезмерные права сервисных учетных записей — в 53%. Разрешающий входящий доступ к чувствительным портам встречается в 34% случаев. OS Login служит более безопасной заменой традиционному SSH-доступу, однако свыше трёх четвертей проверенных учетных записей не используют эти средства контроля.
Размер компании обычно снижает технические риски: крупные предприятия реже оставляют открытые сервисы, слабое шифрование и разрешающие правила межсетевых экранов. С IAM всё наоборот. Слабое управление доступом обнаружено у 87% малых и средних компаний с численностью до 250 сотрудников, у 95% организаций среднего рынка с 251–10 000 сотрудников и у 98% крупных предприятий, где работают от 10 000 до 100 000 и более человек. Чем больше организация, тем больше ролей, сервисных учетных записей, исключений и старых разрешений. Одной привилегированной личности достаточно, чтобы обойти хорошо настроенные сетевые барьеры.
Скорость исправления тоже не растёт линейно вместе с ресурсами компании. Малому бизнесу требуется в среднем 8–16 дней, крупным предприятиям — 10 дней, а организациям среднего рынка — 35 дней. Похоже, именно средний сегмент получает сложность корпоративного облака раньше, чем успевает обзавестись сопоставимой командой безопасности и отлаженными процедурами.
Единый список проверок для AWS, Azure и Google Cloud даёт ложное ощущение порядка. Общая методика оценки нужна, иначе невозможно сравнить состояние всей мультиоблачной инфраструктуры. Но исправления должны учитывать платформу: в AWS приоритетны сетевые ACL, HTTPS для S3 и повышение привилегий; в Azure — Storage Accounts и Entra ID; в Google Cloud — OS Login и сервисные учетные записи. IAM требует отдельного контроля при любом размере компании. Полные данные, включая десять наиболее частых ошибок каждой платформы и показатели по размеру организаций, опубликованы в Intruder's 2026 Cloud Security Index.
Остальные риски распределены резко неравномерно. Открытые сервисы встречаются в 76% сред AWS, 64% Azure и лишь 8% Google Cloud. Разрешающие правила межсетевых экранов обнаружены соответственно в 83%, 45% и 34% случаев, слабое шифрование — в 49%, 35% и 8%. По ошибкам настройки сервисов впереди Azure с 80%, затем идут AWS с 68% и Google Cloud с 37%. AWS показывает наибольшую распространенность проблем в пяти из шести категорий, а Google Cloud — наименьшую также в пяти категориях.
Разрыв между AWS и Google Cloud объясняется, по крайней мере частично, устройством самих платформ. AWS предлагает самый широкий набор сервисов, а значит, больше вариантов конфигурации и больше мест, где можно ошибиться. У Google Cloud сервисов меньше, а модель Shared Fate предполагает более безопасные настройки по умолчанию, особенно для сетевой доступности и шифрования. Это не делает платформу неуязвимой: просто основные слабости смещаются в другую область.
В AWS чаще всего встречается настройка S3 Does Not Enforce HTTPS — 87%. Далее идут разрешение входящего трафика к чувствительным портам через ACL — 84%, чрезмерно открытый Network ACL — 83%, возможность повышения привилегий через политику IAM — 83% и отсутствие VPC Endpoint для EC2 — 82%. S3 широко используют для облачного хранения, поэтому возможность обращаться к нему по обычному HTTP выглядит особенно ненужной. Атаки «человек посередине» на S3 редки, но оставлять незашифрованный канал без практической причины всё равно плохая привычка.
Сложность AWS IAM создаёт менее заметную угрозу: управляемая политика может выглядеть безопасной, но фактически давать лишние разрешения. Цена такой ошибки измеряется минутами. В одном инциденте злоумышленник воспользовался раскрытыми учетными данными, менее чем за 10 минут получил административные права и скомпрометировал 19 субъектов AWS. Поэтому проверять нужно не названия политик, а итоговые полномочия, включая возможные цепочки повышения привилегий.
В Azure первые три позиции связаны с Azure Storage Accounts: автоматическая ротация ключей не включена в 67% случаев, ключи доступа разрешены в 66%, публичный сетевой доступ открыт в 61%. Близкие показатели намекают на неприятный сценарий: несколько защитных механизмов часто отсутствуют одновременно. В таких хранилищах может находиться персональная идентифицируемая информация (PII), поэтому сочетание постоянных ключей и публичного доступа заметно увеличивает последствия одной утечки.
Ещё у 55% учетных записей Azure обнаружены пользователи Entra ID без многофакторной аутентификации (MFA), а Trusted Launch не включён в 45% случаев. Entra ID управляет доступом к облачным ресурсам, Microsoft 365, сторонним SaaS-приложениям и локальным системам. Масштаб возможного ущерба хорошо показал взлом сети Microsoft группировкой Midnight Blizzard в 2024 году: атака началась с распыления паролей против устаревшей тестовой учетной записи, где MFA отсутствовала.
У Google Cloud картина иная: четыре из пяти самых частых ошибок относятся к идентификации и доступу. OS Login MFA не включён в 77% сред, сам OS Login — в 76%, неиспользуемые сервисные учетные записи присутствуют в 75%, чрезмерные права сервисных учетных записей — в 53%. Разрешающий входящий доступ к чувствительным портам встречается в 34% случаев. OS Login служит более безопасной заменой традиционному SSH-доступу, однако свыше трёх четвертей проверенных учетных записей не используют эти средства контроля.
Размер компании обычно снижает технические риски: крупные предприятия реже оставляют открытые сервисы, слабое шифрование и разрешающие правила межсетевых экранов. С IAM всё наоборот. Слабое управление доступом обнаружено у 87% малых и средних компаний с численностью до 250 сотрудников, у 95% организаций среднего рынка с 251–10 000 сотрудников и у 98% крупных предприятий, где работают от 10 000 до 100 000 и более человек. Чем больше организация, тем больше ролей, сервисных учетных записей, исключений и старых разрешений. Одной привилегированной личности достаточно, чтобы обойти хорошо настроенные сетевые барьеры.
Скорость исправления тоже не растёт линейно вместе с ресурсами компании. Малому бизнесу требуется в среднем 8–16 дней, крупным предприятиям — 10 дней, а организациям среднего рынка — 35 дней. Похоже, именно средний сегмент получает сложность корпоративного облака раньше, чем успевает обзавестись сопоставимой командой безопасности и отлаженными процедурами.
Единый список проверок для AWS, Azure и Google Cloud даёт ложное ощущение порядка. Общая методика оценки нужна, иначе невозможно сравнить состояние всей мультиоблачной инфраструктуры. Но исправления должны учитывать платформу: в AWS приоритетны сетевые ACL, HTTPS для S3 и повышение привилегий; в Azure — Storage Accounts и Entra ID; в Google Cloud — OS Login и сервисные учетные записи. IAM требует отдельного контроля при любом размере компании. Полные данные, включая десять наиболее частых ошибок каждой платформы и показатели по размеру организаций, опубликованы в Intruder's 2026 Cloud Security Index.
