摘要：大数据分析的访问控制需要基于策略的安全性，包括对于环境的安全管理以及用户和角色的管理。大数据分析的安全性管理是具有挑战性的。原因就在于：当您无法进行数据分析的时候，您可能需要复制数据。而一旦数据被复制，所有关于确保数据安全性方面的相应的规定，包括谁有权限可以查看数据；或在什么情况下拥有更改数据的权限，也应该随着数据的复制一并被复制。但在今天，这几乎是不可能的。
在Hadoop/Spark方面，我们只有基于角色的、有限的访问控制列表(ACL)。但我相信有一条可以更进一步的道路：在更广泛的安全市场采用已经出现的基于策略的方法。为了探索这一方法要如何才能奏效，我们需要重新审视访问控制的历史，以及其如何演变，进而产生了基于策略的模型。
回顾访问控制的历史
尽管在最开始的时候，会有用户名和密码的身份验证，以防止任何人的随便进入访问，理查德·斯托曼说。
但这样的访问身份验证登录系统存在一个固有的问题。即我们的用户/密码组合的数量会随着新的应用程序的不断增加而趋于出现爆炸似增长，所以我们最终必须以不同的用户名/密码来登录到每一款不同的应用程序。更糟糕的是，一些应用程序甚至要求了不同的密码，以达到不同级别的安全性。
我们开始变得更加聪明，通过用户名来区分我们的“角色”。例如，我们有一套“用户名/密码”，但为了访问某些管理功能，则需要该用户名/密码具有“管理员”的作用。然而，鉴于每一款应用程序都倾向于有自己的部署方式，所以您仍然需要记住越来越多的各种密码列表。
我们甚至变得更聪明，创造了中央系统，最终成为LDAP、活动目录等等。这些统一的用户名/密码被存储在一个核心库，并建立一个位置，能够针对给定用户的角色来查找相应的用户名/密码——但这只是以一个问题代替了另一个问题。
在一个理想的世界中，每一款新的应用程序都会在活动目录中
查看角色列表，并将其映射到应用程序角色中，所以便会有一个干净、一对一的关系。但在现实中，大多数应用程序对于角色的理解都是不同的，这非常简单，因为您可能是某一款应用程序的管理员，但这并不意味着您应该是另一款应用程序的管理员。最终的结果是，您会有各种爆炸增长的角色，来取代爆炸似增长的用户名/密码组合。
这就引出了一个问题：最终要由谁来负责添加新的角色?其往往是承担了行政职能或人力资源管理职能的IT管理人员。而由于从事这些诸如负责添加新的角色等琐碎的工作任务的人员，对于相关的应用程序并没有很好的理解，使得这样的工作往往最终成为了一个“经理审查批准”或“橡皮图章”了，而并非如他们所说那样好。
许多仍然存在角色问题的应用程序采用AD进行身份验证，并让应用程序处理自己的本地角色的实现问题。关于这种方法有很多值得探讨的地方，因为这很显然，应用程序的管理员知道谁应该有什么权限级别的访问。
同时，有明确的规则不适合于用户/角色系统。在其最简单的方面，例如，不能因为我是某家银行的客户，就意味着我可以从任何帐户取钱，即使我有“可以从该银行取钱”的角色。角色通常需要与数据相关联，这就是为什么我们要用ACL映射到我们的数据存储条目的原因所在了。也就是说，帐户1234需要进行一个关联，确定了我作为该1234帐户的所有者，同时我的配偶作为一个授权的帐户管理员。
然而，一些企业有比“这是您的吗?”或者“您在这方面有什么权限?”更复杂的规则。相反，他们会使用您可能称之为“基于环境”或“基于政策的”安全规则。换句话说，当我在美国本土的时候，我可能有取钱的权限。这在一个ACL或基于角色的模型是没办法表达的。相反，我们已经有了跨基于策略的安全性。
当您只能在特定的时间执行一些工作
基于策略的安全性通常存在于一个中央存储库，并且依赖于中央认证机制(LDAP、Kerberos等等)。所不同的是，并非保持一个简单的角色(如可以取钱)，每个用户都与一组策略相关联。该策略是基于与用户相关的一组属性所制定的，其也被称为基于属性的访问控制(ABAC)。这些政策不能集中强制执行，因为他们是完全依赖于应用程序的。