探索BI系统搭建的必要性与AI技术的应用潜力
1326
2022-05-29
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"
支持的配置项如下：
配置项
描述
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
表示对游标操作成功的场景进行审计
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"
支持的配置项如下：
配置项
描述
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
表示对黑名单操作的执行失败进行审计
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个二进制位代表的具体含义如下：
二进制位
含义说明
第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操作
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时，默认查看连接当前实例的审计日志信息。
审计日志查看结果解析，各字段含义如下：
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 |
3. 审计日志维护
用户必须拥有审计权限。
可以通过配置相关参数，实现对包括审计日志存储路径、单个审计日志文件的大小等功能的维护。
审计日志维护相关的配置项如下：
配置项
含义
默认值
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时，将清理最早的审计日志文件。
EI企业智能 Gauss AP 云安全 数据仓库服务 GaussDB(DWS)
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。
相关文章
推荐文章
最近发表
