GaussDB(DWS)数据库安全守护者之审计日志

数据库安全对数据库系统来说至关重要，而数据库审计日志是数据库安全的重要一环。GaussDB(DWS)将用户的所有操作写入审计日志。数据库安全管理员可以利用这些日志信息，重现导致数据库现状的一系列事件，找出非法操作的用户、时间和内容等。

1.    审计日志配置

关于审计功能的配置，需要清楚审计开关的设计：

• audit_enabled：审计总开关，为布尔型开关，默认值为on，表示开启审计功能。审计总开关的开启和关闭也会被记录到审计日志中。
• audit_inner_tool：内部维护工具对应的审计开关，控制是否对来自内部维护工具的操作进行审计；为布尔型开关，默认值为off，表示关闭对来自内部维护工具的操作进行审计。内部维护工具包括：cm_agent、gs_clean、OM、gs_roach、gs_redis、wlm、gs_ctl、gs_rewind等。
• audit_operation_exec：执行成功操作对应的审计开关，支持对各操作类型进行配置，只有审计类型被配置，对应的操作执行成功时才会被记录到审计日志中。
• audit_operation_error：执行失败操作对应的审计开关，支持对各操作类型进行配置，只有审计类型被配置，对应的操作执行失败时才会被记录到审计日志中。
• audit_system_object：控制DDL操作对象的审计开关，数据库的DDL（CREATE，ALTER，DROP，表对象还包含TRUNCATE）操作的对象较多，通过该配置参数在操作对象维度上对审计进行更细粒度的控制。

以上开关属于SIGHUP类型，可以通过以下两种方式进行设置，以设置审计总开关为例：

方式一：gs_guc set设置后，重启数据库使参数生效；

gs_guc set -Z coordinator -Z datanode -N all -I all  -c "audit_enabled=on"

gs_om -t stop && gs_om -t start

方式二：gs_guc reload动态加载，不需要重启数据库，直接生效。

gs_guc reload -Z coordinator -Z datanode -N all -I all  -c "audit_enabled=on"

注意：事务操作具有一定的特殊性，一个事务块涉及到多个语句的执行。如果在事务块进行中，对事务审计配置项（transaction）进行动态修改，将导致该事务块的审计记录不完整的问题。事务审计部分对这种情况按如下约定方式处理：

• 事务进行中事务配置项开启（无头有尾），不审计后续操作（无头有尾不记尾）
• 事务进行中事务配置项关闭（有头无尾），审计后续操作直到事务end（有头无尾不掉尾）
• 事务进行中，事务开关保持开启，但审计总开关开启（开总闸），因事务块的部分语句已经执行完毕，无法记录，所以不审计改事务块的后续操作（无头有尾不记尾）
• 事务进行中，事务开关保持开启，但审计总开关关闭（断总闸），因事务块部分操作已经被记录，为保证事务记录的完整性，审计线程将继续运行，直到该事务块的end被审计后审计线程才退出（有头无尾不掉尾）
• 事务进行中，事务开关保持开启，会话结束，记录事务回滚（未提交事务必回滚）

1.1审计开关audit_operation_exec的配置

audit_operation_exec的默认配置项为：login,logout,database_process,user_lock,grant_revoke,set

表示对用户登录、注销、数据库启动\停止\切换\恢复、用户锁定\解锁、权限授予\收回、SET操作的成功场景进行审计。

如需要增加审计insert操作，可以通过以下方式进行设置：

gs_guc reload -Z coordinator -Z datanode -N all -I all  -c "audit_operation_exec= login,logout,database_process,user_lock,grant_revoke,set,insert"

支持的配置项如下：

1.2审计开关audit_operation_error的配置

audit_operation_error的默认配置项为：login

表示对登录失败的场景进行审计；

如需要增加审计insert操作，可以通过以下方式进行设置：

gs_guc reload -Z coordinator -Z datanode -N all -I all  -c "audit_operation_error= login,insert"

支持的配置项如下：

1.3审计开关audit_system_object的配置

audit_system_object的值由22个二进制位的组合求出，这22个二进制位分别代表GaussDB(DWS)的22类数据库对象。

每一位可以取值0或1，取值的含义为：

• 取值为0：表示不审计对应的数据库对象的DDL操作；
• 取值为1：表示审计对应的数据库对象的DDL操作；

例如：默认值为12295，对应的二进制为0011 0000 0000 0111（高位在前，低位在后），表示打开第0位、第1位、第2位、第12位、第13位对应对象的DDL操作的审计，具体对应DATABASE、SCHEMA、USER、DATA SOURCE、NODE GROUP这五个对象。

