一、Hadoop基础框架

在讲安全之前,先要做个基础普及。我猜国内很多安全人员对Hadoop的框架完全不了解,或知道的很少。

Hadoop在应用当中,业务首要考虑的是性能扩展、集群存储扩展,而在方法上主要依靠开源。了解Hadoop框架的意义在于,框架里的每个组件都存在潜在风险。这个图是Hadoop底层MapReduce系统的简化视图:

图片 1.png

从这个图你可以看到,Hadoop的扩展性非常好,支持并行处理,提供可伸缩节点,也能对多租户跨应用进行支持。但在安全上有个问题,这里每个node都是对等的,且互相通信,通信包括很多内容,比如取保数据正确复制、node在线离线、存储优化等功能,但这也就是说,他们之间是互相信任的,这就是一个风险。

MapReduce只是Hadoop底层一个分布式任务处理系统,而整个Hadoop的框架是这样的:

图片 2.png

你也可以把它看成是类似LAMP堆栈,可以根据自己的业务情况添加组件。例如你用HBase来存储数据,以实现毫秒级的检索,但对多字段的组合查询却比较弱,这时你可能就需要Solr来做组合查询。用Sqoop来帮你从传统关系型数据库导数据,用Pig来实现高级MapReduce功。Spark,Drill,Impala和Hive都可以用来做SQL查询。所以整个Hadoop是灵活、定制、模块化的。

灵活性带来了复杂性,也给安全带来了难度。每个模块都有不同的版本、配置,甚至需要单独的身份验证,因此每个模块都是风险点。所以就有了Sentry,可以为整个Hadoop生态系统统一实现授权,未来也许还有新的安全模块出现。

二、系统安全

在Hadoop的系统层面:

1、身份验证和授权

基于角色的权限访问控制(RBAC)是整个访问控制的核心,RBAC就是把角色和权限进行关联,这个关联包括了角色、组、表、标签以及其他各种可用数据。认证和授权在大型企业里,是需要跨团队的合作的,比如与SSO的集成是和IT打配合,数据字段密级的颗粒控制和数据平台配合实现。Hadoop生态里,身份是个比较复杂的内容,Hadoop在设计的时候就尽可能的与权威身份源松耦合,Hadoop默认使用Kerberos作为认证协议,但Kerberos对更高级的身份特征认证支持是不够的。

2、静态数据保护

静态数据的保护其实就是指加密,HDFS支持原生静态加密,防止直接从磁盘读取数据。但是敏感数据可不仅仅存在于HDFS层,日志、交换文件、消息队列、元数据库等其他地方也会有大量敏感数据存在。

3、多租户

Hadoop通常都是为多租户提供服务,例如我所在的公司,租户包括了不同的bg,也包括收购投资的公司,也有与外部合作的租户。租户之间的数据应该隔离或者加密,有的公司用的ACL来控制,而在云端,多数是通过区域密钥加密。

4、节点通信

举例来说,Hadoop和MongoDB默认是非安全通信方式,用的是基于TCP / IP,未加密的RPC。虽然提供了TLS和SSL,但是很少用在节点之间。

5、客户端交互

Client是和resource manager、node之间交互的,见图一。因此Client可以做出攻击行为,比如恶意占用资源、利用漏洞攻击。而Hadoop是一个分布型的架构,传统上的防火墙之类的工具不适合。

6、分布式节点

有一句话很经典,移动计算比移动数据便宜,数据在有资源的地方计算,从而实现大规模并行处理。分布式会让环境更复杂,从而产生更多的攻击面,补丁、配置管理、身份验证、静态数据保护、一致性都成为问题。

三、运营安全

除了系统安全之外,还有操作运维上的安全。运维一般都希望提供配置管理、补丁升级、策略维护之类的功能。而Hadoop之前是没有这些东西的,就算是现在也缺少成熟的运营手段。在这部分存在的问题是:

1、身份验证和授权

身份和身份验证是安全的核心,在这方面Hadoop做了大量的集成,从最初不提供认证,到集成LDAP,Active Directory,Kerberos、X.509,通过这些集成,可以基于角色映射授权,也可以扩展到更细粒度的授权(比如Apache Sentry),再到自定义。

2、特权访问

在公司里,可能负责操作系统的是一个管理员,Hadoop是另一个管理员,他们都可以访问集群的文件,所以需要分隔管理角色,把不必要的访问限制到最低。对于直接访问数据,可以通过基于角色授权、访问控制列表等的组合管理方式。对于管理角色则可以通过三权分立来分隔。再强一些,则是加密和密钥管理,HDFS加密。

3、配置和补丁管理

集群可能有几百个节点,对这些节点统一做配置和补丁管理是个难题,比如新增节点和原有节点配置不统一这类问题。现有的配置管理工具都是在底层平台上,NoSQL系统还没有对应的配置管理,另外市面上也没有针对Hadoop做特定检查的扫描器。

4、软件依赖

Hadoop有很多不同组件,每个组件有自己的配置、补丁、验证方式。好在Docker技术的出现从很大程度上可以缓解这个问题。

