保障数据安全，如何设计数据库(Mysql)的安全管控体系（一）
前言：重视数据安全
很多时候我们都会觉得安全会阻碍效率，初创型公司讲究的是短平快活下去比什么都重要，所以刚开始的时候并不愿意在安全上面去追加投入，可当公司在有条件或者差点条件时也应该创造条件把安全的短板给补上。
简单举几个例子：
1、因为信息泄露，你的用户遭遇了电信诈骗。警察上门取证，要求下架整顿。这时候你怎么办？
2、因为安全攻击，你的客户信息数据库被黑客删除或者加密勒索了。或者是客户因为用了你的产品导致，自己的数据文件被黑了，向你索要赔偿。这时候你怎么办？
。。。
两个简单的小例子带来的打击是毁灭性的，那么对于数据安全的管控，我们到底应该怎么做呢。下面我将会用我的实际工作经验同你分享常用的企业数据安全管控体系。
数据库(mysql)的常见搭建架构
1、mysql可以支持更多的只读实例，但是不建议。当五个只读实例都还撑不住你的业务，说明你的业务代码存在严重的性能问题，你更加应该检查你的业务设计和代码以及数据库存在的慢查询并且引入缓存中间件。
2、最多配置5个只读实例，还需要考虑到主从同步的延时的问题，太多的只读实例会影响数据库同步的性能与数据插入的实时性。
3、企业级的主从同步，你应该通过GTID的方式来实现主从同步，而不是常规的mysql-binlog中的pos偏移量。
4、灾备和数据库日常实时备份的主要特性是异地备份。单单基于这个特性，如果你的数据库部署在云上，出于成本考虑其实可以舍弃这个成本。但是灾备还有一个特点是：可以用来代替主数据库做手工数据查询，这样可以避免手动查询在主数据库产生慢查询的情况，如果你的数据已经在千万级了，那么你应该使用上灾备，来冗余手工查询的慢查询情况。
账号管理
对于数据库的账户管理，一般你需要对数据库的使用人群进行划分，按照我们的内部的划分是分为了：研发，运维和其它。不通的使用人群，建议分配不同的账户用于权限管控和访问白名单划分。
| 数据库账户 | 面向人员 | 业务场景 | 权限分配 |
| root | 数据库最高管理者 | 超级账号，默认全部权限 | |
| bizOnly | 研发 | 业务系统,研发排查故障等 | 1、增改查权限 2、事务、视图等级别的小部分权限 |
| opsOnly | 运维 | 取数，数据维护，定时器等 | 1、数据表的增删改查 2、表与库对象的常规操作权限，不包含删库删表等权限 3、不包含新建账户，修改账户(主机访问范围，修改其它账号)等权限 |
| readOnly | 外部数据看板系统对接等 | 只读,以及binlog日志读取 |
1、当系统架构是微服务的场景下你还可以将bizOnly继续拆分，例如面向数据导出的模块可以分配一个dataOnly账户，面向财务模块同样也可以在分配一个账户。针对使用场景分配账户除了便于权限管理，当数据库压力过大时，也可以直接通过账户的方式来定位问题产生来源。
2、分配给研发人员的bizOnly账户不建议分配删除数据的权限，但是在实际的业务场景中可能会存在订单取消，或者是订单处于待付款转为付款完成后需要将订单信息从待付款队列表中删除情况。建议你对数据做逻辑删除，当然这会导致该队列表数据越来越多影响性能。那么你可以在运维侧通过运维账号创建定时器等方式定期的将数据库中标记为逻辑删除的数据由源表插入到对应的备份表，再将源表中已经备份的数据删除。
3、禁止常规运维人员接触到数据库的root账户，root账户有管理人员保留，仅进行账户授权与创建等操作。
敏感数据管理
没有绝对安全，你需要考虑当你的数据库被拖库的情况下，怎么样的操作影响是最低的，那么敏感数据加密是必须要推进的工作。
你可以直接使用数据库自带的加密功能通过加盐值的方式进行敏感数据加密。如下展示了基础的代码。
#数据库加盐值方式的数据加密代码示例
HEX(AES_ENCRYPT('源数据','盐值')
那么那些数据属于敏感数据呢？定义什么是敏感数据你可以根据这个原则去分析：当别人获取到这些数据的时候能不能对目标人员进行骚扰，诈骗与分析。下面列举一些数据字段。
1、不要轻易泄露你的加密盐值，即使是在代码中这个盐值都应该是加密保存。
2、数据加密后，在日常的取数等操作中确实会影响效率，建议系统提供一个解密的功能页面。但是该页面需要权限管理，只能部分人员使用，并且使用过程中需要进行日志记录
访问控制管理
访问控制管理一般是通过白名单机制进行实现，它是数据库安全管控体系中很重要的一环。对于企业的数据库管控，如下所示：
1、对于数据库等高危中间件建议只暴露在内网网络。
2、研发和运维可以登入数据库堡垒机，但是研发账户禁止授权从数据库下载文件的权限。以及数据库的导出权限
3、禁止研发登入生产环境的应用部署主机节点。
4、禁止研发通过堡垒机登入线上数据库，但是允许研发通过堡垒机登入灾备数据库(当你的公司具有严格的安全管控的时候，可能这样的授权也是不被允许。如果你需要提供研发的灵活性与效率可以采取这种方式，其安全度也并可算达标。另一方面，只允许研发登入灾备数据库的原因也是因为灾备数据库是处于only-read模式，防止了错误操作带来的死锁、慢查询导致影响生产业务的问题)
审计管理
数据库审计的主要目的是用于事后追责以及日常的行为分析，用于发现高危授权并合理调整账户授权。按照安全标准建议对审计日志最少保存6个月即大概184天
备份管理
对于数据库的备份管理，我们建议进行每天的全备与binlog日志实时备份。数据备份时长最少3个月即90天。
数据库宕机风险预防
对于数据库宕机，可以写的有很多。例如引入缓存中间件，数据限流，队列等等。但是本文只争对数据库本身进行展开。
对于数据库而言从架构层面解决宕机风险，我们可以采用的有主备高可用，数据库读写分离，基于数据表库的分表分库操作。基于长期的一线业务实战经验，这里给个几个小建议：
2、解决数据库的慢查询以及可能存在的死锁问题才是数据库优化宕机风险的第一步，也是最基础的一步而且这个第一步会贯穿你的整个数据维护周期。然后再考虑单个数据库的内存与cpu扩容，后续才开始讨论架构设计的问题。
3、对于数据库的优化感兴趣你可以查看本站博文：Mysql优化在工作中的经验总结、华为云RDS全量慢日志的数据清洗与时间截取思路等相关博文。
本文系作者 @Mr.Lee 原创发布在 维简网。未经许可，禁止转载。
