数据安全合规需要从基于角色的访问控制迈向基于属性的访问控制

基于角色的访问控制和基于属性的访问控制这两个术语是众所周知的，但就此而言，它们不一定被很好地理解——或被很好地定义。如果基于属性的访问控制包括用户角色，那么什么是基于角色的访问控制？线画在哪里？

从根本上说，这些数据访问控制术语——基于角色的访问控制和基于属性的访问控制——命名不当且容易混淆。那是因为它们不太关注角色或属性，而更多地关注策略的处理方式。策略是访问控制的核心，它们的应用方式是基于角色和基于属性的访问控制之间的决定性因素。更重要的是，它们允许数据团队做的事情将高效和安全的数据使用与繁琐、冒险的做法区分开来。

什么是基于角色的访问控制(RBAC)？

基于角色的访问控制(RBAC)是一种数据安全方法，它根据个人在组织中的角色允许或限制系统访问。这表明数据消费者只能访问与其工作职能相关的数据。基于角色的访问控制通常管理对表、列和单元格的访问，并与表访问控制列表(ACL)紧密相关，尽管后者更特定于数据消费者并且在实施组织时不是一个现实的选择-宽的。

通过RBAC管理访问权限的数据团队通过将用户添加到角色来隐式预先确定用户将有权访问的内容，然后显式确定与每个角色关联的权限。简而言之：数据工程师决定谁属于任意“事物”（在本例中为角色），然后必须决定该“事物”可以访问什么。

由于这种隐含的预先确定，RBAC的一个更好的术语是基于静态的访问控制。一个非常适合描述RBAC的类比是编写无法使用变量的代码：您一遍又一遍地编写相同的代码块，根据您希望该策略针对的角色进行细微的更改。例如，如果您想要一个策略来限制组织中每个角色对特定省的访问，您将必须编写34个策略（每个省一个），并为每个策略维护34个角色。如果任何用户可以访问多个状态，您将需要为这些场景创建一个策略——使用RBAC，一切都必须预先确定。

几乎所有现代和遗留数据库都使用基于角色的访问控制模型来实现数据访问控制。开源访问控制框架，如ApacheRanger和Sentry，也遵循这种方法。然而，此类框架的局限性很明显，正如GigaOm的独立研究所证明的那样——基于角色的访问控制的静态性质需要比基于属性的访问控制多93倍的策略更改才能满足相同的安全要求。

什么是基于属性的访问控制(ABAC)？

基于属性的访问控制(ABAC)是一种数据安全方法，它根据分配的用户、对象、操作和环境属性允许或限制数据访问。与依赖于特定于一个角色的特权来保护数据的RBAC相比，ABAC具有多个维度来应用访问控制。这使得基于属性的访问控制成为一个高度动态的模型，因为策略、用户和对象可以独立供应，并且策略在请求数据时做出访问控制决策。

为了理解它是如何工作的，首先理解基于属性的访问控制的元素是很重要的：

属性：系统中任何数据的特征。ABAC根据用户、对象和环境的属性做出访问决策。

用户属性：有关数据用户的信息，包括姓名、职位、部门和权限级别。

对象属性：有关数据本身的信息，包括创建者、类型、创建日期和敏感度级别。

动作属性：关于主体对数据做了什么的信息，包括阅读、编辑、批准和删除。

环境属性：有关数据的上下文信息，包括位置、访问日期和组织威胁级别。

策略：一组规则，根据数据的属性规定对数据的许可或限制。

为了更具体地定义ABAC，让我们重新审视省的示例。不必构建34个策略和角色（或更多，具体取决于用户是否可以访问多个状态），您可以将属性视为动态变量。这意味着使用ABAC，您可以使用单个策略创建包含34个状态的规则，如下所示：仅显示状态为(@user-attribute:state)的行，其中@user-attribute:state是包含它们的动态属性状态列表。

这个例子说明了为什么ABAC会更准确地定义为基于动态的访问控制。回顾我们最初的类比，ABAC就像使用变量编写代码，无需一遍又一遍地创建相同的代码块（策略）。上面列出的变量列表可以区分用户是谁，他们在做什么，以及应该在运行时动态应用什么策略，而不是通过混淆谁有权访问基于什么的内容来预先定义所有策略关于角色，与RBAC一样。

基于角色的访问控制不是什么

