05-访问控制：如何选取⼀个合适的数据保护⽅案？

科技 08-19 来源：为你沉醉english

05-访问控制：如何选取⼀个合适的数据保护⽅案？

在上⼀讲中，我们主要从⾝份认证的场景和威胁上，对⾝份认证进⾏了介绍。同时，⾝份认证的核⼼问题是

⾝份管理，因此我们可以采⽤单点登录的形式，来解决复杂的⾝份管理问题。常⽤的单点登录⽅式包括CAS 流程、JWT、OAuth和OpenID。

“通过⾝份认证，我们只能够确认⽤⼾的⾝份，⽽对⽤⼾的操作和访问⾏为的把控，就是授权和审计的任务了。”

那这⼀讲中，我们就来介绍⼏种常⻅授权机制的概念和原理，以及在实际⼯作中我们该如何去选取合适的保护机制。

访问控制模型

⾸先，在探讨访问控制的机制之前，我们先要来了解⼀下，访问控制的场景是什么。这也是你去理解访问控制机制的⼀个基础。我把访问控制模型抽象成了下图的模型，你可以看看。具体来说就是，⼀个主体请求⼀个客体，这个请求的授权由访问控制来完成。

如何具体的理解这个模型呢？你可以这样想：在⽤⼾去读取⽂件的过程中，⽤⼾是主体，读取这个操作是请作。如果采⽤了role-BAC ，那么管理员只需要简单地将⽤⼾从⼀个⻆⾊转移到另⼀个⻆⾊，就可以完成权限⼾的权限进⾏重新分配。但是，准确识别每⼀个⽤⼾需要哪些权限、不需要哪些权限，是⼀个很有挑战的⼯求，⽂件是客体。下⾯我来详细介绍⼀下。

主体：请求的发起者。主体可以是⽤⼾，也可以是进程、应⽤、设备等任何发起访问请求的来源。
客体：请求的接收⽅，⼀般是某种资源。⽐如某个⽂件、数据库，也可以是进程、设备等接受指令的。
请求：主体对客体进⾏的操作。常规的是读、写和执⾏，也可以进⼀步细分为删除、追加等粒度更细的操作。

常⻅的访问控制机制

访问机制是否对请求进⾏授权，决定着这个操作能否顺利执⾏下去。所以，对于我们来说，了解访问机制的规则⾄关重要。常⻅的访问控制机制有4种： DAC、 role-BAC、 rule-BAC、 MAC。

我们先来第1种，DAC (Discretionary Access Control ，⾃主访问控制) 。

DAC就是让客体的所有者来定义访问控制规则。想象⼀下，你想要从图书馆中拿⾛⼀本书。这个时候，管理员说， “你经过这本书的所有⼈同意了吗？ ”这个过程就是DAC。

在DAC中，访问控制的规则维护完全下发到了所有者⼿上，管理员在理论上不需要对访问控制规则进⾏维护。因此，DAC具备很⾼的灵活性，维护成本也很低。相对的，尽管DAC降低了管理员的⼯作难度，但是会增加整体访问控制监管的难度，以⾄于安全性完全取决于所有者的个⼈安全意识。

这么说来，DAC的特性其实就是将安全交到了⽤⼾⼿中，因此，DAC适合在⾯向⽤⼾的时候进⾏使⽤。当⽤⼾需要掌控⾃⼰的资源时，我们通常会采取DAC ，来完成访问控制。⽐⽅说，Linux中采⽤的就是DAC ，⽤⼾可以控制⾃⼰的⽂件能够被谁访问。

第2种是role-BAC ( role Based Access Control ，基于⻆⾊的访问控制) 。

role- BAC就是将主体划分为不同的⻆⾊，然后对每个⻆⾊的权限进⾏定义。我们还是以图书馆为例。当你想借书的时候，管理员说， “你是学⽣吗？ ”这个过程就是role- BAC。管理员只需要定义好每⼀个⻆⾊所具备的功能权限，然后将⽤⼾划分到不同的⻆⾊中去，就完成了访问控制配置的过程。

role-BAC是防⽌权限泛滥，实现最⼩特权原则的经典解决⽅案。试想⼀下，假如没有⻆⾊的概念，那么管理员需要给每⼀个⽤⼾都制定不同的权限⽅案。当⽤⼾的岗位或职责发⽣变更时，理论上管理员需要对这个⽤的变更。

因此，role-BAC更适合在管理员集中管理的时候进⾏使⽤。在这种情况下，所有的权限都由管理员进⾏分配和变更，所以，使⽤role-BAC可以⼤⼤降低管理员的⼯作难度，提⾼他们的⼯作效率。同样的原理也适⽤于应⽤，应⽤可以对不同的⻆⾊限定不同的操作权限，⽐如：运维⼈员给开发、产品、运维划分不同的机器操作权限。

第3种是rule-BAC ( rule Based Access Control ，基于规则的访问控制) 。

rule-BAC就是制定某种规则，将主体、请求和客体的信息结合起来进⾏判定。在rule-BAC的控制机制中，如果你想要在图书馆借书，管理员会说，“根据规定，持有阅览证就可以借书。”

相⽐较来说，DAC是所有者对客体制定的访问控制策略，role-BAC是管理员对主体制定的访问控制策略，⽽rule-BAC可以说是针对请求本⾝制定的访问控制策略。

