Live软件开发面面谈——权限

我不是女神ヾ 2022-05-14 11:16 69阅读 0赞

# 第6章  权限 #

闲人莫入、机关重地，非请勿入、日剧中命案现场的立入禁止、神剧里文件袋上的机密绝密标签、物业小区的来访登记，出入示证、政府大院的警卫、女生宿舍楼下的阿姨、公司办公室的门禁……这些美妙的标语和人物都提醒我们世界上有些地方不是任何人都可以进的，有些事情是要有相应的权限才能做的。信息世界是对现实世界的模拟和扩展，自然也有和上述事物对应的概念。一个信息系统的使用只要不是无限制无差别的，就会有权限的需要。有选择地限制某个资源的存取/访问（Access）——存取/访问控制（Access control），就是信息系统针对这个问题的做法的统称。存取控制涉及的主体可能是一个人、一只狗、一辆汽车、一个程序，在下面的叙述中，如果是对所有类型都适用的一般论述，就沿用主体之术语，如果主要是针对人（比如使用网站输入用户名和密码的主体），就用用户这个词。存取控制中的资源也是一个范围很广的概念，它不仅指文件、网页、端口这样实在的对象，在业务系统里更多地指用户执行的命令、操作、动作。Access则是一个中文中没有与之完全对应概念的词，主体对资源任何形式的“使用”都在其范围内：阅读、修改某个文件，使用某个端口，点击某个按钮，运行某个程序，执行某个动作……

我们先来看两次网络聊天的真实案例。美女许天仙在上网聊天。慕名已久的王二狗邀她见面，为了防止到时认错人，二狗开通了视频。天仙看到二狗的真面目后说：“我只和帅哥见面。”张三风听闻此事，也去约天仙见面，他发了一张照片过去。天仙还是拒绝了。三风不解：“你不是喜欢帅哥吗？”天仙答曰：“你竟然想用我的男神竹野内丰（读者如认为他不是帅哥可自行换成金秀贤，在下十分好奇“美男”、“帅哥”之类的概念外延有多大，长相差异如此大的两人怎么能被划定为一类人）的照片骗我？”上面的场景用存取控制的术语来解读就是：许天仙仅仅授权帅哥和他见面。王二狗身份验证没问题，存取审批失败。张三风存取审批会成功，如果验证不失败。痛定思痛，王二狗和张三风决定学习一些存取控制的知识。

完整的存取控制包括身份验证（Authentication）、授权（Authorization）、存取审批（Access approval）和审计（Audit）四个过程。身份验证指的是校验一个主体具有某个身份（Identity）之声明是否属实。授权指的是为主体设置对资源的存取权限。存取审批指的是根据主体的身份和权限，实际批准或驳回主体对资源的存取。审计指的是记录存取控制中的各种动作，以供检视和评估。本章将介绍身份验证的理论、Web应用中本地和第三方验证的机制，然后分析现实中应用最广泛的基于角色的存取控制，并由它的局限性引出另一种基于属性的存取控制。

## 6.1  身份验证 ##

身份验证是整个存取控制过程的起点，也是后续进行授权和审批的基础。我们先来看看身份验证涉及的一些理论概念。

### 6.1.1  验证类型 ###

我们在日常生活中对身份验证并不陌生。设想有一天你被宇宙正义联盟选中，去X行星和联盟的地下工作人员接头。进了红玫瑰酒吧，你找到在吧台前坐着的身穿黑色风衣、领口插着一片枫叶的A君，凑到他跟前。A君快速打量了一下你，说道：“牛郎会织女。”你连忙说：“天若有情天亦老。”支线剧情一，A君热烈地抱住你：“同志，我终于等到你了。”支线剧情二，A君漠无表情地转回头去。你正在着急，旁边一位一直在暗中观察你们的中年人走过来说，“A君，没错，他就是联盟派来的B同志，我以前在地球总部见过他。”于是A君热烈地把你抱住。

在上面这段每个人都可能有的平凡经历中，在两条支线剧情中，你最终都通过了身份验证，不过类型不同。第一类是将被验证者的某些有判别能力的属性与他所声称具有的身份的属性作比较，我们不妨把这种类型称为直接验证。A君用于验证你身份的属性就是是否知道正确的接头暗号。第二类是有一个具有公信力的第三方证明被验证者的身份，可以被称为间接验证。支线剧情二中，A君就是因为他信得过的中年人的话，确认了你的身份。间接类型相当于把验证的工作转交给第三方，此第三方可能是直接验证过主体，也可能是通过另一个第三方，但终究要由某个验证者进行直接验证。所以验证的关键还是直接验证中的有判别能力的属性。

### 6.1.2  验证属性 ###

所谓有判别能力，就是说对于该属性，只有某个身份对应的主体才能出具该身份的属性值。理论上这又分两种情况。第一种验证属性的值和身份一一对应，被验证的主体出示某个属性值时，能够被匹配到唯一的身份，例如身份证、指纹。第二种多个身份可能具有相同的属性值，因此校验者单凭主体出具的属性值无法匹配到唯一的身份，而是检查主体声称所具有的身份的属性值是否和他提供的属性值一致。最典型的例子就是密码。一般情况下，用户都有设置和修改账号密码的自由，所以出现多个账号的密码相同的情况是不可避免的，必须同时出具账号和密码才能确定用户的身份。依据验证属性的本质，它们可以分为三类，即三种验证要素（Factor）：

