Google PCD: Идентификация, аутентификация и безопасность приложений — Руководство по подготовке

By Laurynas Brazys · 4 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Обзор

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

Идентификационные данные, аутентификация и контроль доступа

Роли IAM и сервисные аккаунты
- Используйте иерархию ресурсов (организация > папка > проект) и предопределенные роли вместо примитивных. Пользовательские роли следует создавать только тогда, когда предопределенные роли слишком широки.
- Назначайте сервисные аккаунты (СА) рабочим нагрузкам. Не используйте повторно стандартные СА Compute Engine или App Engine. Один СА на границу рабочей нагрузки упрощает применение принципа минимальных привилегий и ротацию доверия.
- Применяйте принцип минимальных привилегий, предоставляя минимальный набор разрешений в самой узкой области видимости ресурса.
- Имперсонация: предпочитайте краткосрочные учетные данные через Service Account Token Creator, чтобы позволить людям, CI/CD или другим сервисам получать эфемерный доступ без сохранения ключей:
  - Предоставьте роль roles/iam.serviceAccountTokenCreator для целевого СА вызывающему субъекту.
  - Пример:

undefined

Workload Identity
- GKE: используйте Workload Identity для привязки сервисных аккаунтов Kubernetes к сервисным аккаунтам Google; токены проецируются и обмениваются автоматически — без JSON-ключей.
- Внешние рабочие нагрузки: используйте Workload Identity Federation для обмена учетных данных OIDC/SAML (например, из GitHub Actions или из локальной среды) на токены доступа Google без хранения долгосрочных ключей.
Режимы отказа и компромиссы
- Слишком широкие роли или предоставление прав в широком скоупе приводят к горизонтальному перемещению. Отсутствие привилегий Token Creator блокирует процессы имперсонации. Файлы с JSON-ключами увеличивают радиус поражения при взломе.
Аутентификация пользователей с помощью OAuth 2.0, OpenID Connect и Google Identity
- Для аутентификации конечных пользователей используйте OIDC с Google в качестве поставщика удостоверений (IdP) или с корпоративным IdP; проверяйте ID-токены на стороне сервера. Для доступа к API используйте токены доступа OAuth 2.0 с соответствующими областями действия (scopes).
- Валидация токенов: проверяйте iss, aud, exp, iat и подпись, используя JWKs поставщика удостоверений; кешируйте JWKs и обеспечивайте ротацию ключей.
- Для бекендов мобильных приложений/SPA отдавайте предпочтение потоку Authorization Code с PKCE. Избегайте неявных потоков (implicit flows).
- Для межсервисного взаимодействия используйте поток OAuth 2.0 Service Account JWT или mTLS; избегайте статических API-ключей.
- Пример (имперсонация токена с помощью gcloud):

undefined

Режимы отказа
- Отсутствие валидации aud/iss допускает атаки типа «путаница токенов» (token confusion). Принятие просроченных токенов или отказ от ротации JWKs повышает риск. Использование refresh-токенов в мобильных приложениях раскрывает долгосрочные учетные данные.
Identity-Aware Proxy (IAP) для доступа через браузер
- Используйте IAP в качестве фронтенда для HTTP-приложений на Cloud Run, GKE или Compute Engine без встраивания логики аутентификации. Для доступа требуйте роль «IAP-secured Web App User».
- Приложения получают подписанный заголовок (x-goog-iap-jwt-assertion). Проверяйте JWT, чтобы доверять идентификатору и email пользователя; не полагайтесь на заголовки X-Forwarded-* для аутентификации.
- Распространенные ошибки: обходные пути, не проходящие через IAP, неправильно настроенный файрвол бекенда или доверие заголовкам с IP-адресом клиента без проверки целостности Cloud Load Balancing.

Секреты, ключи и шифрование

Secret Manager
- Храните API-ключи, пароли баз данных и секреты веб-хуков в Secret Manager. Полагайтесь на версионирование, средства контроля IAM и журналы аудита.
- Паттерны доступа
  - Получать при запуске и кешировать в памяти; обновлять по сигналам об изменении секрета (уведомления Pub/Sub).
  - Избегайте встраивания секретов в образы или переменные окружения. Если переменные окружения используются, убедитесь, что они никогда не попадают в логи или дампы сбоев.
- Ротация
  - Автоматизируйте с помощью Cloud Scheduler + Cloud Functions/Run, чтобы создавать новые версии, обновлять зависимые компоненты и объявлять старые версии устаревшими.
  - Пример:

