Статья Мисконфигурация облака как вектор атаки: полная карта угроз и защиты AWS, Azure и GCP

99% облачных инцидентов безопасности - вина клиента, а не провайдера. Это прогноз Gartner (Through 2025, оригинальная публикация 2019 г.), который цитирует CybelAngel. Не zero-day и не APT-группировка: хватает одной забытой галочки в настройках доступа. Крупные предприятия одновременно держат тысячи мисконфигурированных облачных ресурсов, а среднее время обнаружения ошибки конфигурации - месяцы. За это время автоматизированные сканеры успевают проиндексировать и выгрузить данные из забытого S3-бакета. Облачные вторжения выросли на 26% за 2024 год (CrowdStrike Global Threat Report 2025) и на 37% в 2025-м (CybelAngel), а атаки с использованием валидных credentials - на 71% (IBM X-Force 2025). Мисконфигурация облака - самый дешёвый для атакующего вектор: не нужны эксплойты, хватает curl и понимания, где искать.

Карта темы: навигация по кластеру облачной безопасности​

#	Подтема кластера	Подробнее
1	Открытые хранилища S3, Azure Blob, GCP: разведка, эксплуатация, ransomware	Мисконфигурация облака: S3-бакеты, снапшоты и storage
2	SSRF как путь к облачным credentials через metadata endpoint	SSRF атака на облачные credentials
3	Эскалация привилегий IAM: от ограниченной роли до полного контроля	Повышение привилегий AWS IAM
4	Credential theft, account takeover и detection в AWS/Azure	Атаки на облачные аккаунты AWS и Azure
5	Prototype Pollution в Axios → HTTP header injection и потенциальный SSRF	CVE-2026-40175: Prototype Pollution в Axios - header injection и SSRF-вектор
6	Мисконфигурации в Terraform и CloudFormation до деплоя	Безопасность Infrastructure as Code
7	Мисконфигурации Salesforce: аудит до утечки	Мисконфигурации Salesforce: разбор атак и аудит
8	Injection и privilege escalation в serverless-функциях	Атаки на serverless функции
9	Полная методология пентеста облачной инфраструктуры	Пентест облачной инфраструктуры: методология и цепочки атак

Kill chain облачной атаки: 6 этапов от разведки до exfiltration​

Мисконфигурация облака - не изолированная ошибка. Это начальная точка полноценной цепочки атаки. На облачных пентестах я прохожу одну и ту же последовательность, которая укладывается в конкретные тактики MITRE ATT&CK:

Этап	Тактика MITRE ATT&CK	Техника	Облачный контекст
Разведка	Discovery	T1619 Cloud Storage Object Discovery	Перебор имён S3-бакетов, поиск через GrayhatWarfare
Начальный доступ	Initial Access	T1078.004 Valid Accounts: Cloud Accounts	Утёкшие AWS-ключи в git-репозитории, .env-файлы
Получение credentials	Credential Access	T1552.005 Cloud Instance Metadata API	SSRF к metadata endpoint (169.254.169.254)
Сбор данных	Collection	T1530 Data from Cloud Storage	Скачивание содержимого открытого S3-бакета
Эскалация привилегий	Privilege Escalation	T1078.004 / T1098.003 Additional Cloud Roles	Добавление привилегированных ролей через misconfigured policy (iam:PassRole, sts:AssumeRole abuse)
Lateral movement	Lateral Movement	-	Использование украденных IAM-ключей для доступа к другим сервисам аккаунта

Цепочка нелинейна - она ветвится в зависимости от находок. Открытый бакет даёт прямой путь к T1530 (Data from Cloud Storage). Утёкший .env-файл с AWS-ключами в том же бакете - это уже T1078.004 и дальше lateral movement внутри облачного аккаунта. SSRF в веб-приложении на EC2 - классический T1552.005 с извлечением временных credentials из metadata service.

OWASP относит открытые облачные хранилища к категории A05:2021 - Security Misconfiguration: insecure default configurations, open cloud storage. Не теоретическая классификация - точное описание того, что обнаруживается на каждом втором облачном пентесте.

