迈向零信任与基于属性的加密：一种更简单的安全解决方案

总体来说， 在网络安全中， 我们需要认识到基于角色的访问控制（Role-Based Access Control，简称RBAC）通常不是保护数据和服务的明智解决方案。虽然它简化了操作， 但无法有效支持多域扩展， 最终可能会变成一团乱麻的访问权限。

工作原理是用户根据他们被授予的角色获得访问数据或服务的权限。这些角色的权限范围通常较大，例如，全科医生的角色会获得所有全科医生需要的访问权限，即使他们可能只需要在特定时间访问特定内容，而不是所有内容。一个全科医生可能比另一个全科医生需要更多的权限，因此通常会添加一个特定任务的角色。结果是一个错综复杂、相互交织的角色网络，如果有人获得了某人的账户访问权限，他们将继承该账户所有角色的权限。

一个改进的方法是定义一个零信任架构，在这种架构中，每个用户都需要证明他们拥有访问特定服务或数据所必需的正确属性。例如，我们可能定义访问特定患者数据需要此人位于某个特定位置，使用可穿戴设备进行了身份验证，并且时间在上午9点到下午5点之间。为此，我们需要基于属性的访问控制（ABAC），用户需要获取正确的属性/声明来访问服务或数据。

这样我们就有了两种主要的访问控制类型（见图1）：

• 基于角色的访问控制（RBAC）。 定义访问数据的角色需求，例如，策略 = 主体（AND/或）角色 -> 权限。
• 基于属性的访问控制（ABAC）。 定义属性，例如，策略 = 用户（角色，国籍）AND/或资源（部门，所有者）AND/或操作类型AND/或上下文（时间、IP地址、位置） -> 权限。

图 1

正如我们将要看到的，主要有以下两种基于属性的（ABE）加密方法。

• 基于密钥策略的属性加密（KP-ABE），在KP-ABE中，密钥是根据包含属性的策略生成的。
• 基于密文策略的属性加密（CP-ABE），其中我们利用树形结构的不同密钥来访问特定属性。

而且，昨天我有幸和 ABE 的共同发明人之一，同时也是该领域的世界级专家交谈。

苹果公司这里（点击这里）[这里]

我们通常不擅长将安全措施充分整合，常常依赖叠加的安全模型来弥补我们缺乏内置安全性的不足。我们的安全模型大多源自旧的操作系统，这些操作系统未能有效地保护数据（因为它们最初设计是用来保护文件和目录，而不是数据）。因此，我们通常不能很好地加密数据，而是依赖操作系统给文件设置权限。我们的整体策略因此更侧重于文档而不是数据。

我们因此创造了一个开放的数据环境，为了保护它，我们设立了保护边界。然而，我们发现内部人员能够绕过防火墙访问数据。于是，我们使用加密密钥进行数据加密，但是这种加密方法通常应用于较大的数据集。那么，当我们使用云存储时，如何更好地控制对敏感数据的访问呢？我们需要寻找既能保护数据又能方便处理数据的方法。

我们创建的系统在操作系统安全的基础上发展，并采用了基于角色的访问控制。在Linux系统中，例如：

    用户名: bob  
    群组: gp

我们的访问权限如下所示：

用户组=rwx，组=rwx，其他人=rwx

在这种情形下，鲍勃将根据他拥有的文件或所在的组来获取访问权限——这就是所谓的基于角色的安全性。在Active Directory环境中，鲍勃也可以属于多个组，从而获得相应的权限。但是，仅仅属于一个组并不能真正保证安全，因此我们通常需要覆盖一个安全模型来检查鲍勃访问特定文件的权限情况。我们真正想要的是能够定义访问是基于其他因素，例如他的位置，或者他是否是与患者相关的临床医生。这些因素作为访问权限的属性，定义为基于属性的访问控制。

一种将安全性嵌入数据的绝佳方法是基于属性的加密（ABE），这种方法允许我们对解密过程进行精细控制。我们可以为解密过程设定精细的控制规则。例如，我们可以设定，只有在患者和医生都完成了身份验证并且身处可验证的位置时，才能访问敏感的健康信息。因此，在加密时，我们应用相应的策略。