如需要增加审计table类型的DDL操作，可以通过以下方式进行设置：

• table在第3位，对应的十进制为8
• 在原有12295的基础上加上8，得12303
• 将audit_system_object的值设置为12303即可，如下：

gs_guc reload -Z coordinator -Z datanode -N all -I all  -c "audit_system_object = 12303"

 这22个二进制位代表的具体含义如下：

2.    审计日志查看

只有拥有AUDITADMIN属性的用户才可以查看审计记录。

审计日志需通过数据库接口pg_query_audit和pgxc_query_audit查看。pg_query_audit可以查看当前CN的审计日志，pgxc_query_audit可以查看所有CN的审计日志：

pg_query_audit(timestamptz startime,timestamptz endtime, audit_log)
pgxc_query_audit(timestamptz startime,timestamptz endtime)

参数说明：

• startime和endtime分别表示审计记录的开始时间和结束时间，满足审计条件的记录为startime ≤ 单条审计信息记录的结束时间 < endtime；
• 对于pg_query_audit，可以通过audit_log指定所查看的审计日志所在的物理文件路径，当不指定audit_log时，默认查看连接当前实例的审计日志信息。

审计日志查看结果解析，各字段含义如下：

调用pg_query_audit查看审计日志记录：

postgres=# SELECT * FROM pg_query_audit('2021-02-23 21:49:00','2021-02-23 21:50:00');

查询结果如下：

         begintime         |          endtime          | operation_type | audit_type | result |  username  | database | client_conninfo | object_name | command_text |                           detail_info                            | transaction_xid | query_id |  node_name   |            thread_id            | local_port | remote_port 
---------------------------+---------------------------+----------------+------------+--------+------------+----------+-----------------+-------------+--------------+------------------------------------------------------------------+-----------------+----------+--------------+---------------------------------+------------+-------------
 2021-02-23 21:49:57.76+08 | 2021-02-23 21:49:57.82+08 | login_logout   | user_login | ok     | ommdbadmin | postgres | gsql@[local]    | postgres    | login db     | login db(postgres) successfully, the current user is: ommdbadmin | 0               | 0        | coordinator1 | 140324035360512@667403397820909 | 27777      |

调用pgxc_query_audit查看所有CN节点的审计日志记录：

postgres=# SELECT * FROM pgxc_query_audit('2021-02-23 22:05:00','2021-02-23 22:07:00') where audit_type = 'user_login' and username = 'user1';

查询结果如下：

         begintime          |          endtime           | operation_type | audit_type | result | username | database | client_conninfo | object_name | command_text |                         detail_info                         | transaction_xid | query_id |  node_name   |            thread_id            | local_port | remote_port 
----------------------------+----------------------------+----------------+------------+--------+----------+----------+-----------------+-------------+-----------------+-------------------------------------------------------------+-----------------+----------+--------------+---------------------------------+------------+-------------
 2021-02-23 22:06:22.219+08 | 2021-02-23 22:06:22.271+08 | login_lgout    | user_login | ok     | user1    | postgres | gsql@[local]    | postgres    | login db     | login db(postgres) successfully, the current user is: user1 | 0               | 0        | coordinator2 | 140689577342720@667404382271356 | 27782      |  
 2021-02-23 22:05:51.697+08 | 2021-02-23 22:05:51.749+08 | login_lgout    | user_login | ok     | user1    | postgres | gsql@[local]    | postgres    | login db     | login db(postgres) successfully, the current user is: user1 | 0               | 0        | coordinator1 | 140525048424192@667404351749143 | 27777      |

3.    审计日志维护

用户必须拥有审计权限。

可以通过配置相关参数，实现对包括审计日志存储路径、单个审计日志文件的大小等功能的维护。

• 审计日志维护相关的配置项如下：

• 审计日志保存方式

目前，常用的审计日志保存方式为记录到表中和记录到OS文件中两种方式。但是表是数据库对象，如果采用记录到表中的方式，容易出现用户非法操作审计表的情况，审计记录的准确性难以保证，因此，从数据库安全角度出发，GaussDB(DWS)采用记录到OS文件的方式来保存审计结果，保证了审计结果的可靠性。

• 审计日志保存策略

审计日志有两种保存策略，由参数audit_resource_policy控制：

（1）on表示采用空间优先策略，日志总量超过audit_space_limit时，将清理最早的审计日志文件。

（2）off表示采用时间优先策略，在空间audit_space_limit允许的情况下，存储时间audit_file_remain_time以内的日志，超过时间audit_file_remain_time的审计日志文件将被清理；当audit_file_remain_time设置过大，导致审计日志所占空间达到audit_space_limit时，将清理最早的审计日志文件。