Лабораторная работа — PCSE Google Cloud Professional Cloud Security Engineer

Обзор

Предварительные требования

Шаги

1. 1.Провайдер, службы проекта, именование

   Включите API Cloud KMS, Cloud Storage, Cloud Logging и Org Policy.

   Копировать

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       google = { source = "hashicorp/google", version = "~> 6.0" }
     }
   }
   
   provider "google" {
     project = "your-project-id" # REPLACE
     region  = "us-central1"
   }
   
   locals {
     labels = {
       project    = "certlabpro-pcse"
       managed_by = "terraform"
     }
   }
   
   data "google_project" "current" {}
   
   resource "google_project_service" "cloudkms" {
     service            = "cloudkms.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "storage" {
     service            = "storage.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "logging" {
     service            = "logging.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "orgpolicy" {
     service            = "orgpolicy.googleapis.com"
     disable_on_destroy = false
   }

2. 2.Применение ограничения политики организации, предотвращающего создание сети по умолчанию

   Создаваемые ресурсы:

   • Organization Policy

   Служба политики организации — это примитив ограждения PCSE: установите ограничения один раз на уровне организации / папки / проекта, и ресурсы, нарушающие их, никогда не могут быть созданы. Экзамен PCSE проверяет различие между ограничениями и IAM: IAM регулирует кто может действовать; политика организации регулирует что может существовать.

   Мы применяем compute.skipDefaultNetworkCreation на уровне проекта — при новой инициализации этого проекта GCP обычно создает VPC по умолчанию с чрезмерно разрешительными правилами брандмауэра. Это ограничение предотвращает такое поведение. PCSE-канонический подход предотвращать по умолчанию.

   Копировать

   resource "google_project_organization_policy" "skip_default_network" {
     project    = data.google_project.current.project_id
     constraint = "compute.skipDefaultNetworkCreation"
   
     boolean_policy {
       enforced = true
     }
   
     depends_on = [google_project_service.orgpolicy]
   }

3. 3.Создание связки ключей Cloud KMS + CMK с автоматической ротацией каждые 90 дней

   Создаваемые ресурсы:

   • Cloud KMS

   Cloud KMS — это примитив CMK для PCSE — управляемые клиентом ключи шифрования для каждого сценария шифрования неактивных данных в GCS, BigQuery, дисках Compute Engine, Cloud SQL, Spanner, Secret Manager. Экзамен PCSE проверяет ротацию CMK (постоянно включена по умолчанию в CMEK; ротация по умолчанию каждые 90 дней является рекомендуемой настройкой) и разделение связки ключей + ключа (связка ключей является границей IAM; ключи наследуют ее).

   Мы создаем региональную связку ключей + ключ SYMMETRIC_ENCRYPTION с ротацией каждые 90 дней. Предоставление служебной учетной записи Cloud Storage роли roles/cloudkms.cryptoKeyEncrypterDecrypter требуется, прежде чем бакет в Шаге 4 сможет использовать ключ — Шаг 4 включает эту привязку.

   Копировать

   resource "google_kms_key_ring" "main" {
     name     = "certlabpro-pcse-keyring"
     location = "us-central1"
   
     depends_on = [google_project_service.cloudkms]
   }
   
   resource "google_kms_crypto_key" "storage_cmk" {
     name            = "storage-cmk"
     key_ring        = google_kms_key_ring.main.id
     purpose         = "ENCRYPT_DECRYPT"
     rotation_period = "7776000s" # 90 days
   
     lifecycle {
       prevent_destroy = false # lab-only
     }
   }

