在信息安全领域，一个常见的假定就是：所有系统都是可攻破的。当然还有另一个更明显的假定，那就是，攻破任何一个系统都需要时间。这里的“攻破”是广义的，可以是外部攻击，也可以是恶意内部威胁（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可以得到较快速的处理和对系统的有计划的修复。
而逃避问题不去面对风险，那么当密钥泄漏之后*快速进行（无计划和系统设计的，很可能几年都没有人操作过的）密钥轮转带来的风险就是不可控的，带来的商业风险更是叠加在了密钥泄漏的风险之上。