Пентест хмари і аудит безпеки AWS, Azure, Google Cloud: що перевіряють і що підготувати

Перевірка безпеки хмари AWS, Azure чи Google Cloud шукає те, що відкриває ваші дані без жодного зламу провайдера: зайві права в IAM, публічні сховища, ключі в коді, відкриті порти, вимкнені журнали, слабкі налаштування Kubernetes і конвеєра CI/CD. Є два формати: аудит конфігурації з роллю лише на читання за CIS Benchmarks і пентест, який перевіряє, чи можна цими слабкими місцями справді скористатися.

Нижче пояснюю, за що відповідає провайдер, а за що ви, що саме дивляться в кожній зоні, чим аудит відрізняється від пентесту, які правила тестування діють у AWS, Microsoft Azure і Google Cloud станом на жовтень 2026 року, що підготувати і що отримати в результаті. Загальну підготовку до будь-якого тесту описано в статті як підготуватися до пентесту.

Коротко

• Провайдер захищає саму хмару, ви захищаєте те, що в ній налаштували. Дані, акаунти, права доступу і налаштування завжди на вашому боці. ^{[5] [6]}
• Аудит конфігурації порівнює налаштування з CIS Benchmarks через роль лише на читання і нічого не змінює. Пентест хмари активно перевіряє, куди може дійти зловмисник із публічного доступу або з одного вкраденого ключа.
• Найчастіші знахідки це зайві права, публічні сховища, довгострокові ключі в коді й конвеєрах, відкриті порти керування і журнали, які ніхто не зберігає довше за стандартні строки.
• Погодження провайдера. AWS, Azure і Google Cloud не вимагають попереднього дозволу на тест власних ресурсів, але всі забороняють DoS. AWS вимагає окрему заявку щонайменше за два тижні для прихованих симуляцій атак, серверів керування (C2) і симуляцій фішингу. ^{[1] [2] [4]}
• Від вас потрібні роль лише на читання, список акаунтів, підписок чи проєктів і контакт, який може зупинити тест.

Що перевіряють у хмарі: таблиця

Спільна відповідальність: що ваше, а що провайдера

AWS формулює це так: провайдер відповідає за безпеку самої хмари, тобто обладнання, мережу і дата-центри, а клієнт за безпеку в хмарі. На боці клієнта операційна система віртуальних машин, дані та їх шифрування, права в IAM і налаштування групи безпеки (брандмауера) кожного сервера. ^[5]

Microsoft у своїй матриці відповідальності прямо пише, що за будь-якої моделі, від віртуальних машин до готових сервісів, за клієнтом залишаються дані, акаунти, керування доступом і налаштування. ^[6]

Практичний висновок простий: більшість хмарних інцидентів починаються не зі зламу провайдера, а з налаштування клієнта. Публічне сховище або ключ адміністратора в репозиторії провайдер не виправить за вас.

Аудит конфігурації і пентест хмари: у чому різниця

Аудит конфігурації (configuration review) дивиться на налаштування зсередини через роль лише на читання. Еталоном зазвичай служать CIS Benchmarks: безкоштовні для некомерційного використання рекомендації з безпечних налаштувань, які готує спільнота Center for Internet Security. Є окремі документи для AWS Foundations, Microsoft Azure Foundations, Google Cloud Platform Foundation, Kubernetes, а також для EKS, AKS і GKE. ^[7] Аудит швидкий, нічого не ламає і показує повну картину налаштувань, але не відповідає на запитання «а що з цього реально використати».

Пентест хмари перевіряє ланцюжки. Наприклад: публічна функція повертає помилку з ключем доступу, ключ дає право читати сховище, у сховищі лежить резервна копія бази. Тестувальник працює з двох позицій: ззовні, як будь-хто з інтернету, і з погодженої точки входу, наприклад з обліковими даними звичайного розробника чи скомпрометованого сервера. Так видно, наскільки далеко дійде зловмисник, якщо один ключ уже витік.

Для першої перевірки зазвичай достатньо аудиту конфігурації: він знаходить найпоширеніші проблеми найдешевше. Пентест має сенс, коли базові налаштування вже в порядку, або коли в хмарі живе продукт із даними клієнтів. Часто їх поєднують: аудит усього середовища і пентест критичних застосунків. Детальніше про різницю між автоматичною перевіркою і ручним тестом у статті пентест чи сканування вразливостей.

