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

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

1. 业务背景：支付系统

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

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 终端内，运行以下命令创建工作目录：
    1. mkdir ~/day1-baseline && cd ~/day1-baseline
    2. # 开启必要的API
    3. gcloud services enable cloudresourcemanager.googleapis.com serviceusage.googleapis.com compute.googleapis.com cloudkms.googleapis.com --project=【你的项目ID】
  5. 创建 main.tf 文件：
    1. nano main.tf
  6. 将以下 Terraform 代码粘贴到文件中（按 Ctrl+O，Enter 保存，然后按 Ctrl+X 退出）：
  1. terraform {
  2.   required_providers {
  3.     google = {
  4.       source  = "hashicorp/google"
  5.       version = "~> 5.0"
  6.     }
  7.   }
  8. }
  10. provider "google" {
  11.   # 注意：在 Cloud Shell 中运行时，环境会自动继承您当前的项目 ID
  12.   region  = "me-central1"
  13. }
  15. # 1. 创建安全的自定义 VPC
  16. resource "google_compute_network" "secure_vpc" {
  17.   name                    = "secure-vpc"
  18.   auto_create_subnetworks = false
  19. }
  21. # 2. 创建子网并开启全量流日志 (VPC Flow Logs)
  22. resource "google_compute_subnetwork" "secure_subnet" {
  23.   name          = "secure-payment-subnet"
  24.   ip_cidr_range = "10.0.1.0/24"
  25.   region        = "me-central1"
  26.   network       = google_compute_network.secure_vpc.id
  28.   # 开启私有 Google 访问
  29.   private_ip_google_access = true
  31.   # 开启流日志以满足审计要求
  32.   log_config {
  33.     aggregation_interval = "INTERVAL_5_SEC"
  34.     flow_sampling        = 1.0
  35.     metadata             = "INCLUDE_ALL_METADATA"
  36.   }
  37. }
  39. # 3. IAP 安全防火墙规则 (仅允许 IAP 的 IP 范围 35.235.240.0/20 进行管理访问)
  40. resource "google_compute_firewall" "allow_iap" {
  41.   name    = "allow-iap-proxy"
  42.   network = google_compute_network.secure_vpc.id
  44.   allow {
  45.     protocol = "tcp"
  46.     ports    = ["22", "3389"]
  47.   }
  48.   source_ranges = ["35.235.240.0/20"]
  49. }
  51. # 4. 创建 KMS Keyring 与 CryptoKey用于后续数据加密 (CMEK)
  52. resource "random_id" "suffix" {
  53.   byte_length = 4
  54. }
  56. resource "google_kms_key_ring" "payment_keyring" {
  57.   name     = "payment-keyring-${random_id.suffix.hex}"
  58.   location = "me-central1"
  59. }
  61. resource "google_kms_crypto_key" "payment_key" {
  62.   name            = "payment-cmek-key"
  63.   key_ring        = google_kms_key_ring.payment_keyring.id
  64.   rotation_period = "7776000s" # 90天自动轮转
  65. }
  67. # 5. 创建 WORM 审计日志存储桶
  68. resource "google_storage_bucket" "audit_bucket" {
  69.   name                        = "me-bank-audit-logs-${random_id.suffix.hex}"
  70.   location                    = "me-central1"
  71.   uniform_bucket_level_access = true
  73.   # 开启保留策略 (WORM) 防止篡改，实验设置1天，实际可能为5年
  74.   retention_policy {
  75.     retention_period = 86400 
  76.     is_locked        = false # 实验环境中不锁定，以免无法删除
  77.   }
  78. }
  1. 依次运行以下命令完成基线部署：
    1. terraform init
    2. 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)

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

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 (集群基本信息)：
  6. 网络隔离配置：
  7. 配置节点规格：
  8. 在页面底部的蓝色按钮点击 CREATE (创建)。
    (注意：GKE 集群配置大约需要 5-10 分钟时间。请耐心等待，直到集群名称旁边出现绿色的对勾符号。)

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

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

  1. 在左侧菜单中（仍在 Kubernetes Engine 界面），点击 Workloads (工作负载)。
  2. 在中间点击 创建部署 按钮。
  3. 部署配置 页面：
  4. 在新页面中：
  5. 暴露应用服务：
  6. 创建 Ingress：
  7. 验证

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

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

  1. 展开左上角 导航菜单 (Navigation menu)。
  2. 滚动到 Security (安全)，然后点击 Identity-Aware Proxy。
  3. 点击“启用API”，成功后点击“转到 Identity-Aware Proxy”。
  4. 在 Identity-Aware Proxy 页面，您会看到一个名为 Resources 的表格。
  5. 配置访问权限控制 (IAM)：

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

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

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

  1. 打开 cloudshell，生成并上传一个自签名的证书：
    1. openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout fake.key -out fake.crt -subj "/CN=【你的http IP地址】"
    2. 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，执行以下命令：
    1. curl -k -I https://【你的https地址】
  2. 查看返回的信息，你应该会得到类似的信息：
    1. HTTP/2 401
    2. content-length: 120
    3. content-type: text/html; charset=UTF-8
    4. x-goog-iap-generated-response: true
    5. date: Tue, 09 Jun 2026 09:51:34 GMT
    6. alt-svc: h3=":443"; ma=2592000

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

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

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

  1. gcloud services enable container.googleapis.com --project=【项目名称】
  2. cd ..; mkdir 1.5; cd 1.5; nano main.tf
  1. resource "google_container_cluster" "private_gke" {
  2.   name     = "payment-frontend-cluster"
  3.   location = "me-central1-a"
  4.   network  = "secure-vpc"
  5.   subnetwork = "secure-payment-subnet"
  7.   initial_node_count = 1
  8.   deletion_protection = false
  10.   private_cluster_config {
  11.     enable_private_nodes    = true
  12.     enable_private_endpoint = false
  13.     master_ipv4_cidr_block  = "172.16.0.0/28"
  14.   }
  16.   node_config {
  17.     machine_type = "e2-micro"
  18.   }
  19. }

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

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

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

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

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

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

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