4. 4.Подготовка бакета Cloud Storage, зашифрованного CMK

   Создаваемые ресурсы:

   • Cloud Storage
   • Cloud KMS

   Рекомендуемый PCSE шаблон шифрования неактивных данных: никогда не используйте шифрование по умолчанию, управляемое Google, для конфиденциальных данных; всегда подключайте CMK. Мы предоставляем служебному агенту Cloud Storage (служебная учетная запись, специфичная для проекта, service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com) роль roles/cloudkms.cryptoKeyEncrypterDecrypter для CMK, а затем подготавливаем бакет, который ссылается на ключ.

   Любой объект, записанный в этот бакет, оборачивается ключом шифрования данных (DEK), который сам оборачивается CMK. Ротация CMK ротирует следующий DEK; существующие объекты перешифровываются при следующей записи. Экзамен PCSE проверяет эту форму конвертного шифрования.

   Копировать

   resource "random_id" "suffix" {
     byte_length = 4
   }
   
   resource "google_storage_project_service_account" "gcs_account" {}
   
   resource "google_kms_crypto_key_iam_member" "gcs_kms" {
     crypto_key_id = google_kms_crypto_key.storage_cmk.id
     role          = "roles/cloudkms.cryptoKeyEncrypterDecrypter"
     member        = "serviceAccount:${google_storage_project_service_account.gcs_account.email_address}"
   }
   
   resource "google_storage_bucket" "secure" {
     name                        = "certlabpro-pcse-secure-${random_id.suffix.hex}"
     location                    = "us-central1"
     uniform_bucket_level_access = true
     force_destroy               = true # lab-only
   
     encryption {
       default_kms_key_name = google_kms_crypto_key.storage_cmk.id
     }
   
     labels = local.labels
   
     depends_on = [google_kms_crypto_key_iam_member.gcs_kms]
   }

5. 5.Маршрутизация аудитных журналов IAM в выделенный бакет для журналирования

   Создаваемые ресурсы:

   • Cloud Logging
   • Cloud Audit Logs

   Рекомендуемое PCSE хранение аудитных журналов: бакеты журналов _Required и _Default по умолчанию имеют срок хранения 30 дней. Чувствительные аудиторские события (предоставление/отзыв IAM-прав / редактирование политик) требуют гораздо более длительного срока — часто 7 лет для соответствия SOX / HIPAA / FedRAMP.

   Мы создаем выделенный бакет для журналирования с 400-дневным сроком хранения + приемник журналов, маршрутизирующий аудиторские журналы, связанные с политиками IAM, в него. Флаг unique_writer_identity = true генерирует идентификатор службы для каждого приемника (сохраняет цепочку аудита — вы можете предоставить ему доступ только для записи, не раскрывая свой пользовательский идентификатор).

   С пятью блоками на месте (провайдер+API, ограждение политики организации, связка ключей KMS+CMK, бакет CMK, приемник аудитных журналов) формируется базовая конфигурация PCSE предотвратить → зашифровать → аудировать. Реальные развертывания PCSE накладывают на эту базу Security Command Center (SCC) Premium, периметры VPC Service Controls, Binary Authorization, Cloud Armor WAF, Identity-Aware Proxy, Workforce Identity Federation и Sensitive Data Protection (DLP).

   Копировать

   resource "google_logging_project_bucket_config" "audit" {
     project        = data.google_project.current.project_id
     location       = "global"
     retention_days = 400
     bucket_id      = "audit-events"
   
     depends_on = [google_project_service.logging]
   }
   
   resource "google_logging_project_sink" "audit_sink" {
     name        = "certlabpro-pcse-audit-sink"
     destination = "logging.googleapis.com/${google_logging_project_bucket_config.audit.id}"
     filter      = "logName:\"cloudaudit.googleapis.com\" AND (protoPayload.serviceName=\"iam.googleapis.com\" OR protoPayload.serviceName=\"cloudkms.googleapis.com\")"
   
     unique_writer_identity = true
   }
   
   # Required so the sink can write to the bucket.
   resource "google_project_iam_member" "audit_sink_writer" {
     project = data.google_project.current.project_id
     role    = "roles/logging.bucketWriter"
     member  = google_logging_project_sink.audit_sink.writer_identity
   }

Очистка ресурсов