人们通常会对基于角色的访问控制这一术语感到困惑，并假设“角色”是否可以来自多个系统和维度，就像ABAC一样，它实际上符合基于属性的访问控制。虽然角色是RBAC的重要组成部分，但策略仍然是静态应用的，而不是动态应用的。这就是为什么基于角色的访问控制实际上应该称为基于静态的访问控制(SBAC)，而基于属性的访问控制应该称为基于动态的访问控制(DBAC)。

重要的是要记住，如果您目前正在使用RBAC，则不必放弃现有角色来切换到ABAC。您可以通过ABAC以一种新的、更强大的方式（动态地）简单地利用它们。此外，RBAC可能会与基于标签或基于逻辑的策略编写相混淆，在这些策略中，策略不是基于物理表定义（如表名或列名）而是基于逻辑元数据（如“无处不在的掩码”）应用于表有个人身份信息。”虽然这是构建可扩展策略的强大功能，并且数据属性对于基于属性的访问控制至关重要，但它并未完善完整的ABAC模型。

基于角色的访问控制的优点和缺点

RBAC的优点

基于角色的访问控制的主要优点是它已被广泛采用，并允许中小型组织消除以个人为基础实施访问控制的情况。由于RBAC策略可以根据组织中现有的角色编写，因此易于建立和分配。新员工和内部角色变更不再需要制定新政策；数据团队可以简单地分配或更新适当的角色来规定员工的数据访问级别。

此外，数据工程师可以将单个用户分配给多个角色并创建访问层次结构。例如，具有“人力资源”角色分配的经理也可以被赋予“经理”角色分配，并且可能比他们的直接下属拥有更广泛的访问权限，从而允许经理覆盖他们基于角色的限制。但是，请务必注意，并非所有RBAC实施引擎都支持分层角色结构，而是支持一种平面结构，即每个用户一次只允许一个角色。

由于其维度（或缺乏维度），建立基于角色的访问控制相对容易。数据团队映射组织内的角色并为每个角色分配访问权限；一旦建立，权限将根据用户在系统中分配的角色自动提供或取消提供。这种“一劳永逸”的方法使数据团队无需手动授予或限制访问权限，但也需要他们在必要时主动设置新的角色和权限。很多时候，这将开始脱离现实世界的组织结构，因为这意味着为了政策的目的而建立角色——记住，对于RBAC，所有政策都必须预先确定。

RBAC的缺点

基于角色的访问控制易于设置的相同功能也是其最大的限制之一。对于中小型组织，RBAC可能是可管理的；然而，随着人员和角色数量的增加，数据团队的工作很快就会变得更加复杂，尤其是在使用分层方法时。这引入了极有可能出现“角色爆炸”的可能性，这需要数据工程师管理数百或数千个用户角色，以控制对特定表或数据库中数据的访问。这种时间密集型责任首先否定了实施基于角色的访问控制的一个核心原因——节省了在个人基础上启用访问控制的时间。

角色爆炸还会导致管理员无法再轻松了解哪些角色属于哪些访问权限，因此将用户需求转换为实际角色分配可能非常难以管理。

由于数据团队必须预先确定所有策略，因此RBAC需要在新数据到达时进行工作。在我们的美国州示例中，如果您已经构建了所有策略（每个州和角色一个），然后开始从加拿大加载数据，除非您记得先发制人地创建策略，否则没有人能够看到加拿大数据在新数据到达之前。有如此多的策略、用户和其他需要跟踪的东西，这对任何数据架构师或工程师来说都是一个很大的要求。由于RBAC不会对组织中的任何更改进行未来验证，因此您必须始终主动记住更新有关任何数据或组织结构更改的策略。

此外，RBAC本质上忽略了最小特权原则，该原则规定数据消费者应该只被授予对完成手头任务所需数据的访问权限，而不能访问更多。RBAC模型下提供的粗粒度访问控制不允许数据团队在某个时刻根据个人的需要自动设置权限。每个自定义权限都成为一个新角色，导致前面提到的角色爆炸。

例如，会计人员可能只处理应付账款，没有理由访问员工工资单信息。同时，同一会计部门的另一个人可能需要访问员工税务信息，但没有理由访问合同协议。基于角色的访问控制可能要么给两个人过多的访问权限——违反最小特权原则并可能暴露敏感信息——要么过于严格，在这种情况下，个人可能会请求数据团队必须手动验证和授予或拒绝的访问权限，增加组织的角色数量。

