Google Cloud Storage 数据加密怎么实现，默认加密和自主管理密钥有什么区别

Google Cloud Storage（GCS）默认就会对静态数据实施服务器端加密。用户把对象上传到 Cloud Storage 后，数据在写入存储介质之前就会完成加密，不需要用户修改应用程序，也不需要额外部署一套加密服务器。Google官方文档说明，Cloud Storage 的标准服务器端加密使用 AES-256，在大多数情况下采用 GCM 模式，而且默认加密不会额外收取费用。对于绝大多数普通对象存储业务来说，用户甚至不需要考虑密钥在哪里、什么时候轮换，GCS会负责底层密钥管理。

真正需要企业做架构选择的地方，不是“要不要加密”，而是“谁控制用于保护数据的密钥”。Google Cloud主要提供两种相关模式：Google-owned and Google-managed encryption keys，也就是默认加密；以及 Customer-Managed Encryption Keys，也就是CMEK，由客户通过 Cloud Key Management Service 管理密钥。两者的数据最终都处于服务器端加密保护之下，最大的区别在于密钥的所有权、访问控制、轮换、审计以及生命周期控制权掌握在谁手里。

默认加密到底是怎么工作的

Cloud Storage 的默认加密不是用户自己创建一把 AES 密钥，然后把整份文件直接用这把密钥加密。Google使用的是经过设计的密钥管理和 envelope encryption 体系，底层涉及数据加密密钥以及用于保护这些密钥的密钥加密机制。Google负责整个密钥管理体系，包括密钥的保护、访问控制和审计。用户上传文件时不需要指定任何密钥，也不需要给 Cloud Storage 配置 Cloud KMS 权限。

这也是原稿中“默认加密采用 Google 管理的客户主密钥 CMK”这一说法需要修正的地方。这里不应该把 Google-owned and Google-managed encryption keys 称作用户的 Customer Master Key。官方目前使用的分类是 Google-owned and Google-managed encryption keys，而 CMEK则是 customer-managed encryption keys。两者的控制权完全不同。Google默认加密的密钥由Google拥有和管理，客户不能查看或者直接管理这些密钥，也不能像管理CMEK那样查看密钥使用情况。

默认加密最大的优势就是简单。应用程序仍然按照普通 GCS API 上传和读取对象，开发人员不需要在代码里增加额外的加密逻辑。授权用户读取对象时，底层解密过程同样由 Cloud Storage 自动完成。对于网站图片、日志、备份文件、静态资源、普通数据库导出以及大量一般业务数据，这种模式通常已经足够。

尤其需要纠正的是“默认情况下每90天自动轮换一次”这一说法。不能把90天写成 Cloud Storage 默认加密的一条固定用户可见规则。Google负责其默认加密密钥的管理和轮换，具体内部密钥管理机制由Google控制，用户不能按照管理CMEK的方式自行设置这些Google-owned and Google-managed keys的轮换计划。Google文档对默认加密和CMEK的控制边界有明确区分。

CMEK改变的到底是什么

如果企业需要自己控制密钥，就可以使用 Customer-Managed Encryption Key。CMEK由 Cloud Key Management Service，也就是 Cloud KMS 提供管理能力。用户可以创建自己的密钥，并控制密钥的位置、保护级别、访问权限、轮换计划、状态以及销毁操作。对于支持CMEK的Cloud Storage资源，Cloud Storage通过自己的服务代理访问相应的KMS密钥完成加密和解密，应用程序本身并不需要在每一次读写文件时直接操作密钥。

这点非常重要，因为“自主管理密钥”并不意味着企业必须把原始AES密钥放在自己的服务器上，然后每次上传文件都自己加密。CMEK仍然属于服务器端加密。Cloud Storage与Cloud KMS完成集成之后，业务应用继续像普通GCS一样读写对象，而密钥控制权转移到了客户一侧。

例如，一家公司把生产数据存放在一个 Cloud Storage bucket 中，同时在另一个项目中建立 Cloud KMS key。然后授权该 bucket 对应的 Cloud Storage service agent 使用这个密钥。以后新写入对象可以使用这个CMEK进行保护。Google官方文档明确要求为Cloud Storage服务代理授予相应的 Cloud KMS 加密/解密权限，并且用于CMEK的密钥位置需要满足Cloud Storage对应资源的位置要求。

这就带来了一个默认加密没有的控制能力：企业可以决定谁有权使用这把密钥。

例如，存储项目负责管理数据，安全团队负责管理KMS密钥，两边甚至可以放在不同项目中。这样可以形成职责分离。一个拥有Cloud Storage管理员权限的人，并不自动意味着他拥有修改CMEK生命周期的全部权限。企业可以通过 IAM 对密钥的使用和管理权限进行更细的划分。

CMEK最重要的价值其实不是“加密更强”

很多技术文章容易把CMEK写成“更高级、更安全的加密”。这种说法并不严谨。

默认加密和CMEK都提供静态数据加密保护，CMEK并不是因为AES算法本身突然变得更强，而是因为客户获得了更强的密钥控制能力。Google文档明确说明，CMEK使用Cloud KMS中的客户控制密钥来保护数据，而且可以控制密钥的保护级别、位置、访问控制、轮换、使用以及销毁。

对于普通企业来说，默认加密已经可以解决“磁盘上的数据不能以明文保存”这个问题。如果企业真正需要解决的是“谁能够使用密钥”“密钥必须位于哪个区域”“密钥使用是否能够被审计”“发生安全事件后能否通过撤销密钥访问来阻断数据解密”“是否必须满足某个行业合规框架”，CMEK的价值才会明显体现出来。

