DAC是让人们管理他们拥有的内容的方式。这听起来很明显，但例如 DAC 非常适合让在线社交网络的用户选择谁访问他们的数据。它允许人们立即轻松地撤销或转发特权。反应式访问控制、进一步观察和自由放任文件共享为用户研究 DAC 提供了很好的例子。

RBAC是一种访问控制形式，正如您所说，它适用于在履行多个角色的系统中分离职责。这在公司中显然是正确的（通常伴随着划分，例如Brewer 和 Nash或MCS），但也可以在单用户操作系统上使用以实现最小特权原则。RBAC 专为职责分离而设计通过让用户选择特定任务所需的角色。关键问题是您是否使用角色来表示在系统上执行的任务并在中央机构中分配角色（在这种情况下，RBAC 是 MAC 的一种形式）；或者如果您使用角色让用户控制他们自己对象的权限（导致每个对象有多个角色，并且角色中绝对没有语义，即使理论上是可能的）。

MAC本身是模糊的，有很多方法可以为许多系统实现它。在实践中，您经常会使用不同范式的组合。例如，UNIX 系统主要使用 DAC，但 root 帐户绕过 DAC 权限。在公司中，除了使用 MAC/RBAC 分隔您的不同部门和团队之外，您还可以允许一些 DAC 供同事共享您公司文件系统上的信息。

最好将您的问题具体化并说明您要保护的系统（如果有）。使用何种访问控制始终取决于您正在考虑的特定情况和上下文。

每个系统用于不同的首要安全要求。三个主要的安全要求是机密性、完整性和可用性。

MAC 比其他的更支持保密性的安全要求。DAC 比其他的更支持可用性的安全要求。RBAC 比其他的更支持完整性的安全要求。还有另一种...

MAC 根据标签和权限做出决定。DAC 仅根据权限做出决定。RBAC 根据职能/角色做出决策。

当系统或实现做出决定时（如果编程正确），它将强制执行安全要求。如果你使用了错误的系统，你可以拼凑它来做你想做的事。这种情况经常发生。

除了 DAC 与 MAC 之外，它们不是相互排斥的。有 DAC/RBAC 组合实现是此 Active Directory 角色和权限的最佳示例。

RBAC - 倾向于数据库 - 您不能使用其他系统之一并且必须使用 RBAC 的典型示例是用于客户服务和计费。当您致电有线电视公司要求按次付费时，客户服务代表会说对不起，让我将您转至 Billing，以便您支付逾期账单 - 他们知道您有逾期账单，但他们的角色阻止他们直接获取您的信用卡信息。当您转入账单时，您支付账单并说我可以为您服务。他们说让我把你转回去——我知道你想要这项服务，但这不是我的职责。因此，这两个角色都可以查看所有数据（无机密性），但只能操作他们具有特定职责的字段（完整性）。-你可以争论DAC：但符合“更是如此”的规则。

MAC - 倾向于军事系统或非常狭义的、高安全要求的实现。2 经常使用的 TRusted-Solaris 和 LINUX-MAC 内核模块（这曾经是 SELinux）还有其他的，但你不在乎。仅出现在 MAC 中的关键要素之一是优势结构。如果您拥有机密级别的许可，那么再多的权限也不会让您看到绝密文件。在商业实体中，您很少需要此构造。但它提出了 MAC 独有的第二点——如果一项活动没有被明确允许，那么你就不能这样做。（这破坏了许多商业用途，主要是因为任务或系统要求的快速变化）MAC 的一个很好的用途是在 Web 服务器上 - 您可以在其中编写自定义策略（并且这是非常狭窄地定义为该实现），声明核心进程只能由系统帐户执行。任何由此产生的进程都需要满足特定的权限。

DAC - 每个人都使用它，而我面前的人回答得很好。