Google PCA: Организационный дизайн, IAM и управление облаком — Руководство по подготовке

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Обзор

Проектирование организации, IAM и управление создают основу, на которой работают все архитектуры Google Cloud. Качественное проектирование обеспечивает четкие административные границы, минимизирует радиус поражения, реализует принцип наименьших привилегий, контролирует затраты и масштабируется операционно для множества команд и сред. Управление должно делать акцент на направляющих, а не на барьерах: автоматизируйте безопасные, измеримые и обратимые настройки по умолчанию, делегируя при этом повседневный контроль командам, наиболее близким к рабочей нагрузке.

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

Ресурсы Google Cloud образуют строгое дерево: Организация → Папки → Проекты → Ресурсы (например, экземпляры Compute Engine, бакеты). Политики IAM и ограничения Organization Policy наследуются вниз по дереву.

Ключевые принципы проектирования:

Используйте единую Организацию для централизации управления. Создайте Папки верхнего уровня для основных административных границ (например, бизнес-подразделения, регионы или среды с регулированием и без).
Внутри каждой границы создайте Папки для сред (prod, nonprod), чтобы применять дифференцированные политики. Сохраняйте проекты ориентированными на конкретную рабочую нагрузку и по возможности эфемерными, чтобы уменьшить радиус поражения и упростить возмещение затрат.
Наследование: разрешающие правила накапливаются (объединение разрешающих привязок от предков и узла). Запрещающие политики IAM (IAM Deny), если они используются, имеют приоритет и могут блокировать доступ, даже если существует разрешение. Избегайте назначения широких ролей на высоких уровнях иерархии; радиус поражения велик, и последствия трудно устранить.

Источники идентификации:

Cloud Identity — это плоскость идентификации сотрудников. Интегрируйте ее с вашим корпоративным IdP (SAML/OIDC) для централизации аутентификации и жизненного цикла (прием, перемещение и увольнение сотрудников). При необходимости используйте Google Cloud Directory Sync для синхронизации атрибутов и групп.
Группы являются основными субъектами IAM. Доступ на основе групп обеспечивает масштабируемые изменения и аудируемое владение. Используйте шаблон «группа групп» (например, net-admins, sec-admins, app-team-A) и ограничивайте круг лиц, которые могут управлять членством в группах.
Сервисные аккаунты представляют рабочие нагрузки. Предпочитайте имперсонацию сервисного аккаунта с использованием краткосрочных учетных данных вместо хранимых ключей. Избегайте использования управляемых пользователем ключей сервисных аккаунтов; рассматривайте их как исключение, требующее строгих согласований и ротации.
Шаблоны идентификации рабочих нагрузок:
- GKE Workload Identity связывает сервисные аккаунты Kubernetes с сервисными аккаунтами Google, что устраняет необходимость в учетных данных на уровне узла.
- Workload Identity Federation позволяет внешним идентификаторам (из локальной среды, других облаков, GitHub Actions) получать краткосрочный доступ к Google без ключей. Используйте ограничение области действия пула/провайдера и условия на основе атрибутов для ограничения доступа.

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

Предоставление примитивных ролей (Owner/Editor/Viewer) на уровне Папки или Организации ведет к повсеместному избытку привилегий. Используйте их только в проектах для экстренного доступа с жестко ограниченной областью действия.
Разрастание групп с неясным владением подрывает принцип наименьших привилегий. Внедрите правила именования, теги назначения и метаданные о владельцах для групп.
Бесхозные сервисные аккаунты и устаревшие привязки накапливают риски. Планируйте регулярные проверки доступа и используйте IAM Recommender для сокращения неиспользуемых разрешений.

Модели IAM, роли и операции доступа

Роли и привязки:

Предопределенные роли созданы для конкретных сервисов и должны быть выбором по умолчанию.
Пользовательские роли заполняют пробелы, когда предопределенные роли слишком широки. Создавайте их из минимального набора разрешений, которые были определены как необходимые; версионируйте и тестируйте их.
Базовые роли (Viewer/Editor/Owner) являются устаревшими и слишком широкими. Избегайте их использования на уровне Организации и Папок. Не используйте роль Owner для повседневных операций; зарезервируйте ее для экстренного доступа к платформе с сильными компенсирующими мерами контроля.
Условные привязки ролей (IAM Conditions) ограничивают, когда и где применяется привязка, используя атрибуты, такие как resource.name, resource.matchTag, request.time или request.auth.audiences. Используйте условия для доступа с ограничением по времени, доступа к prod с привязкой к тегам или действий, ограниченных по местоположению.