1. IAM і зайві права

IAM (керування ідентичностями і доступом) це головна зона ризику в будь-якій хмарі. Дивляться:

• хто має права адміністратора: Owner у Azure, Owner чи Editor у Google Cloud, AdministratorAccess в AWS;
• ролі й політики з правом на будь-яку дію над будь-яким ресурсом;
• невикористані користувачі, ролі й ключі доступу;
• MFA для людей і захист root-акаунта в AWS;
• хто може сам собі підняти права, наприклад створити нову політику або видати собі роль.

AWS радить, щоб люди входили через єдиний вхід з тимчасовими обліковими даними, а застосунки працювали через ролі, а не через довгострокові ключі. Невикористані ролі, права й ключі варто регулярно знаходити за даними останнього використання і видаляти. ^[8]

2. Публічні сховища

Сховище з доступом «для всіх» досі один із найпростіших способів втратити дані. В AWS нові бакети S3 за замовчуванням закриті від публічного доступу, але політика бакета чи ACL можуть його відкрити. Тому перевіряють, чи ввімкнене блокування публічного доступу S3 на рівні всього акаунта, а не лише окремих бакетів. ^[9] В Azure дивляться анонімний доступ до контейнерів Blob Storage і посилання SAS (тимчасові посилання з правами) з довгим строком дії. У Google Cloud шукають бакети з доступом для allUsers чи allAuthenticatedUsers.

Перевіряють і зворотне: чи не посилається ваш домен на видалений бакет або сервіс. Такий запис DNS дозволяє чужому акаунту зайняти ім'я і віддавати контент від вашого імені. Під час тесту такий запис лише фіксують: саме захоплення бакета чи піддомену AWS забороняє. ^[1]

3. Ключі й секрети

Ключ доступу до хмари в репозиторії, у Docker-образі, у змінних оточення функції чи в журналі збірки фактично дорівнює паролю адміністратора. Дивляться:

• історію Git, а не лише поточну версію коду: видалений ключ залишається в старих комітах;
• змінні оточення функцій і контейнерів;
• секрети в сховищах ключів (AWS Secrets Manager, Azure Key Vault, Google Secret Manager) і хто може їх читати;
• вік ключів доступу і чи їх хтось змінював.

Знайдений ключ не використовують для доступу до чужих систем. Правила Microsoft окремо забороняють використовувати облікові дані, які вам не належать, навіть якщо вони витекли публічно. ^[3]

4. Мережа і групи безпеки

Групи безпеки в AWS, NSG (мережеві групи безпеки) в Azure і правила брандмауера VPC у Google Cloud визначають, що доступне з інтернету. Типові знахідки: SSH (порт 22), RDP (3389) чи порт бази даних відкриті для всього інтернету, забуті тестові сервери з публічною адресою, бази даних із публічним доступом. Добрий результат: керування серверами йде через бастіон, VPN або сервіс провайдера на кшталт AWS Systems Manager, Azure Bastion чи IAP у Google Cloud, а з інтернету відкриті лише вебпорти тих сервісів, які мають бути публічними.

Зовнішнє сканування ваших публічних адрес показує те саме з боку зловмисника. Його дозволяють усі три провайдери для власних ресурсів. ^{[1] [2] [4]}

5. Журнали і моніторинг

Без журналів після інциденту ніхто не скаже, хто що змінив і що забрав. Що є за замовчуванням:

• AWS CloudTrail. Історія подій увімкнена автоматично, але зберігає лише 90 днів подій керування в кожному регіоні і не показує подій доступу до даних. Для довшого зберігання потрібен trail або сховище подій. ^[10]
• Azure Activity Log. Збирається без налаштувань, але зберігається 90 днів. Довше лише через налаштування діагностики з експортом в Log Analytics чи сховище. Журнали дій усередині ресурсів (наприклад, читання секрету з Key Vault) за замовчуванням не збираються. ^[11]
• Google Cloud Audit Logs. Журнали адміністративних дій пишуться завжди, і вимкнути їх не можна. Журнали доступу до даних, крім BigQuery, за замовчуванням вимкнені. ^[12] Адміністративні журнали зберігаються 400 днів, решта за замовчуванням 30 днів. ^[13]

