解读

面试官问的是“脱敏策略”在 Cloud SQL 只读副本（Read Replica）上的实际生效范围。
核心考点有两层：

1. Cloud SQL 的复制机制是物理复制（基于底层磁盘块或 WAL 流），主实例与只读副本之间传输的是字节级变更，而非 SQL 语句。
2. 脱敏策略（Dynamic Data Masking、Column-level Encryption、DLP 规则或业务侧脱敏视图）到底发生在哪一层：是存储引擎层、查询解析层还是业务应用层。
   如果候选人把“脱敏”理解成“存储层直接改写数据”，就会误判为副本也会落地脱敏后的值；实际上脱敏只在查询返回路径生效，而复制流绕过了这一路径，因此副本拿到的是完整原始数据。
   国内金融、政企客户对“副本数据是否落盘敏感信息”非常敏感，答错会直接触发合规红线，面试官会据此判断候选人是否具备落地级安全合规意识。

知识点

• 物理复制 vs 逻辑复制：Cloud SQL 默认采用物理复制，副本数据页与主库比特级一致。
• 脱敏实现位置：
  – Dynamic Data Masking（DDM）是 Google Cloud 在查询解析层加的规则，只影响 SELECT 返回包，不改写存储。
  – Column-level Encryption（CMEK、EkmConnection）加密的是磁盘页，但解密钥匙在查询时动态获取，副本磁盘同样存密文，解密后仍是原始值。
  – DLP 脱敏视图或业务侧脱敏 UDF 只在主库查询层生效，不会写入 binlog/WAL，因此副本侧无感知。
• 国内合规要求：等保 2.0、个人信息保护法要求“敏感数据在测试、分析环境必须脱敏”，如果副本用于报表或数据沙箱，必须显式再建脱敏视图或使用逻辑导出+脱敏管道。
• Cloud SQL 只读副本限制：不支持触发器、不支持可写函数，无法在主库侧“推”脱敏逻辑到副本；只能在副本侧单独建 Masking Rule（若引擎为 SQL Server 2022）或通过 Proxy 层统一脱敏。

答案

脱敏策略不会随物理复制自动作用于只读副本。
原因：Cloud SQL 的只读副本通过流式物理复制保持与主库磁盘页一致，脱敏规则（DDM、加密列、DLP 视图）仅在查询返回路径生效，不改写存储页内容，也不写入复制流。因此副本落地的是完整原始数据，查询时若未单独配置脱敏规则，就会直接暴露敏感字段。
在国内合规场景下，如果副本要用于报表、测试或数据共享，必须显式在副本侧再建脱敏视图，或使用 Dataflow + DLP 模板把数据导出到新的脱敏实例，否则会出现“副本数据未脱敏”的合规风险。

拓展思考

1. 云原生合规架构：
   对金融客户，可引入双层脱敏网关：外层用 Cloud SQL Auth Proxy + Cloud DLP 实时 Mask，内层在 BigQuery 或 Vertex AI 训练环境再做一次静态脱敏，确保“原始数据永不落盘非生产环境”。
2. 跨区域只读副本的加密域问题：
   若主库在北京地域、副本在上海地域，且主库使用CMEK 密钥，需提前把密钥副本授权给上海地域的 KMS，否则副本无法解密，查询直接失败；此时脱敏策略即便配置了也无效。
3. 未来演进：
   Google Cloud 已在 SQL Server 2022 引擎预览可重复使用的 Dynamic Data Masking 元数据，预计 2025 年 Q3 会下放到 Cloud SQL for SQL Server，届时可在主库定义一次 Masking Rule，副本自动继承，但 MySQL/PostgreSQL 仍无路线图，需要自行在 Proxy 层统一收口。