Google Cloud 服务账号密钥安全吗，什么时候应该避免长期保存 JSON Key

Google Cloud 的 Service Account Key 能不能长期保存？真正危险的是“静态凭证”思维

在 Google Cloud 环境中，Service Account 是应用程序访问云资源的重要身份机制，而 Service Account Key 则是一种让应用程序获得这一身份的传统方式。

问题在于，JSON 格式的 Service Account Key 文件本身包含私钥。一旦这个文件被复制、泄露或者被攻击者取得，攻击者就可能利用对应的服务账号身份访问其被授权的云资源。

因此，在现代云环境中，一个非常重要的安全原则正在逐渐明确：能不用长期保存的 Service Account Key，就尽量不要保存。

这并不是说 JSON Key 完全不能使用，而是说企业不应该把它当成默认、长期存在的认证方式。

一、JSON Key为什么危险

一个典型的 Service Account JSON Key 文件中包含服务账号信息以及私钥材料。私钥本身就是最需要保护的部分。

与用户名和密码类似，谁掌握了有效的私钥，就可能以对应服务账号的身份向 Google Cloud 发起经过认证的请求。

但它又比普通密码更加危险，因为服务账号往往不是一个普通用户，而是一个拥有大量自动化权限的系统身份。

例如，一个负责备份数据库的服务账号可能拥有Cloud Storage写入权限；一个负责部署应用的服务账号可能拥有Compute Engine或者容器平台相关权限。

如果这样的服务账号私钥泄露，攻击者获得的并不是某一个网页账户，而可能是一套能够调用云资源的机器身份。

因此，真正的问题并不是JSON这个文件格式，而是静态私钥长期存在于服务器、代码仓库、配置文件或者开发人员电脑中。

二、最危险的情况，是把JSON Key放进代码

实际开发中最容易出现的问题之一，就是把JSON Key放进项目目录。

例如开发人员为了让程序能够正常运行，把credentials.json直接放到应用程序目录，然后通过代码加载。

开发环境中可能感觉非常方便，但一旦项目被提交到Git仓库，风险就出现了。

更麻烦的是，即使开发人员后来删除这个文件，如果它已经进入Git历史记录，私钥仍然可能存在于过去的提交中。

因此，所谓“我已经把文件删除了”并不意味着密钥已经安全。

一旦私钥已经泄露，正确做法不是简单删除文件，而是立即处理对应的Service Account Key，并重新检查相关权限和访问日志。

三、生产服务器上长期保存同一个Key同样危险

另一种常见模式是把JSON Key上传到生产服务器，然后让应用永久读取这个文件。

这种方式确实简单，但问题也非常明显。

服务器一旦遭到入侵，攻击者首先会寻找环境变量、配置文件和密钥文件。

如果JSON Key长期存在于服务器文件系统中，攻击者获得服务器控制权之后，很可能进一步取得云平台访问能力。

更严重的是，如果同一个Key被多个服务器、多个容器甚至多个应用共享，那么一个系统出现漏洞，就可能影响整个服务账号的安全边界。

这就是为什么现代云安全越来越强调“工作负载身份”和“短期凭证”，而不是把一把长期有效的私钥复制到每台服务器上。

四、真正的问题是服务账号权限有多大

必须注意，Service Account Key本身并不会自动拥有整个Google Cloud项目的全部权限。

它能够做什么，取决于对应Service Account被授予了什么IAM权限。

这意味着密钥安全和权限设计实际上是两个相互关联的问题。

如果一个服务账号只有读取某个Cloud Storage存储桶的权限，那么即使它的Key泄露，攻击者能够造成的影响相对有限。

但如果一个服务账号拥有项目级管理员权限，那么同样的Key泄露以后，后果可能完全不同。

因此，安全设计不能停留在“保护JSON文件”这一层，而应该同时落实最小权限原则。

一个只负责读取数据的程序，不应该获得删除资源的权限。

一个只负责上传文件的服务，也没有理由获得修改整个项目基础设施的权限。

五、不要让多个服务共享同一个Service Account

微服务架构尤其容易出现这个问题。

例如企业有订单服务、支付服务、报表服务和文件处理服务，开发人员为了方便，给所有服务配置同一个Service Account Key。

这种做法看起来管理简单，实际上却破坏了权限隔离。

假设文件处理服务存在漏洞，攻击者取得了这个Key，那么他获得的权限可能不仅能够访问文件，还可以进一步访问订单、支付或者报表相关资源。

更合理的设计是根据业务边界划分Service Account。

订单服务使用自己的身份，支付服务使用自己的身份，报表服务使用自己的身份。