基于属性的访问控制的优点和缺点

ABAC的优点

基于属性的访问控制利用数据和数据消费者的独特属性的多个维度来确定是授予还是拒绝数据访问。与静态的基于角色的访问控制模型不同，ABAC的多维方法使数据访问更加动态。数据团队定义属性并为它们创建策略，但一旦分配给系统组件，它们几乎不需要维护。这避免了手动创建角色和随后的角色爆炸，同时使数据访问控制更具可扩展性。ABAC模型中的单个策略可以替代数百个单独的角色，而这些角色对于使用RBAC方法实现相同的结果来说是必需的。

虽然ABAC属性类别之一涉及用户角色，但与RBAC不同的是，它们与其他几个因素一起被考虑在内。因此，基于属性的访问控制比基于角色的访问控制提供了更多的控制变量，使数据更加安全，并坚持最小权限原则。这意味着数据和合规团队可以更加确定数据不会被不应访问的个人过度访问。减少特定于角色的策略使生态系统更易于管理和监控，从而实现数据策略的执行和审计，从而减少任何敏感数据从裂缝中溜走并落入坏人之手的机会。

回顾我们的会计部门场景，基于属性的访问控制可能将两个用户都定义为会计人员，但是由于与对象属性关联的权限——例如，合同和发票与税务信息——如果负责应付账款的人试图访问W-9，他们将被拒绝。更进一步，负责工资核算的会计师可能能够访问W-9，但只能在特定时间段内或执行特定操作，例如查看但不能编辑。这确保了正确的人可以在正确的时间访问正确的数据，并且这样做以不需要耗时的角色更新或创建的可扩展方式增加了安全层。

与RBAC不同，后者将用户是谁与他们应该拥有的访问权限混为一谈，ABAC将who与what分开。这种灵活性使ABAC充满活力。此外，由于ABAC是动态的，它也是面向未来的。在美国州示例中，如果在ABAC模型下添加新的加拿大数据，则不需要新策略，因为现有策略-仅显示stateIN(@user-attribute:state)所在的行-仍然有效。

ABAC的缺点

虽然基于角色的访问控制更容易建立但更难扩展，但基于属性的访问控制恰恰相反：建立更多的工作但更容易扩展。这是因为数据团队的任务是定义用于定义数据访问策略的标准，然后在其数据环境（包括本地和云平台）中创建并统一实施这些策略。

预测数据安全需求并制定适当的计划来解决这些需求需要与法律和合规团队合作，以了解国家安全法和个人信息保护法等法规、合同义务和行业标准，以及其他考虑因素。虽然法律和合规团队可以就这些要求的实质内容提供指导，但数据团队需要执行安全、一致的保护措施。对数据访问策略进行标准化定义是第一步，但跨越数据源并提供ABAC的自动化数据访问控制解决方案可以简化流程并使其更加直观。这可以减轻耗时耗力的前期工作负担，并确保提供更可靠的保护。

使用哪一个：RBAC还是ABAC？

对于刚开始实施访问控制管理的小型组织，基于角色的访问控制似乎是一个合理的起点。由于内部用户很少、策略很少且数据量有限，这种方法作为初步的数据保护措施更容易起步。

然而，在RBAC和ABAC之间争论的关注现代隐私法规和/或有发展计划的小型组织——以及包含多个数据用户的任何其他组织——实施基于属性的访问控制是明智的开始。这样做将使他们能够更轻松地扩展，而无需在数据源、策略和/或用户大幅增加后重新评估其数据访问结构并重写其访问控制策略。

考虑世界的现状也很重要：虽然RBAC过去可能奏效，但复杂的数据合规性法规现在更加普遍并将继续如此，使RBAC成为一种越来越过时的方法。无论组织规模如何，在当今市场上用于推动分析的敏感数据的激增足以让任何数据团队头晕目眩。使用RBAC提供的粗粒度访问控制，跟上快速增长和演变的数据集、用例、业务需求和监管要求是非常复杂的。相反，ABAC的动态策略创建使数据工程师更容易跟上传入数据的步伐并相应地准备数据，而无需花费不必要的时间创建新角色来满足新需求。

来源：数据驱动智能

作者：晓晓