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

最新推荐文章于 2024-03-05 13:11:25 发布

cizhuo2650

最新推荐文章于 2024-03-05 13:11:25 发布

阅读量172

点赞数

文章标签：系统架构数据库运维

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

背景

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

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

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

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

权限模型

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

如图2所示，传统的权限模型：

ACL访问控制列表，用户与权限直接关联，直接维护用户与列表中资源的关系从而达到权限管控的目的。
RBAC模型则是角色与权限进行关联，用户成为相应的角色而获得对应的权限。

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

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

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

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

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

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

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

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

角色分为个人、组织、自定义3种，一个用户可以同时拥有多个角色，比如用户默认对应一个个人角色，又可同时拥有在公司组织架构中组织角色、在自定义组织的自定义角色。
角色支持多层级，满足角色间权限继承的表达方式。
用户、部门信息Mafka（美团基于Kafka开发的一个分布式消息中间件综合解决方案）实时更新，每天ETL定时同步，保证人员入职、转岗、调离权限实时同步。

资源中心：资源管理

资源类型支持自定义，在通用资源类型的基础上支持自定义的资源接入，满足各个系统不同资源的统一管控。
资源支持多层级，树形结构的资源展示方式便于资源的统一赋权鉴权；给一个报表资源赋权时，挂在报表下的维度、指标等资源能统一获得权限。
支持资源打包简化赋权流程。
资源安全密级、资源负责人，支持按照资源配置不同的审批模板进行权限自助申请。

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

范围策略：例如报表中的平台维度的维值包括美团和大众点评，赋权时，支持按要求给用户赋予部分或全部权限；鉴权时，按照规则解析为某人拥有某维度的部分或全部权限。
表达式策略：当把报表给用户赋权时，设置表达式为limit 10，表示当前用户在该报表其他权限的基础上再进行限制，只能返回前10条记录。
权限自动合并：一个用户拥有多个角色，多角色的同一资源的权限鉴权时按照规则自动合并；规则解析时，权限数据不冲突时取合集，冲突时按照优先级取对应的值。
黑白名单：支持按照特定的规则，对某人针对某资源全面开发和封禁，黑白名单策略的优先级最高，其中黑名单高于白名单。

挑战

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

随着支持的业务线增加，通用平台的不能满足各个业务线的定制需求时，需要保证系统的灵活可扩展。
提供一个通用的数据安全平台，满足大部分的数据安全的要求，保证系统的通用性。
权限系统作为一个高QPS访问的系统，如何保证系统的高可用。

解决思路

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

解决方案

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

提供各种灵活可插拔的Plugin服务，支持在通用服务的基础基础上进行定制开发。
提供基础服务，满足各种通用的数据安全要求。
提供管理工作台，支持管理员对各种数据和规则进行页面管理和配置。

具体方案

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

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

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

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

通用服务提供用户、资源、鉴权授权等通用服务，大部分的系统基于通用服务即可实现权限管控要求。
Plugin服务基于通用服务对外提供的SDK进行拓展，各个Plugin服务单独部署，保证系统之间互相独立。

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

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

通用权限系统架构

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

用户服务：主要包含用户和部门信息同步、角色管理。
资源服务：包含资源注册、资源定时同步、资源密级及管理员管理、资源包管理。
赋权服务：权限自助申请、管理员赋权。
鉴权服务：提供各种鉴权的SDK供使用方调用。

如图9所示：

接入层：对外所有系统通过统一的SDK调用服务。
服务层：微服务架构，各个服务之间互相之间提供服务。
数据库层：合理利用缓存、数据降级，保证服务高可用。
集成公司公共服务，保证系统稳健运行。

审批系统架构

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

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

前期开发一个审批功能需要6个步骤，绘制流程图，配置审批的组和成员，配置通知的消息，配置事件映射，启动审批流，开发回调接口改状态。
而我们在平台的审批服务基础上进行封装，提供通用的审批模板，接入审批系统只需要选择模板启动审批流，并提供回调接口即可。能满足大部分的审批功能。

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

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

对接权限系统，提供管理员权限管控。
对接审计系统，操作数据落到审计系统便于后续的数据审计。

审计系统架构

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

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

每个应用对应一个appkey，每个appkey按照模板分日期自动创建一个索引，支持自动扩展。
每种类型的审计日志对应Elasticsearch索引中的一个type，新增一种操作日志时，type自动创建。
审计日志中的字段对应type中的字段，新增字段时自动扩展。

保证系统高可用

微服务架构服务分离

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

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

如图12所示：

前端接入层通过HTTP接入，BA认证校验请求合法性，通过Nginx负载均衡。
管理控制台，通过调用服务层的各个服务实现统一管理。
服务层，抽象系统各个模块，每个模块都是一个微服务，每一个微服务都独立部署，可以根据每个服务的规模按需部署。
Client层，对外提供统一的Pigeon（美团内部分布式服务RPC通信框架）接口，通过POM引入调用服务层各个服务。

权限继承

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

权限数据存储

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

权限备份与恢复

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

如图14所示：

赋权操作时，通过版本号管理权限数据，每次操作后版本号加1，MySQL和Redis中只存储最新的权限数据。
历史权限数据通过版本号的方式存储到Elasticsearch中，每次查看历史操作记录或恢复权限数据时，根据版本号回溯即可。

权限过期清理

通过Crane定时调度，根据配置的通知规则，扫描即将过期的权限数据，发送消息通知用户进行权限续期。
扫描已过期的权限数据，清理MySQL和Redis中的过期权限数据，并转储到Elasticsearch中保存，已备后续的权限审计。

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

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

如图15所示：

各个服务使用MySQL分库存储；核心服务与非核心服务分离，服务和数据库支持按需弹性拓展。
角色、资源等热点数据使用Redis做缓存，并在Redis缓存不可用时自动下沉到MySQL进行查询。
操作记录和历史数据等不活跃数据落地到Elasticsearch，以便审计和数据恢复。
服务不可用时支持熔断降级，以保证核心服务的可用性。

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

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

如图16所示：

使用消息队列处理用户请求，实时返回操作成功，后台根据接受到的MQ消息异步进行处理并修改状态，页面轮询状态展示最终结果或发送大象（美团内部通讯工具）消息进行最终结果推送。
需要定时同步的任务通过Crane分布式任务调度平台进行定时调度执行。
审批回调时使用线程池处理审批结果回调与失败重试，较少创建销毁线程的开销。
分布式锁，保证同一个方法在同一操作上只能被一台机器上的一个线程执行，避免用户重复提交或者多机器重复处理导致的数据不一致。

展望

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