金融行业谷歌云安全架构案例拆解与落地培训 Day 2 实验手册

模块 0：背景与 Day 1 基线环境部署

1. 业务背景：支付系统

业务系统的核心业务特征与技术挑战包括：

• 纯本地化运营：为保障极致的用户体验与极低的网络延迟，核心服务与交易节点严格限制在沙特阿拉伯等本地市场。
• 严苛的数据主权与合规要求：受当地金融监管机构强力约束，所有支付交易记录、客户隐私（PII）以及系统操作审计日志绝对禁止出境。
• 零信任架构与深度防御：金融支付系统直面全球最严峻的网络攻击。因此，平台必须严格遵循 PCI DSS v4 标准及 ISO 27001 规范，从网络边界、计算环境、应用访问到数据落盘，实行端到端加密与最小权限控制。

2. Day 1 实验基线快速恢复 (Terraform)

在 Day 1 的实验中，我们已经基于上述要求构建了底层安全基座。为确保所有学员在 Day 2 的操作环境完全一致，并迅速进入高级安全功能的配置，请使用以下 Terraform 脚本在 Cloud Shell 中一键拉起 Day 1 基线环境。

基线内容包含：

1. 数据驻留约束：模拟应用组织策略（为实验方便，此处限制资源在 me-central1 部署）。
2. 安全隔离网络：创建自定义的安全 VPC (secure-vpc)，包含专用的子网并开启 VPC 流日志。
3. 安全边界防火墙：配置专门允许 Identity-Aware Proxy (IAP) 的防火墙规则，拒绝所有外部公共互联网的直接 SSH/RDP 探测。
4. 加密与审计底座：创建 KMS 密钥环用于后续的 CMEK 加密，并配置具备防篡改（WORM）特性的 Cloud Storage 存储桶，配合 Log Sink 实现全量日志的安全归档。

2.1 执行步骤

1. 打开 Google Cloud Console (控制台)。
2. 在Day02文件夹下新建一个项目，可以命名为Day02-xxx，或者从Day01中把上周的项目移动到Day02下，但是一定要确保上周的实验完整地完成了。
3. 点击页面右上角的 Activate Cloud Shell 图标。
4. 在屏幕下方弹出的 Cloud Shell 终端内，运行以下命令创建工作目录：

   mkdir ~/day1-baseline && cd ~/day1-baseline
   # 开启必要的API
   gcloud services enable cloudresourcemanager.googleapis.com serviceusage.googleapis.com compute.googleapis.com cloudkms.googleapis.com --project=【你的项目ID】

5. 创建 main.tf 文件：

   nano main.tf

6. 将以下 Terraform 代码粘贴到文件中（按 Ctrl+O，Enter 保存，然后按 Ctrl+X 退出）：

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}
provider "google" {
  # 注意：在 Cloud Shell 中运行时，环境会自动继承您当前的项目 ID
  region  = "me-central1"
}
# 1. 创建安全的自定义 VPC
resource "google_compute_network" "secure_vpc" {
  name                    = "secure-vpc"
  auto_create_subnetworks = false
}
# 2. 创建子网并开启全量流日志 (VPC Flow Logs)
resource "google_compute_subnetwork" "secure_subnet" {
  name          = "secure-payment-subnet"
  ip_cidr_range = "10.0.1.0/24"
  region        = "me-central1"
  network       = google_compute_network.secure_vpc.id
  # 开启私有 Google 访问
  private_ip_google_access = true
  # 开启流日志以满足审计要求
  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 1.0
    metadata             = "INCLUDE_ALL_METADATA"
  }
}
# 3. IAP 安全防火墙规则 (仅允许 IAP 的 IP 范围 35.235.240.0/20 进行管理访问)
resource "google_compute_firewall" "allow_iap" {
  name    = "allow-iap-proxy"
  network = google_compute_network.secure_vpc.id
  allow {
    protocol = "tcp"
    ports    = ["22", "3389"]
  }
  source_ranges = ["35.235.240.0/20"]
}
# 4. 创建 KMS Keyring 与 CryptoKey用于后续数据加密 (CMEK)
resource "random_id" "suffix" {
  byte_length = 4
}
resource "google_kms_key_ring" "payment_keyring" {
  name     = "payment-keyring-${random_id.suffix.hex}"
  location = "me-central1"
}
resource "google_kms_crypto_key" "payment_key" {
  name            = "payment-cmek-key"
  key_ring        = google_kms_key_ring.payment_keyring.id
  rotation_period = "7776000s" # 90天自动轮转
}
# 5. 创建 WORM 审计日志存储桶
resource "google_storage_bucket" "audit_bucket" {
  name                        = "me-bank-audit-logs-${random_id.suffix.hex}"
  location                    = "me-central1"
  uniform_bucket_level_access = true
  # 开启保留策略 (WORM) 防止篡改，实验设置1天，实际可能为5年
  retention_policy {
    retention_period = 86400 
    is_locked        = false # 实验环境中不锁定，以免无法删除
  }
}

1. 依次运行以下命令完成基线部署：

   terraform init
   terraform apply -auto-approve

   等待部署完成（约需 2-3 分钟）。完成之后，所有的 Day 1 基础设施已就绪，我们将直接进入 Day 2 实验。

模块 1：现代应用托管与零信任架构 (GKE & IAP)

1.1 功能介绍与场景目标

在 Day 2 的第一阶段，我们将为业务系统部署“支付网关前端管理系统”。这个 Web 应用运行在容器中，负责让银行内部的运维员工查看支付流水状态和系统健康度。

为了满足金融领域的防御要求，我们将使用以下架构：

1. Private GKE (私有 Kubernetes 集群)：所有的计算节点完全剥离公网 IP，彻底杜绝从外部互联网直接通过节点 IP 发起扫描或入侵。
2. Identity-Aware Proxy (IAP)：摒弃传统的 VPN。在 Web 应用前方配置零信任代理，任何试图访问“支付前端管理系统”的请求，都必须首先通过 Google 身份验证，并在应用层进行细粒度的 IAM 权限检查。

1.2 合规性映射 (Compliance Mapping)

本模块的设计直接响应以下金融合规要求：

• PCI DSS v4 规范 7：“按照业务需知 (Need-to-Know) 的原则限制对系统组件和持卡人数据的访问。” IAP 允许我们配置精确的 IAM 角色，仅允许特定群组（如授权员工）访问前端。
• PCI DSS v4 规范 8：“识别用户并验证对系统组件的访问。” GKE 结合 IAP 提供基于 OAuth 的强身份验证。
• ISO 27001 (A.9 访问控制)：要求建立访问控制策略以限制对信息的访问。私有集群（网络层级拦截）和 IAP（身份层级拦截）构成了深度防御（Defense-in-Depth）的访问控制闭环。

