1. 说明
本篇文章主要说一说Oracle数据库安全审计控制点中b、c、d测评项的相关内容和理解,以及一些其它零碎的与等保相关的内容。
2. 测评项
b)审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息;c)应对审计记录进行保护,定期备份,避免受到未预期的删除、修改或覆盖等;d)应对审计进程进行保护,防止未经授权的中断。
3. 测评项b
b)审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息;
审计记录应该包含足够的信息,对于数据库的审计而言而言,包含具体的SQL
语句是必须的。
从Oracle安全审计(上)
中可以得知,对于SYS
用户,需要参数audit_sys_operations
设置为true
才会记录sys
用户的具体操作的语句,否则只记录开启数据库、关闭数据库、建立连接等信息。
对于普通用户,则需要audit_trail
参数设置为db, extended
或xml, extended
,否则不会记录具体的sql语句。
实际测评时,参数需要查看,同时具体的日志文件也需要查看,查看其是否真的存在记录。
3.1. 数据库表中的记录
如果audit_trail
参数设置为db
或db,extended
,则其记录存放在数据库的表中。
sys.aud$ 表,审计记录的存放表,其它的视图都是从这里获取的数据:
select * from aud$;
这里要说一句,sys.aud$
中的sqlbind
、sqltext
在PL/SQL
中不会直接显示出值:
要手动选择编辑器查看:
或者直接查询某个列:
select dbms_lob.substr(SQLTEXT) from aud$
dba_audit_trail视图,感觉和aud$表差不多,但是它的sqlbind
、sqltext
列是直接显示信息的:
dba_audit_object视图,可以查询所有对象跟踪信息:
dba_audit_session视图,所得到的数据都是有关logon或者logoff的信息:
dba_audit_statement,列出grant ,revoke ,audit ,noaudit ,alter system语句的审计跟踪信息:
audit_actions,可以查询出在aud$等视图中actions列的含义(如果是将记录定位至操作系统的文件中,则日志文件中也会有类似actions的列):
system_privilege_map,可以查询出aud$等视图中priv$used列的含义(如果是将记录定位至操作系统的文件中,则日志文件中可能也会有类似priv$used的列):
3.2. 操作系统中的记录
sys
用户的记录都是存放在操作系统文件中的,普通用户的记录如果设置audit_trail
参数为os、xml、db,extended,也会存放在文件中。
对于Windows而言,可以在事件查看器中的应用程序中进行查看。
对于Linux而言,要查看audit_file_dest
参数,得知存储文件的路径:
路径如下(文件好像是登录1次生成1次):
[root@centos01 adump]# ll总用量 2012-rw-r----- 1 oracle oinstall 932 6月 30 2019 oraclesi_ora_10001_1.aud-rw-r----- 1 oracle oinstall 721 6月 30 2019 oraclesi_ora_10008_1.aud-rw-r----- 1 oracle oinstall 1141 6月 30 2019 oraclesi_ora_10115_1.aud-rw-r----- 1 oracle oinstall 721 6月 30 2019 oraclesi_ora_10127_1.aud-rw-r----- 1 oracle oinstall 721 6月 30 2019 oraclesi_ora_10136_1.aud-rw-r----- 1 oracle oinstall 721 6月 30 2019 oraclesi_ora_10149_1.aud-rw-r----- 1 oracle oinstall 728 7月 16 11:17 oraclesi_ora_10289_1.aud
内容如下段落:
Sat Jul 18 21:11:07 2020 +08:00LENGTH : '193'ACTION :[30] 'update test8.testy set no=102 'DATABASE USER:[3] 'sys'PRIVILEGE :[6] 'SYSDBA'CLIENT USER:[2] 'cx'CLIENT TERMINAL:[15] 'DESKTOP-7TRO2L7'STATUS:[1] '0'DBID:[10] '1539943106'
另外,如果audit_syslog_level
设置了值,就要查看它的值,以及查看系统中syslog.conf
的内容,判断最后将记录输出到哪个文件中。
具体怎么判断,可以把等保测评2.0:Oracle安全审计(上)
的相关内容看一看。
4. 测评项c
c)应对审计记录进行保护,定期备份,避免受到未预期的删除、修改或覆盖等;
4.1. 审计记录的保护
其实在Oracle
官方文档中,就建议用户将审计记录存储于操作系统的文件中。
因为如果存储在表中,dba
用户可以随意删除其中的记录。
而存储于文件中,且该文件仅root或专门的用户可以操作的话,则实现了权限隔离,使得记录不会随意受到修改。
如果存储在文件中,则查询该文件的权限设置,是否不允许操作系统中的数据库用户(比如oracle用户)进行修改。
如果存储在表中,则要看dba角色、update any table等权限被授予给哪些用户了
以及查看o7_dictionary_accessibility参数的值,详情可看等保测评2.0:Oracle访问控制(下)的3.6节。
4.2. 审计记录的备份
如果是存储在数据库中,则对数据库进行备份即可。
在linux上,一般使用定时任务跑备份脚本,测评时直接查看脚本内容以及是否设置了定时任务:
[root@centos01 adump]# crontab -lno crontab for root
然后再查看是否真的存在备份的文件。
如果是存储在文件中,同样也是这个方法。
或者对方使用了软件、备份一体机等,也是要查看策略以及实际备份的文件是否存在。
另外说一句,如果使用了分布式存储,数据同时存在2个或2个以上的可用副本,这个不叫做备份,应该输入热冗余范畴内。
只能说你存在多个副本,某个副本所依赖的硬件出问题了,那其余副本还正常存在,数据没有丢失。
但是如果你删除了某一条数据,则多个副本也同时删除了这一条数据,这条数据就没了。
假如你之前进行了备份,那么这条数据就还在,这就是差别。
4.3. 审计记录的留存时间
在等保测评2.0:MySQL安全审计
的5.2节中,对于网络安全法中对日志留存时间的要求如何测评,进行过一些个人的猜想。
我的个人理解是由于测评项没有作出明确的要求,测评要求中也未进行说明。
同时根据最新的高风险项判定指引(5月28日版)的内容,对于日志留存时间仅应用系统以及集中管控中存在高风险项。
所以我觉得3级系统的各个设备(服务器、数据库等)的日志留存时间,应该集中在集中管控的测评项中统一描述,不用在每个被测评对象的安全审计控制点的c测评项中进行描述。
这么想的话,逻辑上还算自洽。
但是2级系统的的各个设备(服务器、数据库等)的日志留存时间要不要进行测评,就让人疑惑了。
咨询了某位大佬,他的回答如下(文章中的章节指的是最新版的高风险项判定指引):
有点复杂,其实第一次征求意见时这个问题就提出来了,有两种意见,一种是《网络安全法》要求,不分等级,所以二级也要保存6个月;另一种是《网络安全法》的要求前半句是“网络运营者应当按照网络安全等级保护制度的要求,履行下列安全保护义务”,且对于要保存的日志内容,应该是“采取监测、记录网络运行状态、网络安全事件的技术措施,并按照规定留存相关的网络日志不少于六个月”,并不是所有日志都需要保留6个月,且应该是按照“等保的规定”保存,等保要求中只对三级系统有明确保存时间上的要求(即安全管理中心的“应对分散在各个设备上的审计数据进行收集汇总和集中分析,并保证审计记录的留存时间符合法律法规要求”要求),因此,应该是3级系统上判高风险。
最后综合各方意见,做了一个折中的处理:1、对于3级系统,设备日志和应用日志都要至少保存6个月(设备日志在8.1.2章节体现,应用日志在7.2.3.2章节体现);2、对于2级系统,考虑到应用相关日志相对来说对于时间追溯比较重要,,因此作为强制要求,并对应到“应对审计记录进行保护,定期备份,避免受到未预期的删除、修改或覆盖等。”这条要求里;至于设备,由于其自身存储的能力有限,如果没有日志服务器集中存储,日志保存六个月难度比较大,而恰恰2级并没有集中存储的要求,因此,在这一版的《指引》中暂不明确要求,测评时可以根据实际情况进行判断。
5. 测评项d
d)应对审计进程进行保护,防止未经授权的中断。
从基本层面来说,就是修改与审计相关的参数的权限是否得到控制:
SQL> show parameter audit;NAME TYPE VALUE------------------------------------ ----------- ------------------------------audit_file_dest string /oracle/admin/orcl/adumpaudit_sys_operations boolean TRUEaudit_syslog_level stringaudit_trail string NONE
修改参数的语句格式为:
alter system 参数=值 scope=spfile;
所以理论上应该是查看alter system
这个系统权限、dba
角色的授予情况。
另外,这些修改后都是需要重启数据库才能生效的,也只有特权用户sysdba、sysoper才有相关的权限。
所以,还要查看sysdba、sysoper被授予给了谁。
6. Mysql数据库的身份鉴别
在等保测评2.0:MySQL身份鉴别(下)
对身份鉴别控制点c项进行过说明,但是没说全。
c)当进行远程管理时,应采取必要措施防止鉴别信息在网络传输过程中被窃听;
其实和Oracle一样,Mysql数据库就算不适用SSL协议,也不会做出明文传输口令、口令的hash值这种举动的。
Mysql在客户端连接数据库时,也是使用挑战/应答(Challenge/Response)方式进行鉴别的,具体什么是挑战/应答(Challenge/Response)方式请看等保测评2.0:Oracle身份鉴别(下)的4.2节。
所以具体到测评项的判定而言,默认情况下至少判定为部分符合,根据具体情况再选择是否判定为符合。
具体Mysql的鉴别过程,我就不抓包进行验证了,官网上有相关的说明,网上也有很多文章,有兴趣的可以自己验证下:
https://dev.mysql.com/doc/internals/en/successful-authentication.html (官网说文章中的内容已过时,但是没过时的就是找不到……)
http://www.phpweblog.net/GaRY/archive/2010/08/20/mysql_client_to_server_auth_method.html
![bf39f341748c90ac22159abe168a28dc.gif](https://i-blog.csdnimg.cn/blog_migrate/9b5e411cf7b94a5a3341aeb31ed3a71d.gif)
精彩推荐
![f1071bdff0e88b7d3a8fa22e96e8fa9d.png](https://i-blog.csdnimg.cn/blog_migrate/829ec0430f7f4d8211002293ed265028.jpeg)
![87e5f94ebb860416ceeee084996fa778.png](https://i-blog.csdnimg.cn/blog_migrate/c33a43c893693e226a27eee9c1d421e2.png)
![53cbb03e6f0b265c8486be809ba5dd95.png](https://i-blog.csdnimg.cn/blog_migrate/e79a8c19252a2586c6b3ffdd1b33e05e.png)