И вот что отличает облачную kill chain от on-premise: каждый этап выполняется через API, без необходимости ломать сетевой периметр. Нет firewall между атакующим и вашим S3-бакетом - есть только конфигурация доступа. Ошибочна она? Атакующий работает напрямую с облачным API провайдера с любой точки мира.

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

Открытые S3-бакеты, Azure Blob и GCP Storage: 3 облака - одна системная ошибка​

Мисконфигурации облачных хранилищ ответственны за 23% всех инцидентов облачной безопасности в 2025 году (CybelAngel). Масштаб конкретных инцидентов впечатляет: в августе-сентябре 2025 года команда Casmer Labs (Cloud Storage Security) нашла публично доступный S3-бакет с сотнями тысяч PDF-файлов банковских переводов - имена клиентов, номера счетов, IFSC-коды, документы авторизации дебетов. Бакет был активным: новые файлы продолжали поступать в процессе анализа. Никакого взлома - хватило публичного URL.

AWS S3: глобальное пространство имён как подарок атакующему​

S3-бакеты живут в глобальном пространстве имён. Если company-prod-backups существует, он кому-то принадлежит - и атакующий проверяет доступность одной командой:

aws s3 ls s3://target-bucket --no-sign-request
aws s3api list-objects-v2 --bucket target-bucket --no-sign-request --max-keys 10

Успешный ответ на --no-sign-request означает публичный доступ без аутентификации. Разведка включает пассивные методы: Google dorks site:s3.amazonaws.com "companyname", GrayhatWarfare для поиска по индексу публичных бакетов и файлов, crt.sh для обнаружения поддоменов, указывающих на S3-hosted ресурсы. s3scanner (последний релиз: 2023, Python) автоматизирует перебор имён и проверку ACL. Для поиска утёкших ключей - trufflehog v3 (>15k звёзд GitHub, активно поддерживается), который сканирует git-историю и вытаскивает AWS-ключи, токены, пароли.

Azure Blob Storage: ложное чувство защищённости​

Контейнеры внутри storage accounts. Анонимный доступ возможен, если storage account разрешает allowBlobPublicAccess и контейнер настроен как container (листинг + чтение) или blob (чтение по прямой ссылке). Microsoft изменил дефолт для новых storage accounts в ноябре 2023, отключив anonymous access - но существующие аккаунты с мисконфигурацией Azure Blob Storage это обновление не затронуло. Проверка: curl к endpoint https://<account>.blob.core.windows.net/<container>?restype=container&comp=list - XML-ответ со списком блобов означает открытый контейнер. BlobHunter (Python, последнее обновление: 2022) перечисляет storage accounts по подпискам и проверяет публичный доступ.

GCP Cloud Storage: организационные политики как последний рубеж​

Команда gsutil ls gs://bucket-name для анонимной проверки. Типичная GCP bucket misconfiguration - неактивированный uniform bucket-level access: каждый объект может иметь собственный ACL, и контроль превращается в хаос. Организационная политика constraints/storage.publicAccessPrevention на уровне организации и VPC Service Controls для предотвращения data exfiltration - два основных защитных рубежа, рекомендуемых Google.

Паттерн одинаков для всех трёх провайдеров: хранилище создаётся «на время» для тестового воркфлоу, получает широкие права доступа, со временем в него попадают продакшн-данные - а настройки доступа никто не пересматривает. По наблюдениям Casmer Labs, этот lifecycle повторяется в большинстве инцидентов. На аудитах я вижу ту же картину: бакет, созданный полгода назад «для интеграции с подрядчиком», до сих пор торчит наружу с SQL-дампами внутри.

Детальный разбор команд разведки и эксплуатации с полными примерами ACL и bucket policy: Мисконфигурация облака как вектор атаки: S3-бакеты, снапшоты и storage AWS/Azure/GCP.

Публичные снапшоты и EBS-тома: данные, о которых все забыли​