1.3 Web UI 详细操作步骤

请严格按照以下说明在 GCP 控制台中点击操作。

任务 A：在安全 VPC 中创建私有 GKE 集群

1. 展开控制台左上角的 导航菜单 (Navigation menu)。
2. 向下滚动到 Kubernetes Engine，悬停并点击 Clusters (集群)。
3. 在页面顶部，点击 + CREATE (+ 创建)。
4. GCP 提供 Autopilot 和 Standard 两种模式。为了精确控制网络隔离配置，请在 Standard (标准) 模式下点击 CONFIGURE (配置)。
5. Cluster basics (集群基本信息)：
   • 在 Name (名称) 字段中，输入：payment-frontend-cluster
   • 在 Location type (位置类型) 选择 Zonal (可用区)，并在下拉框中选择 me-central1-a（符合数据驻留合规要求）。
6. 网络隔离配置：
   • 在左侧菜单栏中，找到并点击 Networking (网络)。
   • 在 Network (网络) 下拉菜单中，选择 secure-vpc。
   • 在 Node subnet (节点子网) 下拉菜单中，选择 secure-payment-subnet。
7. 配置节点规格：
   • 在左侧菜单栏中，找到并点击 default-pool。
   • 在右侧页面中，将节点数设置为1。
   • 点击左侧 节点数，找到机器类型，在预设中选择 e2-micro。
8. 在页面底部的蓝色按钮点击 CREATE (创建)。
   (注意：GKE 集群配置大约需要 5-10 分钟时间。请耐心等待，直到集群名称旁边出现绿色的对勾符号。)

任务 B：部署“支付网关前端”容器并配置 Ingress

由于我们未通过控制平面建立 Bastion 堡垒机，我们将直接使用 GCP Console UI 的工作负载部署功能来下发应用。

1. 在左侧菜单中（仍在 Kubernetes Engine 界面），点击 Workloads (工作负载)。
2. 在中间点击 创建部署 按钮。
3. 部署配置 页面：
   • 在 部署名称 中输入：payment-web-ui
   • 滚动到页面底部，点击 下一步：容器详细信息。
4. 在新页面中：
   • 选择 Existing container image (现有容器映像)。
   • 在 Image path 中输入用于模拟支付前端的镜像：us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
   • 点击页面底部的 下一步：公开（可选）。
5. 暴露应用服务：
   • 勾选“将 Deployment 作为新 Service 公开”。
   • 在弹出的对话框中，配置如下：
     • Port (端口) 填入：80
     • Target port (目标端口) 填入：8080
     • Service type (服务类型) 下拉菜单，选择 节点端口。
   • 点击下方的 部署 按钮。
6. 创建 Ingress：
   • 在左边菜单选择“Gateway、Service 和 Ingress”。
   • 在上方导航中选择“Ingress”，然后选择“转到服务” 。
   • 勾选刚才创建的服务，在顶部选择“创建Ingress”。
   • 在名称中填入pay-ingress
   • 选择“Host and path rules”，在“backends 1”中选择“payment-web-ui-service”
   • 点击下方的 Create 按钮，稍等几分钟。
7. 验证
   • 当状态显示为OK后，点击前端下面的IP即可访问服务。可以看到“Hello, world! Version: 1.0.0 Hostname: payment-web-xxxxxx”

任务 C：配置 Identity-Aware Proxy (IAP) 零信任代理

现在，前端通过负载均衡器暴露，但处于“裸奔”状态。我们需要启用 IAP 增加身份屏障。

1. 展开左上角 导航菜单 (Navigation menu)。
2. 滚动到 Security (安全)，然后点击 Identity-Aware Proxy。
3. 点击“启用API”，成功后点击“转到 Identity-Aware Proxy”。
4. 在 Identity-Aware Proxy 页面，您会看到一个名为 Resources 的表格。
   • 找到由刚才的 GKE Ingress 创建的后端服务（通常名字类似于 k8s-be-xxxxx）。
   • 在该行右侧，找到 IAP 开关。点击将其 开启 (Toggle ON)。
   • 在弹出的确认框中，勾选“我已阅读配置要求”，并点击 开启。
5. 配置访问权限控制 (IAM)：
   • 启用 IAP 后，选中刚刚开启 IAP 的那一行（点击该行使其高亮）。
   • 屏幕右侧将滑出 Info Panel (信息面板)。点击 添加主账号 按钮。
   • 在 New principals (新主账号) 输入框中，填写您当前的实验账号邮箱。
   • 在 Select a role (选择角色) 下拉菜单中，依次选择 Cloud IAP -> IAP-secured Web App User (受 IAP 保护的 Web 应用用户)。
   • 点击 SAVE (保存)。这直接满足了 PCI DSS 最小权限访问的要求。

1.4 安全验证 (渗透与体验测试)

在金融安全演练中，控制措施必须经过“验证”才能闭环。

前置工作：为负载均衡添加证书

1. 打开 cloudshell，生成并上传一个自签名的证书：

   openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout fake.key -out fake.crt -subj "/CN=【你的http IP地址】"
   gcloud compute ssl-certificates create lab-fake-cert --certificate=fake.crt --private-key=fake.key --global

2. 在搜索栏中输入 负载均衡 并进入页面。
3. 点击负载均衡器进入配置页面。
4. 在页面上方点击修改，点击前端配置，点击添加前端IP和端口。
5. 自定义一个名称，比如“ingres-https”，协议选择https，证书库中选择“使用经典证书”，证书选择我们刚才创建好的证书，最后点击更新并稍微等待一段时间。

测试：未经身份验证的非法访问拦截

1. 打开 cloudshell，执行以下命令：

   curl -k -I https://【你的https地址】

2. 查看返回的信息，你应该会得到类似的信息：

   HTTP/2 401
   content-length: 120
   content-type: text/html; charset=UTF-8
   x-goog-iap-generated-response: true
   date: Tue, 09 Jun 2026 09:51:34 GMT
   alt-svc: h3=":443"; ma=2592000

• 401 代表需要登录。由于在本次实验中，我们没有购买自己的域名，所以当我们直接访问浏览器时，我们没有办法在未授权的浏览器中显示谷歌的登录页面，也没办法在授权的浏览器中看到”hello world!”的显示。在实际的生产中，配置证书后即可实现针对 IAM 的页面访问控制。

1.5 Quick Catch-up: CLI / Terraform 等效操作