1. 业务场景与控制目标

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

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

2. 合规性映射 (Compliance Mapping)

3. Web UI 配置步骤

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

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

  1. 在控制台顶部搜索栏输入 “Cloud Armor”，点击进入 Cloud Armor 政策 页面。
  2. 点击页面上方的蓝色按钮 创建政策。
  3. Configure policy (配置基础策略):
  4. 添加更多规则:
  5. 将政策应用于目标:
  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 命令：

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

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

3.1 简介

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

3.2 合规性映射

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. 在弹出的 “创建密钥” 页面中，填写以下信息：
  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) 按钮创建一个新的存储桶。
  3. 在本地计算机上创建一个名为 sample_transactions.csv 的文件，填入以下虚拟数据（包含虚拟的中东人名和信用卡号）：
    1. TransactionID,CustomerName,CreditCardNumber,Amount
    2. 1001,Ahmed Al-Farsi,4242-4242-4242-4242,150.00
    3. 1002,Fatima Zahra,5105-1051-0510-5100,320.50
    4. 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步：指定模板类型和基本信息
  5. 第 2步：配置去标识化步骤
  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)
  3. 第 2 步：配置检测 (Configure detection)
  4. 第 3 步：添加操作 (Add actions)
  5. 第 4 步：时间安排
  6. 第 5 步：查看并创建

3.5 验证步骤

  1. 验证作业摘要：
    在 DLP 作业详情页面，可以看到 DLP 成功识别出了 CREDIT_CARD_NUMBER的具体匹配次数。
  2. 验证脱敏后的数据：

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

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

Secret Manager CLI

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

