安全管理最佳实践系列:阿里云Access Key的轮转-阿里云开发者社区

开发者社区> 开发与运维> 正文

安全管理最佳实践系列:阿里云Access Key的轮转

简介: 阿里云访问密钥(Access Key)的轮转对于安全风险的防范(prevention)和缓解(mitigation)具有重要的意义,但是具有一定的运维成本。我们不希望因噎废食,害怕出现运维风险而永久使用同一个Access Key。

在信息安全领域,一个常见的假定就是:所有系统都是可攻破的。当然还有另一个更明显的假定,那就是,攻破任何一个系统都需要时间。这里的“攻破”是广义的,可以是外部攻击,也可以是恶意内部威胁(insider threat),当然也可能是无心的泄漏导致的潜在威胁。

在这两个最基本的假定下,安全管理上衍生出了许多的最佳实践,其中本文将要讲述的就是

  • 最小权限原则(principle of least privilege):减小密钥暴露的攻击面(Attack Surface)
  • 定期轮转密钥:减小密钥的有效时间窗口

当然本文主要是讨论怎样轮转阿里云Access Key,但是由于最小权限原则能极大的简化其复杂度,因此也一并讨论。

基本考虑

在设计一个Access Key定期轮转机制之前,需要对系统的密钥管理有以下几点思考

1. 每个Access Key对应着访问哪些阿里云的资源

Access Key的轮转意味着老的Access Key将失去访问阿里云资源的能力。因此在设计轮转机制之前有必要明确每一个Access Key的影响范围。在一个复杂的系统之中,往往存在多个微服务,而各个微服务往往也是独立部署的。如果轮转一个Access Key需要系统重新部署多个微服务,那么就需要考虑是否微服务之间存在解耦不明晰,或者Access Key访问权限过大的问题。

在企业部署拓扑中一个常见的实践是:访问每一个微服务都使用一个独立的密钥。这实际上是最小权限原则的体现。阿里云作为企业部署拓扑的一部分,其ECS,RDS,OSS等服务都可以看作企业部署的微服务。作为最小权限原则的体现,做了权限分割的Access Key不仅可以减小每个Access Key所暴露的攻击面,也可以更好的控制轮转Access Key带来的影响,减小线上故障的发生概率。

2. 是否需要给Access Key设定一个逻辑上的有效期

阿里云并不强制Access Key的过期失效,但是在密钥管理中,很重要的一环就是设计有效期管理机制。在常见的SSL证书管理中,通常会设置一个有效期到期的报警机制,在证书的有效期到期之前提前通知和报警。如果没有类似的Timer报警机制,则可以用一个脚本定期调用RAM Open API查询Access Key的创建时间,并结合企业监控报警机制(比如将查询到的信息写入日志,监控日志中的关键字等方式),在Access Key的创建时间超过企业规定的有效期之后报警。

轮转的步骤

Access Key的轮转建议按照以下步骤进行:

轮转之前

为了方便描述,假定轮转之前,指定的RAM用户有一个正在使用中的Access Key。我们用下表来描述此用户的所有Access Key,Access Key的状态,以及Access Key在应用中的部署状态。

Access Key Access Key状态 部署状态
旧AK 启用 已上线

注:Access Key的状态有启用和禁用两种,启用的Acces Key可以用来访问云服务,禁用的Access Key不能

1. 给对应的RAM用户创建一个新的Access Key

这一步要在旧Access Key处于启用状态并且正在使用的时候进行。创建的新Access Key默认为启用状态。当前用户有两个Access Key

Access Key Access Key状态 部署状态
旧AK 启用 已上线
新AK 启用 未上线

2. 将新创建的AK部署到应用中,替代旧Access Key

完成这一步之后,两个Access Key分别处于以下状态

Access Key Access Key状态 部署状态
旧AK 启用 全部下线(部分下线)
新AK 启用 全部上线(部分上线)

由于对旧AK的替代可能有所遗漏,因此可能存在旧AK尚未全部下线的可能。

3. 将旧Access Key的状态设置为禁用

由于替代旧Access Key可能存在遗漏,因此建议不直接删除,而是将其状态设置为禁用。

Access Key Access Key状态 部署状态
旧AK 禁用 全部下线(部分下线)
新AK 启用 全部上线(部分上线)

4. 确认应用正常工作

在禁用之后,旧Access Key就不再能用来访问阿里云资源,如果存在应用仍然使用旧Access Key,那么就会产生故障。如果发现了故障,需要立即将旧AK重新设置为启用状态,并回到第2步更新产生故障的应用使用新AK。

经过一段时间的监控,保证所有应用都能正常工作,那么就到达了以下状态

Access Key Access Key状态 部署状态
旧AK 禁用 全部下线
新AK 启用 全部上线

5. 如果经过一段时间的监控,保证所有应用都能正常工作,就可以删除旧Access Key了

这一步是不可逆的,所以请确保没有应用在使用旧Access Key

结语

Access Key的轮转对于安全风险的防范(prevention)和缓解(mitigation)具有重要的意义,但是具有一定的运维成本。我们不希望因噎废食,害怕出现运维风险而永久使用同一个Access Key。为了更好的管理运维风险,一个很有效的处理办法就是运用Fail Fast/Fail Often的原则:

如果你担心密钥轮转会导致系统故障,那么就将密钥轮转尽早集成到开发流程中去,并且尽早进行密钥轮转,经常进行密钥轮转。

简单的说,在测试阶段就Fail可以更早的预防系统风险;在用户还很少的时候就Fail可以防止在用户更多之后Fail产生更大的风险;一个经常出现的故障往往也意味着熟悉的修复流程和快速的恢复;在服务正常运行时有计划的密钥轮转带来的(有预期的)Fail可以得到较快速的处理和对系统的有计划的修复。

而逃避问题不去面对风险,那么当密钥泄漏之后被迫快速进行(无计划和系统设计的,很可能几年都没有人操作过的)密钥轮转带来的风险就是不可控的,带来的商业风险更是叠加在了密钥泄漏的风险之上。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章