※ 2018年3月，华住旗下酒店（汉庭、桔子、全季、宜必思）1.3亿入住信息泄露，看似一起程序员泄露密码引起的血案，实则是账号体系的不健全导致。对于如此敏感的操作，假如有更多样的用户认证手段（密码+token，密码+短信），也许就能避免；又或者有更完善的权限控制体系（限制用户能访问的区域），也许不至于泄露如此多的数据......

※ 2017年3月，网爆淘宝电商出售“58同城简历数据”，因其多个接口没做好权限控制，被组合后拉取走批量用户信息；或许因某种特殊原因，部分接口需要放宽权限；但做好敏感接口的监控，是不是可以及时发现并减少被拉取的数据量......

........

历史总是用惨痛的经历让我们明白一些道理，假如拥有一个健全的账号安全体系，许许多多的安全事故或许就不会发生、或者泄露的数据没那么多，影响没那么大。

那么，怎样的账号体系才相对比较安全呢？

二、设计一个相对安全的账号体系

以我的有限的经历来看，假如我是账号的使用者，当我在访问某个系统时，一个安全的账号体系，至少需要解决三个问题，即：

解决了这三个问题，我的一举一动系统就都能掌握，也能够控制。首先，只有知道我是谁，才能确定我能做什么；其次，限制我能做什么不能做什么，是从根本上去除安全隐患；最后，一个系统不可能是完美的，即使设计完美，实现上也可能会有偏差，而了解我在做什么，是确认现有策略是否有效，是一个查漏补缺的措施。

这三个问题，用计算机的术语来说，可以表述成三个A，即

那么，如何实现这三个A呢？我们分别来看下：

三、认证 -- 我是谁

1、认证解决了什么问题

认证所要解决的问题，正是“我是谁”的问题，或者说是确认用户的身份。

只有确认用户身份后，才能根据用户的身份确认其能否访问某个域或某个服务。而认证的过程就是“如何证明你妈就是你妈”的过程。

那么，我们要怎么对用户做认证呢，这还得从认证的发展史说起。

2、认证发展的三个阶段

用户认证的方式多种多样，从其演变过程来看，大致上可以分为三类，即

2.1、What you know -- 我知道A的某些私密信息，证明我是A

（1）静态密码类

上面这种密码认证的方式，相信大家再熟悉不过了，而这也是最传统的用户身份认证方式，通过拥有我的正确密码，就确认访问者就是我。相似的方法，还有如下图我们常见的安全问题等固定密码类问题。

这类验证方式从PC时代QQ经常被盗就突显出其安全性的不足，既依赖于用户对私密信息的保护，一旦泄露，即可被冒充；另一方面，也依赖于用户私密信息的复杂度，太过简单或常见，容易被字典攻击破解；还要求用户多个密码不能相同，否则一个泄露，其他的也将被撞库击破。

总之，过分依赖用户安全意识的系统，绝不是一个安全的账号系统。

（2）动态密码类问题

这类问题的答案虽然是变化的，但其归根到底，还是通过我知道什么，而证明我是谁；例如，以下两个场景

A、到中国移动换SIM卡，客户要求我提供最近三次和谁通话的记录

B、登录淘宝时，曾经弹框要求我选择最近购买的东西，或我的常用收货地址

这种方式，要求用户填写是在考验用户记性和耐心，易用性极差；提供选项让用户选择时，被蒙对的概率又比较大，作为辅助验证方式还好，作为主要验证方式则安全性极差，且泄露用户隐私的风险容易被忽视，在国内用户隐私保护意识还比较差，可能还行得通，在欧美估计就呵呵了。

2.2、What you have -- 我拥有A的某个关键东西，证明我是A

这种认证方式比较常见，且越来越多样化，从远古时代的密码卡，到时下最流行的手机短信验证码都属于这种，从当下来说，用户比较熟悉的有如下三种认证方式:

