中小金融机构 MySQL 数据库安全设计及防范，八个“如何”该怎么做？

如今，数据保护重心已从单纯针对系统与网络基础层面防护，向关注应用和核心业务数据层面的防护转换。尽管如此，仍有一些企业数据安全方面的问题没有得到足够的重视。社区组织活动交流中小金融机构的MySQL安全架构，现由社区专家renou2012总结交流知识点如下，供大家参考。

renou2012：数据库技术爱好者，从事MySQL相关的运维和架构工作

本文内容还有岳彩波、冯帅等社区会员的分享贡献

1 如何做到数据库的安全加固？

2 如何做到数据库的安全防护？

3 如何做到数据库的安全管控？

4 如何做到数据库账号权限的精细化管理？

5 如何做到安全问题监控？

6 如何做到高风险操作和影响安全的发现？

7 如何做到数据防泄漏？

8 如何做到数据库或者服务器的定期巡检？

如何做到数据库的安全加固？

一般是初始设定，后期安全检查加固

系统层面

- 防火墙的策略的设定

- 端口的设置

- 账号权限

- 系统级别登录操作记录

数据库层面

- 账号的权限

- 访问连接ip地址的限制

- 禁止root远程连接

- 禁止使用常用账号特别是root,admin,dba等类似缺省名

- 空密码账号的清理

- 匿名账号的清理

- 权限的检查

- 操作监控部署

- 操作行为审计等

网络层面

- 主要值区域隔离，访问限制

- 使用堡垒机，所有访问经过堡垒机

同时配合定期检查，进行安全加固

如何做到数据库的安全防护？

网络控制

- 数据库服务器区域，应用服务器区域，其他设备区域的隔离，同时还包括办公网络的隔离

- 数据库防火墙的使用，所有操作必须走相应的设备，禁止直连操作

- 网络防火墙禁止对主机，数据库的ping操作

- 网络防火墙禁止服务器区域的端口扫描

- 网络防火墙的准入策略

- 其他安全设备的监控，报警，入侵防御等

数据库帐号密码控制

- 禁止使用默认的账号命名，比如说admin、dba、app等名称

- 对于应用做到专用账号，不混用，即使是读写分离的账号也需要做好账号专用

- 密码的复杂度，建议讲密码策略调至

- 密码的定期+不定期修改，密码过期策略

- 密码的保存策略

数据库连接控制

- 数据库本身的多重验证比如SSL验证

- 限定ip地址的访问

- 限定设备的访问

- 限定时间的访问

- 限制端口访问，根据自己的规则修改默认的端口

数据库权限控制

- 加强数据库账户的权限审核和记录

- 定期不定期检查数据库账号的权限复核检查

- 及时回收不需要的数据库权限

- 禁止级联权限的存在

- 同时加强对于权限人员的管控，防止泄漏

- 数据库日志的记录

- 这部分还包括所有其他日志，做到日志的定期归档，分析

数据库审计控制

- 针对所有账号进行的所有操作都必须进行审计和监控，一个收集操作记录，同时也可以审查高危或者可疑操作

- 针对敏感数据

- 做好敏感数据的脱敏操作，还有就是敏感数据的操作记录，特别是大批量的数据导出

还有其他安全设备的使用

如何做到数据库的安全管控？

数据库的安全管控，要从严格的规章制度，和操作规范来做起，生产环境和准生产，UAT，开发测试环境的制度要分离。在生产环境做任何改动，都要做到根据规章制度申请，DBA的严格审核，实际执行操作至少要两人以上，互相监督执行，具体的规范也要根据实际情况制定。还有一点就是数据库区必须做到不能直连外网，都要通过转发代理。

这个如果根据研发的阶段来划分主要分为开发阶段，测试阶段，准生产阶段，压测阶段，上线阶段。

开发阶段-开发环境

数据库和系统的版本可能都比较新，这里面有一部分是尝鲜的概念在里面，同时，也为了以后的版本更新提供了一定的基础，其次是研发人员对于数据库和操作系统的权限是比较大的，基本上会all in，主要保证开发的进度

测试阶段-测试环境

这个环境的版本可能也是比较新的，不过已经很贴近生产了，然后是对于权限的话，由于主要是测试阶段，研发人员和测试人员的权限基本上限定到库表的DML权限，很难执行其他特别是DDL操作了，当然还是以保证开发和测试为主

准生产阶段-准生产环境

