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

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

嘉宾介绍：微盟数据库高级技术专家，有多年的数据库产品管理和技术规划经验，目前负责微盟数据库团队管理及建设、数据库相关的业务保障、数据库技术决策;专业技能上：专注于数据库的高性能和高可用技术保障，负责数据库架构设计、数据库运维平台的自动化建设、数据库运维体系规范建设。在微盟工作经历中主导海量实例跨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、应急预案，同时会定期进行报告总结和权限收敛等工作。

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