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)
参数说明:
startime
和endtime
分别表示审计记录的开始时间和结束时间,满足审计条件的记录为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)将用户的所有操作写入审计日志。数据库安全管理员可以利用这些日志信息,重现导致数据库现状的一系列事件,找出非法操作的用户、时间和内容等。
- 点赞
- 收藏
- 关注作者
评论(0)