1.介绍
狂战士是哔哩哔哩一站式数据开发与治理平台，基于通用大数据生态组件，满足数据查询、数据分析、日报、数据集成、数据开发、实时计算、数据治理等多种业务场景。在哔哩哔哩，我们通常将狂战士缩写为BSK。
图一。狂战士的整体建筑
图二。狂战士主页
其中，数据安全是狂战士平台的重要组成部分，将对公司内部的Hive、Kafka、ClickHouse、ETL任务等各类资产进行统一的数据安全管理，对数据平台部门内部的数据开发、数据分析、数据报表、数据治理等各类数据产品进行统一的功能安全控制。
本文将重点介绍狂战士数据安全的建设过程。
2.数据安全建设
2.1安全目标
我们安全建设的目标是确保信息资产的机密性、完整性和可用性；
图3。情报局的三个要素
2.2 5A方法
我们将按照数据安全5A的方法论来构建一个完整的安全产品，在每个主要流程中提供相应的产品和服务，实现安全闭环。
图4。数据安全5A方法
其中包括:
身份认证（Authentication）：用户主体是谁授权（Authorization）：授予某些用户主体允许或拒绝访问客体的权限访问控制（Access Control）：控制措施以及是否放行的执行者资产保护（Asset Protection）：资产的保密性、完整性、可用性保障可审计（Auditable）：形成可供追溯的操作日志
2.3数据安全架构
图5。总体框架
其中包括:
身份认证
狂战士连接到公司的统一身份认证。新建账号时，会将账号同步到公司的AD域控制管理，大数据组件会通过Kerberos进行认证。
授权
一般用户在狂战士平台进行数据安全变更(如权限申请)，授权结果记录在数据安全中。数据安全将授权结果同步到Ranger和ClickHouse。
访问控制
狂战士和数据开发等服务由数据安全服务进行身份验证。
Hive、Spark、Flink等计算引擎通过Ranger认证。
资产保护
我们根据不同的数据安全级别制定不同的数据保护策略，采取下载限制、数据脱敏、安全水印、可追溯性等多种措施来保护现在的数据。
审计
记录用户或系统的操作，并将其用于事件跟踪。BSK系统中的多数据服务已接入审计，数据访问分析也通过HDFS元仓库(基于FsImage和HDFS审计日志)进行。
2.4里程碑
2020年7月，首个数据安全服务权威体系从狂战士平立出来。2022年7月，数据安全升级到2.0，经历了几次大的变化。
图6。主要时间节点
2021年8月开始规划数据安全2.0，2021年11月开始前期开发工作，2022年7月上线。其最大的变化如下:
重新设计了一套权限管理系统产品形态上引入了工作空间
3.遇到的问题
3.1权限变更
本质上，权限主要包括账号、资源、权限类型三部分。与1.0相比，Permission 2.0极大地改变了这三个块的设计，主要体现在:
简化了账号体系标准化了资源模型丰富了权限类型
许可1.0
图7。权限1.0模型图
权限系统1.0具有以下特性:
权限系统基于用户进行权限管理并没有区分数据权限和产品功能权限有各种不同的账号类型，权限可以来自于个人、部门、用户组和角色等ETL任务是以个人身份运行权限只有读、写、DDL三种，而且存在包含关系Hive表可以继承Hive库权限
这带来了许多问题:
权限来源过于丰富，账号、资源、权限类型三者都存在继承或包含关系，以至在多数情况下难以定位某用户为何拥有某个资源的某一权限部门变更困难，因个人继承了部门权限，用户变更部门可能会造成其负责的任务无法正常运行权限类型太少，且难以扩展，已经不能满足各种不同的业务场景数据级权限和功能级权限没有分离，难以做到精细化运营。如管理员应该只拥有功能权限，但却拥有所有的数据权限
我们对上述问题做了详细的评估，确认在原有权限体系下难以解决，于是设计了新的权限体系。
许可2.0
图8。权限模型
与1.0相比，2.0的权限有了很大的调整:
进行了账号调整，并拆分三种账号类型以满足多种场景个人账号：认证公司员工，可以获取资源权限系统账号：对接服务平台，不可获取资源权限工作空间账号：ETL任务的运行账号，可以获得资源权限功能权限和数据权限进行了分离数据权限没有继承关系功能权限只能来自于角色，个人继承角色权限，角色间没有包含关系删除了用户组，删除了部门权限扩展了权限类型，并可按不资源类型的不可设置不同的权限类型
比如Hive表是:hive:select，hive:update，hive:alter，hive:drop等权限。
统一了资源定义，并在berserker各子业务间通用
升级过程
由于权限2.0和权限1.0存在差异，在升级过程中，为了保证稳定性，减少用户体验差异，我们主要采取了以下提升措施:
前期小范围验证
在大规模推广Permission 2.0之前，我们进行了一次小范围的验证，以保证系统的稳定性和可靠性:
实现2.0-alpha版，并接入项目的协作管理，但该版本的设计存在一些缺陷，与最终版本存在较大的差异，但为后续改进提供了宝贵的经验。目前项目的协作管理已经按最终方案进行了调整实现2.0-beta版，并接入ClickHouse表权限管理。该版本为权限2.0的原型基于2.0-beta进行完善，小步快跑，多次迭代，形成完善的权限系统权限系统的兼容
数据安全是狂战士的基础服务，为大量服务提供安全支持。同时，数据安全改造也不可能一蹴而就。在推广过程中，有的商家用1.0，有的商家用2.0。因此，我们需要确保系统兼容:
保留并维护权限1.0数据，并实现权限数据双写，如：用户账户、资源等数据需要实现双写，权限2.0的数据同步写回1.0中保留权限1.0相关接口，但不维护该接口，并标志该接口为废弃，业务调用时将打印调用方信息，通过收集调用日志，找到推动调用方使用新接口保留权限1.0数据入仓，以兼容原有数仓业务，同时推动数仓相关业务使用新权限数据数据的迁移
数据迁移包括历史完整数据迁移和增量数据迁移，这将在下面讨论。
3.2权限迁移
背景
为了减少用户的麻烦，保证业务的正确运行，我们需要实现无缝的权限数据迁移，包括数据权限迁移和功能权限迁移。
数据迁移也存在一些问题，尤其是Hive表的权限数据迁移。
3.2.2配置单元表迁移
需要全迁移的数据权限包括:Hive表、Hive库、数据源、主题、ETL任务等。接下来，我们将重点介绍Hive表权限数据的迁移过程。
我们原本计划将部门、角色、用户组等Hive表的权限全部扩展到个人，但是通过计算发现，如果全部扩展权限，最后会有2亿多条权限记录，这显然是有问题的:
权限不合理部门拥有数据权限也不合理，一个部门内可能仅有少数同学使用BSK平台，而其他同学可能都不知道BSK是什么系统管理员可能只是用来审批或管理某些功能，并不使用数据，但依然拥有所有表的权限存在技术问题数据量太大，很难同步到Ranger
权限系统和Ranger数据库在不调整结构的情况也无法存储如此大的数据量
获取有权限的Hive表列表较常见的功能也难以实现
权限系统内部也难以加载并处理如此多的数据。
引入work 空后，任务将在work 空的账号下运行，必须为work 空的账号添加正确的权限。
最后，我们放弃了将原有权限全部扩展到个人的方案，而是采用了HDFS元仓库的分析，通过用户的历史访问行为来添加相应的权限。
图9。配置单元表权限同步过程
我们通过ETL任务实现了Hive表的全数据迁移，主要流程如下:
通过查询近半年的HDFS 元仓数据，获取用户Hive表使用记录，并根据操作类型的不同为使用添加读或写的权限表的责任人为授权 select、update、alter权限个人申请的权限，新系统依然保留该权限用户组的权限展开到个人表归属工作空间授予该表Select、update、alter权限表的产出任务所在工作空间授予该表Select、update、alter权限
通过以上，大大减少了权限策略的数量。同时，权限2.0上线后，没有发现因Hive表迁移导致的权限问题。
缺陷
Hive表权限还是有一些不足，需要后期处理:
只通过近半年的元仓数据，可能会遗漏部分年任务的访问记录，造成相关权限缺失用户权限存在扩大风险，用户申请的权限过期后，因为有访问记录，因此权限0中依然会给到权限，但考虑到多数情况下个人账号并不运行ETL任务，风险可控部分用户依然保有写权限。主要为兼容部分第三方任务（非BSK平台上提交的任务），该任务可能未及时改用工作空间账号、而依旧使用个人账号运行
3.3工作间推进空
背景
随着数据平台用户的增长和服务的丰富，基于用户的数据安全模型系统难以支持各种灵活的业务需求，主要体现在:
图10。基于用户的安全系统存在的问题
我们重新规划了数据安全体系，并参考了业界主流的解决方案，引入了工作室空作为管理资产、任务、成员、角色和权限的基本组织单元。
3.3.2工作空模型
图11。工作空模型
你可以看到:
一个空间只能属于一个部门，一个部门可以拥有多个空间用户可以加入到多个工作空间数据资产归属于工作空间空间内的角色只对当前空间有效
workshop 空的引入将涉及各方的变革，包括但不限于:数据安全、数据开发、数据集成、数据质量、数据治理、数据仓库以及各种数据应用。为此，我们制定了严格的推广策略。
推进过程
workshop 空的整体提升改造过程主要分为四个阶段:
图12。工作间推进流程空
work 空之间的后续工作将按照项目的正常迭代进行。
workshop 空推出后，无论是功能还是技术方面都有了很大的提升。为了降低用户的理解成本，我们在推广过程中采取了一些策略:
不向用户暴露工作空间账号，而是先个人申请权限，提交ETL任务时，通过ETL任务的血缘将个人权限授予工作空间账号因为改动较大、涉及涉及业务方较多，也为了减少升级引起的不确定性，我们选择在周六进行统一升级，减少对用户的打扰为每个一级部门引入默认工作空间，同时每个部门成员将默认加入到该空间，保证推进过程中用户无需要做任何操作依然可以工作空间内的功能ETL任务归属空间后，该ETL的Owner及拥有该任务协作权限的用户也将作为工作空间的开发加入到该空间，以保证用户操作的一致性
3.4 Cain优化
背景
Cain是一个强大高效的开源访问控制框架，其权限管理机制支持多种访问控制模型。Cain用于权限系统内的权限管理。
泰山是哔哩哔哩开发的分布式KV数据库。
权限系统采用泰山缓存权限策略，减轻服务和数据库的压力。权限系统的内部处理流程如下:
图13。授权系统的内部授权/认证流程
可以看到，权限系统内部处理的主要过程如下:
授权：用户授权操作直接写入数据库同步Cain：通过监听数据库最后修改时间，异步同步权限策略到Cain同步Taishan：通过消息队列异步同步权限策略到Taishan，期间使用Cain进行鉴权鉴权：正常情况下都将使用Taishan进行鉴权，但当Taishan数据异常时将降级到使用Cain鉴权。
我们在实施过程中也发现了一些问题:
时间时延。Cain是采用异步加载的方式，难以保证顺序一致。我们要求权限策略表延时5秒加载，以保证资产元数据处理完成。Taishan记录最后一次数据修改时间，内存中也记录最后一次数据修改时间，当两时间超时30秒，表示Taishan时间不可用Cain的性能问题
3.4.2 Cain添加权限性能调优
当我们进行权限迁移时，我们需要在Cain中加载所有权限策略。我们发现Cain的加载性能很低，经过调试，问题定位在hasPolicy的实现上。
下面是hasPolicy和Policy的实现:
图14。用于判断策略是否存在的Cain源代码。
图15。策略定义源代码
HasPolicy函数判断是否已经存在相同的策略，每次添加新策略时都会调用它进行判断。其时间复杂度为o (n 2)，其中策略个数为n，当策略达到一定规模时，性能急剧下降。
我们对Cain进行了优化，增加了一个集合策略集合来记录加载的策略，并判断该集合是否包含hasPolicy中的策略，大大提高了性能。
值得一提的是，Cain 1.25.0之后的版本修复了这个BUG。因此，我们也恢复使用开源版本。
Cain 1.25.0中的实现:
图16。Cain添加策略的优化
可以看到Cain1.25.0之后的版本增加了policyIndex优化hasPolicy。
3 . 4 . 3 cas bin恢复权限的性能调整
大量权限恢复操作很少见，主要在以下情况下:
资源治理，做批量Hive表删除，需要删除相应的权限策略BSK平台的重度用户转岗或离职，需要做资产交接，进而删除其权限工作空间治理，下线工作空间，需要删除工作空间账号的权限
大量权限回收时Cain也会卡死。经过调试，问题将定位在策略和策略索引的维护中。
以下是Cain删除权限策略的源代码:
图17。Cain策略删除了源代码
可以看到，Cain删除权限策略的步骤如下:
通过policyIndex找到权限对应的index通过调用remove删除policy中的元素重新更新受影响的policyIndex
Cain的权限恢复时间复杂度也是O (n 2)，性能较低。
在处理这个问题时，我们没有直接修改Cain源代码，而是引入了类似于数据库的标志删除:
在权限策略中添加deleted标志，标记该策略是否已删除， 鉴权时添加deleted判断回收权限时将删除改为更新操作权限策略中deleted标志的值使用双缓存，定期清理过期权限
即定期创建一个新的Cain模型，加载未删除的权限策略，完成后替换原来的Cain模型，从而清理回收的权限。
目前Cain的删除性能也有了很大的提升。
3.5更多问题
除了上面提到的问题，我们在数据安全建设过程中还存在很多问题，比如:
HDFS路径的权限问题，包括路径权限的继承问题使用Flink CDC或Hudi的任务中间表的归属及权限问题如何预防工作空间账号权限一直扩大的问题非分区Hive表全量更新时删除Hive表所在目录的问题
4.未来前景
在建设狂战士数据安全的过程中，我们参考了许多公司和商业产品的最佳实践，同时确认我们的产品还处于初级阶段，还有大量的功能需要完善。
未来我们的建设路线主要会在几个方面:覆盖全生命周期的数据安全、更加精细化的权限管理、敏感数据保护和风险评估。
本期作者
李昌海-毕丽·毕丽高级开发工程师
大数据平台工具负责人韩志华
来源:微信微信官方账号:科技
资料来源:https://mp.weixin.qq.com/s/L7qecnydWTEnrwixVfwAIw.