解读

在国内政企、金融、互联网大厂的面试里，“数据驻留”常被等价于“数据不出境”或“数据不出省”。面试官真正想听的是：

1. 你能否把合规红线（《网络安全法》《数据安全法》《个人信息保护法》）与Cloud SQL 技术约束一一对应；
2. 你能否给出可落地的工程方案，而不是背概念。
   因此，回答要围绕“合规要求 → Cloud SQL 功能边界 → 替代架构”这条逻辑链展开，并主动暴露风险点，体现资深度。

知识点

1. 数据驻留的国内定义：关键数据必须在境内特定区域（通常指中国大陆地域）存储、处理、备份，未经审批不得出境。
2. Cloud SQL 备份链路：自动备份、PITR 日志、跨区域副本均依赖后台对象存储（Cloud Storage bucket），bucket 的物理 location 决定数据实际落地位置。
3. Cloud SQL 当前地域集：国内只有上海、北京、香港三个可选 region；香港 region 虽属中国，但合规上被多数甲方视为“境外”。
4. 跨区域备份限制：
   • 若实例创建在上海或北京，控制台允许把“备份地理位置”指向香港或任何境外 region，一旦启用即触发违规；
   • 若实例创建在香港，备份无法指向境内 region（产品层面未打通），导致“数据入境”同样不可控；
   • IAM 政策无法精细到 bucket 级 location，只能事后审计，做不到“事前强制拒绝”。
5. Private Service Connect / VPC-SC 边界：目前不支持把 Cloud SQL 备份流量限定在境内 VPC-SC 边界内，合规部门会认定为“黑箱流量”。
6. 可用替代手段：
   • 关闭“跨区域备份”开关，仅保留同 region 多可用区冗余；
   • 使用gcloud sql export 把逻辑备份导出到境内指定 location 的 Cloud Storage bucket，并通过Bucket Lock + CMEK 固化驻留证据；
   • 对金融级场景，每日触发裸磁盘快照（使用磁盘级 CMEK），快照链与实例同 region，再搭配第三方备份软件（如鼎甲、爱数）转储到本地机房，形成“云+本地”双轨，满足银保监 39 号文对“本地可验证副本”的要求。

答案

在中国大陆的 Cloud SQL 项目中，数据驻留策略的核心是“备份数据不得离开境内指定 region”。然而，Cloud SQL 的**“跨区域备份”功能默认允许把备份文件写入用户指定的任意 region**，包括香港及境外。由于：

1. 国内可选 region 仅上海、北京、香港，香港在多数甲方合规框架里被视为“境外”；
2. 备份文件实际存放在 Cloud Storage bucket，bucket 的 location 由用户在一次配置后长期生效，IAM 条件策略无法实时拦截误配；
3. Cloud SQL 后台复制链路对租户侧不可见，审计时无法出具“数据未出境”的完整证据链；
   因此，一旦启用跨区域备份，即直接违反《数据安全法》第21条“重要数据境内存储”要求。
   工程上必须关闭控制台中的“跨区域备份”选项，并采用同 region 自动备份 + 逻辑导出到境内 CMEK 加密 bucket + 本地二次转储的三层方案，才能同时满足SLA、合规、审计三方要求。

拓展思考

如果面试官追问“跨国企业需要全球容灾，又要满足中国数据不出境，如何设计？”
可回答：

1. 在中国区单独部署一套 Cloud SQL（上海/北京），关闭所有出境链路，仅做同 region 高可用；
2. 使用 Cloud SQL for PostgreSQL 的 logical replication slot，把脱敏后的子集数据通过Dataflow 动态脱敏任务同步到境外 BigQuery，实现“原始数据不出境，衍生数据可出境”的合规分层；
3. 全球统一 Terraform 模板里用变量+条件语句强制判断var.region为asia-east2或asia-northeast1时自动禁用backup_location字段，把合规左移到CI 阶段，实现“基础设施即代码”层面的强制驻留。