在rule-BAC中，有⼀点需要我们注意。那就是，我们需要定义是“默认通过”还是“默认拒绝” ，即当某次请求没有命中任何⼀条规则时，我们是应该让它“通过”还是“拒绝”呢？这需要根据安全的需求来进⾏综合考量。

⽐如，某个服务只提供了80和443端⼝的Web服务，那么防⽕墙配置的规则是允许这两个端⼝的请求通过。对于其他任何请求，因为没有命中规则，所以全部拒绝。这就是“默认拒绝”的策略。很多时候，为了保障更⾼的可⽤性，应⽤会采取“默认通过”的策略。

rule-BAC适合在复杂场景下提供访问控制保护，因此， rule-BAC相关的设备和技术在安全中最为常⻅。⼀个典型的例⼦就是防⽕墙。防⽕墙通过将请求的源IP和端⼝、⽬标IP和端⼝、协议等特征获取到后，根据定义好的规则，来判定是否允许主体访问。⽐如，限制22端⼝，以拒绝SSH的访问。同样地，应⽤也往往会采取⻛控系统，对⽤⼾异常⾏为进⾏判定。

最后⼀种是MAC (Mandatory Access Control ，强制访问控制) 。

MAC是⼀种基于安全级别标签的访问控制策略。只看这个定义你可能不太理解，我们还是⽤图书馆的例⼦来解释⼀下，当你在图书馆排队借书的时候，听到管理员说： “初中⽣不能借阅⾼中⽣的书籍。 ”这就是⼀种强制访问控制。在互联⽹中，主体和客体被划分为“秘密、私⼈、敏感、公开”这四个级别。 MAC要求对所有的主体和客体都打上对应的标签，然后根据标签来制定访问控制规则。

⽐如：为了保证机密性，MAC不允许低级别的主体读取⾼级别的客体、不允许⾼级别的主体写⼊低级别的客体；为了保证完整性，MAC不允许⾼级别的主体读取低级别的客体，不允许低级别的主体写⼊⾼级别的客体。这么说有些难以理解，我们可以这样来记：机密性不能低读、⾼写；完整性不能⾼读、低写（上吐下泄来方便记忆）。

MAC是安全性最⾼的访问控制策略。但它对实施的要求也很⾼，需要对系统中的所有数据都进⾏标记。在实际⼯作中，想要做到这⼀点并不容易。每⼀个应⽤和系统，每时每刻都在不停地⽣产新的数据，数据也不停地在各个系统之间流转。你需要对这些⾏为进⾏全⾯的把控，才能将标签落地。因此， MAC仅仅会出现在政府系统中，普通公司在没有过多的合规需求下，不会采取MAC。

好了，相信你现在已经对4种访问控制机制的特点，有了更深刻的理解了。那你可能要问了，在实际⼯作中，它们是如何应⽤的呢？在实际的⼯作中，我们常常需要将它们进⾏组合使⽤。⽐如，在Linux中，我们除了对⽂件进⾏DAC访问控制，也利⽤了role-BAC定义了⽤⼾组 (group) 的概念。这样，管理员就可以将⽤⼾分配到不同的组中，DAC也会按照分组去定义相应的权限了。所以，使⽤访问控制机制的时候，我们要学会灵活应⽤。

威胁评估的步骤

最后，我想跟你聊⼀下威胁评估。在前⾯的课程中，我们描述了如何去衡量安全以及如何去做安全。但是，

在安全⽅案实际落地的过程中，我们⾸先要考虑的是：⽬前存在哪些安全威胁。只有明确了这些安全威胁，你才能够成功说服⽼板和业务⼈员，去配合你推动安全⽅案的落地。既然如此，我们⾸先要做的就是威胁评估，看看哪⾥有安全威胁。

威胁评估主要有三个步骤：识别数据、识别攻击、识别漏洞。

我们先来看⼀下识别数据。我们知道，安全保护的核⼼资产就是数据。因此，威胁评估的第⼀步就是去识别数据。识别数据的最终⽬的是，当发⽣攻击，某⼀份数据的CIA受到影响时，会对公司造成多⼤的损失。这也是我们衡量安全投⼊⾼低的⼀个主要指标。

⼀般情况下，在识别完数据之后，我们就能推测出⿊客会采取哪些⽅式进⾏攻击，这也就到了第⼆个步骤：识别攻击。识别攻击的核⼼就是，明确什么样的数据有价值被攻击。⽐如，对于公开的数据，没有被窃取的意义，所以⿊客只会通过爬⾍来抓站，⽽不会花费更⼤的成本去盗号。

在识别了数据和攻击之后，我们就需要根据应⽤去识别可能的漏洞了。这也就是第三个步骤：识别漏洞。⽐如，对于Web应⽤，它可能出现诸如XSS、SQL注⼊等Web漏洞。关于这⼀点，业内将常⻅的攻击和漏洞进⾏了总结。⽐如，近两年来由MITRE提出的ATTACK框架⽐较知名。在识别漏洞的时候，我们可以基于这些总结性框架去进⾏罗列。

通过对数据、攻击、漏洞的识别，你就能够知道，公司当前⾯临了哪些潜在的威胁，从⽽可以去思考解决⽅案，并推动它的落地。通常来说，我们需要定期 (⽐如每年) 对公司进⾏⼀次全⾯的威胁评估⼯作，并且随着公司的发展，不断调整安全⽅案。