我们大多数人都听说过基于角色的访问控制 (RBAC) 及其稍微更新的后继者，基于属性的访问控制 (ABAC)。但我们并不总是欣赏它们包含的所有伟大想法。
当今最常见的“RBAC”系统已被精简，使其比原始概念弱得多。通过回到最初，我们可以构建一个真正的 RBAC/ABAC 安全模型，它比您之前可能看到的更简单、更强大，适用于非常小的和非常大的网络。
用户、角色、对象类型和策略都是 1992 年向世界介绍 RBAC 的论文中的所有内容，尽管使用了不同的术语。
几乎每个人都已经在使用用户、组和 ACL。许多人认为他们已经完成并称其为 RBAC，但事实并非如此。几乎没有实现完整的 RBAC 模型：
- 每个人都是一个用户（主体）。
- 每个用户都有一个或多个角色。
- 每个对象都有一个或多个标签。
- “安全策略”定义了从（角色、标签）转换为权利的公式。
- 执行层编译安全策略并为每个对象生成有效的权利列表 (ACL)。
这个模型其实并不比普通用户+组模型更难构建……只要我们从一开始就在系统的核心中进行构建。
我们的Tailscale系统管理的对象是设备和端口而不是文件，但所有概念的应用方式与它们在文件系统中的应用方式相同。结果是一种看似简洁的设计：设备或容器所有者可以在其中应用标签；安全团队可以决定谁拥有哪些标签以及该标签授予哪些角色哪些权限；身份/人力资源团队可以决定哪些用户担任哪些角色。
Windows的RBAC系统
让我们看看一个简单的文件系统安全模型，比如在 Windows 上：在 Windows 上，每个文件（或目录）都有一个用户和组列表，以及每个用户和组可以对该文件执行的操作。这是一个访问控制列表 (ACL)。所有者设置 ACL，然后操作系统强制执行它。
在 Windows 文件系统 ACL 中，您有：
- 用户：对文件进行操作的人。在古老的 RBAC 术语中，用户被称为“主体”。
- 组或角色：管理定义的用户集合。
- 文件：被控制的资源。（也称为“客体”，就像在语法中一样。主体作用于客体。）
- 许可或权利：主体-动作-客体规则。有时我们认为主体“拥有”权利或对象“允许”许可，但从两个不同的角度来看，这是同一回事。
- ACL：权利列表。
每个文件都有一个 ACL（权限列表）。ACL 可能会从它所在的子目录的 ACL 继承一些条目，或者不是，但这现在并不重要。
具有相同 ACL 的文件可能会在磁盘上对其 ACL 进行重复数据删除，但这是一个实现细节。
重要的是，每个文件都有一个 ACL。如果您想更改谁可以访问该文件，您必须：
- 更改 ACL 中组（角色）之一的成员资格；或者
- 更改 ACL 以添加或删除权限。
如果您想一次更改一堆文件的 ACL，您可以更改组/角色成员资格（简单），或查找所有相关文件并为每个文件更改 ACL（缓慢且容易出错）。
几乎您使用过的每个系统，无论是否使用 RBAC，都可以让您找到所有有趣的对象并更改它们的 ACL。而且您可能没有仔细跟踪所有这些对象。在分布式系统中，这些对象可能遍布世界各地，存储在许多不同类型的存储系统中，都依赖于您的身份系统，如果您意识到给定的权限是错误的，您必须查找该权限的每个副本许可并修复每个，否则您会遇到安全问题。
RBAC的前世今生：DAC与MAC
RBAC 和 ABAC 的概念和术语起源于几十年前的美国军队。基于角色的访问控制（Ferraiolo 和 Kuhn，1992 年）是一个很好的介绍。
我从来没有当过兵，而且在 1992 年我对访问控制一无所知，但这里似乎已经发生了变化。
首先是自主访问控制 (DAC)，这在今天仍然很常见。使用 DAC，对象的所有者可以为其授予权限。
因此，如果您在 Unix 中拥有一个文件，您可以设置文件权限（“模式”，因此chmod是“更改模式”）以授予其他人对其的读、写或执行访问权限。或者，如果您拥有 Google 文档，则可以按共享按钮并授予访问权限，等等。
军人不太喜欢 DAC，因为超级机密的东西很容易以不符合政策的方式被转发。但这在普通人中仍然很常见，也很合理。
强制访问控制 (MAC) 加强了这一点。MAC 很难解释，因为你不经常看到它。当您这样做时，您可能不会将其视为“访问控制”。
[注意：不要将 MAC（强制访问控制）与网络中使用的“MAC 地址”（媒体访问控制器地址）混淆。他们没有关系。]
MAC 是某个管理员或管理规则在某处定义规则。有了 MAC，您做某事的能力不会让您与他人分享这种能力。
维基百科给出了一个很好的例子：TCP 和 UDP 端口号。如果您绑定到一个本地端口（大概没有SO_REUSEADDR），则该机器上的其他任何人都不能使用同一端口，无论他们有多特权。端口的非重叠要求是“强制性的”。
在控制对文档或系统的访问时，您可以看到为什么军方对 MAC 感到兴奋……理论上。梦想是能够制作一份“只为您的眼睛”的文档，并防止任何其他眼睛阅读它，即使您的眼睛想要分享。想象一下一个锁着的房间，前面有一个保安，你只有出示你的徽章才能进入房间，而警卫阻止你带相机进来。您可以访问聊天室中的文档，但无法共享它们。
这个例子应该给我们一个线索，即数字系统中的 MAC 在理论上比在实践中更容易。一个完整的 MAC 系统很难实际执行。数字限制管理 (DRM) 是一种 MAC，据称文件的接收者无法进一步共享它，每个 BitTorrent 用户都知道它在现实生活中的效果如何。
非常传统地，军队中的 MAC 是围绕“多级安全性”构建的，即不仅仅是管理员和非管理员用户，还可以有不同级别的访问权限。他们最初把这个想象成同心圆（“绝密通关”vs“秘密通关”等等），但结果证明这太没有表现力了。
如今，访问控制通常更像是单独的标志或子组。例如，与旧式“root”与常规用户权限相比，SELinux可让您对每个进程中的每个权限进行细粒度控制。事实证明，除非您是 NSA（编写 SELinux），否则实际使用起来会非常复杂。也许即使你是。
总的来说，MAC 概念既过于严格又过于模糊。很难确切地知道人们在谈论强制访问控制时指的是什么，除了一个常数：可以预见的是，它使用起来很烦人。
RBAC 和 ABAC
RBAC 是 MAC 的子集。它是一种特殊类型的 MAC，但它更具体，因此更易于讨论和使用。
它开始类似于您在许多地方看到的“用户和组”模型。使用 RBAC，一些管理员将用户放入组中，其他人可以与组（角色）共享资源（文件、计算机等），系统会强制这些角色中的哪些角色可以访问资源。共享的接收者不一定有权重新共享，至少在不制作新副本的情况下不会。
基于属性的访问控制（Hu、Kuhn 和 Ferraiolo，2015 年）是对 RBAC 的进一步改进，增加了更多细节。“属性”可以包括给定用户的位置、客户端设备平台、身份验证类型或 http cookie 等内容。当系统决定是否授予用户访问资源的权限时，ABAC 系统不仅会检查他们的 RBAC 角色（组），还会检查此人可能具有的各种其他属性。
如果您在登录服务时遭遇reCAPTCHA验证，而您旁边的朋友却没有，那么您就遇到了 ABAC。
ABAC 很有用，您几乎总是希望使用其中的一些额外属性，尤其是在具有大量攻击向量的 Internet 连接系统中。但从概念上讲，ABAC 就像一个稍微复杂的 RBAC，并且属性部分主要在您的身份提供者中集中实现，所以让我们不管它并坚持使用 RBAC 进行讨论。
更详细点击标题