安全管理最佳实践系列:阿里云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可以得到较快速的处理和对系统的有计划的修复。

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

目录
相关文章
|
6月前
|
安全 Linux Nacos
解决“nacos默认secret.key配置不当权限绕过漏洞“
解决“nacos默认secret.key配置不当权限绕过漏洞“
1083 0
|
2月前
|
Kubernetes 安全 API
Kubernetes系统安全-授权策略(authorization policy)
文章主要介绍了Kubernetes系统中的授权策略,包括授权模块的概述、RBAC授权模块的详细说明以及如何创建和管理角色(Role)和集群角色(ClusterRole)。
53 0
Kubernetes系统安全-授权策略(authorization policy)
|
2月前
|
Kubernetes 关系型数据库 MySQL
Kerbernetes使用Secret资源配置铭感信息
文章介绍了如何在Kubernetes中使用Secret资源来配置敏感信息,包括基于环境变量引用Secret、创建tls类型Secret和创建镜像仓库类型的Secret的案例。
32 0
Kerbernetes使用Secret资源配置铭感信息
|
3月前
|
Prometheus Kubernetes 数据安全/隐私保护
使用kubeseal加密和管理k8s集群的secret
使用kubeseal加密和管理k8s集群的secret
52 2
|
3月前
|
存储 数据安全/隐私保护
【Azure 环境】Azure Key Vault (密钥保管库)中所保管的Keys, Secrets,Certificates是否可以实现数据粒度的权限控制呢?
【Azure 环境】Azure Key Vault (密钥保管库)中所保管的Keys, Secrets,Certificates是否可以实现数据粒度的权限控制呢?
|
3月前
|
存储
【Azure 环境】当Azure Key Vault中存储的证书即将过期时,如何设置Alert邮件警报?
【Azure 环境】当Azure Key Vault中存储的证书即将过期时,如何设置Alert邮件警报?
|
5月前
|
存储 域名解析 前端开发
云上攻防-云服务篇&对象存储&Bucket桶&任意上传&域名接管&AccessKey泄漏
云上攻防-云服务篇&对象存储&Bucket桶&任意上传&域名接管&AccessKey泄漏
169 8
|
5月前
|
存储 Kubernetes 安全
云上攻防-云原生篇&K8s安全&Config泄漏&Etcd存储&Dashboard鉴权&Proxy暴露
云上攻防-云原生篇&K8s安全&Config泄漏&Etcd存储&Dashboard鉴权&Proxy暴露
121 5
|
5月前
|
存储 安全 API
使用KMS为Apollo配置中心敏感配置加密的最佳实践
使用KMS为Apollo配置中心敏感配置加密的最佳实践
596 2
|
6月前
|
敏捷开发 测试技术 持续交付
云效产品使用常见问题之不知道哪里配置access权限 如何解决
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。