最后审核时间:2026年5月
使用原生 Terraform 构建 PCSE 考试中的 AWS 服务——每次构建一个代码块,并紧扣考试领域。相同的代码可在 OpenTofu 上运行。
在本实验结束时,你将使用纯 Terraform 部署最小但实际的 PCSE 安全基线——一个组织策略约束,防止创建默认网络;一个 Cloud KMS 密钥环和带有自动轮换的客户管理加密密钥;一个 CMK 加密的 Cloud Storage 存储桶;以及一个将 IAM 事件路由到专用日志存储桶的 Cloud Audit Logs 接收器。总共五个模块;形成 PCSE 的“阻止 → 加密 → 审计”循环。
将这些片段放入单个 main.tf 文件中,运行 terraform init,然后逐步运行 terraform apply。
>= 1.5 或 OpenTofu >= 1.6。roles/orgpolicy.policyAdmin 角色。相同约束的组织级别版本存在,但需要组织管理员权限。your-project-id。在实验范围内几乎免费:
每月约 $0–$1。如果你想研究控制面板,让其保持运行也很便宜。
启用 Cloud KMS、Cloud Storage、Cloud Logging 和组织策略 API。
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
}组织策略服务 是 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]
}Cloud KMS 是 PCSE 的 CMK 原语——用于 GCS、BigQuery、Compute Engine 磁盘、Cloud SQL、Spanner、Secret Manager 等所有静态加密场景的客户管理加密密钥。PCSE 考试会考查 CMK 轮换(CMEK 中默认始终开启;默认 90 天轮换是推荐设置)以及 密钥环与密钥的分离(密钥环是 IAM 边界;密钥继承其权限)。
我们创建一个区域性密钥环和一个带有 90 天轮换的 SYMMETRIC_ENCRYPTION 密钥。在第 4 步中的存储桶可以使用该密钥之前,需要授予 Cloud Storage 服务账户 roles/cloudkms.cryptoKeyEncrypterDecrypter 权限——第 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
}
}PCSE 推荐的静态加密模式:绝不要对敏感数据使用默认的 Google 管理加密;始终连接 CMK。我们授予 Cloud Storage 服务代理(一个项目特定的服务账户 service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com)在 CMK 上的 roles/cloudkms.cryptoKeyEncrypterDecrypter 权限,然后部署一个引用该密钥的存储桶。
写入此存储桶的任何对象都将用数据加密密钥(DEK)进行封装,而 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]
}PCSE 推荐的审计日志保留策略:默认的 _Required 和 _Default 日志存储桶的保留期为 30 天。敏感的审计事件(IAM 授权/撤销/策略编辑)需要更长的保留期——通常为了 SOX/HIPAA/FedRAMP 合规性需要 7 年。
我们创建一个具有 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
}terraform destroy 会销毁所有资源。KMS 密钥 将被 安排 销毁(24 小时宽限期——Cloud KMS 密钥不会立即删除)。CMK 加密的存储桶 会被销毁(force_destroy = true);现有对象在销毁过程中会重新加密——Cloud Storage 会透明地处理这一点。组织策略约束 将被移除;该项目将再次允许创建默认网络。审计日志接收器 + 存储桶 将被干净地销毁。
PCSE 涵盖了本实验无法容纳的许多安全方面——Security Command Center (SCC Premium / Enterprise – 统一的威胁检测 + 态势管理界面)、VPC Service Controls(围绕 BigQuery / Storage 等的数据泄露边界)、Cloud Armor(WAF + DDoS + 僵尸程序管理)、Identity-Aware Proxy (IAP – 零信任应用级身份验证)、Cloud HSM (FIPS-140-2 Level 3 硬件支持的 KMS)、Cloud External Key Manager (EKM – 密钥保存在 Google 外部)、Confidential VMs / Confidential GKE Nodes(内存加密)、Binary Authorization(镜像认证门控)、Container Threat Detection / Web App and API Protection (WAAP)、Sensitive Data Protection (DLP – PII 发现 + 掩码)、Workforce Identity Federation、Workload Identity Federation、Access Context Manager(上下文感知访问策略),以及整个 Mandiant 收购的领域(威胁情报、攻击面管理、漏洞分析)。
我们坚持使用 组织策略 + KMS + CMK 存储 + 审计日志 原语,因为它们是 PCSE 的基础,所有更高级的控制都建立在此之上。SCC 从相同的审计日志中读取数据。VPC-SC 边界封装相同的存储桶。Cloud HSM 取代 KMS 作为密钥后端。IAP 叠加在相同的 IAM 身份上。掌握基础;分层专业控制。
有关按服务划分的概念性覆盖范围,请参阅此证书页面的 浏览、手册 和 Editorial 部分。