Перевіряють також, чи журнали з усіх акаунтів, підписок чи проєктів збираються в одне місце, чи захищені вони від видалення і чи є сповіщення на критичні події: вхід root, зміна політик, вимкнення журналу.

6. Kubernetes і керовані сервіси

Для EKS, AKS і GKE дивляться базове: чи доступний API кластера з усього інтернету, як влаштовані права всередині кластера (RBAC), чи не мають поди прав, з якими можна вийти в хмарний акаунт, чи оновлена версія кластера. Для цього теж є окремі CIS Benchmarks. ^[7] Для керованих баз даних, функцій і черг перевіряють публічний доступ, шифрування і права сервісних акаунтів, з якими вони працюють.

7. CI/CD і доступи конвеєра

Конвеєр збірки й розгортання часто має права ширші, ніж будь-яка людина в команді. Якщо в секретах GitHub Actions, GitLab CI чи Azure DevOps лежить довгостроковий ключ адміністратора, будь-хто, хто змінить файл конвеєра, отримає цей ключ. Кращий варіант: вхід через OIDC, коли провайдер видає короткий токен лише на одну задачу, і в GitHub немає збереженого хмарного ключа. Це підтримують AWS, Azure і Google Cloud. ^[14] Перевіряють також, хто може змінювати конвеєр і чи обмежено, з якої гілки дозволено розгортання в робоче середовище.

Правила AWS, Azure і Google Cloud для пентесту

Станом на жовтень 2026 року:

• AWS. Попереднє погодження не потрібне для сервісів зі списку дозволених, серед них EC2, RDS, Aurora, CloudFront, API Gateway, Lambda, Lightsail, Elastic Beanstalk, ECS і Fargate. Для інших сервісів звертаються в підтримку AWS. Заборонені DoS і DDoS, зокрема їх симуляція, флуд портів, протоколів і запитів, обхід зон DNS у Route 53, а також захоплення бакетів S3 і піддоменів. Приховані симуляції атак, сервери керування (C2), симуляції фішингу й тестування шкідливим ПЗ потребують окремої заявки щонайменше за два тижні до старту. ^[1]
• Microsoft Azure. Попереднє погодження не вимагається з 15 червня 2017 року, але діють Microsoft Cloud Unified Penetration Testing Rules of Engagement. Заборонені DoS будь-якого виду, доступ до чужих тенантів і сховищ, використання чужих облікових даних, фазинг із надмірним трафіком, фішинг працівників Microsoft або фішинг інших людей через сервіси Microsoft, а також дії після експлуатації проти сервісів самої Microsoft. Перевірити стійкість до DDoS можна через партнерів, яких рекомендує Microsoft. ^{[2] [3]}
• Google Cloud. Повідомляти Google не потрібно. Тест має зачіпати лише ваші проєкти і відповідати правилам допустимого використання та умовам Google Cloud. ^[4]

Усі три правила стосуються інфраструктури провайдера. Дозвіл на тест ваших ресурсів дає не провайдер, а ви: письмово, із межами і контактами. Правила змінюються, тож перед стартом відкрийте актуальні сторінки за посиланнями в джерелах.

Що потрібно від вас

• Межі перевірки. Список акаунтів AWS, підписок Azure чи проєктів Google Cloud, регіонів і середовищ. Окремо, що поза межами: сторонні SaaS-сервіси, акаунти партнерів.
• Роль лише на читання. В AWS це зазвичай керовані політики SecurityAudit і ViewOnlyAccess, в Azure ролі Reader і Security Reader на рівні підписки або групи керування, у Google Cloud ролі Viewer і Security Reviewer на рівні організації чи проєкту. Видається на строк перевірки і відкликається після.
• Для пентесту. Перелік публічних адрес і доменів, погоджена точка входу (наприклад, обліковий запис рівня розробника) і що заборонено: зміна даних, видалення ресурсів, тест у робочі години.
• Опис архітектури. Навіть проста схема: де застосунок, де бази даних, як іде розгортання.
• Контакти. Хто приймає термінові повідомлення і хто може зупинити тест.
• Письмовий дозвіл. Підписує людина, яка має право давати доступ до хмарних акаунтів компанії.

Повний чекліст підготовки з таблицею відповідальних є в статті як підготуватися до пентесту.

Що ви отримаєте