EBS-снапшоты (Amazon Elastic Block Store) - point-in-time копии дисков виртуальных машин - один из самых недооценённых источников утечки данных. Организации полагаются на снапшоты для быстрого восстановления EC2-инстансов, но нередко оставляют их публичными - доступными любому AWS-аккаунту.

На практике эксплуатация выглядит так: атакующий через AWS CLI перечисляет публичные снапшоты в целевом регионе, монтирует найденный снапшот к собственному EC2-инстансу и получает полный доступ к файловой системе - конфигурационные файлы, credentials, SSH-ключи, дампы баз данных. Вся операция происходит в аккаунте атакующего, без какого-либо взаимодействия с инфраструктурой жертвы. Жертва даже не узнает - никаких алертов, никаких логов в её CloudTrail.

По данным Trend Micro, среди целей облачного ransomware EBS-снапшоты на приоритетной позиции: без них восстановление систем может занять дни. Атакующие уничтожают снапшоты после копирования данных в свой аккаунт, блокируя любые пути recovery. Аналогичная проблема существует для RDS-снапшотов (базы данных PostgreSQL, MySQL, Aurora) - клиентские данные, транзакции и credentials становятся доступны при неправильных настройках общего доступа.

Отдельная угроза - container registries. По данным Trend Micro, Amazon Elastic Container Registry (ECR) содержит образы, от которых зависят CI/CD-пайплайны и production-деплой. Компрометация или удаление образов может парализовать все среды развёртывания.

Что делать прямо сейчас: запускайте aws ec2 describe-snapshots --owner-ids <your-account-id> --query 'Snapshots[].SnapshotId' --output text | xargs -n1 -I{} aws ec2 describe-snapshot-attribute --snapshot-id {} --attribute createVolumePermission для обнаружения публичных снапшотов. Внедрите Service Control Policy (SCP) на уровне AWS Organization, запрещающую создание публичных снапшотов. Проверяйте RDS-снапшоты: aws rds describe-db-snapshot-attributes --db-snapshot-identifier <id> на каждом своём снапшоте - ищите restore attribute со значением all (означает публичный доступ).

S3-ransomware: когда мисконфигурация хранилища превращается в шифровальщик​

Ransomware-группы адаптировали тактики под облачную инфраструктуру. Исследователи (Halcyon Research, Trend Micro) описали несколько вариантов S3-ransomware, которые эксплуатируют нативные механизмы шифрования AWS вместо традиционных ransomware-бинарников. Красивый ход - зачем тащить свой шифровальщик, если AWS сам всё зашифрует?

Ключевой сценарий, описанный Halcyon Research (кампания Codefinger, январь 2025): атакующий использует SSE-C (Server-Side Encryption with Customer-Provided Keys) для перезаписи объектов в S3-бакете. Ключ шифрования знает только атакующий - AWS хранит лишь HMAC для верификации. Оригинальные файлы удаляются, на их месте появляется ransom note. Альтернативный вариант - злоупотребление SSE-KMS с ротацией ключа шифрования на подконтрольный атакующему KMS-ключ.

Перед атакой злоумышленник оценивает бакет по трём критериям:

1. Versioning отключён - нельзя откатить перезаписанные файлы к предыдущей версии
2. Object Lock не настроен - объекты можно свободно перезаписывать и удалять
3. MFA Delete выключен - удаление версий без многофакторной аутентификации

Все три условия выполнены - бакет становится идеальной мишенью. По данным Trend Micro, ransomware-группы расширяют список целей за пределы S3: EBS-снапшоты, RDS-базы, ECR-образы контейнеров и системы бэкапирования (Glacier, AWS Backup). Логика атакующих: уничтожить бэкапы, заблокировать восстановление, максимизировать давление на жертву. В реальных кейсах компании без защищённых бэкапов прибегали к выплате выкупа как единственному пути восстановления данных.

Что делать: включайте versioning и Object Lock (compliance mode) на бакетах с критичными данными. Настройте MFA Delete. Используйте AWS Backup с vault lock - даже компрометация IAM-ключей не позволит удалить защищённые бэкапы. Подробный разбор эксплуатации и защиты: Мисконфигурация облака как вектор атаки: S3-бакеты, снапшоты и storage AWS/Azure/GCP.