undefined

Режимы отказа
- Чрезмерные вызовы Secret Manager на каждый запрос увеличивают задержку и создают риск исчерпания квот. Отсутствие роли roles/secretAccessor приводит к ошибкам 403 во время выполнения.
Cloud KMS и шифрование на уровне приложения
- Используйте конвертное шифрование (envelope encryption): локально сгенерированный ключ шифрования данных (DEK) шифрует данные; ключ, управляемый клиентом (CMEK) в Cloud KMS, шифрует DEK (этот ключ называется KEK — key encryption key).
- Регулярно ротируйте ключи; планируйте повторное шифрование. Предпочитайте подход «расшифровать старым, зашифровать новым» при записи; задания массового перешифрования неактивных данных (at-rest) более затратны.
- Включайте CMEK для сервисов (BigQuery, GCS, Pub/Sub, Cloud SQL и др.), когда это требуется для соответствия нормативным требованиям. Храните ключи KMS в том же регионе, что и данные.
- Пример CLI:
  - Шифрование:

undefined

- Расшифровка:

undefined

Используйте проверенные криптографические библиотеки (например, Tink), чтобы избежать ошибок реализации.
Режимы отказа
- Несоответствие местоположений препятствует использованию CMEK. Расшифровка с помощью KMS на каждый запрос увеличивает задержку; кешируйте DEK в памяти с учетом их ротации. Отсутствие роли roles/cloudkms.cryptoKeyEncrypterDecrypter приводит к ошибкам 403.

Авторизация, API и безопасность периметра

Авторизация в приложениях
- Проверки на основе ролей: просто, быстро, но грубо. Управление доступом на основе атрибутов (ABAC) использует атрибуты пользователя, атрибуты ресурса и контекст (время, состояние устройства) для принятия гранулярных решений.
- Централизуйте оценку политик или используйте sidecar/OPA; последовательно распространяйте утверждения (claims) об идентификации и арендаторе через микросервисы.
- Паттерны мультиарендности
  - Встраивайте tenant_id в токены аутентификации и применяйте его при каждом доступе к данным; используйте фильтрацию на уровне строк или отдельные наборы данных для каждого арендатора для строгой изоляции.
  - Рассмотрите возможность использования сервисных аккаунтов или ключей KMS для каждого арендатора, если требуется изоляция в соответствии с нормативными требованиями.
- Сценарии сбоя
  - Небезопасные прямые ссылки на объекты (IDOR) из-за отсутствия проверок арендатора. Расходящаяся логика авторизации в разных сервисах, приводящая к непоследовательному применению правил.
Безопасное проектирование API
- Валидируйте и нормализуйте все входные данные; отклоняйте слишком большие полезные нагрузки (payloads). Принудительно используйте строгие типы контента. Моделируйте угрозы для загрузки файлов; используйте подписанные URL для больших объектов.
- Ограничение частоты запросов и квоты: используйте ограничение частоты запросов в Cloud Armor или Apigee для смягчения злоупотреблений и ошибок 429. Реализуйте на клиентах экспоненциальную выдержку с джиттером (jitter).
- CORS
  - Возвращайте минимальный набор Access-Control-Allow-*; избегайте использования wildcard (*) для origins в запросах с учетными данными. Кэширование предварительных запросов (preflight) снижает задержку.
- Защита от CSRF
  - Предпочитайте API без состояния (stateless) с токенами-носителями (bearer tokens) в заголовках Authorization. Для сессий на основе cookie используйте SameSite=strict или lax, secure cookies и CSRF-токен (метод двойной отправки или синхронизатор).
- Пример (правило Cloud Armor):

undefined

Сценарии сбоя
- Наивное ограничение по IP-адресу можно обойти с помощью IPv6 или прокси. Слишком разрешающие настройки CORS приводят к утечке токенов. Отсутствие CSRF-токенов при использовании cookie позволяет осуществить захват сессии (session riding).
Сетевые средства контроля и периметр данных
- Используйте иерархические политики брандмауэра и правила брандмауэра VPC; разрешайте проверки работоспособности от Google Front Ends при использовании HTTP(S) Load Balancing.
- Пример:

undefined