机短信验证，是移动互联网时代最流行的验证方式，也是实名制大方针下，采用最普遍的验证方式；其通过将验证码发送到我的手机，再通过反馈回来的短信验证码来确认访问者就是我，其背后的假设就是谁拥有我的手机，谁就是我。

在手机短信验证方式流行之前，邮箱注册的方式比较普遍，时至今日，还有很多的系统通过邮箱进行验证，如GitHub等，邮箱验证的方式也有两种，一种是发送激活链接、另一种是发送邮箱验证码，其表现形式不同，但判断的逻辑都是一样的，即谁拥有我的邮箱，谁就是我。

再来说说token，其实有软硬token之分，一个依赖于硬件，一个依赖于软件，硬token通过和我的身份做一对一绑定，实现直接关联，而软token则通过其他认证方式确认我的身份后，将我和该软件做了绑定，间接的打通了软token和我的身份关联；但其原理都是一样的，将计算好的token信息在我的关联设备上展示，谁拥有这个token信息，即可证明谁是我。

......

这类认证方式，虽然表现形式多种多样，但其和第一类的问题类似，需要用户保护好拥有的东西，手机/邮箱被盗、借用、偷用等都可以冒用身份。

2.3、Who you are -- 通过提取我的生物特征，证明我是A

随着科技的发展，生物认证的方式得以越来越普及，用户认证的方式也变得越来也丰富，常见的生物认证方式包括但不限于以下几种：

指纹和人脸，技术相对比较成熟（指纹发展更早，变化更少，相对更成熟），现在已经有越来越多的应用在使用这两种认证方式，指纹解锁、人脸开门/考勤大家应该见怪不怪了；而声纹和虹膜，目前应该还不够成熟，应用的场景不多，更多见于影视剧作品中；DNA则更多地受限于应用成本高昂。

生物认证的方式，不要求访问者提供信息，而是从访问者身上采集信息，通过对访问者信息的分析，以及和存储用户信息的比对，假定访问者就是相似度最高且满足设定阀值的已有用户。

顺便提一下，目前，在国内，关于用户身份生物认证方案这块，应用比较多的，就是阿里引领的IFAA联盟方案，已经微信开源的SOTER腾讯生物认证平台。

但生物认证相对前两张方式，用户不需要保存什么信息，似乎更安全；但生物认证大部分本身就不是一个百分百确认的问题，而是一个相识度判断的问题，带来了一定的不确定性，需要结合其他信息进行确认才能说更安全。其作为单一认证方式进行大规模的应用还显得任重而道远。

3、认证应该怎么做

科技发展到今天，依然找不到一种完美的认证方式。但并不代表就没有好的解决方案，我们能做的依然可以有很多；至少，我们可以通过以下两种方式提供更安全的用户认证方式：

3.1、多因子认证

多因子认证，顾名思义就是采用两种及以上的方式对用户的身份进行认证；其背后的逻辑是用户同时泄露两种及以上的私密信息，相对于泄露一种来说，其概率要小得多，故同时验证多种信息的安全度更高，且采用认证的方式越多，账号的安全性相对来说越高。

但认证方式不是越多越好，其对立面是用户的体验将变得更差；所以，还是那句话，具体情况具体分析，如果一种方式足矣满足需求，那就没必要使用多因子认证方式；在多因子认证里，为了取得安全性和用户体验的平衡，一般采用两种即可；在多因子认证里，设备也常常作为一种隐藏的辅助认证信息，用于提高用户的体验。

如在常用设备上，可采用“设备+密码”或“设备+指纹”进行认证，对用户来说，感受到的是只有一种认证方式；而在非常用设备上，则可采用“密码+短信”的认证方式，虽验证两次，但频率较低，用户体验不会有太大损失。

3.2、多级认证

多级认证是指在一个系统中，当用户访问部分敏感的域服务时，对用户进行二次及以上的用户身份认证；可采用不同的用户身份认证方式，也可采用同一种认证方式，但采用密码时，一般要求设置成不同的密码，才能进行有效的防护。

