做图片的网站,遵义网络科技公司,织梦网站安装教程视频,做网站哪些公司好背景 在大数据时代#xff0c;数据已经成为公司的核心竞争力。此前#xff0c;我们介绍了美团酒旅起源数据治理平台的建设与实践#xff0c;主要是通过各种数据分析挖掘手段#xff0c;为公司发展决策和业务开展提供数据支持。 近期#xff0c;业内数据安全事件频发#… 背景 在大数据时代数据已经成为公司的核心竞争力。此前我们介绍了美团酒旅起源数据治理平台的建设与实践主要是通过各种数据分析挖掘手段为公司发展决策和业务开展提供数据支持。 近期业内数据安全事件频发给相关企业造成了无可挽回的损失更为数据安全防护意识薄弱的企业敲响了警钟。如何对公司内部数据最为集中的数据分析、数据服务、数据治理等各种数据类产品进行权限管控已经成为数据安全建设中最为重要的任务。 如果从控制力的角度来进行划分的话权限管控可以分为功能级权限管控和数据级权限管控。早期的数据安全产品大多使用传统的权限模型只能实现功能级权限管控无法进行数据级权限管控。基于数据类产品更高的安全要求我们需要构建一个同时满足各类产品数据安全的我们需要构建一个同时满足各类产品数据安全的平台。 为此美团用户平台应用研发组不仅设计了能表达和管控各种复杂关系的权限模型还针对事前、事中、事后等三个场景分别设计了审批、权限、审计三个子系统以保障数据安全的完整闭环进而满足数据安全的各种要求。 功能应用类产品的权限表达一般为“是否有权限”而数据类产品权限表达的关系更加复杂。例如数据类产品的报表不仅需要表达出用户能否访问这个报表而且需要表达出用户能访问报表中的哪些维度、指标以及维值的范围。还需要告知这些维度指标来自于哪些库表模型是否有权限访问以及创建报表。 权限模型 传统的权限模型有ACLAccess Control List访问控制列表RBACRole-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所示 赋权操作时通过版本号管理权限数据每次操作后版本号加1MySQL和Redis中只存储最新的权限数据。历史权限数据通过版本号的方式存储到Elasticsearch中每次查看历史操作记录或恢复权限数据时根据版本号回溯即可。权限过期清理 通过Crane定时调度根据配置的通知规则扫描即将过期的权限数据发送消息通知用户进行权限续期。扫描已过期的权限数据清理MySQL和Redis中的过期权限数据并转储到Elasticsearch中保存已备后续的权限审计。数据读写分离、缓存、备份以及服务熔断降级 各个服务使用MySQL分库存储使用Zebra美团数据库访问层中间件进行读写分离合理使用数据缓存与备份并支持服务的熔断降级以保证服务的高可用。 如图15所示 各个服务使用MySQL分库存储核心服务与非核心服务分离服务和数据库支持按需弹性拓展。角色、资源等热点数据使用Redis做缓存并在Redis缓存不可用时自动下沉到MySQL进行查询。操作记录和历史数据等不活跃数据落地到Elasticsearch以便审计和数据恢复。服务不可用时支持熔断降级以保证核心服务的可用性。合理使用消息队列、任务调度、线程池、分布式锁 使用消息队列、任务调度、线程池进行异步、削峰、解耦合减少服务响应时间提升用户体验。并使用分布式锁保证数据一致性。 如图16所示 使用消息队列处理用户请求实时返回操作成功后台根据接受到的MQ消息异步进行处理并修改状态页面轮询状态展示最终结果或发送大象美团内部通讯工具消息进行最终结果推送。需要定时同步的任务通过Crane分布式任务调度平台进行定时调度执行。审批回调时使用线程池处理审批结果回调与失败重试较少创建销毁线程的开销。分布式锁保证同一个方法在同一操作上只能被一台机器上的一个线程执行避免用户重复提交或者多机器重复处理导致的数据不一致。展望 作为一个通用的数据安全平台各个业务线的各种定制需求不可能都满足。目前在系统架构上已支持提供多个可插拔的Plugin服务在通用服务的基础上实现定制的权限管控。后续将军令将针对权限、审批、审计提供Plugin开发规范支持接入的系统在现有的基础上进行定制开发。 如图17所示 后续将对外提供统一的Plugin开发规范支持各个接入方系统以Plugin服务的形式在平台基础服务之上进行定制开发以满足各自的特殊权限管控要求。从而实现数据产品权限集中管控确保数据安全。把将军令中的规则从现有的服务中分离出来抽象出一个通用的规则引擎服务实现规则灵活可配置。作者简介 夷山美团点评技术专家现任TechClub-Java俱乐部主席2006年毕业于武汉大学先后就职于IBM、用友、风行以及阿里。2014年加入美团长期致力于BI工具、数据安全与数据质量工作等方向。中华美团点评数据系统研发工程师2017年加入美团点评数据中心长期从事于BI工具、数据安全相关工作。招聘信息 最后插播一个招聘广告有对数据产品工具开发感兴趣的可以发邮件给 fuyishan#meituan.com。 我们是一群擅长大数据领域数据工具数据治理智能数据应用架构设计及产品研发的工程师。
