Laboratório prático — PCSE Google Cloud Professional Cloud Security Engineer

Visão geral

Pré-requisitos

Passos

1. 1.Provedor, serviços do projeto, nomenclatura

   Habilite as APIs do Cloud KMS, Cloud Storage, Cloud Logging e Org Policy.

   Copiar

   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.Aplique uma restrição de Política da Organização que impede a criação de rede padrão

   Provisiona:

   • Organization Policy

   O Serviço de Política da Organização é o primitivo de barreira de proteção do PCSE — defina restrições uma vez no escopo da organização / pasta / projeto, e recursos que as violarem nunca poderão ser criados. O exame PCSE testa a distinção restrições vs. IAM: o IAM controla quem pode agir; a Política da Organização controla o que pode existir.

   Aplicamos compute.skipDefaultNetworkCreation no escopo do projeto — quando este projeto é recém-inicializado, o GCP normalmente cria uma VPC padrão com regras de firewall excessivamente permissivas. A restrição impede isso. O formato impedir por padrão canônico do PCSE.

   Copiar

   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.Crie um keyring do Cloud KMS + CMK com rotação automática de 90 dias

   Provisiona:

   • Cloud KMS

   O Cloud KMS é o primitivo CMK do PCSE — chaves de criptografia gerenciadas pelo cliente para cada cenário de criptografia em repouso em GCS, BigQuery, discos do Compute Engine, Cloud SQL, Spanner, Secret Manager. O exame PCSE testa a rotação de CMK (sempre ativa por padrão no CMEK; a rotação padrão de 90 dias é a configuração recomendada) e a separação de keyring + chave (o keyring é o limite do IAM; as chaves o herdam).

   Criamos um keyring regional + uma chave SYMMETRIC_ENCRYPTION com rotação de 90 dias. Conceder à conta de serviço do Cloud Storage roles/cloudkms.cryptoKeyEncrypterDecrypter é necessário antes que o bucket no Passo 4 possa usar a chave — o Passo 4 inclui essa vinculação.

   Copiar

   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.Provisione um bucket do Cloud Storage criptografado com CMK

   Provisiona:

   • Cloud Storage
   • Cloud KMS

   Padrão de criptografia em repouso recomendado pelo PCSE: nunca use a criptografia gerenciada pelo Google padrão para dados sensíveis; sempre conecte uma CMK. Concedemos ao agente de serviço do Cloud Storage (uma conta de serviço específica do projeto service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com) roles/cloudkms.cryptoKeyEncrypterDecrypter na CMK, então provisionamos um bucket que referencia a chave.

   Qualquer objeto gravado neste bucket é envolvido com uma chave de criptografia de dados (DEK), que por sua vez é envolvida pela CMK. A rotação da CMK rotaciona a próxima DEK; objetos existentes são recriptografados na próxima gravação. O exame PCSE testa esse formato de criptografia de envelope.

   Copiar

   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.Encaminhe logs de auditoria do IAM para um bucket de registro dedicado

   Provisiona:

   • Cloud Logging
   • Cloud Audit Logs

   Retenção de logs de auditoria recomendada pelo PCSE: os buckets de log padrão _Required e _Default têm retenção de 30 dias. Eventos de auditoria sensíveis (concessões / revogações de IAM / edições de política) precisam de muito mais tempo — frequentemente 7 anos para conformidade com SOX / HIPAA / FedRAMP.

   Criamos um bucket de registro dedicado com retenção de 400 dias + um sink de log que roteia logs de auditoria relacionados à política de IAM para ele. O sinalizador unique_writer_identity = true gera uma identidade de serviço por sink (preserva a cadeia de auditoria — você pode conceder acesso somente de gravação sem expor sua identidade de usuário).

   Com cinco blocos implementados (provedor+APIs, barreira de proteção de Org Policy, keyring+CMK do KMS, bucket CMK, sink de log de auditoria), a linha de base PCSE de prevenir → criptografar → auditar é formada. Implantações PCSE reais sobrepõem Security Command Center (SCC) Premium, perímetros de VPC Service Controls, Binary Authorization, Cloud Armor WAF, Identity-Aware Proxy, Workforce Identity Federation e Sensitive Data Protection (DLP) sobre esta base.

   Copiar

   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
   }

Limpeza