如果您希望使用基础设施即代码 (IaC) 的方式快速重现上述复杂的配置，以下是相应的 Terraform/CLI 命令等效实现参考：

私有 GKE 创建等效代码 (Terraform):

gcloud services enable container.googleapis.com --project=【项目名称】
cd ..; mkdir 1.5; cd 1.5; nano main.tf

resource "google_container_cluster" "private_gke" {
  name     = "payment-frontend-cluster"
  location = "me-central1-a"
  network  = "secure-vpc"
  subnetwork = "secure-payment-subnet"
  initial_node_count = 1
  deletion_protection = false
  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = false
    master_ipv4_cidr_block  = "172.16.0.0/28"
  }
  node_config {
    machine_type = "e2-micro"
  }
}

应用部署、NodePort 与 Ingress 等效命令 (kubectl):

terraform init
terraform apply -auto-approve
gcloud container clusters get-credentials payment-frontend-cluster --zone=me-central1-a
# 1. 部署容器工作负载
kubectl create deployment payment-web-ui --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
# 2. 暴露为 NodePort 服务
kubectl expose deployment payment-web-ui --type=NodePort --port=80 --target-port=8080 --name=payment-web-ui-service
# 3. 创建 Ingress (HTTP 负载均衡器)
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pay-ingress
spec:
  defaultBackend:
    service:
      name: payment-web-ui-service
      port:
        number: 80
EOF

自签发证书与 HTTPS 负载均衡挂载等效命令 (gcloud CLI):

# 1. 生成并上传 SSL 证书
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout fake.key -out fake.crt -subj "/CN=127.0.0.1"
gcloud compute ssl-certificates create lab-fake-cert --certificate=fake.crt --private-key=fake.key --global
# 2. 获取 Ingress 自动创建的 URL Map 名称与公网 IP
export URL_MAP=$(gcloud compute url-maps list --format="value(name)" --filter="name ~ k8s2-um")
export IP_ADDRESS=$(gcloud compute forwarding-rules list --format="value(IPAddress)" --limit=1)
gcloud compute addresses create payment-static-ip --addresses=$IP_ADDRESS --global
# 3. 创建 HTTPS 目标代理并挂载证书
gcloud compute target-https-proxies create https-proxy \
    --url-map=$URL_MAP \
    --ssl-certificates=lab-fake-cert
# 4. 创建 HTTPS 全局转发规则 (开启 443 端口前端)
gcloud compute forwarding-rules create https-forwarding-rule \
    --global \
    --target-https-proxy=https-proxy \
    --ports=443 \
    --address=$IP_ADDRESS

IAP 开启与 IAM 授权等效命令 (gcloud CLI):

# 1. 获取 GKE Ingress 生成的 Backend Service 名称
export BACKEND_SVC=$(gcloud compute backend-services list --format="value(name)" --filter="name ~ k8s")
# 2. 启用 IAP 身份验证
gcloud compute backend-services update $BACKEND_SVC \
    --global \
    --iap=enabled
# 3. 赋予用户访问权限
gcloud iap web add-iam-policy-binding \
    --resource-type=backend-services \
    --service=$BACKEND_SVC \
    --member="【你的邮箱】" \
    --role="roles/iap.httpsResourceAccessor"

模块 2: 边界安全与 Web 应用防火墙 (Cloud Armor)

1. 业务场景与控制目标

在业务系统的支付系统中，对外暴露的支付网关通常面临着来自全球的 DDoS 攻击以及各类应用层漏洞攻击的威胁。Google Cloud Armor 作为企业级的 Web 应用防火墙 (WAF)，能够有效保护部署在外部应用负载均衡器后方的支付网关，抵御如 SQL 注入和跨站脚本等 OWASP Top 10 漏洞。

此外，针对银行客户主要分布在中东地区的特性，我们将实施地理位置封锁 (Geo-blocking)，拒绝非预期地区的异常流量，以此大幅度降低系统的攻击面。

2. 合规性映射 (Compliance Mapping)

• PCI DSS v4.0 Requirement 6.4: 面向公众的 Web 应用程序必须受到保护，免受基于 Web 的攻击。要求部署自动化技术（如 WAF）来持续检测和防范 Web 应用级别的攻击。
• ISO 27001 Control A.8.20 / A.8.22: 网络安全与 Web 过滤。要求实施网络保护以隔离信息系统，并提供安全机制过滤恶意流量，保护应用层不受外部威胁破坏。

3. Web UI 配置步骤

本章节将带领您通过 Google Cloud 控制台，配置并挂载 Cloud Armor 防护策略。

步骤 3.1: 创建并绑定 Cloud Armor 安全策略

1. 在控制台顶部搜索栏输入 “Cloud Armor”，点击进入 Cloud Armor 政策 页面。
2. 点击页面上方的蓝色按钮 创建政策。
3. Configure policy (配置基础策略):
   • Name: 输入 bank-payment-waf-policy，政策类型选择“后端安全政策”，范围选择“全球”。
   • Default rule action: 选择 Allow。由于这是一个实验环境，我们默认放行流量，然后添加明确的拒绝规则（在零信任生产环境中，最佳实践是默认 Deny，显式 Allow 白名单）。
   • 点击 下一步。
4. 添加更多规则:
   • 规则 A：地理位置封锁 (Geo-blocking) - 仅允许中东地区
     • 点击 添加规则。
     • 模式: 选择 高级模式，然后选择匹配条件编辑器。
     • 匹配: 在输入框中粘贴以下 CEL 表达式（它的意思是：如果请求来源国家代码不是阿联酋，不是沙特阿拉伯且不是卡塔尔，则匹配规则）：
       origin.region_code != 'AE' && origin.region_code != 'SA' && origin.region_code != 'QA'
     • 操作: 选择 拒绝。
     • 响应代码: 选择 403 (已禁止)。
     • 优先级: 输入 1000 (数字越小优先级越高)。
     • 点击 保存对规则的更改。

       [!] 实验提示： 如果您当前正在通过非中东地区的 IP（如香港或欧美）进行实验操作，请将自己的节点地区添加到规则允许的地区中，具体的区域代码可以搜索一下，比如新加坡是“SG”。

   • 规则 B：OWASP SQLi 与 XSS 防护
     • 再次点击 添加规则。
     • 模式: 选择 高级模式。
     • 匹配: 输入以下表达式以启用预配置的 WAF 规则集：
       evaluatePreconfiguredExpr('sqli-v33-stable') || evaluatePreconfiguredExpr('xss-v33-stable')
     • 操作: 选择 拒绝。
     • 响应代码: 选择 403 (已禁止)。
     • Priority: 输入 2000。
     • 点击 保存对规则的更改。
   • 点击 下一步。
