Пентест хмарної інфраструктури AWS/Azure: що входить в обсяг робіт (scope)
Пентест хмарної інфраструктури (AWS або Microsoft Azure) перевірка реальної стійкості вашого cloud-середовища до атак з точки зору зловмисника, але в межах погодженого scope (обсягу робіт) та правил тестування. Найчастіше мета — знайти ризики неправильних конфігурацій, надмірних доступів, витоків секретів, вразливостей у сервісах і CI/CD, які можуть привести до компрометації акаунтів, даних і критичних систем.
Далі розповідаємо, що саме зазвичай включають у scope пентесту AWS/Azure, що не включають, та як правильно сформувати обсяг робіт, щоб отримати корисний результат.
Що таке scope у пентесті AWS/Azure
Scope — це список систем, сервісів, акаунтів/підписок, регіонів, мереж, застосунків і сценаріїв, які дозволено тестувати. Чітко визначений обсяг робіт (scope) важливо погодити до старту, тому що в хмарі ресурси швидко змінюються, частина сервісів може бути спільною або належати третім сторонам, а тестування “без меж” легко призводить до зайвих ризиків — від випадкових збоїв і простоїв до небажаних витрат і перевірки того, що взагалі не можна тестувати.
Що входить до обсягу робіт з пентесту хмарної інфраструктури (AWS/Azure)
1) Ідентифікація та доступи: IAM / Entra ID
Це майже завжди найважливіша частина cloud-пентесту, бо більшість компрометацій у хмарі починаються з доступів.
Що входить в обсяг робіт:
- AWS IAM: користувачі, ролі, політики, trust relationships, cross-account доступи, permissions boundaries, SCP (якщо AWS Organizations).
- Azure: Microsoft Entra ID (Azure AD), RBAC ролі, PIM/PAM, conditional access, service principals, managed identities.
- Надмірні привілеї (over-permissioned roles), можливість privilege escalation.
- Небезпечні комбінації прав (наприклад, право змінювати політики та право передавати роль).
- Ротація ключів, MFA/безпарольні механізми, політики паролів, legacy auth.
- Доступи до консолі, API, CLI, федерація (SSO), сторонні IdP.
Як результат, ви бачите просту і зрозумілу картину: хто і до чого має доступ у вашій хмарі AWS/Azure, де ці доступи занадто широкі, і як саме через це можна отримати права адміністратора. Також ви отримуєте перелік конкретних змін, які потрібно зробити, щоб закрити ці ризики.
2) Секрети та ключі: Secrets Management, KMS/Key Vault
Неправильне зберігання секретів — часта причина зламів.
Обсяг робіт:
- AWS Secrets Manager / SSM Parameter Store: політики доступу, шифрування, ротація, логування доступів.
- Azure Key Vault: access policies / RBAC, network rules, private endpoints, purge protection, soft delete.
- KMS / Azure Key Management: ключі, політики, who-can-decrypt, use of customer-managed keys.
- Пошук секретів у репозиторіях, CI/CD, образах контейнерів, конфігураціях, змінних середовища.
- Перевірка витоків токенів (GitHub, Azure DevOps, GitLab, Jenkins тощо).
3) Мережа та сегментація: VPC/VNet, Security Groups/NSG, маршрутизація
Перевіряють, чи можна переміщатися всередині хмари і чи доступна частина вашої хмарної інфраструктури з інтернету без потреби або має слабкий захист.
AWS:
- VPC, Subnets, Route Tables, Internet/NAT Gateways, NACL, Security Groups.
- VPC Endpoints (PrivateLink), peering, Transit Gateway, VPN/Direct Connect.
Azure:
- VNet, Subnets, NSG/ASG, UDR, VPN/ExpressRoute.
- Private Link/Private Endpoints, peering, Azure Firewall.
Перевіряється:
- Відкриті адмін-порти (SSH/RDP), керуючі інтерфейси, «0.0.0.0/0».
- Неправильна сегментація (prod/dev в одному сегменті).
- Можливість lateral movement між підмережами / акаунтами.
- Доступність metadata service (IMDS) і ризик SSRF → крадіжка ролей/токенів.
4) Публічна поверхня атаки: exposed ресурси та конфігурації
Спочатку перевіряють те, до чого є доступ з інтернету.
У scope зазвичай включають:
- Публічні IP/ендпоїнти (Load Balancers, App Gateway, API Gateway, CloudFront/CDN).
- Відкриті сховища: AWS S3: public ACL/policies, bucket listing, presigned URLs, object-level perms. Azure Storage: blob containers, SAS tokens, public access, account keys.
- AWS S3: public ACL/policies, bucket listing, presigned URLs, object-level perms.
- Azure Storage: blob containers, SAS tokens, public access, account keys.
- Публічні бази даних/керовані сервіси: AWS RDS, OpenSearch/Elasticsearch, Redis, etc. Azure SQL, Cosmos DB, Redis, etc.
- AWS RDS, OpenSearch/Elasticsearch, Redis, etc.
- Azure SQL, Cosmos DB, Redis, etc.
- Конфігурації WAF/Front Door/Cloudflare (якщо використовується), rate limits, geo rules.
5) Контейнери та Kubernetes: EKS/AKS, Registry, runtime
Якщо у вас мікросервіси або Kubernetes — це окремий великий блок для пентесту.
Scope може включати:
- EKS/AKS: RBAC, service accounts/managed identity, network policies, admission controls.
- Cluster API exposure, kubeconfig leakage, etcd access risks (за наявності).
- Container images: слабкі базові образи, секрети в шарах, вразливі залежності.
- Registry (ECR/ACR): доступи, public/private, token handling.
- Runtime misconfig: privileged containers, hostPath mounts, CAP_SYS_ADMIN, insecure node settings.
6) Серверні обчислення: Lambda / Azure Functions
Що тестують:
- IAM/role для функцій (least privilege).
- Тригери та подієві ланцюги (S3 → Lambda, Queue → Function).
- Ін’єкції через payload, небезпечні бібліотеки, витоки env vars.
- Доступ функції до мережі (VPC/VNet integration) і можливість pivot у приватні сегменти.
7) CI/CD та IaC: Terraform, CloudFormation, Bicep, pipelines
Це місце, де часто зберігаються ключі і де компрометація дає повний контроль над інфраструктурою.
У scope включають:
- Azure DevOps / GitHub Actions / GitLab CI / Jenkins: права токенів, секрети, service connections.
- IaC репозиторії: неправильні шаблони security groups/NSG, відкриті buckets, hardcoded secrets.
- Artifact storage, container build pipelines, підміна артефактів, supply-chain ризики.
8) Логи та моніторинг: CloudTrail/Defender, Sentinel, GuardDuty
Перевіряється чи побачить ваша команда підозрілі дії вчасно.
Що перевіряють:
- Увімкнений/неувімкнений аудит: AWS CloudTrail, Config, GuardDuty. Azure Activity Logs, Defender for Cloud, Microsoft Sentinel.
- AWS CloudTrail, Config, GuardDuty.
- Azure Activity Logs, Defender for Cloud, Microsoft Sentinel.
- Необхідні алерти на підозрілі дії (створення ключів, зміна політик, вимкнення логів).
- Захист логів від видалення/підміни (immutability, retention, доступи).
Що зазвичай НЕ входить у scope (або вимагає окремого узгодження)
- DoS/Stress/Load testing (ризик простоїв і витрат).
- Атаки на самого хмарного провайдера або multi-tenant інфраструктуру.
- Тестування сторонніх SaaS, якщо вони не ваші (наприклад, окремі продукти/інтеграції без дозволу).
- Соціальна інженерія, фішинг, фізичний доступ — якщо не замовлено окремо.
- Продакшен-експлуатація з руйнівними діями (видалення ресурсів, шифрування даних) — лише контрольовані PoC.
Який обсяг роботи варто зафіксувати перед початком робіт (зазвичай SOW / Rules of Engagement)
- Облікові межі
- AWS Accounts / Azure Subscriptions / Management Groups
- Тенант Entra ID (якщо застосовно)
- Регіони та середовища
- prod / staging / dev
- конкретні регіони (наприклад, eu-central-1, westeurope)
- Сервіси в периметрі
- IAM/Entra, VPC/VNet, S3/Storage, EKS/AKS, RDS/Azure SQL, Functions/Lambda, WAF тощо
- Рівень доступу під час тесту
- Black-box (без доступів)
- Grey-box (read-only/limited)
- White-box (детальний доступ + IaC/архітектура)
- Методи та обмеження
- Заборонені техніки (DoS, brute force на MFA, масове сканування з високою інтенсивністю)
- Вікна тестування (коли можна працювати)
- Контакти для ескалації, stop-test процедура
- Критерії успіху та артефакти
- Звіт із ризиками, PoC, пріоритизація, план ремедіації
- Повторна перевірка (retest) після виправлень
До обсягу робіт з пентесту хмарної інфраструктури AWS/Azure входить тестування IAM/Entra, секрети, мережу, публічні сервіси, контейнери/Kubernetes, serverless, CI/CD та логування. Саме така комбінація дає реальну відповідь на питання: чи може зловмисник отримати доступ до ваших даних і керування хмарою, і яким чином.
FAQ: короткі відповіді на популярні питання
1. Чи можна робити пентест AWS/Azure без доступу? Так, але це дає лише частину картини (публічна поверхня). Найбільші ризики зазвичай у IAM/Entra та внутрішніх конфігураціях, для них потрібен хоча б grey-box.
2. Що важливіше: мережа чи IAM? У хмарі зазвичай IAM/Entra важливіше: з надмірними правами атакувальник може обійти мережеві бар’єри через API.
3. Чи входить аналіз Terraform/Bicep? Часто так, але це краще окремо виділяти як IaC security review в межах пентесту або як додатковий модуль.