Google PCA: Безопасность, соответствие требованиям и архитектура защиты данных — Руководство по подготовке

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

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

Обзор

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

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

Архитектура идентификации и доступа

• Принципы и модель

  • Принцип наименьших привилегий по умолчанию: предоставляйте минимальный набор разрешений, необходимый для выполнения задачи, и отдавайте предпочтение предопределенным или кастомным ролям перед примитивными (Owner, Editor, Viewer).
  • Разделение обязанностей: распределяйте роли между сборщиками (CI/CD), развертывающими, операторами и службой безопасности. Используйте экстренные учетные записи (break-glass) со строгим контролем и логированием для чрезвычайных ситуаций.
  • Применение Zero Trust: используйте доступ на основе контекста для проверки пользователя, устройства, местоположения и риска; требуйте строгую многофакторную аутентификацию (MFA); и постоянно оценивайте контекст сессии.
  • Политики организации и IAM Deny: кодифицируйте защитные ограничения (например, запрет на создание ключей сервисных аккаунтов, ограничение совместного доступа к домену) и используйте политики запрета (deny policies) для установления незыблемых границ.

• Реализация IAM и стратегия использования сервисных аккаунтов

  • Создайте иерархическую модель доступа: папки отражают направления бизнеса или среды (prod, non-prod); проекты изолируют радиус поражения и биллинг; сервисные аккаунты (SA) представляют рабочие нагрузки.
  • Одна рабочая нагрузка — один сервисный аккаунт: избегайте совместного использования SA между несвязанными сервисами. Привязывайте разрешения к области развертывания (проект) и области действия ресурса.
  • Отдавайте предпочтение короткоживущим учетным данным через Service Account Impersonation и Workload Identity Federation. Отключите управляемые пользователем ключи сервисных аккаунтов; если это неизбежно, изолируйте их использование, часто ротируйте и отслеживайте с помощью журналов аудита.
  • Используйте Access Boundaries, чтобы ограничить доступ олицетворенного SA во время запроса (например, ограничить пути к объектам GCS), сдерживая радиус поражения даже в случае неправомерного использования привилегированного SA.
  • Условный IAM: применяйте условия на уровне ресурсов (время, IP, атрибуты участника) для ограничения доступа. Пример: запретить доступ к продакшену, за исключением корпоративных IP-диапазонов и во время окон для внесения изменений.

• Режимы отказа и компромиссы

  • Чрезмерно привилегированные роли (например, Editor на уровне проекта) увеличивают риск; предпочитайте гранулярные роли и проверяйте их с помощью анализаторов политик.
  • Разрастание ключей сервисных аккаунтов в CI/CD и локальных скриптах — распространенный вектор атак; при использовании олицетворения некоторые устаревшие инструменты могут потребовать адаптации.
  • Политики IAM Deny — мощный инструмент, но их отладка может быть сложной; внедряйте и тестируйте изменения в нерабочей среде с явными пробными запусками (dry run).

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

• gcloud auth print-access-token –impersonate-service-account=svc-ci@proj.iam.gserviceaccount.com

Защита данных и криптография

• Cloud KMS и модели управления ключами
  • Шифрование неактивных данных (at rest) включено по умолчанию. Для дополнительного контроля используйте ключи шифрования, управляемые клиентом (CMEK), с такими сервисами, как BigQuery, Cloud Storage, диски Compute Engine, Pub/Sub и постоянные тома GKE.
  • Проектируйте иерархию ключей в соответствии со средой и доменом данных. Используйте отдельные связки ключей (keyrings) для каждого местоположения и отдельные ключи для каждого приложения или набора данных, чтобы ограничить радиус поражения (blast radius).
  • Ротация: включите плановую ротацию и корректно выводите из эксплуатации старые версии ключей с помощью конвертного шифрования (envelope encryption) для приложений. Проверяйте совместимость потребителей перед увеличением частоты ротации.
  • External Key Manager (EKM) и External Key Access (EKA) позволяют размещать ключи за пределами Google Cloud для соблюдения нормативных требований. Компромиссы включают дополнительную задержку и зависимость от доступности внешнего HSM; планируйте работу в режиме ограниченной функциональности (degraded-mode).
  • Применяйте принцип наименьших привилегий IAM для CryptoKeys. Используйте журналы аудита на уровне ключей для подтверждения доступа.

Пример (CMEK с ротацией):

undefined

undefined

