renou2012
作者renou20122017-08-18 16:05
数据库管理员, KE

MySQL安全策略

字数 2429阅读 2421评论 1赞 9

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

系统层

禁用不必要的系统服务,只开必须的进程
禁止使用root账号远程登录
禁止使用root账号启动mysqld等普通业务服务进程
设置GRUB密码
设置专用账号,针对每个用户访问,不使用公用账号
设置系统层的操作审计,记录所有ssh日志
设置操作系统的防火墙,允许部分IP地址的访问
设置操作系统的端口,允许部分端口的访问
设置默认的数据库端口或者SSH端口
设置MySQL及其他数据库服务相关目录权限
设置操作系统历史记录的清除
禁止外网访问,如果实在有需求,可以临时开启,使用完毕需要及时关闭
条件允许可以使用ssh key认证,不允许远程密码登入
条件允许可以使用PAM认证做到账号的统一管理,也更方便、安全
条件允许可以部署堡垒机,所有连接远程服务器都需要先通过堡垒机,堡垒机上就可以实现所有操作记录以及审计功能了。

网络层

设置操作系统的防火墙,允许部分IP地址的访问
设置操作系统的端口,允许部分端口的访问
服务器区域的网络隔绝,限制办公网络连接,需要连接通过跳板机访问,并做好记录
禁止外网访问,如果实在有需求,可以临时开启,使用完毕需要及时关闭

应用层

使用安全模块或者代码,防止注入或者泄漏
使用代码审计工具定期审核和安全扫描等
使用中间件,避免应用直接查库
对于账号信息避免明文存储,使用专用加密算法加密
对敏感数据进行加密或者规则脱敏
不管是用哪种程序语言写连接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? 其实也并不全是,从安全的角度而言,高可用的架构核心是数据冗余,其次才是业务的连续性,目前常用的架构也基本上遵从这个原理
不过有个问题就是大家想过没有,说个偏门的问题,即使你的环境是高可用,如果误删除了你该如何?高可用架构的多份数据也并没有什么用,你需要一个延迟的环境,至于延迟的时间,延迟的策略取决于你,可能说这个冗余环境很久都不会被使用,但是,这个就跟备份的道理是一样的,万一呢?完善的架构才能更好的维护业务的高可用。

关于制度

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

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

9

添加新评论1 条评论

wuwenpinwuwenpin软件开发工程师, 南京
2017-08-23 15:23
比较全面,不错
Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广