加码数据安全,微盟数据安全落地方案

时间:2022-08-19 01:19:14

随着数字化技术的大量应用和普及,作为核心资产的数据,其价值不断提升,数据安全已成为数字经济时代最紧迫和最基础的安全问题。数据安全是一种主动的数据防护手段,微盟主要从两大方面进行实操:一是数据处理的安全,二是数据存储的安全。

加码数据安全,微盟数据安全落地方案

▲微盟集团数据库负责人余成真

嘉宾介绍: 微盟数据库高级技术专家,有多年的数据库产品管理和技术规划经验,目前负责微盟数据库团队管理及建设、数据库相关的业务保障、数据库技术决策;专业技能上:专注于数据库的高性能和高可用技术保障,负责数据库架构设计、数据库运维平台的自动化建设、数据库运维体系规范建设。在微盟工作经历中主导海量实例跨IDC迁移、自建集群到云数据库迁移等迁移工作;组建并带领团队完成数据库产品从0到1,从1到N的跨越;深度参与同城双活/异地多活数据库整体架构及数据同步方案的设计及实施。具备危机处理能力、具备多人组织动员能力、具有很强的判断与决策、计划和执行能力。

分享提纲:

1、数据库账号权限治理

2、数据分类分级、数据加密及脱敏

3、数据库平台:平台账号权限、数据查询、数据执行审计

4、数据库安全运维

加码数据安全,微盟数据安全落地方案

据不完全统计,2017年6月~2021年7月,关于信息安全相关法律法规,共计有14次法规的发布及修正,足以可见国家对数据安全的重视程度。上图是监管矩阵图,监管最强的机构如网信办、工信部等。数据库相关审查的主要点是信息安全和存储安全的保护合规。

关于个人信息保护合规的解读,我理解为三个方面:信息收集规则、信息使用规则,信息存储规则。在数据存储方面,主要是账号安全,数据的分类分级,数据访问安全和数据库及服务器等方面的一些安全工作。

一、数据库账号权限治理

首先,对账号进行了归类。按角色分为研发账号,运维(DBA)账号。按使用方分为业务、数据中心、运维平台、DBA运维。在业务方,建立实例与应用关系,账号无DDL权限。

在数据中心方,遵循小权限账号的使用场景,具备只读权限、Binlog复制权限,对业务方实例无DDL权限。在运维平台方和DBA运维方,我们定义了不同的权限场景。按权限去划分账号,可以分为只读账号、读写账号、复制账号、管理账号以及临时账号。

加码数据安全,微盟数据安全落地方案

只读、读写、复制这三种权限类型主要被业务代码所使用,这类账号其实是最简单的一些权限划分,它相对来讲安全最好把控。管理账号这一类型稍微复杂一点,也是我们需要关注的账号类型,分为平台级和DBA运维级。

简单来讲,平台账号是高于DBA运维账号的权限,因为大部分运维管理的工作都被我们的平台或者工具所取代,由这些工具或平台来完成一些功能需求。我们希望,工具能做到极致的代码质量,代码零bug。

最后,我们也抽象出了一种带有有效期的临时账号类型,这类账号具备只读权限,并且只能用在临时的脚本代码中,它的服务下线不对线上业务有任何影响,仅仅作为修数据或者临时使用,具有有效期。

怎么去做安全使用的管理?微盟账密安全使用管理从1.0到3.0,共经历了明文配置,一代加密(AES)、二代免密(账密替换)三个阶段。1.0明文配置阶段是下发明文账密,研发自主配置。

2.0一代加密(AES)阶段是根据实例与应用关系,生成AES私钥文件,并保存至特定目录。应用通过Apollo配置数据库连接信息(密文密码)。启动应用时,通过私钥文件解密,应用启动成功。

3.0二代免密(账密替换)阶段是根据实例与应用关系、业务数据库与应用关系,生成应用维度的数据库账号。账号注册至woauth账号中心,woauth对外暴露账密。Apollo配置业务数据库占位符,应用启动时上报信息至woauth服务,鉴权并推送账密,由应用端agent替换占位符,应用启动成功。

在使用过程中,微盟也加入了常态化的治理运维工作项。比如,账号治理,主要梳理是否乱用,无用账号的梳理和清理,高危账号权限巡检,账号使用风险评估等工作。

账号过期和密码更换是账号安全的重要保护手段。我们在实际工作中落地了一整套解决方案,将账号过期和密码更换的动作工具化、流程化,从而保障账号在更换过程中业务的无损,将这种风险降到最低。

加码数据安全,微盟数据安全落地方案

上图是从创建到下架,整个账号生命周期管理的平台化功能性支撑。从账号创建开始,有审计记录到账号使用过程中的鉴权,权限变更的历史记录。到最后,账号下架的整个流程,整个历史记录都在平台化里有审计日志。

二、数据分类分级、数据加密及脱敏