其中一个比较特殊的能力是 crypto-shredding，也就是通过销毁用于保护数据的密钥版本，使受保护的数据在密码学意义上无法继续解密。Google把这种能力列为CMEK可以支持的安全目标之一。它适合某些数据退出、租户隔离或者安全事件处置场景，但也意味着企业必须非常谨慎地设计密钥销毁流程，因为密钥管理错误可能直接影响数据可读性。

密钥轮换也不能简单理解为“每90天手动换一把钥匙”

原稿把默认加密和CMEK的轮换机制描述得过于简单。

CMEK的Cloud KMS密钥可以配置自动轮换，也可以手动执行轮换。轮换发生后，Cloud KMS会产生新的key version，并将新的版本设为primary version。旧版本通常仍然保留，用于解密此前由旧版本保护的数据加密密钥。也就是说，轮换并不等于把所有历史数据立刻重新加密一遍。

因此，企业应该把“密钥轮换”和“历史数据重新加密”看成两个不同的问题。轮换主要解决密钥版本生命周期和未来加密操作的问题，而已经存在的数据是否需要重新加密，则取决于具体服务以及企业自己的安全策略。

Google Cloud KMS允许企业根据安全要求配置自动轮换周期。90天可以作为某些安全规范下的一个常见周期，但不能写成所有GCS CMEK用户都必须90天轮换，也不能说CMEK只能手动轮换。Google官方文档明确支持自动轮换和手动轮换。

密钥删除则更加需要谨慎。对于CMEK，密钥并不是一个可以随便删除、以后再从云端找回的普通配置对象。如果企业销毁了仍然用于保护数据的关键密钥版本，就可能导致相应数据无法解密。因此，生产环境应该把密钥销毁审批、依赖关系检查、备份策略和恢复测试纳入变更管理，而不是简单制定一个“至少保留30天”的固定规则。

CMEK和默认加密到底怎么选

如果只是建立一个普通网站，把图片、PDF、日志、备份或者业务文件放在GCS中，通常没有必要为了“高级安全”而强行部署CMEK。Google默认加密已经提供服务器端静态数据加密，而且无需额外配置，适合大量通用业务。Google自己也明确将Standard，也就是默认加密定位为大多数用户的通用选择。

如果企业受到特定合规要求约束，需要控制密钥位置、密钥访问权限、轮换策略、密钥生命周期或者密钥使用审计，那么CMEK就更加合理。例如某些受监管的数据处理环境可能要求企业能够证明谁控制加密密钥、密钥存放在哪里以及谁能够使用密钥。这时候仅仅证明“GCS默认已经加密”可能无法满足内部审计或者监管要求。

还需要特别区分“加密”和“访问控制”。一份文件即使使用CMEK加密，如果IAM配置允许不应该访问它的账号读取对象，那么CMEK并不会自动替代IAM。CMEK解决的是密钥控制问题，Cloud Storage IAM解决的是谁可以访问bucket和object的问题，两者必须一起设计。

同样，CMEK也不能替代备份、对象版本控制、Soft Delete、Retention Policy或者灾难恢复机制。加密主要解决数据机密性以及密钥控制问题，而备份和保留机制解决的是误删除、逻辑损坏、勒索攻击以及灾难恢复问题。企业如果把“已经启用CMEK”理解成“数据已经全面安全”，反而容易形成错误的安全感。

Cloud Storage还允许企业对bucket中的新对象限制允许使用的加密方式。官方文档目前支持针对bucket配置标准加密、CMEK和CSEK等方式的允许或限制策略。例如企业可以要求新对象必须使用标准加密或CMEK，而限制其他加密方式。

对于需要严格控制密钥的企业，比较合理的架构通常是把Cloud Storage、Cloud KMS、IAM和审计日志放在同一个安全模型中考虑。Cloud Storage负责对象存储，Cloud KMS负责密钥生命周期，IAM负责谁可以操作资源，Cloud Audit Logs负责留下关键操作记录。这样做的意义并不是让每一层都重复做一次安全，而是让数据、密钥、身份和审计形成完整的控制链。

还有一点经常被忽略：GCS的静态数据加密和网络传输加密不是同一个问题。Cloud Storage负责服务器端静态数据加密，而对象通过网络上传和下载时，还需要依赖TLS/HTTPS保护传输过程。Google官方文档同样明确区分了静态数据加密和传输过程中的TLS保护。

从工程角度看，选择默认加密还是CMEK，不应该从“哪一个更高级”出发，而应该从业务需求反推。如果企业没有密钥控制、审计、位置隔离和合规要求，默认加密通常是更简单、维护成本更低的方案。如果企业必须掌握密钥生命周期，能够独立控制密钥访问，并且需要在安全审计中证明密钥由谁控制，那么CMEK才有充分的工程价值。

云安全真正麻烦的地方往往不是打开某一个“加密开关”，而是建立完整的权限、密钥、日志、保留和恢复体系。GCS默认加密解决了大量基础安全问题，而CMEK进一步把密钥控制权交给客户。两者并不是“安全”和“不安全”的区别，而是“Google替你管理密钥”和“企业自己承担更多密钥控制责任”的区别。选择CMEK之后，企业得到的是更大的控制权，同时也得到更大的管理责任。这个交换关系，才是设计GCS加密架构时最应该考虑的问题。