5. 将政策应用于目标:
   • 点击 添加目标 按钮。
   • 在“后端服务”中，选择名为k8s-xxxxxx的后端目标。
   • 点击 下一步。
6. 点击 完成，然后点击底部的蓝色按钮 创建政策，应用 Cloud Armor 策略。策略全球下发生效需要约 1-2 分钟。

4. 验证测试 (Validation)

我们将通过模拟黑客攻击来验证边界防护的有效性。

因为我们之前配置了IAP且没有证书，会导致被IAP在网络层面拦截。为了验证 Cloud Armor 的有效性，我们需要先将 IAP 暂时关闭。

1. 在左侧菜单栏中找到“安全”，选择“Identity-Aware Proxy”，在右侧的主页面将“IAP”关掉，然后稍等一段时间。
2. 获取负载均衡器的入口 IP：返回到 负载均衡 页面，点击 k8sxxxxxx。在页面顶部的 前端 区域，复制 IP:Port 栏位中显示的公网 IP 地址。
3. 打开您的本地计算机终端（如 Windows PowerShell 或 macOS/Linux Terminal）或使用 GCP 控制台右上角的 Cloud Shell。
4. 测试正常访问：
   在无痕浏览器中打开：https://<您的负载均衡器IP>
   (预期结果：返回 Hello, world! Version: 1.0.0)
5. 测试 SQL 注入 (SQLi) 攻击被阻断：
   在无痕浏览器中打开（模拟在 URL 参数中植入 SQL 闭合并利用 OR ‘1’=’1’ 恒真式）：
   http://<您的负载均衡器IP>/?id=1'%20OR%20'1'='1"
   (预期结果：返回 403 Forbidden。这表明 Cloud Armor 的 sqli-v33-stable 规则成功识别并拦截了恶意载荷)。
6. 查看审计日志：回到 Cloud Armor 页面，点击进入您创建的 bank-payment-waf-policy。切换到 日志 标签页，点击右侧的 查看政策日志。在日志过滤结果中展开一条日志，您可以清楚地看到 jsonPayload.enforcedSecurityPolicy.outcome 为 "DENY"，以及匹配了哪一条具体的签名集。

5. Quick Catch-up (CLI / Terraform)

如果您希望使用自动化手段快速配置上述功能，可以使用以下 gcloud CLI 命令：

# 创建基础 Cloud Armor 策略
gcloud compute security-policies create bank-payment-waf-policy \
    --description="WAF Policy for Payment Gateway"
# 添加地理封锁规则 (非中东地区拒绝)
gcloud compute security-policies rules create 1000 \
    --security-policy bank-payment-waf-policy \
    --expression "origin.region_code != 'AE' && origin.region_code != 'SA' && origin.region_code != 'QA'" \
    --action "deny-403"
# 添加 SQLi 与 XSS 防护规则
gcloud compute security-policies rules create 2000 \
    --security-policy bank-payment-waf-policy \
    --expression "evaluatePreconfiguredExpr('sqli-v33-stable') || evaluatePreconfiguredExpr('xss-v33-stable')" \
    --action "deny-403"
# 将策略绑定至现有的负载均衡后端服务
export BACKEND_SVC=$(gcloud compute backend-services list --format="value(name)" --filter="name ~ k8s" --limit=1)
gcloud compute backend-services update $BACKEND_SVC \
    --global \
    --security-policy bank-payment-waf-policy

模块 3：数据隐私与机密管理 (Cloud DLP & Secret Manager)

3.1 简介

在支付系统的架构中，保护敏感数据（如数据库密码、API密钥、支付卡信息以及客户的个人可识别信息是重中之重。特别是在中东地区的银行业务中，对于敏感数据的本地化和隐私保护有着严格的要求。本模块将指导您如何使用 Secret Manager 安全地集中存储和管理数据库密码，以及如何利用 Cloud DLP自动扫描并脱敏存储在云端存储桶中的信用卡号等敏感数据。

3.2 合规性映射

• PCI DSS v4.0 核心要求 3 (Protect Stored Account Data)：要求对存储的持卡人数据进行强有力的保护，掩码显示主账号，并安全地管理加密密钥或机密信息。Secret Manager 确保了凭证不会硬编码在源代码中，DLP 则确保了云存储中遗留的或上传的明文 PAN 能够被及时发现并脱敏。
• ISO 27001 (A.8.2.3 资产管理与 A.10.1 加密)：规定了对敏感资产的访问必须进行严格控制，且在存储时要进行适当的加密和脱敏处理。

3.3 实验步骤：使用 Secret Manager 存储数据库密码

在本节中，我们将通过 Google Cloud Console (Web UI) 将一个用于支付数据库连接的敏感密码安全地保存到 Secret Manager 中。

3.3.1 启用 Secret Manager API

1. 登录到 Google Cloud Console。
2. 确保在页面顶部中间的项目下拉菜单中，选择了您 Day 2 实验专用的项目。
3. 在顶部搜索栏中输入 “Secret Manager API” 并按回车。
4. 在搜索结果中点击 Secret Manager API（归类在 API & Services 下）。
5. 如果尚未启用，请点击蓝色的 “启用” (Enable) 按钮。如果显示“已管理”，说明已启用。

3.3.2 创建新的 Secret

1. 在左侧导航菜单中，向下滚动到 “安全” (Security) 部分，点击 “Secret Manager”。
2. 在 Secret Manager 页面顶部，点击带有加号图标的 “+ 创建密钥” (+ CREATE SECRET)” 按钮。
3. 在弹出的 “创建密钥” 页面中，填写以下信息：
   • 名称 (Name): 输入 payment-db-password。
   • 复制政策 (Replication policy): 勾选 手动管理此 Secret 的位置，位置选择me-central1（多哈）。
4. 在 “密钥值” (Secret value) 文本框中，输入您的数据库密码，例如：S3cur3!P@ssw0rd4MEBank。
5. 在加密中，选择“Cloud KMS 密钥”。使用 Day 1 中创建的 KMS 密钥进行加密（CMEK），在这里可能会提示需要授权，点击“授予”然后稍等一下即可。
6. 点击页面底部的蓝色 “创建密钥” (CREATE SECRET) 按钮。
7. 创建成功后，您将被重定向到该密钥的详情页面。您可以点击 “版本” (Versions) 选项卡下的 “查看” (View) 按钮（需要确认权限）来验证刚存储的密码内容。

