【将军令白酒多少钱】将军指挥：构建数据安全平台的实践

在大数据时代，数据已经成为公司的核心竞争力。此前，戴尔介绍了美团葡萄酒旅的原始数据治理平台建设和实践，该旅通过多种数据分析挖掘手段，为公司发展决策和业务开展提供数据支持。

背景

最近行业内数据安全事件频繁发生，给相关企业造成了不可挽回的损失，给数据安全意识薄弱的企业敲响了警钟。如何对公司内数据进行最集中的数据分析、数据服务、数据治理等多种数据产品进行权限控制，成为数据安全建设中最重要的课题。

从控制力的角度来划分的话，权限控制可以分为功能级别权限控制和数据级别权限控制。传统的数据安全产品大多使用传统的权限模式，只能进行功能级别的权限控制，不能进行数据级别的权限控制。基于数据类产品的高安全要求，必须建立同时满足多种产品数据安全的平台。

为此，美团用户平台应用研发ampD团队不仅设计了表达和控制各种复杂关系的权限模型，还分别设计了前、日、后三种方案：批准、权限、审计，为数据安全设计了完整的闭环。这可以满足各种数据安全要求。

图1权限背景

功能应用类产品的权限表达通常是“授权的”，数据类产品权限表达的关系更加复杂。例如，数据类产品的报表不仅需要指示用户是否可以访问此报表，还需要指示用户可以访问报表的维、指标和维值的范围。此外，还必须通知这些维指示器派生自的库表模型、您是否具有访问权限以及报表生成。

权限模型

传统的权限模型包括访问控制列表(ACL)访问控制列表、基于角色的访问控制(RBAC)。上述模型更适合应用类型产品的权限控制，数据类型产品对信息安全要求更高，各种资源之间的关系也更复杂，使用现有模型很难清楚地表达内部关系，因此基于RBAC权限模型扩展了新的权限模型。

图2现有权限模型

如图2所示，现有的权限模型如下：

ACL访问控制列表，用户直接与权限相关联，直接维护用户与列表中资源的关系，从而实现权限控制。RBAC模型是将角色和权限相关联的角色，用户成为该角色并获得相应的权限。为什么要设计新的权限模型？

ACL模型是用户和资源之间的直接关系，没有角色概念。如果某些用户需要对同一资源的权限，则授权操作会变得复杂，此模型不合适。RBAC模式引入角色概念、角色和资源关系。如果某些用户需要对同一资源组的权限，则只需配置角色并授予使用该资源的权限。用户加入此角色后，将拥有该角色的所有权限。解决了授权工作的复杂问题。但是，ACL模型和RBAC模型都存在以下问题：

数据类产品资源之间的关系很复杂，不能很好地表达这种复杂的关系。例如，报表下有多个选项卡页，选项卡页下有多个组件，组件下有多个维、指示符等。同时，维度、指标来自另一个数据模型、库表等。资源和资源之间有关系。如果管理员授予用户对报告的全部或部分权限，则报告下的子资源也必须同时获得相应的权限。RBAC模型的角色和角色之间没有对应关系。例如，在组织结构中，员工所在的组织结构是华东/销售地区/销售组，员工拥有的角色是销售组的角色。角色之间没有关系时，员工需要对华东区角色的权限时，必须添加到华东区角色中。如果角色和角色之间存在从属关系，则可以很好地解决此问题。新的权限模型如何解决这些问题：

设计资源模型时，资源与资源之间存在相关性，资源可以接受多个级别，并以树结构显示。例如，报表是父资源，标签、组件、维指标都是报表下的子资源。这样，在授权时可以清楚地显示报告资源和下面的子资源之间的关系，在授权和认证时可以满足各种权限控制要求。角色和角色之间存在相关性。例如，如果员工在华东/销售区/销售组的组织结构中，华东/销售区/销售组之间各有父子从属关系，员工在销售组之下，则拥有华东地区、销售区、销售组的所有权限。如果权限不冲突，则直接合并所有权限；如果发生冲突，则用“接近原则”复盖。

/ol>

图3 新的权限模型

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

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

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

图4 用户中心

资源中心：资源管理

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

图5 资源中心

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

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

图6 权限中心

挑战

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

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

解决思路

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

解决方案

图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工具、数据安全相关工作。

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

微信扫码关注美团技术团队，阅读更多技术干货。