2024年底，美国网络安全和基础设施安全局CISA遭遇了一次尴尬的安全事件。一家为CISA提供技术服务的承包商，在内部开发过程中将一组AWS GovCloud的访问密钥以明文形式发布到了公共代码仓库中。GovCloud是AWS专门为美国政府机构提供的合规云服务，用于承载政府敏感数据和关键业务系统。这批密钥一旦被攻击者获取，就可能直接访问到CISA在GovCloud中的系统和数据。虽然CISA和AWS方面及时采取了应急措施，但这次事件再次将云凭证管理问题推到了聚光灯下。
这次事件暴露出的核心问题，是云凭证管理中的"人机分离"难题。在云服务深度嵌入企业业务的今天，每个开发人员、每台服务器、每段自动化脚本都需要访问云资源。而访问这些资源的凭证——AWS Access Key、AK/SK密钥对、服务账号密码等——的数量级已经远远超出了传统IT资产管理的能力范围。一家中型企业的云账号数量可能成百上千，这些账号的创建、使用、轮换和回收，如果全靠人工管理，几乎不可能做到万无一失。
从技术层面分析，云凭证泄露的常见场景有几个。最常见的一种情况，是凭证被硬编码到代码中。开发人员为了方便测试和调试，将云服务密钥直接写在源代码里，随后连同代码一起提交到了代码仓库。如果这个仓库是公开的，密钥就相当于被公之于众。CISA承包商事件正是这个场景的典型案例。即使仓库是私有的，攻击者如果在其他环节拿到了仓库的访问权，同样可以获得这些凭证。
第二个场景是凭证被记录在配置文件中。很多应用程序的配置文件包含了云服务的连接信息，这些配置文件有时会被不小心提交到版本控制系统，有时会随容器镜像一起分发，有时会被遗留在测试服务器上。无论哪种情况，只要配置文件落到不该看到的人手中，云资源就面临风险。
第三个场景是过度授权的服务账号。很多企业在创建云服务账号时，习惯性地授予权限范围过大的角色。一个只需要读取对象存储的服务账号，却被赋予了完全的读写权限；一个只需要访问某个特定EC2实例的账号，却可以操作整个区域的云资源。这种过度授权的问题在于，一旦某个账号的凭证被泄露，攻击者能够造成的破坏范围就远大于预期。
针对云凭证管理的挑战，企业可以采取几个务实的措施。密钥集中管理是基础。AWS Secrets Manager、Azure Key Vault、HashiCorp Vault等密钥管理服务，可以将所有云凭证集中存储，并自动轮换。应用程序在运行期间，通过API从密钥管理服务动态获取凭证，而不需要将凭证硬编码到任何文件中。这意味着即使攻击者攻破了服务器，也拿不到持久化的凭证。
凭证检测和告警要常态化。企业应该定期扫描代码仓库中的凭证泄露，可以使用开源工具如GitLeaks或商业解决方案。扫描范围不仅限于主分支，还应该覆盖所有分支、历史提交记录、甚至Issue和Wiki中的内容。一旦发现凭证泄露，立即轮换受影响的所有密钥，同时排查泄露源。
最小权限原则需要严格执行。云服务账号应该按照"刚刚够用"的原则分配权限，不需要为任何一个账号授予超出其职责范围的权限。对于已经存在的账号，建议定期审计其权限配置，识别和收窄过大的授权。同时开启云平台的访问日志和分析功能，对异常访问行为进行实时监控。
云安全评估是发现凭证管理盲区的有效手段。企业可以通过第三方专业评估，对云基础设施的安全配置进行全面检查，包括IAM策略、密钥管理、日志审计、网络策略等多个维度。评估报告能够帮助企业明确需要优先修复的安全弱项。
云服务的安全运行，凭证管理是基础。一个凭证泄露就可能导致整个云环境的沦陷，这个代价是任何企业都无法承受的。北京企密安信息安全技术有限公司提供云安全评估、数据安全方案和云基础设施安全审计服务，帮助企业构建从凭证管理到资源访问的全流程云安全体系。