Cloud Armor предоставляет WAF, защиту от ботов и ограничения по гео/IP; настраивайте правила и анализируйте ложные срабатывания.
Private Service Access обеспечивает подключение по частным IP-адресам к управляемым сервисам Google (например, Cloud SQL, Memorystore); избегайте исходящего трафика в интернет и списков разрешенных IP.
VPC Service Controls снижает риск эксфильтрации (утечки) данных путем создания периметров вокруг поддерживаемых сервисов; используйте в сочетании с Access Context Manager для получения контекста устройства/местоположения.
Сценарии сбоя
- Неправильно настроенные периметры блокируют CI/CD или нарушают вызовы между сервисами. Отсутствие выделенных диапазонов для PSA не позволяет подключить частные IP-адреса. Слишком строгие правила WAF могут вызывать инциденты, связанные с доступностью.

Безопасность цепочки поставок, логирование и реагирование

Безопасность цепочки поставок ПО
- Храните артефакты в Artifact Registry; принудительно используйте сканирование на уязвимости. Прерывайте сборки при обнаружении CVE высокого/критического уровня, с отслеживанием исключений из политики.
- Закрепляйте (пиннинг) версии зависимостей и базовых образов; избегайте тега “latest”. Генерируйте и проверяйте SBOM. Используйте Binary Authorization, чтобы требовать подписанные образы перед развертыванием.
- Подписывайте образы с помощью Cosign и записывайте их происхождение (provenance); внедряйте практики сборки, соответствующие SLSA. Используйте Workload Identity Federation для CI, чтобы избавиться от JSON-ключей.
- Сценарии сбоев
  - Незакрепленные зависимости подтягивают уязвимые релизы. Пропуск проверки происхождения (provenance) позволяет подменить образ. Хранение учетных данных реестра или ключей сервисных аккаунтов в логах CI приводит к утечке секретов.