这样即使其中一个服务遭到攻击，攻击范围也更容易被限制。

六、Google Cloud更推荐什么方式？

如果应用运行在Google Cloud内部，通常应该优先考虑使用平台提供的工作负载身份机制，而不是手工生成JSON Key。

例如运行在Compute Engine、Cloud Run、Google Kubernetes Engine等环境中的应用，可以通过相应的工作负载身份机制获取短期凭证。

这种方式最大的优势是，应用不需要在代码目录里长期保存一个私钥。

应用需要访问云资源时，由云平台负责提供相应的身份和临时访问凭证。

对于Kubernetes环境，Workload Identity Federation尤其重要，因为它可以让Kubernetes工作负载与Google Cloud IAM身份建立对应关系，从而减少在Pod中保存静态密钥的需要。

七、Secret Manager并不能解决所有问题

有些开发人员看到“不能把JSON Key放代码里”，马上想到把JSON Key放进Secret Manager。

这确实比把私钥直接写进代码安全得多，但仍然需要明确一个问题：

Secret Manager解决的是“密钥如何安全保存和读取”，并不意味着“长期使用静态密钥本身已经成为最佳方案”。

如果应用每次启动都从Secret Manager读取一个长期有效的JSON Key，那么静态凭证仍然存在，只是存储位置更加安全。

因此，在能够使用工作负载身份和短期凭证的情况下，应该优先考虑消除长期JSON Key，而不是单纯把JSON Key换一个地方保存。

当然，对于确实必须使用静态密钥的特殊场景，Secret Manager等专业密钥管理系统仍然是比明文文件、代码仓库和普通配置文件更加合理的选择。

八、不要迷信“90天轮换”这个数字

很多安全方案喜欢给出固定的90天轮换周期，但企业不应该把“90天”理解成一个万能标准。

真正重要的是建立完整的密钥生命周期管理。

首先知道有哪些Key。

其次知道每个Key属于哪个Service Account。

然后知道它被哪些应用使用。

同时记录创建时间、最后使用情况以及负责维护的团队。

一旦某个应用不再需要这个Key，就应该删除，而不是让它继续存在。

如果Key已经泄露，则不应该等到轮换周期结束，而应该立即撤销。

换句话说，轮换只是密钥管理的一部分，减少长期存在的静态密钥数量才是更根本的办法。

九、发现Key泄露后，第一反应应该是什么？

如果企业怀疑Service Account JSON Key已经泄露，最忌讳的就是继续观察。

应该立即确认这个Key对应的是哪个Service Account，以及这个服务账号拥有怎样的IAM权限。

然后撤销或者删除已经泄露的Key，并根据实际情况生成新的认证方式。

与此同时，需要检查Cloud Audit Logs等审计记录，确认这个身份最近进行了哪些操作。

重点应该检查资源创建、删除、权限修改、数据访问以及异常时间段的活动。

如果攻击者已经利用这个身份执行过操作，那么简单地删除Key并不意味着安全事件结束。

因为攻击者可能已经创建了其他凭证、修改了IAM权限，或者在系统中留下其他持久化入口。

因此，密钥泄露后的处理应该是一次完整的安全事件响应，而不是简单“换一个密码”。

十、企业真正需要建立的是身份生命周期管理

对于现代云环境，Service Account不应该被理解为一个“程序密码”。

它实际上是一种机器身份。

既然是身份，就应该像管理员账户一样进行生命周期管理。

创建之前明确用途，使用过程中控制权限，运行期间记录访问行为，不再需要时及时撤销。

更理想的状态，是让应用获得短期、动态的访问凭证，而不是把一把永久存在的钥匙放在服务器里。

从安全架构角度看，最值得遵循的原则可以归纳为几个方面：减少静态密钥、采用短期凭证、实行最小权限、不同服务使用不同身份、记录身份活动，并建立明确的撤销机制。

JSON Key并不是绝对不能使用。某些外部系统、遗留应用或者特殊部署环境可能仍然需要它。

但问题在于，一旦使用，就应该把它当成高价值敏感凭证管理，而不是普通配置文件。

对于新的Google Cloud项目，如果能够通过Workload Identity Federation、应用默认凭证以及其他短期身份机制解决认证问题，就没有必要为了方便而生成一份JSON私钥，再把它复制到服务器、容器和代码仓库中。

云安全最危险的习惯，往往不是技术不够先进，而是为了“先跑起来”留下一个永久有效的秘密。

当这个秘密存在数年、被多个系统共享，而且没人真正知道它在哪里时，真正的安全风险就已经产生了。