3.4 实验步骤：使用 Cloud DLP 扫描并脱敏敏感数据

在本节中，我们将使用 Sensitive Data Protection (原 Cloud DLP) 来扫描一个包含中东地区信用卡交易样本记录的 Cloud Storage 存储桶，配置一个检测作业，将敏感数据（特别是 PAN 和个人姓名）检测出来并进行脱敏处理。

3.4.1 准备测试数据和存储桶

1. 在 Console 顶部搜索栏中搜索 “Cloud Storage” 并点击进入 存储桶 页面。
2. 点击 “+ 创建” (+ CREATE) 按钮创建一个新的存储桶。
   • 名称: me-bank-dlp-sample-data-<您的项目号>（名称必须全局唯一），点击“继续”。
   • 位置类型: 选择 “Region”，然后选择 me-central1。
   • 保留其余默认设置，点击底部 “创建” (CREATE)。
3. 在本地计算机上创建一个名为 sample_transactions.csv 的文件，填入以下虚拟数据（包含虚拟的中东人名和信用卡号）：

   TransactionID,CustomerName,CreditCardNumber,Amount
   1001,Ahmed Al-Farsi,4242-4242-4242-4242,150.00
   1002,Fatima Zahra,5105-1051-0510-5100,320.50
   1003,Omar Saeed,6011-1111-1111-1117,75.00

4. 在您新建的存储桶页面中，点击 “上传文件” (UPLOAD FILES)，将 sample_transactions.csv 上传到该存储桶中。
5. 再次在存储桶页面点击 “+ 创建”，创建另一个存储桶用于存放 DLP 的脱敏输出结果，命名为 me-bank-dlp-output-<您的项目号>。

3.4.2 创建去标识化模板 (De-identification Template)

由于我们需要对信用卡号进行特定的掩码处理（保留后4位，其余用 * 替换），我们需要先创建一个脱敏模板。

1. 在 Console 导航菜单中，滚动到 “安全” (Security)，点击 “敏感数据保护” (Sensitive Data Protection)。
2. 在左侧菜单中（或上方导航栏），找到并点击 “配置” (Configuration)，然后选择 “模板” (Templates)。
3. 点击页面顶部的 + 创建模板 (+ CREATE TEMPLATE) 按钮。
4. 第 1步：指定模板类型和基本信息
   • 数据转换类型: 选择 “InfoType”。
   • 模板 ID: 输入 cc-masking-template。
   • 模板类型: 选择 “去标识化” (De-identification)。
   • 位置类型: 选择 “区域” (Region)，然后选择 me-central1。
   • 点击 继续 (CONTINUE)。
5. 第 2步：配置去标识化步骤
   • 点击 + 添加转换规则。
   • 在弹出的配置框中：
     • 转换: 选择 使用字符遮盖。
     • 掩码字符: 输入 *。
     • 要忽略的字符: 选择 指定要忽略的字符并输入-。
     • 要遮盖的字符数: 输入 12 以显示出最后的4位。
     • 要转换的 InfoType: 选择指定 InfoType并点击管理InfoType。在弹窗内搜索并添加CREDIT_CARD_NUMBER。
6. 点击底部的 创建 (CREATE)。
7. 获取模板ID：创建成功后，在cc-masking-template下方会显示ID。将ID复制下来（例子：projects/day2-test2/locations/me-central1/deidentifyTemplates/cc-masking-template），后续步骤会用到。

3.4.3 创建并运行 DLP 检查与脱敏作业

1. 返回主页，在顶部菜单中选择 检查，点击页面顶部的 + 创建作业和作业触发器 按钮。
2. 第 1 步：选择输入数据 (Choose input data)
   • 作业 ID (Job ID): 输入 cc-masking-job。
   • 位置类型: 选择“区域”，选择 me-central1。
   • 存储类型 (Storage type): 选择 “Google Cloud Storage”，位置类型选择“使用可选的包含/排除规则扫描存储桶”，然后点击存储桶名称后方的“浏览”并选择我们之前上传文件的存储桶。（me-bank-dlp-sample-data-xxxxx）。
   • 文件类型：选择 csv。
   • 点击 “继续” (CONTINUE)。
3. 第 2 步：配置检测 (Configure detection)
   • 点击 “管理 InfoType” (Manage InfoTypes)，确保搜索并单选 CREDIT_CARD_NUMBER。
   • 点击 “继续” (CONTINUE)。
4. 第 3 步：添加操作 (Add actions)
   • 开启 “制作去标识化副本” (Make a de-identified copy) 的开关。
   • “去标识化模板”输入刚才记下的ID。
   • Cloud Storage 输出位置：输入 gs://me-bank-dlp-output-xxxxxx。
   • 文件类型：选择 csv。
   • 点击 “继续” (CONTINUE)。
5. 第 4 步：时间安排
   • 保留默认的 “无 (在创建后立即运行一次性作业)”。
   • 点击 “继续” (CONTINUE)。
6. 第 5 步：查看并创建
   • 点击蓝色的 “创建” (CREATE) 按钮。

3.5 验证步骤

1. 验证作业摘要：
   在 DLP 作业详情页面，可以看到 DLP 成功识别出了 CREDIT_CARD_NUMBER的具体匹配次数。
2. 验证脱敏后的数据：
   • 在顶部搜索栏重新进入 “Cloud Storage”，打开您的输出存储桶 me-bank-dlp-output-<您的项目号>。
   • 您会发现 DLP 在这里创建了相应的目录结构和输出文件。
   • 点击输出的 CSV 文件名称，然后点击 “下载” (DOWNLOAD) 。
   • 打开文件，您应该看到类似以下的输出：

     TransactionID,CustomerName,CreditCardNumber,Amount
     1001,Ahmed Al-Farsi,****-****-****-4242,150.00
     1002,Fatima Zahra,****-****-****-5100,320.50
     1003,Omar Saeed,****-****-****-1117,75.00

   • 验证结论：成功证明 PCI DSS 合规要求得到满足，敏感主账号 (PAN) 被安全屏蔽和去标识化。

3.6 快速追赶 (Quick Catch-up) / CLI & Terraform 等效命令

如果您希望跳过 UI 步骤并使用命令行自动完成上述核心操作，请使用 Cloud Shell 运行以下命令：

Secret Manager CLI

# 创建 Secret
gcloud secrets create payment-db-password \
    --replication-policy="automatic"
# 添加 Secret 版本（即实际的密码值）
echo -n 'S3cur3!P@ssw0rd4MEBank' | gcloud secrets versions add payment-db-password \
    --data-file=-
