一次主账号AK-SK疑似泄露处理过程

缘起

最近抽业余时间帮朋友看了一眼他的公司的一批阿里云账号，发现一个极为严重的隐患，那就是有主账号访问密钥对（AK - AccessKeyId，SK - AccessKeySecret，后面统一简称AK-SK），且这个AK-SK是明文写在公司App应用的配置文件中，App用它来上传下载客户的文件。这意味着什么？就是任何有心人都有可能拿到这个AK-SK，并且稍微有点开发知识就可以基于这个调用阿里云API做到所有的事情，包括乱开资源、给服务器/数据库加公网地址并登录读取公司数据、删除释放公司的云资源、删除公司所有云上的备份数据，从而给公司造成极其严重的后果。即使不懂开发，也有现成大量的阿里云管理工具，配置AK-SK进去即可拥有最高权限。公司应用到现在还未出问题实属不易，需要尽快解决，下面记录一下帮朋友解决该问题的过程。

初步尝试

启用MFA

考虑过给资源变更启用MFA，这样其他人没有注册手机来接收短信，就可以避免资源危险，但实际查看和测试才发现MFA只对控制台操作有效，所以MFA是否启用，对我们这种情况没有任何作用。

尝试修改AK-SK权限

因为控制台上并没有任何对主账号的AK-SK设置权限的入口，因此向阿里云的专家求助，看他们是否能够帮助我们在后台设置这个AK-SK的权限，让它只能对指定的资源访问，不要有这么大的权限，但可惜的是阿里云方面表示他们也无这样的设置入口，此路不通。

尝试转移AK-SK到某个RAM用户下

同样向阿里云专家询问这样是否可行，但阿里云方面表示也无法做到，一方面动客户的资源是个雷区，阿里云不会这样改动任何客户的资源（除非客户提工单要求提前释放某些资源，或者对底层的资源做运维优化工作），另一方面也没有主账号AK-SK转成子账号AK-SK的途径，毕竟这样可能带来系统上非常大的隐患，此路也不通。

修复方案

不管临时措施怎么样，这个问题本身还是要解决的，在发现这一问题后第一时间拉相关开发，首先要从源头把这个问题堵上，就是赶紧修改App代码，这份代码在这方面存在以下几个问题：

1. 不应该用主账号的AK-SK，应该专门创建子账号的AK-SK并只赋予最小必要资源权限
2. AK-SK这类的敏感配置信息不应该明文存储，至少应该做一层加密
3. AK-SK就不应该出现在客户端上，只应该保存在服务器上，且在服务器上也应该加密存储
4. 服务器上应该尽量也不用AK-SK，如果是云端的服务器（ECS），那么可以设置ECS RAM Role，避免直接使用AK-SK
5. 客户端需要直接访问云资源（比如从OSS上传下载文件），需要先向服务端请求加签的URL，上传下载都可以先给URL签名，然后客户端直接对URL操作
6. 客户端应该尽量避免直接访问云资源，除了一些文件、流量、直播类的操作，如OSS、CDN、视频直播等，其他的都应该发送请求到服务器端完成

做相关的变更后，发现问题并不能迎刃而解，因为新版本的App应用需要在各个应用市场上架，这需要一定的时间，即使上架后外面已安装的成千上万的App用户短时间内也不可能大部分都做了更新，因而这个已经创建的AK-SK还需要保持比较长一段时间，然后才能禁用或者删除

缓解措施

既然危险的AK-SK短时间不能禁掉，那也不能留着系统在如此高的风险下什么都不做，不然在问题AK-SK禁用前，哪天真的被有心人盯上，导致的问题会无法挽回。在联系了阿里云同学确认无法针对AK-SK做任何限制之后，得要思考怎么才能在禁用AK-SK之前尽量缓解这个问题，我们采取的措施如下：

所有的数据跨账号备份

所幸的是当前账号下的持久层并不复杂，主要是RDS和OSS两种，没有Mongo、Redis、NAS、大数据等等一些列其他产品，那么我们主要针对这两种数据做了跨账号备份操作，跨账号备份的原因是AK-SK能对当前账号下的所有资源做操作，只有把数据备份到其他账号去，别人才无法彻底抹除我们的数据。

RDS的备份

在另一个账号中购买开通DBS服务，使用DBS的跨账号备份功能，实现对问题账号的RDS数据的实时备份，达到秒级RPO的能力，万一发生什么问题，我们可以用DBS来恢复数据到之前任何一个时间点。

OSS的备份

在另一个账号里，使用OSS的在线迁移功能，把存量的和增量的OSS文件迁移过去，这样如果当前账号的OSS被做了删除，所有的数据文件还是能够在另一个账号里找回来。

对当前账号资源做实时监控和报警

虽然数据做了备份，但万一整个系统运行环境被破坏了，数据虽然不丢，但业务不可避免的会停顿，重新部署验证整个业务环境需要很多时间，这样RTO也会变得非常大，这对公司也是无法接受的，那我们有没有什么办法来知道是否有人对我们的账号资源来做了什么额外的事呢？答案是肯定的，就是用ActionTrail搭配SLS来一起实现。

ActionTrail的开通使用

ActionTrail支持资源创建、删除和修改的操作审计，且会记录这些操作是来自于何处 - 用户登录的操作还是通过哪个AK的操作，比如我用AK来创建了个SLB：

然后用登录账号删除了SLB：

可以看出两者的操作者的区别。

然后ActionTrail还支持另一项好用的功能，就是同步这些操作日志到SLS中，如：

SLS中的事件查询

还是和上个步骤中的测试一样，因为我们在测试之前已经开通了SLS同步的功能，所以这两个操作其实已经在日志中了。

• 控制台操作资源日志：
  
• 通过AK操作资源日志：
  

然后我们可以进一步在SLS中针对这些日志进行过滤（如只关注指定AK的资源操作，因为控制台操作可控），对正常的业务操作带来的资源变更进行忽略，但和业务无关的资源变动，就设置报警，及时提醒公司的团队来登录处理 - 如果发生了来自于高危AK的不属于业务的资源变更，那就说明可能AK-SK已经被有心人拿到并开始捣乱了，我们需要第一时间来采取应急措施 - 比如临时禁止这个AK-SK，因为访问日志也包括来源IP，我们也可以请求司法机关的协助，让对方停止侵害行为。

当然后面也可以用这个来监控问题AK在业务中的访问量情况，在访问完全消失或者低到一定程度后表明客户基本上都已经更新到App新版本，那么就可以禁用或者删除这个AK了。

ActionTrail的操作日志的同步是秒级的，因此我们可以尽早的发现问题并采取应急措施。

总结

本文写的是如何处理疑似主账号AK-SK泄露的情况，虽然没能第一时间彻底解决问题，但至少也做了一定的缓解，从数据的安全、监控报警方面采取了必要的措施，不用一直提心吊胆的在猜会发生什么情况。但切记切记切记，一定一定不要用主账号AK-SK做任何事情，甚至不要申请主账号AK-SK才是最应该要做的事

这次是公司的App设计不够严谨，但其他公司因为其他原因带来的同类隐患也不少，比如有的公司用主账号的AK-SK（或者子账号的AK-SK）配置到服务端，以为这样就不会出问题，但可能会被员工（不管在职还是离职的）把这部分代码放到公网上（如github）并不设置任何访问权限，从而导致泄露。但这样的问题相对比较好解决，即重新生成AK-SK之后到服务器上配置或者重新发布，然后禁掉泄露的AK-SK就可以了，不像这次这么棘手。