One of our major problems in security is that we have build systems which use role-based security, and it is flawed. Increasingly we need attributes, such as location, and time, to properly authenticate a user.

安全性方面的主要问题之一是我们拥有使用基于角色的安全性的构建系统，并且存在缺陷。 我们越来越需要属性(例如位置和时间)来正确验证用户身份。

We are generally poor at properly integrating security, and often use overlay models to overcome our lack of embedded security. Our models of security often, too, come from our legacy operating systems, and which fail to protect data (as they were designed to protect files and directories rather than data). We thus often we fail to encrypt data properly, and we fall back to the operating system to provide rights to files. Our overall policies thus focus on documents and not on data.

通常，我们无法正确集成安全性，因此经常使用覆盖模型来克服我们缺乏嵌入式安全性的问题。 我们的安全模型通常也来自我们的旧操作系统，并且无法保护数据(因为它们旨在保护文件和目录而不是数据)。 因此，我们经常无法正确加密数据，而我们只能依靠操作系统来提供文件权限。 因此，我们的总体政策侧重于文档而不是数据。

We have thus created a data world which is open, and then to protect it we put up perimeters. But we find out that there’s insiders who sit behind the firewall and can access our data. So we then encrypt with an encryption key, but this is often applied on a fairly large scale basis. So how do we control access to sensitive data when we use cloud-based storage? Well, we need to look at better ways of protecting our data, while still being able to process it.

因此，我们创建了一个开放的数据世界，然后为了保护它，我们建立了边界。 但是我们发现，内部人员位于防火墙后面，可以访问我们的数据。 因此，我们然后使用加密密钥进行加密，但这通常在相当大的基础上应用。 那么当我们使用基于云的存储时我们如何控制对敏感数据的访问？ 好吧，我们需要寻找更好的方法来保护我们的数据，同时仍然能够处理它。

The systems we have created have grown up through operating system security, and apply role based security. In a Linux system we can have:

我们创建的系统是通过操作系统安全性发展起来的，并应用了基于角色的安全性。 在Linux系统中，我们可以具有：

and we have access rights as:

我们的访问权限为：

In this case Bob will have access rights based on his ownership of a file, or on the group he is in — and is defined as role-based security. In an Active Directory infrastructure, Bob can also be part of multiple groups, and will this gain him rights. But being part of a group is not properly applying security, and we thus have to normally overlay a security model to check Bob’s rights to access given file. What we really want is to be able to define that the access is based on other things, such as his location, or whether he is the clinician associated with a patient. These are defined as attributes for his access rights, and define attributed-based security.

在这种情况下，Bob将基于其文件所有权或他所在的组具有访问权限，并被定义为基于角色的安全性。 在Active Directory基础结构中，Bob也可以是多个组的一部分，这将使他获得权利。 但是，作为一个小组的成员并不能正确地应用安全性，因此，我们通常必须覆盖安全性模型以检查Bob的访问给定文件的权限。 我们真正想要的是能够定义访问基于其他因素，例如他的位置，或者他是否是与患者相关联的临床医生。 这些被定义为他的访问权限的属性，并定义了基于属性的安全性。

One of the best methods of embedding security into data is ABE (Attributed-based Encryption), and where we can define fine-grained control on the decryption process. For example, we might define that some sensitive health information is only accessible when the patient and the clinician have both authenticated themselves, and are in a provable location. Thus during the encryption process, we apply a policy:

将安全性嵌入到数据中的最佳方法之一是ABE(基于属性的加密)，我们可以在其中定义对解密过程的细粒度控制。 例如，我们可能定义为只有当患者和临床医生都进行了身份验证并且位于可证明的位置时，才能访问某些敏感的健康信息。 因此，在加密过程中，我们将应用以下策略：

In this case we would allow access to a file based on a user who is a GP in Edinburgh, or a Scottish patient. In this way we can base our accesses on real attributes, rather than operating system rights.

在这种情况下，我们将允许基于爱丁堡的GP或苏格兰患者的用户访问文件。 这样，我们可以基于真实属性而不是操作系统权限来进行访问。

There are two main types of ABE. The first is Key-policy attribute-based encryption (KP-ABE) and the other is Ciphertext-policy attribute-based encryption (CP-ABE). In KP-ABE we generate the key based on a policy that contains attributes. For CP-ABE we use a tree structure with different keys into order to access given attributes.

ABE有两种主要类型。 第一种是基于密钥策略属性的加密(KP-ABE)， 第二种是基于密文策略策略的属性加密(CP-ABE)。 在KP-ABE中，我们根据包含属性的策略生成密钥。 对于CP-ABE，我们使用具有不同键的树结构来访问给定的属性。

In this case we have several stages for the encryption process:

在这种情况下，加密过程分为几个阶段：

So let’s keep it simple. Let’s say we have six attributes (0 1 2 3 4 5), and then define a policy based on these. The following is the Golang code to implement a basic demo [here]:

因此，让我们保持简单。 假设我们有六个属性(0 1 2 3 4 5)，然后根据这些属性定义一个策略。 以下是Golang代码来实现基本的演示[ 这里 ]：

A sample run is [here]:

样本运行在[ 这里 ]：

and for a failure [here]:

和失败[ 这里 ]：

Our security models are old, and where we have had to use overlay methods, and then spanned these across hybrid systems. This has created complex security policies, and which rely often on operating systems and domain controllers making judgments on access rights to files. In a world of Cloud computing we must assume that our data can be accessed by anyone, so we increasingly need to embed security into our data.

我们的安全模型很旧，我们不得不使用覆盖方法，然后将它们扩展到混合系统中。 这创建了复杂的安全策略，并且通常依赖于操作系统和域控制器来判断对文件的访问权限。 在云计算的世界中，我们必须假设任何人都可以访问我们的数据，因此我们越来越需要将安全性嵌入到我们的数据中。

Our future must be built by embedding policies into our data, and supporting users providing various attributes to define the claims they have to access the data.

我们必须通过将策略嵌入到我们的数据中并支持用户提供各种属性来定义他们必须访问数据的声明来构建我们的未来。