GCP - Basic Information
Ієрархія ресурсів
Google Cloud використовує Ієрархію ресурсів, яка концептуально схожа на традиційну файлову систему. Це забезпечує логічний батьківський/дочірній робочий процес з конкретними точками прикріплення для політик та дозволів.
На високому рівні це виглядає так:
Віртуальна машина (називається Екземпляром обчислення) є ресурсом. Ресурс знаходиться в проекті, ймовірно, поруч з іншими Екземплярами обчислення, сховищами даних тощо.
Міграція проектів
Можливо перенести проект без будь-якої організації в організацію з дозволами roles/resourcemanager.projectCreator та roles/resourcemanager.projectMover. Якщо проект знаходиться в іншій організації, потрібно звернутися до підтримки GCP, щоб виділити їх з організації спочатку. Для отримання додаткової інформації перегляньте це.
Політики організації
Дозволяють централізувати контроль над хмарними ресурсами вашої організації:
Централізований контроль для налаштування обмежень щодо використання ресурсів вашої організації.
Визначте та встановіть обмеження для вашої команди розробників, щоб вони дотримувалися меж відповідності.
Допоможіть власникам проектів та їх командам швидко рухатися без страху порушення відповідності.
Ці політики можуть бути створені для впливу на всю організацію, папки або проекти. Потомки цільового вузла ієрархії ресурсів успадковують політику організації.
Для визначення політики організації ви обираєте обмеження, яке є певним типом обмеження проти служби Google Cloud або групи служб Google Cloud. Ви налаштовуєте це обмеження з ваших бажаних обмежень.
Загальні випадки використання
Обмеження обміну ресурсами на основі домену.
Обмеження використання службових облікових записів Ідентифікації та управління доступом.
Обмеження фізичного розташування новостворених ресурсів.
Вимкнення створення службових облікових записів
Є багато інших обмежень, які дають вам дрібнозернистий контроль над ресурсами вашої організації. Для додаткової інформації перегляньте список всіх обмежень сервісу політики організації.
Стандартні політики організації
Ролі IAM
Це схоже на політики IAM в AWS, оскільки кожна роль містить набір дозволів.
Однак, на відміну від AWS, немає централізованого сховища ролей. Замість цього ресурси надають ролі X доступ до принципалів Y, ідиний спосіб дізнатися, хто має доступ до ресурсу - використовувати метод get-iam-policy над цим ресурсом.
Це може бути проблемою, оскільки це означає, що єдиний спосіб дізнатися, які дозволи має принципал, - це запитати кожен ресурс, кому він надає дозвіл, і користувач може не мати дозволу отримувати дозволи від усіх ресурсів.
Є три типи ролей в IAM:
Базові/примітивні ролі, які включають ролі Власник, Редактор та Переглядач, які існували до введення IAM.
Попередньо визначені ролі, які надають дрібнозернистий доступ до конкретної служби та керуються Google Cloud. Існує багато попередньо визначених ролей, ви можете переглянути їх всі разом з привілеями, які вони мають тут.
Користувацькі ролі, які надають дрібнозернистий доступ відповідно до списку дозволів, вказаних користувачем.
У GCP існує тисячі дозволів. Щоб перевірити, чи має роль дозволи, ви можете знайти дозвіл тут та подивитися, які ролі його мають.
Ви також можете шукати тут попередньо визначені ролі , запропоновані кожним продуктом. Зверніть увагу, що деякі ролі не можуть бути прикріплені до користув
Користувачі
У консолі GCP немає управління Користувачами або Групами, це робиться в Google Workspace. Однак ви можете синхронізувати інший постачальник ідентичності в Google Workspace.
Ви можете отримати доступ до користувачів та груп Workspaces на https://admin.google.com.
Багатофакторна аутентифікація (MFA) може бути примусовою для користувачів Workspaces, однак зловмисник може використовувати токен для доступу до GCP через cli, який не буде захищений MFA (він буде захищений MFA лише тоді, коли користувач увійде для його генерації: gcloud auth login).
Групи
При створенні організації рекомендується створити кілька груп. Якщо ви керуєте будь-якою з них, ви можете скомпрометувати всю або важливу частину організації:
Група | Функція |
| Управління будь-яким ресурсом, який належить організації. Надавайте цю роль обережно; адміністратори організації мають доступ до всіх ваших ресурсів Google Cloud. Альтернативно, оскільки ця функція має високі привілеї, розгляньте можливість використання окремих облікових записів замість створення групи. |
| Створення мереж, підмереж, правил брандмауерів та мережевих пристроїв, таких як Cloud Router, Cloud VPN та хмарні балансувальники. |
| Налаштування облікових записів та моніторинг їх використання. |
| Проектування, кодування та тестування додатків. |
| Встановлення та управління політиками безпеки для всієї організації, включаючи управління доступом та обмеженнями політики організації. Див. посібник з основ безпеки Google Cloud для отримання додаткової інформації про планування інфраструктури безпеки Google Cloud. |
| Створення або управління кінцевими конвеєрами, які підтримують безперервну інтеграцію та доставку, моніторинг та надання систем. |
| |
| |
| |
| Моніторинг витрат на проекти. Типові члени - частина фінансової команди. |
| Перегляд інформації про ресурси в організації Google Cloud. |
| Перегляд безпеки хмари. |
| Перегляд конфігурацій мережі. |
| Перегляд журналів аудиту. |
| Адміністрування Центру керування безпекою. |
| Управління секретами в Менеджері секретів. |
Політика паролів за замовчуванням
Застосовувати складні паролі
Від 8 до 100 символів
Неможливість повторного використання
Немає терміну дії
Якщо люди отримують доступ до Workspace через постачальника сторонніх послуг, ці вимоги не застосовуються.
Службові облікові записи
Це принципали, які ресурси можуть мати прикріпленими та отримувати доступ для взаємодії з GCP. Наприклад, можливо отримати аутентичний токен Службового облікового запису, прикріпленого до ВМ, у метаданих.
Можливі конфлікти при використанні IAM та обмежень доступу одночасно. Наприклад, вашому службовому обліковому запису може бути надана роль IAM compute.instanceAdmin, але екземпляр, який ви порушили, має обмеження області https://www.googleapis.com/auth/compute.readonly. Це може перешкодити внесенню змін за допомогою токена OAuth, який автоматично призначається вашому екземпляру.
Це схоже на ролі IAM в AWS. Але, на відміну від AWS, будь-який службовий обліковий запис може бути прикріплений до будь-якої служби (не потрібно дозволяти це через політику).
Декілька службових облікових записів, які ви знайдете, фактично автоматично генеруються GCP при початку використання служби, наприклад:
Проте також можливо створювати та прикріплювати до ресурсів власні службові облікові записи, які будуть виглядати наступним чином:
Області доступу
Області доступу додаються до створених токенів OAuth для доступу до кінцевих точок API GCP. Вони обмежують дозволи токену OAuth. Це означає, що якщо токен належить Власнику ресурсу, але не має в області токену доступу до цього ресурсу, токен не може бути використаний для (зло)вживання цих привілеїв.
Google фактично рекомендує не використовувати області доступу і повністю покладатися на IAM. Веб-портал управління фактично це накладає, але області доступу все ще можуть бути застосовані до екземплярів за допомогою власних облікових записів служб програмно.
Ви можете побачити, які області призначені, запитавши:
```bash curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token='
{ "issued_to": "223044615559.apps.googleusercontent.com", "audience": "223044615559.apps.googleusercontent.com", "user_id": "139746512919298469201", "scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth", "expires_in": 2253, "email": "username@testing.com", "verified_email": true, "access_type": "offline" }
Політики IAM, Прив'язки та Учасники Terraform
Як визначено в terraform на https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam, використовуючи terraform з GCP є різні способи надання основному доступу до ресурсу:
Учасники: Ви встановлюєте основних як учасників ролей без обмежень щодо ролі або основних. Ви можете встановити користувача як учасника ролі, а потім встановити групу як учасника тієї ж ролі, а також встановити цих основних (користувача та групу) як учасників інших ролей.
Прив'язки: Декілька основних можуть бути прив'язані до ролі. Ці основні все ще можуть бути прив'язані або бути учасниками інших ролей. Однак, якщо основний, який не прив'язаний до ролі, встановлений як учасник прив'язаної ролі, то наступного разу, коли прив'язка застосовується, учасництво зникне.
Політики: Політика є авторитетною, вона вказує ролі та основних, і після цього ці основні не можуть мати більше ролей, а ці ролі не можуть мати більше основних, якщо тільки політика не буде змінена (навіть в інших політиках, прив'язках або учасництвах). Отже, коли роль або основний вказано в політиці, всі його привілеї обмежуються цією політикою. Очевидно, це можна обійти у випадку, якщо основний отримує можливість змінювати політику або дозволи на підвищення привілеїв (наприклад, створити нового основного та прив'язати йому нову роль).
Посилання
Last updated
