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:00

LENGTH : '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 -l

no 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/adump

audit_sys_operations boolean TRUE

audit_syslog_level string

audit_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 (官网说文章中的内容已过时，但是没过时的就是找不到……)