美团数据安全平台建设

转自美团 https://tech.meituan.com/2019/02/14/data-security-platform-construction-practice-jiangjunling.html

如果从控制力的角度来进行划分的话，权限管控可以分为功能级权限管控和数据级权限管控。早期的数据安全产品大多使用传统的权限模型，只能实现功能级权限管控，无法进行数据级权限管控。 image.png

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

权限模型

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

图2 传统权限模型

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

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

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

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

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

1. 设计资源模型时，资源与资源之间具有从属关系，并且资源允许多层级，以树形结构展示。例如报表是一个父资源，标签、组件、维度指标都是报表下的子资源，这样赋权时能清晰地展示出报表资源与下面的子资源的关系，赋权和鉴权时才能满足各种权限控制的要求。

2. 角色与角色之间具有从属关系，例如员工在华东区/销售一区/销售一组的组织架构中，华东区/销售一区/销售一组这3个角色之间分别具有父子级的从属关系，当员工在销售一组部门下，则拥有华东区、销售一区、销售一组的所有权限。当权限不冲突时则直接合并所有权限，冲突时则以“就近原则”进行覆盖。

   
   图3 新的权限模型
   

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

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

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

图4 用户中心

资源中心：资源管理

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

图5 资源中心

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

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

图6 权限中心

挑战

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

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

解决思路

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

解决方案

图7 将军令整体架构

图7 将军令整体架构

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

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

具体方案

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

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

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

图8 Plugin服务

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

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

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

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

通用权限系统架构

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

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

图9 权限系统架构

如图9所示：

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

审批系统架构

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

图10 审批系统架构

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

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

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

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

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

审计系统架构

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

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

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

保证系统高可用

微服务架构服务分离

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

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

图12 微服务架构

如图12所示：

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

权限继承

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

图13 权限继承

权限数据存储

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

权限备份与恢复

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

图14 权限备份与恢复

如图14所示：

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

权限过期清理

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

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

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

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

如图15所示：

• 各个服务使用MySQL分库存储；核心服务与非核心服务分离，服务和数据库支持按需弹性拓展。

• 角色、资源等热点数据使用Redis做缓存，并在Redis缓存不可用时自动下沉到MySQL进行查询。

• 操作记录和历史数据等不活跃数据落地到Elasticsearch，以便审计和数据恢复。

• 服务不可用时支持熔断降级，以保证核心服务的可用性。

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

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

图16 提高服务响应速度

如图16所示：

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

展望

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

图17 总体架构与展望

如图17所示：

• 后续将对外提供统一的Plugin开发规范，支持各个接入方系统以Plugin服务的形式在平台基础服务之上进行定制开发，以满足各自的特殊权限管控要求。从而实现数据产品权限集中管控确保数据安全。
• 把将军令中的规则从现有的服务中分离出来，抽象出一个通用的规则引擎服务，实现规则灵活可配置。

作者简介

• 夷山，美团点评技术专家，现任TechClub-Java俱乐部主席，2006年毕业于武汉大学，先后就职于IBM、用友、风行以及阿里。2014年加入美团，长期致力于BI工具、数据安全与数据质量工作等方向。
• 中华，美团点评数据系统研发工程师，2017年加入美团点评数据中心，长期从事于BI工具、数据安全相关工作。