Google ACE: Иерархия ресурсов, IAM и управление биллингом — Руководство по подготовке

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Часть Google Associate Cloud Engineer — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Google, или пройдите тесты на время на ExamRoll.io.

Обзор

Иерархия ресурсов, управление идентификацией и доступом (IAM) и администрирование биллинга составляют плоскость управления (control plane) в операциях Google Cloud. Отказоустойчивая архитектура начинается с четкой иерархии (организация, папки, проекты) для определения области действия политик и ответственности; применяет принцип наименьших привилегий в IAM с администрированием через группы и использованием короткоживущих учетных данных для рабочих нагрузок; использует бюджеты, экспорт данных и метки для атрибуции затрат; и обеспечивает управление с помощью политик организации и всестороннего аудиторского логирования. Операционное совершенство достигается за счет стандартизации на основе наследования, централизации биллинга и логов, а также использования имперсонации сервисных аккаунтов вместо долгоживущих ключей. В этом разделе подробно рассматриваются основные конструкции, их предполагаемое использование и распространенные ошибки, которых следует избегать.

Иерархия ресурсов и модель идентификации

• Иерархия ресурсов

  • Организация: Корневой узел, создается с помощью Cloud Identity или Google Workspace. Владеет глобальными политиками (IAM, политики организации, теги).
  • Папки: Необязательная группировка для отделов, сред (например, dev, prod) или приложений. Полезны для делегирования администрирования и определения области действия политик.
  • Проекты: Административная граница для ресурсов, API, квот, IAM и привязки к биллингу. Большинство ресурсов Google Cloud являются дочерними по отношению к проектам.
  • Наследование: Политики IAM и политики организации наследуются сверху вниз. Запреты и ограничения на более высоких уровнях имеют приоритет. Планируйте размещение (организация → папки → проекты) так, чтобы минимизировать исключения и потребность в экстренном доступе (break-glass).

• Субъекты (Principals)

  • Аккаунты Google (пользователи), группы Google, сервисные аккаунты и внешние удостоверения через Workload Identity Federation.
  • Группы Google должны быть основной целью привязки для доступа людей, чтобы упростить управление жизненным циклом и проверки.
  • Сервисные аккаунты представляют приложения или сервисы; предпочитайте workload identity вместо ключей.

• Workload identities (Удостоверения рабочих нагрузок)

  • В Google Cloud: GCE/GAE/Cloud Run/GKE используют сервер метаданных для выпуска короткоживущих токенов для привязанного сервисного аккаунта.
  • Вне Google Cloud: Workload Identity Federation сопоставляет внешние удостоверения (OIDC/SAML/AWS) с сервисными аккаунтами без использования статических ключей.

• Компромиссы в проектировании и типичные ошибки

  • Беспорядочное разрастание проектов без структуры папок приводит к дублированию и рассогласованию политик.
  • Предоставление ролей напрямую пользователям увеличивает ручную работу; предпочитайте привязки на основе групп.
  • Использование сервисного аккаунта по умолчанию для Compute Engine с широкими разрешениями повышает риски; создавайте сервисные аккаунты с минимальными привилегиями для каждой рабочей нагрузки.
  • Размещение проекта в неправильной папке приводит к наследованию неверных политик; используйте теги или перемещайте проекты осторожно, с контролем изменений.

Роли IAM и проектирование политик

• Типы ролей

  • Базовые роли (Viewer, Editor, Owner): Широкие, устаревшие. Избегайте их использования, за исключением строго контролируемого экстренного доступа (break-glass).
  • Предопределенные роли: Специально подобраны для каждого сервиса; предпочтительны для большинства сценариев использования.
  • Кастомные роли: Агрегация разрешений на уровне организации или проекта для особых нужд.
  • Условные роли: Условия IAM (CEL) добавляют контекст, такой как имя ресурса, папка, теги или время; используйте их для ограничения мощных ролей.

