Praxislabor — PCSE Google Cloud Professional Cloud Security Engineer

Übersicht

Voraussetzungen

Schritte

1. 1.Provider, Projektdienste, Benennung

   Aktivieren Sie die Cloud KMS-, Cloud Storage-, Cloud Logging- und Org Policy-APIs.

   Kopieren

   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.Anwenden einer Organisationsrichtlinienbeschränkung, die die Erstellung von Standardnetzwerken verhindert

   Ressourcen:

   • Organization Policy

   Org Policy Service ist die Leitplanke-Primitive von PCSE – legen Sie Beschränkungen einmal auf Organisations-, Ordner- oder Projektebene fest, und Ressourcen, die diese verletzen, können niemals erstellt werden. Die PCSE-Prüfung testet die Unterscheidung zwischen Beschränkungen und IAM: IAM regelt, wer handeln kann; Org Policy regelt, was existieren darf.

   Wir wenden compute.skipDefaultNetworkCreation auf Projektebene an – wenn dieses Projekt neu initialisiert wird, erstellt GCP normalerweise ein Standard-VPC mit übermäßig permissiven Firewall-Regeln. Die Beschränkung verhindert dies. Die PCSE-kanonische Form standardmäßig verhindern.

   Kopieren

   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.Erstellen eines Cloud KMS-Schlüsselbunds + CMK mit automatischer 90-Tage-Rotation

   Ressourcen:

   • Cloud KMS

   Cloud KMS ist die CMK-Primitive von PCSE – kundenverwaltete Verschlüsselungsschlüssel für jedes Verschlüsselungsszenario im Ruhezustand über GCS, BigQuery, Compute Engine-Datenträger, Cloud SQL, Spanner, Secret Manager hinweg. Die PCSE-Prüfung testet die CMK-Rotation (standardmäßig immer aktiviert in CMEK; die standardmäßige 90-Tage-Rotation ist die empfohlene Einstellung) und die Trennung von Schlüsselbund + Schlüssel (der Schlüsselbund ist die IAM-Grenze; Schlüssel erben diese).

   Wir erstellen einen regionalen Schlüsselbund + einen SYMMETRIC_ENCRYPTION-Schlüssel mit 90-Tage-Rotation. Dem Cloud Storage-Dienstkonto roles/cloudkms.cryptoKeyEncrypterDecrypter muss die Berechtigung erteilt werden, bevor der Bucket in Schritt 4 den Schlüssel verwenden kann – Schritt 4 enthält diese Bindung.

   Kopieren

   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.Bereitstellen eines CMK-verschlüsselten Cloud Storage-Buckets

   Ressourcen:

   • Cloud Storage
   • Cloud KMS

   PCSE-empfohlenes Verschlüsselungsmuster im Ruhezustand: Verwenden Sie niemals die standardmäßige von Google verwaltete Verschlüsselung für sensible Daten; verbinden Sie immer einen CMK. Wir gewähren dem Cloud Storage-Dienstagenten (ein projektspezifisches Dienstkonto service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com) roles/cloudkms.cryptoKeyEncrypterDecrypter für den CMK und stellen dann einen Bucket bereit, der den Schlüssel referenziert.

   Jedes in diesen Bucket geschriebene Objekt wird mit einem Datenverschlüsselungsschlüssel (DEK) umhüllt, der selbst vom CMK umhüllt wird. Das Rotieren des CMK rotiert den nächsten DEK; bestehende Objekte werden beim nächsten Schreibvorgang neu verschlüsselt. Die PCSE-Prüfung testet diese Umschlagverschlüsselungs-Form.

   Kopieren

   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.Leiten von IAM-Audit-Logs in einen dedizierten Logging-Bucket

   Ressourcen:

   • Cloud Logging
   • Cloud Audit Logs

   PCSE-empfohlene Aufbewahrung von Audit-Logs: Die standardmäßigen _Required- und _Default-Log-Buckets haben eine Aufbewahrungsdauer von 30 Tagen. Sensible Audit-Ereignisse (IAM-Erteilungen/-Widerrufe/-Richtlinienänderungen) benötigen eine viel längere Aufbewahrung – oft 7 Jahre für SOX-/HIPAA-/FedRAMP-Konformität.

   Wir erstellen einen dedizierten Logging-Bucket mit 400-Tage-Aufbewahrungsdauer + eine Log-Senke, die IAM-Richtlinien-bezogene Audit-Logs dorthin leitet. Das Flag unique_writer_identity = true generiert eine dienstspezifische Identität pro Senke (bewahrt die Audit-Kette – Sie können ihr reinen Schreibzugriff gewähren, ohne Ihre Benutzeridentität preiszugeben).

   Mit fünf vorhandenen Blöcken (Provider+APIs, Org Policy Leitplanke, KMS Schlüsselbund+CMK, CMK Bucket, Audit-Log-Senke) ist die PCSE verhindern → verschlüsseln → prüfen-Grundlage geschaffen. Echte PCSE-Bereitstellungen schichten Security Command Center (SCC) Premium, VPC Service Controls Perimeters, Binary Authorization, Cloud Armor WAF, Identity-Aware Proxy, Workforce Identity Federation und Sensitive Data Protection (DLP) auf diese Basis auf.

   Kopieren

   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
   }

Bereinigung