长期密钥隐患多
长期密钥是一种隐患，且随着时间推移，这种隐患通常会不断加剧。随着人员离职，组织外部人员获取密钥信息的风险会增加；假设有人一直在尝试猜测密钥或密码，那么随着时间的推移，他们猜对的可能性也会增大；加密密钥在其安全保障开始降低之前有使用限制。
管理风险的两种方式
可以通过两种方式来管理这种风险。第一种是缩小给定密钥的权限范围，这是理想做法，但并非总是可行，因为某些密钥为了完成其工作，本身就需要具备强大的权限。更通用的风险降低方法是轮换密钥，不过，密钥轮换也是一件非常麻烦的事情。很多读者可能有过类似经历，如因密钥泄露而需要紧急进行轮换；几年前由前员工生成的密钥，关于其生成方式的文档不准确或根本没有文档；轮换过程中因仓促推出或文档过时无法遵循而导致服务中断；由于密钥轮换失败且无法优雅降级，导致服务中断影响范围很大。
临时密钥优势大
基于临时密钥（即有效期约为 1 天或更短的密钥）构建的系统可以避免很多此类麻烦，因为“轮换”是其内置功能。用临时密钥取代长期密钥是安全工程工作的最佳应用之一。例如，长期生产 SSH 密钥可能会被四处复制、硬编码到配置文件中，并且在发生安全事件之前可能会被遗忘。如果用 EC2 实例连接这样的模式取代长期 SSH 密钥，SSH 密钥就会变成需要近期进行身份验证和授权检查的临时凭证；可以使用可信发布者，而不是依赖一个不知怎么跑到首席技术官个人 1Password 里，并且还被多个质量参差不齐的发布管道重复使用的静态 PyPI 令牌，这允许使用特定的 GitHub Actions 工作流来生成用于包发布的临时凭证；单点登录（SSO）之所以有用，一个重要原因是可以用来自可信身份提供商（IdP）的短期身份验证断言，取代每个应用程序中用户选择的长期密码，攻击者可以猜测选择不当的密码，但很难用同样的方式猜测签名的 XML 文档。
仍需长期密钥
不过，可能仍然需要长期密钥。内心的安全专家可能会感到不满，难道真的能消除所有长期密钥吗？上面提到的 SSO 示例忽略了一个事实，即虽然每个身份验证断言是临时的，但签署该断言的密钥却不是。确实如此，可能无法消除每一个长期密钥，然而，减少长期密钥仍然有很大的好处。首先，减少长期密钥的数量意味着可以集中精力进行安全防护，与分析任意工程师的笔记本电脑的安全性相比，分析专门用于让 KMS 进行签名的 EC2 实例的安全性要容易得多。通过减少长期密钥的数量，往往会创建更小、更聚焦的基础设施，这些设施更容易加固和分析。另一个好处是，对安全敏感的基础设施往往比大多数工具需要更严格的管理，严格管理通常意味着要稍微放慢速度，但并非总是需要严格管理，也需要谨慎考虑在哪些方面牺牲速度。之前提到的加密密钥使用限制，肯定不希望它成为任意工程团队的次要问题，从而占用他们用于功能开发的时间，这种问题更有可能被遗忘、被降为次要优先级或处理不当，相反，可以将其作为某个人（或某个团队）的核心工作，为其他所有人一次性解决这个问题。
维护长期密钥建议
妥善维护长期密钥需要付出努力，对长期密钥的一般建议如下：限制给定密钥或凭证的权限范围，例如，可能希望将数据加密密钥的权限范围限定在客户数据的特定分片上；仔细考虑给定密钥的最大使用期限，加密密钥的典型安全模型是“超级计算机需要数十亿年才能猜出密钥”，设定的使用期限也应该有同样可靠和有把握的依据；目标是至少每季度轮换一次长期密钥，从操作角度来看，轮换密钥就像锻炼肌肉，如果定期进行，就可能拥有更准确、更有用的工具或文档，好的工具和文档意味着不太可能错过服务级别协议（SLA）。这种设置很繁琐，不要让每个人都承担这种繁琐的工作，可以将这些工作集中到一个有动力严格执行并一次性为所有人解决问题的团队，减少繁琐工作并集中严格管理是强大安全基础设施的一大优势。
关于 Argemma
Argemma 是一家安全工程咨询公司，专注于为科技初创公司提供实际的安全和工程专业知识。可以直接与工程和产品团队合作，审查设计方案、发现高影响的漏洞，并提供可操作的安全建议。如果正在开发有趣的软件，并且希望增强对产品安全性的信心，请通过本域名下的 hello@ 联系。
