其他分享
首页 > 其他分享> > 将军令:数据安全平台建设实践

将军令:数据安全平台建设实践

作者:互联网

背景

在大数据时代,数据已经成为公司的核心竞争力。此前,我们介绍了美团酒旅起源数据治理平台的建设与实践,主要是通过各种数据分析挖掘手段,为公司发展决策和业务开展提供数据支持。

近期,业内数据安全事件频发,给相关企业造成了无可挽回的损失,更为数据安全防护意识薄弱的企业敲响了警钟。如何对公司内部数据最为集中的数据分析、数据服务、数据治理等各种数据类产品进行权限管控,已经成为数据安全建设中最为重要的任务。

如果从控制力的角度来进行划分的话,权限管控可以分为功能级权限管控和数据级权限管控。早期的数据安全产品大多使用传统的权限模型,只能实现功能级权限管控,无法进行数据级权限管控。基于数据类产品更高的安全要求,我们需要构建一个同时满足各类产品数据安全的我们需要构建一个同时满足各类产品数据安全的平台。

为此,美团用户平台应用研发组不仅设计了能表达和管控各种复杂关系的权限模型,还针对事前、事中、事后等三个场景,分别设计了审批、权限、审计三个子系统以保障数据安全的完整闭环,进而满足数据安全的各种要求。

图1 权限背景

功能应用类产品的权限表达,一般为“是否有权限”,而数据类产品权限表达的关系更加复杂。例如数据类产品的报表,不仅需要表达出用户能否访问这个报表,而且需要表达出用户能访问报表中的哪些维度、指标以及维值的范围。还需要告知这些维度指标来自于哪些库表模型,是否有权限访问以及创建报表。

权限模型

传统的权限模型有ACL(Access Control List)访问控制列表,RBAC(Role-Based Access Control)基于角色的访问控制等。以上模型比较适用于应用类型产品的权限管控,而数据类型的产品对信息安全的要求更高,而且各类资源间的关系也更复杂,使用传统的模型难以将内部关系进行清晰的表达,所以我们在RBAC权限模型的基础上,扩展设计了新的权限模型。

图2 传统权限模型

如图2所示,传统的权限模型:

为什么要设计新的权限模型?

  1. ACL模型是用户与资源直接建立关系,没有角色的概念。当某些用户需要一批同样资源的权限时,赋权操作就变得很复杂,此时这种模型就不太适应了。
  2. RBAC模型引入了角色的概念,角色与资源建立关系。当某些用户需要一批同样资源的权限时,只需要构建一个角色并赋予使用这批资源的权限。当用户加入这个角色时,则拥有该角色的所有权限。解决了赋权操作复杂的问题。

不过ACL模型和RBAC模型,都存在以下几个问题:

  1. 数据类产品资源之间关系复杂,不能很好地表达这种复杂的关系。例如:一个报表下有多个标签页,一个标签页下有多个组件,一个组件下有多个维度、指标等。同时维度、指标又来自不同的数据模型、库表等。资源与资源之间存在关系,当管理员给一个用户赋予报表的全部或部分权限时,报表下的子资源需要同时获得对应的权限。
  2. RBAC模型中角色与角色之间没有对应的关系。例如:组织架构中,员工所在的组织架构如下:华东区/销售一区/销售一组,员工拥有的角色是销售一组的角色。当角色之间没有关系时,员工如果需要华东区角色的权限时,需要添加到华东区的角色中。而如果角色与角色之间具有从属关系时,则能很好地解决这个问题。

新的权限模型是如何解决上面这些问题的:

  1. 设计资源模型时,资源与资源之间具有从属关系,并且资源允许多层级,以树形结构展示。例如报表是一个父资源,标签、组件、维度指标都是报表下的子资源,这样赋权时能清晰地展示出报表资源与下面的子资源的关系,赋权和鉴权时才能满足各种权限控制的要求。
  2. 角色与角色之间具有从属关系,例如员工在华东区/销售一区/销售一组的组织架构中,华东区/销售一区/销售一组这3个角色之间分别具有父子级的从属关系,当员工在销售一组部门下,则拥有华东区、销售一区、销售一组的所有权限。当权限不冲突时则直接合并所有权限,冲突时则以“就近原则”进行覆盖。

图3 新的权限模型

如图3所示,新的权限模型包含3个部分,用户中心、资源中心、权限中心。

用户中心:用户管理、角色管理

图4 用户中心

资源中心:资源管理

图5 资源中心

权限中心:角色与资源的关系的多种策略表达

图6 权限中心

挑战

在建设数据安全平台的过程中,主要面临以下几点挑战:

解决思路

  1. 提供灵活可插拔的Plugin服务,在通用权限基础上,满足各个业务线灵活的权限管控要求。
  2. 提供一个通用的数据安全平台,满足基本的权限、审批、审计的基础功能。
  3. 微服务架构、核心与非核心服务分离、数据缓存降级满足系统高可用。

解决方案

图7 将军令整体架构