原则上这个环境跟生产环境基本上1：1，版本跟生产是一样的，其次配置比生产会低很多，权限的话，已经不允许DDL语句了，并且DML也会严格控制

压测阶段--压测环境

一般化而言，很多公司会把准这个压测环境放到准生产上面，对此，我不反对不建议，完全看你的想法和公司的规划，压测环境跟生产环境保证100%完全一致性，因为为了追求那个极致，同时全面禁止的DDL，只读环境

ps：很多时候，你的准生产可能就是压测环境，这边就不做过多说明了，主要还是看你的规划

上线阶段--线上环境

这个就不说了，完全禁止的DML、DDL操作，任何操作必须有记录，比如审计，工单等等

如何做到数据库账号权限的精细化管理？

一定是做到了对权限的全方位掌控

根据账户的不同类型，以前缀区分。简单的分类，分为业务账户和实名账户。细分来讲，业务账号分为网站应用、手机应用、报表应用、服务应用、查询服务，实名账户可以跟踪到具体的员工。

网站应用(web_业务简称)

手机应用(mob_业务简称)

报表应用(rep_业务简称)

服务应用(dae_业务简称)

查询服务(sea_业务简称)

实名查询(dev_姓名拼音)

业务账号权限最大到 SELECT、UPDATE、DELETE 和 INSERT，查询服务和实名查询账户只能有查询权限。每个用户只有一个密码，授权时需要知悉此用户是否存在，如果存在，使用旧密码授权，如果不存在，生成随机密码进行授权。

实名权限只能通过堡垒机或者跳板机进行查询，堡垒机有用户登录和执行 SQL 日志。

线上 IDC 数据库只允许线上 Web 机连接，不允许测试机连接。

员工申请权限需要工单申请，授权只能 DBA 操作。DBA 需要做好权限控制，相关业务负责人可以申请较高权限，但需要邮件抄送上一级领导进行审批。

DBA 有一套完整的元数据库，里面记录了所有的用户相关信息，此数据库重要级别最高，做好安全控制。

用户的密码需要足够复杂，而且有一套完整的随机密码生成规则。

业务方通知业务账户存在异常，需要制定快速更改账户的流程。

员工申请的临时高权账号，需要有备案，需要设置密码过期时间，而且需要制定回收流程。

MySQL root 密码只有 DBA 拥有，而且不允许将此密码保存在任何云笔记或者云存储上，只能保存到本地。另外，定期修改 MySQL root 密码。

通过终端进入 MySQL，不允许将密码明文显示。

用户授权操作建议在 Web 页面完成，需要做好安全控制。此项也就是 DB 运维管理平台，需要编码实现。

做好数据备份，可以在误操作最快恢复数据。

如有可能，在新业务上线 MySQL 审计方案，可以通过 init-connect 参数 + access_log + binlog 实现审计。

关于精细化，主要是各个权限分配细致，做到，不重复，其次是权限的定义明确，该给什么权限给什么权限，不存在模糊权限，最后是权限的记录，做到从权限开始，审批，授权，收回，删除等一整套的规章流程，最重要的是一个精细化的思想，做到心中有数。

如何做到安全问题监控？

开审计，监控软件商业的现在有很完善的，开源的也有免费的插件，没有最成熟，只有最适合。

还想说一下，数据库的安全不止要从数据库方面考虑，还要考虑网络和系统，网络和系统如果在入侵的过程中防不住了，数据库层次的防御力也有限，在前边两个层次就要做到万无一失才对，数据库的安全只是针对数据，针对一些sql注入等等进行一些安全配置。还要做好备份，主从，异地备，高可用等，其实这些都可以算在数据库的安全里边，特别是MySQL，作为一个DBA，也许我们做不到万无一失，但我们要用一万种方法来防止出问题，能考虑到的，能做到的，我们都要用上。

需要确定你当前所想要达到的目标，其次是对业务的影响。

目前常规是通过数据库防火墙的策略规则，进行告警处理，主要的还是事后审计的报表分析。

如何做到高风险操作和影响安全的发现？

这部分主要是审计部分。

通俗的说就是你需要记录所有数据库的操作行为包括超级权限所有者。

其次是你当你有记录之后，需要对操作行为进行一个分析，当然这是一个长期的分析。

举个简单的例子，你可以通过数据库的审计或者数据库防火墙或者其他安全设备找出取有的sql语句，然后把这些数据录入到你自己的数据分析平台，具体的操作行为包括登录设备，登录设备ip地址，登录时间，退出时间，账号，库，表，语句数据量等，条件运行还可以加上一些其他因素。

