|
目录 |
|
- 缘起 |
如果你是一名黑客，你是试图直接攻击一个层层加固、布满各种检测技术、24小时人员职守的系统并窃取数据。还是选择通过社会工程学的方式获取系统账号后，如入无人之境地查看、下载数据。
大多数情况从外部发起攻击都需要经历建立据点、搜寻目标、获取权限、拿到数据的几个阶段。对于一个基础安全牢固且运营良好的系统而言，直接攻击将耗费大量的时间和精力，而通过社工等方式获取系统特权账号则成了一条捷径。
缘起
云环境相比传统环境，新增的一大风险即用户Access key的泄露风险。AK是应用程序调用云平台API时使用的认证凭据。一个用户的AK泄露往往代表用户在云平台最高权限的泄露，云环境中所有计算、存储资源对入侵者门洞大开。非法利用者甚至不需要为此单独开发工具，直接使用现成的产品就能直接获取用户在云内的所有资源列表。
将AK导入商用的产品后可轻松获取用户云上资源
入侵者实际能做的还远不止这些。包括轻易查看当前用户所有的数据资产，在主机资产上执行任意命令，修改存储访问权限，数据库账号创建、提权，增加高权限用户，删除日志等等，可谓是无所不能。所以不能简单地将云平台的AK当作单个系统的*权限，而是云上所有资源的*权限。这也注定了用户在云上的AK将成为攻击者的重点目标。
AK功能强大，基本上管理员账号能做的AK都能做
当前主流AK泄露检测方式
从Gartner预言至少90%的云安全事故是因为用户的错误配置导致，到CSPM成为热门。AK泄露的检测其实并不是一个全新的领域。但是现有对于云平台AK泄露的手段主要还集中在检测代码泄露这一个途径上。
将仓库克隆到本地后就可以通过正则表达式来搜索，当时实际的扫描会更复杂一点，github承载的代码已经非常庞大了。
这种检测方式主要思想为：每次用户commit代码，添加新的文件或修改现有的文件时，密钥泄漏检测模块就会被启动。扫描被硬编码到代码中的Access Key和Access Secret字符串，将疑似AK的字符串发送给对应合作伙伴处进行确认，一旦合作伙伴匹配上真实的AK，即认为发生了AK明文泄露。随后对AK的拥有者发送邮件告警。
按照这位老哥在这里的测试，他故意提交包含AWS明文AK的代码到github平台测试恶意攻击者利用的时间。从提交代码到收到AWS 平台发出的AK泄露告警邮件，中间时间间隔不到1分钟。
而需要注意的是代码提交6分钟后，故意泄露的AK已经被3个攻击者利用，而且产生了查询S3存储桶的日志记录。
之所以有6分钟的延迟，还是因为github平台 commit 的事件订阅流有5分钟延迟。也就是说扣掉这5分钟延迟，攻击者和git平台几乎同时发现用户泄露的明文AK（扣除发邮件的时间，可能github平台稍快一点？不过重点还是在于攻击手段之普遍）。
这种通过扫描程序员代码中硬编码AK的检测技术，有点类似于密码撞库，其优点在于：
1、能在AK泄露的第一时间尽早发现，运气好的话AK此时还未被真正利用，给AK拥有者留了一定的反应时间。但是鉴于恶意使用者的扫描速度，以及从收到通知到完全禁用AK中间的操作时间，这个时间还是不容乐观，最好能通过SOAR工具进行自动化响应。
2、可检测的AK种类不局限于单个平台。目前国内的阿里云、腾讯云、京东云的AK都在github官方支持的范围内。https://docs.github.com/en/code-security/secret-scanning/secret-scanning-patterns#supported-secrets-for-partner-patterns
但是，这种方案的问题也很明显：
- 对于非git平台上传的代码无法检测。代码管理平台那么多，不是每个都集成了AK明文检查。而且git平台的合作伙伴数量也很有限，并没有覆盖企业用户的核心供应商，这是非常致命的问题。而且在越来越多的企业信息管理趋严，禁止员工将代码上传公共平台的情况下，这个方案的效果将比较有限。
- 内部人员被网络钓鱼、社会工程后泄露的AK无法及时发现。极有可能发一个免费领云平台代金券的钓鱼邮件就能收获到一堆的AK，参照某学校发邮件领月饼的测试。
- 这种检测方式无法检测通过第三方系统暴露的AK，云平台AK应用范围极为广阔，云厂家在努力构建生态的同时，各种生态的合作伙伴水平参差不齐，容易成为整个环节的短板，一旦发生从第三方泄露的事件，极有可能又会产生对云平台的信任危机，以及最终责任难以追溯。
- 最后还是跟第三方有关，用户在开放AK给第三方时，如果没有做到良好的访问控制，不受监控的第三方可能滥用AK权限读取和保存过多原本它不应该读取的数据。
当然除了代码库扫描以外，还有其他的检测方式，比如通过浏览器插件来扫描隐藏在跨源http请求中的AK，但这些方案目前都还不是企业级方案。
防止AK滥用的关键要素？
AK滥用的问题需要从平台方和用户方两边共同解决。平台方需要提供足够多的安全措施，而用户则需要做好特权的管理。
1、默认安全：安全与开放和便利天然就是对立的，从云平台的角度来说对于开放API的范围以及开放的形式需要更加谨慎。高危的功能以什么形式开放，执行权限和编辑权限是否同时对外开放等。应该经过充分的安全评估后，再决定对外开放的范围。
2、分权。避免权限滥用最重要的就是做分权，这是API设计思想层面的改造。在给子账号分配权限时，将API分为读、写操作能达到及格的水平。按API业务属性和管理属性区分会更适合。参照三权分立的思想，创建密钥、重置主机密码这类授权类的读写API，与资源列表、弹性配置等业务数据类的读写API分开。上传任意自定义脚本与运行已经上传脚本的权限分开。最安全的方式也是云平台推荐的方式即删除主AK，只保留子AK。
3、审计和检测。对于AK的利用行为进行审计，记录下请求发起方的角色、调用的记录、读取的实例范围等内容。用以评估是否有AK在用户不知情的情况下被调用。在这基础上可以进一步基于行为进行调用风险的检测，对于某些特定的API调用序列进行告警，高风险API的调用告警。这一点似乎还没有哪一个云平台做到足够的重视。
4、访问控制。平台方有义务提供足够多的访问控制手段，包括不限于单独限制每一个AK访问源IP、访问时间段、可以访问的资源集/资源id、可以调用的API的范围。尽量从API权限层面缩减暴露面，减少不必要的访问风险。不过这么基础的能力，目前却只有华为云做了，而且不能单独对AK进行设置。限制key的使用范围是非常有必要的，但是访问控制不能解决所有的问题。因为高权限的key始终存在泄露的风险，除非高权限的key不存在。
这些都是在git平台泄露检测以外，出于安全的主观视角去考虑应该如何防止最高权限被滥用。当前主流云平台可提供的检测方案与理想还存在不小的差距，更别提还有很多云平台连AK泄露检测都还没有。
对于企业用户而言问题要更棘手一点，AK只是特权账号的一种，分散在各级系统、产品、控制台中的特权账号依旧无法得到有效管理。用户也无法被动指望自己的所有供应商都提供足够的特权管理手段。站在用户的角度来看，特权账号的管理必须是一个统一的产品，而不是松散的产品集合。但是目前并没有一个产品能够提供所有的保护手段。
哪些算特权账号管理？
特权账号广泛分布在企业内部的各个操作系统、应用程序中，而一旦发生云平台AK这种*权限的泄露将危害无穷。按照权限级别，大致可以分为以下3类。
根据账号的属性分，大致可以分为4类。
对于特权账号的管理，重点则在于对这4类账号中的高特权的管理员账号进行识别和管理。
如何做特权账号管理？
特权管理的思路本质上与管理其他的资产没有太大的区别。为了达到最佳效果，特权管理解决方案应该至少接入ATT&CK框架中常用到的本地账号、域账号、云账号。并且能够做到：
- 能够协助企业管理人员识别分散在内部各种系统中的特权账号-包括root账号、公用账号、高权限管理员、SSH密钥、证书、API key等等。
- 持续监控账号状态，包括账号的权限变更、轮换记录、使用范围等信息。
- 根据账号的权限等级和用途，将特权账号的使用监控起来，审计特权账号的所有使用记录，包括特权账号的登陆设备、访问源、访问目的、访问时间、访问数据范围等信息，及时发发现对关键文件和目录的未授权访问和/或更改。
- 最好能根据账号的使用记录自动学习生成每个账号的安全策略。再通过人的运营来补齐管理策略。
- 能对特权账号的可疑行为进行告警。必要时并可以联动其他设备，阻断恶意的访问行为。对可疑的活动进行阻断或放行后，能持续更新账号安全策略。
特权管理与堡垒机、IAM、零信任的关系？
堡垒机、IAM、零信任都属于特权管理的一部分，在特权管理的实施层面提供支持。这些产品在各自领域都能发挥特权访问控制的能力，应该利用他们自身的认证、审计和管控能力，保证特权管理策略落地。
而零信任平台则是在将来最有希望能够成为统一大PAM的平台。只是目前的阶段还挣扎在权限控制的大坑里。
特权管理是否应该侵入到业务流程中？
对于特权管理平台的建设，是否应该做一个大而全的系统，不仅仅是监控特权账号的滥用，还要深入到特权账号的整个生命周期中，将特权账号创建、使用、删除、审计全部管理起来？
我个人认为在初期没有必要，不要过度追求一个完美的系统。不同类型的账号管理方式差异很大，包括认证方式、密码轮换策略、访问控制策略等都不相同。如果在一开始就将所有的东西集成在一个大的平台内，会导致这一个平台的工程量和建设周期被无限拉长，且变得过于依赖执行层面的设备，然后面临大量定制开发。
相反通过采集这些特权账号的使用日志，通过大数据的方式检测特权账号的生成、使用、泄露。以及特权账号，会更容易落地。并且可以与恶意行为关联起来。
这个世界总会有新的变化，你无法阻止它们。安全不是阻止未知的事物或做一些很酷的新事物。决定你能做什么不能做什么，并集中精力把基本的事情做好。
参考资料：
1、Privileged Attack Vectors
2、Detecting and Mitigating Secret-Key Leaks in Source Code Repositories
3、 https://www.anquanke.com/post/id/275261 云主机AK/SK泄露利用
4、 https://docs.github.com/en/developers/overview/secret-scanning-partner-program Secret scanning partner program