SSRF и облачный metadata endpoint: одна уязвимость - полный доступ к аккаунту​

Server-Side Request Forgery (SSRF) в веб-приложении на облачной виртуальной машине - один из самых результативных путей к захвату credentials целого аккаунта. Механизм прост до неприличия: приложение по запросу атакующего обращается к metadata service (IP 169.254.169.254 в AWS и GCP, специальный endpoint в Azure) и возвращает временные IAM credentials, привязанные к роли инстанса.

Техника маппируется на T1552.005 - Cloud Instance Metadata API в MITRE ATT&CK. Полученные credentials дают атакующему те же права, что и роль EC2-инстанса - а на практике роли часто назначаются с избыточными привилегиями (доступ к S3, DynamoDB, SQS, Secrets Manager). Вот ключевой момент: одна SSRF-уязвимость трансформируется в полноценный initial access к облачному аккаунту через украденные временные ключи.

AWS ввёл IMDSv2 (Instance Metadata Service v2) с обязательным session-token для запросов к metadata, что сильно усложняет эксплуатацию через простой SSRF. Но IMDSv2 не включён принудительно на всех инстансах - организации должны явно мигрировать. И не мигрируют. В Azure аналогичную роль играет IMDS с Managed Identity, в GCP - metadata server с заголовком Metadata-Flavor: Google.

Отдельную угрозу представляют уязвимости на уровне приложений, способные обойти даже IMDSv2. CVE-2026-40175 в библиотеке Axios (CVSS 4.8, Medium) демонстрирует цепочку, в которой prototype pollution в сторонней зависимости позволяет инжектировать unsanitized header values в исходящие HTTP-запросы (CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers, CWE-444 HTTP Request Smuggling, CWE-918 SSRF). Это не RCE - но header injection теоретически может использоваться как SSRF-вектор для обращения к metadata endpoint при использовании IMDSv1; для IMDSv2 эта CVE не обеспечивает обхода, поскольку IMDSv2 требует отдельного PUT-запроса с session-token. Подробный разбор: CVE-2026-40175: Prototype Pollution в Axios - header injection и SSRF-вектор.

Для противодействия T1552.005 MITRE D3FEND рекомендует: Configuration Inventory (D3-CI) для аудита IMDSv2-настроек всех инстансов, Credential Compromise Scope Analysis (D3-CCSA) для оценки масштаба компрометации при утечке metadata credentials и Credential Revocation (D3-CR) для немедленного отзыва скомпрометированных ключей.

Что делать: принудительно включайте IMDSv2 через --metadata-options HttpTokens=required на каждом EC2-инстансе. Проводите security review веб-приложений на предмет SSRF. Глубокий разбор от IMDSv1 до постэксплуатации: SSRF атака на облачные credentials.

IAM-мисконфигурации: от read-only до полного захвата аккаунта за 5 шагов​

IAM (Identity and Access Management) - фундамент безопасности облака и одновременно самая частая точка провала. Техника T1078.004 - Valid Accounts: Cloud Accounts входит сразу в четыре тактики MITRE ATT&CK: initial access, persistence, privilege escalation и defense evasion.

По данным CrowdStrike Global Threat Report 2025, 75% облачных вторжений в 2024 году задействовали действительные учётные данные - не эксплойты, не malware, а легитимные ключи и токены. IBM X-Force оценивает объём ежедневно появляющихся на теневых площадках свежих credentials в более чем 6000 записей - облачные ключи входят в этот поток наряду с корпоративными паролями.

Типичные IAM-мисконфигурации, которые я обнаруживаю на аудитах:

• Wildcard-политики ("Action": "[I]", "Resource": "[/I]") - полный доступ ко всем сервисам аккаунта. Встречается чаще, чем хотелось бы
• Долгоживущие access keys без ротации - компрометация одного ключа означает постоянный доступ
• Cross-account trust relationships с широкими правами - lateral movement между аккаунтами
• Отсутствие Service Control Policies (SCP) - нет ограничений даже для администраторов
• Привилегированные роли на EC2-инстансах, выполняющих одну узкую задачу (классика: инстанс для отправки email имеет AdministratorAccess)