关于分类分级,工信部的166号文件里有明确的管理办法。我们在此基础上,定义了微盟4级标准:仅在数据归属部门内使用的信息,不允许开放共享的数据;法律法规等要求不允许泄露的信息;数据未经授权披露、丢失、滥用、篡改或销毁后对国家安全、企业利益或公民权益会造成严重危害。

在分类上,主要是对个人信息做安全规范的定义,比如手机、身份证、地址、银行卡等。在数据分类的具体实现上,主要是通过正则表达式对数据库的表结构,数据库里面的数据去做定期的扫描,通过正则匹配来为这些表及字段打上分级的标签,完成数据的分级工作。

加码数据安全,微盟数据安全落地方案

最终,我们会输出数据分级的监管报表。通过报表可以很清楚的发现我们有多少种四级账号。

数据加密与脱敏比较容易实现,加密需要业务方根据产品及监管的要求,在前后端做一些敏感信息的字符串替换来完成脱敏,其实是需要分业务场景和按监管的需求来进行的一类操作。

我们的基础架构团队输出SDK或者API的工具给业务方使用。这些工具主要基于RSA的非对称加密算法,可以细化到商户维度的数据进行加密。

在数据加密的前期,我们历史存量的数据与实时数据是共存的,加密数据临时放在中间态字段中。当存量的数据全部完成加密以后,将双写改为单写,将中间态数据字段变更为正式字段,非加密的原始数据字段是可以根据需求来选择删除。

加码数据安全,微盟数据安全落地方案

上图是我们加解密的架构模型。业务方需要先从组件中心申请业务K的只读权限,然后代码引入SDK,根据每一个应用的名称从内部的鉴权服务获取公钥,再通过公钥加上申请的业务K,请求微盟秘钥管理系统(WKMS)。

请求相关的接口来获取数据加密的密钥,也叫做DEK,最后获取的DEK来完成数据的加解密。我们使用腾讯云的物理加密机来保护跟秘钥的绝对安全。关于微盟秘钥管理系统(WKMS),我们做了很多的功能扩展,比如高可用的存储、备份、缓存、审计等相关的功能,支持加密字段的模糊搜索。

三、数据库平台:平台账号权限、数据查询、数据执行审计

数据库平台安全管控的目标是最小权限分配原则。拆解下来,主要是授权范围、隔离策略、信息互通、可审计。资源只给对应的租户(业务团队)使用;租户(业务团队)间信息相互隔离;业务团队(租户)内所有信息共享,包括工单、资源监控、告警/慢日志推送等。数据库DML审计日志和平台操作审计日志。

加码数据安全,微盟数据安全落地方案

数据库平台权限体系分为租户(业务组)和用户操作权限两部分,用户操作权限包括是否可备份、可重启、可Kill、可资源管理、可成员管理等。对租户(业务组)进行管控,划分为用户与租户(业务组)、租户IM(业务组)、资源与租户(业务组)等。通过这些关系权限,就可以实现对资源进行操作。

数据审计主要解析BinLog日志,引入实例的相关信息,做一些分析加工,变成结构化的数据,写入到对象存储当中。与此同时,我们引入Databend数仓实时查询功能,支持在线查询的数据库服务。

数据审计相关工作可以对高危命令做治理/审计,比如,delete、drop;也可以给业务提供操作数据的变更审计;具备数据快照的能力,很清楚的知道数据变更前后的样子;还可以做在线事务、长事务分析;数据操作地图,可以定位哪些频繁被修改的表。

关于平台权限体系的功能实现,用户细粒度的操作权限,不同的实例在每个人身上有不同的操作位权限,比如只允许备份、可以重启、不可以Kill等等。租户(业务组)对资源的管理,能够控制租户操作的资源范围。在租户(业务组)下,所有的成员操作记录共享、信息共享,实现团队内部的互相审计。

四、数据库安全运维

加码数据安全,微盟数据安全落地方案

首先,定义规范防未然。我们抽象常用的运维操作类型,尽可能地将运维操作类型拆到最小,原子力度的操作类型抽象化,比如新建实例、资源扩缩容、重启集群,重启节点、主从切换等等。其次,对每一种操作类型定义高、中、低风险等级。

同时,定义发布的窗口期,不同的风险等级在不同的发布窗口期走不同的审批流。低风险的应用允许在发布窗口,经过两道审批就可以完成运维变更的操作。从而实现规范化的运维操作,来降低人为批量操作的风险,也可以起到严控发布及变更的质量,也能够降低操作的影响面。

加码数据安全,微盟数据安全落地方案

在规范流程方面,我们整理了最常用的操作SOP、应急预案,同时会定期进行报告总结和权限收敛等工作。

加码数据安全,微盟数据安全落地方案

在团队管理方面,我们进行了运维安全风控。比如制度风控,关注员工的动态,引导员工积极向上的进行运维安全的工作。在系统风控层面,有权限风控、操作风控和应急预案等。