如图7所示,将军令分3块,数据内容权限平台、审批流平台、审计日志平台:

具体方案

Plugin服务层,保证系统灵活可扩展

在满足通用权限的基础上,各个业务线难免会有定制的权限管控需求,于是设计了权限Plugin模块。

通用服务提供用户管理、资源管理、鉴权授权的服务,Plugin调用基础服务实现特殊的权限管控。Plugin模块的应用和数据各自单独管理,通过RPC方式调用通用服务实现灵活可插拔。后续Plugin模块的服务支持各个接入的应用单独定制开发。

图8 Plugin服务

如图8所示,通用权限的服务与Plugin的服务是分离的,支持多个Plugin服务灵活可插拔:

最终的权限实现分层管控,分为核心数据层(用户、资源、权限数据)和应用层。核心数据层的数据由通用服务进行管理,达到权限数据统一管控的要求。应用层以Plugin服务方式接入,Plugin通过通用服务层对外的SDK进行权限数据读写,达到定制的管控要求。应用层的数据各自存储,可以自定义管控规则。接口之间的调用通过BA认证鉴权,保证服务之间调用的安全性。

基础服务层,保证系统通用性

通用权限系统架构

使用微服务架构设计,系统分为接入层、服务层、数据库层、以及外部服务层。主要包含以下几个核心服务:

图9 权限系统架构

如图9所示:

审批系统架构

提供通用的审批服务,提供多级审批模板,使用时选择模板启动审批流,审批系统按照启动的参数进行规则解析,自动适配对应的审批流程。缩减接入流程支持一键接入。

图10 审批系统架构

如图10所示:优化审批接入流程,提供通用的审批服务,减少系统接入开发成本:

提供通用的规则解析引擎,支持审批人、审批条件、审批通知按照规则动态解析匹配。灵活实现自动审批、多人多级审批、定时催办等多种通用功能。

对接权限和审计系统,保证审批系统数据安全:

审计系统架构

提供通用的数据审计服务,客户端日志埋点上报,审计日志按类型落到Elasticsearch中存储。对接如意可视化报表出审计报告,对接权限系统管控数据权限。

图11 审计系统架构

如图11所示:审计数据模型层支持自动扩展:

保证系统高可用

微服务架构服务分离

随着系统的模块功能越来越多,单一架构模式已不再适合敏捷开发,模块越来越大系统启动则越慢,任一模块出错则整个系统的服务都不可用。

为了保证服务的高可用和扩展性,于是以微服务架构把模块进行拆分,并把核心与非核心服务进行分离。

图12 微服务架构

如图12所示:

权限继承

由于资源支持多层级,设计权限模型时支持权限继承,当赋权时开启继承,则用户默认拥有该资源以及下面所有资源的全部权限,数据存储时只需要存储祖先资源与用户之间的关系。大大减少了权限矩阵大小。

图13 权限继承

权限数据存储

接入的系统越多,则资源和用户就越多。随着系统运行越久,对应的权限数据也会随之快速增长。如何在数据增长的同时保证接口的性能和高可用。

权限备份与恢复

参照HBase的版本号和MySQL的Binlog的设计思路,赋权时权限只存储当前用户最新权限数据,历史权限数据和操作记录用版本号的方式存储到Elasticsearch中。用户鉴权时只需要查询MySQL的权限数据即可,保证鉴权接口的高效性。

图14 权限备份与恢复

如图14所示:

权限过期清理

数据读写分离、缓存、备份以及服务熔断降级

各个服务使用MySQL分库存储,使用Zebra(美团数据库访问层中间件)进行读写分离;合理使用数据缓存与备份,并支持服务的熔断降级,以保证服务的高可用。

图15 数据读写分离、缓存、备份以及服务熔断降级

如图15所示:

合理使用消息队列、任务调度、线程池、分布式锁

使用消息队列、任务调度、线程池进行异步、削峰、解耦合,减少服务响应时间,提升用户体验。并使用分布式锁保证数据一致性。

图16 提高服务响应速度

如图16所示:

展望

作为一个通用的数据安全平台,各个业务线的各种定制需求不可能都满足。目前在系统架构上已支持提供多个可插拔的Plugin服务,在通用服务的基础上实现定制的权限管控。后续将军令将针对权限、审批、审计提供Plugin开发规范,支持接入的系统在现有的基础上进行定制开发。

图17 总体架构与展望

如图17所示:

作者简介

招聘信息

最后插播一个招聘广告,有对数据产品工具开发感兴趣的可以发邮件给 fuyishan#meituan.com

我们是一群擅长大数据领域数据工具,数据治理,智能数据应用架构设计及产品研发的工程师。

欢迎加入美团大数据技术交流群,跟作者零距离交流。进群方式:请加美美同学微信(微信号:MTDPtech02),回复:数据安全,美美会自动拉你进群。

在这里插入图片描述

标签:服务,角色,将军令,实践,用户,数据安全,权限,数据,资源
来源: https://blog.51cto.com/u_15197658/2769415