• Шифрование на уровне приложения

  • Используйте конвертное шифрование (например, с помощью Tink) для шифрования конфиденциальных полей на уровне приложения, обеспечивая выборочный доступ и изоляцию данных тенантов. Создавайте производные ключи для каждого тенанта, чтобы минимизировать влияние между ними.
  • Проверяйте целостность (AEAD) для предотвращения подделки данных и атак повторного воспроизведения (replay attacks).

• Secret Manager и жизненный цикл секретов

  • Храните учетные данные, токены и ключи API как версионируемые секреты; никогда не храните их в образах, Git или метаданных инстансов. Предоставляйте IAM-разрешения на уровне секрета или проекта сервисному аккаунту времени выполнения.
  • Ротация: автоматизируйте с помощью Cloud Functions/Cloud Run, запускаемых по триггеру Pub/Sub, для создания новой версии, обновления зависимых систем и отзыва старых версий. Предпочитайте замену долгоживущих паролей баз данных на аутентификацию через IAM или кратковременные токены.
  • Безопасность конфигурации: отделяйте несекретную конфигурацию (ConfigMap, переменные окружения) от секретов. Предотвращайте раскрытие секретов в логах и сообщениях об ошибках.

Пример (добавление новой версии секрета):

undefined

• Усиление защиты и конфиденциальные вычисления в Compute
  • Shielded VMs: включите безопасную загрузку (secure boot), vTPM и мониторинг целостности для защиты от буткитов и руткитов. Применяйте принудительно через политики организации и проверяйте в CI/CD-пайплайнах.
  • Confidential VMs: шифрование памяти по умолчанию защищает используемые данные (data-in-use) с минимальными изменениями конфигурации; оцените влияние на производительность для высокопроизводительных, криптографически интенсивных рабочих нагрузок.
  • Усиленные образы (Hardened images): используйте в качестве основы оптимизированные Google или усиленные по стандартам CIS образы; управляйте установкой патчей с помощью OS Config и отключайте ненужные пакеты и порты.

Сетевая и периметральная безопасность

• Сетевая сегментация и контроль исходящего трафика (egress)

  • Сегментируйте по уровням и чувствительности данных, используя отдельные VPC, подсети и иерархические правила брандмауэра. Комбинируйте теги брандмауэра, учитывающие идентификацию, с ограничениями между сервисами (например, GKE NetworkPolicy) для применения контроля над трафиком “восток-запад” (east-west).
  • Контролируйте исходящий трафик (egress) с помощью Cloud NAT, политик DNS и ограниченного Private Google Access для минимизации эксфильтрации данных. Используйте явные списки разрешенных исходящих соединений (egress allowlists) и инспекцию через прокси, где это оправдано.

• VPC Service Controls (VPC SC)

  • Создавайте периметры безопасности (service perimeters) вокруг проектов, содержащих защищаемые данные, чтобы предотвратить их эксфильтрацию через управляемые Google API (GCS, BigQuery, Secret Manager, Pub/Sub и т.д.).
  • Уровни доступа (Access levels): определите контекстные условия (идентификация пользователя, IP-диапазоны, состояние устройства), которые должны быть выполнены для доступа к сервисам внутри периметра.
  • Используйте мосты периметра (perimeter bridges) для контролируемых рабочих процессов между несколькими периметрами и правила исходящего трафика (egress rules) для ограничения адресатов. Тестируйте в режиме “пробного запуска” (dry-run), чтобы избежать нарушения работы пайплайнов.
  • Ограничения: не защищает напрямую трафик к IP-адресам Compute Engine; дополняйте его правилами брандмауэра и контролем исходящего трафика. Некоторые инструменты и гибридные сценарии могут требовать сервисных аккаунтов, “знающих” о периметре, и Private Service Connect для подключения к ограниченным VIP.

• Защита на периметре и защита приложений

  • Cloud Armor: защищайте HTTP(S)-приложения за глобальным внешним балансировщиком нагрузки с помощью защиты от DDoS-атак на уровнях L3/L4/L7, списков разрешенных/запрещенных IP-адресов, геолокационных контролей и ограничения частоты запросов (rate limiting).
  • Правила WAF: применяйте предустановленные управляемые правила и пользовательские сигнатуры для защиты от угроз из списка OWASP Top 10; настраивайте их для уменьшения ложных срабатываний. Привязывайте правила к отдельным бэкенд-сервисам, чтобы адаптировать политики под разные версии API или компоненты приложения.
  • Защита API: размещайте перед API шлюзы API Gateway или Apigee для аутентификации, квотирования, валидации схем и обнаружения угроз; интегрируйте Cloud Armor для защиты на периметре; рассмотрите использование reCAPTCHA Enterprise и средств контроля ботов, где это уместно.
  • Компромиссы: более глубокая инспекция трафика может добавлять задержку и операционный шум. Внедряйте правила в режиме предварительного просмотра (preview mode), отслеживайте логи и вводите их в действие постепенно.

