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

举报
半岛里有个小铁盒 发表于 2024/01/09 20:49:41 2024/01/09
【摘要】 数据库安全的所有操作写对数据库系统来说至关重要,而数据库审计日志是数据库安全的重要一环。本文主要讲解GaussDB(DWS)审计功能如何使用,主要分为:审计日志配置、审计日志查看、审计日志维护三个方面。

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

1. 前言

  • 适用版本:【8.1.3及以上】

  数据库安全的所有操作写对数据库系统来说至关重要,而数据库审计日志是数据库安全的重要一环。本文主要讲解GaussDB(DWS)审计功能如何使用,主要分为:审计日志配置、审计日志查看、审计日志维护三个方面。

2. 审计日志配置

  关于审计功能的配置,需要清楚审计开关的设计:

  • 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被审计后审计线程才退出(有头无尾不掉尾)
  • 事务进行中,事务开关保持开启,会话结束,记录事务回滚(未提交事务必回滚)

2.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"

支持的配置项如下:

配置项 描述
none 表示未配置审计项,如果同时配置了其他任何审计项,则none失效
all 表示对所有操作成功的场景进行审计。如果同时配置了其他任何审计项,则覆盖所有其他审计项的配置。
需要注意,即使配置为all,也不表示对所有的DDL操作进行审计,仍然需要结合audit_system_object,对DDL操作的对象级别进行控制
login 表示对用户登录成功的场景进行审计,默认配置
logout 表示对用户退出进行审计,默认配置
database_process 表示对数据库启动、停止、切换、恢复操作进行审计,默认配置
user_lock 表示对用户锁定和解锁成功的场景进行审计,默认配置
grant_revoke 表示对用户权限授予和回收成功的场景进行审计,默认配置
ddl 表示对DDL操作成功的场景进行审计,因为DDL操作由会根据操作对象进行更细粒度控制,仍然沿用审计开关audit_system_object,即由audit_system_object控制对哪些对象的DDL操作进行审计(此处不配置ddl,只要配置了audit_system_object,审计也会生效)
select 表示对select操作成功的场景进行审计
copy 表示对copy操作成功的场景进行审计
userfunc 表示对用户自定义函数、存储过程、匿名块操作成功的场景进行审计
set 表示对set操作成功的场景进行审计,默认配置
transaction 表示对事务操作成功的场景进行审计
vacuum 表示对vacuum操作成功的场景进行审计
analyze 表示对analyze操作成功的场景进行审计
explain 表示对explain操作成功的场景进行审计
specialfunc 表示对特殊函数调用操作成功的场景进行审计,包括:pg_terminate_backend、pg_cancel_backend
insert 表示对insert操作成功的场景进行审计
update 表示对update操作成功的场景进行审计
delete 表示对delete操作成功的场景进行审计
merge 表示对merge操作成功的场景进行审计
show 表示对show操作成功的场景进行审计
checkpoint 表示对checkpoint操作成功的场景进行审计
barrier 表示对barrier操作成功的场景进行审计
cluster 表示对cluster操作成功的场景进行审计
comment 表示对comment操作成功的场景进行审计
cleanconn 表示对clean connection操作成功的场景进行审计
prepare 表示对PREPARE、EXECUTE、DEALLOCATE操作成功的场景进行审计
constraints 表示对constraints操作成功的场景进行审计
cursor 表示对游标操作成功的场景进行审计

2.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"

支持的配置项如下:

配置项 描述
none 表示未配置审计项,如果同时配置了其他任何审计项,则none失效
syn_success 表示同步audit_operation_exec的配置,即配置了某操作执行成功场景的审计,则对应的执行失败场景也记入审计。需注意,配置了syn_success后,仍可以继续配置其他操作执行失败场景的审计;
如果audit_operation_exec配置为all,则所有的失败场景均记入审计;如果audit_operation_exec配置为none,则syn_success等同于none,即未配置审计项
parse 表示对用户输入命令解析失败场景进行审计,包含等待命令超时的失败场景
login 表示对用户登录失败的场景进行审计,默认配置
user_lock 表示对用户锁定和解锁失败的场景进行审计
violation 表示对用户访问存在越权的场景进行审计
grant_revoke 表示对用户权限授予和回收失败的场景进行审计
ddl 表示对DDL操作失败的场景进行审计,因为DDL操作由会根据操作对象进行更细粒度控制,仍然需要结合audit_system_object的配置情况,所以此处配置ddl后,将对audit_system_object指定类型的DDL失败场景进行审计
select 表示对SELECT操作失败的场景进行审计
copy 表示对COPY操作失败的场景进行审计
userfunc 表示对用户自定义函数、存储过程、匿名块操作失败的场景进行审计
set 表示对SET操作失败的场景进行审计
transaction 表示对事务操作失败的场景进行审计
vacuum 表示对VACUUM操作失败的场景进行审计
analyze 表示对ANALYZE操作失败的场景进行审计
explain 表示对EXPLAIN操作失败的场景进行审计
specialfunc 表示对特殊函数调用操作失败的场景进行审计,包括:pg_terminate_backend、pg_cancel_backend
insert 表示对INSERT操作失败的场景进行审计
update 表示对UPDATE操作失败的场景进行审计
delete 表示对DELETE操作失败的场景进行审计
merge 表示对MERGE操作失败的场景进行审计
show 表示对SHOW操作失败的场景进行审计
checkpoint 表示对CHECKPOINT操作失败的场景进行审计
barrier 表示对BARRIER操作失败的场景进行审计
cluster 表示对CLUSTER操作失败的场景进行审计
comment 表示对COMMENT操作失败的场景进行审计
cleanconn 表示对CLEAN CONNECTION操作失败的场景进行审计
prepare 表示对PREPARE、EXECUTE、DEALLOCATE操作失败的场景进行审计
constraints 表示对CONSTRAINTS操作失败的场景进行审计
cursor 表示对游标操作失败的场景进行审计
blacklist 表示对黑名单操作的执行失败进行审计