5、应用和节点的身份验证

如果攻击者可以添加一个节点进入集群,就可以渗透到数据层,这就直接绕过了身份认证。通过节点进一步拿到Kerberos密钥表文件,则可以伪造身份。这时候则可以考虑证书,虽然证书部署会变得复杂一些,但提高了安全性。

6、日志审计

如果发生数据泄漏,能不能从日志上进行追踪?大数据环境里有一些开源工具可以用,比如Facebook开源的Scribe或者Logstash,日志可以存放在集群里面,不过这样也有被篡改风险,所以很多公司会考虑Splunk等专用平台,把日志传到其他平台。Hadoop 里有很多组件,不同的日志格式,所以还需要做日志的聚合。另外仅有用户、ip这些信息不够,还要知道查询语句是什么。

7、监控和阻断

最常见的场景,计算平台资源不足,原因是某些熊孩子在平台上跑了一些垃圾任务占用了资源。又或者你发现一个恶意查询,这时候就得有手段阻止。Hadoop提供了一些监控工具,这些工具一般是嵌入在Hive或Spark这样的服务中,对恶意查询进行过滤。

四、架构安全

从安全性来说,认证、授权、加密、密钥管理、日志审计,是整个架构安全的基石,但把这些技术组合起来,如何部署和在哪里部署就十分重要了。下图是系统安全层面风险和可考虑的措施。

例如传输层保护可以有两种办法,一个是SSL这种,但要求你能够对证书进行管理。还有一种是网络分隔来保证攻击者进不来,缺少了内部防护但更容易实现。

而在身份认证和授权上,则可以考虑Apache Ranger 或者Sentry。

图片 3.png

而在下图中则是操作层面风险和措施,每种手段都各有优点,成本也不同。举例来说,在特权管理这部分,提到了不同的加密方式,在理想化的情形下这当然是最佳选择,但实际上很多大数据平台已经运行了一段时间,这个时候要做加密,会影响到上下游的生产,一个不慎就是一个事故。在这个情形下,加密就不是最佳选择,而应该考虑动态掩码,字段型标签或者token化,这会让项目很容易推进,成本也更低。

图片 4.png

在架构层面,对安全团队来说,要考虑的问题就更多了。哪些方法有效、管理起来成本比较低、能够获得业务部门支持。大型互联网公司里,安全部门提出的方案,是要接受业务challenge的。比如安全部门提出,应该对Hadoop做字段型加密,并且要使用kms一次一密,会被业务部门用刀砍死的。因此,安全总要在现实中做考量,不必拘泥于哪种是最安全的,可以多种方法组合来保障。

例如一些现实选择,Hadoop的身份验证,通过应用网关来进行,而IAM对用户来说是透明的,加密后置。集群高度多租户,就一定要考虑TLS来保护,也就更迫切的需要细粒度的动态级控制(mask、tokenization等)。

最常见的方法就是下图这种,类似于护城河。整个集群在内部,严格控制访问,整个基础设施安全取决于防火墙、认证这些保护措施。优点是简单,在业务那里不会受到什么挑战,也容易低成本实现。缺点是,一旦通过认证授权,则一路畅通。

图片 5.png

在集群内部安全中:Hadoop内部的功能是公开的,和其他关系型数据库不一样,对节点间、集群复制等功能都是透明的,对其保护需要集成很多原生、三方的安全工具,安全性应该是整个集群的一部分架构。工具可能包括:SSL / TLS确保安全通信,Kerberos的节点之间认证,静态数据存储安全性,身份和授权等。下图中标明各种安全措施的位置。

图片 6.png

此外,大型互联网公司的数据来源一般都有无数个,而安全团队很难知道数据都在哪活动,保护措施是什么,但这些数据都在数据中心的载体上,因此可选择一些基本保护措施:tokenization、masking和加密。这些措施保证不管数据在哪里使用都能够一定强度的保护。Tokenization是一个数据令牌,有点像我们在游戏厅的游戏代币,它不是现金,但是可以用来抓娃娃。在数据保护中,则用数据令牌来代替像是银行卡号的敏感数据,但数据令牌本身毫无含义,它只能去映射真正的数据。Masking则是对数据做部分遮盖或替换,比如用一个随机数来代替身份证号码,这样原始数据不会在查询中出现,但真正的数据还是在表中存储的。

图片 7.png

做这些事情,是因为无论内外部用户都是不可信的,因为你不知道数据在什么时候就被与合作伙伴或者什么人共享了,动态脱敏的做法可以根据ip、设备类型、时间来进行额外控制。静态脱敏方法可以完全掩盖敏感数据,同时保留数据分析的价值。需要根据不同情况做选择。

 

与Hadoop兼容、或者为Hadoop设计的安全解决方案数量这些年一直在增加,最大贡献来自于开源社区,甚至有的企业也会直接贡献,帮用户们解决了很大的痛苦。介绍几个工具:

1、Apache Ranger