В GCP аналогичная проблема: использование primitive roles (Owner/Editor/Viewer) вместо predefined roles и утечка JSON-ключей сервисных аккаунтов. Google рекомендует Workload Identity Federation вместо JSON keys и организационную политику, запрещающую создание ключей сервисных аккаунтов.

Для мониторинга IAM-аномалий в SigmaHQ доступно около 41 detection-правила по тегу T1078.004 (репозиторий регулярно обновляется) - от aws_iam_s3browser_loginprofile_creation.yml (создание login-профиля через S3 Browser как потенциальный persistence) до azure_mfa_interrupted.yml и azure_mfa_denies.yml (обнаружение brute force через паттерны MFA-отказов).

Что делать: проведите аудит IAM с помощью AWS IAM Access Analyzer и Prowler. Удалите неиспользуемые access keys старше 90 дней. Принцип наименьших привилегий - каждая роль получает только те permissions, которые нужны для конкретной задачи. Детальные техники эскалации: Повышение привилегий AWS IAM: техники эскалации через роли, политики и misconfiguration.

Infrastructure as Code: небезопасная конфигурация рождается до деплоя​

Terraform-модули, CloudFormation-шаблоны и Kubernetes-манифесты - код, который определяет вашу инфраструктуру. Ошибка в IaC-конфиге - мисконфигурация, которая воспроизводится при каждом деплое и масштабируется на все окружения автоматически. Написал один раз криво - получил десять одинаково дырявых сред.

Типичные IaC-мисконфигурации из реальных аудитов:

• acl = "public-read" в Terraform-ресурсе aws_s3_bucket - незащищённое облачное хранилище создаётся публичным с момента рождения
• Отсутствие encryption_configuration - данные хранятся без шифрования
• Security group с ingress 0.0.0.0/0:22 - SSH открыт всему интернету
• Kubernetes pod с securityContext.privileged: true - контейнер с правами root на хосте (проверяйте соответствие DISA Kubernetes STIG)

Инструменты статического анализа IaC обнаруживают эти ошибки до деплоя: Trivy (Aqua Security, активно поддерживается, покрывает IaC + containers + CSPM), Checkov (Bridgecrew/Palo Alto), tfsec. Интеграция в CI/CD-пайплайн позволяет блокировать деплой с критичными мисконфигурациями - shift-left подход, который предотвращает проблему вместо реагирования.

Отдельный вектор - supply chain атаки через зависимости IaC. В начале июня 2026 года Microsoft Security опубликовал отчёт о масштабной кампании Red Hat npm Miasma: компрометация более 90 версий пакетов @redhat-cloud-services с кражей credentials из CI/CD-окружений и облачных платформ. Вредоносный код распространялся при каждом npm install, заражая сборочные среды.

Что делать: внедрите pre-commit hooks с Trivy или Checkov для всех IaC-репозиториев. Проводите аудит зависимостей - npm, pip, Go modules - на предмет typosquatting. Полный гайд: Безопасность Infrastructure as Code: от мисконфигурации в Terraform до detection-правила в SIEM.

Serverless и SaaS: расширяющийся периметр облачных атак​

Мисконфигурация облака не ограничивается хранилищами и виртуальными машинами. Serverless-функции (AWS Lambda, Azure Functions, Google Cloud Functions) и SaaS-платформы (Salesforce, Microsoft 365) формируют новые поверхности атаки, которые часто выпадают из поля зрения security-команд. А зря.

Serverless: injection и event poisoning​

Lambda-функция, обрабатывающая события из S3 или API Gateway, наследует IAM-роль с определёнными привилегиями. Если входные данные не валидируются - атакующий проводит command injection через event payload, получает execution context функции и пользуется её IAM-ролью для доступа к другим ресурсам аккаунта (DynamoDB, S3, Secrets Manager). Эта цепочка - конкретный пример lateral movement внутри облачного аккаунта без компрометации традиционных серверов.

