解读

在国内面试场景中，这道题考察的是“把数据库安全审计事件接入无服务器函数”的完整链路。面试官想确认两点：

1. 你是否理解 Cloud SQL 审计日志（Audit Log）的产生位置与格式；
2. 你是否能把日志事件无侵入地变成 Cloud Functions 的触发源，并兼顾权限、时延、幂等、成本四个维度。
   答得太浅（只说“用 Pub/Sub 就行”）会被追问细节；答得太深（直接讲代码实现）又容易超时。因此，用“架构图语言”把数据流、配置点、风险点讲清楚是最佳策略。

知识点

1. Cloud SQL Audit Log 类别：ADMIN_READ、ADMIN_WRITE、DATA_READ、DATA_WRITE，均归属 Cloud Audit Logs，统一写入 Cloud Logging。
2. Logging Sink：通过 Log Router 把符合过滤条件的日志路由到 Pub/Sub Topic；国内 VPC 环境务必勾选 “使用 Private Google 访问” 避免公网出流量。
3. EventArc（推荐）：在 北京/上海区域 已可用，原生把 Cloud Audit Logs → Cloud Functions，无需手写 Pub/Sub 订阅，且自动做 IAM 鉴权与重试。
4. Cloud Functions 触发器类型：
   • Pub/Sub 触发器：需自己管理订阅与死信；
   • EventArc 触发器：全托管，支持 CloudAuditLogs 事件类型，函数签名用 CloudEvents 格式。
5. 过滤语法：
   protoPayload.methodName="cloudsql.instances.connect" OR protoPayload.methodName="cloudsql.instances.update"
   可精确到 实例级别 加 resource.labels.database_id="project:instance"。
6. 最小权限：
   • Sink 身份 需 roles/logging.sinkWriter；
   • Function 身份 需 roles/eventarc.eventReceiver 与 roles/cloudsql.client（若需回写数据库）。
7. 幂等：Audit Log 自带 insertId，函数内用其去重表或Redis SETNX 防重放。
8. 费用优化：国内 Pub/Sub 每百万条 2.4 元，EventArc 不额外收费；过滤条件越精准，费用越低。
9. 合规：若客户为金融、政企，需把日志 Sink 到 某地域的日志专属项目，并加 CMEK 密钥，否则无法过等保。

答案

标准答案采用 EventArc 方案，四步完成：

1. 启用日志：在 Cloud SQL 实例 → “标志位” 打开 cloudsql.enable_google_cloud_logging，并确认项目级 data_access 审计配置已勾选。
2. 创建 EventArc 触发器：

   gcloud eventarc triggers create sql-audit-trigger \
     --location=cn-north1 \
     --destination-cloud-function=processSqlAudit \
     --event-filters="type=google.cloud.audit.log.v1.written" \
     --event-filters="serviceName=cloudsql.googleapis.com" \
     --event-filters="methodName=cloudsql.instances.update" \
     --service-account=my-function@my-project.iam.gserviceaccount.com
   

   其中 --location 必须选国内已支持 EventArc 的区域（cn-north1 或 cn-east1）。
3. 函数代码：使用 CloudEvents SDK，入口签名为 def processSqlAudit(cloud_event)，解析 protoPayload 中的 request 字段即可拿到 SQL 语句或连接 IP，把高危命令（drop、grant）转发到企业微信或飞书群。
4. 观测：在 Cloud Monitoring 新建指标 eventarc/google.cloud.audit.log.v1.written/count，5 分钟无触发则报警，防止因权限误删导致审计链断裂。

如果客户环境 EventArc 未开通，则退化为“Logging Sink + Pub/Sub”方案：

• 在 Logging 创建 Sink，目标选 Pub/Sub Topic，过滤条件同上；
• Cloud Functions 选择 Pub/Sub 触发器，代码里手动解析 jsonPayload.protoPayload；
• 额外步骤：给 Topic 配置 死信订阅（ack_deadline=60 s，max_attempts=5），防止网络抖动造成审计事件丢失。

拓展思考

1. 多项目统一审计：国内大型国企常把生产、测试、日志分三层项目，可通过 Organization Sink 把全部 Cloud SQL 审计日志汇总到日志中台项目，再用 EventArc + Cloud Functions 做统一封禁 IP 或自动创建 Jira 工单。
2. 实时 vs 离线：若需秒级封禁暴力破解，EventArc 方案平均时延 1.5 s；若只需次日审计，可把 Sink 指向 BigQuery，用 Scheduled Queries 批量处理，成本降低 70%。
3. 跨云合规：部分客户数据库在 阿里云 RDS，但仍要求把审计日志镜像到 Google Cloud 做 AI 异常检测。此时可在阿里云侧开 SLS 投递到 OSS，再用 Transfer Service 定时同步到 Cloud Storage，最后Cloud Functions 触发 DLP API 做敏感数据脱敏，实现多云统一审计。