• Принципы политик

  • Принцип наименьших привилегий: Предоставляйте только минимально необходимую роль в самой узкой области действия (ресурс/проект/папка).
  • Разделение обязанностей: Разделяйте обязанности (например, администратор сети, администратор безопасности, администратор биллинга). Не связывайте действия по развертыванию и утверждению в одном субъекте (principal).
  • Осознание наследования: Привязка на уровне организации/папки влияет на всех потомков; документируйте предполагаемую зону влияния (blast radius) перед применением.

• Политики запрета (Deny policies)

  • Политики запрета (IAM Deny) явно блокируют разрешения, даже если они предоставлены в другом месте; используйте их для создания защитных барьеров (guardrails) (например, запретить iam.serviceAccountKeys.create).
  • Запрет имеет приоритет; обеспечьте документированный экстренный доступ (break-glass) с ограниченными по времени процессами исключений.

• Примеры

  • Копирование кастомной роли из dev в prod:

undefined

• Предоставление группе прав администратора SSH через OS Login:

undefined

• Типичные ошибки
  • Роль Editor, предоставленная на уровне организации или папки, непреднамеренно распространяется на все проекты.
  • Условные роли со слишком строгими условиями могут незаметно нарушить работу автоматизации; протестируйте с помощью Policy Troubleshooter перед внедрением.
  • Кастомные роли могут отставать от появления новых разрешений; периодически пересматривайте их.

Администрирование биллинга и затрат

• Платежные аккаунты и привязка

  • Проект должен быть привязан ровно к одному платежному аккаунту для использования платных сервисов.
  • Роли: Billing Account Administrator управляет аккаунтом и способами оплаты; Billing Account User привязывает проекты; Project Billing Manager управляет привязкой проекта к биллингу.
  • Централизуйте биллинг в корпоративном платежном аккаунте; мигрируйте проекты, обновляя их привязку к биллингу.

• Бюджеты, оповещения и атрибуция

  • Бюджеты генерируют оповещения, а не ограничивают расходы. Используйте программное реагирование с помощью Pub/Sub и Cloud Functions/Cloud Run, если требуется принудительное ограничение.
  • Экспортируйте данные биллинга в BigQuery для ежедневной/ежемесячной аналитики и прогнозирования затрат; комбинируйте с метками и тегами ресурсов для атрибуции.
  • Метки и теги: Стандартизируйте ключи (например, cost_center, env, app). Отсутствие меток снижает точность атрибуции.

• Анализ затрат

  • Используйте экспорт в BigQuery для расчета скользящих прогнозов по SKU/сервису с помощью SQL. Объединяйте с метаданными ресурсов (например, метками GCE) для гранулярной отчетности.
  • Для анализа по нескольким проектам агрегируйте данные из экспортов всех проектов или экспортируйте их в один центральный набор данных.

• Распространенные ошибки

  • Бюджеты не настроены для новых проектов; создайте политику для автоматического создания бюджетов при создании проекта.
  • Отсутствие экспорта в BigQuery означает ограниченное представление об исторических данных; включите его как можно раньше, чтобы накопить историю.
  • Использование личных кредитных карт в проектах фрагментирует ответственность; консолидируйте все под корпоративным платежным аккаунтом с соответствующими IAM и платежными профилями.
  • Аномалии затрат в проектах с общими сервисами требуют использования тегов и политики перераспределения затрат (cross-charging).

Безопасная аутентификация и шаблоны доступа для рабочих нагрузок

• Имперсонация сервисного аккаунта
  • Предпочитайте имперсонацию использованию ключей. Предоставьте роль roles/iam.serviceAccountTokenCreator вызывающей стороне (identity); она получит короткоживущие токены для действий от имени сервисного аккаунта.
  • Пример:

undefined

• Ключи и их ротация

  • Избегайте ключей, управляемых пользователем. Если они необходимы, храните их в Secret Manager, ротируйте не реже чем каждые 90 дней, отслеживайте использование и ограничивайте доступ с помощью VPC Service Controls и CMEK.
  • Применяйте ограничения для блокировки создания ключей: constraints/iam.disableServiceAccountKeyCreation = true