# 验证
gcloud secrets versions access latest --secret="payment-db-password"

Cloud DLP Terraform 示例

(注：以下为创建 DLP 去标识化掩码模板以及触发 GCS 存储桶脱敏作业的核心 Terraform 资源示例)

data "google_project" "current" {}
resource "random_id" "bucket_suffix" {
  byte_length = 4
}
resource "google_storage_bucket" "sample_data" {
  name                        = "me-bank-dlp-sample-data-${random_id.bucket_suffix.hex}"
  location                    = "me-central1"
  uniform_bucket_level_access = true
  force_destroy               = true # 方便实验后一键销毁
}
resource "google_storage_bucket" "dlp_output" {
  name                        = "me-bank-dlp-output-${random_id.bucket_suffix.hex}"
  location                    = "me-central1"
  uniform_bucket_level_access = true
  force_destroy               = true
}
# 1. 创建去标识化模板
resource "google_data_loss_prevention_deidentify_template" "cc_masking" {
  parent       = "projects/${data.google_project.current.project_id}/locations/me-central1"
  description  = "Mask credit card numbers leaving last 4 digits"
  display_name = "cc-masking-template"
  deidentify_config {
    info_type_transformations {
      transformations {
        info_types {
          name = "CREDIT_CARD_NUMBER"
        }
        primitive_transformation {
          character_mask_config {
            masking_character = "*"
            number_to_mask    = 12
            reverse_order     = false
            characters_to_ignore {
              characters_to_skip = "-"
            }
          }
        }
      }
    }
  }
}
# 2. 创建 DLP 检查与脱敏作业触发器
resource "google_data_loss_prevention_job_trigger" "cc_masking_trigger" {
  parent       = "projects/${data.google_project.current.project_id}/locations/me-central1"
  description  = "Scan GCS bucket for credit card data and mask them into output bucket"
  display_name = "cc-masking-job"
  triggers {
    schedule {
      recurrence_period_duration = "2592000s"
    }
  }
  inspect_job {
    inspect_config {
      info_types {
        name = "CREDIT_CARD_NUMBER"
      }
    }
    # 执行操作：制作去标识化副本并输出到 GCS
    actions {
      deidentify {
        cloud_storage_output    = "gs://${google_storage_bucket.dlp_output.name}/"
        file_types_to_transform = ["CSV"]
        transformation_config {
          deidentify_template = google_data_loss_prevention_deidentify_template.cc_masking.id
        }
      }
    }
    # 扫描目标：输入存储桶
    storage_config {
      cloud_storage_options {
        file_set {
          url = "gs://${google_storage_bucket.sample_data.name}/*"
        }
      }
    }
  }
}

gcloud services enable dlp.googleapis.com
terraform init
terraform apply -auto-approve

模块 4: 零信任数据边界 (VPC Service Controls)

1. 业务场景与控制目标

传统的网络防火墙能够限制 IP 层面的访问，但在云原生环境中，核心系统会频繁调用 Cloud Storage 和 Secret Manager 等 PaaS 服务。如果开发人员不慎赋予了过宽的 IAM 权限，外部攻击者甚至内部恶意员工只需拿着合法的凭证，就可以从任何公网环境（如家中的电脑或未授权的外部服务器）直接拉取受保护的云上数据。
为了防范这种数据外发风险，业务系统通常会采用 VPC Service Controls (VPC-SC)。通过在指定的受保护项目外部“画一个圈”，即使拥有最高 IAM 权限的管理员，只要网络环境不在受信任的 VPC 或指定的访问级别内，对这些敏感 PaaS API 的请求也会被底层组织策略直接阻断。

2. 合规性映射 (Compliance Mapping)

• PCI DSS v4.0 Requirement 1.2 & 1.3: 保护持卡人数据环境 (CDE) 的网络控制。VPC-SC 提供了一种与传统子网隔离并驾齐驱的微隔离手段，严格限制了对存储持卡人数据的云原生存储资源的直接公网访问。
• ISO 27001 Control A.8.20 & A.8.24: 强调了网络层面的安全隔离及利用加密机制来保护机密信息资产。VPC-SC 从网络层面收敛了 API 的攻击与暴露面。

3. Web UI 配置步骤

💡 实验说明：由于我们身处共享的培训环境中，本实验将使用 项目级范围化政策 (Project-scoped Policies) 来配置 VPC-SC，确保学员之间的策略互不干扰。

步骤 3.1: 提前准备测试存储桶

由于边界生效后会立即阻断所有未授权访问，我们需要先创建好存储桶以便后续观察拦截效果。

1. 在控制台顶部搜索栏输入 Cloud Storage，进入 Buckets 页面。
2. 点击 + CREATE 创建一个新的存储桶，命名为 bank-payment-cde-<您的姓名缩写>（需全局唯一）。
3. 区域选择 me-central1，其余保持默认，点击 Create 完成创建。

步骤 3.2: 创建项目级 VPC Service Controls 边界

1. 在控制台顶部搜索栏输入 “VPC Service Controls”，点击安全类别下的 VPC Service Controls 进入。
2. 选择组织 确保页面左上角的资源选择器指向的是您的 组织 (Organization)，而不是项目 (Project)。
3. 点击页面中间的 管理权限访问政策 蓝色按钮，然后在顶上点击 创建。
4. 在新建向导页面，依次进行如下配置：
   • 访问权限政策标题: 输入 xxxx-Policy。
   • 选择要纳入政策的资源: 点击 添加项目，然后选择自己的项目。
   • 完成配置: 点击页面下方的 创建访问权限政策。
5. 选择项目 返回VPC-SC主页，然后将资源选择器更换为您的 项目 (Project)。
6. 创建边界详情 点击页面上方的 新建边界。
   • 标题: 输入 xxxx-Policy-1。
   • 边界类型: 选择 定期。
   • 实施模式: 选择 已实施。
7. 设置要保护的资源 点击 继续。
   • 项目: 点击添加项目，然后选择你的项目。
   • VPC网络: 点击添加项目，选择你的项目，然后选择secure-vpc并点击添加所选网络。
8. 受限服务:
   • 点击页面中的 添加服务。
   • 在搜索框中搜索并勾选 Cloud Storage API (storage.googleapis.com)，点击 继续。
9. 剩余配置项：直接保持默认即可，完成后点击底部“创建”。

4. 验证测试 (Validation)

我们将通过“先被拦截、后配置放行”的过程，验证 VPC-SC 零信任数据边界的威力。

阶段 A：验证 VPC-SC 的强制拦截 (The Block)