Принцип наименьших привилегий и повышение привилегий:

Разделяйте обязанности по «чтению», «эксплуатации» и «администрированию». Например, команды, отвечающие за сеть, безопасность и приложения, получают разные роли в разных областях видимости.
Используйте JIT-повышение привилегий с помощью рабочих процессов Access Approval или автоматизации на основе заявок для привязки ролей с ограниченным сроком действия через условия.

Запрещающие политики и связанные с ними риски:

IAM Deny может централизованно блокировать рискованные разрешения (например, resourcemanager.projects.delete). Запрет имеет приоритет над разрешением и применяется ко всему поддереву. Тщательно проверяйте; неверно настроенные запреты могут заблокировать автоматизацию или нарушить развертывания.

Аудит и проверки:

Включите журналы Admin Activity на уровне Организации; по умолчанию они хранятся 400 дней. Для чувствительных сервисов включите журналы Data Access и направляйте их в BigQuery для долгосрочного хранения и аудита.
Внедрите периодические проверки доступа: перечисляйте привязки с помощью Cloud Asset Inventory, сверяйте их с реестрами владения, удаляйте неиспользуемые роли, предложенные IAM Recommender, и проверяйте срок действия исключений.

Полезный пример (привязка с ограничением по времени и области действия тега):

undefined

Финансовое управление и ограничительные барьеры политик организации

Архитектура биллинга:

Централизуйте один или несколько платежных аккаунтов под управлением финансового отдела. Используйте несколько платежных аккаунтов только в случае юридической или операционной необходимости (например, для отдельных юридических лиц или моделей реселлеров).
Привязывайте проекты к платежным аккаунтам с помощью автоматизации; не допускайте ручной привязки вне утвержденных рабочих процессов.

Перераспределение затрат и прозрачность расходов:

Последовательно используйте метки (labels) и теги для распределения затрат (cost allocation tags). Метки — это метаданные произвольного формата для фильтрации и отчетности; теги иерархичны и могут использоваться в условиях и политиках IAM. Включите распределение затрат для выбранных тегов, чтобы они появились в экспорте биллинга.
Экспортируйте данные биллинга в BigQuery для аналитики; создавайте дашборды по владельцам, центрам затрат и средам. Требуйте, чтобы у каждого проекта был ответственный владелец и бюджет.

Бюджеты и обнаружение аномалий:

Создавайте бюджеты с оповещениями на уровне папок (Folder) и проектов. Добавляйте программные реакции (например, уведомление дежурного, создание тикетов или отключение увеличения новых квот), чтобы сдерживать неконтролируемый рост расходов.
Используйте квоты и обязательства (CUD) в соответствии с ожидаемым использованием; отслеживайте утилизацию.

Ограничения политик организации (безопасность по умолчанию):

Применяйте ограничительные барьеры на уровне организации или папки и ослабляйте их только при наличии обоснования. Распространенные ограничения:
- constraints/iam.disableServiceAccountKeyCreation = true
- constraints/compute.requireOsLogin = true
- constraints/compute.trustedImageProjects для ограничения образов ВМ
- constraints/sql.restrictPublicIp = true
- constraints/storage.uniformBucketLevelAccess = true
- constraints/compute.disableSerialPortAccess = true
Используйте VPC Service Controls для снижения риска эксфильтрации данных для поддерживаемых сервисов в пределах чувствительных периметров.

Обработка исключений из политик:

Исключения должны быть запрашиваемыми, утвержденными, ограниченными по времени и аудируемыми. Предпочтительно использовать условия IAM (IAM Conditions) для ограничения области действия исключений по тегу/времени. Периодически сверяйте исключения и обеспечивайте их автоматическое истечение с помощью конвейеров policy-as-code.

Пример политики организации (YAML) для отключения ключей сервисных аккаунтов:

name: organizations/1234567890/policies/iam.disableServiceAccountKeyCreation spec: rules:
- enforce: true Затем примените: gcloud org-policies set-policy policy.yaml

Все домены · Вычислительные ресурсы →

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