• OS Login и SSH

  • Используйте OS Login с ролями IAM, назначенными группам (compute.osLogin, compute.osAdminLogin). Каждый пользователь загружает свой публичный SSH-ключ в свой аккаунт Google для атрибуцируемого доступа. Аудит осуществляется через журналы Admin Activity и Data Access.
  • Избегайте встраивания общих SSH-ключей в образы.

• Workload Identity Federation

  • Для локальных сред или других облаков настройте федерацию удостоверений, чтобы предоставлять доступ к Google Cloud без создания ключей, снижая риск утечки данных.

• Сценарии сбоев и способы их устранения

  • Хранение ключей в репозиториях или переменных CI/CD приводит к компрометации; переключитесь на имперсонацию или федерацию.
  • Сервисные аккаунты по умолчанию с широкими ролями рискованны; ограничьте их с помощью constraints/iam.allowedPolicyMemberDomains и удалите примитивные роли.
  • Отсутствие scope на устаревших инстансах GCE может блокировать доступ к API; предпочитайте использовать IAM для каждого API вместе с учетными данными приложения по умолчанию (default application credentials).

Управление, политики организации, аудит и устранение неполадок

• Политики организации и ограничения

  • Применяйте защитные барьеры (guardrails) с помощью ограничений: запрет внешних IP-адресов для ВМ, ограничение регионов, запрет создания ключей, ограничение разрешенных сервисов, требование единообразного доступа на уровне бакетов, ограничение совместного использования доменов.
  • Применяйте к иерархии ресурсов и уточняйте с помощью тегов для исключений, специфичных для окружения.

• Cloud Identity и жизненный цикл

  • Cloud Identity предоставляет каталог пользователей, SSO и административные роли. Делегируйте полномочия узко (например, Group Admin, User Management Admin) и автоматизируйте рабочие процессы joiner-mover-leaver для обновления членства в группах и доступа.
  • Используйте Access Approvals и Access Transparency для чувствительных сред.

• Аудит логов

  • Логи Admin Activity и System Event всегда включены; логи Data Access необходимо включать явно, что может повлечь за собой расходы.
  • Централизуйте логи, направляя агрегированные приемники (sinks) из папок/организации в проект безопасности. Защитите их с помощью CMEK и ограниченного доступа.
  • Отслеживайте логи Policy Denied для выявления конфликтов политик организации.

• Инструменты для устранения неполадок в нескольких проектах

  • Policy Troubleshooter: Диагностирует, почему доступ разрешен или запрещен, учитывая действующие политики IAM и запреты.
  • Cloud Asset Inventory: Запрашивает привязки IAM и историю политик в масштабе организации/папок/проектов. Пример:

undefined

• Logs Explorer: Фильтрует по участнику (principal), методу и ресурсу для отслеживания действий между проектами.
• Конфигурации gcloud для переключения контекста оператора:

undefined

• Распространенные сценарии сбоев: конфликтующие политики организации, блокирующие развертывания; отсутствие логов Data Access, затрудняющее расследования; и IAM, предоставленный на неверном уровне иерархии. Создайте регламенты (runbooks) и предварительные проверки изменений, чтобы сократить среднее время восстановления после инцидента (MTTR).

Практический сценарий

Компания Aurelia Retail объединяет несколько команд и проектов после поглощения. Им необходимо централизовать биллинг, обеспечить единообразное администрирование IAM и SSH для сотен виртуальных машин Compute Engine, а также внедрить управление с минимальными нарушениями в работе.

1. Создайте корпоративный платежный аккаунт и привяжите проекты

• Обоснование: Единый платежный аккаунт централизует способы оплаты, кредиты и бюджеты. Предоставьте роль Billing Account User группе миграции проектов и Project Billing Manager руководителям команд, чтобы они могли перепривязывать проекты без избыточных привилегий.
• Действие: В консоли создайте платежный аккаунт. Для каждого проекта обновите его привязку к биллингу. Немедленно включите экспорт данных биллинга в BigQuery в центральном проекте для аналитики.

2. Стандартизируйте иерархию ресурсов с помощью папок и тегов