首先是语句的查找比如TCL/DDL/DML/DCL。

TCL(Transaction Control Language):

事务控制语言

常用的有 SET TRANSACTION、SAVEPOINT、ROLLBACK、START TRANSACTION、COMMIT等

DML(data manipulation language):

常用的有SELECT、UPDATE、INSERT、DELETE、EXPLAIN PLAN、LOCK TABLE等

DDL(data definition language):

常用的有CREATE、ALTER、DROP、TRUNCATE 等

DCL（Data Control Language)

常用的有GRANT、REVOKE等

具体的可以参考

https://dev.mysql.com/doc/refman/5.7/en/sql-syntax.html

这些都是需要进行分析的。

制定你的规则，可以是库级别，表级别，列级别，通过不同的维度界限去分析，在这个过程中，通过出现的 频率次数，时间范围，确定相应的操作行为，至于是高风险操作还是影响安全的操作这是一个模糊的范围定义，不过高风险操作的频次，可以先邮件通知主管领导如果必要进行权限收回，影响安全的操作也大体相似，主要是需要制定你的条件规则。

如何做到数据防泄漏？

关于数据防泄漏，我们首先需要根据企业本身来进行信息分类。

客户身份数据

客户金融数据

客户隐私数据

公司重要的知识产权

公司的重要经营数据，这些构成了企业的核心机密信息，任何信息的泄密，都可能造成企业无法估计的损失。

从整个企业的IT架构层面来看，数据的安全架构涵盖网络和终端的安全。

对于公司的网络一般会划分安全域，在安全域之间的边界（如公司的内外网出口位置）实施监视和访问控制 ，做到对网络出口的数据进行抽取并分析，使数据出口可监、可管、可控。 

对于终端设备，严格地管理和约束终端的用户操作行为，做到合法用户使用终端，用户的合规操作进行规范管理。通过终端安装的应用，采用技术手段有效对客户要发送的邮件、文件内容、移动存储、文件外发扫描、全盘智能扫描、打印机监等功能；并可实现对终端监控结果的统一上报及管理。

主要还是依赖安全设备，因为说白了从数据库层面你并不知道哪些操作访问是否非法，当然审计之类的是可以发现的，不过已经是事后的操作，当然某些监控防火墙可以做到告警阻断，其实归根到底，数据库层面的防止还是比较困难的，主要还是业务层面的控制，比如说报表部分的数据脱敏，记录，还有文件的传播限制等。

如何做到数据库或者服务器的定期巡检？

如果是日常巡检的话，要做到每天都要巡检，深度巡检的话最好每月做一次，每季度进行一次问题大彻查，并且根据一些可能发生的问题做一些预防，对瓶颈进行整改优化。

其实就数据库或者服务器而言，我们有时候会感到困惑，不知道巡检哪些东西，机器太多麻烦，生成可视化报告太困难，无法直观呈现结果等

一般化我们会分成三个日常巡检，季度巡检，年度巡检。

日常巡检

状态检查

数据库状态检查，服务器状态检查

服务器

处理器、物理内存、磁盘、网卡等详细信息

数据库层面

文件大小、配置信息、空间等

季度巡检

年度巡检

日常的巡检是比较偏业务层面的，保证业务的连续性，季度和年度的巡检比较偏配置这块，一个是机器的负载，数据库的负载，为后期扩容情况的做一些依据等

根据以上一些基础信息做成你自己的小工具，同时做好记录，如果有什么需要的可以随时加进去定制化，当然也可以使用一些现成的产品或者工具加上定制化的工具，主要是需要有这样一个意识，正常的监控大家都会做，定期的巡检做的并不多，很多问题我们可以通过对定期巡检的记录对比发现一些潜在的问题。

最后，数据库安全包含两层含义（摘自百度百科）：第一层是指系统运行安全，系统运行安全通常受到的威胁如下，一些网络不法分子通过网络，局域网等途径通过入侵电脑使系统无法正常启动，或超负荷让机子运行大量算法，并关闭cpu风扇，使cpu过热烧坏等破坏性活动； 第二层是指系统信息安全，系统安全通常受到的威胁如下，黑客对数据库入侵，并盗取想要的资料。数据库系统的安全特性主要是针对数据而言的，包括数据独立性、数据安全性、数据完整性、并发控制、故障恢复等几个方面。

始终牢记，安全无小事。

点及阅读原文，有更多MySQL相关文章

长按二维码关注公众号