目录
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 行为时失效。
未完待续 ……