数据库审计
数据库审计能够实时记录网络上的数据库活动,对数据库操作进行细粒度审计的合规性管理,对数据库遭受到的风险行为进行告警,对攻击行为进行阻断。它通过对用户访问数据库行为的记录、分析和汇报,用来帮助用户事后生成合规报告、事故追根溯源,同时加强内外部数据库网络行为记录,提高数据资产安全。
数据库是任何商业和公共安全中最具有战略性的资产,通常都保存着重要的商业伙伴和客户信息,这些信息需要被保护起来,以防止竞争者和其他非法者获取。互联网的急速发展使得企业数据库信息的价值及可访问性得到了提升,同时,也致使数据库信息资产面临严峻的安全挑战,概括起来主要表现在以下三个层面:
1.管理风险:主要表现为人员的职责、流程有待完善,内部员工的日常操作有待规范,第三方维护人员的操作监控失效等等,离职员工的后门,致使安全事件发生时,无法追溯并定位真实的操作者。
2.技术风险:oracle, sql server是一个庞大而复杂的系统,安全漏洞如溢出, 注入层出不穷,每一次的cpu(critical patch update)都疲于奔命, 而企业和政府处于稳定性考虑,往往对补丁的跟进非常延后,更何况通过应用层的注入攻击使得数据库处于一个无辜受害的状态。
3. 审计层面:现有的依赖于数据库日志文件的审计方法,存在诸多的弊端,比如:数据库审计功能的开启会影响数据库本身的性能、数据库日志文件本身存在被篡改的风险,难于体现审计信息的有效性和公正性。此外,对于海量数据的挖掘和迅速定位也是任何审计系统必须面对和解决的一个核心问题之一。
伴随着数据库信息价值以及可访问性提升,使得数据库面对来自内部和外部的安全风险大大增加,如违规越权操作、恶意入侵导致机密信息窃取泄漏,但事后却无法有效追溯和审计。
审计项目
通过应用层访问和数据库操作请求进行多层业务关联审计,实现访问者信息的完全追溯,包括:操作发生的url、客户端的ip、请求报文等信息,通过多层业务关联审计更精确地定位事件发生前后所有层面的访问及操作请求,使管理人员对用户的行为一目了然,真正做到数据库操作行为可监控,违规操作可追溯。
通过对不同数据库的sql语义分析,提取出sql中相关的要素(用户、sql操作、表、字段、视图、索引、过程、函数、包…) 实时监控来自各个层面的所有数据库活动,包括来自应用系统发起的数据库操作请求、来自数据库客户端工具的操作请求以及通过远程登录服务器后的操作请求等 通过远程命令行执行的sql命令也能够被审计与分析,并对违规的操作进行阻断 系统不仅对数据库操作请求进行实时审计,而且还可对数据库返回结果进行完整的还原和审计,同时可以根据返回结果设置审计规则。
灵活的策略定制:根据登录用户、源ip地址、数据库对象(分为数据库用户、表、字段)、操作时间、sql操作命令、返回的记录数或受影响的行数、关联表数量、sql执行结果、sql执行时长、报文内容的灵活组合来定义客户所关心的重要事件和风险事件 多形式的实时告警:当检测到可疑操作或违反审计规则的操作时,系统可以通过监控中心告警、短信告警、邮件告警、syslog告警等方式通知数据库管理员。
一般包括以下几方面内容:
1、登入和登出
2、数据库源头(ip和操作命令)
3、职权分离(角色和权限)
4、日志分析
5、审计数据库错误
审计系统特点
完整性:独一无二的多层业务关联审计,可针对web层、应用中间层、数据层各层次进行关联审计
细粒度:细粒度的审计规则、精准化的行为检索及回溯、全方位的风险控制。
有效性:独有专利技术实现对数据库安全的各类攻击风险和管理风险的有效控制;灵活的、可自定义的审计规则满足了各类内控和外审的需求(有效控制误操作、越权操作、恶意操作等违规行为)
公正性:基于独立审计的工作模式,实现了数据库管理与审计的分离,保证了审计结果的真实性、完整性、公正性
零风险:无需对现有数据库进行任何更改或增加配置,即可实现零风险部署
高可靠:提供多层次的物理保护、掉电保护、自我监测及冗余部署,提升设备整体可靠性
易操作:充分考虑国内用户的使用和维护习惯,提供web-based全中文操作界面及在线操作提示
软件产品举例:安华金和数据库审计系统
2017年6月1日《中华人民共和国网络安全发》的正式施行,极大促进了信息安全等级保护工作的建设。而由于信息安全等级保护三级对内控与审计方面的要求,市面上的各种审计产品如雨后春笋般涌现,用户难免会被市面上众说纷纭的解说所误导,对产品的认识可能产生偏差。(其实最好的审计就是每天的运维检查和研发数据库监控系统)
背景:
假设这么一个情况,你是某公司mysql-dba,某日突然公司数据库中的所有被人为删了。
尽管有数据备份,但是因服务停止而造成的损失上千万,现在公司需要查出那个做删除操作的人。
但是拥有数据库操作权限的人很多,如何排查,证据又在哪?
是不是觉得无能为力?
mysql本身并没有操作审计的功能,那是不是意味着遇到这种情况只能自认倒霉呢?
本文就将讨论一种简单易行的,用于mysql访问审计的思路。
概述:
其实mysql本身已经提供了详细的sql执行记录–general log(详见上篇blog) ,但是开启它有以下几个缺点
无论sql有无语法错误,只要执行了就会记录,导致记录大量无用信息,后期的筛选有难度。
sql并发量很大时,log的记录会对io造成一定的印象,是数据库效率降低。
日志文件很容易快速膨胀,不妥善处理会对磁盘空间造成一定影响。
实话实说吧,那么笔者根据以往的工作经验和经历总结出以下几种方案供读者参考。
一、mysql5.6(及其以后版本)的审计功能
mysql5.6以后的版本自带的安全审计功能,个人感觉是一个累赘的设计没有什么意义的,但有总比没有的好,期待以后的mysql版本功能越来越强大(不过oracle甲骨文收购了mysql别抱有太大的期望,还是用mariadb吧社区k8凯发棋牌的解决方案更多)
二、使用init-connect binlog的方法进行mysql的操作审计(此方法还是比较管用)
mysql服务器自身没有提供审计功能,但是我们可以使用init-connect binlog的方法进行mysql的操作审计。
由于mysql binlog记录了所有对数据库长生实际修改的sql语句,及其执行时间,和connection_id但是却没有记录connection_id对应的详细用户信息。
在后期审计进行行为追踪时,根据binlog记录的行为及对应的connection-id 结合 之前连接日志记录 进行分析,得出最后的结论。
1. 设置init-connect
1.1 创建用于存放连接日志的数据库和表
create database accesslog;
create table accesslog.accesslog (`id` int(11) primary key auto_increment, `time` timestamp, `localname` varchar(30), `matchname` varchar(30))
1.2 创建用户权限
可用现成的root用户用于信息的读取
grant select on accesslog.* to root;
如果存在具有to *.* 权限的用户需要进行限制。
这里还需要注意用户必须对accesslog表具有insert权限
grant select on accesslog.* to user@’%’;
1.3 设置init-connect
在[mysqld]下添加以下设置:
init-connect=’insertinto accesslog.accesslog(id, time, localname, matchname)
values(connection_id(),now(),user(),current_user());’
------注意user()和current_user()的区别
log-bin=xxx
这里必须开启binlog
1.4 重启数据库生效
shell> /etc/init.d/mysql restart
2. 记录追踪
2.1 thread_id确认
可以用以下语句定位语句执行人
tencent:~ # mysqlbinlog --start-datetime='2011-01-26 16:00:00'
--stop-datetime='2011-01-26 17:00:00' /var/lib/mysql/mysql-bin.000010
| grep -b 5 'wsj'
commit/*!*/;
# at 767
#110126 16:16:43 server id 1 end_log_pos 872 query thread_id=19 exec_time=0 error_code=0
use test/*!*/;
set?timestamp=1296029803/*!*/;
create table wsj(id int unsigned not null)
--
begin
/*!*/;
# at 940
#110126 16:16:57 server id 1 end_log_pos 1033 query thread_id=19 exec_time=0 error_code=0
set?timestamp=1296029817/*!*/;
insert into wsj(id) values (1)
--
begin
/*!*/;
# at 1128
#110126 16:16:58 server id 1 end_log_pos 1221 query thread_id=19 exec_time=0 error_code=0
set?timestamp=1296029818/*!*/;
insert into wsj(id) values (2)
2.2 用户确认
thread_id 确认以后,找到元凶就只是一条sql语句的问题了。
mysql> select * from accesslog where id=19;
---- --------------------- --------------------- -----------
| id | time | localname | matchname |
---- --------------------- --------------------- -----------
| 19 | 2011-01-26 16:15:54 | test@10.163.164.216 | test@% |
---- --------------------- --------------------- -----------
1 row in set (0.00 sec)
3. q
q:使用init-connect会影响服务器性能吗?
a:理论上,只会在用户每次连接时往数据库里插入一条记录,不会对数据库产生很大影响。除非连接频率非常高(当然,这个时候需要注意的就是如何进行连接复用和控制,而非是不是要用这种方法的问题了)---如果采用长连接并且缓存的话,可以提高性能
q:access-log表如何维护?
a: 由于是一个log系统,推荐使用archive存储引擎,有利于数据厄压缩存放。如果数据库连接数量很大的话,建议一定时间做一次数据导出,然后清表。
q:表有其他用途么?
a:有!access-log表当然不只用于审计,当然也可以用于对于数据库连接的情况进行数据分析,例如每日连接数分布图等等,只有想不到没有做不到。---可以用来测试读写分离,验证负载均衡等
q:会有遗漏的记录吗?
a:会的,init-connect 是不会在super用户登录时执行的。所以access-log里不会有数据库超级用户的记录,这也是为什么我们不主张多个超级用户,并且多人使用的原因。--这种审计不会记录root等具有super权限的账号对数据库的访问
三、mysql audit—sql审计插件or第三方开源审计插件:libaudit_plugin.so 来完成mysql的审计工作(插件很常用审计)
mysql audit plugin是一个 mysql安全审计插件,由mcafee提供,设计强调安全性和审计能力。
windows和linux参考:mysql audit—sql审计插件 https://www.linuxidc.com/linux/2017-08/146256.htm
mysql--audit审计 - ?https://blog.csdn.net/dbaxiaosa/article/details/51783214
四、基于360开源数据库流量审计mysql sniffer(别忽视了开源的软件的力量,对于初创公司可以省不少事)
具体设置:基于360开源数据库流量审计mysql sniffer - 博客园 https://www.cnblogs.com/qcfeng/p/7390006.html
五、使用elk处理mysql数据库审计日志(elk日志分析功能是很强大的)
拒绝背锅,使用elk处理mysql数据库审计日志-elk-运维人生 http://www.ywadmin.com/?id=86
六、mysql bin-log日志进行实时存储和行为分析 当触发设定的规则就实现记录和告警
七、开启mysql监控,实施监控日志和用户命令的操作 ,这类往往是一个平台或者软件开发结果集
总之开源的不好用,就二次开发或者自研重写。
这是一项软件工程,开源的mysql监控系统有很多,弹药满足企业自身发展的需求的并不多。所以需要大量的测试和作二次开发
当然还可以尝试一种一劳永逸的方式,使用第三方的数据库审计系统,以安华金和数据库安全审计系统为例,咱们重点讲解一下部署方式:
【物理部署】
对于要求高吞吐量、高性能敏感度、高稳定性的业务系统,将das旁路物理部署于网络中,持续监控系统的访问行为,并对安全事件进行事后分析。
das通过交换机镜像的数据流量实现对数据库行为的旁路监听,完全独立于数据库部署,不影响数据库的正常使用。
【虚拟化部署】
在无法通过交换机镜像引流时,将rmagent插件部署于数据库服务器中,rmagent从数据库服务器获取流量并将其通过网络发送给das,以完成数据采集。
【云化部署】
das支持云化部署,为云环境部署提供api接口,适用于主流私有云环境部署,如:青云、华为云、阿里云、腾讯云等。
【混合部署】
das支持混合部署,在混合部署的场景下,推荐安装rmagent插件,以实现审计复杂网络环境中的数据库流量。
试用申请