1. 点击控制台右上角的 Activate Cloud Shell 图标（ >_ ）打开网页终端。
2. 等待一段时间，执行以下命令尝试列出您刚刚创建的存储桶内容：
   gcloud storage ls gs://bank-payment-cde-<您的姓名缩写>
3. 检查拦截结果：
   您应当会看到一行红色的错误输出，核心内容类似于：
   ERROR: (gcloud.storage.ls) [账号] does not have permission to access b instance [桶名称] (or it may not exist): Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: xxxx. This command is authenticated as 账号 which is the active account specified by the [core/account] property
   这就证明了，尽管您的账户拥有 Project Owner 级别的完全权限，但由于零信任网络边界的拦截，外部环境的数据访问被成功识别并拒绝。

阶段 B：配置基于身份的入站放行规则

为了让我们自己能够合法管理数据，我们需要在边界上开一个入站规则，仅允许我们当前的员工账号访问。

1. 回到 VPC Service Controls 页面，点击您刚才创建的边界名称 (xxxx-Policy-1) ，然后点击页面上方的修改。
2. 点击左侧导航栏的 入站流量政策。
3. 点击 添加入站流量规则，这里谷歌有个机翻错误，“开始日期”其实是“From（请求来源）”，“结束日期”其实是“To（访问目标）”。
4. 在弹出的规则配置表单中：
   • 开始日期（请求来源）:
     • 身份: 选择 选择身份和群组，点击 添加身份，在输入框中填入您当前登录 GCP 控制台的实验账号邮箱。
     • 来源: 选择 所有来源（因为我们在内网，不固定外部 IP），然后点击 保存。
   • 结束日期（访问目标）:
     • 项目: 选择 所有项目（适用于边界内的项目）。
     • 操作或 IAM 角色: 选择 选择操作，点击添加操作，勾选 Cloud Storage API后点击添加所有方法，然后点击完成。
5. 点击底部的 保存 保存边界更新。(请耐心等待 1-2 分钟让策略在全球节点生效)。

阶段 C：验证访问恢复

1. 再次回到 Cloud Shell，按下键盘的 向上方向键，重新执行刚才的查看命令：
   gcloud storage ls gs://bank-payment-cde-<您的姓名缩写>
2. 这次，命令将顺利执行，不会再出现任何错误（如果桶是空的，将直接返回空行）。您已成功实现了基于用户身份和上下文的微隔离！

4.5. Quick Catch-up (CLI / Terraform)

如果您希望使用基础设施即代码 (IaC) 或自动化脚本快速重现本章节的配置，以下是针对项目级范围化访问政策 的等效实现参考：

选项 A：使用 gcloud CLI 命令

# 1. 环境变量准备 (请替换为您的实际值)
export PROJECT_ID="您的项目ID"
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")
export USER_EMAIL="您当前登录的实验账号邮箱"
export ORG_ID=$(gcloud organizations list --format="value(ID)" | head -n 1)
gcloud access-context-manager policies create \
  --organization=$ORG_ID \
  --scopes="projects/$PROJECT_NUMBER" \
  --title="xxxx-Policy"
POLICY_ID=$(gcloud access-context-manager policies list \
  --organization=$ORG_ID \
  --format="value(name)" \
  --filter="title:xxxx-Policy")
# 创建入站规则的 YAML 配置文件 (ingress.yaml)
cat <<EOF > ingress.yaml
- ingressFrom:
    identities:
    - user:$USER_EMAIL
    sources:
    - accessLevel: "*"
  ingressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: "*"
    resources:
    - "*"
EOF
# 创建 VPC-SC 边界，应用资源、受限服务及入站规则
gcloud access-context-manager perimeters create xxxx_Policy_1 \
  --title="xxxx-Policy-1" \
  --resources="projects/$PROJECT_NUMBER" \
  --restricted-services="storage.googleapis.com" \
  --ingress-policies=ingress.yaml \
  --policy=$POLICY_ID
# 使用 update 命令，将安全 VPC 网络绑定到该边界中
gcloud access-context-manager perimeters update xxxx_Policy_1 \
  --policy=$POLICY_ID \
  --add-resources="//compute.googleapis.com/projects/$PROJECT_ID/global/networks/secure-vpc"

选项 B：使用 Terraform (IaC 最佳实践)

# 1. 声明由外部自动注入的变量
variable "org_id" {
  description = "GCP Organization ID"
  type        = string
}
# 2. 自动获取当前项目的上下文信息
data "google_project" "current" {}
# 3. 创建项目级范围化访问政策
resource "google_access_context_manager_access_policy" "scoped_policy" {
  parent = "organizations/${var.org_id}"
  title  = "xxxx-Policy2"
  scopes = ["projects/${data.google_project.current.number}"]
}
# 4. 创建边界、绑定 VPC 网络并配置身份级入站白名单
resource "google_access_context_manager_service_perimeter" "project_perimeter" {
  parent         = "accessPolicies/${google_access_context_manager_access_policy.scoped_policy.name}"
  name           = "accessPolicies/${google_access_context_manager_access_policy.scoped_policy.name}/servicePerimeters/xxxx_Policy_1"
  title          = "xxxx-Policy-2"
  perimeter_type = "PERIMETER_TYPE_REGULAR"
  status {
    # 保护项目资源，并将 VPC 网络作为资源直接加入边界
    resources = [
      "projects/${data.google_project.current.number}",
      "//compute.googleapis.com/projects/${data.google_project.current.project_id}/global/networks/secure-vpc"
    ]
    # 限制的 PaaS 服务
    restricted_services = ["storage.googleapis.com"]
    # 配置入站放行规则 (Ingress Rule)
    ingress_policies {
      ingress_from {
        identities = ["user:【实际的邮箱】"]
        sources {
          access_level = "*" # 匹配所有来源
        }
      }
      ingress_to {
        resources = ["*"]
        operations {
          service_name = "storage.googleapis.com"
          method_selectors {
            method = "*"
          }
        }
      }
    }
  }
}

# 1. 确保环境变量已加载
export TF_VAR_org_id=$(gcloud organizations list --format="value(ID)" | head -n 1)
# 2. 动态获取之前创建的 Policy 的真实 ID
POLICY_NAME=$(gcloud access-context-manager policies list \
  --organization=$TF_VAR_org_id \
  --format="value(name)" \
  --filter="title:xxxx-Policy")
# 3. 先删除 VPC-SC 边界
gcloud access-context-manager perimeters delete xxxx_Policy_1 \
  --policy=$POLICY_NAME --quiet
# 4. 再删除访问策略 (Policy)
gcloud access-context-manager policies delete $POLICY_NAME --quiet
# 5. 创建
terraform init
terraform apply -auto-approve

