第三部分 账号扫雷

1 概述（what）

1.1 含义

账号扫雷是指对系统使用的各类账号的认证、授权、鉴权的脆弱性进行梳理和整改的一系列过程的统称。

1.2 原理

账号及权限，无论权限大小，有了账号便可以使用全部或部分功能。账号安全如果做的不好，就给入侵者打开了方便之门。账号安全主要有两个方面，一是认证强度，二是权限合理性。

认证强度的影响因素有口令的健壮性、账号使用的限制条件、是否开启MFA、账号的暴露面等。

1. 口令健壮性即口令在经历暴力破解时的破解概率。口令健壮性的第一要务是不要使用弱口令，据某项统计，全世界使用“123456”作为登录口令的账号约占总量的10%，而排名前十的弱口令合计占比将更高（懒得查询具体数据了）。在以往的护网演练中，攻击队得分的最重要的手段之一也是口令破解。
2. 账号使用条件是指账号使用的一些列约束，例如只能特定的设备和特定的IP登录。通常对于极重要的身份要经过多重的限制措施，例如第一部分所讲的逃生通道，由于权限过大，通常会绑定特定的mac和IP地址。
3. 是否开启MFA同样影响着登录口令被破解的难度。MFA通常有数字令牌和短信验证码。数字令牌又分为软件方式和硬件方式。软件方式通常在智能设备上安装一个支持OTP协议的软件，使用时通过一个种子密钥和一个基于事件的伪随机数算法周期性的生成伪随机口令。硬件方式的原理类似，只不过是通过一个单独的硬件设备来生成动态登录口令。OTP的安全性主要取决于种子密钥的安全性，因此要确保种子密钥在输入动态口令设备后要技术被销毁，同时种子密钥如果长时间未被使用时要设置过期时间。
4. 账号暴露面是一个运营安全问题。在系统的建设、测试过程中会产生大量的测试账号，在后期运用中也会因为人员的流动产生无效的僵尸账号。这些账号可能被授予极高的权限，而且由于很多测试账号主要被用在系统交付阶段，一般不会通过成熟的制度进行管理，因此如果在系统交付后没有刻意回收这部分账号，那么会有极大可能造成安全隐患。

权限合理性的影响因素是最小授权原则是否被认真执行，即是否有对“谁以怎样的方式访问哪些资源”有明确的定义，同时认真落实这个定义中的各种细节。

1. 特权账号滥用。特权账号是指能够登录生产环境的运维系统、管控后台、操作系统、数据库等等与生产系统安全性与稳定性息息相关的账号，尤其是特权管理员账号，例如root和Administrator这类账号。这类账号的危害不用多说，治理办法是将业务场景分为两类，对人员登录的账号，创建与人员绑定的且不能共用的账号，对于机器登录的账号，例如调用API接口的账号（通常被叫做服务账号），创建仅并授予与被调用接口绑定的权限（这个权限范围是有限的并且通常很小，通过几条策略就可以描述清楚）。在此基础上，除了对特定人员，应该在全域禁止使用管理员账号，禁止的方法可以是修改管理员密码，也可以绑定其他要素辅助进行限制（例如限定特定的机器登录root账号）。
2. 账号权限过大，通常由于特权系统缺少有效的授权管理流程导致的，因此在整改的时候需要将过高的权限回收。另外由于人员流动，很多内部人员的账号可能保留已经不再负责的业务域的职责和权限，对于这类账号也要及时交还权限。
3. 合理分权，杜绝特权权限过度集中的情况。如果少数或者个别账号具有很高的权限，那么有可能因误操作或内部人员的恶意行为造成严重的损失，因此需要将重要权限分散开来，由不同的人员来管理。在一些成熟的管控类产品的权限涉及中，会提到“三权分立”的授权理念，即运维管理员、安全管理员和审计员必须不能有交叉重叠的职责，并且必须要有不同的人员来承担对应的职责，避免内部人员监守自盗。

1.3 原则

在上一小节原理中已经或多或少提及了账号安全管理的几条重要原则，这里再提炼一下。

1. 最小授权原则