Логирование и мониторинг безопасности
- Включите Admin Activity и Data Access Audit Logs для критически важных проектов и сервисов. Направляйте логи в выделенный проект с ограниченным доступом.
- Создайте метрики в Cloud Logging для отслеживания ошибок аутентификации, отказов в доступе и ошибок оценки политик; настройте оповещения через Cloud Monitoring.
- Пример (идея кастомной метрики-счетчика): подсчитывать частоту ошибок 401/403 на /api/* и оповещать об отклонениях от базового уровня.
- Анализ и устранение угроз
  - Используйте Security Command Center для агрегации находок; создайте сценарии реагирования (playbooks) для ключевых ситуаций (утечка ключей, брутфорс, аномальные изменения в IAM).
  - Автоматизируйте стандартные действия по устранению угроз (отзыв токенов, отключение ключей, ротация секретов, помещение сервисных аккаунтов в карантин).
- Проектирование с учетом конфиденциальности
  - Минимизируйте использование персональных данных (PII); по возможности токенизируйте их. Маскируйте конфиденциальные значения в логах; используйте Cloud DLP для их классификации. Применяйте политики с минимальным сроком хранения и регионального хранения данных.
- Сценарии сбоев
  - Отключение логов Data Access не позволяет обнаружить эксфильтрацию данных. Метки с высокой кардинальностью приводят к взрывному росту затрат. Логирование секретов создает долгосрочную уязвимость.

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

Компания Acme Retail создает мультиарендный аналитический портал на Cloud Run с фронтендом на React, API на Python и наборами данных в BigQuery для каждого арендатора. Требования включают SSO для сотрудников и клиентов, изоляцию арендаторов, управление секретами и ключами, приватный доступ к базе данных, WAF и ограничение частоты запросов, а также надежную CI/CD-инфраструктуру без долгоживущих ключей.

Подход:

Определение идентификаторов и принципа наименьших привилегий

Создайте выделенный сервисный аккаунт Google для каждого микросервиса (api-sa, ingest-sa). Предоставьте роли с наименьшими привилегиями на уровне проекта или набора данных (например, roles/bigquery.dataEditor для наборов данных арендаторов).
Обоснование: Использование отдельных SA для каждого сервиса ограничивает радиус поражения (blast radius) и упрощает ротацию; узкоспециализированные роли сокращают возможность горизонтального перемещения.

Использование Workload Identity Federation для CI/CD

Настройте GitHub Actions OIDC для имперсонации deployer-sa через роли roles/iam.workloadIdentityUser и roles/iam.serviceAccountTokenCreator. Развертывайте в Cloud Run с использованием имперсонированных токенов.
Обоснование: Исключает JSON-ключи из CI; короткоживущие учетные данные снижают риск кражи.

Фронтенд и аутентификация пользователей

Настройте IAP на HTTPS Load Balancer перед сервисами Cloud Run. Интегрируйте Google как IdP для сотрудников и IdP клиентов через федерацию. Ограничьте доступ с помощью роли “IAP-secured Web App User” для авторизованных групп.
Обоснование: Централизованная аутентификация для браузерных приложений; отсутствие логики аутентификации в сервисах; поддержка SSO.

Проверка идентификатора IAP в API

Проверяйте заголовок x-goog-iap-jwt-assertion в API; требуйте наличие утверждения (claim) tenant_id (сопоставленного из группы или кастомного утверждения).
Обоснование: Надежная гарантия подлинности от IAP; встраивание контекста арендатора в каждый запрос обеспечивает последовательную авторизацию на последующих этапах.

Реализация авторизации с учетом арендатора

Храните политики для каждого арендатора и сопоставляйте пользователей с ролями (viewer, analyst, admin). При каждом запросе проверяйте роль и условия ABAC (совпадение tenant_id, флаги функций).
Обоснование: Сочетает простоту RBAC с гибкостью ABAC; устраняет уязвимости IDOR за счет принудительного разделения по арендаторам.

Секреты и доступ к базе данных

Храните пароли от БД и токены сторонних API в Secret Manager; предоставьте роль roles/secretmanager.secretAccessor только для API SA. Получайте доступ к секретам при запуске и обновляйте их по уведомлениям о ротации через Pub/Sub.
Обоснование: Отсутствие жестко закодированных учетных данных; аудируемый доступ; своевременная ротация без перезапуска сервисов.

Шифрование данных и CMEK

Создайте связку ключей (keyring) и ключи в Cloud KMS для каждой среды. Включите CMEK для наборов данных BigQuery и бакетов Cloud Storage. Используйте конвертное шифрование (envelope encryption) для любых конфиденциальных данных, хранящихся в приложении.
Обоснование: Ключи, управляемые клиентом (CMEK), соответствуют требованиям комплаенса и обеспечивают разделение обязанностей.

Приватное подключение и периметр безопасности сервисов

Используйте Private Service Access для приватного IP-адреса Cloud SQL. Создайте периметр VPC Service Controls для проекта, в котором размещены BigQuery и GCS; добавьте политики Access Context для доступа корпоративных администраторов.
Обоснование: Устраняет публичные пути для исходящего трафика; снижает риск эксфильтрации данных.

Безопасность API, ограничение частоты запросов, CORS и CSRF

Примените политику безопасности Cloud Armor с управляемыми правилами WAF и ограничением частоты запросов к внешнему HTTP(S) LB; настройте списки разрешенных IP-адресов партнеров. Настройте строгий CORS (с явным указанием источников) для API и используйте токены Authorization bearer; cookie не используются.
Обоснование: Снижает риски из списка OWASP Top 10 и защищает от злоупотреблений; предотвращает междоменную утечку учетных данных; избегает CSRF за счет отказа от использования cookie.

Усиление безопасности цепочки поставок

Храните образы в Artifact Registry. Включите сканирование на уязвимости и прерывайте сборки при обнаружении критических CVE. Подписывайте образы с помощью Cosign и используйте Binary Authorization, чтобы требовать подписи Acme в продакшене.
Обоснование: Предотвращает запуск непроверенных артефактов; сохраняет информацию о происхождении (provenance).

Логирование, мониторинг и оповещения

Включите Audit Logs и направляйте их в централизованный проект. Создайте метрики на основе логов для всплесков ошибок 401/403, permissionDenied от BigQuery и доступа к Secret Manager. Настройте оповещения об аномалиях и проверки доступности (uptime checks) в Cloud Monitoring для публичных эндпоинтов.
Обоснование: Раннее обнаружение сбоев аутентификации и неправомерного использования; мониторинг доступности.

Сценарии реагирования на инциденты и учения по ротации

Задокументируйте шаги по отзыву скомпрометированных SA (отключение, ротация ключей, аннулирование токенов), ротации секретов и повторному шифрованию с новыми версиями ключей KMS. Проводите тестирование ежеквартально.
Обоснование: Подготовленное, воспроизводимое реагирование минимизирует время простоя и риск раскрытия данных.

Такая архитектура обеспечивает использование короткоживущих, проверяемых идентификаторов на каждом этапе, последовательную авторизацию с учетом арендатора, защиту секретов и ключей, приватные каналы передачи данных и усиленную безопасность цепочки поставок, а также наблюдаемость и процессы реагирования, которые поддерживают отказоустойчивость системы при атаках и в ходе штатной эксплуатации.

← Данные приложений · Все домены · Непрерывная доставка →

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