快捷菜单
社交媒体
联系方式
业务咨询

400-816-1670

地址

北京市 海淀区 东北旺西路8号 中关村软件园9号楼2区306A

Email

contact@HanSight.com

Phone

(+86 10) 8282 6616

新闻 / News

详解颇具挑战的大数据安全分析

  • 关键词:大数据 安全 by 瀚思HanSight编译
  • - Feb.26, 2016
导语:面向大数据分析的访问控制技术需要基于策略的安全机制,这种安全机制不仅包括用户和角色,还包括上下文。
【本文本文系瀚思编译稿件,如需转载,请注明出处!原文作者:Andrew C Oliver】

面向大数据分析的安全颇具挑战性。

原因如下:如果你无法当场分析,就需要复制该数据。这时候,关于谁可以在什么样的情况下,查看或更改各种各样数据的所有规定也应该一并复制。而如今,这几乎是不可能完成的任务。

在Hadoop/Spark方面,我们只有基于角色的、有限的访问控制列表(ACL),这种安全机制可以说很原始。不过我认为倒是有一条出路:采用基于策略的方法,这种方法已出现在更广泛的安全市场。为了探究这是如何工作的,我们需要回顾访问控制的历史,以及它如何演变、推出一种基于策略的模式。

简述访问控制的历史

起初,使用用户名和密码将可能想要闯入的每个人拒之门外。

这套系统存在一个固有的问题。随着新编写的应用程序越来越多,用户/密码组合的数量往往随之激增,于是我们最后只好为每个应用程序使用不同的用户名/密码。更糟糕的是,一些应用程序需要不同的密码,以便获得不同的安全级别。

我们变乖了,使用用户名划分了“角色”。比如说,我们会有一个“用户/密码”,但是想访问管理员功能,该用户/密码还需要“管理员”角色。然而,每个应用程序往往以自己的方式实施这种机制,所以你仍得记住越来越多的密码。

接下来,我们变得更乖了,设计出了中央系统,它们最终成为了LDAP和活动目录等系统。这类系统将用户/密码合并在一个核心库,并设立了一个地方,以便查询某个用户的角色,但是这在解决一个问题的同时带来了另一个问题。

在理想情况下,每个新的应用程序查看活动目录中的角色列表后,将它们与应用程序角色对应起来,那样就有了清楚的一对一关系。而实际上,大多数应用程序考虑角色的方式不一样;除此之外,就因为你是某个应用程序的管理员,并不意味着你应该是另一个应用程序的管理员。最后,只不过是将数量激增的用户名/密码组合换成了数量激增的角色。

这就引出了一个问题:最后谁来负责增添新的角色?这往往是某种IT管理职能或与人力资源部门共担的职能。由于负责增添角色的那些人很可能并不是非常切实了解应用程序,这到头来通常成了 “经理审批”或“橡皮图章”,这并不好。

许多应用程序仍采用这种方法来解决角色问题:使用活动目录来验证身份,让应用程序处理自己的本地角色实现。这种方法被人津津乐道,因为显然是应用程序管理员知道谁应该有什么样的访问级别。

同时,有些明确的规则并不是很适合用户/角色这种系统。简单来说,因为我是个银行客户,并不意味着我可以从任何账户取钱,哪怕我拥有“能取钱”这一角色。角色常常需要与数据关联起来,这就是为什么ACL与数据存储区中的条目一一对应。也就是说,账户1234拥有一种关联,可以识别我是账户所有者、我的配偶是授权的账户管理员。

然而,一些公司拥有较复杂的规则,比“这是你的吗?”或“你对此记录拥有什么样的权限?”来得复杂。相反,它们使用所谓的“上下文”或“基于策略”的安全规则。换句话说,我可能拥有这种权限:只有在美国境内才可以取钱。在ACL或基于角色的模式中无法表示这一点。相反,我们进入到了基于策略的安全。

你有时只能做某些事情

基于策略的安全往往存在于中央库,依赖中央验证机制(LDAP和Kerberos等)。区别在于,每个用户与一组策略关联起来,而不是维持简单的角色(比如“能取钱”)。策略基于关于用户的一组属性,又叫基于属性的访问控制(ABAC)。那些策略无法集中执行,因为它们完全依赖应用程序。

已经有支持这种方法的标准,一方面来自国防业及其他个别行业。可扩展访问控制标记语言(XACML)就是这样一种标准,它让你可以表示一组组策略。通常基于应用程序来完成执行,使用某种算法或规则系统。XACML是一种用于表示策略的相当全面的标准,甚至可以处理异常,比如策略冲突,或两种算法执行一个策略。

就像RBAC那样,ABAC驱动的这些策略常常基于数据,而不是单单基于应用程序功能(只有你在美国境内为这某一家公司工作,而且是遵纪守法的公民,才可以访问F-22战斗机的图表)。运用策略的头一步就是,常常识别策略规则应该适用于哪个数据,并“标记”该数据。

为何要关注先进安全?

很显然,使用ABAC式样的策略和XACML比RBAC迈进了一大步。即使只为了避免遭受巨额罚款,你也应该有动机这么做。

此外,有些企业组织有复杂的规则和数据所有权。随着这些公司日益变得数据驱动型,无法当场分析每个数据,它们需要一种并不仅限于如今的常见RBAC模式的系统,而不是需要集中。此外,为了让这切实可行,它们还需要标记以及便于运用以XACML等标准表示的策略的库,另外还需要必要时,在本地运用策略时集中管理策略的工具。

如果我们看一下今天的大数据解决方案,比如Ranger和Sentry,没有一个可以满足这样的要求。连面向基于RDBMS的系统的解决方案也往往是专有产品、成本高昂,而且功能不全面。用复杂安全规则做好高度安全工作的企业组织被迫实施这种解决方案。对Hadoop之类的大数据系统而言,数据标记工具仍处于初期阶段。

换句话说,如果厂商能切实拿出方案,这方面面临大好机会。很显然,国防业是第一个客户,因为它已经出于需要而在这么做。随着更多的公司构建中央数据资料库用于大数据分析,对基于策略的安全的需求只会日益增长。(原文链接:http://www.infoworld.com/article/3031849/application-development/big-data-needs-big-security-changes.html)