《2022大数据平台安全报告》由会员分享，可在线阅读，更多相关《2022大数据平台安全报告（31页珍藏版）》请在金锄头文库上搜索。
1、1大数据平台安全报告目录一、大数据平台概况1(一)大数据产业蓬勃发展1(二)大数据平台应用模式多样化演进2二、大数据平台安全现状4(一)组件配置类安全隐患6(二)组件安全漏洞9(三)组件安全隐患统计分析12三、大数据平台安全问题分析18(一)基于 Hadoop 的开源大数据平台安全配置复杂度较高19(二)安全漏洞修复对平台运行影响较大19(三)大数据平台建设过程中安全投入不足21(四)大数据平台重视边界防护忽视内部安全21(五)企业大数据平台安全管理制度滞后22(六)企业技术人员安全能力不足23四、大数据平台安全解决方案建议23(一)加强大数据平台安全基线管理24(二)对大数据平台安全进行整体
2、规划24(三)大数据平台边界防护与内部安全建设并重25(四)建立完善的大数据平台安全制度流程25(五)增强企业技术人员安全能力25五、大数据平台安全未来发展建议26(一)加强企业大数据平台安全防护工作的监管26(二)强化大数据平台安全防护技术研究27(三)推动大数据平台安全产品和服务市场发展27(四)构建大数据平台安全生态28图 目 录图 1 中国大数据市场规模预测2图 2 大数据平台架构2图 3 大数据平台类型分布占比5图 4 大数据平台组件配置安全隐患统计6图 5 大数据平台安全漏洞统计10图 6 单个组件安全隐患占比13图 7 单个组件配置安全隐患占比13图 8 单个组件安全漏洞占比14
3、图 9 各类组件安全隐患占比15图 10 各类组件配置安全隐患占比15图 11 各类组件漏洞安全隐患占比16图 12 传输类组件安全隐患等级分布17图 13 存储类组件安全隐患等级分布17图 14 计算类组件安全隐患等级分布18图 15 平台管理类组件安全隐患等级分布18图 16 漏洞修复方式选择流程图20大数据平台安全研究报告一、大数据平台概况当今时代大数据产业持续发展，对于挖掘新的经济增长点大有益处，大数据成为了推动各行业发展的新动力。大数据平台作为大数据的载体起到了关键作用。(一) 大数据产业蓬勃发展根据IDC 最新预测，2020 年中国大数据相关市场的总体收益将达到 104.2 亿美元
4、，较 2019 年同比增长 16.0%，如图 1 所示，增幅领跑全球大数据市场。2020 年，大数据硬件在中国整体大数据相关收益中将继续占主导地位，占比高达 41.0%；大数据软件和大数据服务收入比例分别为 25.4%和 33.6%。而到 2024 年，随着技术的成熟与融合、以及数据应用和更多场景的落地，软件收入占比将逐渐增加，服务相关收益占比将保持平稳，而硬件收入在整体的占比则将逐渐减少。硬件、服务、软件三者的比例将逐渐趋近于各占三分之一的比例。IDC 预计，在 2020-2024 年的预测期间内，中国大数据相关技术与服务市场将实现 19.0%的年均复合增长率。28图 1 中国大数据市场规模
5、预测数据来源：IDC 中国，2020(二) 大数据平台应用模式多样化演进大数据平台通常使用 Apache Hadoop 架构进行搭建，由存储、计算、平台资源管理、传输交换等类型组件组成整个平台，如图 2 所示。目前，大数据平台主要有基于开源技术的自建平台和商业化平台两种。自建平台灵活性强、自主性高，商业化平台安全性强、使用便捷。图 2 大数据平台架构数据来源：中国信息通信研究院1. 自建大数据平台灵活性强、对企业技术水平要求较高自建平台使用开源大数据平台技术架构，其优势在于有较高的自主性和灵活性，企业可以根据业务需求选择不同的功能组件，同时所有数据都在自己的管控范围内，避免第三方参与造成的数据
6、泄露。除此之外，虽然自建大数据平台建设成本较低，但需要足够的人力资源和较高的技术水平，才能满足平台正常运行维护的需求。运维人员需要关注各个组件的配置与漏洞情况，根据最新的风险情报对平台进行加固，防止风险事件的发生。参与卓信大数据平台安全专项行动的企业中，只有少数几家企业采用自建的方式，这些企业都有自己的大数据技术团队作为支撑。2. 商业化大数据平台易管理、安全性高商业化大数据平台可分为委托式大数据平台和自主控制式大数据平台。委托式大数据平台由供应商进行日常维护，用户通过服务调用方式使用大数据平台。自主控制式大数据平台搭建在用户的服务器或私有云上，用户对大数据平台具有控制权，且自主进行日常维护。
7、二者都采用成熟的商用大数据平台产品，产品安全性均经过供应商的专业测试，用户的日常使用亦可得到供应商的技术支持。（1） 委托式大数据平台成本低，供应商一般提供全托管式服务，但定制化程度不高委托式大数据平台部署于供应商侧，其提供的服务通过接口等方式供使用者调用。平台通常采用虚拟化技术，大数据平台服务被多个使用者共享。供应商对该种大数据平台拥有控制权，并负责日常运维。对用户而言，此种方式无须自行搭建大数据平台，前期使用成本较低。然而，该种方式的大数据平台对企业的定制化程度不高，企业部署的系统及软件需符合大数据提供商的相关技术标准。提供委托式大数据平台的厂商有：亚马逊、阿里云等。（2） 自主控制式大数
8、据平台成本较高，功能全面、保密性强自主控制式大数据平台是企业将具备完善功能的大数据平台部署在自己的服务器或私有云上，并自行负责日常的大数据平台运维。此种大数据平台服务为企业独占，用户可根据自身需求进行定制化， 因此该模式的平台保密性强，且功能全面。同时，自主控制式大数据平台可在一定范围内进行大数据组件的自主选择和搭配使用。相对于委托式大数据平台，自主控制式大数据平台的硬件使用和日常运维由企业自行负责，成本较高。二、大数据平台安全现状随着企业大数据平台对内运营的支撑能力不断提升，数据来源不断丰富，数据分析挖掘功能不断创新，数据安全问题与挑战日益增加，企业对大数据平台的安全保障要求也不断提高。目前
9、，大数据平台组件往往独立设计、开发，并根据不同的业务需求进行组合搭建，若是对平台组件的安全管控不当，极易造成非法访问、敏感数据泄露等安全风险。本章以参与卓信大数据平台安全专项行动的企业大数据平台安全检测初测结果作为数据来源，统计各类安全隐患的分布、排名和影响等级情况，同时分析了主要安全隐患产生的根源和可能的危害影响。以下统计数据不代表参与行动企业当下的大数据平台保障安全工作现状。大数据平台类型分布图4%9%39%17%31%CDH HDP EMRApache Hadoop其他首先看到，本次专项行动检测的大数据平台类型基本涵盖了主流平台应用类型，具体分布如图 3 所示，CDH 平台占 39%，H
10、DP 占31%，EMR 占17%（其中阿里云EMR 占9%，腾讯云EMR 占8%），原生 Apache Hadoop 集群占 9%，优刻得 Ucloud 和星环 TDC 等其他平台占 4%。数据来源：中国信息通信研究院图 3 大数据平台类型分布(一) 组件配置类安全隐患组件配置安全隐患TOP71009080706050403020100存在该问题的企业占比（%）日志记录不完整身份认证机制未开启账号权限未做到最小化审计日志文件访问控制未开启 组件未配置SSL加密服务连接数未作限制敏感配置数据未加密从本次专项行动检测初测结果来看，日志记录不完整、身份认证机制未开启等组件配置安全隐患在受检企业大数据
11、平台中普遍存在，如图 4 所示，其中排在前五位的是日志记录不完整、身份认证机制未开启、账号权限未最小化、审计日志文件权限未最小化和组件间数据传输未加密，出现以上配置安全隐患的企业在所有受检企业中的占比分别为 90%、88%、80%、79%、74%。这些配置管理上的安全隐患会给大数据平台带来数据安全审计日志不全、组件访问权限管理失控、敏感数据泄露或被篡改、集群拒绝服务等安全危害。本章对常见的组件配置类安全隐患出现的根源及可能引发的后果进行解析。1数据来源：中国信息通信研究院图 4 大数据平台组件配置安全隐患统计1. 组件配置安全隐患一：日志记录不完整出现此类隐患的主要原因是组件的日志记录文件使用
12、了默认的配置参数ERROR。这种情况下，组件的日志文件只记录了组件已发生错误事件的日志信息，而未记录潜在的错误信息、组件访问记录等信息。潜在的错误信息往往隐含着口令爆破等攻击行为信息， 组件访问记录包含了组件被访问的时间、操作者、事件类型、被访问资源记录等要素，这些信息的缺乏会导致后续数据安全审计因缺乏相应数据源，而无法及时发现数据滥用、内部泄露等风险。2. 组件配置安全隐患二：身份认证机制未开启出现此类安全隐患的主要原因是开启 Kerberos 认证机制会提高集群的消耗、降低工作效率。开启 Kerberos 认证机制后，所有的新节点加入集群时，都要向 KDC 申请身份凭证；每隔一段时间，集群
13、中所有节点都要再次向 KDC 申请身份凭证；且所有外部应用（Client） 对集群（Service）的访问都需要通过 Kerberos 认证后才能进行，相比 Client 到 Service 的点对点直接访问，开启 Kerberos 认证机制后， 集群增加了额外的认证过程消耗。集群不开启 Kerberos 认证机制时， 采用默认的Simple 认证方式，通过简单 ACL（访问控制列表）方式执行外部用户的访问控制。若攻击者通过字典等攻击方式获取了系 统用户名密码，则可以获得集群资源的控制权。不仅对集群的正常 运行带来极大危害，也会使得平台上的数据完全暴露给攻击者。3. 组件配置安全隐患三：账号权
14、限未做到最小化出现此类安全隐患的主要原因是账号权限分配不规范，权限配置方面未做到最小化，给组件运行账号分配的权限过高。有的企业给运行组件程序的账号分配了 root、administrator 或 supervisor 等高级别权限，有的企业把运行组件程序的账号放到了 sys、root、administrator、super 等超级管理员组中。权限过高的账号加重了运维人员误操作、内部人员窃取数据或破坏系统的安全风险，同时增加了外部攻击可能造成的破坏和影响程度。4. 组件配置安全隐患四：审计日志文件权限未最小化出现此类安全隐患的主要原因是未修改平台审计日志文件的访问权限，使用了默认参数值，致使审计日志文件的访问权限向平台所有用户公开，安全审计组和超级管理员组之外的用户也可以访问审计日志文件，进行修改、删除等操作。攻击者通过非法手段获取到任意一个账号，就可以对审计日志进行操作，隐藏数据窃取、篡改等攻击行为，使得集群安全审计和溯源失去准确的数据源，无法达到及时发现安全威胁、处置安全事件的目的。5. 组件配置安全隐患五：未设置组件间传输加密出现此类安全隐患的主要原因是未对平台服务与客户端间的数据转移实施加密，导致数据在传输过程中存在截取、篡改等安全风险，无法保证数据的保密性。6. 组件配置安全隐患六：服务连接数未限制出现此类安