Операции по обеспечению безопасности, мониторинг и соответствие требованиям

• Security Command Center (SCC) и обнаружение угроз

  • SCC агрегирует инвентаризационные данные о ресурсах и результаты проверок по проектам и организациям. Используйте его для определения базового состояния безопасности (публичные бакеты, открытые правила брандмауэра), отслеживания отклонений и запуска процессов устранения.
  • Премиум-версия для обнаружения угроз включает Event Threat Detection, VM Threat Detection и Container Threat Detection для выявления вредоносного ПО, криптомайнинга и аномального поведения.
  • Интегрируйте результаты проверок с конвейерами систем тикетов и SOAR; определяйте политики подавления/исключения с истечением срока действия, чтобы избежать усталости от оповещений.

• Безопасность уязвимостей и артефактов

  • Используйте Artifact Analysis для сканирования образов контейнеров на наличие CVE; применяйте политики времени развертывания с помощью Binary Authorization и подписанных аттестаций из CI.
  • Управление исправлениями через OS Config; отслеживайте окна уязвимости и автоматизируйте развертывание с помощью канареечных релизов.

• Журналы аудита, конфиденциальность и доказательства

  • Cloud Audit Logs по умолчанию предоставляет журналы Admin Activity и System Event; журналы Data Access можно включить для каждого сервиса, и они являются платными. Направляйте журналы в BigQuery для аналитики и в Cloud Storage для неизменяемого хранения и юридического удержания.
  • Классификация данных: используйте Cloud DLP для обнаружения и классификации персональных данных (PII), применения меток и тегов, а также сопоставления с уровнями защиты (CMEK, VPC SC, Confidential VMs).
  • Конфиденциальность и резидентность данных: ограничивайте местоположения с помощью политики организации; согласовывайте местоположения CMEK и хранилищ с нормативными требованиями.
  • Юридическое удержание и хранение: включайте политики хранения и удержания для бакетов; при необходимости используйте Object Versioning. Документируйте цепочку ответственности для криминалистических образов и журналов, чтобы предоставлять юридически состоятельные доказательства.

• Реагирование на инциденты и готовность к криминалистическому анализу

  • Подготовьте сценарии реагирования (runbooks), пути доступа и автоматизацию. Убедитесь, что у ответственных за реагирование есть доступ с минимальными привилегиями, а аудит включен на уровне организации, папок и проектов.
  • Сдерживание: изолируйте экземпляры, удаляя их из балансировщиков нагрузки, применяя правила брандмауэра для запрета исходящего трафика или перемещая проекты под действие более строгих политик организации; отключайте скомпрометированные сервисные аккаунты и ротируйте секреты и ключи.
  • Криминалистический анализ: создавайте снимки дисков и экспортируйте образы для офлайн-анализа; сохраняйте журналы путем экспорта. Где это применимо, используйте зеркалирование пакетов. Не изменяйте доказательства; работайте с копиями.
  • Восстановление: пересобирайте из доверенных образов, восстанавливайте секреты и проверяйте с помощью дымовых тестов и тестов безопасности. Проводите разбор инцидентов и используйте извлеченные уроки для улучшения защитных механизмов и систем обнаружения.

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

NimbusPay, SaaS-компания в сфере финансовых технологий, должна обрабатывать данные с тегом PCI в мультитенантных микросервисах на Google Cloud, обеспечить резидентность данных в ЕС, защититься от атак на уровне API и предоставлять аудируемые доказательства применения средств контроля. Компания планирует развернуть новый API v2, сохраняя работоспособность v1 на том же хостнейме.

Подход:

1. Разделение проектов и идентификаторов

• Создать отдельные проекты для каждой среды и уровня микросервисов (прием, обработка, отчетность). Назначить уникальный сервисный аккаунт рабочей нагрузки для каждого сервиса. Обоснование: изолирует радиус поражения и сопоставляет принцип минимальных привилегий с отдельными рабочими нагрузками.

2. Внедрение принципов Zero Trust и минимальных привилегий

• Предоставить предопределенные/пользовательские роли сервисным аккаунтам и группам DevOps; применить условный IAM для ограничения доступа к производственной среде корпоративными IP-адресами и рабочими часами. Обоснование: уменьшает возможность горизонтального перемещения и случайных изменений.

3. Удаление статических ключей сервисных аккаунтов