Специфика serverless-безопасности: EDR на Lambda не поставишь, контейнер живёт минуты (попробуй успей среагировать), а CloudWatch Logs - нередко единственный нативный источник телеметрии. Это создаёт слепые зоны, которые атакующие активно эксплуатируют.

Подробный разбор техник: Атаки на serverless функции: injection, event poisoning и privilege escalation.

SaaS-платформы: Salesforce как показательный пример​

Salesforce - одна из самых распространённых SaaS-платформ в enterprise-сегменте. Открытые API-эндпоинты, избыточные sharing rules, guest user access с широкими правами приводят к утечкам клиентских данных без какого-либо «взлома» в классическом понимании. Проблема аналогична мисконфигурации S3 - данные становятся доступны по прямому URL из-за ошибки в настройках доступа.

Пошаговый аудит Salesforce: Мисконфигурации Salesforce: находим и закрываем до утечки.

Что делать: включайте serverless-функции и SaaS-платформы в scope облачного аудита. Для Lambda - минимизируйте IAM-роль до необходимых permissions, валидируйте все входные события. Для Salesforce - ревизия guest user access и sharing rules.

Атаки на облачные аккаунты: credential theft и account takeover​

Компрометация облачного аккаунта - финальная цель большинства атак через мисконфигурацию. Украденные IAM-ключи, перехваченные через SSRF temporary credentials, пароли из открытых .env-файлов - все дороги ведут к account takeover.

Масштаб проблемы с credentials: IBM X-Force Threat Intelligence Index 2025 фиксирует рост атак с использованием валидных учётных данных на 71% год к году. CrowdStrike отмечает, что среднее время lateral movement после первоначального доступа составило 62 минуты в 2024 году, с рекордом в 51 секунду. При таких скоростях ручной incident response не успевает. Просто вдумайтесь: 51 секунда от initial access до lateral movement.

Техники закрепления в облачном аккаунте после начального доступа:

• Persistence через IAM - создание скрытых IAM-пользователей, дополнительных access keys, Automation Runbook в Azure (для верификации: Atomic Red Team содержит тест Azure Persistence Automation Runbook Created or Modified по T1078.004)
• Credential stuffing - использование утёкших паролей для доступа к облачным консолям
• Session hijacking - перехват токенов через XSS или утёкшие session cookies
• Abuse of trusted integrations - использование CI/CD-пайплайнов для lateral movement

MITRE D3FEND рекомендует для противодействия T1078.004: Access Modeling (D3-AM) для выявления аномальных паттернов использования аккаунтов, Account Locking (D3-AL) при обнаружении аномалий и Agent Authentication (D3-AA) для усиления механизмов аутентификации.

Что делать: MFA для всех IAM-пользователей и root-аккаунта. CloudTrail с alerting на создание новых IAM-пользователей и access keys. Полный разбор с detection-правилами: Атаки на облачные аккаунты AWS и Azure: техники, detection и реальные кейсы.

Аудит безопасности облачного хранилища: CSPM, инструменты и detection-правила​

Обнаружение мисконфигураций - задача, которую невозможно решить ручными проверками. Облачные ресурсы постоянно создаются, модифицируются и удаляются. Нужен непрерывный автоматизированный мониторинг - Cloud Security Posture Management (CSPM).

Инструменты аудита​

Инструмент	Провайдеры	Назначение	Контекст применения
Prowler	AWS, Azure, GCP	CSPM, compliance (CIS Benchmarks, PCI DSS)	Регулярный аудит, внешний пентест
ScoutSuite	AWS, Azure, GCP, Oracle	Multi-cloud аудит конфигурации	Первичная оценка multi-cloud среды
Trivy	AWS, Azure, GCP	IaC-сканирование + CSPM + containers	Shift-left в CI/CD
CloudMapper	AWS	Визуализация сетевой топологии	Визуализация attack surface
Pacu	AWS	Exploitation framework (offensive)	Внутренний пентест / red team
BlobHunter	Azure	Проверка публичного доступа storage	Точечная проверка Azure (обновление: 2022)