Ranger是Hadoop集群的集中安全管理解决方案,包括审计,密钥管理和细粒度的数据访问控制。可以集成HDFS,Hive,YARN,Solr,Kafka等模块的安全认证机制。关键!Ranger是少数能够提供中央管理视图的工具,所以你可以在HDFS设置文件和目录权限,在Hive中设置SQL策略,形成一个整体性的安全控制。

2、HDFS加密

HDFS提供嵌入在Hadoop文件中的“透明”加密,数据在存储到文件系统时候被透明加密,对应用集群来说代价就比较低了。支持区域、文件、目录的加密,每个区域可以用不同的密钥,这样就可以支持多租户,也能够与KMS集成。

3、Apache Knox

可以把Knox视为Hadoop防火墙。更确切地说,它是一个API网关。Knox处理HTTP和RESTful请求,执行身份验证和策略控制。结合网络分区分域,进一步减少攻击面。

4、Apache Atlas

开源治理框架,可以管理数据血缘关系、数据字典、数据分类等一系列元数据的核心能力。简单的说,实现数据发现和访问控制。不过Atlas也才刚刚发展起来,成熟性可能是个问题。

5、Apache Ambari

管理Hadoop集群的工具,可以把配置同步到整个集群,貌似国内用的不多。当然你也可以自己写脚本,脚本可以提供自定义的功能。但是对于中小型公司来说,Ambari能快速启动运行对集群的一致性管理。

6、监控

监控有两个部分,实时分析和拦截。Hive,PIQL,Impala,Spark 模块提供的是SQL或伪SQL语法,这就可以利用前面提到的tokenization、masking来进行保护。或者更细粒度的授权,来改变替换查询结果。以数据的监控视角,会比应用的监控视角得到更多的信息。

 

五、建议

考虑Hadoop集群的安全方案,先给几个原则:

1、不能损害集群的功能

2、架构一致,不能和Hadoop架构冲突

3、能够解决安全的威胁

为什么要这样说,因为市面上太多鱼龙混杂的公司,号称提供大数据解决方案,他们自己都还在用mysql做产品。再者,Hadoop整个生态都还年轻,并不是所有工具都是成熟的。

在技术上,建议考虑如下这些部分,又或者我认为,这是一个Hadoop集群的基线安全:

1、Kerberos进行节点认证

已经这么做的公司越来越多了,而且集成Kerberos现在也比以前简单多了。Kerberos认证在节点安全上是最有效的安全控制手段之一,而且本身就是内置在Hadoop基础架构中的。建议使用。

2、文件层加密

简单的说,是保护静止的数据,可以防止管理员、恶意用户、租户的非授权访问,当然也能保证硬盘被盗后的安全。而且,很多地方已经开始要求数据必须加密存储了,也需要考虑合规。文件层加密能够保证一致性,跨越操作系统、平台、存储介质,也能在集群增加的时候无缝扩展,对应用和平台来说都是透明的。所以加密不是建议,而应该是强制选项。

3、KMS

攻击者可以拿到密钥,你的加密就没有意义了。很多管理员、开发会把密钥存在硬盘上—我真的扫描过开发和dba的硬盘,所以我知道。所以需要独立的密钥管理平台来分发密钥和证书。尤其在大规模企业中,多密钥多租户的管理就是更现实的问题。

4、Apache Ranger

前面已经介绍了。

5、自动化部署

有的公司用脚本和源代码控制实现,有的用传统的补丁管理系统来实现,还有一些就是噩梦管理方法。可以考虑配置自动化工具比如Chef和Puppet,从可信镜像安装、升级、分发密钥等。

6、日志和监控

可以利用内置的Hadoop功能创建日志,使用集群本身来存储事件,还包括像LogStash,Log4J和Kafka来进行数据流管理和搜索。

7、通信加密

SSL / TLS用于实现节点之间、节点和应用之间的安全通信,建议全部加密,虽然这对性能有一点影响,但这个开销是所有节点共享的,所以压力并不大。

加密,认证和平台管理工具大大提高了Hadoop集群安全性,在认证鉴权上的集成,细粒度的访问控制让安全工作更容易做一些。Hadoop社区的速度很快,说实话超越了我的期望值。不过坦白说,就我了解的很多国内公司,对于Hadoop的安全还停留在网络隔离的水平上,然后期望攻击者无法渗透进来,外硬内软。在合规监管的要求下,在数据开放生态的大环境下,网络隔离远远不够。希望我的文章能给大家一些帮助。

参考资料

1、https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.5.0/bk_security/bk_security.pdf

2、http://www.wuzesheng.com/?p=2345

3、http://blog.csdn.net/lalaguozhe/article/details/11570009

4、https://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH4/latest/CDH4-Security-Guide/CDH4-Security-Guide.html

5、http://www.slideshare.net/blueboxtraveler/uparmoning-the-elephant-adding-kerberosbased-security-to-hadoop

6、http://hortonworks.com/blog/the-role-of-delegation-tokens-in-apache-hadoop-security/