管理员要注意避免超范围授权，对过期的授权要及时回收，对人员职责变化也要关注。另外，除了对账号权限的最小可用以外，账号的创建也要注意最小可用，尽量避免创建过多账号，增加风险暴露面。

1. 权限分散原则

要避免重要权限过于集中的情况，从机制上避免监守自盗的可能性，谨防内部人员超越职权的行为。

2 目的（why）

账号安全的脆弱性是入侵者最大的突破口，主要原因在于账号的问题容易被忽视，而且许多重要的风险是不可见的，例如某个账号的弱口令，是很难被动被发现的。而系统的漏洞，往往由于各种通告和人们天然的不安全感，容易被重视。但其实账号安全引发的风险比漏洞有过之而无不及。

3 方案（how）

针对护网，总结以下几点安全加固措施。

1. 修改账号口令

可以考虑集中对系统的全部账号口令进行修改，修改的范围包括管控系统、OA系统、操作系统与数据库、员工云账号等等，修改后的口令应满足密码强度要求。一般是不低于8位，包含大小写字母、数字、符号中不少于三种的组合。同时要对系统中的账号进行弱口令扫描，扫描的字典可以从网上收集top100的弱口令。弱口令扫描对技术部门的能力有一点点要求，如果实在做不到，那就老老实实改密码。

1. 回收特权账号

对root、Administrator这类账号，要尽可能回收，对于这些账号启动的进程、访问的服务，要进行降权。

1. 回收僵尸账号

回收僵尸账号即对系统中不再使用的账号或长时间未使用的账号进行发现和禁用的过程。禁用的方式可以是删除账号、冻结账号、注销账号等。这些叫法可能略有差别，但大体都差不多，需要注意的是一些系统的冻结可能只是不能登录，但访问api还是可以的，因此要搞清楚定义。回收僵尸账号的难点在于僵尸账号的发现，一般的做法除了人工调研，就是通过日志排查。这里和第二章的内容呼应起来，只有有日志，才可以从日志中统计出那些账号在一段时间内被使用过，如果可以从系统导出账号列表，再一一比对，就可以发现哪些账号是没用过的。

1. 回收非必要权限

回收权限是最难的一项工作，目前看起来没有什么特别高效的做法，如果大家有经验也可以分享。回收权限可以通过访谈的方式沟通，对于不用的权限再一一回收，也可以通过查询日志的方式统计哪些权限在较长的时间范围内没有被使用过。如果有自动化的权限管理系统流程，那么上述工作会更容易进行。当然，回收权限有一定的自我伤害，对于业务部门的反弹会比较大，因此需要争取组织领导的支持，并且最好请组织领导出面站台或亲自推动。

1. 开启MFA

开启MFA即打开动态口令认证或手机短信认证，有时候需要一定的功能改造，如果一些开源产品或商业产品不支持MFA，还需要自己又能hack。但这项工作的收效是极佳的，对于防御针对单一因素的弱口令攻击有很好的防御能力。

1. 监控账号行为

在护网这个场景里面，应该对账号行为进行观察，发现可疑的行为后快速阻断。这也需要依赖账号的使用日志，具备开发能力的组织可以自行实现或者通过开源代码搭建日志审计工具，如果能力不够的，也可以写一些文本处理脚本进行统计分析，然后通过定期任务执行。当然最简单的方式是购买商业产品。

1. 绑定认证要素

极个别重要系统的重要账号在登录时，可以绑定设备、网络等要素，这需要产品有能力支持，因为放在最后一项。

4 需要注意的一些问题

第一，对于账号全策略有效性验证是一项非常关键的工作，在对账号安全策略进行落地实施的时候，可能会有覆盖不全，执行不到位的情况。因此必须具备反向验证手段去检查执行的效果，这项工作非常重要。

第二，尽量不要用人员姓名及拼音或缩写作为账号，这非常容易导致被暴力破解，因为攻击者很容易获得一个组织人员名单。如果一定要有姓名的拼音或缩写作为账号id的一部分，那么也应该加入一些其他难以被推出和收集的信息，例如随机数。