访问控制模型

具体来说，一个主体请求一个课题，这个请求的授权由访问控制来完成。

常见的访问控制机制

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

DAC就是让客体（资源）的所有者来定义访问控制规则。例如Linux采用的就是DAC，用户可以控制自己的文件能够被谁访问。

Role-BAC（role Based Access Control，基于角色的访问控制）

管理员只需要定义好每一个角色所具备的功能权限，然后将用户划分到不同角色中，就完成了访问控制配置的过程。

Role-bac是防止权限泛滥，实现最小特权原则的经典解决方案。

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。

在实际工作中，常常将4中访问控制机制组合使用

比如，在 Linux 中，我们除了对文件进行 DAC 访问控制，也利用了 role-BAC 定义了用户组（group）的概念。这样，管理员就可以将用户分配到不同的组中，DAC 也会按照分组去定义相应的权限了。

威胁评估步骤

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

三个主要步骤：识别数据、识别攻击、识别漏洞

一般情况下，在识别完数据之后，就能推测出黑客会采取哪些方式进行攻击

识别攻击。识别攻击的核心就是，明确什么样的数据有价值被攻击。比如公开的数据，就没有意义

识别漏洞。比如，对于web应用，他可能出现如xss、sql注入等web漏洞。比如，进两年来由MIRE提出的ATTACK框架比较知名。

https://attack.mitre.org/

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

标签：DAC,访问控制,05,用户,bac,客体,识别,数据保护
From： https://www.cnblogs.com/Adam-Ye/p/17715639.html

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