其背后的逻辑，是设置多重保护后，即使上一层的认证被欺骗通过，本次认证也被欺骗通过的难度要相对更大一些，所以，可以更好的保护用户更重要的信息或资产不被盗用，减少用户损失，提升账号安全性。

举个大家可能遇到的场景，当我登录京东时，首先要进行身份认证（密码/短信等），而当我准备买单使用京东里的财产（如京券、京豆）时，需要输入我的支付密码才能使用我的资产；这里使用资产相对于选购物品等操作更为敏感，所以，使用了二次密码，可以更好的保护我的资产。

四、授权 -- 我能做什么

1、授权解决了什么问题

前面的认证解决了用户身份的问题，从而使得系统可以区分不同的用户，对于不同的用户使其能访问不同的服务，而要做到这一点不是你定一个规则让用户去遵循，靠用户的自觉性去实现在网络时间里显然是行不通的，必须有一套明确的权限控制策略；而授权要实现的正是“我允许你做什么你才能做什么，我禁止你做什么你就不能做什么”的能力，具体来说，就是实现以下三点：

2、几种常见的权限控制策略

常见的权限控制策略，有三种

2.1、OBAC--基于对象的访问控制

OBAC，全称Object-based Access Control，是从受限资源的角度出发，对系统中的访问主体和受控对象进行一维的权限管理。

采用OBAC模型的权限控制策略，常见的有两种

（1）DAC: Discretionary Access Control 自主访问控制

这种策略比较简单，就是每个资源都有一个可以访问它的用户列表（ACL），当用户访问这个资源时，检查一下用户是否在列表中，不在则拒绝其访问。

优点：可以满足各类用户访问各种资源的需求。

缺点：权限控制分散，无法将大批资源同时赋予某个用户访问权限；也无法进行集中管理。

（2）Mandatory Access Control 强制访问控制

这种策略的实现方式是，管理员创建一组Level，将每个资源绑定一个Level，每个用户也绑定特定的level，每个用户只能访问所绑定level及其以下的level的资源，不能访问高于绑定level的资源。

优点：权限集中管理，维护简单。

缺点：用户需要访问更高级别level的某个资源时无法完美解决，因为提高level后，无法控制其不访问其他的level。

2.2、RBAC--基于角色的访问控制

RBAC，全称Role-based Access Control，是从用户的角度出发，将不同资源的访问权限分配给不同的角色，再将不同的用户通过扮演不同的角色，获取不同的权限。

这种权限控制一般需要对用户角色进行分级管理，比较经典的是三级权限管理体系，即

（1）超级管理员：可以分配模块管理员角色及其对应的权限

（2）模块管理员：可以分配该模块下的普通角色及其对应的权限

（3）各类普通角色：每种角色只拥有有限的访问权限

适用场景：

A、用户并非资源所有者，但需要访问该资源

B、访问控制基于职责（对应角色）而非谁是资源所有者

缺点：管理员的需要维护用户和角色的关系，资源和角色的关系；当用户数量庞大或资源数量庞大时，需要不停的增删不同角色的不同权限，或者变更不同用户的不同角色，运维任务将变得十分繁重。

2.3、ABAC--基于属性的访问控制

ABAC，全称Attribute-Based Access Control，是通过主体属性、客体属性、环境属性等三重属性作为授权的基础实现访问控制，可以实现复杂场景的权限控制，各种属性举例如下：

（1）主体属性：身份、角色、职位等

（2）客体属性：数据、文件、服务等

（3）环境属性：时间、操作、状态等

优点：通过调整主体、客体、环境三个属性，实现不同粒度的权限控制

缺点：由于权限不够直观，规则复杂且多时，维护起来非常麻烦。

3、什么样的权限控制策略是好的策略

首先，权限控制的策略多样多化，没有绝对的好与坏之分；不同的应用场景，不同的安全需求，需要选择不同的策略或多种策略的组合，一句话，满足需求即可，不必过分追求。

如果没有特定应用场景要求的话，以我浅薄的经历来看，一个好的权限控制策略，至少需要满足两个原则。

