解读

在国内金融、政企类客户的 Google Cloud 落地项目中，VPC Service Controls（VPC-SC） 是数据出境治理的核心防线。一旦 Cloud SQL 实例被“跨边界”访问（如 on-prem 堡垒机通过公网 IP 直连、开发者在办公室用 Cloud Shell 绕开边界、或者 Terraform 在未被列入 VPC-SC 的 CI/CD 项目里调用 SQL Admin API），VPC-SC 会在网络层拒绝请求，并同步生成一次 AUDIT_DENY 日志。面试官问“会记录哪些字段”，实质在考察：

1. 你能否把“拒绝点”与 Cloud Audit Logs 的 schema 精准对应；
2. 你能否通过日志字段反向溯源“谁、在哪、访问了哪个 Cloud SQL 资源、触发了哪条 VPC-SC 规则”，从而满足国内等保 2.0 对“安全事件可追溯”的要求。

知识点

1. VPC-SC 审计日志类型：只有AUDIT_DENY，没有 AUDIT_ALLOW；与数据访问日志（DATA_READ / DATA_WRITE）分离存储。
2. Cloud Audit Logs 三大核心段：
   • protoPayload：承载 Google 内部 RPC 细节，methodName、resourceName、serviceName 均在此段；
   • securityContext：VPC-SC 专用段，vpcServiceControlsUniqueId、vpcServiceControlsStatus、restrictedServices 等字段出现；
   • requestMetadata：记录callerIp、callerSuppliedUserAgent，用于定位“跳板机”或“个人笔记本”。
3. 国内合规敏感字段：
   • resource.labels.project_id（客户在国内的关联实体项目）；
   • resource.labels.database_id（Cloud SQL 实例 id，形如 project:region:instance）；
   • protoPayload.authenticationInfo.principalEmail（国内员工企业邮箱或服务账号）；
   • protoPayload.request.@type（API 请求类型，如 type.googleapis.com/google.cloud.sql.v1beta4.SqlInstancesGetRequest）。
4. 日志桶策略：VPC-SC 拒绝日志强制写入 _Default 桶，且不受 VPC-SC 自身限制，确保安全团队总能拿到日志。

答案

当 VPC-SC 边界被违反时，Cloud Audit Logs 会在AUDIT_DENY 事件中至少出现以下关键字段：

• protoPayload.methodName：触发拒绝的 API，如 cloudsql.instances.get、cloudsql.instances.connect；
• protoPayload.resourceName：被访问的 Cloud SQL 资源完整路径，例 //cloudsql.googleapis.com/projects/xxx/instances/yyy；
• protoPayload.authenticationInfo.principalEmail：发起请求的账号；
• protoPayload.requestMetadata.callerIp：源地址，国内常见为办公网 NAT 或堡垒机出口 EIP；
• securityContext.vpcServiceControlsUniqueId：命中那条 VPC-SC 边界的唯一标识；
• securityContext.vpcServiceControlsStatus：固定为 VIOLATED；
• resource.labels.project_id 与 resource.labels.database_id：定位受保护项目与实例；
• severity：ERROR；
• timestamp：RFC3339 格式，国内需转成 UTC+8 做溯源。

通过上述字段，安全运维可在Log Analytics 或 SIEM（如国内自研泰山平台） 中一键检索：
severity=ERROR AND protoPayload.methodName:"cloudsql" AND securityContext.vpcServiceControlsStatus="VIOLATED"
即可还原完整违规路径。

拓展思考

1. 双边界场景：若客户在北京 region 建立“生产”VPC-SC，在上海 region 建立“研发”VPC-SC，且 Cloud SQL 实例通过 Private Service Connect 被跨 region 访问，日志里会出现两条 AUDIT_DENY，分别对应两个 perimeter 的 uniqueId；此时需用 traceId 字段串联两次拒绝事件，避免重复告警。
2. Cloud SQL Auth Proxy 的特殊性：代理默认走 OAuth2 令牌+HTTPS 443，流量先抵达 Google 前端；VPC-SC 拒绝发生在前端转发层，因此 callerIp 记录的是 Google 前端出口，而非真实客户端 IP。要拿到“第一跳”地址，需让客户端在代理启动时加 --enable_iam_login 并开启 GFE-IP-Forwarding，此时 protoPayload.requestMetadata.callerIp 才会显示原始地址，满足国内监管对“源 IP 真实可追溯”的强要求。
3. 与国内云审计对接：很多央企要求 7×24 把日志回传到集团审计中台。可在日志接收器（Log Sink） 中过滤 securityContext.vpcServiceControlsStatus="VIOLATED"，通过 Pub/Sub + Dataflow 模板 实时推送到 Kafka，再落地到集团自建的“国密算法加密”对象存储，实现“云侧产生、集团侧不落 GCP”的合规闭环。