规则 = ((用户类型=全科医生 且 地点=爱丁堡) 或 (用户类型=病人 且 地点=苏格兰))

在这种情况下，我们可以允许文件访问，前提是用户是爱丁堡的全科医生或苏格兰患者。这样，我们就可以根据实际属性而非操作系统权限来控制访问。

以下提供一个基于ABE的基本演示，以及我们在其中使用基于配对的加密技术[1]的地方：

通过CP-ABE，我们会定义一个基于属性（如时间和地点）的策略（见图2）。这些属性将被用来生成一个公钥，加入策略后，用于加密数据。当生成用于访问的属性时，这将生成一个相应的私钥，该私钥用于解密数据。

该政策按照阈值树的后序遍历进行编码。对于“foo bar fim 2of3 baf 1of2”，这会产生两个阈值门和四个叶子。更多示例[这里]：

• “fim bar baf 2of3 foo 1of2” 试试看!
• “foo bar baf 2of3 fim 1of2” 试试看!

这段代码如下所示：

在这个过程中，我们有几个阶段来进行加密。

• 设置阶段。此阶段会生成公钥参数（PK）和主密钥（MK）。
• 加密(PK,M,A)。在此阶段，我们将公钥(PK)和一条消息(M)，以及所有属性的访问结构(A)一起使用。输出将是一些密文(CT)，其中嵌入了A，使得当用户满足所需的属性时，他们将能够解密密文。
• 密钥生成(MK,S)。在此阶段，我们将主密钥(MK)和定义密钥的属性集合(S)一起使用，并输出一个私钥(SK)。
• 解密(PK, CT, SK)。在此阶段，我们将公钥参数(PK)，密文(CT — 包含访问策略)和密钥(给定属性集S)，尝试解密密文。如果成功，我们将再次获得消息(M)。
• 委托(SK, S˜)。如有需要，我们可以让一个委托人，该委托人将私钥(SK)，并生成一个新的私钥(SK)用于给定的属性集(S˜)。

下面是一个例子

现在我们试着用“staff csn09112 admin 2of3”策略条件以及“staff”、“csn09112”和“csn09101”属性来访问CP-ABE的数据[在这里]：

正如我们看到的，我们可以解密这些加密的数据。但现在让我们假设我们是一个正在学习“csn09112”和“csn09101”的学生。可以在这里查看详细信息[这里]：

现在我们看到我们没有足够的属性来匹配策略。现在，我们登录为“root”，并使用该策略“staff csn09112 csn09110 2of3 root 1of2” [这里]，我们得到：

所以，我们现在可以创建一个可以根据策略动态加密数据的系统。数据访问不再由操作系统控制，而是嵌入数据中。这样，我们的数据就可以存在于一个开放的地方——例如在云端——那里有我们信任的属性提供者。

如果我们从头开始构建我们的数据基础设施，我们肯定不会从目前的状态开始。比如我们的电子表格、文档、数据库等，几乎没有内置的安全机制，因此我们必须叠加我们的安全模型。这使得基础设施变得复杂，管理起来也很困难。CP-ABE则提供了一个更简单的方案，让我们能够更好地保护我们的数据。

我们的安全模型已经老旧，我们不得不采用叠加的方法来适应混合系统。这造成了复杂的安全策略，这些策略常常依赖操作系统和域控制器来决定文件的访问权限。在云计算的世界里，我们必须假设任何人都可以访问我们的数据，因此，我们需要将更多的安全措施嵌入到数据中。

我们的未来必须通过将政策嵌入到数据中，并提供各种属性来支持用户定义他们可以访问的数据权限要求来构建。

这是Brent在聊他的发明。

[1] Bethencourt, J., Sahai, A., & Waters, B. (2007, 五月). 密文策略的属性加密方案. 在2007年IEEE安全与隐私研讨会 (pp. 321–334). IEEE. 页 321-334