最小权限原则（最早由 Saltzer 和 Schroeder 提出），是指每个程序和系统用户都应该具有完成任务所必需的最小权限集合。

职责分离原则，是指不能将利益相关的两个职位分配给同一个人，用运动场上的话说，就是你不能既当裁判员又当运动员！

五、审计 -- 我在做什么

1、审计要解决什么问题

审计更多时候是作为一种安全的能力存在，不止服务于账号体系，也服务于系统的方方面面，但一个较为完善的账号体系，又离不开审计带来的安全能力的完善。

审计是一个连续不断改进提高的过程。一方面，需要评估现行的安全策略、机制是否有效；另一方面也是对系统进行全盘的监控。从账户的角度出发，其要解决的问题，包括但不限于以下三类：

从实现形式上来看，大致分为两类，一类是实时的在线审计，另一类是事后的离线审计。

2、实时在线审计

实时审计就是对当前的会话进行实时监控，并对恶意请求进行实时拦截或告警，常见的方式包括但不限于以下几种：

（1）各类黑库过滤

黑IP库、黑手机库、黑IMEI库、黑设备库等等，只要是在黑库中的请求，即可进行直接拦截或重点监控。

（2）聚集分析

账号(UIN/手机号/邮箱/户口所在地等)聚集、IP聚集（IP聚集/IP频繁变更/区域聚集等）、设备(IMEI/GUID/MAC地址)聚集、时间段聚集等，只要有易于往常的明显聚集出现，即恶意攻击的可能性大大增加，可进行告警，人工介入分析；更严重的情况，也可进行拦截。

（3）波动分析

对来自某个业务的请求过大时，可进行限流限频，防止其可能遭受的恶意攻击影响到其他业务正常运行。

对访问量大幅波动的情况，进行告警，人工介入，查看是否正常。

对访问量超过阀值的情况，进行告警，人工介入，查看是否正常。

3、事后离线审计

事后分析既是一种补救的措施，也是一种补充的措施，相对于实时在线审计，离线审计可以在更大的时间范围，做和实时审计相同或不同的分析，从而发现在线审计发现不了的问题，常见的方式包括但不限于以下几种：

（1）构建各类黑库

用更大量的数据去确认线上的可疑对象是否真的是恶意请求，从而建立起更准确的各类黑库，反馈到线上，用于线上实时打击。

（2）构建用户画像

除了直接拉入黑库外，对其余用户进行归类分析处理，以便后续对可疑用户进行重点关注；对安全用户减少关注，但仍需定时审计，以便更合理的利用计算机资源。

（3）改善系统安全

对于已发生的安全事件，可通过审计日志，回溯事件，确认问题所在，用于改善系统安全能力。

六、小结

保护用户的账号安全，需要在背后做很多的工作；很多细节都来不及展开（后续有机会再写），泛泛而谈就已经写了这么多；账号安全相关的知识肯定也不止我写的这些，能力有限就写到这吧。

最后，汇总一下前面提到的点，小结一下，如下图：

七、后话

需要说明的是，本文探讨的是怎样构建一个相对安全的账号体系；并不是说，所有的系统都要做到这种安全级别，对于一个没有重要信息或资产，安全性要求也不高的系统，做下简单认证，验下登录态足矣，浪费过多的资源，为其搭建一个庞大复杂的账号体系，反而是拿着牛刀来杀鸡；还是那句话，满足需求即可。

同样地，做到这种安全级别也是不够的，只能说，在当下相对安全而已；随着科技的发展，安全手段在不断增强；未知的安全威胁也在不断增加，让我们一起努力为用户构建一个更安全的账号体系吧。

最后的最后，引用下电影《我是谁：没有绝对安全的系统》的一句话给自己以及账号安全体系的设计者们：

微信公众号：「新猿一马」，微信扫一扫。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/weixin_40725706/article/detail/122106

如何构建一个相对安全的账号体系？_账户体系 权限 最早哪里出现的

一、你的账号安全吗？