Ограничения: CloudMapper ориентирован только на AWS и имеет ограниченную поддержку. BlobHunter не обновлялся с 2022 года - используйте как дополнительный инструмент, а не основной. Pacu - offensive framework, не подходит для compliance-аудита. В реальных проектах я начинаю с Prowler (бесплатный, покрывает CIS Benchmarks) и дополняю ScoutSuite для multi-cloud.

Detection-правила и верификация​

Для мониторинга подозрительной облачной активности в SigmaHQ доступно 41 detection-правило по тегу T1078.004. Примеры для внедрения в SIEM:

• aws_iam_s3browser_loginprofile_creation.yml - обнаружение создания login-профиля через S3 Browser (persistence)
• azure_tap_added.yml - добавление Temporary Access Pass в Entra ID (легитимная функция для onboarding; аномальна вне HR/onboarding workflow - потенциальный account takeover)
• azure_mfa_denies.yml - множественные отказы MFA (brute force / credential stuffing)

Atomic Red Team предоставляет воспроизводимые тесты для проверки ваших detection-capabilities:

• T1530: AWS - Scan for Anonymous Access to S3 (iaas:aws); Azure - Dump Azure Storage Account Objects via CLI (iaas:azure). Тесты T1530 в Atomic Red Team доступны только для платформ iaas:aws и iaas:azure
• T1619: AWS - Scan for Anonymous Access to S3 (iaas:aws); Azure - Scan for Anonymous Access to Azure Storage (iaas:azure)
• T1078.004: Creating GCP Service Account and Key (iaas:gcp); Azure Persistence Automation Runbook (iaas:azure); GCP - Create Custom IAM Role (iaas:gcp)

Нативные средства провайдеров​

AWS Config + Security Hub, Azure Defender for Storage + Microsoft Defender for Cloud, GCP Security Command Center - нативные CSPM-решения, интегрированные с CloudTrail / Activity Log / Cloud Audit Logs. Минимум для каждой организации: настройка alerting на конкретные события - создание публичного бакета, отключение шифрования, изменение IAM-политики, создание новых access keys.

Что делать: разверните Prowler для начального аудита (бесплатно, покрывает CIS Benchmarks). Настройте Sigma-правила в SIEM для непрерывного мониторинга. Запустите Atomic Red Team тесты для T1530 и T1619 для верификации detection. Полная методология облачного пентеста: Пентест облачной инфраструктуры: методология, инструменты и реальные цепочки атак.

Чеклист: 12 действий для немедленного аудита облачных хранилищ​

Этот чеклист пригоден для передачи security-инженеру или включения в отчёт по аудиту. Каждый пункт - конкретное действие с командой или настройкой.

1. Block Public Access на уровне аккаунта - AWS: aws s3control put-public-access-block; Azure: allowBlobPublicAccess = false на storage account; GCP: organization policy constraints/storage.publicAccessPrevention
2. Аудит существующих публичных бакетов - Prowler check s3_bucket_public_access или ручная проверка через aws s3api get-bucket-acl для каждого бакета
3. Включить versioning на всех бакетах с критичными данными - защита от перезаписи и S3-ransomware
4. Настроить Object Lock (compliance mode) - иммутабельность объектов на заданный retention period
5. Включить MFA Delete - запрет удаления версий объектов без MFA-подтверждения
6. Принудительно включить IMDSv2 на всех EC2-инстансах - HttpTokens=required (защита от SSRF к metadata)
7. Аудит IAM-политик - удалить wildcard permissions ("Action": "*"), провести ротацию access keys старше 90 дней, удалить неиспользуемые ключи
8. Включить CloudTrail Data Events для S3 - логирование GetObject/PutObject/DeleteObject для forensics и alerting
9. Проверить публичные EBS- и RDS-снапшоты - aws ec2 describe-snapshots --owner-ids <your-account-id> --query 'Snapshots[].SnapshotId' --output text | xargs -n1 -I{} aws ec2 describe-snapshot-attribute --snapshot-id {} --attribute createVolumePermission; aws rds describe-db-snapshots --snapshot-type public
10. Настроить encryption at rest - SSE-KMS с customer-managed keys (AWS), Entra ID auth + customer-managed keys через Key Vault (Azure), CMEK (GCP)
11. Развернуть CSPM - Prowler/ScoutSuite для continuous monitoring или нативный Security Hub / Defender for Cloud / Security Command Center
12. Интегрировать IaC-сканирование в CI/CD - Trivy/Checkov в pre-merge проверку Terraform/CloudFormation/Kubernetes-манифестов