第五部分：常态化安全运营与威胁响应 (SCC)

5.1 实验背景与合规映射

在安全架构搭建完成后，常态化的安全运营是保障合规的生命线。针对业务系统的支付系统，每天都会产生大量的配置变更和网络流量，任何细微的错误配置都可能导致严重的数据泄露。

合规要求映射：

• PCI DSS v4.0 Requirement 10 & 11：要求记录和监控所有访问，并定期测试系统和网络的安全性。要求能够迅速识别并响应异常行为。
• ISO 27001 (A.16 Information security incident management)：要求建立持续、有效的流程来管理信息安全事件。

本节我们将使用 Security Command Center (SCC) 这一 GCP 的原生云态势感知中心。我们将通过 Web 界面模拟制造一个安全漏洞，并在 SCC 中捕获、分析并修复该漏洞，完成一次完整的安全运营闭环。在此之前，我们首先要为项目开启SCC：

1. 在控制台左上角，选择我们今天创建的项目。
2. 在上方搜索栏中，输入 Security Command Center 并进入。
3. 选择计费层级：在真实的合规审计中，通常需要使用 Premium（高级版），但为了本次实验不产生额外费用，请选择 获取标准版 并点击激活。

5.2 模拟安全漏洞：将敏感存储桶设为公开

为了让 SCC 捕捉到真实的告警（Finding），我们先故意“制造”一个安全漏洞。

1. 在 GCP 控制台顶部搜索栏输入 Cloud Storage，然后点击进入 Cloud Storage > Buckets（存储桶）。
2. 找到您在之前创建的任意一个存储桶（或者新建一个测试桶）。
3. 点击存储桶名称进入详情页，然后点击 Permissions（权限） 标签页。
4. 点击 允许公开访问 按钮。
5. 点击“授予访问权限”，新的主账号填写 allUsers，角色选择 Storage Object Viewer。
6. 点击 SAVE（保存）。系统可能会弹出一个警告对话框，提示您这是公开访问权限，请点击 ALLOW PUBLIC ACCESS（允许公开访问） 强行放行。

5.3 在 Security Command Center 中调查与响应

SCC 会在后台持续扫描您的资源配置。漏洞制造完成后，可能需要等待 10-15 分钟，扫描器才能生成并展示告警（取决于扫描周期的触发机制）。

1. 在控制台左上角导航菜单，选择 Security（安全） -> Security Command Center -> Overview（概览）。
2. 在概览面板中，您可以看到当前的整体安全态势，包括按严重程度划分的各类漏洞。
3. 点击左侧菜单的 发现结果。
4. 在右侧列表中，您应该能看到一条关于刚才那个存储桶的告警。点击告警标题进入详细分析页。
5. 分析告警（Investigate）：
   • 在详情页中，重点查看 后续步骤。SCC 通常会直接提供指导，告诉安全工程师如何修复此漏洞。
   • 查看 受影响的资源 确认是哪个具体的存储桶被不当配置了。
6. 修复漏洞（Remediate）：
   • 根据后续步骤中的指引，我们可以通过网页配置或者直接在Cloud Shell中运行命令，把存储桶设置回去。
7. 验证修复并静默告警：
   • 回到 SCC 的 发现结果 页面。
   • 勾选刚才的那条告警。
   • 在列表上方的操作栏中，点击 忽略选项，并选择 应用忽略覆盖。虽然我们已经物理修复了漏洞，但 SCC 下一次扫描还未发生，手动 忽略可以向团队表明“此告警已处理”。

5.4 CLI 快速进阶方式

如果您希望通过命令行快速完成上述操作：

# 模拟漏洞 1：关闭存储桶的“公开访问权限预防”
gcloud storage buckets update gs://[实际桶名称] \
    --no-public-access-prevention
# 模拟漏洞 2：授予 allUsers 读取权限，正式将存储桶公开
gcloud storage buckets add-iam-policy-binding gs://[实际桶名称] \
    --member="allUsers" \
    --role="roles/storage.objectViewer"
# (等待 SCC 扫描出告警并进行调查后...)
# 修复漏洞 1：移除公开权限
gcloud storage buckets remove-iam-policy-binding gs://[实际桶名称] \
    --member="allUsers" \
    --role="roles/storage.objectViewer"
# 修复漏洞 2：重新开启“公开访问权限预防”
gcloud storage buckets update gs://[实际桶名称] \
    --public-access-prevention

第六部分：实验环境清理

强烈建议：实验完成后务必清理资源以避免不必要的费用产生！

在 Day 2 的实验中，我们创建了诸多高价值的资源，包括 GKE 集群、外部负载均衡、Cloud Armor 以及可能的数据库或 KMS 密钥。

由于我们在 Day 1 / Day 2 的基线中启用了 WORM（不可篡改）存储桶锁定，单向删除部分资源可能会遇到权限拒绝的报错。因此，清理环境最干净、最彻底的方法是直接删除整个 GCP Project。

6.1 删除沙盒资源与项目 (CLI 方式)

请在 Cloud Shell 中执行以下命令，完成最终的资源清理：

# 请将以下变量替换为您在 Day 2 实验中实际使用的 Project ID
export TARGET_PROJECT="您的项目ID"
# 1. 解除项目上可能存在的留置权（Lien）。
# 在开启了某些安全服务（如 VPC-SC 或高级计费）时，GCP 可能会对项目添加 Lien 以防止意外删除。
# 获取 Lien 名称：
gcloud alpha resource-manager liens list --project=$TARGET_PROJECT
# 删除 Lien (请替换下方命令中的 LIEN_NAME)：
# gcloud alpha resource-manager liens delete [LIEN_NAME]
# 2. 强制删除项目
# 这会将项目标记为待删除，项目内部的所有计费将立刻停止，包括那些被 WORM 策略锁定的存储桶。
gcloud projects delete $TARGET_PROJECT
# 3. 退出项目上下文
gcloud config unset project
# 4. （可选）如果您不再需要用于隔离的沙盒文件夹，可以将其删除。
# 注意：只有当文件夹内的所有项目都被标记为删除后，才能删除该文件夹。
export FOLDER_ID="您的沙盒文件夹ID"
gcloud resource-manager folders delete $FOLDER_ID

注：项目被执行删除命令后，会进入 30 天的待删除状态，这期间您无法使用该项目的名字，但所有资源已停止计费。30 天后，项目及其内含数据将被 GCP 物理销毁，不可恢复。

至此，Day 2 的云安全合规工程实验全部结束！感谢您的参与！