Cloud DLP Terraform 示例

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

  1. data "google_project" "current" {}
  3. resource "random_id" "bucket_suffix" {
  4.   byte_length = 4
  5. }
  7. resource "google_storage_bucket" "sample_data" {
  8.   name                        = "me-bank-dlp-sample-data-${random_id.bucket_suffix.hex}"
  9.   location                    = "me-central1"
  10.   uniform_bucket_level_access = true
  11.   force_destroy               = true # 方便实验后一键销毁
  12. }
  14. resource "google_storage_bucket" "dlp_output" {
  15.   name                        = "me-bank-dlp-output-${random_id.bucket_suffix.hex}"
  16.   location                    = "me-central1"
  17.   uniform_bucket_level_access = true
  18.   force_destroy               = true
  19. }
  22. # 1. 创建去标识化模板
  23. resource "google_data_loss_prevention_deidentify_template" "cc_masking" {
  24.   parent       = "projects/${data.google_project.current.project_id}/locations/me-central1"
  25.   description  = "Mask credit card numbers leaving last 4 digits"
  26.   display_name = "cc-masking-template"
  28.   deidentify_config {
  29.     info_type_transformations {
  30.       transformations {
  31.         info_types {
  32.           name = "CREDIT_CARD_NUMBER"
  33.         }
  34.         primitive_transformation {
  35.           character_mask_config {
  36.             masking_character = "*"
  37.             number_to_mask    = 12
  38.             reverse_order     = false
  39.             characters_to_ignore {
  40.               characters_to_skip = "-"
  41.             }
  42.           }
  43.         }
  44.       }
  45.     }
  46.   }
  47. }
  49. # 2. 创建 DLP 检查与脱敏作业触发器
  50. resource "google_data_loss_prevention_job_trigger" "cc_masking_trigger" {
  51.   parent       = "projects/${data.google_project.current.project_id}/locations/me-central1"
  52.   description  = "Scan GCS bucket for credit card data and mask them into output bucket"
  53.   display_name = "cc-masking-job"
  55.   triggers {
  56.     schedule {
  57.       recurrence_period_duration = "2592000s"
  58.     }
  59.   }
  61.   inspect_job {
  62.     inspect_config {
  63.       info_types {
  64.         name = "CREDIT_CARD_NUMBER"
  65.       }
  66.     }
  68.     # 执行操作：制作去标识化副本并输出到 GCS
  69.     actions {
  70.       deidentify {
  71.         cloud_storage_output    = "gs://${google_storage_bucket.dlp_output.name}/"
  72.         file_types_to_transform = ["CSV"]
  73.         transformation_config {
  74.           deidentify_template = google_data_loss_prevention_deidentify_template.cc_masking.id
  75.         }
  76.       }
  77.     }
  79.     # 扫描目标：输入存储桶
  80.     storage_config {
  81.       cloud_storage_options {
  82.         file_set {
  83.           url = "gs://${google_storage_bucket.sample_data.name}/*"
  84.         }
  85.       }
  86.     }
  87.   }
  88. }
  1. gcloud services enable dlp.googleapis.com
  2. terraform init
  3. 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)

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. 在新建向导页面，依次进行如下配置：
  5. 选择项目 返回VPC-SC主页，然后将资源选择器更换为您的 项目 (Project)。
  6. 创建边界详情 点击页面上方的 新建边界。
  7. 设置要保护的资源 点击 继续。
  8. 受限服务:
  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. 在弹出的规则配置表单中：
  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. # 1. 环境变量准备 (请替换为您的实际值)
  2. export PROJECT_ID="您的项目ID"
  3. export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")
  4. export USER_EMAIL="您当前登录的实验账号邮箱"
  5. export ORG_ID=$(gcloud organizations list --format="value(ID)" | head -n 1)
  7. gcloud access-context-manager policies create \
  8.   --organization=$ORG_ID \
  9.   --scopes="projects/$PROJECT_NUMBER" \
  10.   --title="xxxx-Policy"
  12. POLICY_ID=$(gcloud access-context-manager policies list \
  13.   --organization=$ORG_ID \
  14.   --format="value(name)" \
  15.   --filter="title:xxxx-Policy")
  17. # 创建入站规则的 YAML 配置文件 (ingress.yaml)
  18. cat <<EOF > ingress.yaml
  19. - ingressFrom:
  20.     identities:
  21.     - user:$USER_EMAIL
  22.     sources:
  23.     - accessLevel: "*"
  24.   ingressTo:
  25.     operations:
  26.     - serviceName: storage.googleapis.com
  27.       methodSelectors:
  28.       - method: "*"
  29.     resources:
  30.     - "*"
  31. EOF
  33. # 创建 VPC-SC 边界，应用资源、受限服务及入站规则
  34. gcloud access-context-manager perimeters create xxxx_Policy_1 \
  35.   --title="xxxx-Policy-1" \
  36.   --resources="projects/$PROJECT_NUMBER" \
  37.   --restricted-services="storage.googleapis.com" \
  38.   --ingress-policies=ingress.yaml \
  39.   --policy=$POLICY_ID
  41. # 使用 update 命令，将安全 VPC 网络绑定到该边界中
  42. gcloud access-context-manager perimeters update xxxx_Policy_1 \
  43.   --policy=$POLICY_ID \
  44.   --add-resources="//compute.googleapis.com/projects/$PROJECT_ID/global/networks/secure-vpc"

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

  1. # 1. 声明由外部自动注入的变量
  2. variable "org_id" {
  3.   description = "GCP Organization ID"
  4.   type        = string
  5. }
  7. # 2. 自动获取当前项目的上下文信息
  8. data "google_project" "current" {}
  10. # 3. 创建项目级范围化访问政策
  11. resource "google_access_context_manager_access_policy" "scoped_policy" {
  12.   parent = "organizations/${var.org_id}"
  13.   title  = "xxxx-Policy2"
  14.   scopes = ["projects/${data.google_project.current.number}"]
  15. }
  17. # 4. 创建边界、绑定 VPC 网络并配置身份级入站白名单
  18. resource "google_access_context_manager_service_perimeter" "project_perimeter" {
  19.   parent         = "accessPolicies/${google_access_context_manager_access_policy.scoped_policy.name}"
  20.   name           = "accessPolicies/${google_access_context_manager_access_policy.scoped_policy.name}/servicePerimeters/xxxx_Policy_1"
  21.   title          = "xxxx-Policy-2"
  22.   perimeter_type = "PERIMETER_TYPE_REGULAR"
  24.   status {
  25.     # 保护项目资源，并将 VPC 网络作为资源直接加入边界
  26.     resources = [
  27.       "projects/${data.google_project.current.number}",
  28.       "//compute.googleapis.com/projects/${data.google_project.current.project_id}/global/networks/secure-vpc"
  29.     ]
  31.     # 限制的 PaaS 服务
  32.     restricted_services = ["storage.googleapis.com"]
  34.     # 配置入站放行规则 (Ingress Rule)
  35.     ingress_policies {
  36.       ingress_from {
  37.         identities = ["user:【实际的邮箱】"]
  38.         sources {
  39.           access_level = "*" # 匹配所有来源
  40.         }
  41.       }
  42.       ingress_to {
  43.         resources = ["*"]
  44.         operations {
  45.           service_name = "storage.googleapis.com"
  46.           method_selectors {
  47.             method = "*"
  48.           }
  49.         }
  50.       }
  51.     }
  52.   }
  53. }
  1. # 1. 确保环境变量已加载
  2. export TF_VAR_org_id=$(gcloud organizations list --format="value(ID)" | head -n 1)
  4. # 2. 动态获取之前创建的 Policy 的真实 ID
  5. POLICY_NAME=$(gcloud access-context-manager policies list \
  6.   --organization=$TF_VAR_org_id \
  7.   --format="value(name)" \
  8.   --filter="title:xxxx-Policy")
  10. # 3. 先删除 VPC-SC 边界
  11. gcloud access-context-manager perimeters delete xxxx_Policy_1 \
  12.   --policy=$POLICY_NAME --quiet
  14. # 4. 再删除访问策略 (Policy)
  15. gcloud access-context-manager policies delete $POLICY_NAME --quiet
  17. # 5. 创建
  18. terraform init
  19. terraform apply -auto-approve

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

5.1 实验背景与合规映射

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

合规要求映射：

本节我们将使用 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）：
  6. 修复漏洞（Remediate）：
  7. 验证修复并静默告警：

5.4 CLI 快速进阶方式

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

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

第六部分：实验环境清理

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

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

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

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

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

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

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

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