Для Azure дополнительно: отключить shared key access (использовать только Entra ID auth), user-delegation SAS вместо account SAS, Private Endpoints для storage accounts.

Для GCP дополнительно: включить uniform bucket-level access, организационная политика запрета создания ключей сервисных аккаунтов, VPC Service Controls для предотвращения data exfiltration.

Куда движется облачная безопасность: прогноз и приоритеты​

Cloud Security Alliance в отчёте за 2024 год поставил мисконфигурации и недостаточный контроль изменений на первое место среди облачных угроз - поднявшись с третьей позиции всего за два года. Динамика однозначна: рост облачных вторжений с 26% в 2024-м до 37% в 2025-м (CybelAngel) - устойчивая кривая, а не временный всплеск.

Три сдвига, которые определят ближайший год.

Shift-left станет обязательным. Обнаружение мисконфигурации после деплоя - запоздалая реакция. CSPM + IaC-сканирование в CI/CD + Policy-as-Code - минимальный стек для организации, которая не хочет попасть в новости. По данным CloudAdvisor (со ссылкой на Gartner), к 2026 году 60% организаций будут рассматривать предотвращение мисконфигураций как приоритет облачной безопасности. Первоисточник Gartner не верифицирован.

Ransomware в облаке перестанет быть экзотикой. Кампания Codefinger и исследования Trend Micro показали, что S3-ransomware технически созрел. Следующий шаг - массовая автоматизация, эксплуатирующая типовые мисконфигурации по шаблону.

Credential theft продолжит ускоряться. При 6000+ утечках credentials ежедневно и сокращении времени lateral movement до минут и секунд - detection и response обязаны работать в реальном времени.

Приоритет прямо сейчас: пройдите чеклист из 12 пунктов выше. Это закроет 80% типовых мисконфигураций за один спринт.

Если хотите отработать описанные техники в контролируемой среде - от разведки открытых S3-бакетов до эксплуатации IAM-мисконфигураций и построения полной kill chain - обратите внимание на курсы Codeby по пентесту и облачной безопасности. Практические лаборатории с реальными сценариями, feedback от действующих специалистов.

Большинство команд, которые я вижу на аудитах, тратят бюджет на WAF, EDR и SIEM - и при этом держат S3-бакеты с продакшн-данными в режиме public-read. Не преувеличение. Тысячи мисконфигурированных ресурсов на среднее предприятие - и месяцы до обнаружения.

Проблема не в инструментах. Prowler бесплатен, AWS Config стоит копейки, Block Public Access включается одной командой. Проблема в организационной слепоте: конфигурация облака не воспринимается как поверхность атаки. Security-команда мониторит сетевой трафик и эндпоинты, а облачный control plane - зона ответственности «кого-то из DevOps». Этот «кто-то» создаёт бакет для тестового пайплайна, делает его публичным для интеграции с подрядчиком, переключается на следующую задачу - и через неделю в бакете лежат SQL-дампы с PII.

Shared responsibility model уже десять лет объясняет, что конфигурация - зона клиента. Но на аудитах я продолжаю находить публичные бакеты у компаний с SOC, SIEM и шестью сертификациями ISO. Проблема глубже: облачная безопасность - не надстройка поверх существующей ИБ-программы, а отдельная дисциплина с собственным инструментарием, процессами и competency model. Кто через год будет воспринимать CSPM как «ещё одну утилиту для галочки», а не как фундаментальный слой мониторинга наравне с SIEM - будет узнавать о своих мисконфигурациях из публичных отчётов исследователей. Или из требования выкупа.