• Отключить управляемые пользователем ключи SA с помощью политики организации. Использовать имперсонацию сервисного аккаунта для CI/CD и операционной деятельности; применить Access Boundaries, ограничивая пути GCS для каждого тенанта. Обоснование: устраняет частый вектор утечки учетных данных и ограничивает доступ к данным даже в случае кражи токенов.

4. Защита данных с помощью CMEK и региональных средств контроля

• Создать связки ключей (keyrings) и ключи Cloud KMS в регионах europe-west; включить CMEK для наборов данных BigQuery, бакетов GCS и Persistent Disks. Настроить плановую ротацию и мониторинг версий. Обоснование: доказуемый криптографический контроль, соответствующий требованиям ЕС по резидентности данных и PCI.

5. Внедрение шифрования на уровне приложения для данных карт

• Использовать конвертное шифрование (Tink AEAD) с ключами данных для каждого тенанта, обернутыми с помощью CMEK; хранить в базах данных только зашифрованный текст. Обоснование: защита на уровне полей и минимизация области анализа при разборе инцидента.

6. Централизация секретов и их автоматическая ротация

• Хранить учетные данные БД и токены API в Secret Manager с IAM для каждого сервиса. Реализовать задания ротации, запускаемые по Pub/Sub, которые создают новые версии и обновляют развертывания. Где возможно, перейти на аутентификацию IAM DB для Cloud SQL. Обоснование: аудируемый жизненный цикл секретов с минимальным временем простоя.

7. Сегментация сетей и контроль исходящего трафика

• Использовать иерархические политики брандмауэра для обеспечения потоков web→API→DB; запретить прямой доступ web→DB. Включить Cloud NAT со списками разрешенных исходящих подключений и Private Google Access (restricted) для Google API. Обоснование: ограничивает перемещение трафика «восток-запад» и блокирует несанкционированную эксфильтрацию.

8. Изоляция сервисов данных с помощью VPC Service Controls

• Поместить проекты BigQuery, GCS и Secret Manager в периметр безопасности; определить уровни доступа, требующие корпоративного IP и управляемых устройств. Протестировать в режиме dry-run, затем принудительно включить. Обоснование: снижает риск эксфильтрации данных через украденные токены или неверно настроенные клиенты.

9. Защита периметра и API

• Установить перед глобальным HTTPS-балансировщиком нагрузки Cloud Armor с управляемыми правилами и ограничением частоты запросов. Использовать маршрутизацию на основе пути для разделения /v1 и /v2 на разные бэкенд-сервисы и применять индивидуальные политики WAF для каждой версии. Интегрировать Apigee для аутентификации, квот и валидации схем. Обоснование: многоуровневая защита API, плавный переход с v1 на v2 и минимизация ложных срабатываний.

10. Усиление защиты вычислительных ресурсов и аттестация артефактов

• Включить Shielded VMs и Confidential VMs для узлов обработки; использовать базовые образы, усиленные по стандартам CIS. Сканировать образы в Artifact Registry, требовать подписанные аттестации с помощью Binary Authorization для GKE. Обоснование: защищает цепочку загрузки и используемые данные, а также обеспечивает доверие к цепочке поставок.

11. Мониторинг состояния безопасности и угроз с помощью SCC

• Включить SCC Premium для обнаружения рискованных конфигураций и угроз времени выполнения; интегрировать с системой тикетов для соблюдения SLA. Подавлять принятые риски с указанием даты истечения. Обоснование: непрерывная проверка и полезные, применимые на практике сигналы.

12. Сбор, хранение журналов и предоставление доказательств

• Направлять журналы Admin Activity, Data Access и VPC Flow Logs в BigQuery и Cloud Storage с политиками хранения и юридическим удержанием. Помечать наборы данных метками резидентности и конфиденциальности. Обоснование: поддерживает расследования и внешние аудиты с ограниченным доступом.

13. Подготовка к реагированию на инциденты и криминалистическому анализу

• Создать сценарии реагирования для изоляции скомпрометированных сервисов путем перемещения проектов в карантинную папку с более строгими политиками, отключения задействованных SA и создания снимков дисков для офлайн-анализа. Обоснование: быстрое сдерживание с сохранением доказательств.

Краткие команды для поддержки развертывания:

• gcloud kms keyrings create pci-ring –location=europe-west1
• gcloud kms keys create tenant-wrap –keyring=pci-ring –location=europe-west1 –purpose=encryption –rotation-period=90d
• gcloud access-context-manager levels create corp-devices –title=corp-devices –basic-level-spec=‘ipSubnetworks: [“203.0.113.0/24”]’

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

← Сетевое взаимодействие · Все домены · Надежность →

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

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