目录
openGauss数据库SQL引擎
openGauss数据库执行器技术
openGauss存储技术
openGauss事务机制
openGauss数据库安全
Ⅰ.openGauss安全机制概览
Ⅱ.openGauss安全认证
Ⅲ.openGauss角色管理机制
Ⅳ.openGauss审计与追踪
1.审计记录机制
2.审计追踪机制
3.统一审计
Ⅴ.openGauss数据安全技术
Ⅵ.openGauss云安全技术
Ⅶ.openGauss智能安全机制
四.openGauss审计与追踪
openGauss在部署完成后,实际上会有多个用户参与数据管理。除了管理员用户外,更多的是创建的普通用户直接进行数据管理。用户的多样性会导致数据库存在一些不可预期的风险。如何快速发现和追溯到这些异常的行为,则需要依赖审计机制和审计追踪机制。
审计记录机制01
审计记录的关键在于:
§ 定义何种数据库操作行为需要进行日志记录。
§ 记录的事件以何种形式展现和存储。
只有有效的记录了所关心的行为信息,才能依据这些行为进行问题审计和追溯,实现对系统的一个有效监督。
正如我们在“三权分立模型”章节描述的,进行权限分离后,就出现了审计管理员(当然也可以使用普通角色管理模型中的系统管理员来担当)。审计管理员最重要的作用在于对管理员以及普通用户所有关心的行为进行记录和审计追溯。审计首先要定义审计哪些数据库行为,其次需要定义审计内容记录在什么文件中以及何种目录下,最后需要定义清楚应提供何种接口供审计管理员进行审计查询。
openGauss针对用户所关心的行为提供了基础审计能力,包括事件的发起者、发生的时间和发生的内容。openGauss的审计功能受总体开关audit_enabled控制,默认开启。该开关不支持动态加载,需要重启数据库后才可以使功能的性质发生改变。在总体开关的基础上,openGauss增加了每一个对应审计项的开关。只有相应的开关开启,对应的审计功能项才能生效。
不同于总体开关,每一个对应的子审计项都支持动态加载,在数据库运行期间修改审计开关的值,不需要重启数据库即可支持。审计的子项目包括如下的部分:
§ audit_login_logout:用户登录、注销审计
§ audit_database_process:数据库启动、停止、恢复和切换审计
§ audit_user_locked:用户锁定和解锁审计
§ audit_user_violation:用户访问越权审计
§ audit_grant_revoke:授权和回收权限审计
§ audit_system_object:数据库对象的Create、Alter和Drop操作审计
§ audit_dml_state:具体表的INSERT、UDPDATE和DELETE操作审计
§ audit_dml_state_select:select查询操作审计
§ audit_copy_exec:copy行为审计
§ audit_function_exec:审计执行function的操作
§ audit_set_parameter:审计设置参数的行为
定义完审计记录行为后,当数据库执行相关的操作,内核独立的审计线程就会记录审计日志。
传统的审计日志保存方法有两种,记录到数据库的表中以及记录到OS文件中。前种方法由于表是数据库的对象,在符合权限的情况下就可以访问到该审计表,当发生非法操作时,审计记录的准确性难以得到保证。而后种方法虽然需要用户维护审计日志,但是比较安全,即使一个账户可以访问数据库,但不一定有访问OS这个文件的权限。
与审计日志存储相关的配置参数及其含义定义如下:
§ audit_directory:字符串类型,定义审计日志在系统中的存储目录,一个相对于“/data”数据目录的路径,默认值为:/var/log/openGauss/perfadm/pg_audit,也可以由用户指定。
§ audit_resource_policy:布尔类型,控制审计日志的保存策略,即以空间还是时间限制为优先策略决定审计文件更新,默认值为on。
§ audit_space_limit:整型类型,定义允许审计日志占用的磁盘空间总量,默认值为1GB,在实际配置中需要结合环境进行总体考虑。
§ audit_file_remain_time:整型类型,定义保留审计日志的最短时间要求,默认值为90,单位为天。特别的,如果取值为0,则表示无时间限制。
§ audit_file_remian_threshold:整型类型,定义审计目录audit_directory下可以存储的审计文件个数。默认值为1048576。
§ audit_rotation_size:整型类型,定义单个审计日志文件的最大大小,当审计日志文件大小超过此参数值时,新创建一个审计文件。
§ audit_rotation_interval:整型类型,定义新创建一个审计日志文件的时间间隔。默认值为1天,单位为分钟。
通过上述的这些配置参数,系统管理员用户可以在查询任务发生后找到对应的审计日志,并进行有效归档。审计日志文件也会按照参数指定的规则来进行更新、轮换等。
审计追踪机制02
openGauss将审计所产生的文件独立存放在审计文件中,并按照产生的先后顺序进行标记管理,并以特定的格式进行存储(默认为二进制格式文件)。当审计管理员需要进行审计查询时,通过执行函数pg_query_audit即可,其具体的语法如下所示:
select * from pg_query_audit(timestamp valid_start_time, timestamp valid_end_time, audit_log);
其中,valid_start_time和valid_end_time定义了审计管理员将要审计的有效开始时间和有效结束时间;audit_log表示审计日志信息所在的归档路径,当不指定该参数时,默认查看链接当前实例的审计日志文件(不区分具体的审计文件)。
值得注意的是,valid_start_time和valid_end_time的有效值为从valid_start_time日期中的00:00:00开始到valid_end_time日期中23:59:59之间。由于审计日志中包含了众多的信息,如时间、地点、行为分类等等,审计管理在获得完整的信息后可以增加各种过滤条件来获得相对应的更明确的信息。
统一审计03
传统审计依据开关定义了不同的审计组合行为。事实上,这种无区分对待的审计行为虽然记录了所有想要审计的行为,但是对于通过审计日志发现问题则显得不那么容易,且管理员无法为特定的用户定义特定的行为,反而造成了系统处理的负担。因此需要为审计添加更精细化管理的能力。
统一审计的目的在于通过一系列有效的规则在数据库内部有选择性执行有效的审计,从而简化管理,提高数据库生成的审计数据的安全性。本节所述的技术目前处于研发阶段,对应产品尚未向客户发布。
openGauss提供了一套完整的统一审计策略机制,依据不同任务的诉求对用户的行为进行定制化审计管理。更进一步,openGauss的统一审计不仅可以依据用户、依据表进行审计行为定义,同时还可以扩展至通过IP地址、APP的名称来过滤和限制需要审计的内容。实际的语法如下所示:
CREATE AUDIT_POLICY policy_name
[
(privilege_audit_clause) | (access_audit_clause)
[filter_clause FILTER_TYPE(filter_value)]
[ENABLED|DISABLED]
];
其中,privilege_audit_clause定义语法如下:
PRIVILEGES (DDL|ALL) [ ON (LABEL(resource_label_name)) [, …]* ];
该语法定义了针对DDL类语句的审计策略,其中LABEL表示一组资产集合,即数据库对象的集合。access_audit_clause定义语法如下:
ACCESS (DML|ALL) [ ON (LABEL(resource_label_name)) [, ...]* ];
该语法定义了针对DML类语句的审计策略。filter_clause标记需要过滤的信息,常见的Filter types类型包括IP、APPS应用(访问的应用名)、ROLES(数据库系统用户)以及LABEL对象。
一个有效的统一审计策略可参见如下:
CREATE AUDIT_POLICY admin_policy PRIVILEGES CREATE, ALTER, DROP FILTER ON IP(local), ROLES(dev);
表示创建针对CREATE/ALTER/DROP操作的审计策略,审计策略只对dev用户在本地(local)执行CREATE/ALTER/DROP行为时生效。
未完待续......