2.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个二进制位代表的具体含义如下:

二进制位 含义说明
第0位 是否审计DATABASE对象的CREATE、DROP、ALTER操作
第1位 是否审计SCHEMA对象的CREATE、DROP、ALTER操作
第2位 是否审计USER对象的CREATE、DROP、ALTER操作
第3位 是否审计TABLE对象的CREATE、DROP、ALTER、TRUNCATE操作
第4位 是否审计INDEX对象的CREATE、DROP、ALTER操作
第5位 是否审计VIEW对象的CREATE、DROP、ALTER操作
第6位 是否审计TRIGGER对象的CREATE、DROP、ALTER操作
第7位 是否审计PROCEDURE/FUNCTION对象的CREATE、DROP、ALTER操作
第8位 是否审计TABLESPACE对象的CREATE、DROP、ALTER操作
第9位 是否审计RESOURCE POOL对象的CREATE、DROP、ALTER操作
第10位 是否审计WORKLOAD对象的CREATE、DROP、ALTER操作
第11位 是否审计SERVER FOR HADOOP对象的CREATE、DROP、ALTER操作
第12位 是否审计DATA SOURCE对象的CRAETE、DROP、ALTER操作
第13位 是否审计NODE GROUP对象的CREATE、DROP、ALTER操作
第14位 是否审计ROW LEVEL SECURITY对象的CREATE、DROP、ALTER操作
第15位 是否审计TYPE对象的CREATE、DROP、ALTER操作
第16位 是否审计TEXT SEARCH对象(CONFIGURATION和DICTIONARY)的CREATE、DROP、ALTER操作
第17位 是否审计DIRECTORY对象的CREATE、DROP、ALTER操作
第18位 是否审计SYNONYM对象的CREATE、DROP、ALTER操作
第19位 是否审计REDACTION POLICY对象的CREATE、DROP、ALTER操作
第20位 是否审计SEQUENCE对象的CREATE、DROP、ALTER操作
第21位 是否审计NODE对象的CREATE、DROP、ALTER操作

3. 审计日志查看

  只有拥有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)

参数说明:

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

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

字段 含义
begintime 执行操作的开始时间
endtime 执行操作的结束时间,查看审计日志是根据此时间判断的
operation_type 操作类型
audit_type 审计类型
result 执行操作的结果
username 执行操作的用户名
database 数据库名称
client_conninfo 客户端信息
object_name 操作对象的名称
command_text 执行操作的命令
detail_info 执行操作详细信息
transaction_xid 事务id
query_id query id
node_name 节点名称
thread_id 线程id
local_port 本地节点
remote_port 远端节点

调用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      |

4. 审计日志维护

  用户必须拥有审计权限。
  可以通过配置相关参数,实现对包括审计日志存储路径、单个审计日志文件的大小等功能的维护。

  • 审计日志维护相关的配置项如下:
配置项 含义 默认值
audit_directory 审计文件的存储目录 mpp/用户名/pg_audit
audit_data_format 审计日志文件的格式 binary(当前仅支持二进制格式)
audit_rotation_interval 创建一个新审计日志文件的时间间隔 1440min
audit_rotation_size 单个审计日志文件的最大容量 10MB
audit_resource_policy 审计日志的保存策略 on(表示使用空间优先策略)
audit_space_limit 审计文件占用的磁盘空间总量 1GB
audit_file_remain_time 审计日志文件的最小保存时间 90d
audit_file_remain_threshold 审计目录下审计文件的最大数量 1048576
  • 审计日志保存方式
      目前,常用的审计日志保存方式为记录到表中和记录到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时,将清理最早的审计日志文件。

5. 总结

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

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。