MySQL安全策略

 

数据是企业的核心资产,特别是敏感数据,稍有不慎,就会造成数据泄露、非法窃取、恶意破坏等,网络上经常会出现一些社工资源,还有一些敏感数据的交易,大部分的数据都是被非法获取的,我们需要时刻做好安全防护,下面讲针对安全重点谈谈如何从系统层,网络层,应用层,管理层,数据库层来保护数据,当然这里面的部分策略是相互耦合的,不过这个从安全的角度上而言,耦合也是为了更好的保护数据,还有就是,某一策略的缺陷可能会造成木桶效应也需要大家的关注。

系统层

禁用不必要的系统服务,只开必须的进程

禁止使用root账号远程登录

禁止使用root账号启动mysqld等普通业务服务进程

设置GRUB密码

设置专用账号,针对每个用户访问,不使用公用账号

设置系统层的操作审计,记录所有ssh日志

设置操作系统的防火墙,允许部分IP地址的访问

设置操作系统的端口,允许部分端口的访问

设置默认的数据库端口或者SSH端口

设置MySQL及其他数据库服务相关目录权限

设置操作系统历史记录的清除

禁止外网访问,如果实在有需求,可以临时开启,使用完毕需要及时关闭

条件允许可以使用ssh key认证,不允许远程密码登入

条件允许可以使用PAM认证做到账号的统一管理,也更方便、安全

条件允许可以部署堡垒机,所有连接远程服务器都需要先通过堡垒机,堡垒机上就可以实现所有操作记录以及审计功能了。

网络层

设置操作系统的防火墙,允许部分IP地址的访问

设置操作系统的端口,允许部分端口的访问

服务器区域的网络隔绝,限制办公网络连接,需要连接通过跳板机访问,并做好记录

禁止外网访问,如果实在有需求,可以临时开启,使用完毕需要及时关闭

应用层

使用安全模块或者代码,防止注入或者泄漏

使用代码审计工具定期审核和安全扫描等

使用中间件,避免应用直接查库

对于账号信息避免明文存储,使用专用加密算法加密

对敏感数据进行加密或者规则脱敏

不管是用哪种程序语言写连接MySQL数据库的程序,有一条准则是永远不要相信用户提交的数据!要做到验证

数据库层

参考 MySQL 安全规范

管理层

关于备份

当你有了备份,你不仅仅需要保证备份的多副本,还要保证其安全性,这里面的安全性包括内部安全,外部安全。

很多时候外部反而是安全的,一个有效的备份经历加密、访问控制,别人无论是获取还是解密都需要花费大量的时间的,而内部往往更容易出问题,千里之堤,毁于蚁穴。

关于审计

数据库审计能够实时记录网络上的数据库活动,对数据库操作进行细粒度审计的合规性管理,对数据库遭受到的风险行为进行告警,对攻击行为进行阻断。

它通过对用户访问数据库行为的记录、分析和汇报,用来帮助用户事后生成合规报告、事故追根溯源,同时加强内外部数据库网络行为记录,提高数据安全。

审计对数据库记录和行为进行独立的审查和估计,其主要作用和目的包括以下几个方面:

对可能存在的潜在攻击者起到威慑和警示作用,核心是风险评估。

测试系统的控制情况,及时进行调整,保证与安全策略和操作规程协调一致。

对已出现的破坏事件,做出评估并提供有效的灾难恢复和追究责任的依据。

对系统控制、安全策略与规程中的变更进行评价和反馈,以便修订决策和部署。

协助系统管理员及时发现网络系统入侵或潜在的系统漏洞及隐患。

有个不知道算奇怪还是正常的事情,不知道多少人给生产恢复过数据,这里面不谈因由,只有做过的人才知道这其中的坑有多少,所以也就需要大家对于各种恢复手段都有所了解,乃至于熟练掌握。

虽然防患未然还是比较困难的,毕竟各种情况都会发生,但是,可以未雨绸缪,从安全上讲,有了审计可以大大减少这类事情的发生。

对于数据库而言,无论是硬件设备还是软件审计都会加大数据库的压力,从性能的损耗上讲,事后审计是比较折中的策略,这边先讲下软件部分的,无论是MySQL官方还是MariaDB或者Percona还是其他的都有一套自己的审计产品。

下面列下常用的几种

MariaDB Audit Plugin(https://mariadb.com/kb/en/mariadb/about-the-mariadb-audit-plugin/),
Percona(https://www.percona.com/doc/percona-server/5.6/management/audit_log_plugin.html),
MySQL(https://dev.mysql.com/doc/refman/5.7/en/audit-log.html),
mcafee(https://github.com/mcafee/mysql-audit)等等功能都差不多

主要用哪个还得看你适合哪个,如果你有足够的资源可以考虑采用硬件的模式,尽量选择专门审计设备的设备,然后根据定期的报表检查你的相关配置。

关于架构

我们一直都在追求或者说改进自己的架构而成为更好的架构,高可用(High Availabiltity)是一个常用的标准,指标的话至少3个9目标4个9或者更多个9,不过随之带来的是成本,毕竟事务的两面性决定了不可能完美,我们始终要明白高可用的核心是什么,业务的连续性7*24? 其实也并不全是,从安全的角度而言,高可用的架构核心是数据冗余,其次才是业务的连续性,目前常用的架构也基本上遵从这个原理
不过有个问题就是大家想过没有,说个偏门的问题,即使你的环境是高可用,如果误删除了你该如何?高可用架构的多份数据也并没有什么用,你需要一个延迟的环境,至于延迟的时间,延迟的策略取决于你,可能说这个冗余环境很久都不会被使用,但是,这个就跟备份的道理是一样的,万一呢?完善的架构才能更好的维护业务的高可用。

关于制度

最后说下制度,这边主要说下安全的相关制度,个人觉得主要作用还是威慑,同时也是一个对自己的保护,在企业中,往往关系错综复杂,你需要更好的保护你所接触到的数据,同时也需要保护自己,而对于数据安全而言,有相应的制度去保证,保护我们不犯错,同时也防止我们犯错。

总之,制度的作用在于使我们知道,应该做什么,不应该做什么。

 

|

社区正在进行技术交流

中小金融机构MySQL数据库安全设计及防范

点击阅读原文,参与交流分享

|

 

 

长按二维码关注公众号