1.  知识要素：即主体所知道的，如密码、身份证号、安全问题的答案。
2.  拥有要素：即主体所拥有的，如身份证、ID卡、某个号码的手机、USB-KEY、安全令牌等。
3.  内在要素：即主体所是或有特征的所为，前者如面孔、嗓音、指纹、视网膜、基因序列，后者如签名。

采用某种属性验证身份时，最重要的就是防止冒用身份。从冒用者的角度考虑，要伪造某个特定或任意的身份的属性值，能否得逞取决于几个因素。首先是伪造或盗用属性值的难度。输入密码显然比伪造身份证或银行卡容易，反过来银行卡被人窃取却又比其密码被人窃知更有可能发生。某个主体所知道的可能被其他主体有意无意知道，某个主体所拥有的也可能被其他主体占据和使用。相较于这两类要素，内在要素，特别是主体所是的生物性的要素，是三者中最不易被冒用的。其次是属性值的集合大小，也就是属性有多少个可能的值。假如集合不大，冒用者就可以将所有的值尝试一遍，即暴力破解。所谓的密码强度，就是以其长度和所用字符种类来衡量，两者的数量越大，所有可能的密码数量就越大，冒用者尝试成功的可能性就越小。再次是验证失败时再度验证的难度。身份所有者也有可能失误，导致验证失败。因此系统必须允许用户多次尝试。不过对此更加渴望的是冒用者，他们最需要的就是能不加限制地反复尝试。所以系统最好区分这两种需要。最常用的方式是限制失败时尝试的次数，超过时锁定该账户。有些系统如Lotus Notes则指数式地延长每次尝试前需等待的时间，这样既给了粗心的用户机会，又有效地防止了冒用者的无穷尝试。

使用的难度和成本也会影响一种验证要素的应用。采用知识要素的验证是最易实现的，也是信息系统最早和最广泛使用的。拥有要素是日常生活中用得最多的——身份证。从用户的角度说，内在要素是最友好的。用户既不需要费心想一个和记住密码，也不用携带USB-KEY，自身的属性就能用于验证。不过利用内在要素验证的技术要求和成本也最高，应用场合不如前两者多。

上面讨论的都是仅仅使用某一类验证要素。一个提高安全性的简单有效的方法就是同时使用两类或三类验证要素，这被称为多要素验证，最常见的是使用知识和拥有要素的双要素验证（Two-factor authentication）。我们从ATM机取款就是一个典型的例子，验证账号主人身份需要银行卡和密码的组合。其他金融系统的例子有网上银行所用的USB-KEY、财务使用的安全令牌。比起这些专用的拥有要素，手机因为随身携带和使用便捷，现在被广泛用于各种场合的双要素验证。系统将验证码发到用户绑定号码的手机上，用户提交验证码以确认是该手机的主人。

### 6.1.3  知识要素验证 ###

以抽象的过程来描述，任何验证都有以下几个步骤：

1.  主体声明具有某个身份，或要求访问某个需要一定权限的资源。
2.  验证者提出问题。
3.  主体回答。
4.  验证者根据答案判断主体是否具有声称的身份。

上面的第二步和第三步，在信息技术中通常被称为挑战（Challenge）和回应（Response）。挑战和回应的性质决定使用的是哪种验证要素。比如验证者要主体提供指纹，利用的就是内在要素。不过验证要素分成三类，是从要素的本质衡量。对我们关心的信息系统来说，无论采用哪种要素，都要被转换成数据发送给校验者，然后凭藉某种算法和已知的数据得出判断，因此从校验者的角度看，它们都可以被看作知识要素的某种形式。

最简单的挑战回应当然就是问主体一个口令，主体输入口令，验证者检查口令是否正确。这样的验证系统开发起来就像一项平凡的业务功能，只需读取一条数据库记录。安全一点可以加密保存用户的口令，得到某个用户提交的口令后，不是直接比较，而是以同样的算法加密，再与保存的值比较。这种简单实现的前提是主题与验证者之间传递口令的通道是安全的。否则恶意用户可以在传递过程中窃取口令。于是问题变成如何不直接传递口令，而又让验证者确信主体知道口令。有很多种聪明的方法可以做到这一点。比如双方把口令当作加密键使用，验证者加密一个随机整数发送给主体作为挑战，主体用口令解密得出该数，加一后再加密发送给验证者作回应，验证者解密回应，和原随机数做比较，就能确定主体知道口令。

从信息技术的角度看，当主体和验证者不在本地而分处网络两端时，验证过程涉及到主体和验证者两个系统以及居于其间的信息通道。可以为身份验证设计专门的协议，如Kerberos、NTLM，也可以在通用的应用协议（如HTTP）上开发。主体和验证者的地位也不是绝对的，当主体需要验证对方的身份时，两者的角色就对调了。网络中计算机之间的相互验证，用户和网站之间的双向验证，都是这种状况的例子。

6.2  Web应用的验证  
6.2.1  验证与会话  
6.2.2  第三方身份验证  
6.3  授权  
6.4  基于角色的存取控制  
6.4.1  用户与权限  
6.4.2  群组与角色  
6.4.3  权限与操作  
6.4.4  实现  
6.5  基于属性的存取控制  
6.5.1  资源与存取方式  
6.5.2  从权限到属性