• Обоснование: Размещение проектов в папках по средам (prod, nonprod) позволяет наследовать защитные барьеры и настраивать целевые исключения. Теги обеспечивают гранулярное применение политик организации без дублирования деревьев папок.
• Действие: Создайте папки для prod и nonprod; переместите проекты соответствующим образом. Определите теги env=prod|nonprod и идентификаторы приложений.

3. Внедрите IAM на основе групп с принципом наименьших привилегий и разделением обязанностей

• Обоснование: Группы упрощают управление жизненным циклом и аудит. Разделение ролей между командами развертывания, безопасности и сетевыми администраторами уменьшает радиус поражения (blast radius).
• Действие: Создайте группы Google для app-operators, net-admins, sec-admins и billing-managers. Привяжите предопределенные роли на уровне папок/проектов по мере необходимости; избегайте базовых ролей.

4. Внедрите администрирование SSH на основе OS Login

• Обоснование: Индивидуальные SSH-ключи, привязанные к учетным записям пользователей, обеспечивают атрибутируемый и отзываемый доступ. Роли OS Login управляют учетными записями Linux через IAM, устраняя необходимость в общих ключах.
• Действие: В каждом проекте включите метаданные OS Login. Предоставьте роль compute.osAdminLogin группе ops-admins. Пример:

undefined

5. Замените ключи сервисных аккаунтов на имперсонацию

• Обоснование: Краткосрочные учетные данные снижают риск утечки ключей и упрощают их ротацию. Аудит-логи фиксируют, кто и какой сервисный аккаунт имперсонировал, улучшая отслеживаемость.
• Действие: Предоставьте роль roles/iam.serviceAccountTokenCreator идентификаторам CI/CD-раннеров для сервисных аккаунтов рабочих нагрузок. Удалите ключи, управляемые пользователями, и примените политику организации, блокирующую создание новых ключей.

6. Примените политики организации для создания защитных барьеров

• Обоснование: Ограничения предотвращают рискованные конфигурации во всех проектах, допуская исключения с помощью тегов там, где это оправдано.
• Действие: Примените ограничения, чтобы запретить внешние IP-адреса в prod-среде, ограничить использование регионов до утвержденных, и отключить создание ключей сервисных аккаунтов. Используйте теги, чтобы разрешить исключения для конкретных проектов с документированными утверждениями.

7. Настройте управление затратами

• Обоснование: Бюджеты предупреждают владельцев до перерасхода средств; экспорт в BigQuery позволяет атрибутировать затраты и прогнозировать их. Метки и теги связывают расходы на ресурсы с центрами затрат.
• Действие: Создайте бюджеты для каждой папки и крупного приложения с уведомлениями через Pub/Sub. Обеспечьте соблюдение политик меток через шаблоны развертывания и проверку политик в CI.

8. Централизуйте аудит и ускорьте устранение неполадок

• Обоснование: Агрегированные логи и инвентаризация ресурсов в масштабе организации ускоряют расследования и подготовку отчетов о соответствии требованиям.
• Действие: Создайте агрегированные приемники (sinks) в проект безопасности с бакетами, защищенными CMEK. Включите логи Data Access для критически важных сервисов (Cloud Storage, BigQuery). Используйте Cloud Asset Inventory для регулярного сканирования привязок IAM. Обучите операторов использовать Policy Troubleshooter при сбоях доступа и Logs Explorer для отслеживания Admin Activity/Data Access.

9. Операционализируйте изменения с помощью предварительных просмотров и поэтапного развертывания

• Обоснование: Проверка эффекта от изменений IAM и политик перед их применением сокращает количество сбоев.
• Действие: Сначала протестируйте IAM и политики организации в nonprod-среде. Используйте пробные запуски (dry-runs) и симуляцию политик, где это возможно. Для автоматизации развертывания внедрите канареечные релизы и планы отката.

Этот подход обеспечивает централизованный биллинг и контроль затрат, атрибутируемое администрирование SSH через OS Login, IAM с принципом наименьших привилегий с использованием имперсонации, надежные превентивные меры контроля через политики организации, а также мощные средства аудита и устранения неполадок в новой среде с множеством проектов.

Все домены · Compute Engine и операции с виртуальными машинами →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Google →