Last updated
Вивчайте та практикуйте AWS Hacking: Вивчайте та практикуйте GCP Hacking:
Google Cloud використовує , яка концептуально схожа на традиційну файлову систему. Це забезпечує логічний робочий процес батьків/дочок з конкретними точками прив'язки для політик і дозволів.
На високому рівні це виглядає так:
Віртуальна машина (називається Compute Instance) є ресурсом. Ресурс знаходиться в проекті, ймовірно, поряд з іншими Compute Instances, сховищами, тощо.
Дозволяють централізувати контроль над ресурсами хмари вашої організації:
Централізувати контроль для налаштування обмежень на те, як можуть використовуватися ресурси вашої організації.
Визначити та встановити обмеження для ваших команд розробників, щоб залишатися в межах відповідності.
Допомогти власникам проектів та їх командам швидко рухатися без побоювань щодо порушення відповідності.
Ці політики можуть бути створені для впливу на всю організацію, папки або проекти. Наслідники цільового вузла ієрархії ресурсів успадковують політику організації.
Обмежити обмін ресурсами на основі домену.
Обмежити використання облікових записів служби управління ідентифікацією та доступом.
Обмежити фізичне розташування новостворених ресурсів.
Вимкнути створення облікових записів служби.
Це схоже на політики IAM в AWS, оскільки кожна роль містить набір дозволів.
Однак, на відміну від AWS, немає централізованого репозиторію ролей. Замість цього, ресурси надають X ролей доступу Y принципалам, і єдиний спосіб дізнатися, хто має доступ до ресурсу, - це використовувати метод get-iam-policy для цього ресурсу.
Це може бути проблемою, оскільки це означає, що єдиний спосіб дізнатися, які дозволи має принципал, - це запитати кожен ресурс, кому він надає дозволи, і користувач може не мати дозволів, щоб отримати дозволи з усіх ресурсів.
Існує три типи ролей у IAM:
Основні/примітивні ролі, які включають ролі Власника, Редактора та Переглядача, що існували до впровадження IAM.
Користувацькі ролі, які надають детальний доступ відповідно до списку дозволів, вказаного користувачем.
У консолі GCP немає управління Користувачами або Групами, це робиться в Google Workspace. Хоча ви можете синхронізувати інший постачальник ідентичності в Google Workspace.
MFA може бути вимушена для користувачів Workspace, однак зловмисник може використовувати токен для доступу до GCP через cli, який не буде захищений MFA (він буде захищений MFA лише тоді, коли користувач входить для його генерації: gcloud auth login).
Коли створюється організація, кілька груп рекомендується створити. Якщо ви керуєте будь-якою з них, ви можете скомпрометувати всю організацію або важливу її частину:
Вимагати сильні паролі
Від 8 до 100 символів
Без повторного використання
Без терміну дії
Якщо люди отримують доступ до Workspace через стороннього постачальника, ці вимоги не застосовуються.
Це принципали, які ресурси можуть мати прикріпленими та доступом для легкого взаємодії з GCP. Наприклад, можливо отримати доступ до токена автентифікації облікового запису служби прикріпленого до ВМ у метаданих.
Можливо зіткнутися з деякими конфліктами при використанні як IAM, так і обмежень доступу. Наприклад, ваш обліковий запис служби може мати роль IAM compute.instanceAdmin, але екземпляр, до якого ви отримали доступ, має обмеження за обсягом https://www.googleapis.com/auth/compute.readonly. Це завадить вам вносити будь-які зміни, використовуючи токен OAuth, який автоматично призначається вашому екземпляру.
Це схоже на ролі IAM з AWS. Але не так, як в AWS, будь-який обліковий запис служби може бути прикріплений до будь-якої служби (не потрібно дозволяти це через політику).
Декілька облікових записів служби, які ви знайдете, насправді автоматично генеруються GCP при початку використання служби, як:
Однак також можливо створювати та приєднуватися до ресурсів кастомних облікових записів служби, які виглядатимуть так:
Існує 2 основні способи доступу до GCP як до облікового запису служби:
Через OAuth токени: Це токени, які ви отримаєте з таких місць, як кінцеві точки метаданих або шляхом викрадення http запитів, і вони обмежені обсягами доступу.
Ключі: Це пари публічних і приватних ключів, які дозволять вам підписувати запити як обліковий запис служби і навіть генерувати OAuth токени для виконання дій як обліковий запис служби. Ці ключі небезпечні, оскільки їх складніше обмежити і контролювати, тому GCP рекомендує не генерувати їх.
Обсяги доступу прикріплені до згенерованих OAuth токенів для доступу до кінцевих точок API GCP. Вони обмежують дозволи OAuth токена. Це означає, що якщо токен належить власнику ресурсу, але не має в обсязі токена доступу до цього ресурсу, токен не може бути використаний для (зловживання) цими привілеями.
Ви можете побачити, які обсяги призначені, запитуючи:
Попередні сфери - це ті, що генеруються за замовчуванням за допомогою gcloud для доступу до даних. Це тому, що коли ви використовуєте gcloud, спочатку ви створюєте токен OAuth, а потім використовуєте його для зв'язку з кінцевими точками.
Найважливішою сферою з цих потенційно є cloud-platform, що в основному означає, що можливо доступ до будь-якої служби в GCP.
Якщо у вас є gcloud облікові дані браузера, можливо отримати токен з іншими сферами, зробивши щось на зразок:
Членства: Ви встановлюєте принципалів як членів ролей без обмежень щодо ролі або принципалів. Ви можете призначити користувача членом ролі, а потім призначити групу членом тієї ж ролі, а також встановити цих принципалів (користувача та групу) членами інших ролей.
Прив'язки: Кілька принципалів можуть бути прив'язані до ролі. Ці принципали все ще можуть бути прив'язані або бути членами інших ролей. Однак, якщо принципал, який не прив'язаний до ролі, встановлений як член прив'язаної ролі, наступного разу, коли прив'язка буде застосована, членство зникне.
Політики: Політика є авторитетною, вона вказує ролі та принципалів, і тоді ці принципали не можуть мати більше ролей, а ці ролі не можуть мати більше принципалів, якщо ця політика не буде змінена (навіть в інших політиках, прив'язках або членствах). Тому, коли роль або принципал вказані в політиці, всі їхні привілеї є обмеженими цією політикою. Очевидно, це можна обійти, якщо принципалу надано можливість змінювати політику або дозволи на ескалацію привілеїв (наприклад, створити нового принципала та прив'язати його до нової ролі).
Можливо мігрувати проект без організації в організацію з правами roles/resourcemanager.projectCreator та roles/resourcemanager.projectMover. Якщо проект знаходиться в іншій організації, потрібно зв'язатися з підтримкою GCP, щоб спочатку перемістити їх з організації. Для отримання додаткової інформації перегляньте .
Щоб визначити політику організації, ви вибираєте , яке є певним типом обмеження щодо або служби Google Cloud, або групи служб Google Cloud. Ви налаштовуєте це обмеження з вашими бажаними обмеженнями.
Існує багато інших обмежень, які надають вам детальний контроль над ресурсами вашої організації. Для додаткової інформації дивіться .
Попередньо визначені ролі, які надають детальний доступ до конкретної служби та керуються Google Cloud. Існує багато попередньо визначених ролей, ви можете переглянути всі з ними привілеї .
В GCP є тисячі дозволів. Щоб перевірити, чи має роль дозволи, ви можете і подивитися, які ролі його мають.
Ви також можете пропоновані кожним продуктом. Зверніть увагу, що деякі ролі не можуть бути прикріплені до користувачів і тільки до СА через деякі дозволи, які вони містять. Більше того, зверніть увагу, що дозволи набудуть чинності лише якщо вони прикріплені до відповідної служби.
Або перевірте, чи може користувацька роль використовувати .
Ви можете отримати доступ до користувачів і груп Workspace за адресою .
Зверніть увагу, що кожного разу, коли створюється SA, GCP генерує ключ для облікового запису служби, до якого користувач не має доступу (і який не буде вказано в веб-додатку). Згідно з , цей ключ використовується внутрішньо GCP для надання доступу до кінцевих точок метаданих для генерації доступних OAuth токенів.
Google насправді , щоб обсяги доступу не використовувалися і щоб повністю покладатися на IAM. Веб-портал управління насправді це забезпечує, але обсяги доступу все ще можуть бути застосовані до екземплярів за допомогою програмних облікових записів служби.
Ви можете знайти список .
Як визначено terraform в , використовуючи terraform з GCP, існують різні способи надання доступу принципалу до ресурсу:
Learn & practice AWS Hacking: Learn & practice GCP Hacking:
Check the !
Join the 💬 or the or follow us on Twitter 🐦 .
Share hacking tricks by submitting PRs to the and github repos.
Група | Функція |
| Адміністрування будь-якого ресурсу, що належить організації. Призначайте цю роль обережно; адміністратори організації мають доступ до всіх ваших ресурсів Google Cloud. Альтернативно, оскільки ця функція має високі привілеї, розгляньте можливість використання індивідуальних облікових записів замість створення групи. |
| Створення мереж, підмереж, правил брандмауера та мережевих пристроїв, таких як Cloud Router, Cloud VPN та балансувальники навантаження в хмарі. |
| Налаштування рахунків для виставлення рахунків та моніторинг їх використання. |
| Проектування, кодування та тестування додатків. |
|
| Створення або управління кінцевими конвеєрами, які підтримують безперервну інтеграцію та доставку, моніторинг та постачання систем. |
|
|
|
| Моніторинг витрат на проекти. Типові учасники є частиною фінансової команди. |
| Перегляд інформації про ресурси в організації Google Cloud. |
| Перегляд безпеки хмари. |
| Перегляд конфігурацій мережі. |
| Перегляд журналів аудиту. |
| Адміністрування Центру команд безпеки. |
| Управління секретами в Secret Manager. |
Встановлення та управління політиками безпеки для всієї організації, включаючи управління доступом та . Дивіться для отримання додаткової інформації про планування вашої інфраструктури безпеки Google Cloud.