• Короткий висновок для керівництва: що знайдено, чим загрожує бізнесу, що виправляти першим.
• Кожну знахідку окремо: у якому акаунті чи проєкті, на якому ресурсі, доказ, вплив, рівень серйозності і як виправити, з посиланням на пункт CIS Benchmarks або рекомендацію провайдера, де це доречно.
• Для пентесту: описані шляхи атаки від точки входу до даних, крок за кроком.
• Перелік перевіреного і неперевіреного, щоб ніхто не вважав безпечним акаунт, якого не дивилися.
• Повідомлення про критичне одразу, наприклад про публічне сховище з персональними даними, без очікування звіту.
• Ретест (повторну перевірку після виправлень), якщо він входить у погоджений обсяг.

Що робити зі звітом далі, описано в статті що робити після пентесту. Ширшу картину безпеки компанії, від процесів до доступів, дає Security Assessment.

Чекліст перед перевіркою хмари

• Складено список усіх акаунтів, підписок і проєктів, включно з тестовими.
• Видано роль лише на читання на строк перевірки.
• Root-акаунт AWS і всі адміністратори мають MFA.
• Блокування публічного доступу S3 увімкнене на рівні акаунта, публічні сховища пояснені.
• Перевірено, що в репозиторіях і конвеєрах немає довгострокових хмарних ключів.
• SSH, RDP і бази даних не відкриті для всього інтернету.
• Журнали всіх акаунтів зберігаються довше за стандартні 90 днів в одному захищеному місці.
• API кластерів Kubernetes не доступний з усього інтернету без потреби.
• Перевірено актуальні правила тестування свого провайдера.
• Підписано дозвіл, визначено контакт, який може зупинити тест.

Завантажити чекліст підготовки (PDF)PDF · A4

FAQ

Чи потрібен дозвіл AWS, Azure або Google Cloud на пентест?

Станом на жовтень 2026 року для тесту власних ресурсів попереднього дозволу не треба, але треба дотримуватися правил кожного провайдера. AWS окремо вимагає заявку за два тижні для прихованих симуляцій атак, C2 і симуляцій фішингу. DoS заборонений у всіх трьох.

Чим аудит конфігурації відрізняється від пентесту хмари?

Аудит через роль лише на читання показує, що налаштовано не так, порівнюючи з CIS Benchmarks. Пентест перевіряє, чи можна цими помилками скористатися і куди дійде зловмисник. Аудит дешевший і безпечніший, пентест дає докази реальних шляхів атаки.

Чи може перевірка зламати робочу систему?

Аудит конфігурації ні: він лише читає налаштування. Пентест працює в погоджених межах без DoS і без видалення даних, а ризиковані кроки погоджують окремо. Свіжа резервна копія і контакт, який може зупинити тест, все одно потрібні.

Чи достатньо вбудованих інструментів провайдера?

AWS Security Hub, Microsoft Defender for Cloud і Security Command Center у Google Cloud корисні для постійного контролю налаштувань. Але вони не бачать ланцюжків атаки, логіки ваших застосунків і ключів у коді поза хмарою. Їх варто ввімкнути, а незалежну перевірку робити періодично.

Скільки триває перевірка хмари?

Залежить від кількості акаунтів, підписок чи проєктів і від того, чи потрібен пентест. Аудит одного невеликого середовища може зайняти кілька днів, кілька середовищ із пентестом довше. Строк і вартість фіксують до початку, після погодження меж.

Посилання

1. AWS: Penetration Testing aws.amazon.com
2. Microsoft Learn: Penetration testing (Azure) learn.microsoft.com
3. Microsoft Cloud Unified Penetration Testing Rules of Engagement microsoft.com
4. Google Cloud Security FAQ support.google.com
5. AWS: Shared Responsibility Model aws.amazon.com
6. Microsoft Learn: Shared responsibility in the cloud learn.microsoft.com
7. Center for Internet Security: CIS Benchmarks cisecurity.org
8. AWS: Security best practices in IAM docs.aws.amazon.com
9. AWS: Blocking public access to your Amazon S3 storage docs.aws.amazon.com
10. AWS: Working with CloudTrail event history docs.aws.amazon.com
11. Microsoft Learn: Activity log in Azure Monitor learn.microsoft.com
12. Google Cloud: Cloud Audit Logs overview docs.cloud.google.com
13. Google Cloud: Cloud Logging quotas and limits docs.cloud.google.com
14. GitHub Docs: OpenID Connect docs.github.com