0784-CDP安全管理工具介绍
安全管理工具介绍
本文档描述如何使用多种安全管理工具来保护CDP环境。重点介绍安全管理工具与CDP环境之间的集成点，但不会探讨这些工具的核心功能。
CDP在内部将这些工具整合到一个全面的、统一的安全架构中，同时支持与其他第三方主流工具进行外部集成。
1.1身份认证
身份认证意味着我们能够验证用户身份。没有身份认证，所有其他安全措施均无效。例如：由于无法验证用户的身份，则用户可以把自己指定为系统管理员，而我们只能信任他。
在我们想象中，身份认证就是输入用户名和密码，但是大数据平台的分布式机制使得认证过程没有这么简单。
CDP集群由三类节点组成：边缘节点，主节点和工作节点。每种类型的节点都可能有多个。在其中一个节点（例如：边缘节点）上成为本地Linux管理员，并不意味着它应该具有HDFS分布式文件系统的管理员访问权限。
在边缘节点上，如果您是本地Linux管理员，那么你可以使用其他任何用户的安全特权（例如：HDFS管理员用户hdfs）。边缘节点并不安装CDP核心服务，只会安装CDP库（jar）和客户端配置文件（xml）。因此，边缘节点很容易放松警惕，普通用户经常会有管理员权限。这就是为什么Linux身份验证在大数据平台上不能提供充分信任的原因。
很多外部第三方应用程序都需要：
- 通过终端命令行方式（例如：Spark，HDFS）访问大多数CDP组件
- 使用“单点登录”功能：每次通过命令行对集群任何组件执行操作时，系统都不会要求用户提供密码
要解决上述安全问题，满足条件的技术是Kerberos。
1.1.1 Kerberos
我们在这里不会深入介绍Kerberos体系结构。Kerberos的主要组件是KDC（Key Distribution Center）。它负责将票证传递给身份认证模块。
每个节点上运行的CDP组件都需要与Kerberos集成在一起，以便可以接受Kerberos票证。接下来，客户端（用户或服务）需要通过KDC进行一次身份验证（命令行kinit）以获得票证，然后票证就可以传递给在任何节点上运行的任何服务，而无需再次进行身份验证。
这样一来，身份认证就可以从Linux系统中删除，这意味着，成为一个节点上的root用户并不意味着拥有访问集群的特权。同时，用户进入集群后只需要输入一次密码。
1.2 用户授权
授权是在身份认证成功之后建立一些标识，该标识即为允许用户执行的操作。
授权有很多种工具：
- 使用HDFS acl（POSIX权限设计）
- 使用Apache Ranger管理更多的数据对象，例如：表，列，行，topic，consumer group等
- 通过CDP组件的Web界面，集成LDAP目录服务，从而限制用户登录Web界面后的权限
Apache Ranger是其中功能最强大、使用最广泛的授权组件。
1.2.1 Apache Ranger
Ranger使用基于角色的访问控制（RBAC）策略和基于属性的访问控制（ABAC）策略。也就是说，Ranger通过角色或属性将组映射到数据访问权限。
例如：
- QA角色有数据库中特定数据的只读权限
- X部门的所有人都有QA角色
- 那么， X部门的所有人都可以访问数据库中的特定数据
1.2.2 Apache Atlas
Apache Atlas可以用来定义属性，也称为标签（Tags）。标签非常灵活，可以标记表，列，行，topic，consumer group和几乎其他所有数据对象。
例如：
- 使用QA标签在数据库中标记特定的数据
- 接下来，使用QA标签为用户或用户组添加标签
- 如果用户的组标签和数据对象标签匹配，则用户可以访问这些特定的数据
1.2.3 组成员
以上两种方式都有一个基本思路：通过组成员身份来管理访问。
很多外部第三方应用程序都需要：
- 与CDP组件集成
- 企业级集中式信息管理
- 开箱即用的安全工具
满足上述条件的主流技术是LDAP目录服务。
1.2.4 Kerberos+LDAP目录服务
Cloudera 建议通过Kerberos进行身份验证，然后通过基于目录服务的用户组进行授权。
HDFS，YARN和其他CDP组件会使用“ id -gr” Linux命令，Apache Ranger也会使用类似的Linux命令。
这些组件通过从Kerberos用户名中剔除Kerberos Realm来提取OS用户。例如， Kerberos用户名为fayson@cdp.com， fayson将被提取出来作为OS用户，由此衍生出组成员身份。
在Linux环境，“ id”命令可用于查询组成员身份。那么如何将目录服务中的用户和用户组映射到Linux环境呢？一般使用SSSD或者Centrify。SSSD或者Centrify允许将用户/用户组从目录服务引入Linux OS级别，更重要的是，它允许CDP组件直接从Linux OS级别获取组成员身份，而无需再访问目录服务。
注意：Active Directory组织单位（OU）和OU用户--应该在Active Directory中创建一个单独的OU，以及一个有权在该OU中创建其他帐户的帐户。该帐户将被分配给Cloudera Manager，以便它可以为每个CDP服务自动创建账号。
1.2.5 Microsoft Active Directory 和Redhat IPA (IDM)
Kerberos和LDAP目录服务是完全独立的产品，各自管理各自的用户。因此，CDP需要将两者集成在一起，以便它们共享同一数据库。有两种主流产品：Microsoft Active Directory和Redhat IDM（IPA）。
- MS AD包含了安全管理的所有模块：Kerberos，LDAP目录服务，TLS CA，DNS，NTP。AD和集群所有节点的Linux OS之间的SSSD集成需要独立完成。MS AD只能在Windows上运行。
- Redhat IDM使用开源组件：MIT Kerberos，389 LDAP，DogTag（TLS，DNS，NTP），在安装新客户端时开箱即用的SSSD部署。另外，Redhat IDM还有自己的Web UI，所有组件均由Redhat开发的python脚本整合在一起 。Redhat IDM在Redhat及其衍生产品上运行。
1.3 通过Web界面进行身份认证和授权
Cloudera集群有很多组件都有自己的Web界面，例如Cloudera Manager，HUE，Atlas，CDSW等等。
每个用户界面都可以通过LDAP协议与目录服务集成，以进行身份认证和授权。 但这样做的缺点是，用户每次使用时都需要输入密码。
1.3.1Apache Knox
还有一种选择是使用Apache Knox这样的身份认证网关。Knox可以与Cloudera集群中的所有Web UI集成。出于授权目的，UI和目录服务之间会在用户组映射方面进行一些后台集成，这极大提升了用户的使用体验。
建议先使用单点登录（SSO）技术（例如SAML，Okta是其中一种比较流行的实现方式）来登录Knox。然后，再通过Know登录到所有基础组件的Web UI。
Apache KNOX经常被用作对集群的单点访问。
KNOX的优点：
- 第一道防线变成单个（或启用HA）入口点，比较容易管控
- 通过KNOX进行身份验证，并不依赖外部的Kerberos，因此，当用户和集群不在同一域中时，不会出现SPNEGO问题
- 通过一个中心点来完成相互之间的SSL证书验证
KNOX的缺点：
- 客户端软件必须支持REST API，因为KNOX完全基于HTTPS
1.4 数据加密
1.4.1 网络加密
Cloudera集群可以使用传输层安全性（TLS）进行加密：
- 到所有Web UI的网络传输
- 集群节点之间的网络流量
- 终端用户和节点之间的网络传输
- Cloudera Manager Server和Agent之间的网络传输
1.4.2 静态数据加密
Cloudera也可以使用透明数据加密（TDE），在数据写到磁盘之前对数据进行加密。
解决方案如下：
- Cloudera透明加密可对HDFS上存储的数据进行加密
- Ranger Encrypt对与Cloudera Manager，Atlas，Hive和HBase相关的所有其他类型的数据（包括元数据，日志和spill数据）进行加密
- Key Trustee Server用于加强型和容错型的密钥管理
HDFS数据加密是其中最核心的内容。因为在HDFS上有大量的CSV文件或其他纯文本文件，则这些纯文本内容默认是没有加密的，在Linux文件系统中处于可读状态。
1.5 审计和监控
安全管理有一项基本原则是“充分信任用户行为但必须进行审计跟踪”。
1.5.1Apache Ranger
即便是安全集群，也仍然需要启用审计服务。CDP使用Apache Ranger来提供审计报告，以便更深入地控制生产环境。Ranger插件从用户日常操作中收集审计日志，并通过一个独立的线程汇聚到Ranger Audit Server。Ranger在后台使用Solr存储审计日志，并通过Ranger Admin UI提供自助式搜索。在默认情况下，Solr Audit Collection的保存周期为90天。
Ranger审计记录同时也会写入HDFS。因为合规要求，企业往往需要保留很长时间的安全审计记录，因此HDFS中存储的审计记录可以导出到任何SIEM系统或外部离线存储中。
Ranger审计报告通常用来查看用户访问轨迹及其结束状态。同时，还能用来调整Ranger现有的访问策略或者定义新的访问策略。
基于以上方式，我们可以对集群中发生的事件进行监控和审计，以便在发生重大安全事故时进行取证分析。